| draft-ietf-teas-rsvp-ingress-protection-06.txt | draft-ietf-teas-rsvp-ingress-protection-07.txt | |||
|---|---|---|---|---|
| Internet Engineering Task Force H. Chen, Ed. | Internet Engineering Task Force H. Chen, Ed. | |||
| Internet-Draft Huawei Technologies | Internet-Draft Huawei Technologies | |||
| Intended status: Experimental R. Torvi, Ed. | Intended status: Experimental R. Torvi, Ed. | |||
| Expires: October 17, 2016 Juniper Networks | Expires: February 9, 2017 Juniper Networks | |||
| April 15, 2016 | August 8, 2016 | |||
| Extensions to RSVP-TE for LSP Ingress Local Protection | Extensions to RSVP-TE for LSP Ingress Local Protection | |||
| draft-ietf-teas-rsvp-ingress-protection-06.txt | draft-ietf-teas-rsvp-ingress-protection-07.txt | |||
| Abstract | Abstract | |||
| This document describes extensions to Resource Reservation Protocol - | This document describes extensions to Resource Reservation Protocol - | |||
| Traffic Engineering (RSVP-TE) for locally protecting the ingress node | Traffic Engineering (RSVP-TE) for locally protecting the ingress node | |||
| of a Traffic Engineered (TE) Label Switched Path (LSP), which is a | of a Traffic Engineered (TE) Label Switched Path (LSP), which is a | |||
| Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. | Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. | |||
| Status of this Memo | Status of this Memo | |||
| skipping to change at page 1, line 34 ¶ | skipping to change at page 1, line 34 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on October 17, 2016. | This Internet-Draft will expire on February 9, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 23 ¶ | skipping to change at page 2, line 23 ¶ | |||
| 3.2. Backup and Source Detect Failure . . . . . . . . . . . . . 5 | 3.2. Backup and Source Detect Failure . . . . . . . . . . . . . 5 | |||
| 4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 5 | 4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 5 | |||
| 4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 5 | 4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 5 | |||
| 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 | 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6 | 5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6 | |||
| 5.1.1. Subobject: Backup Ingress IPv4 Address . . . . . . . . 7 | 5.1.1. Subobject: Backup Ingress IPv4 Address . . . . . . . . 7 | |||
| 5.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 8 | 5.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 8 | |||
| 5.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 8 | 5.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 8 | |||
| 5.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 8 | 5.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 8 | |||
| 5.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 9 | 5.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 9 | |||
| 5.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 10 | 5.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 9 | |||
| 6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 10 | 6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 10 | |||
| 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 10 | 6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 10 | |||
| 6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 11 | 6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 11 | |||
| 6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 12 | 6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 12 | |||
| 6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 12 | 6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13 | 6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13 | |||
| 6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 13 | 6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 13 | |||
| 6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 14 | 6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 14 | |||
| 6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 15 | 6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 14 | |||
| 6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 17 | 6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 17 | |||
| 6.3.3. Failure Detection and Refresh PATH Messages . . . . . 18 | 6.3.3. Failure Detection and Refresh PATH Messages . . . . . 17 | |||
| 6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 18 | 6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 18 | |||
| 6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 18 | 6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 18 | |||
| 6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 19 | 6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 19 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 8.1. A New Class Number . . . . . . . . . . . . . . . . . . . . 20 | 8.1. A New Class Number . . . . . . . . . . . . . . . . . . . . 19 | |||
| 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 | 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 | 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 | |||
| A. Problem Summary . . . . . . . . . . . . . . . . . . . . . . . 22 | A. Problem Summary . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| B. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 | B. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 1. Co-authors | 1. Co-authors | |||
| Ning So, Autumn Liu, Yimin Shen, Tarek Saad, Fengman Xu, Mehmet Toy, | Ning So, Autumn Liu, Yimin Shen, Tarek Saad, Fengman Xu, Mehmet Toy, | |||
| Lei Liu | Lei Liu | |||
| skipping to change at page 4, line 36 ¶ | skipping to change at page 4, line 36 ¶ | |||
| Exactly how to detect the failure of the ingress is out of scope. | Exactly how to detect the failure of the ingress is out of scope. | |||
| However, it is necessary to discuss different modes for detecting the | However, it is necessary to discuss different modes for detecting the | |||
| failure because they determine what is the required behavior for the | failure because they determine what is the required behavior for the | |||
| source and backup ingress. | source and backup ingress. | |||
| 3.1. Source Detects Failure | 3.1. Source Detects Failure | |||
| Source Detects Failure or Source-Detect for short means that the | Source Detects Failure or Source-Detect for short means that the | |||
| source is responsible for fast detecting the failure of the primary | source is responsible for fast detecting the failure of the primary | |||
| ingress of an LSP. The backup ingress is ready to import the traffic | ingress of an LSP. The backup ingress is ready to import the traffic | |||
| from the source into the backup LSP after the backup LSP is up. | from the source into the backup LSP(s) after the backup LSP(s) is up. | |||
| In normal operations, the source sends the traffic to the primary | In normal operations, the source sends the traffic to the primary | |||
| ingress. When the source detects the failure of the primary ingress, | ingress. When the source detects the failure of the primary ingress, | |||
| it switches the traffic to the backup ingress, which delivers the | it switches the traffic to the backup ingress, which delivers the | |||
| traffic to the next hops of the primary ingress through the backup | traffic to the next hops of the primary ingress through the backup | |||
| LSP, where the traffic is merged into the primary LSP. | LSP(s), where the traffic is merged into the primary LSP. | |||
| For a P2P LSP, after the primary ingress fails, the backup ingress | For a P2P LSP, after the primary ingress fails, the backup ingress | |||
| MUST use a method to reliably detect the failure of the primary | MUST use a method to reliably detect the failure of the primary | |||
| ingress before the PATH message for the LSP expires at the next hop | ingress before the PATH message for the LSP expires at the next hop | |||
| of the primary ingress. After reliably detecting the failure, the | of the primary ingress. After reliably detecting the failure, the | |||
| backup ingress sends/refreshes the PATH message to the next hop | backup ingress sends/refreshes the PATH message to the next hop | |||
| through the backup LSP as needed. | through the backup LSP as needed. | |||
| After the primary ingress fails, it will not be reachable after | After the primary ingress fails, it will not be reachable after | |||
| routing convergence. Thus checking whether the primary ingress | routing convergence. Thus checking whether the primary ingress | |||
| skipping to change at page 6, line 32 ¶ | skipping to change at page 6, line 32 ¶ | |||
| object into the PATH message to be sent to the backup ingress for | object into the PATH message to be sent to the backup ingress for | |||
| protecting the primary ingress. It has the following format: | protecting the primary ingress. It has the following format: | |||
| Class-Num = TBD C-Type = 1 for INGRESS_PROTECTION_IPv4 | Class-Num = TBD C-Type = 1 for INGRESS_PROTECTION_IPv4 | |||
| C-Type = 2 for INGRESS_PROTECTION_IPv6 | C-Type = 2 for INGRESS_PROTECTION_IPv6 | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 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 | | | Length (bytes) | Class-Num | C-Type | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Secondary LSP ID | Flags | Options | | | Reserved (zero) | NUB | Flags | Options | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ (Subobjects) ~ | ~ (Subobjects) ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| NUB Number of Unprotected Branches | ||||
| Flags | Flags | |||
| 0x01 Ingress local protection available | 0x01 Ingress local protection available | |||
| 0x02 Ingress local protection in use | 0x02 Ingress local protection in use | |||
| 0x04 Bandwidth protection | 0x04 Bandwidth protection | |||
| Options | Options | |||
| 0x01 Revert to Ingress | 0x01 Revert to Ingress | |||
| 0x02 P2MP Backup | 0x02 P2MP Backup | |||
| The Secondary LSP ID in the object is an LSP ID that the primary | For protecting the ingress of a P2MP LSP, if the backup ingress | |||
| ingress has allocated for a protected LSP tunnel. The backup ingress | doesn't have a backup LSP to each of the next hops of the primary | |||
| may use this LSP ID to set up a new LSP from the backup ingress to | ingress, it SHOULD clear "Ingress local protection available" and set | |||
| the destinations of the protected LSP tunnel. This allows the new | NUB to the number of the next hops to which there is no backup LSP. | |||
| LSP to share resources with the old one. | ||||
| The flags are used to communicate status information from the backup | The flags are used to communicate status information from the backup | |||
| ingress to the primary ingress. | ingress to the primary ingress. | |||
| o Ingress local protection available: The backup ingress sets this | o Ingress local protection available: The backup ingress sets this | |||
| flag after backup LSPs are up and ready for locally protecting the | flag after backup LSPs are up and ready for locally protecting the | |||
| primary ingress. The backup ingress sends this to the primary | primary ingress. The backup ingress sends this to the primary | |||
| ingress to indicate that the primary ingress is locally protected. | ingress to indicate that the primary ingress is locally protected. | |||
| o Ingress local protection in use: The backup ingress sets this flag | o Ingress local protection in use: The backup ingress sets this flag | |||
| skipping to change at page 7, line 32 ¶ | skipping to change at page 7, line 31 ¶ | |||
| The options are used by the primary ingress to specify the desired | The options are used by the primary ingress to specify the desired | |||
| behavior to the backup ingress. | behavior to the backup ingress. | |||
| o Revert to Ingress: The primary ingress sets this option indicating | o Revert to Ingress: The primary ingress sets this option indicating | |||
| that the traffic for the primary LSP successfully re-signaled will | that the traffic for the primary LSP successfully re-signaled will | |||
| be switched back to the primary ingress from the backup ingress | be switched back to the primary ingress from the backup ingress | |||
| when the primary ingress is restored. | when the primary ingress is restored. | |||
| o P2MP Backup: This option is set to ask for the backup ingress to | 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 | use P2MP backup LSP to protect the primary ingress. | |||
| 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 transit node. | ||||
| The INGRESS_PROTECTION object may contain some sub objects below. | The INGRESS_PROTECTION object may contain some sub objects below. | |||
| 5.1.1. Subobject: Backup Ingress IPv4 Address | 5.1.1. Subobject: Backup Ingress IPv4 Address | |||
| When the primary ingress of a protected LSP sends a PATH message with | When the primary ingress of a protected LSP sends a PATH message with | |||
| an INGRESS_PROTECTION object to the backup ingress, the object may | an INGRESS_PROTECTION object to the backup ingress, the object MUST | |||
| have a Backup Ingress IPv4 Address sub object containing an IPv4 | have a Backup Ingress IPv4 Address sub object containing an IPv4 | |||
| address belonging to the backup ingress. The Type of the sub object | address belonging to the backup ingress if IPv4 is used. The Type of | |||
| is TBD1 (the exact number to be assigned by IANA), and the body of | the sub object is TBD1 (the exact number to be assigned by IANA), and | |||
| the sub object is given below: | the body of the sub object is given below: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Backup ingress IPv4 address (4 bytes) | | | Backup ingress IPv4 address (4 bytes) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Backup ingress IPv4 address: An IPv4 host address of backup ingress | Backup ingress IPv4 address: An IPv4 host address of backup ingress | |||
| 5.1.2. Subobject: Backup Ingress IPv6 Address | 5.1.2. Subobject: Backup Ingress IPv6 Address | |||
| When the primary ingress of a protected LSP sends a PATH message with | When the primary ingress of a protected LSP sends a PATH message with | |||
| an INGRESS_PROTECTION object to the backup ingress, the object may | an INGRESS_PROTECTION object to the backup ingress, the object MUST | |||
| have a Backup Ingress IPv6 Address sub object containing an IPv6 | have a Backup Ingress IPv6 Address sub object containing an IPv6 | |||
| address belonging to the backup ingress. The Type of the sub object | address belonging to the backup ingress if IPv6 is used. The Type of | |||
| is TBD2, the body of the sub object is given below: | the sub object is TBD2, the body of the sub object is given below: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Backup ingress IPv6 address (16 bytes) | | | Backup ingress IPv6 address (16 bytes) | | |||
| ~ ~ | ~ ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Backup ingress IPv6 address: An IPv6 host address of backup ingress | Backup ingress IPv6 address: An IPv6 host address of backup ingress | |||
| skipping to change at page 11, line 6 ¶ | skipping to change at page 10, line 42 ¶ | |||
| The primary ingress relays the information for ingress protection of | The primary ingress relays the information for ingress protection of | |||
| an LSP to the backup ingress via PATH messages. Once the LSP is | an LSP to the backup ingress via PATH messages. Once the LSP is | |||
| created, the ingress of the LSP sends the backup ingress a PATH | created, the ingress of the LSP sends the backup ingress a PATH | |||
| message with an INGRESS_PROTECTION object with Label-Routes | message with an INGRESS_PROTECTION object with Label-Routes | |||
| subobject, which is populated with the next-hops and labels. This | subobject, which is populated with the next-hops and labels. This | |||
| provides sufficient information for the backup ingress to create the | provides sufficient information for the backup ingress to create the | |||
| appropriate forwarding state and backup LSP(s). | appropriate forwarding state and backup LSP(s). | |||
| The ingress also sends the backup ingress all the other PATH messages | The ingress also sends the backup ingress all the other PATH messages | |||
| for the LSP with an empty INGRESS_PROTECTION object. Thus, the | for the LSP with an empty INGRESS_PROTECTION object. An | |||
| backup ingress has access to all the PATH messages needed for | INGRESS_PROTECTION object without any Traffic-Descriptor sub-object | |||
| modification to refresh control-plane state after a failure. | is called an empty INGRESS_PROTECTION object. Thus, the backup | |||
| ingress has access to all the PATH messages needed for modification | ||||
| to refresh control-plane state after a failure. | ||||
| The advantages of this method include: 1) the primary LSP is | The advantages of this method include: 1) the primary LSP is | |||
| independent of the backup ingress; 2) simple; 3) less configuration; | independent of the backup ingress; 2) simple; 3) less configuration; | |||
| and 4) less control traffic. | and 4) less control traffic. | |||
| 6.1.2. Proxy-Ingress Method | 6.1.2. Proxy-Ingress Method | |||
| Conceptually, a proxy ingress is created that starts the RSVP | Conceptually, a proxy ingress is created that starts the RSVP | |||
| signaling. The explicit path of the LSP goes from the proxy ingress | 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 | to the backup ingress and then to the real ingress. The behavior and | |||
| skipping to change at page 13, line 27 ¶ | skipping to change at page 13, line 20 ¶ | |||
| 1. Select a PATH message. | 1. Select a PATH message. | |||
| 2. If the backup ingress is off-path, then send it a PATH message | 2. If the backup ingress is off-path, then send it a PATH message | |||
| with the content from the selected PATH message and an | with the content from the selected PATH message and an | |||
| INGRESS_PROTECTION object; else (the backup ingress is a next | INGRESS_PROTECTION object; else (the backup ingress is a next | |||
| hop, i.e., on-path case) add an INGRESS_PROTECTION object into | hop, i.e., on-path case) add an INGRESS_PROTECTION object into | |||
| the existing PATH message to the backup ingress (i.e., the next | the existing PATH message to the backup ingress (i.e., the next | |||
| hop). The object contains the Traffic-Descriptor sub-object, the | hop). The object contains the Traffic-Descriptor sub-object, the | |||
| Backup Ingress Address sub-object and the Label-Routes sub- | Backup Ingress Address sub-object and the Label-Routes sub- | |||
| object. The options is set to indicate whether a Backup P2MP LSP | object. The options is set to indicate whether a Backup P2MP LSP | |||
| is desired. A secondary LSP-ID is allocated (if it is not | is desired. The Label-Routes sub-object contains the next-hops | |||
| allocated yet) and used in the object. The Label-Routes sub- | of the ingress and their labels. | |||
| object contains the next-hops of the ingress and their labels. | ||||
| 3. For each of the other PATH messages, send the backup ingress a | 3. For each of the other PATH messages, send the backup ingress a | |||
| PATH message with the content copied from the message and an | PATH message with the content copied from the message and an | |||
| empty INGRESS_PROTECTION object, which is an object without any | empty INGRESS_PROTECTION object. | |||
| Traffic-Descriptor sub-object. | ||||
| 6.2.2. Proxy-Ingress Method | 6.2.2. Proxy-Ingress Method | |||
| The primary ingress is responsible for starting the RSVP signaling | The primary ingress is responsible for starting the RSVP signaling | |||
| for the proxy-ingress node. To do this, the following MUST be done | for the proxy-ingress node. To do this, the following MUST be done | |||
| for the RSVP PATH message. | for the RSVP PATH message. | |||
| 1. Compute the EROs for the LSP as normal for the ingress. | 1. Compute the EROs for the LSP as normal for the ingress. | |||
| 2. If the selected backup ingress node is not the first node on the | 2. If the selected backup ingress node is not the first node on the | |||
| path (for all sub-LSPs), then insert at the beginning of the ERO | path (for all sub-LSPs), then insert at the beginning of the ERO | |||
| first the backup ingress node and then the ingress node. | first the backup ingress node and then the ingress node. | |||
| 3. In the PATH RRO, instead of recording the ingress node's address, | 3. In the PATH RRO, instead of recording the ingress node's address, | |||
| replace it with the Proxy-Ingress-Id. | replace it with the Proxy-Ingress-Id. | |||
| 4. Leave the HOP object populated as usual with information for the | 4. Leave the HOP object populated as usual with information for the | |||
| ingress-node. | ingress-node. | |||
| 5. Add the INGRESS_PROTECTION object to the PATH message. Allocate | 5. Add the INGRESS_PROTECTION object to the PATH message. Include | |||
| a secondary LSP-ID to be used in the INGRESS-PROTECTION object. | the Backup Ingress Address (IPv4 or IPv6) sub-object and the | |||
| Include the Backup Ingress Address (IPv4 or IPv6) sub-object and | Traffic-Descriptor sub-object. Set or clear the options | |||
| the Traffic-Descriptor sub-object. Set or clear the options | ||||
| indicating that a Backup P2MP LSP is desired. | indicating that a Backup P2MP LSP is desired. | |||
| 6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path | 6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path | |||
| message. Indicate whether one-to-one backup is desired. | message. Indicate whether one-to-one backup is desired. | |||
| Indicate whether facility backup is desired. | Indicate whether facility backup is desired. | |||
| 7. The RSVP PATH message is sent to the backup node as normal. | 7. The RSVP PATH message is sent to the backup node as normal. | |||
| If the ingress detects that it can't communicate with the backup | If the ingress detects that it can't communicate with the backup | |||
| ingress, then the ingress SHOULD instead send the PATH message to the | ingress, then the ingress SHOULD instead send the PATH message to the | |||
| skipping to change at page 15, line 41 ¶ | skipping to change at page 15, line 31 ¶ | |||
| The backup ingress creates the appropriate forwarding state for the | The backup ingress creates the appropriate forwarding state for the | |||
| backup LSP tunnel(s) to the merge point(s). | backup LSP tunnel(s) to the merge point(s). | |||
| When the backup ingress sends a RESV message to the primary ingress, | When the backup ingress sends a RESV message to the primary ingress, | |||
| it MUST add an INGRESS_PROTECTION object into the message. It MUST | it MUST add an INGRESS_PROTECTION object into the message. It MUST | |||
| set or clear the flags in the object to report "Ingress local | set or clear the flags in the object to report "Ingress local | |||
| protection available", "Ingress local protection in use", and | protection available", "Ingress local protection in use", and | |||
| "bandwidth protection". | "bandwidth protection". | |||
| If the backup ingress doesn't have a backup LSP tunnel to each of the | If the backup ingress doesn't have a backup LSP tunnel to each of the | |||
| merge points, it SHOULD clear "Ingress local protection available". | merge points, it SHOULD clear "Ingress local protection available" | |||
| [Editor Note: It is possible to indicate the number or which are | and set NUB to the number of the merge points to which there is no | |||
| unprotected via a sub-object if desired.] | backup LSP. | |||
| When the primary ingress fails, the backup ingress redirects the | When the primary ingress fails, the backup ingress redirects the | |||
| traffic from a source into the backup P2P LSPs or the backup P2MP LSP | traffic from a source into the backup P2P LSPs or the backup P2MP LSP | |||
| transmitting the traffic to the next hops of the primary ingress, | transmitting the traffic to the next hops of the primary ingress, | |||
| where the traffic is merged into the protected LSP. | where the traffic is merged into the protected LSP. | |||
| In this case, the backup ingress MUST keep the PATH message with the | In this case, the backup ingress MUST keep the PATH message with the | |||
| INGRESS_PROTECTION object received from the primary ingress and the | INGRESS_PROTECTION object received from the primary ingress and the | |||
| RESV message with the INGRESS_PROTECTION object to be sent to the | RESV message with the INGRESS_PROTECTION object to be sent to the | |||
| primary ingress. The backup ingress MUST set the "local protection | primary ingress. The backup ingress MUST set the "local protection | |||
| skipping to change at page 19, line 20 ¶ | skipping to change at page 19, line 11 ¶ | |||
| backup ingress. After receiving the "Revert to Ingress" control- | backup ingress. After receiving the "Revert to Ingress" control- | |||
| option, the backup ingress MUST stop sending/refreshing PATH messages | option, the backup ingress MUST stop sending/refreshing PATH messages | |||
| for the protected LSP. | for the protected LSP. | |||
| 6.4.2. Global Repair by Backup Ingress | 6.4.2. Global Repair by Backup Ingress | |||
| When the backup ingress has determined that the primary ingress of | When the backup ingress has determined that the primary ingress of | |||
| the protected LSP has failed (e.g., via the IGP), it can compute a | the protected LSP has failed (e.g., via the IGP), it can compute a | |||
| new path and signal a new LSP along the new path so that it no longer | new path and signal a new LSP along the new path so that it no longer | |||
| relies upon local repair. To do this, the backup ingress MUST use | relies upon local repair. To do this, the backup ingress MUST use | |||
| the same tunnel sender address in the Sender Template Object and the | the same tunnel sender address in the Sender Template Object and | |||
| previously allocated secondary LSP-ID in the INGRESS_PROTECTION | allocate a LSP ID different from the one of the old LSP as the LSP-ID | |||
| object of the PATH message as the LSP-ID of the new LSP. This allows | of the new LSP. This allows the new LSP to share resources with the | |||
| the new LSP to share resources with the old LSP. In addition, if the | old LSP. Alternately, the Backup Ingress can create a new LSP with | |||
| Ingress recovers, the Backup Ingress SHOULD send it RESVs with the | no bandwidth reservation that duplicates the path(s) of the protected | |||
| INGRESS_PROTECTION object where the "Revert to Ingress" is specified. | LSP, move traffic to the new LSP, delete the protected LSP, and then | |||
| The Secondary LSP ID MUST be the unused LSP ID - while the LSP ID | resignal the new LSP with bandwidth. | |||
| signaled in the RESV will be that currently active. The Ingress can | ||||
| learn from the RESVs what to signal. Even if the Ingress does not | ||||
| take over, the RESVs notify it that the particular LSP IDs are in | ||||
| use. The Backup Ingress can reoptimize the new LSP as necessary | ||||
| until the Ingress recovers. Alternately, the Backup Ingress can | ||||
| create a new LSP with no bandwidth reservation that duplicates the | ||||
| path(s) of the protected LSP, move traffic to the new LSP, delete the | ||||
| protected LSP, and then resignal the new LSP with bandwidth. | ||||
| 7. Security Considerations | 7. Security Considerations | |||
| In principle this document does not introduce new security issues. | In principle this document does not introduce new security issues. | |||
| The security considerations pertaining to RFC 4090, RFC 4875 and | The security considerations pertaining to RFC 4090, RFC 4875 and | |||
| other RSVP protocols remain relevant. | other RSVP protocols remain relevant. | |||
| 8. IANA Considerations | 8. IANA Considerations | |||
| IANA is requested to administer the assignment of new values defined | IANA is requested to administer the assignment of new values defined | |||
| skipping to change at page 20, line 15 ¶ | skipping to change at page 19, line 40 ¶ | |||
| 8.1. A New Class Number | 8.1. A New Class Number | |||
| IANA maintains a registry called "Class Names, Class Numbers, and | IANA maintains a registry called "Class Names, Class Numbers, and | |||
| Class Types" under "Resource Reservation Protocol-Traffic Engineering | Class Types" under "Resource Reservation Protocol-Traffic Engineering | |||
| (RSVP-TE) Parameters". IANA is requested to assign a new Class | (RSVP-TE) Parameters". IANA is requested to assign a new Class | |||
| Number for new object INGRESS_PROTECTION as follows: | Number for new object INGRESS_PROTECTION as follows: | |||
| +====================+===============+============================+ | +====================+===============+============================+ | |||
| | Class Names | Class Numbers | Class Types | | | Class Names | Class Numbers | Class Types | | |||
| +====================+===============+============================+ | +====================+===============+============================+ | |||
| | INGRESS_PROTECTION | TBD (>192) | 1: INGRESS_PROTECTION_IPv4 | | | INGRESS_PROTECTION | 206 | 1: INGRESS_PROTECTION_IPv4 | | |||
| | | +----------------------------+ | | | is suggested +----------------------------+ | |||
| | | | 2: INGRESS_PROTECTION_IPv6 | | | | | 2: INGRESS_PROTECTION_IPv6 | | |||
| +--------------------+---------------+----------------------------+ | +--------------------+---------------+----------------------------+ | |||
| IANA is requested to assign Types for new TLVs in the new objects as | IANA is requested to assign Types for new TLVs in the new objects as | |||
| follows: | follows: | |||
| Type Name Allowed in | Type Name Allowed in | |||
| 1 BACKUP_INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 | 1 BACKUP_INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 | |||
| 2 BACKUP_INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6 | 2 BACKUP_INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6 | |||
| 3 INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 | 3 INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4 | |||
| End of changes. 24 change blocks. | ||||
| 60 lines changed or deleted | 47 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||