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/