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/ |