draft-ietf-ccamp-gmpls-segment-recovery-00.txt   draft-ietf-ccamp-gmpls-segment-recovery-01.txt 
Network Working Group Louis Berger (Movaz Networks) Internet Draft Louis Berger (Movaz Networks)
Internet Draft Igor Bryskin (Movaz Networks) Updates: 3473 Igor Bryskin (Movaz Networks)
Expiration Date: September 2004 Dimitri Papadimitriou (Alcatel) Category: Standards Track Dimitri Papadimitriou (Alcatel)
Adrian Farrel (Old Dog Consulting) Expiration Date: April 2005 Adrian Farrel (Old Dog Consulting)
March 2004 October 2004
GMPLS Based Segment Recovery GMPLS Based Segment Recovery
draft-ietf-ccamp-gmpls-segment-recovery-00.txt draft-ietf-ccamp-gmpls-segment-recovery-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. Internet-Drafts are working patent or other IPR claims of which I am aware have been disclosed,
documents of the Internet Engineering Task Force (IETF), its areas, or will be disclosed, and any of which I become aware will be
and its working groups. Note that other groups may also distribute disclosed, in accordance with RFC 3668.
working documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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 a "work in progress."
To view the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow http://www.ietf.org/1id-abstracts.html
Directory, see http://www.ietf.org/shadow.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract Abstract
This document describes protocol specific procedures for GMPLS This document describes protocol specific procedures for GMPLS
(Generalized Multi-Protocol Label Switching) RSVP-TE (Resource (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
ReserVation Protocol - Traffic Engineering) signaling extensions to ReserVation Protocol - Traffic Engineering) signaling extensions to
support LSP segment protection and restoration. These extensions are support LSP segment protection and restoration. These extensions are
intended to be compliment and be consistent with the Extensions for intended to be compliment and be consistent with the Extensions for
End-to-End GMPLS-based Recovery. Implications and interactions with End-to-End GMPLS-based Recovery. Implications and interactions with
Fast Reroute are also addressed. Fast Reroute are also addressed. This document also updates the
handling of Notify_Request objects specified in [RFC3473].
Contents Contents
1 Introduction .............................................. 3 1 Introduction .............................................. 3
2 Segment Recovery .......................................... 4 2 Segment Recovery .......................................... 4
2.1 Segment Protection ........................................ 6 2.1 Segment Protection ........................................ 6
2.2 Segment Re-routing and Restoration ........................ 6 2.2 Segment Re-routing and Restoration ........................ 6
3 Association Object ........................................ 6 3 Association Object ........................................ 6
3.1 Format .................................................... 7 3.1 Format .................................................... 7
3.2 Procedures ................................................ 7 3.2 Procedures ................................................ 7
3.2.1 Resource Sharing Association Type Processing .............. 7 3.2.1 Resource Sharing Association Type Processing .............. 7
4 Explicit Control of LSP Segment Recovery .................. 8 4 Explicit Control of LSP Segment Recovery .................. 8
4.1 Secondary Explicit Route Object Format .................... 8 4.1 Secondary Explicit Route Object Format .................... 8
4.1.1 Protection Subobject ...................................... 8 4.1.1 Protection Subobject ...................................... 8
4.2 Explicit Control Procedures ............................... 9 4.2 Explicit Control Procedures ............................... 9
4.2.1 Resv Message Processing ................................... 10 4.2.1 Branch Failure Handling ................................... 10
4.2.2 Branch Failure Handling ................................... 11 4.2.2 Resv Message Processing ................................... 11
4.2.3 Admin Status Change ....................................... 11 4.2.3 Admin Status Change ....................................... 12
4.2.4 Recovery LSP Tear Down .................................... 12 4.2.4 Recovery LSP Tear Down .................................... 12
4.3 Tear Down From Non-Ingress Nodes .......................... 12 4.3 Tear Down From Non-Ingress Nodes .......................... 13
4.3.1 Modified Notify Request Object Processing ................. 13 4.3.1 Modified Notify Request Object Processing ................. 13
4.3.2 Modified Notify and Error Message Processing .............. 14 4.3.2 Modified Notify and Error Message Processing .............. 14
5 Secondary Record Route Objects ............................ 14 5 Secondary Record Route Objects ............................ 14
5.1 Format .................................................... 14 5.1 Format .................................................... 14
5.2 Path Processing ........................................... 14 5.2 Path Processing ........................................... 15
5.3 Resv Processing ........................................... 15 5.3 Resv Processing ........................................... 15
6 Dynamic Control of LSP Segment Recovery ................... 15 6 Dynamic Control of LSP Segment Recovery ................... 16
6.1 Modified Protection Object Format ......................... 16 6.1 Modified Protection Object Format ......................... 16
6.2 Dynamic Control Procedures ................................ 16 6.2 Dynamic Control Procedures ................................ 17
7 Additional Fast Reroute Considerations .................... 18 7 Updated RSVP Message Formats .............................. 18
8 Updated RSVP Message Formats .............................. 18 8 Security Considerations ................................... 20
9 Security Considerations ................................... 20 9 IANA Considerations ....................................... 21
10 IANA Considerations ....................................... 21 10 Intellectual Property Considerations ...................... 21
11 Intellectual Property Considerations ...................... 21 11 References ................................................ 22
12 References ................................................ 22 11.1 Normative References ...................................... 22
12.1 Normative References ...................................... 22 11.2 Informative References .................................... 22
12.2 Informative References .................................... 22 12 Authors' Addresses ........................................ 23
13 Contributors .............................................. 23 13 Full Copyright Statement .................................. 23
14 Full Copyright Statement .................................. 23 14 Intellectual Property ..................................... 24
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition, the reader is assumed to be familiar with the In addition, the reader is assumed to be familiar with the
terminology used in [RFC3209], [RFC3471], [RFC3473] as well as terminology used in [RFC3209], [RFC3471], [RFC3473] as well as
[TERM], [FUNCT], [E2E-RECOVERY] and [FRR]. [TERM], [FUNCT], [E2E-RECOVERY] and [FRR].
1. Introduction 1. Introduction
[TERM] covers multiple types of protection, including end-to-end and [TERM] covers multiple types of protection, including end-to-end and
segment based approaches. [E2E-RECOVERY], RSVP-TE Extensions in segment based approaches. [E2E-RECOVERY], RSVP-TE Extensions in
support of End-to-End GMPLS-based Recovery, defines a set of support of End-to-End GMPLS-based Recovery, defines a set of
extensions to support multiple types of recovery. The supported extensions to support multiple types of recovery. The supported
types include 1+1 unidirectional/ 1+1 bi-directional protection, LSP types include 1+1 unidirectional/ 1+1 bi-directional protection, LSP
protection with extra-traffic (including 1:N protection with extra- protection with extra-traffic (including 1:N protection with extra-
traffic), pre-planned LSP re- routing without extra-traffic traffic), pre-planned LSP re-routing without extra-traffic (including
(including shared mesh), and full LSP re-routing. In all cases, the shared mesh), and full LSP re-routing. In all cases, the recovery is
recovery is provided on an end-to-end basis, i.e., the ingress and provided on an end-to-end basis, i.e., the ingress and egress nodes
egress nodes of both the protected and the protecting LSP are the of both the protected and the protecting LSP are the same.
same.
[FRR] provides a form of segment recovery for packet MPLS-TE [FRR] provides a form of segment recovery for packet MPLS-TE
networks. Two methods of Fast Reroute are defined in [FRR]. The networks. Two methods of Fast Reroute are defined in [FRR]. The
one-to-one backup method creates detour LSPs for each protected LSP one-to-one backup method creates detour LSPs for each protected LSP
at each potential point of local repair. The facility backup method at each potential point of local repair. The facility backup method
creates a bypass tunnel to protect a potential failure point which is creates a bypass tunnel to protect a potential failure point which is
shared by multiple LSPs and uses label stacking. Neither approach shared by multiple LSPs and uses label stacking. Neither approach
supports the full set of recovery types supported by [E2E-RECOVERY]. supports the full set of recovery types supported by [E2E-RECOVERY].
Additionally, the facility backup method is not applicable to most Additionally, the facility backup method is not applicable to most
non-PSC (packet) switching technologies. non-PSC (packet) switching technologies.
The extensions defined in this document allow for support of the full The extensions defined in this document allow for support of the full
set of recovery types supported by [E2E-RECOVERY] on a segment, or set of recovery types supported by [E2E-RECOVERY] on a segment, or
portion of the LSP, basis. The extensions allow (a) the signaling of portion of the LSP, basis. The extensions allow (a) the signaling of
desired LSP segment protection type, (b) upstream nodes to optionally desired LSP segment protection type, (b) upstream nodes to optionally
identify where segment protection starts and stops, and (c) to also identify where segment protection starts and stops, (c) the optional
optionally identify hops used on protection segments. These identification of hops used on protection segments, and (d) the
extensions are intended to be compatible with, and in some cases used reporting of paths used to protect an LSP. The extensions also widen
with Fast Reroute. the topological scope over which protection can be supported. They
allow recovery segments that protect against an arbitrary number of
nodes and links. They enable overlapping protection and nested
protection. These extensions are intended to be compatible with, and
in some cases used with Fast Reroute.
2. Segment Recovery 2. Segment Recovery
Segment recovery is used to provide protection and restoration over a Segment recovery is used to provide protection and restoration over a
portion of an end-to-end LSP. Such segment protection and portion of an end-to-end LSP. Such segment protection and
restoration is useful to protect against a span failure, a node restoration is useful to protect against a span failure, a node
failure, or failure over a particularly portion of a network used by failure, or failure over a particularly portion of a network used by
an LSP. an LSP.
Consider the following topology: Consider the following topology:
skipping to change at page 5, line 33 skipping to change at page 5, line 33
terminator. Standard ERO semantics, see [RFC3209], can optionally be terminator. Standard ERO semantics, see [RFC3209], can optionally be
used within and SERO to explicitly control the recovery LSP. A used within and SERO to explicitly control the recovery LSP. A
Secondary Record Route object or SRRO is defined for recording the Secondary Record Route object or SRRO is defined for recording the
path of a segment recovery LSP, see section 5. path of a segment recovery LSP, see section 5.
SEROs are carried between the node creating the SERO, typically the SEROs are carried between the node creating the SERO, typically the
ingress, and the node initiating a recovery LSP. The node initiating ingress, and the node initiating a recovery LSP. The node initiating
a recovery LSP uses the SERO to create the ERO for the recovery LSP. a recovery LSP uses the SERO to create the ERO for the recovery LSP.
At this (branch) node, all local objects are removed, and the new At this (branch) node, all local objects are removed, and the new
protection subobject is used to create the Protection object for the protection subobject is used to create the Protection object for the
recovery LSP. SRROs are carried in Path messages between the node recovery LSP. It is also possible to control the handling of a
terminating a recovery LSP, the merge node, and the egress. SRROs failure to establish a recovery LSP.
are used in Resv messages between a branch node and the ingress. The
merge node of a recovery LSP creates an SRRO by copying the RRO from SRROs are carried in Path messages between the node terminating a
the Path message of the associated recovery LSP into a new SRRO recovery LSP, the merge node, and the egress. SRROs are used in Resv
object. Any SRROs present in the recovery LSP's Path message are messages between a branch node and the ingress. The merge node of a
also copied. The branch node of a recovery LSP creates an SRRO by recovery LSP creates an SRRO by copying the RRO from the Path message
copying the RRO from the Resv message of associated recovery LSP into of the associated recovery LSP into a new SRRO object. Any SRROs
a new SRRO object. Any SRROs present in the recovery LSP's Resv present in the recovery LSP's Path message are also copied. The
message are also copied. branch node of a recovery LSP creates an SRRO by copying the RRO from
the Resv message of associated recovery LSP into a new SRRO object.
Any SRROs present in the recovery LSP's Resv message are also copied.
Notify request processing is also impacted by LSP segment recovery. Notify request processing is also impacted by LSP segment recovery.
Per [RFC3473], only one Notify Request object is meaningful and Per [RFC3473], only one Notify Request object is meaningful and
should be propagated. Additional Notify Request objects are used to should be propagated. Additional Notify Request objects are used to
identify recovery LSP branch nodes. identify recovery LSP branch nodes.
2.1. Segment Protection 2.1. Segment Protection
Three approaches of end-to-end protection are defined in [E2E- Three approaches of end-to-end protection are defined in [E2E-
RECOVERY]: 1+1 Unidirectional Protection, see Section 5; 1+1 Bi- RECOVERY]: 1+1 Unidirectional Protection, see Section 5; 1+1 Bi-
skipping to change at page 10, line 11 skipping to change at page 10, line 11
determination is made by examining the first object of each SERO and determination is made by examining the first object of each SERO and
seeing if the address indicated in the subobject can be associated seeing if the address indicated in the subobject can be associated
with the local node. If any of indicated addresses are associated with the local node. If any of indicated addresses are associated
with the local node, then the local node is a branch node. If the with the local node, then the local node is a branch node. If the
local node is not a branch node, all received SEROs MUST be local node is not a branch node, all received SEROs MUST be
transmitted, without modification, in the corresponding outgoing Path transmitted, without modification, in the corresponding outgoing Path
message. message.
At a branch node, the SERO together with the Path message of LSP At a branch node, the SERO together with the Path message of LSP
being recovered provides the information to create the recovery LSP. being recovered provides the information to create the recovery LSP.
If the processing node is unable to support the requested branch, a
PathErr message SHOULD sent for the LSP being being protected, and
normal processing of the LSP continues. The PathErr message SHOULD
indicate an error of "TBD" and the Path_State_Removed flag MUST NOT
be set. If no error is generated then a recovery LSP is created.
The Path message for the recovery LSP is created at the branch node The Path message for the recovery LSP is created at the branch node
by cloning the objects carried in the incoming Path message of the by cloning the objects carried in the incoming Path message of the
LSP being protected. Certain objects are replaced or modified in the LSP being protected. Certain objects are replaced or modified in the
recovery LSP's outgoing Path message. The Sender_template MUST be recovery LSP's outgoing Path message. The Sender_template MUST be
updated to use an address on the local node, and the LSP ID MUST be updated to use an address on the local node, and the LSP ID MUST be
updated to ensure uniqueness. The Session object MUST be updated to updated to ensure uniqueness. The Session object MUST be updated to
use the address indicated in the final subobject of the SERO as the use the address indicated in the final subobject of the SERO as the
tunnel endpoint, the tunnel ID MAY be updated, and the extended tunnel endpoint, the tunnel ID MAY be updated, and the extended
tunnel ID MUST be set to the local node. The Protection object is tunnel ID MUST be set to the local node. The Protection object is
replaced with the contents of the matching SERO protection subobject, replaced with the contents of the matching SERO protection subobject,
when present. Any RROs and EROs present in the incoming Path message when present. In all cases, the R-bit of a new Protection object is
reset (0). Any RROs and EROs present in the incoming Path message
MUST NOT be included in the recovery LSP. A new ERO MUST be MUST NOT be included in the recovery LSP. A new ERO MUST be
included, with the contents of the SERO that indicated a local included, with the contents of the SERO that indicated a local
branch. As with all EROs, no local information (local address and branch. As with all EROs, no local information (local address and
any protection subobjects) is carried in the ERO carried in the any protection subobjects) is carried in the ERO carried in the
recovery LSP's outgoing Path message. The SERO that indicated a recovery LSP's outgoing Path message. The SERO that indicated a
local branch MUST be omitted from the recovery LSP's outgoing Path local branch MUST be omitted from the recovery LSP's outgoing Path
message. Note, by default all other received SEROs are passed in the message. Note, by default all other received SEROs are passed in the
recovery LSP's outgoing Path message. SEROs MAY be omitted, from the recovery LSP's outgoing Path message. SEROs MAY be omitted, from the
recovery LSP's outgoing Path message as well as the outgoing Path recovery LSP's outgoing Path message as well as the outgoing Path
message for the LSP being protected when the SERO does not relate to message for the LSP being protected when the SERO does not relate to
the outgoing path message. the outgoing path message.
The resulting Path message is used to create the recovery LSP. From The resulting Path message is used to create the recovery LSP. From
this point on, Standard Path message processing is used in processing this point on, Standard Path message processing is used in processing
the resulting Path message. the resulting Path message.
4.2.1. Resv Message Processing 4.2.1. Branch Failure Handling
During setup, it is possible that a processing node will be unable to
support a requested branch. Additionally, during setup and during
normal operation, PathErr messages may be received at a branch node.
The processing of these events depend on a number of factors.
When a failure or received PathErr message is associated with the LSP
being protected, the event is first processed per standard processing
rules. This includes generation of a standard PathErr message. When
LSP state is removed due to a local failure or the a PathErr message
with the Path_State_Removed flag set (1), the node MUST send a
PathTear message downstream on all other branches.
When a failure or received PathErr message is associated with a
recovery LSP, processing is based on the R-bit in addition to the
Path_State_Removed flag. In all cases, a received PathErr message is
first processed per standard processing rules and the the failure or
received PathErr message SHOULD trigger the generation of a PathErr
message upstream for the LSP being protected. The outgoing PathErr
message SHOULD indicate an error of "Routing Problem/LSP Segment
Protection Failed". The outgoing PathErr message MUST include any
SEROs carried in a received PathErr message. If no SERO is present
in a received PathErr message or when the failure is local, then an
SERO that matches the errored LSP or failed branch MUST be added to
the outgoing PathErr message.
When a PathErr message with the Path_State_Removed flag cleared (0)
is received, the outgoing (upstream) PathErr message SHOULD be sent
with the Path_State_Removed flag cleared (0).
When a PathErr message for a recover LSP with the Path_State_Removed
flag set (1) is received, the processing node MUST examine the R-bit
(as defined below) of the LSP being protected. The R-bit is carried
in the protection object that triggered the initiation of the
recovery LSP. When the R-bit is not set (0), the outgoing (upstream)
PathErr message SHOULD be sent with the Path_State_Removed flag
cleared (0). When the R-bit is set (1), the outgoing (upstream)
PathErr message MUST be sent with the Path_State_Removed flag set
(1).
In all cases where an outgoing (upstream) PathErr message is sent
with the Path_State_Removed flag set (1), all path state for the LSP
being protected MUST be removed and the node MUST send a PathTear
message downstream on all active branches.
4.2.2. Resv Message Processing
Branch nodes will process Resv messages for both recovery LSPs and Branch nodes will process Resv messages for both recovery LSPs and
LSPs being protected. Resv messages are propagated upstream of branch LSPs being protected. Resv messages are propagated upstream of branch
nodes only after a Resv message is received for the protected LSP. nodes only after a Resv message is received for the protected LSP.
Resv messages on recovery LSPs will typically not trigger Resv messages on recovery LSPs will typically not trigger
transmission of upstream Resv messages (for the LSP being protected). transmission of upstream Resv messages (for the LSP being protected).
Exceptions to this include when RROs/SRROs are being collected and Exceptions to this include when RROs/SRROs are being collected and
during certain Admin Status object processing. See below for more during certain Admin Status object processing. See below for more
information on related processing. information on related processing.
4.2.2. Branch Failure Handling
During setup and during normal operation, PathErr messages may be
received at a branch node. In all cases, a received PathErr message
is first processed per standard processing rules. When the PathErr
messages is not on a recovery LSP and the Path_State_Removed flag is
set, then any recovery LSPs associated with the LSP MUST also be torn
down.
If the PathErr messages is on a recovery LSP, receipt of the PathErr
message SHOULD trigger the generation of a PathErr message upstream
on the associated LSP. This outgoing (upstream) PathErr message
SHOULD be sent with the Path_State_Removed flag cleared (0) as only
the recovery LSP is impacted. However, if a branch node sends a
PathErr message with the Path_State_Removed flag set (1), which is
not recommended, the node MUST send a PathTear message downstream on
all other branches.
Additionally, an outgoing PathErr message MUST include any SEROs
carried in a received PathErr message. If no SERO is present in a
received PathErr message, then an SERO that matches the errored LSP
MUST be added to the outgoing PathErr message.
4.2.3. Admin Status Change 4.2.3. Admin Status Change
In general, objects in a recovery LSP are created based on the In general, objects in a recovery LSP are created based on the
corresponding objects in the LSP being protected. The Admin Status corresponding objects in the LSP being protected. The Admin Status
object is created the same way, but it also requires some special object is created the same way, but it also requires some special
coordination at branch nodes. Specifically, in addition to normal coordination at branch nodes. Specifically, in addition to normal
processing, a branch node that receives an Admin Status object in a processing, a branch node that receives an Admin Status object in a
Path message also MUST relay the Admin Status object in a Path on Path message also MUST relay the Admin Status object in a Path on
every recovery LSP. All Path messages MAY be concurrently sent every recovery LSP. All Path messages MAY be concurrently sent
downstream. downstream.
skipping to change at page 12, line 40 skipping to change at page 13, line 17
As with any LSP, any node along a recovery LSP may initiate removal As with any LSP, any node along a recovery LSP may initiate removal
of the recovery LSP. To do this, the node initiating the tear down of the recovery LSP. To do this, the node initiating the tear down
sends a PathErr message with the appropriate Error Code and the sends a PathErr message with the appropriate Error Code and the
Path_State_Removed flag cleared (0) toward the LSP ingress. As Path_State_Removed flag cleared (0) toward the LSP ingress. As
described above, the recovery LSP ingress will propagate the error to described above, the recovery LSP ingress will propagate the error to
the LSP ingress which can then signal the removal of the recovery the LSP ingress which can then signal the removal of the recovery
LSP. LSP.
It is also possible for the node initiating the tear down to remove a It is also possible for the node initiating the tear down to remove a
Recovery LSP in a non-graceful manner. In this case, the initiator Recovery LSP in a non-graceful manner. In this case, the initiator
sends a PathTear message downstream and a PathErr message with Error sends a PathTear message downstream and a PathErr message with a
Code TBD and the Path_State_Removed flag set (1) toward the LSP "Confirmation" indication (error code and value set to zero) and the
ingress node. This manner of non-ingress node tear down is NOT Path_State_Removed flag set (1) toward the LSP ingress node. This
RECOMMENDED as it can result in the removal of the LSP being manner of non-ingress node tear down is NOT RECOMMENDED as it can
protected in some case. result in the removal of the LSP being protected in some case.
4.3.1. Modified Notify Request Object Processing 4.3.1. Modified Notify Request Object Processing
When a node is branching a recovery LSP, it SHOULD include a single When a node is branching a recovery LSP, it SHOULD include a single
Notify Request object in the Path message of the recovery LSP. The Notify Request object in the Path message of the recovery LSP. The
notify node address MUST be set to the router address of the branch notify node address MUST be set to the router address of the branch
node. node.
A branch node SHOULD also add a Notify Request object to the LSP A branch node SHOULD also add a Notify Request object to the LSP
being protected. The notify node address is set to the address used being protected. The notify node address is set to the address used
skipping to change at page 13, line 42 skipping to change at page 14, line 12
of the listed Notify Request objects. Note, to cover certain of the listed Notify Request objects. Note, to cover certain
backwards compatibility scenarios the Notify Request object SHOULD backwards compatibility scenarios the Notify Request object SHOULD
NOT be removed if it is the sole Notify Request object. NOT be removed if it is the sole Notify Request object.
A similar set of rules are applied to the processing of Resv message A similar set of rules are applied to the processing of Resv message
objects to enable merge nodes adding a Notify Request to the Resv objects to enable merge nodes adding a Notify Request to the Resv
message for the protected LSP, arranging the objects as an ordered message for the protected LSP, arranging the objects as an ordered
list or stack. list or stack.
Note this requires the following change to [RFC3473], Section 4.2.1: Note this requires the following change to [RFC3473], Section 4.2.1:
- old text: o old text:
If a message contains multiple Notify_Request objects, only the first If a message contains multiple Notify_Request objects, only the
object is meaningful. Subsequent Notify_Request objects MAY be first object is meaningful. Subsequent Notify_Request objects
ignored and SHOULD NOT be propagated. MAY be ignored and SHOULD NOT be propagated.
- new text: o new text:
If a message contains multiple Notify_Request objects, only the first If a message contains multiple Notify_Request objects, only the
object used is in notification. Subsequent Notify_Request objects first object used is in notification. Subsequent Notify_Request
MUST be propagated in the order received. objects MUST be propagated in the order received.
4.3.2. Modified Notify and Error Message Processing 4.3.2. Modified Notify and Error Message Processing
Branch nodes MUST support the following modification to Notify Branch nodes MUST support the following modification to Notify
message processing. When a branch node receives notification of an message processing. When a branch node receives notification of an
LSP failure and it is unable to recover from that failure, it MUST LSP failure and it is unable to recover from that failure, it MUST
notify the node indicated in the first Notify_Request object received notify the node indicated in the first Notify_Request object received
in the Path message associated with the LSP. in the Path message associated with the LSP.
5. Secondary Record Route Objects 5. Secondary Record Route Objects
skipping to change at page 16, line 17 skipping to change at page 16, line 31
LSP Segment Recovery Flags are carried in the Protection object C- LSP Segment Recovery Flags are carried in the Protection object C-
Type defined in [E2E-RECOVERY]. The format of the flags are: Type defined in [E2E-RECOVERY]. The format of the flags are:
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 | Class-Num(37) | C-Type (TBA) | | Length | Class-Num(37) | C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| Reserved | Seg.Flags | Reserved | |I|R| Reserved | Seg.Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In-Place (I): 1 bit In-Place (I): 1 bit
When set (1) indicates that the desired segment recovery type When set (1) indicates that the desired segment recovery type
indicated in the LSP Segment Recovery Flag is already in place indicated in the LSP Segment Recovery Flag is already in place
for the associated LSP. for the associated LSP.
Required (R): 1 bit
When set (1) indicates that failure to establish the indicated
protection should result in a failure of the LSP being
protected.
(LSP) Segment (Recovery) Flags: 6 bits (LSP) Segment (Recovery) Flags: 6 bits
This field is used to indicate when an upstream node desires This field is used to indicate when an upstream node desires
LSP Segment recovery to be dynamically initiated where LSP Segment recovery to be dynamically initiated where
possible. The values used in this field are identical to the possible. The values used in this field are identical to the
values defined for LSP Flags, see [E2E-RECOVERY]. values defined for LSP Flags, see [E2E-RECOVERY].
See [E2E-RECOVERY] for the definition of other fields. See [E2E-RECOVERY] for the definition of other fields.
6.2. Dynamic Control Procedures 6.2. Dynamic Control Procedures
skipping to change at page 17, line 30 skipping to change at page 17, line 50
updated to ensure uniqueness. The Session object MUST be updated to updated to ensure uniqueness. The Session object MUST be updated to
use the address of the dynamically identified merge node as the use the address of the dynamically identified merge node as the
tunnel endpoint, the tunnel ID MAY be updated, and the extended tunnel endpoint, the tunnel ID MAY be updated, and the extended
tunnel ID MUST be set to the local node. The Protection object is tunnel ID MUST be set to the local node. The Protection object is
updated with the In-Place bit set (1). Any RROs and EROs present in updated with the In-Place bit set (1). Any RROs and EROs present in
the incoming Path message MUST NOT be included in the recovery LSP. A the incoming Path message MUST NOT be included in the recovery LSP. A
new ERO MAY be created based on any path information dynamically new ERO MAY be created based on any path information dynamically
computed by the local node. computed by the local node.
The resulting Path message is used to create the recovery LSP. While The resulting Path message is used to create the recovery LSP. While
the recovery LSP exists, the Protection object in the original Path the recovery LSP exists and unless overridden by local policy, the
message MUST also be updated with the In-Place bit set (1). From Protection object in the original Path message MUST also be updated
this point on, Standard Path message processing is used in processing with the In-Place bit set (1). From this point on, Standard Path
the resulting and original Path messages. message processing is used in processing the resulting and original
Path messages.
The merge node of a dynamically controlled recovery LSP SHOULD reset The merge node of a dynamically controlled recovery LSP SHOULD reset
(0) the In-Place bit in the Protection object of the outgoing Path (0) the In-Place bit in the Protection object of the outgoing Path
message associated with the terminated recovery LSP. message associated with the terminated recovery LSP.
Unlike with explicit control, if the creation of a dynamically Unlike with explicit control, if the creation of a dynamically
identified recovery LSP fails for any reason, the recovery LSP is identified recovery LSP fails for any reason, the recovery LSP is
removed and no error message or indication is sent upstream. With removed and no error message or indication is sent upstream. With
this exception, all the other procedures for explicitly controlled this exception, all the other procedures for explicitly controlled
recovery LSPs apply to dynamically controlled recovery LSPs. These recovery LSPs apply to dynamically controlled recovery LSPs. These
other procedures are defined above in defined in Sections 4.2.1 other procedures are defined above in defined in Sections 4.2.1
through 4.2.4. through 4.2.4.
7. Additional Fast Reroute Considerations 7. Updated RSVP Message Formats
This section is under construction.
8. Updated RSVP Message Formats
This section presents the RSVP message related formats as modified by This section presents the RSVP message related formats as modified by
this document. Where they differ, formats for unidirectional LSPs this document. Where they differ, formats for unidirectional LSPs
are presented separately from bidirectional LSPs. are presented separately from bidirectional LSPs.
The format of a Path message is as follows: The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ] [ <MESSAGE_ID> ]
skipping to change at page 20, line 38 skipping to change at page 20, line 38
[ <SECONDARY_RECORD_ROUTE> ... ] [ <SECONDARY_RECORD_ROUTE> ... ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec> <SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec> | <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <SECONDARY_RECORD_ROUTE> ... ] [ <SECONDARY_RECORD_ROUTE> ... ]
9. Security Considerations 8. Security Considerations
This document introduces no additional security considerations. See This document introduces no additional security considerations. See
[RFC3473] for relevant security considerations. [RFC3473] for relevant security considerations.
10. IANA Considerations 9. IANA Considerations
This document requests assignment of a new Association Type within This document requests assignment of a new Association Type within
the Association object. It also defines bits previously reserved in the Association object. It also defines bits previously reserved in
the Protection object. Both of these objects were defined in [E2E- the Protection object. Both of these objects were defined in [E2E-
RECOVERY]. RECOVERY].
This document also defines the Secondary Explicit Route Objects and This document also defines the Secondary Explicit Route Objects and
Secondary Record Route Objects. Both of these objects of the form Secondary Record Route Objects. Both of these objects of the form
11bbbbbb. The values 198 and 199 respectively are suggested. The c- 11bbbbbb. The values 198 and 199 respectively are suggested. The c-
type values and subobjects associated with the Secondary Explicit type values and subobjects associated with the Secondary Explicit
Route Object should read "Same values as and subobjects as Route Object should read "Same values as and subobjects as
EXPLICIT_ROUTE (C-Num 20)." The c-type values and subobjects EXPLICIT_ROUTE (C-Num 20)." The c-type values and subobjects
associated with the Secondary Record Route Object should read "Same associated with the Secondary Record Route Object should read "Same
values as and subobjects as RECORD_ROUTE (C-Num 21)." values as and subobjects as RECORD_ROUTE (C-Num 21)."
11. Intellectual Property Considerations This document defines the following new error codes:
o "Routing Problem/LSP Segment Protection Failed" (Suggested value =TBD)
10. Intellectual Property Considerations
This section is taken from Section 10.4 of [RFC2026]. This section is taken from Section 10.4 of [RFC2026].
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 22, line 5 skipping to change at page 22, line 5
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional Label Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003. Description", RFC 3471, January 2003.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[E2E-RECOVERY] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors, [E2E-RECOVERY] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors,
"RSVP-TE Extensions in support of End-to-End "RSVP-TE Extensions in support of End-to-End
GMPLS-based Recovery", Work in Progress, GMPLS-based Recovery", Work in Progress,
draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt, draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt,
February 2004. February 2004.
[FRR] Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP [FRR] Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt,
December 2003. August 2004.
12.2. Informative References 11.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
[FUNCT] J.P.Lang and B.Rajagopalan (Editors), "Generalized MPLS [FUNCT] J.P.Lang and B.Rajagopalan (Editors), "Generalized MPLS
Recovery Functional Specification," Internet Draft, Recovery Functional Specification," Internet Draft,
Work in Progress, draft-ietf-ccamp-gmpls-recovery- Work in Progress, draft-ietf-ccamp-gmpls-recovery-
functional-01.txt, September 2003. functional-01.txt, September 2003.
[TERM] E.Mannie and D.Papadimitriou (Editors), "Recovery [TERM] E.Mannie and D.Papadimitriou (Editors), "Recovery
(Protection and Restoration) Terminology for GMPLS," (Protection and Restoration) Terminology for GMPLS,"
Internet Draft, Work in progress, draft-ietf-ccamp- Internet Draft, Work in progress, draft-ietf-ccamp-
gmpls-recovery-terminology-02.txt, May 2003. gmpls-recovery-terminology-02.txt, May 2003.
13. Contributors 12. Authors' Addresses
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Phone: +1 703 847-1801 Phone: +1 703 847-1801
Email: lberger@movaz.com Email: lberger@movaz.com
Igor Bryskin Igor Bryskin
skipping to change at page 23, line 33 skipping to change at page 23, line 33
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel.be
14. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. This Copyright (C) The Internet Society (2004). This document is subject
document and translations of it may be copied and furnished to to the rights, licenses and restrictions contained in BCP 78, and
others, and derivative works that comment on or otherwise explain it except as set forth therein, the authors retain all their rights.
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be This document and the information contained herein are provided on an
revoked by the Internet Society or its successors or assigns. This "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
document and the information contained herein is provided on an "AS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OR FITNESS FOR A PARTICULAR PURPOSE.
Generated on: Mon Mar 29 17:52:52 2004 14. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Generated on: Sun Oct 24 21:29:04 2004
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/