draft-ietf-teas-rsvp-ingress-protection-00.txt | draft-ietf-teas-rsvp-ingress-protection-01.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: Standards Track R. Torvi, Ed. | Intended status: Standards Track R. Torvi, Ed. | |||
Expires: July 4, 2015 Juniper Networks | Expires: July 14, 2015 Juniper Networks | |||
December 31, 2014 | January 10, 2015 | |||
Extensions to RSVP-TE for LSP Ingress Local Protection | Extensions to RSVP-TE for LSP Ingress Local Protection | |||
draft-ietf-teas-rsvp-ingress-protection-00.txt | draft-ietf-teas-rsvp-ingress-protection-01.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) in a Multi- | of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- | |||
Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. | Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. | |||
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 July 4, 2015. | This Internet-Draft will expire on July 14, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2015 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 24 | skipping to change at page 2, line 24 | |||
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/IPv6 Address . . . . . 7 | 5.1.1. Subobject: Backup Ingress IPv4/IPv6 Address . . . . . 7 | |||
5.1.2. Subobject: Ingress IPv4/IPv6 Address . . . . . . . . . 8 | 5.1.2. Subobject: Ingress IPv4/IPv6 Address . . . . . . . . . 8 | |||
5.1.3. Subobject: Traffic Descriptor . . . . . . . . . . . . 8 | 5.1.3. Subobject: Traffic Descriptor . . . . . . . . . . . . 8 | |||
5.1.4. Subobject: Label-Routes . . . . . . . . . . . . . . . 9 | 5.1.4. Subobject: Label-Routes . . . . . . . . . . . . . . . 9 | |||
6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 9 | 6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 9 | |||
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 9 | 6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 9 | |||
6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 10 | 6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 11 | |||
6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 11 | 6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 11 | |||
6.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 11 | 6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 13 | |||
6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 12 | 6.3.3. Failure Detection and Refresh PATH Messages . . . . . 13 | |||
6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12 | 6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 14 | |||
6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 13 | 6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 14 | |||
6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 14 | 6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 14 | |||
6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 16 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | |||
6.3.3. Failure Detection and Refresh PATH Messages . . . . . 17 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 17 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 18 | 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 18 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 | |||
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 | A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 | ||||
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 | ||||
A. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
1. Co-authors | 1. Co-authors | |||
Ning So, Autumn Liu, Alia Atlas, Yimin Shen, Tarek Saad, Fengman Xu, | Ning So, Autumn Liu, Alia Atlas, Yimin Shen, Tarek Saad, Fengman Xu, | |||
Mehmet Toy, Lei Liu | Mehmet Toy, Lei Liu | |||
2. Introduction | 2. Introduction | |||
For MPLS LSPs it is important to have a fast-reroute method for | For MPLS LSPs it is important to have a fast-reroute method for | |||
protecting its ingress node as well as transit nodes. This is not | protecting its ingress node as well as transit nodes. This is not | |||
skipping to change at page 9, line 43 | skipping to change at page 9, line 43 | |||
6. Behavior of Ingress Protection | 6. Behavior of Ingress Protection | |||
6.1. Overview | 6.1. Overview | |||
There are four parts of ingress protection: 1) setting up the | There are four parts of ingress protection: 1) setting up the | |||
necessary backup LSP forwarding state; 2) identifying the failure and | necessary backup LSP forwarding state; 2) identifying the failure and | |||
providing the fast repair (as discussed in Sections 3 and 4); 3) | providing the fast repair (as discussed in Sections 3 and 4); 3) | |||
maintaining the RSVP-TE control plane state until a global repair can | maintaining the RSVP-TE control plane state until a global repair can | |||
be done; and 4) performing the global repair(see Section 6.4). | be done; and 4) performing the global repair(see Section 6.4). | |||
There are two different proposed signaling approaches to obtain | ||||
ingress protection. They both use the same new INGRESS_PROTECTION | ||||
object. The object is sent in both PATH and RESV messages. | ||||
6.1.1. Relay-Message Method | ||||
The primary ingress relays the information for ingress protection of | ||||
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 | ||||
message with an INGRESS_PROTECTION object with Label-Routes | ||||
subobject, which is populated with the next-hops and labels. This | ||||
provides sufficient information for the backup ingress to create the | ||||
appropriate forwarding state and backup LSP(s). | ||||
The ingress also sends the backup ingress all the other PATH messages | ||||
for the LSP with 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 | ||||
independent of the backup ingress; 2) simple; 3) less configuration; | ||||
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. | ||||
[ traffic source ] *** Primary LSP | ||||
$ $ --- Backup LSP | ||||
$ $ $$ Link | ||||
$ $ | ||||
[ proxy ingress ] [ backup ] | ||||
[ & ingress ] | | ||||
* | | ||||
*****[ MP ]----| | ||||
Figure 2: Example Protected LSP with Proxy Ingress Node | ||||
The backup ingress must know the merge points or next-hops and their | ||||
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 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 | ||||
+-------+-----------+------+--------+-----------------+---------+ | ||||
| |Primary LSP|Simple|Config |PATH Msg from |Reuse | | ||||
|Method |Depends on | |Proxy- |Backup to primary|Some of | | ||||
| |Backup | |Ingress-|RESV Msg from |Existing | | ||||
| |Ingress | |ID |Primary to backup|Functions| | ||||
+-------+-----------+------+--------+-----------------+---------+ | ||||
|Relay- | No |Yes | No | No | Yes- | | ||||
|Message| | | | | | | ||||
+-------+-----------+------+--------+-----------------+---------+ | ||||
|Proxy- | Yes |Yes- | Yes | Yes | Yes | | ||||
|Ingress| | | | | | | ||||
+-------+-----------+------+--------+-----------------+---------+ | ||||
6.2. Ingress Behavior | 6.2. Ingress Behavior | |||
The primary ingress must be configured with two or three pieces of | The primary ingress must be configured with a couple of pieces of | |||
information for ingress protection. | information for ingress protection. | |||
o Backup Ingress Address: The primary ingress must know an IP | o Backup Ingress Address: The primary ingress must know an IP | |||
address for it to be included in the INGRESS_PROTECTION object. | address for it to be included in the INGRESS_PROTECTION object. | |||
o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The | ||||
Proxy-Ingress-Id is only used in the Record Route Object for | ||||
recording the proxy-ingress. If no proxy-ingress-id is specified, | ||||
then a local interface address that will not otherwise be included | ||||
in the Record Route Object can be used. A similar technique is | ||||
used in [RFC4090 Sec 6.1.1]. | ||||
o Application Traffic Identifier: The primary ingress and backup | o Application Traffic Identifier: The primary ingress and backup | |||
ingress must both know what application traffic should be directed | ingress must both know what application traffic should be directed | |||
into the LSP. If a list of prefixes in the Traffic Descriptor | into the LSP. If a list of prefixes in the Traffic Descriptor | |||
sub-object will not suffice, then a commonly understood | sub-object will not suffice, then a commonly understood | |||
Application Traffic Identifier can be sent between the primary | Application Traffic Identifier can be sent between the primary | |||
ingress and backup ingress. The exact meaning of the identifier | ingress and backup ingress. The exact meaning of the identifier | |||
should be configured similarly at both the primary ingress and | should be configured similarly at both the primary ingress and | |||
backup ingress. The Application Traffic Identifier is understood | backup ingress. The Application Traffic Identifier is understood | |||
within the unique context of the primary ingress and backup | within the unique context of the primary ingress and backup | |||
ingress. | ingress. | |||
With this additional information, the primary ingress can create and | With this additional information, the primary ingress can create and | |||
signal the necessary RSVP extensions to support ingress protection. | signal the necessary RSVP extensions to support ingress protection. | |||
6.2.1. Relay-Message Method | The primary ingress relays the information for ingress protection of | |||
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 | ||||
message with an INGRESS_PROTECTION object with Label-Routes | ||||
subobject, which is populated with the next-hops and labels. This | ||||
provides sufficient information for the backup ingress to create the | ||||
appropriate forwarding state and backup LSP(s). | ||||
The ingress also sends the backup ingress all the other PATH messages | ||||
for the LSP with 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. | ||||
To protect the ingress of an LSP, the ingress does the following | To protect the ingress of an LSP, the ingress does the following | |||
after the LSP is up. | after the LSP is up. | |||
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 | |||
skipping to change at page 12, line 35 | skipping to change at page 11, line 10 | |||
object. The flags is set to indicate whether a Backup P2MP LSP | object. The flags is set to indicate whether a Backup P2MP LSP | |||
is desired. A second LSP-ID is allocated (if it is not allocated | is desired. A second LSP-ID is allocated (if it is not allocated | |||
yet) and used in the object. The Label-Routes sub-object | yet) and used in the object. The Label-Routes sub-object | |||
contains the next-hops of the ingress and their labels. | 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, which is an object without any | |||
Traffic-Descriptor sub-object. | Traffic-Descriptor sub-object. | |||
6.2.2. Proxy-Ingress Method | ||||
The primary ingress is responsible for starting the RSVP signaling | ||||
for the proxy-ingress node. To do this, the following is done for | ||||
the RSVP PATH message. | ||||
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 | ||||
path (for all sub-LSPs), then insert at the beginning of the ERO | ||||
first the backup ingress node and then the ingress node. | ||||
3. In the PATH RRO, instead of recording the ingress node's address, | ||||
replace it with the Proxy-Ingress-Id. | ||||
4. Leave the HOP object populated as usual with information for the | ||||
ingress-node. | ||||
5. Add the INGRESS_PROTECTION object to the PATH message. Allocate | ||||
a second LSP-ID to be used in the INGRESS-PROTECTION object. | ||||
Include the Backup Ingress Address (IPv4 or IPv6) sub-object and | ||||
the Traffic-Descriptor sub-object. 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. | ||||
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 | ||||
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 | ||||
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 | 6.3. Backup Ingress Behavior | |||
An LER determines that the ingress local protection is requested for | An LER determines that the ingress local protection is requested for | |||
an LSP if the INGRESS_PROTECTION object is included in the PATH | an LSP if the INGRESS_PROTECTION object is included in the PATH | |||
message it receives for the LSP. The LER can further determine that | 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 | it is the backup ingress if one of its addresses is in the Backup | |||
Ingress Address sub-object of the INGRESS_PROTECTION object. The LER | Ingress Address sub-object of the INGRESS_PROTECTION object. The LER | |||
as the backup ingress will assume full responsibility of the ingress | as the backup ingress will assume full responsibility of the ingress | |||
after the primary ingress fails. In addition, the LER determines | 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. | that it is off-path if it is not a next hop of the primary ingress. | |||
skipping to change at page 15, line 28 | skipping to change at page 12, line 39 | |||
primary ingress, and tear down the one-to-one backup LSPs for | primary ingress, and tear down the one-to-one backup LSPs for | |||
protecting the primary ingress if one-to-one backup is used or unbind | protecting the primary ingress if one-to-one backup is used or unbind | |||
the facility backup LSPs if facility backup is used. | the facility backup LSPs if facility backup is used. | |||
When the backup ingress receives a PATH message from the primary | When the backup ingress receives a PATH message from the primary | |||
ingress for locally protecting the primary ingress of a protected | ingress for locally protecting the primary ingress of a protected | |||
LSP, it checks to see if any critical information has been changed. | LSP, it checks to see if any critical information has been changed. | |||
If the next hops of the primary ingress are changed, the backup | If the next hops of the primary ingress are changed, the backup | |||
ingress SHALL update its backup LSP(s) accordingly. | ingress SHALL update its backup LSP(s) accordingly. | |||
6.3.1.1. Relay-Message Method | ||||
When the backup ingress receives a PATH message with an non empty | When the backup ingress receives a PATH message with an non empty | |||
INGRESS_PROTECTION object, it examines the object to learn what | INGRESS_PROTECTION object, it examines the object to learn what | |||
traffic associated with the LSP. It determines the next-hops to be | traffic associated with the LSP. It determines the next-hops to be | |||
merged to by examining the Label-Routes sub-object in the object. | merged to by examining the Label-Routes sub-object in the object. | |||
The backup ingress stores the PATH message received from the primary | The backup ingress stores the PATH message received from the primary | |||
ingress, but does NOT forward it. | ingress, but does NOT forward it. | |||
The backup ingress MUST respond with a RESV to the PATH message | The backup ingress responds with a RESV to the PATH message received | |||
received from the primary ingress. If the INGRESS_PROTECTION object | from the primary ingress. If the INGRESS_PROTECTION object is not | |||
is not "empty", the backup ingress SHALL send the RESV message with | "empty", the backup ingress SHALL send the RESV message with the | |||
the state indicating protection is available after the backup LSP(s) | state indicating protection is available after the backup LSP(s) are | |||
are successfully established. | successfully established. | |||
6.3.1.2. Proxy-Ingress Method | ||||
The backup ingress determines the next-hops to be merged to by | ||||
collecting the set of the pair of (IPv4/IPv6 sub-object, Label sub- | ||||
object) from the Record Route Object of each RESV that are closest to | ||||
the top and not the Ingress router; this should be the second to the | ||||
top pair. If a Label-Routes sub-object is included in the | ||||
INGRESS_PROTECTION object, the included IPv4/IPv6 sub-objects are | ||||
used to filter the set down to the specific next-hops where | ||||
protection is desired. A RESV message must have been received before | ||||
the Backup Ingress can create or select the appropriate backup LSP. | ||||
When the backup ingress receives a PATH message with the | ||||
INGRESS_PROTECTION object, the backup ingress examines the object to | ||||
learn what traffic associated with the LSP. The backup ingress | ||||
forwards the PATH message to the ingress node with the normal RSVP | ||||
changes. | ||||
When the backup ingress receives a RESV message with the | ||||
INGRESS_PROTECTION object, the backup ingress records an IMPLICIT- | ||||
NULL label in the RRO. Then the backup ingress forwards the RESV | ||||
message to the ingress node, which is acting for the proxy ingress. | ||||
6.3.2. Backup Ingress Behavior in On-path Case | 6.3.2. Backup Ingress Behavior in On-path Case | |||
An LER as the backup ingress determines that it is on-path if one of | An LER as the backup ingress determines that it is on-path if one of | |||
its addresses is a next hop of the primary ingress (and the primary | its addresses is a next hop of the primary ingress. The LER on-path | |||
ingress is not its next hop via checking the PATH message with the | sends the corresponding PATH messages without any INGRESS_PROTECTION | |||
INGRESS_PROTECTION object received from the primary ingress for | object to its next hops. It creates a number of backup P2P LSPs or a | |||
Proxy-Ingress Method). The LER on-path sends the corresponding PATH | backup P2MP LSP from itself to the other next hops (i.e., the next | |||
messages without any INGRESS_PROTECTION object to its next hops. It | hops other than the backup ingress) of the primary ingress. The | |||
creates a number of backup P2P LSPs or a backup P2MP LSP from itself | other next hops are from the Label-Routes sub object. | |||
to the other next hops (i.e., the next hops other than the backup | ||||
ingress) of the primary ingress. The other next hops are from the | ||||
Label-Routes sub object. | ||||
It also creates a forwarding entry, which sends/multicasts the | It also creates a forwarding entry, which sends/multicasts the | |||
traffic from the source to the next hops of the backup ingress along | traffic from the source to the next hops of the backup ingress along | |||
the protected LSP when the primary ingress fails. The traffic is | the protected LSP when the primary ingress fails. The traffic is | |||
described by the Traffic-Descriptor. | described by the Traffic-Descriptor. | |||
After the forwarding entry is created, all the backup P2P LSPs or the | After the forwarding entry is created, all the backup P2P LSPs or the | |||
backup P2MP LSP is up and associated with the protected LSP, the | backup P2MP LSP is up and associated with the protected LSP, the | |||
backup ingress sends the primary ingress the RESV message with the | backup ingress sends the primary ingress the RESV message with the | |||
INGRESS_PROTECTION object containing the state of the local | INGRESS_PROTECTION object containing the state of the local | |||
skipping to change at page 18, line 9 | skipping to change at page 14, line 35 | |||
- Global Repair by Backup Ingress: After determining that the | - Global Repair by Backup Ingress: After determining that the | |||
primary ingress of an LSP has failed, the backup ingress computes | primary ingress of an LSP has failed, the backup ingress computes | |||
a new optimal path, signals a new LSP along the new path, and | a new optimal path, signals a new LSP along the new path, and | |||
switches the traffic to the new LSP. | switches the traffic to the new LSP. | |||
6.4.1. Revert to Primary Ingress | 6.4.1. Revert to Primary Ingress | |||
If "Revert to Primary Ingress" is desired for a protected LSP, the | If "Revert to Primary Ingress" is desired for a protected LSP, the | |||
(primary) ingress of the LSP re-signals the LSP that starts from the | (primary) ingress of the LSP re-signals the LSP that starts from the | |||
primary ingress after the primary ingress restores. When the LSP is | primary ingress after the primary ingress restores. After the LSP is | |||
re-signaled successfully, the traffic is switched back to the primary | re-signaled successfully, the traffic can be switched back to the | |||
ingress from the backup ingress and redirected into the LSP starting | primary ingress from the backup ingress on the source node and | |||
from the primary ingress. | redirected into the LSP starting from the primary ingress. | |||
If the ingress can resignal the PATH messages for the LSP, then the | ||||
ingress can specify the "Revert to Ingress" control-option in the | ||||
INGRESS_PROTECTION object. Doing so may cause a duplication of | ||||
traffic while the Ingress starts sending traffic again before the | ||||
Backup Ingress stops; the alternative is to drop traffic for a short | ||||
period of time. | ||||
Additionally, the Backup Ingress can set the "Revert To Ingress" | The primary ingress can specify the "Revert to Ingress" control- | |||
control-option as a request for the Ingress to take over. | option in the INGRESS_PROTECTION object in the PATH messages to the | |||
backup ingress. After receiving the "Revert to Ingress" control- | ||||
option, the backup ingress stops sending/refreshing PATH messages 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 uses the | relies upon local repair. To do this, the backup ingress uses the | |||
same tunnel sender address in the Sender Template Object and uses the | same tunnel sender address in the Sender Template Object and uses the | |||
previously allocated second LSP-ID in the INGRESS_PROTECTION object | previously allocated second LSP-ID in the INGRESS_PROTECTION object | |||
of the PATH message as the LSP-ID of the new LSP. This allows the | of the PATH message as the LSP-ID of the new LSP. This allows the | |||
End of changes. 15 change blocks. | ||||
227 lines changed or deleted | 54 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |