MPLS Working Group S. Bryant Internet Draft Cisco Intended status: Standards Y. Weingarten N. Sprecher Nokia Siemens Networks H. van Helvoort Huawei A. Fulignoli Ericsson Expires: September 2009 March 9, 2009 MPLS-TP Linear Protection draft-weingarten-mpls-tp-linear-protection-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 9, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Weingarten et al. Expires September 9, 2009 [Page 1] Internet-Draft MPLS-TP Linear Protection March 2009 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes mechanisms for linear protection of Multi- Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) and Pseudowires (PW) on multiple layers. Linear protection provides a fast and simple protection switching mechanism, that is especially optimized for a mesh topology. It provides a clear indication of the protection status. The mechanisms are described both at the architectural level as well as providing a protocol that is used to control and coordinate the protection switching. Table of Contents 1. Introduction...............................................3 1.1. Contributing Authors .................................4 2. Conventions used in this document..........................4 2.1. Abbreviations.........................................4 2.2. Definitions and terminology...........................5 3. Network objectives.........................................5 4. Protection architectures...................................6 4.1. 1+1 Protection architecture...........................6 4.2. 1:1 Protection architecture...........................7 4.3. Protection of P2MP networks...........................8 4.4. Extension to 1:n protection...........................8 4.5. Revertive and Non-revertive switching.................9 5. Protection switching trigger mechanisms....................9 5.1. Hold-off timer...................................... 10 5.2. Protection switching control logical architecture... 10 6. Protection switching coordination (PSC) protocol......... 12 6.1. Protocol format .................................... 12 6.1.1. PSC Requests................................... 14 6.1.1.1. Interaction between requests ............. 15 6.1.2. Path fault identifier.......................... 15 6.1.3. Active path indicator.......................... 15 6.1.4. Current protection type........................ 16 6.2. Addressing of PSC requests.......................... 16 Weingarten et al. Expires September 9, 2009 [Page 2] Internet-Draft MPLS-TP Linear Protection March 2009 6.3. Principles of operation............................. 16 6.3.1. Normal state................................... 17 6.3.2. Failure or Degraded condition.................. 17 6.3.3. Lockout of protection.......................... 18 6.3.4. Operator controlled switching.................. 18 6.3.5. Recovery from switching........................ 19 6.3.5.1. Wait-to-restore timer..................... 20 7. Security Considerations.................................. 20 8. IANA Considerations...................................... 20 9. Acknowledgments.......................................... 20 10. References ............................................. 21 10.1. Normative References............................... 21 10.2. Informative References............................. 21 1. Introduction As noted in the architecture for MPLS-TP [7], the overall architecture framework for MPLS-TP is based on a profile of the MPLS and PW procedures as specified for the MPLS and (MS-)PW architectures defined in RFC 3031 [3], RFC 3985 [5] and [6]. One of the basic survivability functions, pointed out by the Survivability Framework document [11], is that of simple and rapid protection switching mechanisms for Label Switched Paths (LSP) and Pseudo-wires (PW). Protection switching is a fully allocated survivability mechanism. It is fully allocated in the sense that the route and bandwidth of the recovery path is reserved for a selected working path. It provides a fast and simple survivability mechanism that allows the network operator to easily grasp the active state of the network compared to other survivability mechanisms. This draft proposes an architecture and protocol to provide protection for the different types of point-to-point (p2p) paths supported by MPLS-TP. These include LSP, PW, Path Segment Tunnels (PST), and Tandem Connections (TC). For unidirectional protection switching a 1+1 architecture is described. For bidirectional switching both a 1+1 and a 1:1 architecture are described. In 1+1 unidirectional architecture, a recovery transport path is dedicated to each working transport path. Normal traffic is bridged and fed to both the working and the recovery transport entities by a permanent bridge at the source of the protection domain. The sink of the protection domain selects which of the working or recovery entities to receive the traffic from, based on a predetermined criteria, e.g. server defect indication. When used for bidirectional switching the 1+1 protection architecture must also support a Protection Switching Coordination (PSC) protocol. This protocol is Weingarten et al. Expires September 9, 2009 [Page 3] Internet-Draft MPLS-TP Linear Protection March 2009 used to help synchronize the decisions of both ends of the protection domain in selecting the proper traffic flow. In the 1:1 architecture, a recovery transport path is dedicated to the working transport path. However, the normal traffic is transmitted only once, on either the working or the recovery path, by using a selector bridge at the source of the protection domain. A selector at the sink of the protection domain then selects the path that carries the normal traffic. Since the source and sink need to be coordinated to ensure that the selector bridge at both ends select the same path, this architecture must support the PSC protocol. 1.1. Contributing Authors John Drake, Hao Long 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 2.1. Abbreviations DNR Do Not Revert FS Forced Switch LSR Label Switching Relay MS Manual Switch P2P Point to point P2MP Point to multipoint PSC Protection Switching Coordination Protocol PST Path Segment Tunnel SD Signal Degrade SF Signal Fail SLA Service Level Agreement WTR Wait-to-Restore Weingarten et al. Expires September 9, 2009 [Page 4] Internet-Draft MPLS-TP Linear Protection March 2009 2.2. Definitions and terminology Protection domain: Transport path (e.g. LSP, PW, PST, TC) that provides protection for its normal traffic. The protection domain consists of the following elements - Two end points (East and West) that in each direction one acts as the source and the other as the sink, a working path, and a recovery path. Recovery path: A transport path that is dedicated to transport normal user traffic in case of a failure of the Working path. Working path: A transport path that is used for transport of normal user traffic, under normal conditions. The terminology used in this document is based on the terminology defined in [10]. In addition, we use the term LSR to refer to a MPLS-TP Network Element, whether it is a LSR, LER, T-PE, or S-PE. 3. Network objectives Linear protection for MPLS-TP should comply with the following network objectives: . Switch time: protection switching should operate as fast as possible. A switching time of less than 50ms has been proposed as a target for certain use cases. The switching time does not include the detection time and the hold-off time . Hold-off times: to allow protection by the layer that is closest to the detected defect and retain the stability of the network, a hold-off timer should be employed when a defect is detected. At the expiration of the hold-off period, the defect should be rechecked and if still existing the protection mechanism shall be invoked. . Extent of protection: the protection mechanism should restore interrupted traffic due to a facility (link or node) failure, within a protection domain. Traffic terminating at a failed node may be disrupted, however, traffic passing through to other nodes should be protected. . Operation modes: the protection mechanism should provide protection for both unidirectional and bidirectional transport entities. The protection mechanism should support both revertive and non-revertive modes of operation. Weingarten et al. Expires September 9, 2009 [Page 5] Internet-Draft MPLS-TP Linear Protection March 2009 . Manual control: administrative commands may be provided for manual control of the protection switching operations. The following are examples of possible manual commands: Clear, Forced Switch, Manual Switch (see definitions in [10]). 4. Protection architectures The protection mechanism defined here supports transport paths (as defined in [2]) within a mesh-based network. This includes support for unidirectional, both point-to-point and point-to-multipoint, and bidirectional point-to-point paths. This protection may be supported by different protection architectures as described in the following subsections. 4.1. 1+1 Protection architecture The 1+1 protection architecture provides for a fully dedicated recovery path in addition to the configured working path. Both the recovery and working path must support the full SLA requirements for the traffic between the two end points of the protection domain. In this architecture (see figure 1), all traffic from LSR A to LSR Z is bridged, using the permanent bridge at LSR A, to both transport entities, and LSR Z employs a selector bridge to receive the data from the working path, discarding the packets from the recovery path. In case of a condition, e.g. a failure condition or an operator command, where protection switching is indicated, LSR Z SHOULD select the data packets from the recovery path and discard any data packets from the working path. It should be further noted that OAM packets for monitoring the protection domain, or control plane packets, may be transmitted on the "non-active" transport path. These packets SHALL NOT be discarded. |-------------Protection Domain-----------------| ============================== /**********Working path************\ +--------+ ============================== +--------+ | LSR /| |\ LSR | | A {< | | >} Z | | PB \| | SB | +--------+ ============================== +--------+ \***********Recovery path***********/ ============================== Weingarten et al. Expires September 9, 2009 [Page 6] Internet-Draft MPLS-TP Linear Protection March 2009 PB: Permanent Bridge SB: Selector Bridge Figure 1: 1+1 Unidirectional protection architecture When using the 1+1 architecture for bidirectional switching, each of the end-points would have both a permanent bridge and a selector bridge one for each direction. 4.2. 1:1 Protection architecture Another option to protect either a unidirectional or bidirectional connection is a 1:1 architecture. This architecture provides for a fully allocated recovery transport path in addition to the working transport path used for normal user data. In principle, this recovery path MUST support the full capacity and bandwidth of the SLA but may be degraded from the normal working path. |-------------Protection Domain-----------------| ============================== /**********Working path***********\ +--------+ ============================== +--------+ | LSR /| |\ LSR | | A {< | | >} Z | | SB | | SB | +--------+ ============================== +--------+ Recovery path ============================== SB: Selector Bridge Figure 2: 1:1 Bidirectional protection architecture using working path In this architecture both ends of the protection domain have a Selector bridge (SB) that selects the transport path to transmit the data packets over. Under normal conditions the SB selects the working path for transmission of the data packets. When a condition that triggers protection switching is active, the SB selects the recovery path for data transmission. In principle, the recovery path could be used for "extra traffic", i.e. preemptible traffic. However, if protection switching is in force then this traffic SHALL be pre-empted by the protected data that is being transmitted on this path. In any case, the recovery path MUST support OAM and protection coordination traffic (see section 6). Weingarten et al. Expires September 9, 2009 [Page 7] Internet-Draft MPLS-TP Linear Protection March 2009 This architecture requires communication between the end-points of the protection domain to coordinate the protection state. In general bidirectional protection switching requires coordination between the end-points and verification that both transmission directions remain on a corouted bidirectional path. 4.3. Protection of P2MP networks [2] specifies that all P2MP MPLS-TP connections are unidirectional by nature. It further requires that these connections should be supported by both 1+1 and 1:1 protection architectures. When protecting a P2MP network using a 1+1 protection architecture, the basic protection mechanism is still relevant. The root LSR will bridge the user traffic (using a permanent bridge) to both the working and recovery transport entities. Each leaf LSR will select the traffic from one transport path according to its own local triggers. This may lead to a situation where, due to a failure condition on one branch of the network, that some leaf LSRs may select the working transport path, while other leaf LSRs may select traffic from the recovery transport path. When protecting a P2MP network using 1:1 protection architecture, there is a need for the root LSR to identify the existence of a failure condition on any of the branches of the network. Editor's note: This requires the use tools from the OAM toolset [9], and also a return path that can pass the indication back to the root LSR. This protection architecture, in the P2MP case, also requires that each leaf LSR selects the traffic from the incoming transport entities based local logic. When protection switching is triggered, the root LSR selects the recovery transport path to transfer the traffic and each leaf LSR continues to select the proper transmission. Endof Editor's note!! 4.4. Extension to 1:n protection This is for further study Editor's note: definition of 1:n protection should be that there is one recovery path that is given a different label relative to each working path that is being protected. When any one of the working paths indicates a failure, then the traffic is redirected to the recovery path, using the dedicated recovery label. When more than one working path reports a failure, then the path with the highest priority will have its traffic redirected to the recovery path and traffic from other paths will not be protected. It should be noted Weingarten et al. Expires September 9, 2009 [Page 8] Internet-Draft MPLS-TP Linear Protection March 2009 further that 1:n protection cannot be supported using a single phase protocol, since the coordination of which is the highest priority path and notification to other paths needs acknowledgement, i.e. at least a second phase. There is a suggestion to have a separate draft for the extension to 1:n protection, that would include a definition to the two-phased protocol. This draft should only prepare the groundwork of the protocol so as not to preclude the 1:n protection. This is still under discussion Endof Editor's note 4.5. Revertive and Non-revertive switching In revertive operation, the normal traffic signal is restored to the working transport path after the condition that triggered the switching has cleared. When a manual operator command (e.g. Forced Switch) has cleared, then the reversion happens immediately. When a failure or degradation of service has cleared, the reversion may be delayed until the expiry of a Wait-to-restore timer, used to neutralize the effect of intermittent defects. In non-revertive mode of operation, the normal traffic continues to use the recovery transport path, even after the condition that triggered has cleared. Eventually, the network may be reverted to use the working transport path, by using an explicit operator command (see section 6.3.5). The 1+1 protection architecture is often provisioned to operate as non-revertive, since the recovery transport path is fully dedicated in any case and continuing to select it on the sink avoids a second disturbance to the traffic. There may, however, be certain operator policies that dictate provisioning revertive operation for 1+1 protection. The 1:1 protection architecture is often provisioned to operate in revertive mode. This takes advantage of the (typically) more optimized working transport path, even at the cost of the additional disturbance to traffic from the additional switch. In principle, the configuration of revertive or non-revertive operation should be the same at both ends of the protection domain. 5. Protection switching trigger mechanisms The protection switching should be initiated in reaction to any of the following triggers: Weingarten et al. Expires September 9, 2009 [Page 9] Internet-Draft MPLS-TP Linear Protection March 2009 . Server layer indication - if any of the lower layers (e.g. the physical layer) raises an interrupt indicating that a failure has been detected. . OAM signalling - if the OAM continuity and connectivity verification tools detect that there is a loss of continuity or mis-connectivity or the performance monitoring indicates a degradation of the utility of the working path for the current transport path. In cases of signal degradation, switching to the recovery path SHOULD only be activated if the recovery path can guarantee better conditions than the degraded working path. . Control plane - if there is a control plane active in the network (either signalling or routing), it may send an indication of problems on the working path. Protection switching should be initiated as a result, until the problems are signalled to have cleared. . Operator command - the network operator may issue commands that trigger protection switching. The commands that are supported include - Forced Switch, Manual Switch, Clear, Lockout of Protection, (see definitions in [10]). 5.1. Hold-off timer In order to coordinate timing of protection switches at multiple layers, a hold-off timer may be required. Its purpose is to allow, for example, a server layer protection switch to have a chance to fix the problem before switching at a client layer. Each protection group should have a provisionable holdoff timer. The suggested range of the holdoff timer is 0 to 10 seconds in steps of 100 ms with an accuracy within 5 ms. The default duration for the holdoff timer is 0 seconds. When a failure condition is detected, this will not immediately activate protection switching if the provisioned hold-off timer value is non-zero. Rather, the hold-off timer will be started. When the hold-off timer expires, we check if a failure condition is still present. If there is still a failure condition, then the protection switching is activated, regardless if it is the same failure condition that caused the activation the hold-off timer. 5.2. Protection switching control logical architecture Protection switching processes the triggers described above together with the inputs received from the far-end LSR. These inputs cause Weingarten et al. Expires September 9, 2009 [Page 10] Internet-Draft MPLS-TP Linear Protection March 2009 the LSR to take certain actions, e.g. switching the Selector Bridge to select the working or recovery path, and to transmit different protocol messages. +-------------+ Operator Command Local PSC +-----------+ | External |-----------------+ +-----------------| PSC Status| | Interface | | | request +---| Module | +-------------+ | | | +-----------+ V V V Prot. Stat. ^ +----------+ Local OAM +---------------+Highest +------------+ | | OAM |----------->| Local Request |------->| PSC Mess. | | | Module | request | logic |local R.| Generator | | +----------+ +---------------+ +------------+ | | | | Highest local request| | | V V | +-------------+ +-----------------+ PSC Message | | Remote Req. | Remote PSC | global Request | | | Receiver |------------>| logic | | +-------------+ Request +-----------------+ | ^ | | | Highest global request| | | V | | +-----------------+ PSC status | Remote PSC message | PSC Process |-----------------+ | logic |--------> Action | | +-----------------+ Figure 3: Protection switching control logic Figure 3 describes the logical architecture of the protection switching control. The Local Request logic unit accepts the triggers from the OAM, external operator commands, and from the local control plane (when present) and determines the highest priority request. This high-priority request is passed to both the PSC Message generator, that will generate the appropriate protocol message to be sent to the far-end LSR, and the Global Request logic, that will cross-check this local request with the information received from the far-LSR. The Global Request logic then processes these two PSC requests that determines the highest priority request that is passed to the PSC Process logic. The PSC Process logic uses this input to determine what actions need to be taken, e.g. switching the Selector Bridge, and the current status of the protection domain. Weingarten et al. Expires September 9, 2009 [Page 11] Internet-Draft MPLS-TP Linear Protection March 2009 6. Protection switching coordination (PSC) protocol Bidirectional protection switching requires coordination between the two end-points in determining which of the two possible paths, the working or recovery path, is operational in any given situation. When protection switching is triggered as described in section 5, the end-points must inform each other of the switch-over from one path to the other in a coordinated fashion. There are different possibilities for the type of coordinating protocol. One possibility is a two-phased coordination in which the MEP that is initiating the protection switching sends a protocol message indicating the switch but the actual switch-over is performed only after receiving an 'Ack' from the far-end MEP. The other possibility is a single-phased coordination in which the initiating MEP switches over to the alternate path and informs the far-end of the switch, and the far-end must complete the switch-over. In the following sub-sections we describe the protocol messages that should be used between the two end-points of the protection domain. For the sake of simplicity of the protocol, this protocol is based on the single-phase approach described above. The protocol messages should be transmitted over the recovery path only. This allows the transmission of the messages without affecting the normal traffic in the most prevalent case, i.e. the idle state. In addition, limiting the transmission to a single path avoids possible conflicts and race conditions that could develop if the PSC messages were sent on both paths. 6.1. Protocol format The protocol messages SHALL be sent over the GACH as described in [8]. There is a single channel type for the set of PSC messages, each message will be identified by the first field of the ACH payload as described below. PSC messages SHOULD support addressing by use of the method described in [ACH-TLV]. The following figure shows the format for the full PSC message. Weingarten et al. Expires September 9, 2009 [Page 12] Internet-Draft MPLS-TP Linear Protection March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP PSC Channel Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Addressing TLV + : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ PSC Controlmessage ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Format of PSC packet with a GACH header Where: . MPLS-TP PSC Channel Code is the GACH channel number assigned to the PSC = TBD . The ACH TLV Header is described in [ACHTLV] . The use of the Addressing TLV are described in section 6.2 . The following figure shows the format of the PSC Control message that is the payload for the PSC packet. Editor's note: There is a suggestion that this format should be aligned with the format used by G.8031/G.8131/Y.1731 in ITU. The argument being that this would make it easier to pass review from ITU and allow easier transfer of technology. The counter-argument is that the ITU format is based upon an attempt to find a common format for different functionality and therefore involves different fields that are not necessary for the protection switching. Defining a new dedicated format would make for a simpler and more intuitive protocol. This is still under discussion Endof Editor's note. Weingarten et al. Expires September 9, 2009 [Page 13] Internet-Draft MPLS-TP Linear Protection March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |Request|F|Typ| Path | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. Format of the PSC Control packet Where: . Ver: is the version of the protocol, for this version the value SHOULD be 0. . Request: this field indicates the specific PSC request that is being transmitted, the details are described in section 6.1.1 . Path: used to indicate the currently active path, possible values are described in section 6.1.3 . F: used to indicate the path that is reporting a failure condition, the possible values are described in section 6.1.2 . Typ: indicates the type of protection scheme currently supported, more details are given in section 6.1.4 6.1.1. PSC Requests The Protection Switching Coordination (PSC) protocol SHALL support the following request types, in order of priority from highest to lowest: . (1111) Clear . (1110) Lockout protection . (1101) Forced switch . (0110) Signal fault . (0101) Signal degrade . (0100) Manual switch . (0011) Wait to restore . (0010) Do not revert (DNR) . (0000) No request Weingarten et al. Expires September 9, 2009 [Page 14] Internet-Draft MPLS-TP Linear Protection March 2009 See section 6.3 for a description of the operation of the different requests 6.1.1.1. Interaction between requests The following rules SHOULD be observed for interaction between different requests: . If the protection domain is currently in a protecting state, i.e. normal traffic is being transmitted over the recovery path as a result of a trigger, then the LSRs SHOULD NOT accept a Manual Switch request. . If the protection domain is currently in a protecting state, i.e. normal traffic is being transmitted over the recovery path as a result of a trigger, and a Forced Switch is requested then the normal traffic SHALL continue to be transmitted on the recovery path even if the original protection trigger is cleared. . If a Signal Degrade request is received, then protection switching will be activated only if the recovery path can guarantee a better signal than the working path. Editor's note: Do we need to define the method of comparison or is this out of scope? Endof Editor's note . If the Clear request is issued in the absence of a Manual Switch, Forced Switch, Freeze, or Lockout protection, then it SHALL be ignored. In the presence of any of these commands, the Clear request SHALL clear the state affected by the operator command. 6.1.2. Path fault identifier The F-bit of the PSC control SHALL be used only in a Signal fault (0101) or Signal degrade (0100) control packet. Its value indicates on which path the signal anomaly was detected. The following are the possible values: . 0: indicates the Recovery path . 1: indicates the Working path 6.1.3. Active path indicator The Path field of the PSC control SHALL be used to indicate which path the source MEP is currently using for data transmission. The Weingarten et al. Expires September 9, 2009 [Page 15] Internet-Draft MPLS-TP Linear Protection March 2009 MEP should compare the value of this bit with the path that is locally selected for data transmission to verify that there is no inconsistency between the two end-points of the protected domain. If an inconsistency is detected then an alarm should be raised. The following are the possible values: . 0: indicates the Recovery path . 1: indicates the Working path . 2-255: for future extensions . Possibility of extension for 1:n protection would change the interpretation of this field, where 0 indicates that all normal traffic is being carried on the working paths, a value other than 0 indicates that the recovery path is being used to transmit normal traffic for the path indicated, e.g. if we define this field to be 8 bits then a value of 102 would indicate that recovery path is currently carrying traffic that was intended for the failed path 102. 6.1.4. Current protection type The Typ field indicates the currently configured protection architecture type, this should be validated to be consistent for both ends of the protected domain. If an inconsistency is detected then an alarm should be raised. The following are the possible values: . 11: 1+1 bidirectional switching . 10: 1:1 bidirectional switching . 01: 1+1 unidirectional switching . 00: 1:1 unidirectional switching 6.2. Addressing of PSC requests To be incorporated in a future revision of this document 6.3. Principles of operation In all of the following sub-sections, assume a protected domain between LSR-A and LSR-Z, using paths W (working) and R (recovery). Weingarten et al. Expires September 9, 2009 [Page 16] Internet-Draft MPLS-TP Linear Protection March 2009 6.3.1. Normal state When the protected domain has no special condition in effect, the ingress LSR SHOULD forward the user data along the working path, and in the case of 1+1 protection the Permanent Bridge will bridge the data to the recovery path as well. The receiving LSR SHOULD read the data from the working path. The ingress LSR MAY transmit a No Request PSC packet with the P-bit set to 0 for the recovery path. 6.3.2. Failure or Degraded condition If one of the LSRs (for example, LSR-A) detects a failure condition or a serious degradation condition on the working path that warrants invoking protection switching, then it SHOULD take the following actions: . Switch all traffic for LSR-Z to the recovery path only. . Transmit a PCS control packet, using GACH, with the appropriate Request code (either Signal fault or Signal degrade), the F-bit set to 0, to indicate that the fault/degrade was detected on the working path, and the P-bit set to 1, indicating that traffic is now being forwarded on the recovery path. This transmission should be repeated every xx ms for the duration of the failure/degrade condition. . Verify that LSR-Z replies with a PCS control packet indicating that it has switched to the recovery path. If this is not received after xxx then send an alarm to the management system. When the far-end LSR (in this example LSR-Z) receives the PCS packet informing it that other LSR (LSR-A) has switched, it SHOULD perform the following actions: . Check priority of the request . Switch all traffic addressed to LSR-A to the recovery path only. . Begin transmission of a PCS control packet, using GACH, with the appropriate Request code (either Signal fault or Signal degrade), the F-bit set to 0, to indicate that the fault/degrade was detected on the working path, and the P-bit set to 1, indicating that traffic is now being forwarded on the Weingarten et al. Expires September 9, 2009 [Page 17] Internet-Draft MPLS-TP Linear Protection March 2009 recovery path. This transmission should be repeated every xx ms for the duration of the failure/degrade condition. 6.3.3. Lockout of protection If one of the LSRs (for example, LSR-A) receives a management command indicating that the protection is disabled, then it SHOULD indicate this to the far-end LSR (for example, LSR-Z) that it is not possible to use the recovery path. The following actions MUST be taken: . Transmit a PCS control packet, using GACH, with the Request code set to Lockout of protection (1010), the F-bit set to 1, and the P-bit set to 0. . All normal traffic packets should be transmitted on the working path only. . Verify that the far-end LSR (for example LSR-Z) is forwarding the data packets on the working path. Raise alarm in case of mismatch. When the far-end LSR (in this example LSR-Z) receives the PCS packet informing it that other LSR (LSR-A) has switched, it SHOULD perform the following actions: . Check priority of request . Switch all normal traffic addressed to LSR-A to the working path only. . Begin transmission of a PCS control packet, using GACH, with the appropriate Request code (Lockout of protection), the F-bit set to 1, and the P-bit set to 0, indicating that traffic is now being forwarded on the working path only. This transmission should be repeated every xx ms for the duration of the lockout condition. 6.3.4. Operator controlled switching If the management system indicated to one of the LSRs (for example LSR-A) that a switch is necessary, e.g. either a Forced Switch or a Manual Switch, then the LSR SHOULD switch the traffic to the recovery path and perform the following actions: . Switch all data traffic to the recovery path only. Weingarten et al. Expires September 9, 2009 [Page 18] Internet-Draft MPLS-TP Linear Protection March 2009 . Transmit a PCS control packet, using GACH, with the appropriate Request code (either Manual switch or Forced switch), the F-bit set to 0, to indicate that the fault/degrade was detected on the working path, and the P-bit set to 1, indicating that traffic is now being forwarded on the recovery path. This transmission should be repeated every xx ms for the duration of the switch condition. . Verify that LSR-Z replies with a PCS control packet indicating that it has switched to the recovery path. If this is not received after xxx then send an alarm to the management system. When the far-end LSR (in this example LSR-Z) receives the PCS packet informing it that other LSR (LSR-A) has switched, it SHOULD perform the following actions: . Check priority of the request . Switch all normal traffic addressed to LSR-A to the recovery path only. . Begin transmission of a PCS control packet, using GACH, with the appropriate Request code (either Manual switch of Forced switch), the F-bit set to 0, to indicate that the fault/degrade was detected on the working path, and the P-bit set to 1, indicating that traffic is now being forwarded on the recovery path. This transmission should be repeated every xx ms for the duration of the switch condition. 6.3.5. Recovery from switching When the condition that triggered the protection switching clears, e.g. the cause of the failure condition has been corrected, the operator clears a Manual Switch, then the protection domain SHOULD follow the following procedures: . If the network is configured for non-revertive behaviour, then the two LSRs SHOULD transmit DNR (Request code 0010) messages. When the operator clears the non-revertive condition, the two LSRs SHOULD return to use of the working transport path and transmit No request (Request code 0000) messages. . If the network is recovering from an operator switching command (in revertive mode), then both LSRs SHOULD return to using the working transport path and transmit No request (Request code 0000) messages. Weingarten et al. Expires September 9, 2009 [Page 19] Internet-Draft MPLS-TP Linear Protection March 2009 . If the network is recovering from a failure or degraded condition (in revertive mode), then the LSR that detects this recovery SHALL activate a local Wait-to-restore (WTR) timer (see section 6.3.5.1) to verify that there is not an intermittent failure. After the WTR expires, the LSR SHOULD return to using the working transport path and transmit No request (Request code 0000) messages. 6.3.5.1. Wait-to-restore timer In revertive mode, in order to prevent frequent activation of protection switching due to an intermittent defect, the working transport path must become stable and fault-free before reverting to the normal condition. In order to verify that this is the case a fixed period of time must elapse before the normal traffic uses the working transport path. This period, called the WTR period, should be configurable by the operator in 1-minute intervals within the range 1-12 minutes. The default value is 5 minutes. During this period, if a failure condition is detected on the working transport path, then the WTR timer is stopped and the normal traffic SHALL continue to be transported over the recovery transport path. If the WTR timer expires without being pre-empted by a failure, then the traffic SHOULD be returned to use the working transport path (as above). 7. Security Considerations To be incorporated in a future revision of this document 8. IANA Considerations To be incorporated in a future revision of this document 9. Acknowledgments The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the T-MPLS Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile. This document was prepared using 2-Word-v2.0.template.dot. Weingarten et al. Expires September 9, 2009 [Page 20] Internet-Draft MPLS-TP Linear Protection March 2009 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., Ueno, S., "MPLS TP Requirements", draft-jenkins-mpls-tp- requirements-04, Feb 2009 10.2. Informative References [3] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 [4] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, January 2001 [5] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005 [6] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007 [7] Bocci, M., et al., " A Framework for MPLS in Transport Networks", draft-blb-mpls-tp-framework-00 (work in progress), July 2008 [8] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., " MPLS Generic Associated Channel ", draft-bocci-mpls- tp-gach-gal-00, October 2008 [9] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-vigoureux-mpls-tp-oam- requirements-00, July 2008 [10] Mannie, E., Papadimitriou, D., "Recovery Terminology for Generalized Multi-Protocol Label Switching", RFC 4427, March 2006 [11] Sprecher, N., Farrel, A., Kompella, V., "Multi-protocol Label Switching Transport Profile Survivability Framework", draft-sprecher-mpls-tp-survive-fwk-01", Feb 2009 Weingarten et al. Expires September 9, 2009 [Page 21] Internet-Draft MPLS-TP Linear Protection March 2009 Authors' Addresses Stewart Bryant Cisco Systems Email: stbryant@cisco.com Nurit Sprecher Nokia Siemens Networks Email: nurit.sprecher@nsn.com Yaacov Weingarten Nokia Siemens Networks Email: yaacov.weingarten@nsn.com Annamaria Fulignoli Ericsson Email: annamaria.fulignoli@ericsson.com Huub van Helvoort Huawei Email: hhelvoort@huawei.com Contributing Authors' Addresses John E. Drake Boeing Corporation Email: John.E.Drake2@boeing.com Hao Long Huawei Email: lonho@huawei.com Weingarten et al. Expires September 9, 2009 [Page 22]