| TOC |
|
The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is being specified jointly by IETF and ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document.
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 Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 July 31, 2011.
Copyright (c) 2011 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 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
1.
Introduction
1.1.
Protection architectures
1.2.
Scope of the document
1.3.
Contributing authors
2.
Conventions used in this document
2.1.
Acronyms
2.2.
Definitions and Terminology
3.
Protection switching control logic
3.1.
Protection switching control logical architecture
3.1.1.
Local Request Logic
3.1.2.
Remote Requests
3.1.3.
PSC Control Logic
3.1.4.
PSC Message Generator
3.1.5.
Wait-to-Restore (WTR) timer
3.1.6.
PSC Control States
4.
Protection state coordination (PSC) protocol
4.1.
Transmission and acceptance of PSC control packets
4.2.
Protocol format
4.2.1.
PSC Ver field
4.2.2.
PSC Request field
4.2.3.
Protection Type (PT)
4.2.4.
Revertive (R) field
4.2.5.
Fault path (FPath) field
4.2.6.
Data path (Path) field
4.3.
Principles of Operation
4.3.1.
Basic operation
4.3.2.
Priority of inputs
4.3.3.
Operation of PSC States
5.
IANA Considerations
6.
Security Considerations
7.
Acknowledgements
Appendix A.
PSC state machine tables
8.
References
8.1.
Normative References
8.2.
Informative References
§
Authors' Addresses
| TOC |
The MPLS Transport Profile (MPLS-TP) [TPFwk] (Bocci, M., Bryant, S., and L. Levrau, “A Framework for MPLS in Transport Networks,” July 2009.) is a framework for the construction and operation of packet-switched transport networks based on the architectures for MPLS ([RFC3031] (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” Jan 2001.) and [RFC3032] (Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding,” Jan 2001.)) and for Pseudowires (PWs) ([RFC3985] (Bryant, S. and P. Pate, “Pseudowire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.) and [RFC5659] (Bocci, M. and S. Bryant, “An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge,” October 2009.)) and the requirements of [RFC5654] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.).
Network survivability is the ability of a network to recover traffic delivery following failure, or degradation of network resources. The MPLS-TP Survivability Framework [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.) is a framework for survivability in MPLS-TP networks, and describes recovery elements, types, methods, and topological considerations, focusing on mechanisms for recovering MPLS-TP Label Switched Paths (LSPs).
Linear protection in mesh networks – networks with arbitrary interconnectivity between nodes – is described in Section 4.7 of [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.). Linear protection provides rapid and simple protection switching. In a mesh network, linear protection provides a very suitable protection mechanism because it can operate between any pair of points within the network. It can protect against a defect in an intermediate node, a span, a transport path segment, or an end-to-end transport path.
| TOC |
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 or set of working paths. 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.
As specified in the Survivability Framework document [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.), protection switching is applied to a protection domain. For the purposes of this document, we define the protection domain of a P2P LSP as consisting of two Label Edge Routers (LER) and the transport paths that connect them. For a P2MP LSP the protection domain includes the root (or source) LER, the destination (or sink) LERs, and the transport paths that connect them.
In 1+1 unidirectional architecture as presented in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.), a recovery transport path is dedicated to the working transport path. Normal traffic is bridged (as defined in [RFC4427] (Mannie, E. and D. Papadimitriou, “Recovery Terminology for Generalized Multi-Protocol Label Switching,” Mar 2006.))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 State Coordination (PSC) protocol. This protocol is used to help coordinate between 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 of a single service and the traffic is only transmitted either on 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 a PSC protocol.
The 1:n protection architecture extends the 1:1 architecture above by sharing the recovery path among n services. Again, the recovery path is fully allocated and disjoint from any of the n working transport paths that it is being used to protect. The normal data traffic for each service is transmitted either on the normal working path for that service or, in cases that trigger protection switching (as defined in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.)), may be sent on the recovery path. The switching action is similar to the 1:1 case where a selector bridge is used at the source. It should be noted that in cases where multiple working path services have triggered protection switching that some services, dependent upon their Service Level Agreement (SLA), may not be transmitted as a result of limited resources on the recovery path. In this architecture there may be a need for coordination of the protection switching, and also for resource allocation negotiation. The procedures for this are for further study and may be addressed in future documents.
| TOC |
As was pointed out in the Survivability Framework [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.) and highlighted above, there is a need for coordination between the end points of the protection domain when employing bidirectional protection schemes. This is especially true when there is a need to maintain traffic over a co-routed bidirectional LSP.
The scope of this draft is to present a protocol for the Protection State Coordination of Linear Protection. The protocol addresses the protection of LSPs in an MPLS-TP network as required by [RFC5654] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.) (in particular requirements 63-67 and 74-79) and described in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.). The basic protocol is designed for use in conjunction with the 1:1 protection architecture (for both unidirectional and bidirectional protection) and for 1+1 protection of a bidirectional path (for both unidirectional and bidirectional protection switching). Applicability of the protocol for 1:n protection schemes may be documented in a future document. The applicability of this protocol to additional MPLS-TP constructs and topologies may be documented in future documents.
While the unidirectional 1+1 protection architecture does not require the use of a coordination protocol, the protocol may be used by the ingress node of the path to notify the far-side end point that a switching condition has occurred and verify the consistency of the end point configuration. This use may be especially useful for point-to-multipoint transport paths, that are unidirectional by definition of [RFC5654] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.).
| TOC |
Hao Long (Huawei), Dan Frost (Cisco), Davide Chiara (Ericsson), Francesco Fondelli (Ericsson),
| TOC |
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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
This draft uses the following acronyms:
| DNR | Do not revert |
| FS | Forced Switch |
| G-ACh | Generic Associated Channel Header |
| LER | Label Switching Router |
| MPLS-TP | Transport Profile for MPLS |
| MS | Manual Switch |
| P2P | Point-to-point |
| P2MP | Point-to-multipoint |
| PSC | Protection State Coordination Protocol |
| PST | Path Segment Tunnel |
| SD | Signal Degrade |
| SF | Signal Fail |
| SLA | Service Level Agreement |
| WTR | Wait-to-Restore |
| TOC |
The terminology used in this document is based on the terminology defined in [RFC4427] (Mannie, E. and D. Papadimitriou, “Recovery Terminology for Generalized Multi-Protocol Label Switching,” Mar 2006.) and further adapted for MPLS-TP in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.). In addition, we use the term LER to refer to a MPLS-TP Network Element, whether it is a LSR, LER, T-PE, or S-PE.
| TOC |
| TOC |
Protection switching processes the local triggers described in requirements 74-79 of [RFC5654] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.) together with inputs received from the far-end LER. Based on these inputs the LER will take certain protection switching actions, e.g. switching the Selector Bridge to select the working or protection path, and transmit different protocol messages.
The following figure shows the logical decomposition of the PSC Control Logic into different logical processing units. These processing units are presented in subsequent subsections of this document.
Server Indication Control Plane Indication
-----------------+ +-------------
Operator Command | | OAM Indication
----------------+ | | +---------------
| | | |
V V V V
+---------------+ +-------+
| Local Request |<--------| WTR |
| logic |WTR Exps | Timer |
+---------------+ +-------+
| ^
Highest local|request |
V | Start/Stop
+-----------------+ |
Remote PSC | PSC Control |------------+
------------>| logic |
Request +-----------------+
|
| Action +------------+
+---------------->| Message |
| Generator |
+------------+
|
Output PSC | Message
V
| Figure 1: Protection switching control logic |
Figure 1 (Protection switching control logic) describes the logical architecture of the protection switching control. The Local Request logic unit accepts the triggers from the OAM, external operator commands, from the local control plane (when present), and the Wait-to-Restore timer. By considering all of these local request sources it determines the highest priority local request. This high-priority request is passed to the PSC Control logic, that will cross-check this local request with the information received from the far-end LER. The PSC Control logic uses this input to determine what actions need to be taken, e.g. local actions at the LER, or what message should be sent to the far-end LER, and the current status of the protection domain.
| TOC |
The protection switching logic processes input triggers from five sources:
The Local request logic SHALL process these different input sources and, based on the priorities between them (see section 4.3.2), SHALL produce a current local request. If more than one local input source generates an indicator, then the Local request logic SHALL select the higher priority indicator and block any lower priority indicator. As a result, there is a single current local request that is passed to the PSC Control logic. The different local requests that may be output from the Local Request Logic are:
If none of the input sources have generated any input then the Local request logic SHALL generate a No Request (NR) request as the current local request .
| TOC |
In addition to the local requests, generated as a result of the local triggers, indicated in the previous subsection, the PSC Control Logic SHALL accept PSC messages from the far-end LER of the transport path. These remote messages indicate the status of the transport path from the viewpoint of the far-end LER, and may indicate if the local MEP SHOULD initiate a protection switch operation.
The following remote requests may be received by the PSC process:
| TOC |
The PSC Control Logic SHALL accept as input –
- a.
- the current local request output from the Local Request Logic (see section 3.1.1),
- b.
- the remote request message from the remote end point of the transport path, and
- c.
- the current state of the PSC Control Logic (maintained internally by the PSC Control Logic).
Based on the priorities between the different inputs, the PSC Control Logic SHALL determine the new state of the PSC Control Logic and what actions need to be taken.
The new state information SHALL be retained by the PSC Control Logic, while the requested action SHALL be sent to the PSC Message Generator (see subsection 3.1.4) to generate and transmit the proper PSC message to be transmitted to the remote end point of the protection domain.
| TOC |
Based on the action output from the Control Logic this unit formats the PSC protocol message that is transmitted to the remote end point of the protection domain. When the PSC information has changed, three PSC messages SHOULD be transmitted in quick succession, and subsequent messages should be transmitted continually at a lower frequency.
The transmission of three rapid packets allows for fast protection switching even if one or two PSC messages are lost or corrupted. For protection switching within 50ms, it is RECOMMENDED that the default interval of the first three PSC messages SHOULD be no larger than 3.3ms. The subsequent messages SHOULD be transmitted with an interval of 5 sec, to avoid traffic congestion.
| TOC |
The WTR timer is used to delay reversion to Normal state when recovering from a failure condition on the working path and the protection domain is configured for revertive behavior. The WTR may be in one of two states – either Running or Stopped. The WTR timer MAY be started or stopped by the PSC Control Logic.
If the WTR timer expires prior to being stopped it SHALL generate a WTR Expires local signal that shall be processed by the Local Request Logic. If the WTR timer is running, sending a Stop command SHALL reset the timer but SHALL NOT generate a WTR Expires local signal. If the WTR timer is not running, a Stop command SHALL be ignored.
| TOC |
The PSC Control Logic SHOULD maintain information on the current state of the protection domain. The state information SHALL include information of the current state and an indication of the cause for the current state (e.g. unavailable due to local LO command, protecting due to remote FS). In particular, the state information SHOULD include an indication if the state is related to a remote or local condition. If there are both a local indicator and remote indicator for the state then the state shall be considered a local state. For example, if the LER enters into a Protecting failure state due to a remote SF input, and then a local SF indication is received then even though this was initially a remote Protecting failure state, by receiving the local SF input the LER is considered to be in local Protecting failure state.
It should be noted that when referring to the "transport" of the data traffic, in the following descriptions and later in the document that the data will be transmitted on both the working and the protection paths when using 1+1 protection, and on either the working or the protection path exclusively when using 1:1 protection. When using 1+1 protection, the receiving LER should select the proper transmission, according to the state of the protection domain.
The states that are supported by the PSC Control Logic are:
See section 4.3.3 for details on what actions are taken by the PSC Process Logic for each state and the relevant input.
| TOC |
An end-point may be in a given state as a result of either a local input indicator, e.g. OAM, WTR timer, or as a result of receiving a PSC message from the far-end LER. If the state is entered as a result of a local input indicator, then the state SHOULD be considered a local state. If the state is entered as a result of a PSC message, in the absence of a local input, then the state SHOULD be considered a remote state. This differentiation affects how the LER should react to different inputs, as described in section 4.3.3. The PSC Control logic should maintain, together with the current state, an indication of whether this is a local or remote state.
In any instance where the LER has both a local and remote indicators that cause the PSC Control logic to enter a particular state, then the state SHOULD be considered a local state, regardless of the order in which the indicators were processed. If, however, the LER has local and remote indicators that would cause the PSC Control logic to enter different states, e.g. a Local SF on working and a Remote Lockout message, then the state with the higher importance will be the deciding factor and the source of that indicator will determine whether it is local or remote. In the given example the result would be a Remote Unavailable state transmitting SF(1,0) messages.
| TOC |
Bidirectional protection switching, as well as unidirectional 1:1 protection, requires coordination between the two end points in determining which of the two possible paths, the working or recovery path, is transmitting the data traffic in any given situation. When protection switching is triggered as described in section 3.1, 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 LER 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 LER. The other possibility is a single-phased coordination, in which the initiating LER performs the protection switchover to the alternate path and informs the far-end LER of the switch, and the far-end LER MUST complete the switchover.
This protocol is a single-phase protocol, as described above. In the following subsections we describe the protocol messages that SHALL be used between the two end points of the protection domain.
| TOC |
The PSC control packets SHALL be transmitted over the protection path only. This allows the transmission of the messages without affecting the normal data traffic in the most prevalent case, i.e. the Normal 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.
When the PSC information is changed due to a local input, three PSC messages SHOULD be transmitted as quickly as possible, to allow for rapid protection switching. This set of three rapid messages allows for fast protection switching even if one or two of these packets are lost or corrupted. When the PSC information changes due to a remote message there is no need for the aforementioned rapid transmission of three messages. The exception (e.g. when the rapid transmission is still required) is when going from WTR state to Normal state as a result of a remote NR message.
The frequency of the three rapid messages and the separate frequency of the continual transmission SHOULD be configurable by the operator. For protection switching within 50ms, the default interval of the first three PSC messages is RECOMMENDED to be no larger than 3.3ms. The continuous transmission interval is RECOMMENDED to be 5 seconds.
If no valid PSC specific information is received, the last valid received information remains applicable. In the event a signal fail condition is detected on the protection path, the received PSC specific information should be evaluated.
| TOC |
The protocol messages SHALL be sent over the G-ACh as described in [RFC5586] (Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and D. Ward, “MPLS Generic Associated Channel,” May 2009.). There is a single channel type for the set of PSC messages [to be assigned by IANA]. The actual message function SHALL be identified by the Request field of the ACH payload as described below. The following figure shows the format for the complete PSC message:.
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|Version| Reserved | Channel Type = MPLS-TP PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|Request|PT |R| Reserved | FPath | Path |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 2: Format of PSC packet with a G-ACh header |
Where:
| TOC |
The Ver field identifies the version of the protocol. For this version the value SHALL be 0.
| TOC |
The PSC protocol SHALL support transmission of the following requests between the two end points of the protection domain:
| TOC |
The PT field indicates the currently configured protection architecture type, this SHOULD be validated to be consistent for both ends of the protection domain. If an inconsistency is detected then an alarm SHALL be sent to the management system. The following are the possible values:
As described in the introduction (section 1.1) a 1+1 protection architecture is characterized by the use of a permanent bridge at the source node, whereas the 1:1 and 1:n protection architectures are characterized by the use of a selector bridge at the source node.
| TOC |
This field indicates that the transmitting end point is configured to work in revertive mode. If there is an inconsistency between the two end points, i.e. one end point is configured for revertive action and the second end point is in non-revertive mode, then the management system SHOULD be notified. Possible values are:
| TOC |
The Fpath field indicates which path (i.e. working or protection) is identified to be in a fault condition or affected by an administrative command. The following are the possible values:
| TOC |
The Path field indicates which data is being transmitted on the protection path. Under normal conditions, the protection path (especially in 1:1 or 1:n architecture) does not need to carry any user data traffic. If there is a failure/degrade condition on one of the working paths, then that working path's data traffic will be transmitted over the protection path. The following are the possible values:
| TOC |
In all of the following subsections, assume a protection domain between LER-A and LER-Z, using paths W (working) and P (protection) as shown in figure 3.
+-----+ //=======================\\ +-----+
|LER-A|// Working Path \\|LER-Z|
| /| |\ |
| ?< | | >? |
| \|\\ Protection Path //|/ |
+-----+ \\=======================// +-----+
|--------Protection Domain--------|
| Figure 3: Protection domain |
| TOC |
The purpose of the PSC protocol is to allow an end point of the protection domain to notify its peer of the status of the domain that is known at the end point and coordinate the transmission of the data traffic. The current state of the end point is expressed in the values of the Request field [reflecting the local requests at that end point] and the Fpath field [reflecting knowledge of a blocked path]. The coordination between the end points is expressed by the value of the Path field [indicating where the user data traffic is being transmitted]. The value of the Path field SHOULD be identical for both end points at any particular time. The values of the Request and Fpath fields may not be identical between the two end points. In particular it should be noted that a remote message MAY not cause the end point to change the Request field that is being transmitted while it does affect the Path field (see details in the following subsections).
The protocol is a single-phase protocol. Single-phase implies that each end point notifies its peer of a change in the operation (switching to or from the protection path) and makes the switch without waiting for acknowledgement.
The following subsections will identify the messages that SHALL be transmitted by the end point in different scenarios. The messages are described as REQ(FP, P) – where REQ is the value of the Request field, FP is the value of the Fpath field, and P is the value of the Path field. All examples assume a protection domain between LER-A and LER-Z with a single working path and single protection path (as shown in figure 3). Again it should be noted that when using 1:1 protection the data traffic will be transmitted exclusively on either the protection or working path, while when using 1+1 protection the traffic will be transmitted on both paths and the receiving LER should select the appropriate signal based on the state. The text will refer to this transmission/selection as "transport" of the data traffic.
| TOC |
As noted above (in section 3.1.1) the PSC Control Process accepts input from five local input sources. There is a definition of priority between the different inputs that may be triggered locally. The list of local requests in order of priority are (from highest to lowest priority):
As was noted above, the Local request logic SHALL always select the local input indicator with the highest priority as the current local request. All local inputs with lower priority than this current local request will be blocked.
The determination of whether a remote message is accepted or ignored is a function of the current state of the local LER and the current local request (see section 3.1.3). Part of this consideration will be included in the following subsections describing the operation in the different states.
| TOC |
The following sub-sections present the operation of the different states defined in section 3.1.6. For each state we define the reaction, i.e. the new state and the message to transmit, to each possible input – either the highest priority local input or the PSC message from the remote LER. If the definition states to "ignore" the message, the intention is that the LER should remain in its current state and continue transmitting (as presented in section 4.1) the current PSC message.
| TOC |
When the protection domain has no special condition in effect, the ingress LER SHALL 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 LER SHALL read the data from the working path.
When the end point is in Normal State it SHALL transmit a NR(0,0) message, indicating – Nothing to report and data traffic is being transported on the working path.
When the LER (assume LER-A) is in Normal State the following transitions are relevant in reaction to a local input (new state SHOULD be marked as local):
In Normal state, remote messages would cause the following reaction from the LER (new state SHOULD be marked as remote):
| TOC |
When the protection path is unavailable – either as a result of a Lockout operator command, or as a result of a SF detected on the protection path – then the protection domain is in the unavailable state. In this state, the data traffic is transported on the working path and is not protected. When the domain is in unavailable state the PSC messages may not get through and therefore the protection is more dependent on the local inputs rather than the remote messages (that may not be received).
The protection domain will exit the unavailable state and revert to the normal state when, either the operator clears the Lockout command or the protection path recovers from the signal fail or degraded situation. Both ends will resume sending the PSC packets over the protection path, as a result of this recovery.
When the LER (assume LER-A) is in Unavailable State the following transitions are relevant in reaction to a local input (new state SHOULD be marked as local):
If remote messages are being received over the protection path then they would have the following affect:
| TOC |
In the protecting state the user data traffic is being transported on the protection path, while the working path is blocked due to an operator command, i.e. Forced Switch or Manual Switch. The difference between a local FS and local MS affects what local indicators may be received - the Local request logic will block any local SF when under the influence of a local FS, whereas the SF would override a local MS. In general, a MS will be canceled in case of either a local or remote SF or LO condition.
The following describe the reaction to local input:
While in Protecting administrative state the LER may receive and react as follows to remote PSC messages:
| TOC |
When the protection mechanism has been triggered and the protection domain has performed a protection switch, the domain is in the protecting failure state. In this state the normal data traffic is transported on the protection path. When an LER is in this state it implies that there was either a local SF condition or received a remote SF PCS message. The SF condition or message indicated that the failure is on the working path.
This state may be overridden by the Unavailable state triggers, i.e. Lockout of Protection or SF on the protection path, or by issuing a FS operator command. This state will be cleared when the SF condition is cleared. In order to prevent flapping due to an intermittent fault, the LER SHOULD employ a Wait-to-restore timer to delay return to Normal state until the network has stabilized (see section 3.1.5)
The following describe the reaction to local input:
While in Protecting failure state the LER may receive and react as follows to remote PSC messages:
| TOC |
The Wait-to-Restore state is used by the PSC protocol to delay reverting to the normal state, when recovering from a failure condition on the working path, for the period of the WTR timer to allow the recovering failure to stabilize. While in the Wait-to-Restore state the data traffic SHALL continue to be transported on the protection path. The natural transition from the Wait-to-Restore state to Normal state will occur when the WTR timer expires.
When in Wait-to-Restore state the following describe the reaction to local inputs:
When in Wait-to-Restore state the following describe the reaction to remote messages:
| TOC |
Do-not-revert state is a continuation of the Protecting failure state. When the protection domain is configured for non-revertive behavior. While in Do-not-revert state, data traffic continues to be transported on the protection path until the administrator sends a command to revert to the Normal state. It should be noted that there is a fundamental difference between this state and Normal – whereas Forced Switch in Normal state actually causes a switch in the transport path used, in Do-not-revert state the Forced switch just switches the state (to Protecting administrative state) but the traffic would continue to be transported on the protection path! To revert back to Normal state the administrator SHALL issue a Lockout of protection command followed by a Clear command.
When in Do-not-revert state the following describe the reaction to local input:
When in Do-not-revert state the following describe the reaction to remote messages:
| TOC |
This draft requires the allocation of a Channel Code from the G-ACh repository.
| TOC |
To be added in future version.
| TOC |
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.
| TOC |
The PSC state machine is described in section 4.3.3. This appendix provides the same information but in tabular format. In the event of a mismatch between these tables and the text in section 4.3.3, the text is authoritative. Note that this appendix is intended to be a functional description, not an implmentation specification.
For the sake of clarity of the table the six states listed in the text are split into thirteen states. The logic of the split is to differentiate between the different cases given in the conditional statements in the descriptions of each state in the text. In addition, the remote and local states were split for the Unavailable, Protecting failure, and Protecting administrative states.
There is only one table for the PSC state machine, but it is broken into two parts for space reasons. The first part lists the thirteen possible states, the eight possible local inputs (that is, inputs which are generated by the node in question) and the action taken when a given input is received when the node is in a particular state. The second part of the table lists the thirteen possible states and the eight remote inputs (inputs which come from a node other than the one executing the state machine).
There are thirteen rows in the table, headers notwithstanding. These rows are the thirteen possible extended states in the state machine.
The text in the first column is the current state. Those states which have both source and cause are formatted as State:Cause:Source. For example, the string UA:LO:L indicates that the current state is 'Unavailable', that the cause of the current state is a Lockoutof protection that was a Local input. In contrast, the state N simply is Normal; there is no need to track the cause for entry into Normal state.
The thirteen extended states, as they appear in the table, are:
| N | Normal state |
| UA:LO:L | Unavailable state due to local Lockout |
| UA:P:L | Unavailable state due to local SF on protection path |
| UA:LO:R | Unavailable state due to remote Lockout message |
| UA:P:R | Unavailable state due to remote SF message on protection path |
| PF:W:L | Protecting failure state due to local SF on working path |
| PF:W:R | Protecting failure state due to remote SF message on working path |
| PA:F:L | Protecting administrative state due to local FS operator command |
| PA:M:L | Protecting administrative state due to local MS operator command |
| PA:F:R | Protecting administrative state due to remote FS message |
| PA:M:R | Protecting administrative state due to remote MS message |
| WTR | Wait-to-restore state |
| DNR | Do-not-revert state |
Each state corresponds to the transmission of a particular set of Request, FPath and Path bits. The table below lists the message that is generally sent in each particular state. If the message to be sent in a particular state deviates from the table below, it is noted in the footnotes to the state-machine table.
| State | REQ(FP,P) |
|---|---|
| N | NR(0,0) |
| UA:LO:L | LO(0,0) |
| UA:P:L | SF(0,0) |
| UA:LO:R | NR(0,0) |
| UA:P:R | NR(0,0) |
| PF:W:L | SF(1,1) |
| PF:W:R | NR(0,1) |
| PA:F:L | FS(1,1) |
| PA:M:L | MS(1,1) |
| PA:F:R | NR(0,1) |
| PA:M:R | NR(0,1) |
| WTR | WTR(0,1) |
| DNR | DNR(0,1) |
The top row in each table is the list of possible inputs. The local inputs are:
| NR | No Request |
| OC | Operator Clear |
| LO | Lockout of protection |
| SF-P | Signal Fail on protection path |
| SF-W | Signal Fail on working path |
| FS | Forced Switch |
| CSF | Clear Signal Fail |
| MS | Manual Switch |
| WTRExp | WTR Expired |
and the remote inputs are:
| LO | remote LO message |
| SF-P | remote SF message indicating protection path |
| SF-W | remote SF message indicating working path |
| FS | remote FS message |
| MS | remote MS message |
| WTR | remote WTR message |
| DNR | remote DNR message |
| NR | remote NR message |
Section 4.3.3 refers to some states as 'remote' and some as 'local'. By definition, all states listed in the table of local sources are local states, and all states listed in the table of remote sources are remote states. For example, section 4.3.3.1 says "A local Lockout of protection input SHALL cause the LER to go into local Unavailable State". As the trigger for this state change is a local one, 'local Unavailable State' is by definition displayed in the table of local sources. Similarly, "A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state" means that the state represented in the Unavailable rows in the table of remote sources is by definition a remote Unavailable state.
Each cell in the table below contains either a state, a footnote, or the letter 'i'. 'i' stands for Ignore, and is an indication to continue with the current behavior. See section 4.3.3. The footnotes are listed below the table.
Part 1: Local input state machine
| OC | LO | SF-P | FS | SF-W | CSF | MS | WTRExp
--------+-----+-------+------+------+------+------+------+-------
N | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i
UA:LO:L | N | i | i | i | i | i | i | i
UA:P:L | i |UA:LO:L| i | i | i | [5] | i | i
UA:LO:R | i |UA:LO:L| [1] | i | [2] | [6] | i | i
UA:P:R | i |UA:LO:L|UA:P:L| i | [3] | [6] | i | i
PF:W:L | i |UA:LO:L|UA:P:L|PA:F:L| i | [7] | i | i
PF:W:R | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i | i | i
PA:F:L | N |UA:LO:L|UA:P:L| i | i | i | i | i
PA:M:L | N |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i | i | i
PA:F:R | i |UA:LO:L|UA:P:L|PA:F:L| [4] | [8] | i | i
PA:M:R | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i
WTR | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| [9]
DNR | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i
Part 2: Remote messages state machine
| LO | SF-P | FS | SF-W | MS | WTR | DNR | NR
--------+-------+------+------+------+------+------+------+------
N |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i
UA:LO:L | i | i | i | i | i | i | i | i
UA:P:L | [10] | i | i | i | i | i | i | i
UA:LO:R | i | i | i | i | i | i | i | [16]
UA:P:R |UA:LO:R| i | i | i | i | i | i | [16]
PF:W:L | [11] | [12] |PA:F:R| i | i | i | i | i
PF:W:R |UA:LO:R|UA:P:R|PA:F:R| i | i | [14] | [15] | i
PA:F:L |UA:LO:R|UA:P:R| i | i | i | i | i | i
PA:M:L |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | i
PA:F:R |UA:LO:R|UA:P:R| i | i | i | i | i | N
PA:M:R |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | N
WTR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | [17]
DNR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i
The following are the footnotes for the table:
[1] Remain in the current state (UA:LO:R) and transmit SF(0,0)
[2] Remain in the current state (UA:LO:R) and transmit SF(1,0)
[3] Remain in the current state (UA:P:R) and transmit SF(1,0)
[4] Remain in the current state (PA:F:R) and transmit SF(1,1)
[5] If the SF being cleared is SF-P, Transition to N. If it's SF-W, ignore the clear.
[6] Remain in current state (UA:x:R), if the CSF corresponds to a previous SF then begin transmitting NR(0,0).
[7] If the SF being cleared is SF-P, ignore the clear. If it's SF-W, transition to WTR, start the WTR timer, and send WTR(1,1)
[8] Remain in PA:F:R and transmit NR(0,1)
[9] Remain in WTR, send NR(0,1)
[10] Transition to UA:LO:R continue sending SF(0,0)
[11] Transition to UA:LO:R and send SF(1,0)
[12] Transition to UA and send SF(1,0)
[13] Transition to PF:W:R and send NR(0,1)
[14] Transition to WTR state and continue to send the current message.
[15] Transition to DNR state and continue to send the current message.
[16] Transition to N state and continue to send the current message.
[17] If the receiving node's WTR timer has expired, transition to N. If not, maintain current state and message.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997. |
| [RFC5654] | Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” RFC 5654, September 2009. |
| TOC |
| [RFC3031] | Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” RFC 3031, Jan 2001. |
| [RFC3032] | Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding,” RFC 3032, Jan 2001. |
| [RFC5659] | Bocci, M. and S. Bryant, “An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge,” RFC 5659, October 2009. |
| [RFC3985] | Bryant, S. and P. Pate, “Pseudowire Emulation Edge-to-Edge (PWE3) Architecture,” RFC 3985, March 2005 (TXT). |
| [RFC5085] | Nadeau, T. and C. Pignataro, “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires,” RFC 5085, December 2007 (TXT). |
| [TPFwk] | Bocci, M., Bryant, S., and L. Levrau, “A Framework for MPLS in Transport Networks,” ID draft-ietf-mpls-tp-framework-06.txt, July 2009. |
| [RFC5586] | Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and D. Ward, “MPLS Generic Associated Channel,” RFC 5586, May 2009. |
| [RFC4427] | Mannie, E. and D. Papadimitriou, “Recovery Terminology for Generalized Multi-Protocol Label Switching,” RFC 4427, Mar 2006. |
| [SurvivFwk] | Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” ID draft-ietf-mpls-tp-survive-fwk-02.txt, Feb 2009. |
| [RFC4872] | Lang, J., Papadimitriou, D., and Y. Rekhter, “RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery,” RFC 4872, May 2007. |
| [RFC3945] | Mannie, E., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” RFC 3945, Oct 2004. |
| TOC |
| Stewart Bryant (editor) | |
| Cisco | |
| United Kingdom | |
| Email: | stbryant@cisco.com |
| Eric Osborne | |
| Cisco | |
| United States | |
| Email: | eosborne@cisco.com |
| Nurit Sprecher (editor) | |
| Nokia Siemens Networks | |
| 3 Hanagar St. Neve Ne'eman B | |
| Hod Hasharon, 45241 | |
| Israel | |
| Email: | nurit.sprecher@nsn.com |
| Annamaria Fulignoli (editor) | |
| Ericsson | |
| Italy | |
| Phone: | |
| Email: | annamaria.fulignoli@ericsson.com |
| Yaacov Weingarten | |
| Nokia Siemens Networks | |
| 3 Hanagar St. Neve Ne'eman B | |
| Hod Hasharon, 45241 | |
| Israel | |
| Phone: | +972-9-775 1827 |
| Email: | yaacov.weingarten@nsn.com |