--- 1/draft-chen-mpls-p2mp-ingress-protection-10.txt 2014-02-14 09:14:42.098800789 -0800 +++ 2/draft-chen-mpls-p2mp-ingress-protection-11.txt 2014-02-14 09:14:42.162802342 -0800 @@ -1,19 +1,19 @@ Internet Engineering Task Force H. Chen, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track R. Torvi, Ed. -Expires: June 29, 2014 Juniper Networks - December 26, 2013 +Expires: August 18, 2014 Juniper Networks + February 14, 2014 Extensions to RSVP-TE for LSP Ingress Local Protection - draft-chen-mpls-p2mp-ingress-protection-10.txt + draft-chen-mpls-p2mp-ingress-protection-11.txt Abstract This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. Status of this Memo @@ -23,25 +23,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 29, 2014. + This Internet-Draft will expire on August 18, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -56,43 +56,43 @@ 3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 4 3.1. Backup and Source Detect Failure . . . . . . . . . . . . . 4 3.2. Backup Detects Failure . . . . . . . . . . . . . . . . . . 5 3.3. Source Detects Failure . . . . . . . . . . . . . . . . . . 5 3.4. Next Hops Detect Failure . . . . . . . . . . . . . . . . . 5 3.5. Comparing Different Detection Modes . . . . . . . . . . . 6 4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 6 4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 7 4.2. Forwarding State on Next Hops . . . . . . . . . . . . . . 7 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7 - 5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 7 + 5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 8 5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address . . . . . 10 5.1.2. Subobject: Ingress IPv4/IPv6 Address . . . . . . . . . 11 - 5.1.3. Subobject: Traffic Descriptor . . . . . . . . . . . . 12 + 5.1.3. Subobject: Traffic Descriptor . . . . . . . . . . . . 11 5.1.4. Subobject: Label-Routes . . . . . . . . . . . . . . . 12 6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13 - 6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 14 - 6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 15 + 6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 13 + 6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 14 6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 15 - 6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 16 + 6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 15 6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 16 - 6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 18 - 6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 18 + 6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 17 + 6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 17 6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 20 6.3.3. Failure Detection . . . . . . . . . . . . . . . . . . 21 - 6.4. Merge Point Behavior . . . . . . . . . . . . . . . . . . . 22 + 6.4. Merge Point Behavior . . . . . . . . . . . . . . . . . . . 21 6.5. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 22 - 6.5.1. Revert to Primary Ingress . . . . . . . . . . . . . . 23 + 6.5.1. Revert to Primary Ingress . . . . . . . . . . . . . . 22 6.5.2. Global Repair by Backup Ingress . . . . . . . . . . . 23 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 1. Co-authors Ning So, Autumn Liu, Alia Atlas, Yimin Shen, Fengman Xu, Mehmet Toy, @@ -111,50 +111,53 @@ this is that the backup LSP may reserve additional network bandwidth. This specification defines a simple extension to RSVP-TE for local protection of the ingress node of a P2MP or P2P LSP. 2.1. An Example of Ingress Local Protection Figure 1 shows an example of using a backup P2MP LSP to locally protect the ingress of a primary P2MP LSP, which is from ingress R1 to three egresses: L1, L2 and L3. The backup LSP is from backup - ingress Ra to the next hops R2 and R4 of ingress R1. The backup - egress must be only one logical hop away from the ingress. + ingress Ra to the next hops R2 and R4 of ingress R1. [R2]******[R3]*****[L1] * | **** Primary LSP * | ---- Backup LSP * / .... BFD Session * / $ Link [R1]*******[R4]****[R5]*****[L2] $ $ . / / * $ $ . / / * [S] . / / * $ . / / * $ ./ / * [Ra]----[Rb] [L3] Figure 1: Backup P2MP LSP for Locally Protecting Ingress Source S may send the traffic simultaneously to both primary ingress R1 and backup ingress Ra. R1 imports the traffic into the primary LSP. Ra normally does not put the traffic into the backup LSP. - Ra must be able to detect the failure of R1 and switch the traffic + Ra should be able to detect the failure of R1 and switch the traffic within 10s of ms. The exact method by which Ra does so is out of scope. Different options are discussed in this draft. When Ra detects the failure of R1, it imports the traffic from S into the backup LSP to R1's next hops R2 and R4, where the traffic is merged into the primary LSP, and then sent to egresses L1, L2 and L3. + Note that the backup egress must be one logical hop away from the + ingress. A logical hop is a direct link or a tunnel such as a GRE + tunnel, over which RSVP-TE messages may be exchanged. + 2.2. Ingress Local Protection with FRR Through using the ingress local protection and the FRR, we can locally protect the ingress node, all the links and the intermediate nodes of an LSP. The traffic switchover time is within tens of milliseconds whenever the ingress, any of the links and the intermediate nodes of the LSP fails. The ingress node of the LSP can be locally protected through using the ingress local protection. All the links and all the intermediate @@ -235,24 +238,24 @@ hops selects the traffic from the primary ingress and sends the traffic to the destinations of the LSP. When each of the next hops detects the failure of the primary ingress, it switches to receive the traffic from the backup ingress and then sends the traffic to the destinations. 3.5. Comparing Different Detection Modes +----------+--------------+----------------+--------+-------------------+ -|Protection|Traffic Always|Backup Ingress |Next-Hop|Incorrect Failure | -|Mode |Sent to |Activation of |Select |Detection Cause | -| |Backup Ingress|Forwarding Entry|Stream |Traffic Duplication| -| | | | |(Ingress does FRR) | +|\_Behavior|Traffic Always|Backup Ingress |Next-Hop|Incorrect Failure | +| \______ |Sent to |Activation of |Select |Detection Cause | +|Detection\|Backup Ingress|Forwarding Entry|Stream |Traffic Duplication| +|Mode | | | |(Ingress does FRR) | +----------+--------------+----------------+--------+-------------------+ |Backup- | | | | | |Source- | No | Yes | No | No | |Detect | | | | | +----------+--------------+----------------+--------+-------------------+ |Backup- | Yes | Yes | No | Yes | |Detect | | | | | +----------+--------------+----------------+--------+-------------------+ |Source- | No | No | No | No | |Detect | | (Always Active)| | | @@ -264,51 +267,53 @@ | | | | |can mitigate) | +----------+--------------+----------------+--------+-------------------+ A primary goal of failure detection and FRR protection is to avoid traffic duplication, particularly along the P2MP. A reasonable assumption when this ingress protection is in use is that the ingress is also trying to provide link and node protection. When the failure cannot be accurately identified as that of the ingress, this can lead to the ingress sending traffic on bypass to the next-next-hop(s) for node-protection while the backup ingress is sending traffic to its - next-hop(s) if Next-Hop-Detect mode is used. RSVP Path messages sent - through the bypass tunnels may help to eventually resolve this by - changing the PHOP through which traffic should be received. + next-hop(s) if Next-Hop-Detect mode is used. RSVP Path messages from + the bypass may help to eventually resolve this by removing the + forwarding entry for receiving the traffic from the next-hop. 4. Backup Forwarding State Before the primary ingress fails, the backup ingress is responsible for creating the necessary backup LSPs to the next hops of the ingress. These LSPs might be multiple bypass P2P LSPs that avoid the ingress. Alternately, the backup ingress could choose to use a single backup P2MP LSP as a bypass or detour to protect the primary ingress of a primary P2MP LSP. - The backup ingress may be off-path (i.e., not a next-hop of the - primary ingress) or on-path (i.e., a next-hop of the primary - ingress). If the backup ingress is on-path, the primary forwarding - state associated with the primary LSP SHOULD be clearly separated - from the backup LSP(s) state. Specifically in Backup-Detect mode, - the backup ingress will receive traffic from the primary ingress and - from the traffic source; only the former should be forwarded until - failure is detected even if the backup ingress is the only next-hop. + The backup ingress may be off-path or on-path of an LSP. When a + backup ingress is not any node of the LSP, we call the backup ingress + is off-path. When a backup ingress is a next-hop of the primary + ingress of the LSP, we call it is on-path. If the backup ingress is + on-path, the primary forwarding state associated with the primary LSP + SHOULD be clearly separated from the backup LSP(s) state. + Specifically in Backup-Detect mode, the backup ingress will receive + traffic from the primary ingress and from the traffic source; only + the former should be forwarded until failure is detected even if the + backup ingress is the only next-hop. 4.1. Forwarding State for Backup LSP A forwarding entry for a backup LSP is created on the backup ingress after the LSP is set up. Depending on the failure-detection mode - (e.g., source-detect), it may be set up to forward received traffic - or simply be inactive (e.g., backup-detect) until required. In - either case, when the primary ingress fails, this forwarding entry is - used to import the traffic into the backup LSP to the primary - ingress' next hops, where the traffic is merged into the primary LSP. + (e.g., source-detect), it may be used to forward received traffic or + simply be inactive (e.g., backup-detect) until required. In either + case, when the primary ingress fails, this forwarding entry is used + to import the traffic into the backup LSP to the next hops of the + primary ingress, where the traffic is merged into the primary LSP. The forwarding entry for a backup LSP is a local implementation issue. In one device, it may have an inactive flag. This inactive forwarding entry is not used to forward any traffic normally. When the primary ingress fails, it is changed to active, and thus the traffic from the source is imported into the backup LSP. 4.2. Forwarding State on Next Hops When Next-Hop-Detect is used, a forwarding entry for a backup LSP is @@ -332,33 +337,31 @@ Class-Num = TBD C-Type = TBD 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (bytes) | Class-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Secondary LSP ID | Flags | Options | DM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | ~ (Subobjects) ~ - | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags 0x01 Ingress local protection available 0x02 Ingress local protection in use 0x04 Bandwidth protection Options 0x01 Revert to Ingress - 0x02 Force to Backup + 0x02 Ingress-Proxy/Relay-Message 0x04 P2MP Backup DM (Detection Mode) 0x00 Backup-Source-Detect 0x01 Backup-Detect 0x02 Source-Detect 0x03 Next-Hop-Detect For backward compatible, the two high-order bits of the Class-Num in the object are set as follows: @@ -395,24 +398,23 @@ protected LSP against the primary ingress failure. The options are used by the primary ingress to specify the desired behavior to the backup ingress and next-hops. o Revert to Ingress: The primary ingress sets this option indicating that the traffic for the primary LSP successfully re-signaled will be switched back to the primary ingress from the backup ingress when the primary ingress is restored. - o Force to Backup: If the backup ingress receives an object with - this option set for an LSP, it should activate its backup - forwarding state; otherwise, it should deactivate its backup - forwarding state. + o Ingress-Proxy/Relay-Message: This option is set to one indicating + that Ingress-Proxy method is used. It is set to zero indicating + that Relay-Message method is used. o P2MP Backup: This option is set to ask for the backup ingress to use P2MP backup LSP to protect the primary ingress. Note that one spare bit of the flags in the FAST-REROUTE object can be used to indicate whether P2MP or P2P backup LSP is desired for protecting an ingress and intermediate node. The DM (Detection Mode) is used by the primary ingress to specify a desired failure detection mode. @@ -441,143 +443,128 @@ the sub object for Backup Ingress IPv4/IPv6 Address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved (zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 0x01 Backup Ingress IPv4 Address + Type: TBD-1 Backup Ingress IPv4 Address Length: Total length of the subobject in bytes, including the Type and Length fields. The Length is always 8. Reserved: Reserved two bytes are set to zeros. IPv4 address: A 32-bit unicast, host address. 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 (zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IPv6 address (16 bytes) ~ - | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 0x02 Backup Ingress IPv6 Address + Type: TBD-2 Backup Ingress IPv6 Address Length: Total length of the subobject in bytes, including the Type and Length fields. The Length is always 20. Reserved: Reserved two bytes are set to zeros. - IPv6 address: A 128-bit unicast, host address. - This sub object is optional. If there is not any Backup Ingress - Address sub object in the INGRESS_PROTECTION object of the PATH - message to the backup ingress, the backup ingress SHOULD use the - destination address of the message as the backup ingress address. - 5.1.2. Subobject: Ingress IPv4/IPv6 Address The INGRESS_PROTECTION object in a PATH message from the primary ingress to the backup ingress may have an Ingress IPv4/IPv6 Address sub object containing an IPv4/IPv6 address belonging to the primary ingress. The sub object has 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 (zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 0x03 Ingress IPv4 Address + Type: TBD-3 Ingress IPv4 Address Length: Total length of the subobject in bytes, including the Type and Length fields. The Length is always 8. Reserved: Reserved two bytes are set to zeros. IPv4 address: A 32-bit unicast, host address. 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 (zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IPv6 address (16 bytes) ~ - | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 0x04 Backup Ingress IPv6 Address + Type: TBD-4 Backup Ingress IPv6 Address Length: Total length of the subobject in bytes, including the Type and Length fields. The Length is always 20. Reserved: Reserved two bytes are set to zeros. IPv6 address: A 128-bit unicast, host address. - This sub object is optional. If there is not any Ingress Address sub - object in the INGRESS_PROTECTION object of the PATH message to the - backup ingress, the backup ingress SHOULD use the address in the - RSVP_HOP object of the message as the ingress address. - 5.1.3. Subobject: Traffic Descriptor The INGRESS_PROTECTION object in a PATH message from the primary ingress to the backup ingress may have a Traffic Descriptor sub object describing the traffic to be mapped to the backup LSP on the backup ingress for locally protecting the primary ingress. The sub object has 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 (zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Element 1 | ~ ~ | Traffic Element n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 0x05/06/07 Interface/IPv4/6 Prefix + Type: TBD-5/TBD-6/TBD-7 Interface/IPv4/6 Prefix Length: Total length of the subobject in bytes, including the Type and Length fields. Reserved: Reserved two bytes are set to zeros. The Traffic Descriptor sub object may contain multiple Traffic Elements of same type as follows. - o Interface Traffic (Type 5): Each of the Traffic Elements is a 32 - bit index of an interface, from which the traffic is imported into - the backup LSP. + o Interface Traffic (Type TBD-5): Each of the Traffic Elements is a + 32 bit index of an interface, from which the traffic is imported + into the backup LSP. - o IPv4/6 Prefix Traffic (Type 6/7): Each of the Traffic Elements is - an IPv4/6 prefix, containing an 8-bit prefix length followed by an - IPv4/6 address prefix, whose length, in bits, was specified by the - prefix length, padded to a byte boundary. + o IPv4/6 Prefix Traffic (Type TBD-6/TBD-7): Each of the Traffic + Elements is an IPv4/6 prefix, containing an 8-bit prefix length + followed by an IPv4/6 address prefix, whose length, in bits, was + specified by the prefix length, padded to a byte boundary. 5.1.4. Subobject: Label-Routes The INGRESS_PROTECTION object in a PATH message from the primary ingress to the backup ingress will have a Label-Routes sub object containing the labels and routes that the next hops of the ingress use. The sub object has 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 (zeros) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | ~ (Subobjects) ~ - | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 0x08 Label-Routes + Type: TBD-8 Label-Routes Length: Total length of the subobject in bytes, including the Type and Length fields. Reserved: Reserved two bytes are set to zeros. The Subobjects in the Label-Routes are copied from the Subobjects in the RECORD_ROUTE objects contained in the RESV messages that the primary ingress receives from its next hops for the protected LSP. They MUST contain the first hops of the LSP, each of which is paired with its label. @@ -616,23 +603,20 @@ and 4) less control traffic. 6.1.2. Proxy-Ingress Method Conceptually, a proxy ingress is created that starts the RSVP signaling. The explicit path of the LSP goes from the proxy ingress to the backup ingress and then to the real ingress. The behavior and signaling for the proxy ingress is done by the real ingress; the use of a proxy ingress address avoids problems with loop detection. - The backup ingress must be only one logical hop away from the - ingress, whether that be via a direct link or a tunnel. - [ traffic source ] *** Primary LSP $ $ --- Backup LSP $ $ $$ Link $ $ [ proxy ingress ] [ backup ] [ & ingress ] | * | *****[ MP ]----| Figure 2: Example Protected LSP with Proxy Ingress Node @@ -641,24 +625,24 @@ associated labels. This is accomplished by having the RSVP PATH and RESV messages go through the backup ingress, although the forwarding path need not go through the backup ingress. If the backup ingress fails, the ingress simply removes the INGRESS-PROTECTION object and forwards the PATH messages to the LSP's next-hop(s). If the ingress has its LSP configured for ingress protection, then the ingress can add the backup ingress and itself to the ERO and start forwarding the PATH messages to the backup ingress. Slightly different behavior can apply for the on-path and off-path - cases. In the on-path case, the backup ingress is already the only - immediate node after the ingress for the LSP. In the off-path, the - backup ingress is not the immediate node after the ingress for all - associated sub-LSPs. + cases. In the on-path case, the backup ingress is a next hop node + after the ingress for the LSP. In the off-path, the backup ingress + is not any next-hop node after the ingress for all associated sub- + LSPs. The key advantage of this approach is that it minimizes the special handling code requires. Because the backup ingress is on the signaling path, it can receive various notifications. It easily has access to all the PATH messages needed for modification to be sent to refresh control-plane state after a failure. 6.1.3. Comparing Two Methods +-------+-----------+------+--------+-----------------+---------+ @@ -670,21 +654,21 @@ |Relay- | No |Yes | No | No | Yes- | |Message| | | | | | +-------+-----------+------+--------+-----------------+---------+ |Proxy- | Yes |Yes- | Yes | Yes | Yes | |Ingress| | | | | | +-------+-----------+------+--------+-----------------+---------+ 6.2. Ingress Behavior The primary ingress must be configured with four pieces of - information for ingress protect. + information for ingress protection. o Backup Ingress Address: The primary ingress must know an IP address for it to be included in the INGRESS-PROTECTION object. o Failure Detection Mode: The primary ingress must know what failure detection mode is to be used: Backup-Source-Detect, Backup-Detect, Source-Detect, or Next-Hop-Detect. o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The Proxy-Ingress-Id is only used in the Record Route Object for @@ -707,24 +691,23 @@ With this additional information, the primary ingress can create and signal the necessary RSVP extensions to support ingress protection. 6.2.1. Relay-Message Method To protect the ingress of an LSP, the ingress does the following after the LSP is up. 1. Select a PATH message. - 2. If the backup ingress is not a next hop of the primary ingress - (i.e., off-path case), then send the backup ingress a PATH - message with the content from the selected PATH message and an - INGRESS-PROTECTION object; else (the backup ingress is a next + 2. If the backup ingress is off-path, then send the backup ingress a + PATH message with the content from the selected PATH message and + an INGRESS-PROTECTION object; else (the backup ingress is a next hop, i.e., on-path case) add an INGRESS-PROTECTION object into the existing PATH message to the backup ingress (i.e., the next hop). The INGRESS-PROTECTION object contains the Traffic- Descriptor sub-object, the Backup Ingress Address sub-object and the Label-Routes sub-object. The DM (Detection Mode) in the object is set to indicate the failure detection mode desired. The flags is set to indicate whether a Backup P2MP LSP is desired. If not yet allocated, allocate a second LSP-ID to be used in the INGRESS-PROTECTION object. The Label-Routes sub- object contains the next-hops of the ingress and their labels. @@ -758,22 +741,20 @@ Include the Backup Ingress Address (IPv4 or IPv6) sub-object and the Traffic-Descriptor sub-object. Set the control-options to indicate the failure detection mode desired. Set or clear the flag indicating that a Backup P2MP LSP is desired. 6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path message. Indicate whether one-to-one backup is desired. Indicate whether facility backup is desired. 7. The RSVP PATH message is sent to the backup node as normal. - Since the backup ingress node must be only one logical hop away - from the ingress, normal RSVP signaling can be used. If the ingress detects that it can't communicate with the backup ingress, then the ingress should instead send the PATH message to the next-hop indicated in the ERO computed in step 1. Once the ingress detects that it can communicate with the backup ingress, the ingress SHOULD follow the steps 1-7 to obtain ingress failure protection. When the ingress node receives an RSVP PATH message with an INGRESS- PROTECTION object and the object specifies that node as the ingress node and the PHOP as the backup ingress node, the ingress node SHOULD @@ -781,42 +762,43 @@ and, if it is not the Next-Hop-Detect, then the ingress node SHOULD remove the INGRESS-PROTECTION object from the PATH message before sending it out. Additionally, the ingress node must store that it will install ingress forwarding state for the LSP rather than midpoint forwarding. When an RSVP RESV message is received by the ingress, it uses the NHOP to determine whether the message is received from the backup ingress or from a different node. The stored associated PATH message contains an INGRESS-PROTECTION object that identifies the backup - ingres node. If the RESV message is not from the backup node, then + ingress node. If the RESV message is not from the backup node, then ingress forwarding state should be set up, and the INGRESS-PROTECTION object MUST be added to the RESV before it is sent to the NHOP, which should be the backup node. If the RESV message is from the backup node, then the LSP should be considered available for use. If the backup ingress node is on the forwarding path, then a RESV is received with an INGRESS-PROTECTION object and an NHOP that matches the backup ingress. In this case, the ingress node's address will not appear after the backup ingress in the RRO. The ingress node should set up ingress forwarding state, just as is done if the LSP weren't ingress-node protected. 6.3. Backup Ingress Behavior An LER determines that the ingress local protection is requested for an LSP if the INGRESS_PROTECTION object is included in the PATH message it receives for the LSP. The LER can further determine that it is the backup ingress if one of its addresses is in the Backup - Ingress Address sub-object of the INGRESS-PROTECTION object. In - addition, the LER determines that it is off-path if it is not a next - hop of the primary ingress. + Ingress Address sub-object of the INGRESS-PROTECTION object. The LER + as the backup ingress will assume full responsibility of the ingress + after the primary ingress fails. In addition, the LER determines + that it is off-path if it is not a next hop of the primary ingress. 6.3.1. Backup Ingress Behavior in Off-path Case The backup ingress considers itself as a PLR and the primary ingress as its next hop and provides a local protection for the primary ingress. It behaves very similarly to a PLR providing fast-reroute where the primary ingress is considered as the failure-point to protect. Where not otherwise specified, the behavior given in [RFC4090] for a PLR should apply. @@ -848,22 +830,22 @@ protection available", "Ingress local protection in use", and "bandwidth protection". If the backup ingress doesn't have a backup LSP tunnel to all the merge points, it SHOULD clear "Ingress local protection available". [Editor Note: It is possible to indicate the number or which are unprotected via a sub-object if desired.] When the primary ingress fails, the backup ingress redirects the traffic from a source into the backup P2P LSPs or the backup P2MP LSP - transmitting the traffic to the primary ingress' next hops, where the - traffic is merged into the protected LSP. + transmitting the traffic to the next hops of the primary ingress, + where the traffic is merged into the protected LSP. In this case, the backup ingress keeps the PATH message with the INGRESS_PROTECTION object received from the primary ingress and the RESV message with the INGRESS_PROTECTION object to be sent to the primary ingress. The backup ingress sets the "local protection in use" flag in the RESV message, indicating that the backup ingress is actively redirecting the traffic into the backup P2P LSPs or the backup P2MP LSP for locally protecting the primary ingress failure. Note that the RESV message with this piece of information will not be