draft-ietf-mpls-tp-1ton-protection-01.txt   draft-ietf-mpls-tp-1ton-protection-02.txt 
Network Working Group E. Osborne Network Working Group E. Osborne
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track F. Zhang Intended status: Standards Track F. Zhang
Expires: August 8, 2013 ZTE Expires: February 7, 2014 ZTE
Y. Weingarten Y. Weingarten
February 4, 2013 August 6, 2013
MPLS-TP 1toN Protection MPLS-TP 1toN Protection
draft-ietf-mpls-tp-1ton-protection-01.txt draft-ietf-mpls-tp-1ton-protection-02.txt
Abstract Abstract
As part of the Transport Profile for Multiprotocol Label Switching There is a requirement for Multiprotocol Label Switching Transport
(MPLS-TP) there is a requirement to support 1:n linear protection for Profile(MPLS-TP) to support 1:n linear protection for transport
transport paths. This requirement is further elaborated in RFC6372 paths. This requirement is further elaborated in RFC6372
[SurvivFwk]. The basic protocol for linear protection, specified in [SurvivFwk]. The basic protocol for linear protection, specified in
RFC6378 [LinProt], is limited to 1+1 and 1:1 protection. This RFC6378 [LinProt], is limited to 1+1 and 1:1 protection. This
document extends that protocol to address the additional document extends that protocol to address the additional
functionality necessary to support scenarios where a single functionality necessary to support scenarios where a single
protection path is preconfigured to provide protection of multiple protection path is preconfigured to provide protection of multiple
transport paths between two joint endpoints. transport paths between two joint endpoints.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 7, line 17 skipping to change at page 7, line 17
In non-locking protection operation mode, LER-A switches data traffic In non-locking protection operation mode, LER-A switches data traffic
onto P immediately upon failure detection. This minimizes traffic onto P immediately upon failure detection. This minimizes traffic
loss, but at the cost of temporary asymmetry of packet flow. At a loss, but at the cost of temporary asymmetry of packet flow. At a
high level, it works like this: high level, it works like this:
o LER-A detects the failure of W1 and stops sending traffic on W1. 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 o LER-A immediately begins to transport W1's data traffic over the
protection path P. 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. 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 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 traffic to P, and transmits a PSC message to LER-A indicating that
W1 is now protected in P. W1 is now protected in P.
o LER-A receives the PSC message from LER-Z and needs to take no o LER-A receives the PSC message from LER-Z and needs to take no
action, as the protection switch had already been completed. action, as the protection switch had already been completed.
In the non-locking case, the packet loss between the endpoints is In the non-locking case, the packet loss between the endpoints is
skipping to change at page 9, line 35 skipping to change at page 9, line 35
2.2. Definitions and Terminology 2.2. Definitions and Terminology
The terminology used in this document is based on the terminology The terminology used in this document is based on the terminology
defined in [RFC4427] and further adapted for MPLS-TP in [SurvivFwk]. 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, 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. whether it is a LSR, LER, T-PE, or S-PE.
3. Use cases and scenarios 3. Use cases and scenarios
This section presents some use-cases and scenarios that should 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 3.1. Non-locking use case: Per-node label space
Non-locking protection can be used when the payload that is received Non-locking protection can be used when the payload that is received
from the protection path is unambiguous and can be properly forwarded from the protection path is unambiguous and can be properly forwarded
without the need to explicitly establish selector and bridge without the need to explicitly establish selector and bridge
configuration at the time of failure. One example where this applies configuration at the time of failure. One example where this applies
is when the endpoints of the protection domain are using per-platform is when the endpoints of the protection domain are using per-platform
label space [RFC3031]. label space [RFC3031].
skipping to change at page 27, line 25 skipping to change at page 27, line 25
protection path is available to switch the traffic from working protection path is available to switch the traffic from working
path W2. path W2.
4.3.4. Wait for Acknowledge (WFA) timer 4.3.4. Wait for Acknowledge (WFA) timer
The protection system MUST include a timer called the Wait for The protection system MUST include a timer called the Wait for
Acknowledge (WFA) timer that SHALL be started when the LER enters WFA Acknowledge (WFA) timer that SHALL be started when the LER enters WFA
state and reset when the Acknowledge message is received. The length state and reset when the Acknowledge message is received. The length
of the WFA timer SHOULD be configured to allow protection switching of the WFA timer SHOULD be configured to allow protection switching
within the normal time constraints. The WFA timer will expire only 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 WFA Expires local input should have a priority just below that of the
WTRExpires signal. WTRExpires signal.
4.3.5. Additional PSC State 4.3.5. Additional PSC State
As described above and demonstrated in the scenarios in Section 3.3, As described above and demonstrated in the scenarios in Section 3.3,
there is a need, in some scenarios, for the endpoint that is there is a need, in some scenarios, for the endpoint that is
reporting a trigger for protection-switching to delay the actual reporting a trigger for protection-switching to delay the actual
switchover until an acknowledge is received from the far end LER. In switch-over until an acknowledge is received from the far end LER.
order to facilitate this wait period it is necessary to define a new In order to facilitate this wait period it is necessary to define a
PSC State - Wait for Acknowledge (WFA) state. WFA is used in both new PSC State - Wait for Acknowledge (WFA) state. WFA is used in
the Locking and Non-Locking cases. It is more essential to the both the Locking and Non-Locking cases. It is more essential to the
Locking mode of operation, as agreement is the mechanism to establish Locking mode of operation, as agreement is the mechanism to establish
and release the lock on the protection LSP. However, it is necessary and release the lock on the protection LSP. However, it is necessary
for the Non-Locking mode as a persistent disagreement on the contents for the Non-Locking mode as a persistent disagreement on the contents
of the protection LSP indicates an error in the network devices and of the protection LSP indicates an error in the network devices and
WFA is the method used to detect this error. WFA is the method used to detect this error.
In the locking mode, WFA comes into play when a failed LSP preempts In the locking mode, WFA comes into play when a failed LSP preempts
another LSP. This is highlighted in the scenarios presented in another LSP. This is highlighted in the scenarios presented in
Figure 7 & Figure 9. Figure 7 & Figure 9.
skipping to change at page 29, line 9 skipping to change at page 29, line 9
protected working path, i.e. the highest priority working path protected working path, i.e. the highest priority working path
indicating an SF condition]. If the LER is in WFA state due to 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 any other trigger, then begin transmitting a SF(x, 0) PSC message
[where x indicates the index of the working path that is [where x indicates the index of the working path that is
generating the SF condition]. generating the SF condition].
o A local ClearSF indication where the working path is the same as 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 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) 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 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. protection path then the indication SHALL be ignored.
o A local MS operator command SHALL cause the LER to remain in WFA 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, 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 then the node continues to transmit MS(x, 0) messages [where x
indicates the index of the protected working path, i.e. the 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 the LER is in WFA state due to any other trigger, ignore the MS
command and continue transmitting the current message. command and continue transmitting the current message.
o If the WFA timer expires, i.e. the LER did not receive the 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 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 LER SHALL go to Unavailable state, i.e. it assumes that there is a
problem on the protection path (where all PSC traffic is problem on the protection path (where all PSC traffic is
transmitted) and send an error notification to the management transmitted) and send an error notification to the management
system. The LER SHALL continue transmitting the current PSC system. The LER SHALL continue transmitting the current PSC
message with Path field set to 0. message with Path field set to 0.
skipping to change at page 30, line 19 skipping to change at page 30, line 19
FS message and remain in WFA state. If the remote FS message FS message and remain in WFA state. If the remote FS message
indicates an index of higher priority or the LER is in WFA state indicates an index of higher priority or the LER is in WFA state
as a result of a SF or MS trigger, then the LER SHALL perform the as a result of a SF or MS trigger, then the LER SHALL perform the
protection switch for the protected working path indicated by the protection switch for the protected working path indicated by the
remote FS message, and SHALL go to Protecting administrative state remote FS message, and SHALL go to Protecting administrative state
and transmit the appropriate message for the local trigger with and transmit the appropriate message for the local trigger with
the Path field set to the index of the remote message and the the Path field set to the index of the remote message and the
Acknowledge flag set to 1. Acknowledge flag set to 1.
o A remote SF message indicating an error on the protection path o A remote SF message indicating an error on the protection path
SHALL cause the LER to go into Unavailable stateand transmit the SHALL cause the LER to go into Unavailable state and transmit the
appropriate message for the trigger that caused to WFA state. appropriate message for the trigger that caused to WFA state.
o A remote SF message indicating an error on the same working path o A remote SF message indicating an error on the same working path
as the local SF condition that triggered the WFA state SHALL be as the local SF condition that triggered the WFA state SHALL be
considered an Acknowledge message (even if the Acknowledge flag is considered an Acknowledge message (even if the Acknowledge flag is
not set). The LER SHALL perform the protection switch, go to not set). The LER SHALL perform the protection switch, go to
Protecting failure state and transmit the SF(x, x) message [where Protecting failure state and transmit the SF(x, x) message [where
x is the index of the protected working path]. If the remote SF x is the index of the protected working path]. If the remote SF
message indicates a different index than the one indicated in the message indicates a different index than the one indicated in the
local SF, then if the local command indicates a higher priority local SF, then if the local command indicates a higher priority
skipping to change at page 36, line 37 skipping to change at page 36, line 37
Email: eosborne@cisco.com Email: eosborne@cisco.com
Fei Zhang Fei Zhang
ZTE ZTE
China China
Email: zhang.fei3@zte.com.cn Email: zhang.fei3@zte.com.cn
Yaacov Weingarten Yaacov Weingarten
34 Hagefen St 34 Hagefen St
Karnei Shomron, 44853 Karnei Shomron, 4485500
Israel Israel
Email: wyaacov@gmail.com Email: wyaacov@gmail.com
 End of changes. 13 change blocks. 
18 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/