diff options
Diffstat (limited to 'doc/rfc/rfc4426.txt')
| -rw-r--r-- | doc/rfc/rfc4426.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc4426.txt b/doc/rfc/rfc4426.txt new file mode 100644 index 0000000..6cadfc0 --- /dev/null +++ b/doc/rfc/rfc4426.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group J. Lang, Ed. +Request for Comments: 4426 B. Rajagopalan, Ed. +Category: Standards Track D. Papadimitriou, Ed. + March 2006 + + + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery Functional Specification + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document presents a functional description of the protocol + extensions needed to support Generalized Multi-Protocol Label + Switching (GMPLS)-based recovery (i.e., protection and restoration). + Protocol specific formats and mechanisms will be described in + companion documents. + +Table of Contents + + 1. Introduction ................................................. 2 + 1.1. Conventions Used in This Document ...................... 3 + 2. Span Protection .............................................. 3 + 2.1. Unidirectional 1+1 Dedicated Protection ................ 4 + 2.2. Bi-directional 1+1 Dedicated Protection ................ 5 + 2.3. Dedicated 1:1 Protection with Extra Traffic ............ 6 + 2.4. Shared M:N Protection .................................. 8 + 2.5. Messages ............................................... 10 + 2.5.1. Failure Indication Message ..................... 10 + 2.5.2. Switchover Request Message ..................... 11 + 2.5.3. Switchover Response Message .................... 11 + 2.6. Preventing Unintended Connections ...................... 12 + 3. End-to-End (Path) Protection and Restoration ................. 12 + 3.1. Unidirectional 1+1 Protection .......................... 12 + 3.2. Bi-directional 1+1 Protection .......................... 12 + 3.2.1. Identifiers .................................... 13 + 3.2.2. Nodal Information .............................. 14 + + + +Lang, et al. Standards Track [Page 1] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + 3.2.3. End-to-End Failure Indication Message .......... 14 + 3.2.4. End-to-End Failure Acknowledgement Message ..... 15 + 3.2.5. End-to-End Switchover Request Message .......... 15 + 3.2.6. End-to-End Switchover Response Message ......... 15 + 3.3. Shared Mesh Restoration ................................ 15 + 3.3.1. End-to-End Failure Indication and + Acknowledgement Message ........................ 16 + 3.3.2. End-to-End Switchover Request Message .......... 16 + 3.3.3. End-to-End Switchover Response Message ......... 17 + 4. Reversion and Other Administrative Procedures ................ 17 + 5. Discussion ................................................... 18 + 5.1. LSP Priorities During Protection ....................... 18 + 6. Security Considerations ...................................... 19 + 7. Contributors ................................................. 20 + 8. References ................................................... 21 + 8.1. Normative References ................................... 21 + 8.2. Informative References ................................. 22 + +1. Introduction + + A requirement for the development of a common control plane for both + optical and electronic switching equipment is that there must be + signaling, routing, and link management mechanisms that support data + plane fault recovery. In this document, the term "recovery" is + generically used to denote both protection and restoration; the + specific terms "protection" and "restoration" are used only when + differentiation is required. The subtle distinction between + protection and restoration is made based on the resource allocation + done during the recovery period (see [RFC4427]). + + A label-switched path (LSP) may be subject to local (span), segment, + and/or end-to-end recovery. Local span protection refers to the + protection of the link (and hence all the LSPs marked as required for + span protection and routed over the link) between two neighboring + switches. Segment protection refers to the recovery of an LSP + segment (i.e., an SNC in the ITU-T terminology) between two nodes, + i.e., the boundary nodes of the segment. End-to-end protection + refers to the protection of an entire LSP from the ingress to the + egress port. The end-to-end recovery models discussed in this + document apply to segment protection where the source and destination + refer to the protected segment rather than the entire LSP. Multiple + recovery levels may be used concurrently by a single LSP for added + resiliency; however, the interaction between levels affects any one + direction of the LSP results in both directions of the LSP being + switched to a new span, segment, or end-to-end path. + + + + + + +Lang, et al. Standards Track [Page 2] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + Unless otherwise stated, all references to "link" in this document + indicate a bi-directional link (which may be realized as a pair of + unidirectional links). + + Consider the control plane message flow during the establishment of + an LSP. This message flow proceeds from an initiating (or source) + node to a terminating (or destination) node, via a sequence of + intermediate nodes. A node along the LSP is said to be "upstream" + from another node if the former occurs first in the sequence. The + latter node is said to be "downstream" from the former node. That + is, an "upstream" node is closer to the initiating node than a node + further "downstream". Unless otherwise stated, all references to + "upstream" and "downstream" are in terms of the control plane message + flow. + + The flow of the data traffic is defined from ingress (source node) to + egress (destination node). Note that for bi-directional LSPs, there + are two different data plane flows, one for each direction of the + LSP. This document presents a protocol functional description to + support Generalized Multi-Protocol Label Switching (GMPLS)-based + recovery (i.e., protection and restoration). Protocol-specific + formats, encoding, and mechanisms will be described in companion + documents. + +1.1. 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 [RFC2119]. + + In addition, the reader is assumed to be familiar with the + terminology used in [RFC3945], [RFC3471] and referenced as well as + [RFC4427]. + +2. Span Protection + + Consider a (working) link i between two nodes A and B. There are two + fundamental models for span protection. The first is referred to as + 1+1 protection. Under this model, a dedicated link j is pre-assigned + to protect link i. LSP traffic is permanently bridged onto both + links i and j at the ingress node, and the egress node selects the + signal (i.e., normal traffic) from i or j, based on a selection + function (e.g., signal quality). Under unidirectional 1+1 span + protection (Section 2.1), each node A and B acts autonomously to + select the signal from the working link i or the protection link j. + Under bi-directional 1+1 span protection (Section 2.2) the two nodes + A and B coordinate the selection function such that they select the + signal from the same link, i or j. + + + +Lang, et al. Standards Track [Page 3] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + Under the second model, a set of N working links are protected by a + set of M protection links, usually with M =< N. A failure in any of + the N working links results in traffic being switched to one of the M + protection links that is available. This is typically a three-step + process: first the data plane failure is detected at the egress node + and reported (notification), then a protection link is selected, and + finally, the LSPs on the failed link are moved to the protection + link. If reversion is supported, a fourth step is included, i.e., + return of the traffic to the working link (when the working link has + recovered from the failure). In Section 2.3, 1:1 span protection is + described. In Section 2.4, M:N span protection is described, where + M =< N. + +2.1. Unidirectional 1+1 Dedicated Protection + + Suppose a bi-directional LSP is routed over link i between two nodes + A and B. Under unidirectional 1+1 protection, a dedicated link j is + pre-assigned to protect the working link i. LSP traffic is + permanently bridged on both links at the ingress node, and the egress + node selects the normal traffic from one of the links, i or j. If a + node (A or B) detects a failure of a span, it autonomously invokes a + process to receive the traffic from the protection span. Thus, it is + possible that node A selects the signal from link i in the B to A + direction of the LSP, and node B selects the signal from link j in + the A to B direction. + + The following functionality is required for 1+1 unidirectional span + protection: + + o Routing: A single TE link encompassing both working and + protection links SHOULD be announced with a Link Protection + Type "Dedicated 1+1", along with the bandwidth parameters for + the working link. As the resources are consumed/released, the + bandwidth parameters of the TE link are adjusted accordingly. + Encoding of the Link Protection Type and bandwidth parameters + in IS-IS is specified in [RFC4205]. Encoding of this + information in OSPF is specified in [RFC4203]. + + o Signaling: The Link Protection object/TLV SHOULD be used to + request "Dedicated 1+1" link protection for that LSP. This + object/TLV is defined in [RFC3471]. If the Link Protection + object/TLV is not used, link selection is a matter of local + policy. No additional signaling is required when a fail-over + occurs. + + + + + + + +Lang, et al. Standards Track [Page 4] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + o Link management: Both nodes MUST have a consistent view of the + link protection association for the spans. This can be done + using the Link Management Protocol (LMP) [RFC4204], or if LMP + is not used, this MUST be configured manually. + +2.2. Bi-directional 1+1 Dedicated Protection + + Suppose a bi-directional LSP is routed over link i between two nodes + A and B. Under bi-directional 1+1 protection, a dedicated link j is + pre-assigned to protect the working link i. LSP traffic is + permanently duplicated on both links, and under normal conditions, + the traffic from link i is received by nodes A and B (in the + appropriate directions). A failure affecting link i results in both + A and B switching to the traffic on link j in the respective + directions. Note that some form of signaling is required to ensure + that both A and B start receiving traffic from the protection link. + + The basic steps in 1+1 bi-directional span protection are as follows: + + 1. If a node (A or B) detects the failure of the working link (or + a degradation of signal quality over the working link), it + SHOULD begin receiving on the protection link and send a + Switchover Request message reliably to the other node (B or A, + respectively). This message SHOULD indicate the identity of + the failed working link and provide other relevant information. + + 2. Upon receipt of the Switchover Request message, a node MUST + begin receiving from the protection link and send a Switchover + Response message to the other node (A or B, respectively). + Because both the working/protect spans are exposed to routing + and signaling as a single link, the switchover SHOULD be + transparent to routing and signaling. + + The following functionality is required for 1+1 bi-directional span + protection: + + o The routing procedures are the same as in 1+1 unidirectional. + + o The signaling procedures are the same as in 1+1 unidirectional. + + o In addition to the procedures described in 1+1 + (unidirectional), a Switchover Request message MUST be used to + signal the Switchover Request. This can be done using LMP + [RFC4204]. Note that GMPLS-based mechanisms MAY not be + necessary when the underlying span (transport) technology + provides such a mechanism. + + + + + +Lang, et al. Standards Track [Page 5] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + +2.3. Dedicated 1:1 Protection with Extra Traffic + + Consider two adjacent nodes, A and B. Under 1:1 protection, a + dedicated link j between A and B is pre-assigned to protect working + link i. Link j may be carrying (pre-emptable) Extra Traffic. A + failure affecting link i results in the corresponding LSP(s) being + restored to link j. Extra Traffic being routed over link j may need + to be pre-empted to accommodate the LSPs that have to be restored. + + Once a fault is isolated/localized, the affected LSP(s) must be moved + to the protection link. The process of moving an LSP from a failed + (working) link to a protection link must be initiated by one of the + nodes, A or B. This node is referred to as the "master". The other + node is called the "slave". The determination of the master and the + slave may be based on configured information or protocol specific + requirements. + + The basic steps in dedicated 1:1 span protection (ignoring reversion) + are as follows: + + 1. If the master detects/localizes a link failure event, it + invokes a process to allocate the protection link to the + affected LSP(s). + + 2. If the slave detects a link failure event, it informs the + master of the failure using a failure indication message. The + master then invokes the same procedure as (1) to move the LSPs + to the protection link. If the protection link is carrying + Extra Traffic, the slave stops using the span for the Extra + Traffic. + + 3. Once the span protection procedure is invoked in the master, it + requests the slave to switch the affected LSP(s) to the + protection link. Prior to this, if the protection link is + carrying Extra Traffic, the master stops using the span for + this traffic (i.e., the traffic is dropped by the master and + not forwarded into or out of the protection link). + + 4. The slave sends an acknowledgement to the master. Prior to + this, the slave stops using the link for Extra Traffic (i.e., + the traffic is dropped by the slave and not forwarded into or + out of the protection link). It then starts sending the normal + traffic on the selected protection link. + + 5. When the master receives the acknowledgement, it starts sending + and receiving the normal traffic over the new link. The + switchover of the LSPs is thus completed. + + + + +Lang, et al. Standards Track [Page 6] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + Note: Although this mechanism implies more traffic dropped than + necessary, it is preferred over possible misconnections during the + recovery process. + + From the description above, it is clear that 1:1 span protection may + require up to three signaling messages for each failed span: a + failure indication message, an LSP Switchover Request message, and an + LSP Switchover Response message. Furthermore, it may be possible to + switch multiple LSPs from the working span to the protection span + simultaneously. + + The following functionality is required for dedicated 1:1 span + protection: + + o Pre-emption MUST be supported to accommodate Extra Traffic. + + o Routing: A single TE link encompassing both working and + protection links is announced with a Link Protection Type + "Dedicated 1:1". If Extra Traffic is supported over the + protection link, then the bandwidth parameters for the + protection link MUST also be announced. The differentiation + between bandwidth for working and protect links is made using + priority mechanisms. In other words, the network MUST be + configured such that bandwidth at priority X or lower is + considered Extra Traffic. + + If there is a failure on the working link, then the normal + traffic is switched to the protection link, pre-empting Extra + Traffic if necessary. The bandwidth for the protection link + MUST be adjusted accordingly. + + o Signaling: To establish an LSP on the working link, the Link + Protection object/TLV indicating "Dedicated 1:1" SHOULD be + included in the signaling request message for that LSP. To + establish an LSP on the protection link, the appropriate + priority (indicating Extra Traffic) SHOULD be used for that + LSP. These objects/TLVs are defined in [RFC3471]. If the Link + Protection object/TLV is not used, link selection is a matter + of local policy. + + o Link management: Both nodes MUST have a consistent view of the + link protection association for the spans. This can be done + using LMP [RFC4204] or via manual configuration. + + o When a link failure is detected at the slave, a failure + indication message MUST be sent to the master informing the + node of the link failure. + + + + +Lang, et al. Standards Track [Page 7] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + +2.4. Shared M:N Protection + + Shared M:N protection is described with respect to two neighboring + nodes, A and B. The scenario considered is as follows: + + o At any point in time, there are two sets of links between A and + B, i.e., a working set of N (bi-directional) links carrying + traffic subject to protection and a protection set of M (bi- + directional) links. A protection link may be carrying Extra + Traffic. There is no a priori relationship between the two + sets of links, but the value of M and N MAY be pre-configured. + The specific links in the protection set MAY be pre-configured + to be physically diverse to avoid the possibility of failure + events affecting a large proportion of protection links (along + with working links). + + o When a link in the working set is affected by a failure, the + normal traffic is diverted to a link in the protection set, if + such a link is available. Note that such a link might be + carrying more than one LSP, e.g., an OC-192 link carrying four + STS-48 LSPs. + + o More than one link in the working set may be affected by the + same failure event. In this case, there may not be an adequate + number of protection links to accommodate all of the affected + traffic carried by failed working links. The set of affected + working links that are actually restored over available + protection links is then subject to policies (e.g., based on + relative priority of working traffic). These policies are not + specified in this document. + + o When normal traffic must be diverted from a failed link in the + working set to a protection link, the decision as to which + protection link is chosen is always made by one of the nodes, A + or B. This node is considered the "master" and it is required + to both apply any policies and select specific protection links + to divert working traffic. The other node is considered the + "slave". The determination of the master and the slave MAY be + based on configured information, protocol-specific + requirements, or as a result of running a neighbor discovery + procedure. + + o Failure events are detected by transport layer mechanisms, if + available (e.g., SONET Alarm Indication Signal (AIS)/Remote + Defect Indication (RDI)). Since the bi-directional links are + formed by a pair of unidirectional links, a failure in the link + from A to B is typically detected by B, and a failure in the + opposite direction is detected by A. It is possible for a + + + +Lang, et al. Standards Track [Page 8] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + failure to simultaneously affect both directions of the bi- + directional link. In this case, A and B will concurrently + detect failures, in the B-to-A direction and in the A-to-B + direction, respectively. + + The basic steps in M:N protection (ignoring reversion) are as + follows: + + 1. If the master detects a failure of a working link, it + autonomously invokes a process to allocate a protection link to + the affected traffic. + + 2. If the slave detects a failure of a working link, it MUST + inform the master of the failure using a failure indication + message. The master then invokes the same procedure as above + to allocate a protection link. (It is possible that the master + has itself detected the same failure, for example, a failure + simultaneously affecting both directions of a link.) + + 3. Once the master has determined the identity of the protection + link, it indicates this to the slave and requests the + switchover of the traffic (using a "Switchover Request" + message). Prior to this, if the protection link is carrying + Extra Traffic, the master stops using the link for this traffic + (i.e., the traffic is dropped by the master and not forwarded + into or out of the protection link). + + 4. The slave sends a "Switchover Response" message back to the + master. Prior to this, if the selected protection link is + carrying traffic that could be pre-empted, the slave stops + using the link for this traffic (i.e., the traffic is dropped + by the slave and not forwarded into or out of the protection + link). It then starts sending the normal traffic on the + selected protection link. + + 5. When the master receives the Switchover Response, it starts + sending and receiving the traffic that was previously carried + on the now-failed link over the new link. + + Note: Although this mechanism implies more traffic dropped than + necessary, it is preferred over possible misconnections during the + recovery process. + + From the description above, it is clear that M:N span restoration + (involving LSP local recovery) MAY require up to three messages for + each working link being switched: a failure indication message, a + Switchover Request message, and a Switchover Response message. + + + + +Lang, et al. Standards Track [Page 9] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + The following functionality is required for M:N span restoration: + + o Pre-emption MUST be supported to accommodate Extra Traffic. + + o Routing: A single TE link encompassing both sets of working and + protect links should be announced with a Link Protection Type + "Shared M:N". If Extra Traffic is supported over a set of the + protection links, then the bandwidth parameters for the set of + protection links MUST also be announced. The differentiation + between bandwidth for working and protect links is made using + priority mechanisms. + + If there is a failure on a working link, then the affected + LSP(s) MUST be switched to a protection link, pre-empting Extra + Traffic if necessary. The bandwidth for the protection link + MUST be adjusted accordingly. + + o Signaling: To establish an LSP on the working link, the Link + Protection object/TLV indicating "Shared M:N" SHOULD be + included in the signaling request message for that LSP. To + establish an LSP on the protection link, the appropriate + priority (indicating Extra Traffic) SHOULD be used. These + objects/TLVs are defined in [RFC3471]. If the Link Protection + object/TLV is not used, link selection is a matter of local + policy. + + o For link management, both nodes MUST have a consistent view of + the link protection association for the links. This can be + done using LMP [RFC4204] or via manual configuration. + +2.5. Messages + + The following messages are used in local span protection procedures. + + These messages SHOULD be delivered reliably. Therefore, the protocol + mechanisms used to deliver these messages SHOULD provide sequencing, + acknowledgement, and retransmission. The protocol SHOULD also handle + situations where the message(s) cannot be delivered. + + The messages described in the following subsections are abstract; + their format and encoding will be described in separate documents. + +2.5.1. Failure Indication Message + + This message is sent from the slave to the master to indicate the + identities of one or more failed working links. This message MAY not + be necessary when the transport plane technology itself provides for + such a notification. + + + +Lang, et al. Standards Track [Page 10] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + The number of links included in the message depends on the number of + failures detected within a window of time by the sending node. A + node MAY choose to send separate failure indication messages in the + interest of completing the recovery for a given link within an + implementation-dependent time constraint. + +2.5.2. Switchover Request Message + + Under bi-directional 1+1 span protection, this message is used to + coordinate the selecting function at both nodes. This message + originated at the node that detected the failure. + + Under dedicated 1:1 and shared M:N span protection, this message is + used as an LSP Switchover Request. This message is sent from the + master node to the slave node (reliably) to indicate that the LSP(s) + on the (failed) working link can be switched to an available + protection link. If so, the ID of the protection link, as well as + the LSP labels (if necessary), MUST be indicated. These identifiers + MUST be consistent with those used in GMPLS signaling. + + A working link may carry multiple LSPs. Since the normal traffic + carried over the working link is switched to the protection link, it + MAY be possible for the LSPs on the working link to be mapped to the + protection link without re-signaling each individual LSP. For + example, if link bundling [RFC4201] is used where the working and + protect links are mapped to component links, and the labels are the + same on the working and protection links, it MAY be possible to + change the component links without needing to re-signal each + individual LSP. Optionally, the labels MAY need to be explicitly + coordinated between the two nodes. In this case, the Switchover + Request message SHOULD carry the new label mappings. + + The master may not be able to find protection links to accommodate + all failed working links. Thus, if this message is generated in + response to a Failure Indication message from the slave, then the set + of failed links in the message MAY be a sub-set of the links received + in the Failure Indication message. Depending on time constraints, + the master may switch the normal traffic from the set of failed links + in smaller batches. Thus, a single failure indication message MAY + result in the master sending more than one Switchover Request message + to the same slave node. + +2.5.3. Switchover Response Message + + This message is sent from the slave to the master (reliably) to + indicate the completion (or failure) of switchover at the slave. In + this message, the slave MAY indicate that it cannot switch over to + the corresponding free link for some reason. In this case, the + + + +Lang, et al. Standards Track [Page 11] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + master and slave notify the user (operator) of the failed switchover. + A notification of the failure MAY also be used as a trigger in an + end-to-end recovery. + +2.6. Preventing Unintended Connections + + An unintended connection occurs when traffic from the wrong source is + delivered to a receiver. This MUST be prevented during protection + switching. This is primarily a concern when the protection link is + being used to carry Extra Traffic. In this case, it MUST be ensured + that the LSP traffic being switched from the (failed) working link to + the protection link is not delivered to the receiver of the pre- + empted traffic. Thus, in the message flow described above, the + master node MUST disconnect (any) pre-empted traffic on the selected + protection link before sending the Switchover Request. The slave + node MUST also disconnect pre-empted traffic before sending the + Switchover Response. In addition, the master node SHOULD start + receiving traffic for the protected LSP from the protection link. + Finally, the master node SHOULD start sending protected traffic on + the protection link upon receipt of the Switchover Response. + +3. End-to-End (Path) Protection and Restoration + + End-to-end path protection and restoration refer to the recovery of + an entire LSP from the initiator to the terminator. Suppose the + primary path of an LSP is routed from the initiator (Node A) to the + terminator (Node B) through a set of intermediate nodes. + + The following subsections describe three previously proposed end-to- + end protection schemes and the functional steps needed to implement + them. + +3.1. Unidirectional 1+1 Protection + + A dedicated, resource-disjoint alternate path is pre-established to + protect the LSP. Traffic is simultaneously sent on both paths and + received from one of the functional paths by the end nodes A and B. + + There is no explicit signaling involved with this mode of protection. + +3.2. Bi-directional 1+1 Protection + + A dedicated, resource-disjoint alternate path is pre-established to + protect the LSP. Traffic is simultaneously sent on both paths; under + normal conditions, the traffic from the working path is received by + nodes A and B (in the appropriate directions). A failure affecting + the working path results in both A and B switching to the traffic on + the protection path in the respective directions. + + + +Lang, et al. Standards Track [Page 12] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + Note that this requires coordination between the end nodes to switch + to the protection path. + + The basic steps in bi-directional 1+1 path protection are as follows: + + o Failure detection: There are two possibilities for this. + + 1. A node in the working path detects a failure event. Such + a node MUST send a Failure Indication message toward the + upstream or/and downstream end node of the LSP (node A or + B). This message MAY be forwarded along the working path + or routed over a different path if the network has + general routing intelligence. + + Mechanisms provided by the data transport plane MAY also + be used for this, if available. + + 2. The end nodes (A or B) detect the failure themselves + (e.g., loss of signal). + + o Switchover: The action taken when an end node detects a failure + in the working path is as follows: Start receiving from the + protection path; at the same time, send a Switchover Request + message to the other end node to enable switching at the other + end. + + The action taken when an end node receives a Switchover Request + message is as follows: + + - Start receiving from the protection path; at the same + time, send a Switchover Response message to the other end + node. + + GMPLS signaling mechanisms MAY be used to (reliably) signal the + Failure Indication message, as well as the Switchover Request and + Response message. These messages MAY be forwarded along the + protection path if no other routing intelligence is available in the + network. + +3.2.1. Identifiers + + LSP Identifier: A unique identifier for each LSP. The LSP identifier + is within the scope of the Source ID and Destination ID. + + Source ID: ID of the source (e.g., IP address). + + Destination ID: ID of the destination (e.g., IP address). + + + + +Lang, et al. Standards Track [Page 13] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + +3.2.2. Nodal Information + + Each node that is on the working or protection path of an LSP MUST + have knowledge of the LSP identifier. If the network does not + provide routing intelligence, nodal information MAY also include + previous and next nodes in the LSP so that restoration-related + messages can be forwarded properly. When the network provides + general routing intelligence, messages MAY be forwarded along paths + other than that of the LSP. + + At the end-point nodes, the working and protection paths MUST be + associated. The association of these paths MAY be either provisioned + using signaling or MAY be configured when LSP provisioning does not + involve signaling (e.g., provisioning through a management system). + The related association information MUST remain until the LSP is + explicitly de-provisioned. + +3.2.3. End-to-End Failure Indication Message + + This message is sent (reliably) by an intermediate node toward the + source of an LSP. For instance, such a node might have attempted + local span protection and failed. This message MAY not be necessary + if the data transport layer provides mechanisms for the notification + of LSP failure by the endpoints (i.e., if LSP endpoints are co- + located with a corresponding data (transport) maintenance/recovery + domain). + + Consider a node that detects a link failure. The node MUST determine + the identities of all LSPs that are affected by the failure of the + link and send an End-to-End Failure Indication message to the source + of each LSP. For scalability reasons, Failure Indication messages + MAY contain the identity and the status of multiple LSPs rather than + a single one. Each intermediate node receiving such a message MUST + forward the message to the appropriate next node such that the + message would ultimately reach the LSP source. However, there is no + requirement that this message flows toward the source along the same + path as the failed LSP. Furthermore, if an intermediate node is + itself generating a Failure Indication message, there SHOULD be a + mechanism to suppress all but one source of Failure Indication + messages. Finally, the Failure Indication message MUST be sent + reliably from the node detecting the failure to the LSP source. + Reliability MAY be achieved, for example, by retransmitting the + message until an acknowledgement is received. However, + retransmission of Failure Indication messages SHOULD not cause + further message drops. This MAY be achieved through the appropriate + configuration and use of congestion and flow control mechanisms. + + + + + +Lang, et al. Standards Track [Page 14] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + +3.2.4. End-to-End Failure Acknowledgement Message + + This message is sent by the source node to acknowledge the receipt of + an End-to-End Failure Indication message. This message is sent to + the originator of the Failure Indication message. The Acknowledge + message SHOULD be sent for each Failure Indication Message received. + Each intermediate node receiving the Failure Acknowledgement message + MUST forward it toward the destination of the message. However, + there is no requirement that this message flows toward the + destination along the same path as the failed LSP. + + This message MAY not be required if other means of ensuring reliable + message delivery are used. + +3.2.5. End-to-End Switchover Request Message + + This message is generated by the source node receiving an indication + of failure in an LSP. It is sent to the LSP destination, and it + carries the identifier of the LSP being restored. The End-to-End + Switchover Request message MUST be sent reliably from the source to + the destination of the LSP. + +3.2.6. End-to-End Switchover Response Message + + This message is sent by the destination node receiving an End-to-End + Switchover Request message toward the source of the LSP. This + message SHOULD identify the LSP being switched over. This message + MUST be transmitted in response to each End-to-End Switchover Request + message received and MAY indicate either a positive or negative + outcome. + +3.3. Shared Mesh Restoration + + Shared mesh restoration refers to schemes under which protection + paths for multiple LSPs share common link and node resources. Under + these schemes, the protection capacity is pre-reserved, i.e., link + capacity is allocated to protect one or more LSPs, but explicit + action is required to instantiate a specific protection LSP. This + requires restoration signaling along the protection path. Typically, + the protection capacity is shared only amongst LSPs whose working + paths are physically diverse. This criterion can be enforced when + provisioning the protection path. Specifically, provisioning-related + signaling messages may carry information about the working path to + nodes along the protection path. This can be used as call admission + control to accept/reject connections along the protection path based + on the identification of the resources used for the primary path. + + + + + +Lang, et al. Standards Track [Page 15] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + Thus, shared mesh restoration is designed to protect an LSP after a + single failure event, i.e., a failure that affects the working path + of at most one LSP sharing the protection capacity. It is possible + that a protection path may not be successfully activated when + multiple, concurrent failure events occur. In this case, shared mesh + restoration capacity may be claimed for more than one failed LSP and + the protection path can be activated only for one of them (at most). + + For implementing shared mesh restoration, the identifier and nodal + information related to signaling along the control path are as + defined for 1+1 protection in Sections 3.2.1 and 3.2.2. In addition, + each node MUST also keep (local) information needed to establish the + data plane of the protection path. This information MUST indicate + the local resources to be allocated, the fabric cross-connect to be + established to activate the path, etc. The precise nature of this + information would depend on the type of node and LSP (the GMPLS + signaling document describes different type of switches [RFC3471]). + It would also depend on whether the information is fine or coarse- + grained. For example, fine-grained information would indicate pre- + selection of all details pertaining to protection path activation, + such as outgoing link, labels, etc. Coarse-grained information, on + the other hand, would allow some details to be determined during + protection path activation. For example, protection resources may be + pre-selected at the level of a TE link, while the selection of the + specific component link and label occurs during protection path + activation. + + While the coarser specification allows some flexibility in the + selection of the precise resource to activate, it also adds + complexity in decision making and signaling during the time-critical + restoration phase. Furthermore, the procedures for the assignment of + bandwidth to protection paths MUST take into account the total + resources in a TE link so that single-failure survivability + requirements are satisfied. + +3.3.1. End-to-End Failure Indication and Acknowledgement Message + + The End-to-End failure indication and acknowledgement procedures and + messages are as defined in Sections 3.2.3 and 3.2.4. + +3.3.2. End-to-End Switchover Request Message + + This message is generated by the source node receiving an indication + of failure in an LSP. It is sent to the LSP destination along the + protection path, and it identifies the LSP being restored. If any + intermediate node is unable to establish cross-connects for the + protection path, then it is desirable that no other node in the path + + + + +Lang, et al. Standards Track [Page 16] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + establishes cross-connects for the path. This would allow shared + mesh restoration paths to be efficiently utilized. + + The End-to-End Switchover message MUST be sent reliably from the + source to the destination of the LSP along the protection path. + +3.3.3. End-to-End Switchover Response Message + + This message is sent by the destination node receiving an End-to-End + Switchover Request message toward the source of the LSP, along the + protection path. This message SHOULD identify the LSP that is being + switched over. Prior to activating the secondary bandwidth at each + hop along the path, Extra Traffic (if used) MUST be dropped and not + forwarded. + + This message MUST be transmitted in response to each End-to-End + Switchover Request message received. + +4. Reversion and Other Administrative Procedures + + Reversion refers to the process of moving an LSP back to the original + working path after a failure is cleared and the path is repaired. + Reversion applies both to local span and end-to-end path-protected + LSPs. Reversion is desired for the following reasons. First, the + protection path may not be optimal in comparison to the working path + from a routing and resource consumption point of view. Second, + moving an LSP to its working path allows the protection resources to + be used to protect other LSPs. Reversion has the disadvantage of + causing a second service disruption. Use of reversion is at the + option of the operator. Reversion implies that a working path + remains allocated to the LSP that was originally routed over it, even + after a failure. It is important to have mechanisms that allow + reversion to be performed with minimal service disruption to the + customer. This can be achieved using a "bridge-and-switch" approach + (often referred to as make-before-break). + + The basic steps involved in bridge-and-switch are as follows: + + 1. The source node commences the process by "bridging" the normal + traffic onto both the working and the protection paths (or + links in the case of span protection). + + 2. Once the bridging process is complete, the source node sends a + Bridge and Switch Request message to the destination, + identifying the LSP and other information necessary to perform + reversion. Upon receipt of this message, the destination + + + + + +Lang, et al. Standards Track [Page 17] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + selects the traffic from the working path. At the same time, + it bridges the transmitted traffic onto both the working and + protection paths. + + 3. The destination then sends a Bridge and Switch Response message + to the source confirming the completion of the operation. + + 4. When the source receives this message, it switches to receive + from the working path, and stops transmitting traffic on the + protection path. The source then sends a Bridge and Switch + Completed message to the destination confirming that the LSP + has been reverted. + + 5. Upon receipt of this message, the destination stops + transmitting along the protection path and de-activates the LSP + along this path. The de-activation procedure should remove the + crossed connections along the protection path (and frees the + resources to be used for restoring other failures). + + Administrative procedures other than reversion include the ability to + force a switchover (from working to protection or vice versa) and + locking out switchover, i.e., preventing an LSP from moving from + working to protection administratively. These administrative + conditions have to be supported by signaling. + +5. Discussion + +5.1. LSP Priorities During Protection + + Under span protection, a failure event could affect more than one + working link and there could be fewer protection links than the + number of failed working links. Furthermore, a working link may + contain multiple LSPs of varying priority. Under this scenario, a + decision must be made as to which working links (and therefore LSPs) + should be protected. This decision MAY be based on LSP priorities. + + In general, a node might detect failures sequentially, i.e., all + failed working links may not be detected simultaneously, but only + sequentially. In this case, as per the proposed signaling + procedures, LSPs on a working link MAY be switched over to a given + protection link, but another failure (of a working link carrying + higher priority LSPs) may be detected soon afterward. In this case, + the new LSPs may bump the ones previously switched over the + protection link. + + In the case of end-to-end shared mesh restoration, priorities MAY be + implemented for allocating shared link resources under multiple + failure scenarios. As described in Section 3.3, more than one LSP + + + +Lang, et al. Standards Track [Page 18] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + can claim shared resources under multiple failure scenarios. If such + resources are first allocated to a lower-priority LSP, they MAY have + to be reclaimed and allocated to a higher-priority LSP. + +6. Security Considerations + + There are a number of security threats that MAY be experienced due to + the exchange of messages and information, as detailed in this + document. Some examples include interception, spoofing, + modification, and replay of control messages. Therefore, the + following security requirements are applicable to the mechanisms of + this document. + + o Signaling MUST be able to provide authentication, integrity, + and protection against replay attacks. + + o Privacy and confidentiality are not required. Only + authentication is required to ensure that the signaling + messages are originating from the right place and have not been + modified in transit. + + o Protection of the identity of the data plane end-points (in + Failure Indication messages) is not required + + The consequences of poorly secured protection may increase the risk + of triggering recovery actions under false Failure Indication + messages, including LSP identifiers that are not under failure. Such + information could subsequently trigger the initiation of "false" + recovery actions while there are no reasons to do so. Additionally, + if the identification of the LSP is tampered with from a Failure + Indication message, recovery actions will involve nodes for which the + LSPs do not indicate any failure condition or for which no Failure + Indication message has been received. The consequences of such + actions is unpredictable and MAY lead to de-synchronisation between + the control and the data plane, as well as increase the risk of + misconnections. Moreover, the consequences of poorly applied + protection may increase the risk of misconnection. In particular, + when Extra Traffic is involved, it is easily possible to deliver the + wrong traffic to the wrong destination. Similarly, an intrusion that + sets up what appears to be a valid protection LSP and then causes a + fault may be able to divert traffic. + + Moreover, tampering with a routing information exchange may also have + an effect on traffic engineering. Therefore, any mechanisms used for + securing and authenticating the transmission of routing information + SHOULD be applied in the present context. + + + + + +Lang, et al. Standards Track [Page 19] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + +7. Contributors + + This document was the product of many individuals working together in + the CCAMP WG Protection and Restoration design team. The following + are the authors that contributed to this document: + + Deborah Brungard (AT&T) + 200 S. Laurel Ave. + Middletown, NJ 07748, USA + + EMail: dbrungard@att.com + + + Sudheer Dharanikota + + EMail: sudheer@ieee.org + + + Jonathan P. Lang (Sonos) + 223 East De La Guerra Street + Santa Barbara, CA 93101, USA + + EMail: jplang@ieee.org + + + Guangzhi Li (AT&T) + 180 Park Avenue, + Florham Park, NJ 07932, USA + + EMail: gli@research.att.com + + + Eric Mannie + + EMail: eric_mannie@hotmail.com + + + Dimitri Papadimitriou (Alcatel) + Francis Wellesplein, 1 + B-2018 Antwerpen, Belgium + + EMail: dimitri.papadimitriou@alcatel.be + + + + + + + + + +Lang, et al. Standards Track [Page 20] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + + Bala Rajagopalan + Microsoft India Development Center + Hyderabad, India + + EMail: balar@microsoft.com + + + Yakov Rekhter (Juniper) + 1194 N. Mathilda Avenue + Sunnyvale, CA 94089, USA + + EMail: yakov@juniper.net + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching + (GMPLS) Signaling Functional Description", RFC 3471, + January 2003. + + [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling + in MPLS Traffic Engineering (TE)", RFC 4201, October + 2005. + + [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4203, October 2005. + + [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC + 4204, October 2005. + + [RFC4205] Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate + System to Intermediate System (IS-IS) Extensions in + Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4205, October 2005. + + + + + + + + + + + + +Lang, et al. Standards Track [Page 21] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + +8.2. Informative References + + [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching + (GMPLS) Architecture", RFC 3945, October 2004. + + [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery + (Protection and Restoration) Terminology for Generalized + Multi-Protocol Label Switching (GMPLS)", RFC 4427, March + 2006. + +Editors' Addresses + + Jonathan P. Lang + Sonos, Inc. + 223 East De La Guerra Street + Santa Barbara, CA 93101 + + EMail: jplang@ieee.org + + + Bala Rajagopalan + Microsoft India Development Center + Hyderabad, India + + Ph: +91-40-5502-7423 + EMail: balar@microsoft.com + + + Dimitri Papadimitriou + Alcatel + Francis Wellesplein, 1 + B-2018 Antwerpen, Belgium + + Phone: +32 3 240-8491 + EMail: dimitri.papadimitriou@alcatel.be + + + + + + + + + + + + + + + + +Lang, et al. Standards Track [Page 22] + +RFC 4426 GMPLS Recovery Functional Specification March 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Lang, et al. Standards Track [Page 23] + |