--- 1/draft-ietf-mpls-tp-1ton-protection-01.txt 2013-08-06 13:14:08.909578853 -0700 +++ 2/draft-ietf-mpls-tp-1ton-protection-02.txt 2013-08-06 13:14:08.981580715 -0700 @@ -1,26 +1,26 @@ Network Working Group E. Osborne Internet-Draft Cisco Intended status: Standards Track F. Zhang -Expires: August 8, 2013 ZTE +Expires: February 7, 2014 ZTE Y. Weingarten - February 4, 2013 + August 6, 2013 MPLS-TP 1toN Protection - draft-ietf-mpls-tp-1ton-protection-01.txt + draft-ietf-mpls-tp-1ton-protection-02.txt Abstract - As part of the Transport Profile for Multiprotocol Label Switching - (MPLS-TP) there is a requirement to support 1:n linear protection for - transport paths. This requirement is further elaborated in RFC6372 + There is a requirement for Multiprotocol Label Switching Transport + Profile(MPLS-TP) to support 1:n linear protection for transport + paths. This requirement is further elaborated in RFC6372 [SurvivFwk]. The basic protocol for linear protection, specified in RFC6378 [LinProt], is limited to 1+1 and 1:1 protection. This document extends that protocol to address the additional functionality necessary to support scenarios where a single protection path is preconfigured to provide protection of multiple transport paths between two joint endpoints. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport @@ -36,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on August 8, 2013. + This Internet-Draft will expire on February 7, 2014. Copyright Notice Copyright (c) 2013 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 (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 @@ -255,21 +255,21 @@ In non-locking protection operation mode, LER-A switches data traffic onto P immediately upon failure detection. This minimizes traffic loss, but at the cost of temporary asymmetry of packet flow. At a high level, it works like this: o LER-A detects the failure of W1 and stops sending traffic on W1. o LER-A immediately begins to transport W1's data traffic over the protection path P. - o Simultaneously LER-A transmitts a PSC message to LER-Z indicating + o Simultaneously LER-A transmits a PSC message to LER-Z indicating that W1 has failed and is currently being protected in P. o LER-Z receives the PSC message from LER-A, switches all W1 data traffic to P, and transmits a PSC message to LER-A indicating that W1 is now protected in P. o LER-A receives the PSC message from LER-Z and needs to take no action, as the protection switch had already been completed. In the non-locking case, the packet loss between the endpoints is @@ -361,21 +361,21 @@ 2.2. Definitions and Terminology The terminology used in this document is based on the terminology defined in [RFC4427] and further adapted for MPLS-TP in [SurvivFwk]. In addition, we use the term LER to refer to a MPLS Network Element, whether it is a LSR, LER, T-PE, or S-PE. 3. Use cases and scenarios This section presents some use-cases and scenarios that should - illucidate the use of PSC for 1:n protection. + elucidate the use of PSC for 1:n protection. 3.1. Non-locking use case: Per-node label space Non-locking protection can be used when the payload that is received from the protection path is unambiguous and can be properly forwarded without the need to explicitly establish selector and bridge configuration at the time of failure. One example where this applies is when the endpoints of the protection domain are using per-platform label space [RFC3031]. @@ -1164,33 +1164,33 @@ protection path is available to switch the traffic from working path W2. 4.3.4. Wait for Acknowledge (WFA) timer The protection system MUST include a timer called the Wait for Acknowledge (WFA) timer that SHALL be started when the LER enters WFA state and reset when the Acknowledge message is received. The length of the WFA timer SHOULD be configured to allow protection switching within the normal time constraints. The WFA timer will expire only - if no Acknowledge message was recieved by the LER in WFA state. The + if no Acknowledge message was received by the LER in WFA state. The WFA Expires local input should have a priority just below that of the WTRExpires signal. 4.3.5. Additional PSC State As described above and demonstrated in the scenarios in Section 3.3, there is a need, in some scenarios, for the endpoint that is reporting a trigger for protection-switching to delay the actual - switchover until an acknowledge is received from the far end LER. In - order to facilitate this wait period it is necessary to define a new - PSC State - Wait for Acknowledge (WFA) state. WFA is used in both - the Locking and Non-Locking cases. It is more essential to the + switch-over until an acknowledge is received from the far end LER. + In order to facilitate this wait period it is necessary to define a + new PSC State - Wait for Acknowledge (WFA) state. WFA is used in + both the Locking and Non-Locking cases. It is more essential to the Locking mode of operation, as agreement is the mechanism to establish and release the lock on the protection LSP. However, it is necessary for the Non-Locking mode as a persistent disagreement on the contents of the protection LSP indicates an error in the network devices and WFA is the method used to detect this error. In the locking mode, WFA comes into play when a failed LSP preempts another LSP. This is highlighted in the scenarios presented in Figure 7 & Figure 9. @@ -1242,28 +1242,28 @@ protected working path, i.e. the highest priority working path indicating an SF condition]. If the LER is in WFA state due to any other trigger, then begin transmitting a SF(x, 0) PSC message [where x indicates the index of the working path that is generating the SF condition]. o A local ClearSF indication where the working path is the same as the path that triggered the LER into WFA state SHALL cause the LER to go into WTR state (note: 1:N protection is always revertive) and to transmit the WTR(0, 0) message. If the ClearSF indicates a - different index from the protected working path or incates the + different index from the protected working path or indicates the protection path then the indication SHALL be ignored. o A local MS operator command SHALL cause the LER to remain in WFA state. If the LER is in WFA state due an existing MS trigger, then the node continues to transmit MS(x, 0) messages [where x indicates the index of the protected working path, i.e. the - highest prirority working path indicating the MS condition]. If + highest priority working path indicating the MS condition]. If the LER is in WFA state due to any other trigger, ignore the MS command and continue transmitting the current message. o If the WFA timer expires, i.e. the LER did not receive the Acknowledge message from the far end in a timely manner, then the LER SHALL go to Unavailable state, i.e. it assumes that there is a problem on the protection path (where all PSC traffic is transmitted) and send an error notification to the management system. The LER SHALL continue transmitting the current PSC message with Path field set to 0. @@ -1583,14 +1583,14 @@ Email: eosborne@cisco.com Fei Zhang ZTE China Email: zhang.fei3@zte.com.cn Yaacov Weingarten 34 Hagefen St - Karnei Shomron, 44853 + Karnei Shomron, 4485500 Israel Email: wyaacov@gmail.com