diff options
Diffstat (limited to 'doc/rfc/rfc8400.txt')
| -rw-r--r-- | doc/rfc/rfc8400.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc8400.txt b/doc/rfc/rfc8400.txt new file mode 100644 index 0000000..f1a050e --- /dev/null +++ b/doc/rfc/rfc8400.txt @@ -0,0 +1,1179 @@ + + + + + + +Internet Engineering Task Force (IETF) H. Chen +Request for Comments: 8400 Huawei Technologies +Category: Standards Track A. Liu +ISSN: 2070-1721 Ciena + T. Saad + Cisco Systems + F. Xu + Verizon + L. Huang + China Mobile + June 2018 + + + Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection + +Abstract + + This document describes extensions to Resource Reservation Protocol - + Traffic Engineering (RSVP-TE) for locally protecting the egress + node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) + Traffic Engineered (TE) Label Switched Path (LSP). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8400. + +Copyright Notice + + Copyright (c) 2018 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 + (https://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. + + + + +Chen, et al. Standards Track [Page 1] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Local Protection of Egress Nodes . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Extensions to SERO . . . . . . . . . . . . . . . . . . . 5 + 4.1.1. Primary Egress Subobject . . . . . . . . . . . . . . 7 + 4.1.2. P2P LSP ID Subobject . . . . . . . . . . . . . . . . 8 + 5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 9 + 5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . 9 + 5.2. Primary Egress Behavior . . . . . . . . . . . . . . . . . 10 + 5.3. Backup Egress Behavior . . . . . . . . . . . . . . . . . 10 + 5.4. Transit Node and PLR Behavior . . . . . . . . . . . . . . 11 + 5.4.1. Signaling for One-to-One Protection . . . . . . . . . 12 + 5.4.2. Signaling for Facility Protection . . . . . . . . . . 12 + 5.4.3. Signaling for S2L Sub-LSP Protection . . . . . . . . 13 + 5.4.4. PLR Procedures during Local Repair . . . . . . . . . 14 + 6. Application Traffic Considerations . . . . . . . . . . . . . 14 + 6.1. A Typical Application . . . . . . . . . . . . . . . . . . 14 + 6.2. PLR Procedure for Applications . . . . . . . . . . . . . 17 + 6.3. Egress Procedures for Applications . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 9.2. Informative References . . . . . . . . . . . . . . . . . 19 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + +1. Introduction + + [RFC4090] describes two methods for locally protecting the transit + nodes of a P2P LSP: one-to-one and facility protection. [RFC4875] + specifies how these methods can be used to protect the transit nodes + of a P2MP LSP. These documents do not discuss the procedures for + locally protecting the egress node(s) of an LSP. + + This document fills that void and specifies extensions to RSVP-TE for + local protection of the egress node(s) of an LSP. "Egress node" and + "egress" are used interchangeably. + + + + + + + + +Chen, et al. Standards Track [Page 2] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + +1.1. Local Protection of Egress Nodes + + In general, locally protecting an egress node of an LSP means that + when the egress node fails, the traffic that the LSP carries will be + delivered to its destination by the direct upstream node of the + egress node to a backup egress node. Without protecting the egress + node of the LSP, when the egress node fails, the traffic will be lost + (i.e., the traffic will not be delivered to its destination). + + Figure 1 shows an example of using backup LSPs to locally protect + egress nodes L1 and L2 of a primary P2MP LSP starting from ingress + node R1. La and Lb are the designated backup egress nodes for + primary egress nodes L1 and L2, respectively. The backup LSP for + protecting L1 is from its upstream node R3 to backup egress node La, + and the backup LSP for protecting L2 is from R5 to Lb. + + ******* ******* S Source + [R2]-----[R3]-----[L1] CEx Customer Edge + */ &\ \ Rx Non-Egress + */ &\ \ Lx Egress + */ &\ [CE1] *** Primary LSP + */ &\ / &&& Backup LSP + */ &\ / + */ [La] + */ + */ + */ + */ ******** ******** ******* + [S]---[R1]------[R4]------[R5]-----[L2] + &\ \ + &\ \ + &\ [CE2] + &\ / + &\ / + [Lb] + + Figure 1: Backup LSP for Locally Protecting Egress + + During normal operations, the traffic carried by the P2MP LSP is sent + through R3 to L1, which delivers the traffic to its destination CE1. + When R3 detects the failure of L1, R3 switches the traffic to the + backup LSP to backup egress node La, which delivers the traffic to + CE1. The time for switching the traffic is within tens of + milliseconds. + + The exact mechanism by which the failure of the primary egress node + is detected by the upstream node R3 is out of the scope of this + document. + + + +Chen, et al. Standards Track [Page 3] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + In the beginning, the primary P2MP LSP from ingress node R1 to + primary egress nodes L1 and L2 is configured. It may be used to + transport the traffic from source S, which is connected to R1, to + destinations CE1 and CE2, which are connected to L1 and L2, + respectively. + + To protect the primary egress nodes L1 and L2, one configures on the + ingress node R1 a backup egress node for L1, another backup egress + node for L2, and other options. After the configuration, the ingress + node sends a Path message for the LSP with information such as the + Secondary Explicit Route Objects (SEROs), refer to Section 4.1, + containing the backup egress nodes for protecting the primary egress + nodes. + + After receiving the Path message with the information, the upstream + node of a primary egress node sets up a backup LSP to the + corresponding backup egress node for protecting the primary egress + node. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Terminology + + The following terminology is used in this document. + + LSP: Label Switched Path + + TE: Traffic Engineering + + P2MP: Point-to-Multipoint + + P2P: Point-to-Point + + LSR: Label Switching Router + + RSVP: Resource Reservation Protocol + + S2L: Source-to-Leaf + + SERO: Secondary Explicit Route Object + + RRO: Record Route Object + + + +Chen, et al. Standards Track [Page 4] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + BFD: Bidirectional Forwarding Detection + + VPN: Virtual Private Network + + L3VPN: Layer 3 VPN + + VRF: Virtual Routing and Forwarding + + LFIB: Label Forwarding Information Base + + UA: Upstream Assigned + + PLR: Point of Local Repair + + BGP: Border Gateway Protocol + + CE: Customer Edge + + PE: Provider Edge + +4. Protocol Extensions + +4.1. Extensions to SERO + + The Secondary Explicit Route Object (SERO) is defined in [RFC4873]. + The format of the SERO is reused. + + The SERO used for protecting a primary egress node of a primary LSP + may be added into the Path messages for the LSP and sent from the + ingress node of the LSP to the upstream node of the egress node. It + contains three subobjects. + + The first subobject (refer to Section 4.2 of [RFC4873]) indicates the + branch node that is to originate the backup LSP (to a backup egress + node). The branch node is typically the direct upstream node of the + primary egress node of the primary LSP. If the direct upstream node + does not support local protection against the failure of the primary + egress node, the branch node can be any (upstream) node on the + primary LSP. In this case, the backup LSP from the branch node to + the backup egress node protects against failures on the segment of + the primary LSP from the branch node to, and including, the primary + egress node. + + The second subobject is an Egress Protection subobject, which is a + PROTECTION object with a new C-Type (3). The format of the Egress + Protection subobject is defined as follows: + + + + + +Chen, et al. Standards Track [Page 5] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |L| Type | Length | Reserved | C-Type (3) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved |E-Flags| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optional Subobjects | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + E-Flags are defined for local protection of egress nodes. + + Bit 31 ("egress local protection" flag): It is the least significant + bit of the 32-bit word and is set to 1, which indicates that local + protection of egress nodes is desired. + + Bit 30 ("S2L sub-LSP backup desired" flag): It is the second least + significant bit of the 32-bit word and is set to 1, which + indicates an S2L sub-LSP (refer to [RFC4875]) is desired for + protecting an egress node of a P2MP LSP. + + The Reserved parts MUST be set to zero on transmission and MUST be + ignored on receipt. + + Four optional subobjects are defined: they are IPv4 and IPv6 primary + egress node subobjects as well as IPv4 and IPv6 P2P LSP ID + subobjects. IPv4 and IPv6 primary egress node subobjects indicate + the IPv4 and IPv6 address of the primary egress node, respectively. + IPv4 and IPv6 P2P LSP ID subobjects contain the information for + identifying IPv4 and IPv6 backup P2P LSP tunnels, respectively. + Their contents are described in Sections 4.1.1 through 4.1.2.2. They + have the following format: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved (zero) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Contents / Body of Subobject | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where Type is the type of a subobject and Length is the total size of + the subobject in bytes, including Type, Length, and Contents fields. + The Reserved field MUST be set to zero on transmission and MUST be + ignored on receipt. + + + + + +Chen, et al. Standards Track [Page 6] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + The third (final) subobject (refer to Section 4.2 of [RFC4873]) in + the SERO contains the egress node of the backup LSP, i.e., the + address of the backup egress node in the place of the merge node. + + After the upstream node of the primary egress node (a.k.a. the branch + node) receives the SERO and determines a backup egress node for the + primary egress node, it computes a path from itself to the backup + egress node and sets up a backup LSP along the path for protecting + the primary egress node according to the information in the + FAST_REROUTE object in the Path message. For example, if facility + protection is desired, it is provided for the primary egress node. + + The upstream node constructs a new SERO based on the SERO received + and adds the new SERO into the Path message for the backup LSP. The + new SERO also contains three subobjects as the SERO for the primary + LSP. The first subobject in the new SERO indicates the upstream + node, which may be copied from the first subobject in the SERO + received. The second subobject in the new SERO includes a primary + egress node, which indicates the address of the primary egress node. + The third one contains the backup egress node. + + The upstream node updates the SERO in the Path message for the + primary LSP. The Egress Protection subobject in the SERO contains a + subobject called a P2P LSP ID subobject, which contains the + information for identifying the backup LSP. The final subobject in + the SERO indicates the address of the backup egress node. + +4.1.1. Primary Egress Subobject + + There are two primary egress subobjects: the IPv4 primary egress + subobject and the IPv6 primary egress subobject. + + The Type of an IPv4 primary egress subobject is 1, and the body of + the subobject is given below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Address (4 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o IPv4 Address: The IPv4 address of the primary egress node. + + + + + + + + + +Chen, et al. Standards Track [Page 7] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + The Type of an IPv6 primary egress subobject is 2, and the body of + the subobject is shown below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Address (16 bytes) | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o IPv6 Address: The IPv6 address of the primary egress node. + +4.1.2. P2P LSP ID Subobject + + A P2P LSP ID subobject contains the information for identifying a + backup P2P LSP tunnel. + +4.1.2.1. IPv4 P2P LSP ID Subobject + + The Type of an IPv4 P2P LSP ID subobject is 3, and the body of the + subobject is shown below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P2P LSP Tunnel Egress IPv4 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved (MUST be zero) | Tunnel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Extended Tunnel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o P2P LSP Tunnel Egress IPv4 Address: The IPv4 address of the egress + node of the tunnel. + + o Tunnel ID (refer to [RFC4875] and [RFC3209]): A 16-bit identifier + that remains constant over the life of the tunnel and occupies the + least significant 16 bits of the 32-bit word. + + o Extended Tunnel ID (refer to [RFC4875] and [RFC3209]): A 4-byte + identifier that remains constant over the life of the tunnel. + + + + + + + + + + +Chen, et al. Standards Track [Page 8] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + +4.1.2.2. IPv6 P2P LSP ID Subobject + + The Type of an IPv6 P2P LSP ID subobject is 4, and the body of the + subobject is illustrated below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ P2P LSP Tunnel Egress IPv6 Address (16 bytes) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved (MUST be zero) | Tunnel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Extended Tunnel ID (16 bytes) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o P2P LSP Tunnel Egress IPv6 Address: The IPv6 address of the egress + node of the tunnel. + + o Tunnel ID (refer to [RFC4875] and [RFC3209]): A 16-bit identifier + that remains constant over the life of the tunnel and occupies the + least significant 16 bits of the 32-bit word. + + o Extended Tunnel ID (refer to [RFC4875] and [RFC3209]): A 16-byte + identifier that remains constant over the life of the tunnel. + +5. Egress Protection Behaviors + +5.1. Ingress Behavior + + To protect a primary egress node of an LSP, the ingress node MUST set + the "label recording desired" flag and the "node protection desired" + flag in the SESSION_ATTRIBUTE object. + + If one-to-one backup or facility backup is desired to protect a + primary egress node of an LSP, the ingress node MUST include a + FAST_REROUTE object and set the "one-to-one backup desired" or + "facility backup desired" flag, respectively. + + If S2L sub-LSP backup is desired to protect a primary egress node of + a P2MP LSP, the ingress node MUST set the "S2L sub-LSP backup + desired" flag in an SERO object. + + The decision to instantiate a backup egress node for protecting the + primary egress node of an LSP can be initiated by either the ingress + node or the primary egress node of that LSP, but not both. + + + + + + +Chen, et al. Standards Track [Page 9] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + A backup egress node MUST be configured on the ingress node of an LSP + to protect a primary egress node of the LSP if and only if the backup + egress node is not configured on the primary egress node (refer to + Section 5.2). + + The ingress node MUST send a Path message for the LSP with the + objects above and the SEROs for protecting egress nodes of the LSP if + protection of the egress nodes is desired. For each primary egress + node of the LSP to be protected, the ingress node MUST add an SERO + object into the Path message if the backup egress node, or some + options, are given. If the backup egress node is given, then the + final subobject in the SERO contains it; otherwise, the address in + the final subobject is zero. + +5.2. Primary Egress Behavior + + To protect a primary egress node of an LSP, a backup egress node MUST + be configured on the primary egress node of the LSP to protect the + primary egress node if and only if the backup egress node is not + configured on the ingress node of the LSP (refer to Section 5.1). + + If the backup egress node is configured on the primary egress node of + the LSP, the primary egress node MUST send its upstream node a Resv + message for the LSP with an SERO for protecting the primary egress + node. It sets the flags in the SERO in the same way as an ingress + node. + + If the LSP carries the service traffic with a service label, the + primary egress node sends its corresponding backup egress node the + information about the service label as a UA label (refer to + [RFC5331]) and the related forwarding. + +5.3. Backup Egress Behavior + + When a backup egress node receives a Path message for an LSP, it + determines whether the LSP is used for egress local protection by + checking the SERO with an Egress Protection subobject in the message. + If there is an Egress Protection subobject in the Path message for + the LSP and the "egress local protection" flag in the object is set + to 1, the LSP is the backup LSP for local protection of an egress + node. The primary egress node to be protected is in the primary + egress subobject in the SERO. + + When the backup egress node receives the information about a UA label + and its related forwarding from the primary egress node, it uses the + backup LSP label as a context label and creates a forwarding entry + using the information about the UA label and the related forwarding. + + + + +Chen, et al. Standards Track [Page 10] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + This forwarding entry is in a forwarding table for the primary egress + node. + + When the primary egress node fails, its upstream node switches the + traffic from the primary LSP to the backup LSP to the backup egress + node, which delivers the traffic to its receiver, such as a CE, using + the backup LSP label as a context label to get the forwarding table + for the primary egress node and using the service label as a UA label + to find the forwarding entry in the table to forward the traffic to + the receiver. + +5.4. Transit Node and PLR Behavior + + If a transit node of an LSP receives the Path message with the SEROs + and it is not an upstream node of any primary egress node of the LSP + as a branch node, it MUST forward them unchanged. + + If the transit node is the upstream node of a primary egress node to + be protected as a branch node, it determines the backup egress node, + obtains a path for the backup LSP, and sets up the backup LSP along + the path. If the upstream node receives the Resv message with an + SERO object, it MUST send its upstream node the Resv message without + the object. + + The PLR (which is the upstream node of the primary egress node a.k.a. + the branch node) MUST extract the backup egress node from the + respective SERO object in either a Path or a Resv message. If no + matching SERO object is found, the PLR tries to find the backup + egress node, which is not the primary egress node but has the same IP + address as the destination IP address of the LSP. + + Note that if a backup egress node is not configured explicitly for + protecting a primary egress node, the primary egress node and the + backup egress node SHOULD have the same local address configured, and + the cost to the local address on the backup egress node SHOULD be + much bigger than the cost to the local address on the primary egress + node. Thus, the primary egress node and backup egress node are + considered as a "virtual node". Note that the backup egress node is + different from this local address (e.g., from the primary egress + node's point of view). In other words, it is identified by an + address different from this local address. + + After obtaining the backup egress node, the PLR computes a backup + path from itself to the backup egress node and sets up a backup LSP + along the path. It excludes the segment including the primary egress + node to be protected when computing the path. The PLR sends the + primary egress node a Path message with an SERO for the primary LSP, + + + + +Chen, et al. Standards Track [Page 11] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + which indicates the backup egress node by the final subobject in the + SERO. The PLR puts an SERO into the Path messages for the backup + LSP, which indicates the primary egress node. + + The PLR MUST provide one-to-one backup protection for the primary + egress node if the "one-to-one backup desired" flag is set in the + message; otherwise, it MUST provide facility backup protection if the + "facility backup desired" flag is set. + + The PLR MUST set the protection flags in the RRO subobject for the + primary egress node in the Resv message according to the status of + the primary egress node and the backup LSP protecting the primary + egress node. For example, it sets the "local protection available" + flag and the "node protection" flag, which indicate that the primary + egress node is protected when the backup LSP is up and ready to + protect the primary egress node. + +5.4.1. Signaling for One-to-One Protection + + The behavior of the upstream node of a primary egress node of an LSP + (as a PLR) is the same as that of a PLR for one-to-one backup + described in [RFC4090], except that the upstream node (as a PLR) + creates a backup LSP from itself to a backup egress node in a session + different from the primary LSP. + + If the LSP is a P2MP LSP and a primary egress node of the LSP is also + a transit node (i.e., bud node), the upstream node of the primary + egress node (as a PLR) creates a backup LSP from itself to each of + the next hops of the primary egress node. + + When the PLR detects the failure of the primary egress node, it + switches the packets from the primary LSP to the backup LSP to the + backup egress node. For the failure of the bud node of a P2MP LSP, + the PLR also switches the packets to the backup LSPs to the bud + node's next hops, where the packets are merged into the primary LSP. + +5.4.2. Signaling for Facility Protection + + Except for backup LSP and downstream label, the behavior of the + upstream node of the primary egress node of a primary LSP (as a PLR) + follows the PLR behavior for facility backup, which is described in + [RFC4090]. + + For a number of primary P2P LSPs going through the same PLR to the + same primary egress node, the primary egress node of these LSPs MAY + be protected by one backup LSP from the PLR to the backup egress node + designated for protecting the primary egress node. + + + + +Chen, et al. Standards Track [Page 12] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + The PLR selects or creates a backup LSP from itself to the backup + egress node. If there is a backup LSP that satisfies the constraints + given in the Path message, then this one is selected; otherwise, a + new backup LSP to the backup egress node is created. + + After getting the backup LSP, the PLR associates the backup LSP with + a primary LSP for protecting its primary egress node. The PLR + records that the backup LSP is used to protect the primary LSP + against its primary egress node failure and MUST include an SERO + object in the Path message for the primary LSP. The object MUST + contain the backup LSP ID. It indicates that the primary egress node + MUST send the backup egress node the service label as a UA label and + also send the information about forwarding the traffic to its + destination using the label if there is a service carried by the LSP + and the primary LSP label as a UA label (if the label is not implicit + null). How a UA label is sent is out of scope for this document + (refer to [FRAMEWK]). + + When the PLR detects the failure of the primary egress node, it + redirects the packets from the primary LSP into the backup LSP to the + backup egress node and keeps the primary LSP label from the primary + egress node in the label stack if the label is not implicit null. + The backup egress node delivers the packets to the same destinations + as the primary egress node using the backup LSP label as a context + label and the labels under as UA labels. + +5.4.3. Signaling for S2L Sub-LSP Protection + + The S2L sub-LSP protection uses an S2L sub-LSP (refer to [RFC4875]) + as a backup LSP to protect a primary egress node of a P2MP LSP. The + PLR MUST determine to protect a primary egress node of a P2MP LSP via + S2L sub-LSP protection when it receives a Path message with the "S2L + sub-LSP backup desired" flag set. + + The PLR MUST set up the backup S2L sub-LSP to the backup egress node + and create and maintain its state in the same way as if setting up a + S2L sub-LSP defined in [RFC4875] from the signaling's point of view. + It computes a path for the backup LSP from itself to the backup + egress node, constructs and sends a Path message along the path, and + receives and processes a Resv message responding to the Path message. + + After receiving the Resv message for the backup LSP, the PLR creates + a forwarding entry with an inactive state or flag called "inactive + forwarding entry". This inactive forwarding entry is not used to + forward any data traffic during normal operations. + + + + + + +Chen, et al. Standards Track [Page 13] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + When the PLR detects the failure of the primary egress node, it + changes the forwarding entry for the backup LSP to "active". Thus, + the PLR forwards the traffic to the backup egress through the backup + LSP, which sends the traffic to its destination. + +5.4.4. PLR Procedures during Local Repair + + When the upstream node of a primary egress node of an LSP (as a PLR) + detects the failure of the primary egress node, it follows the + procedures defined in Section 6.5 of [RFC4090]. It SHOULD notify the + ingress node about the failure of the primary egress node in the same + way as a PLR notifies the ingress node about the failure of a transit + node. + + Moreover, the PLR MUST let the upstream part of the primary LSP stay + alive after the primary egress node fails by sending the Resv message + to its upstream node along the primary LSP. The downstream part of + the primary LSP from the PLR to the primary egress node SHOULD be + removed. When a bypass LSP from the PLR to a backup egress node + protects the primary egress node, the PLR MUST NOT send any Path + message for the primary LSP through the bypass LSP to the backup + egress node. + + In the local revertive mode, the PLR will re-signal each of the + primary LSPs that were routed over the restored resource once it + detects that the resource is restored. Every primary LSP + successfully re-signaled along the restored resource will be switched + back. + + Note that the procedure for protecting the primary egress node is + triggered on the PLR if the primary egress node failure is + determined. If link (from PLR to primary egress node) failure and + primary egress node alive are determined, then the link protection + procedure is triggered on the PLR. How to determine these is out of + scope for this document. + +6. Application Traffic Considerations + + This section focuses on an example with application traffic carried + by P2P LSPs. + +6.1. A Typical Application + + L3VPN is a typical application. Figure 2 below shows a simple VPN + that consists of two CEs, CE1 and CE2, connected to two PEs, R1 and + L1, respectively. There is a P2P LSP from R1 to L1, which is + represented by stars (****). This LSP is called the primary LSP. R1 + is the ingress node of the LSP and L1 is the (primary) egress node of + + + +Chen, et al. Standards Track [Page 14] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + the LSP. R1 sends the VPN traffic received from CE1 through the P2P + LSP to L1, which delivers the traffic to CE2. R1 sends the VPN + traffic with an LSP label and a VPN label via the LSP. When the + traffic reaches the egress node L1 of the LSP, L1 pops the LSP label + and uses the VPN label to deliver the traffic to CE2. + + In previous solutions based on ingress protection to protect the VPN + traffic against failure of the egress node L1 of the LSP, when the + egress node fails, the ingress node R1 of the LSP does the reroute + (refer to Figure 2). This solution entailed: + + 1. A multi-hop BFD session between ingress node R1 and egress node + L1 of the primary LSP. The BFD session is represented by dots + (....). + + 2. A backup LSP from ingress node R1 to backup egress node La, which + is indicated by ampersands (&&&&). + + 3. La sends R1 a VPN backup label and related information via BGP. + + 4. R1 has a VRF with two sets of routes for CE2: one set uses the + primary LSP and L1 as the next hop; the other uses the backup LSP + and La as the next hop. + + ***** ***** + CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP + one VPN */ : \ &&&& Backup LSP + */ .................: \ .... BFD Session + [CE1]--[R1] ..: [CE2] + &\ / + &\ / + [R4]-----[R5]-----[La](BGP sends R1 VPN backup label) + &&&&& &&&&& + + Figure 2: Protect Egress for L3VPN Traffic + + In normal operations, R1 sends the VPN traffic from CE1 through the + primary LSP with the VPN label received from L1 as the inner label to + L1, which delivers the traffic to CE2 using the VPN label. + + When R1 detects the failure of L1, R1 sends the traffic from CE1 via + the backup LSP with the VPN backup label received from La as the + inner label to La, which delivers the traffic to CE2 using the VPN + backup label. + + + + + + + +Chen, et al. Standards Track [Page 15] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + The solution defined in this document that uses egress local + protection for protecting L3VPN traffic entails (refer to Figure 3): + + 1. A BFD session between R3 (i.e., upstream node of L1) and egress + node L1 of the primary LSP. This is different from the BFD + session in Figure 2, which is a multi-hop between ingress node R1 + and egress node L1. The PLR R3 is closer to L1 than the ingress + node R1. It may detect the failure of the egress node L1 faster + and more reliably. Therefore, this solution can provide faster + protection for failure of an egress node. + + 2. A backup LSP from R3 to backup egress node La. This is different + from the backup LSP in Figure 2, which is an end-to-end LSP from + ingress node R1 to backup egress node La. + + 3. Primary egress node L1 sends backup egress node La the VPN label + as a UA label and also sends related information. The backup + egress node La uses the backup LSP label as a context label and + creates a forwarding entry using the VPN label in an LFIB for the + primary egress node L1. + + 4. L1 and La are virtualized as one node (or address). R1 has a VRF + with one set of routes for CE2, using the primary LSP from R1 to + L1 and a virtualized node as the next hop. This can be achieved + by configuring the same local address on L1 and La using the + address as a destination of the LSP and BGP next hop for the VPN + traffic. The cost to L1 is configured to be less than the cost + to La. + + ***** ***** + CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP + one VPN */ &\:.....: \ &&&& Backup LSP + */ &\ \ .... BFD Session + [CE1]--[R1] &\ [CE2] + &\ / + &\ / + [La](VPN label from L1 as a UA label) + + Figure 3: Locally Protect Egress for L3VPN Traffic + + In normal operations, R1 sends the VPN traffic from CE1 via the + primary LSP with the VPN label as an inner label to L1, which + delivers the traffic to CE2 using the VPN label. + + When the primary egress node L1 fails, its upstream node R3 detects + it and switches the VPN traffic from the primary LSP to the backup + LSP to La, which delivers the traffic to CE2 using the backup LSP + + + + +Chen, et al. Standards Track [Page 16] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + label as a context label to get the LFIB for L1 and the VPN label as + a UA label to find the forwarding entry in the LFIB to forward the + traffic to CE2. + +6.2. PLR Procedure for Applications + + When the PLR gets a backup LSP from itself to a backup egress node + for protecting a primary egress node of a primary LSP, it includes an + SERO object in the Path message for the primary LSP. The object + contains the ID information of the backup LSP and indicates that the + primary egress node sends the backup egress node the application + traffic label (e.g., the VPN label) as a UA label when needed. + +6.3. Egress Procedures for Applications + + When a primary egress node of an LSP sends the ingress node of the + LSP a label for an application such as a VPN label, it sends the + label (as a UA label) to the backup egress node for protecting the + primary egress node. Exactly how the label is sent is out of scope + for this document. + + When the backup egress node receives a UA label from the primary + egress node, it adds a forwarding entry with the label into the LFIB + for the primary egress node. When the backup egress node receives a + packet from the backup LSP, it uses the top label as a context label + to find the LFIB for the primary egress node and uses the inner label + to deliver the packet to the same destination as the primary egress + node according to the LFIB. + +7. Security Considerations + + This document builds upon existing work, specifically, the security + considerations of [RFC4090], [RFC4875], [RFC3209], and [RFC2205] + continue to apply. Additionally, protecting a primary egress node of + a P2P LSP carrying service traffic through a backup egress node + requires out-of-band communication between the primary egress node + and the backup egress node in order for the primary egress node to + convey a service label as a UA label and also convey its related + forwarding information to the backup egress node. It is important to + confirm that the identifiers used to identify the primary and backup + egress nodes in the LSP are verified to match with the identifiers + used in the out-of-band protocol (such as BGP). + + + + + + + + + +Chen, et al. Standards Track [Page 17] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + +8. IANA Considerations + + IANA maintains a registry called "Class Names, Class Numbers, and + Class Types" under "Resource Reservation Protocol (RSVP) Parameters". + IANA has assigned a new C-Type under the PROTECTION object class, + Class Number 37: + + Value Description Definition + ----- ----------- ---------- + 3 Egress Protection Section 4.1 + + IANA has created and now maintains a registry under the PROTECTION + object class (Class Number 37) and Egress Protection (C-Type 3). + Initial values for the registry are given below. Future assignments + are to be made through IETF Review [RFC8216]. + + Value Description Definition + ----- ----------- ---------- + 0 Reserved + 1 IPv4_PRIMARY_EGRESS Section 4.1.1 + 2 IPv6_PRIMARY_EGRESS Section 4.1.1 + 3 IPv4_P2P_LSP_ID Section 4.1.2 + 4 IPv6_P2P_LSP_ID Section 4.1.2 + 5-127 Unassigned + 128-255 Reserved + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + <https://www.rfc-editor.org/info/rfc3209>. + + [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast + Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, + DOI 10.17487/RFC4090, May 2005, + <https://www.rfc-editor.org/info/rfc4090>. + + [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, + "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, + May 2007, <https://www.rfc-editor.org/info/rfc4873>. + + + +Chen, et al. Standards Track [Page 18] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + + [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. + Yasukawa, Ed., "Extensions to Resource Reservation + Protocol - Traffic Engineering (RSVP-TE) for Point-to- + Multipoint TE Label Switched Paths (LSPs)", RFC 4875, + DOI 10.17487/RFC4875, May 2007, + <https://www.rfc-editor.org/info/rfc4875>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", + RFC 8216, DOI 10.17487/RFC8216, August 2017, + <https://www.rfc-editor.org/info/rfc8216>. + +9.2. Informative References + + [FRAMEWK] Shen, Y., Jeganathan, J., Decraene, B., Gredler, H., + Michel, C., Chen, H., and Y. Jiang, "MPLS Egress + Protection Framework", Work in Progress, draft-ietf-mpls- + egress-protection-framework-00, January 2018. + + [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 + Functional Specification", RFC 2205, DOI 10.17487/RFC2205, + September 1997, <https://www.rfc-editor.org/info/rfc2205>. + + [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream + Label Assignment and Context-Specific Label Space", + RFC 5331, DOI 10.17487/RFC5331, August 2008, + <https://www.rfc-editor.org/info/rfc5331>. + +Acknowledgements + + The authors would like to thank Richard Li, Nobo Akiya, Lou Berger, + Jeffrey Zhang, Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, + Michael Yue, Daniel King, Rob Rennison, Neil Harrison, Kannan + Sampath, Yimin Shen, Ronhazli Adam, and Quintin Zhao for their + valuable comments and suggestions on this document. + + + + + + + + + + + + +Chen, et al. Standards Track [Page 19] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + +Contributors + + The following people contributed significantly to the content of this + document and should be considered coauthors: + + Ning So + Tata + Email: ningso01@gmail.com + + Mehmet Toy + Verizon + Email: mehmet.toy@verizon.com + + Lei Liu + Fujitsu + Email: lliu@us.fujitsu.com + + Zhenbin Li + Huawei Technologies + Email: lizhenbin@huawei.com + + We also acknowledge the contributions of the following individuals: + + Boris Zhang + Telus Communications + Email: Boris.Zhang@telus.com + + Nan Meng + Huawei Technologies + Email: mengnan@huawei.com + + Prejeeth Kaladharan + Huawei Technologies + Email: prejeeth@gmail.com + + Vic Liu + China Mobile + Email: liu.cmri@gmail.com + + + + + + + + + + + + + +Chen, et al. Standards Track [Page 20] + +RFC 8400 RSVP LSP Egress Protection June 2018 + + +Authors' Addresses + + Huaimo Chen + Huawei Technologies + Boston, MA + United States of America + + Email: huaimo.chen@huawei.com + + + Autumn Liu + Ciena + United States of America + + Email: hliu@ciena.com + + + Tarek Saad + Cisco Systems + + Email: tsaad@cisco.com + + + Fengman Xu + Verizon + 2400 N. Glenville Dr + Richardson, TX 75082 + United States of America + + Email: fengman.xu@verizon.com + + + Lu Huang + China Mobile + No.32 Xuanwumen West Street, Xicheng District + Beijing 100053 + China + + Email: huanglu@chinamobile.com + + + + + + + + + + + + +Chen, et al. Standards Track [Page 21] + |