draft-ietf-ccamp-gmpls-segment-recovery-01.txt   draft-ietf-ccamp-gmpls-segment-recovery-02.txt 
Internet Draft Louis Berger (Movaz Networks) Internet Draft Louis Berger (Movaz Networks)
Updates: 3473 Igor Bryskin (Movaz Networks) Updates: 3473 Igor Bryskin (Movaz Networks)
Category: Standards Track Dimitri Papadimitriou (Alcatel) Category: Standards Track Dimitri Papadimitriou (Alcatel)
Expiration Date: April 2005 Adrian Farrel (Old Dog Consulting) Expiration Date: November 2005 Adrian Farrel (Old Dog Consulting)
October 2004 May 2005
GMPLS Based Segment Recovery GMPLS Based Segment Recovery
draft-ietf-ccamp-gmpls-segment-recovery-01.txt draft-ietf-ccamp-gmpls-segment-recovery-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. 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 a "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html 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 label switched path (LSP) segment protection and restoration.
intended to be compliment and be consistent with the Extensions for These extensions are intended to complement and be consistent with
End-to-End GMPLS-based Recovery. Implications and interactions with the Extensions for End-to-End GMPLS-based Recovery. Implications and
Fast Reroute are also addressed. This document also updates the interactions with Fast Reroute are also addressed. This document
handling of Notify_Request objects specified in [RFC3473]. also updates the handling of Notify_Request objects.
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 Recovery Type Processing .................................. 7
3.2.2 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 Branch Failure Handling ................................... 10 4.2.1 Branch Failure Handling ................................... 11
4.2.2 Resv Message Processing ................................... 11 4.2.2 Resv Message Processing ................................... 12
4.2.3 Admin Status Change ....................................... 12 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 .......................... 13 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 .................................................... 15
5.2 Path Processing ........................................... 15 5.2 Path Processing ........................................... 15
5.3 Resv Processing ........................................... 15 5.3 Resv Processing ........................................... 15
6 Dynamic Control of LSP Segment Recovery ................... 16 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 ................................ 17 6.2 Dynamic Control Procedures ................................ 17
7 Updated RSVP Message Formats .............................. 18 7 Updated RSVP Message Formats .............................. 18
8 Security Considerations ................................... 20 8 Security Considerations ................................... 20
9 IANA Considerations ....................................... 21 9 IANA Considerations ....................................... 21
10 Intellectual Property Considerations ...................... 21 10 References ................................................ 21
11 References ................................................ 22 10.1 Normative References ...................................... 21
11.1 Normative References ...................................... 22 10.2 Informative References .................................... 22
11.2 Informative References .................................... 22 11 Authors' Addresses ........................................ 22
12 Authors' Addresses ........................................ 23 12 Full Copyright Statement .................................. 23
13 Full Copyright Statement .................................. 23 13 Intellectual Property ..................................... 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].
skipping to change at page 3, line 39 skipping to change at page 3, line 39
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], but on a segment,
portion of the LSP, basis. The extensions allow (a) the signaling of or portion of the LSP, basis. The extensions allow (a) the signaling
desired LSP segment protection type, (b) upstream nodes to optionally of desired LSP segment protection type, (b) upstream nodes to
identify where segment protection starts and stops, (c) the optional optionally identify where segment protection starts and stops, (c)
identification of hops used on protection segments, and (d) the the optional identification of hops used on protection segments, and
reporting of paths used to protect an LSP. The extensions also widen (d) the reporting of paths used to protect an LSP. The extensions
the topological scope over which protection can be supported. They also widen the topological scope over which protection can be
allow recovery segments that protect against an arbitrary number of supported. They allow recovery segments that protect against an
nodes and links. They enable overlapping protection and nested arbitrary number of nodes and links. They enable overlapping
protection. These extensions are intended to be compatible with, and protection and nested protection. These extensions are intended to
in some cases used with Fast Reroute. 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 particular portion of a network used by an
an LSP. LSP.
Consider the following topology: Consider the following topology:
A---B---C---D---E---F A---B---C---D---E---F
\ / \ /
G---I G---I
In this topology, end-to-end protection and recovery is not possible In this topology, end-to-end protection and recovery is not possible
for an LSP going between node A and node F, but it is possible to for an LSP going between node A and node F, but it is possible to
protect/recover a portion of the LSP. Specifically, if the LSP uses protect/recover a portion of the LSP. Specifically, if the LSP uses
a working path of [A,B,C,D,E,F] then a protection or restoration LSP a working path of [A,B,C,D,E,F] then a protection or restoration LSP
skipping to change at page 6, line 7 skipping to change at page 6, line 7
the Resv message of associated recovery LSP into a new SRRO object. 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. 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 for 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-
directional Protection, see Section 6: and 1:1 Protection With Extra directional Protection, see Section 6: and 1:1 Protection With Extra
Traffic, see Section 7. The segment protection forms of these Traffic, see Section 7. The segment protection forms of these
protection approaches all operate much like their end-to-end protection approaches all operate much like their end-to-end
counterparts. Each behaves just like there end-to-end counterparts, counterparts. Each behaves just like its end-to-end counterpart,
with the exception that the protection LSP protects only a portion of with the exception that the protection LSP protects only a portion of
the working LSP. The type of protection to be used on a segment the working LSP. The type of protection to be used on a segment
protection LSP is indicated, to the protection LSP's ingress, using protection LSP is indicated, to the protection LSP's ingress, using
the protection SERO subobject defined in Section 4.1. the protection SERO subobject defined in Section 4.1.
The switch-over processing for segment 1+1 Bi-directional protection The switch-over processing for segment 1+1 Bi-directional protection
and 1:1 Protection With Extra Traffic follows the same procedures as and 1:1 Protection With Extra Traffic follows the same procedures as
end-to-end protection forms, see Section 6.2 and Section 7.2 for end-to-end protection forms, see Section 6.2 and Section 7.2 for
details. details.
skipping to change at page 6, line 40 skipping to change at page 6, line 40
exactly like their end-to-end counterparts, with the exception that exactly like their end-to-end counterparts, with the exception that
the restoration LSP recovers only a portion of the working LSP. The the restoration LSP recovers only a portion of the working LSP. The
type of re-routing or restoration to be used on a segment restoration type of re-routing or restoration to be used on a segment restoration
LSP is indicated, to the restoration LSP's ingress, using the new LSP is indicated, to the restoration LSP's ingress, using the new
protection SERO subobject. protection SERO subobject.
3. Association Object 3. Association Object
The Association object is used association of segment protection LSPs The Association object is used association of segment protection LSPs
when [FRR] isn't being used. The Association object is defined in when [FRR] isn't being used. The Association object is defined in
[E2E-RECOVERY]. In this document we define a new type to support [E2E-RECOVERY]. In this document we define a new Association Type
make before break, formats and procedures defined in [E2E-RECOVERY] field value to support make before break, formats and procedures
are not otherwise modified. defined in [E2E-RECOVERY] are not otherwise modified.
3.1. Format 3.1. Format
Association Type: 16 bits Association Type: 16 bits
Value Type Value Type
----- ---- ----- ----
2 Resource Sharing (R) 2 Resource Sharing (R)
See [E2E-RECOVERY] for the definition of other fields and other See [E2E-RECOVERY] for the definition of other fields and other
values. values.
3.2. Procedures 3.2. Procedures
The Association object is used to associate different LSPs with each The Association object is used to associate different LSPs with each
other. In the protection and restoration context, the object is used other. In the protection and restoration context, the object is used
to associate a recovery LSP with the LSP it is protecting. It is to associate a recovery LSP with the LSP it is protecting. The
also used to support resource sharing during make-before-break. This Association object is also used to support resource sharing during
object MUST NOT be used when association is made according to the make-before-break. This object MUST NOT be used when association is
methods defined in [FRR]. made according to the methods defined in [FRR].
3.2.1. Resource Sharing Association Type Processing 3.2.1. Recovery Type Processing
Recovery type processing procedures are the same as those defined in
[E2E-RECOVERY], but processing and identification occurs with respect
to segment recovery LSPs. Note that this means that multiple
Association objects of type recovery may be present on an LSP.
3.2.2. Resource Sharing Association Type Processing
The Association object with an Association Type with the value The Association object with an Association Type with the value
Resource Sharing is used to enable resource sharing during make- Resource Sharing is used to enable resource sharing during make-
before-break. Resource sharing during make-before-break is defined before-break. Resource sharing during make-before-break is defined
in [RFC3209]. The defined support only works with LSPs that share in [RFC3209]. The defined support only works with LSPs that share
the same LSP egress. With the introduction of segment recovery LSPs, the same LSP egress. With the introduction of segment recovery LSPs,
it is now possible for an LSP end-point to change during make-before- it is now possible for an LSP end-point to change during make-before-
break. break.
A node includes an Association object with a Resource Sharing A node includes an Association object with a Resource Sharing
Association Type in outgoing an Path message when it wishes to Association Type in outgoing an Path message when it wishes to
indicate resource sharing across an associated set of LSPs. The indicate resource sharing across an associated set of LSPs. The
Association Source is set to the branch node's router address. The Association Source is set to the originating node's router address.
Association ID MUST be set to a value that uniquely identifies the The Association ID MUST be set to a value that uniquely identifies
association of LSPs. This MAY be set to the upstream LSP's LSP ID. the association of LSPs. This MAY be set to the working LSP's LSP
Once included, an Association object with a Resource Sharing ID. Once included, an Association object with a Resource Sharing
Association Type SHOULD NOT be removed from the Path messages Association Type SHOULD NOT be removed from the Path messages
associated with an LSP. associated with an LSP.
When a node is branching an LSP and the associated upstream Path
messages is received with an Association object with a Resource
Sharing type, the branch node inserts a new Association object with a
Resource Sharing type in the Path message of the new LSP. The
Association Source is set to the branch node's router address. The
Association ID MUST be set to a value that uniquely identifies the
association of LSPs. This MAY be set to the recovery LSP's LSP ID.
Any node processing a Path message for which it does not have Any node processing a Path message for which it does not have
matching state, and which contains a Association object with a matching state, and which contains a Association object with a
Resource Sharing type, examines existing LSPs for matching Resource Sharing type, examines existing LSPs for matching
Association Type, Association Source and Association ID values. If Association Type, Association Source and Association ID values. If
any match is found, then [RFC3209] style resource sharing SHOULD be any match is found, then [RFC3209] style resource sharing SHOULD be
provided between the new and old LSPs. See [RFC3209] for additional provided between the new and old LSPs. See [RFC3209] for additional
details. details.
4. Explicit Control of LSP Segment Recovery 4. Explicit Control of LSP Segment Recovery
Secondary Explicit Route objects, or SEROs, may be used to indicate Secondary Explicit Route objects, or SEROs, may be used to indicate
the branch and merge nodes of recovery LSPs. They may also provide the branch and merge nodes of recovery LSPs. They may also provide
additional information that is to be carried in a recovery LSP's ERO. additional information that is to be carried in a recovery LSP's ERO.
When upstream control of branch and merge nodes are not desired, When upstream control of branch and merge nodes is not desired, SEROs
SEROs are not used. are not used.
4.1. Secondary Explicit Route Object Format 4.1. Secondary Explicit Route Object Format
The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an
EXPLICIT_ROUTE object. This includes the definition of subobjects EXPLICIT_ROUTE object. This includes the definition of subobjects
defined for EXPLICIT_ROUTE object. The class of the defined for EXPLICIT_ROUTE object. The class of the
SECONDARY_EXPLICIT_ROUTE object is TBA (of form 11bbbbbb). SECONDARY_EXPLICIT_ROUTE object is TBA by IANA (of form 11bbbbbb).
4.1.1. Protection Subobject 4.1.1. Protection Subobject
The protection subobject is not valid for use with the Explicit and The protection subobject is not valid for use with the Explicit and
Record Route objects and MUST NOT be included in those objects. Record Route objects and MUST NOT be included in those objects.
The format of the Protection Subobject is defined as follows: The format of the Protection Subobject is defined as follows:
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
skipping to change at page 9, line 13 skipping to change at page 9, line 13
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L-bit L-bit
This is defined in [RFC3209] and MUST be set to zero for This is defined in [RFC3209] and MUST be set to zero for
protection subobjects. protection subobjects.
Type Type
37 Protection 37 Protection
Length
As defined in [RFC3209], Section 4.3.3.
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
C-Type C-Type
The C-Type of the included Protection object. The C-Type of the included Protection object.
PROTECTION Object Contents PROTECTION Object Contents
The contents of the Protection object with the format matching The contents of the Protection object, with the format matching
the indicated C-Type, excluding the object header. the indicated C-Type, excluding the object header.
4.2. Explicit Control Procedures 4.2. Explicit Control Procedures
SEROs are carried in Path messages and indicate at which node a SEROs are carried in Path messages and indicate at which node a
recovery LSP is to be initiated relative to the LSP carrying the recovery LSP is to be initiated relative to the LSP carrying the
SERO. More than one SERO MAY be present in a Path message. SERO. More than one SERO MAY be present in a Path message.
To indicate the branch and merge nodes of a recovery LSPs, an SERO is To indicate the branch and merge nodes of a recovery LSPs, an SERO is
created and added to the Path message of the LSP being recovered. created and added to the Path message of the LSP being recovered.
skipping to change at page 12, line 43 skipping to change at page 13, line 10
message per standard processing, see [RFC3209] and [RFC2205], and message per standard processing, see [RFC3209] and [RFC2205], and
MUST also relay a PathTear on every recovery LSP. All PathTear MUST also relay a PathTear on every recovery LSP. All PathTear
messages (received from upstream and locally originated) may be messages (received from upstream and locally originated) may be
concurrently sent downstream. concurrently sent downstream.
4.2.4.2. Tear Down With Admin Status Change 4.2.4.2. Tear Down With Admin Status Change
Per [RFC3473], the ingress node originates a Path message with the D Per [RFC3473], the ingress node originates a Path message with the D
and R bits set in the Admin Status object. The admin status change and R bits set in the Admin Status object. The admin status change
procedure defined above, see Section 4.2.3, MUST then be followed. procedure defined above, see Section 4.2.3, MUST then be followed.
Once the ingress receives all expected Resv messages MUST follow the Once the ingress receives all expected Resv messages, it MUST follow
tear down procedure described in the Section 4.2.4. the tear down procedure described in Section 4.2.4.1.
4.3. Tear Down From Non-Ingress Nodes 4.3. Tear Down From Non-Ingress Nodes
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.
skipping to change at page 14, line 37 skipping to change at page 15, line 7
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
Secondary Record Route objects, or SRROs, are used to record the path Secondary Record Route objects, or SRROs, are used to record the path
used by recovery LSPs. used by recovery LSPs.
5.1. Format 5.1. Format
The format of a SECONDARY_RECORD_ROUTE object is the same as an The format of a SECONDARY_RECORD_ROUTE object is the same as a
RECORD_ROUTE object, Class number 21. This includes the definition RECORD_ROUTE object, Class number 21. This includes the definition
of subobjects defined for RECORD_ROUTE object. The class of the of subobjects defined for RECORD_ROUTE object. The class of the
SECONDARY_RECORD_ROUTE object is TBA (of form 11bbbbbb). SECONDARY_RECORD_ROUTE object is TBA by IANA (of form 11bbbbbb).
The protection subobject defined in [E2E-RECOVERY] can also be used The protection subobject defined above can also be used in
in SECONDARY_RECORD_ROUTE objects. SECONDARY_RECORD_ROUTE objects.
5.2. Path Processing 5.2. Path Processing
SRROs may be carried in Path messages and indicate the presence of SRROs may be carried in Path messages and indicate the presence of
upstream recovery LSPs. More than one SRRO MAY be add and present in upstream recovery LSPs. More than one SRRO MAY be add and present in
a Path message. a Path message.
Any received SRRO, MUST be transmitted by transit nodes, without Any received SRRO, MUST be transmitted by transit nodes, without
modification, in the corresponding outgoing Path message. modification, in the corresponding outgoing Path message.
skipping to change at page 16, line 21 skipping to change at page 16, line 30
Segment Recovery Flags are used to indicate when LSP segment recovery Segment Recovery Flags are used to indicate when LSP segment recovery
is desired. When these bits are set branch and merge nodes are is desired. When these bits are set branch and merge nodes are
dynamically identified. dynamically identified.
Note, the procedures defined in this section parallel the explicit Note, the procedures defined in this section parallel the explicit
control procedures defined above in Section 4.2. The primary control procedures defined above in Section 4.2. The primary
difference is in creation of a recovery LSP's ERO. difference is in creation of a recovery LSP's ERO.
6.1. Modified Protection Object Format 6.1. Modified Protection Object Format
LSP Segment Recovery Flags are carried in the Protection object C- LSP Segment Recovery Flags are carried in the Protection object of
Type defined in [E2E-RECOVERY]. The format of the flags are: the same C-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|R| Reserved | Seg.Flags | Reserved | |I|R| Reserved | Seg.Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 41 skipping to change at page 17, line 4
|I|R| 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 Required (R): 1 bit
When set (1) indicates that failure to establish the indicated When set (1) indicates that failure to establish the indicated
protection should result in a failure of the LSP being protection should result in a failure of the LSP being
protected. protected.
(LSP) Segment (Recovery) Flags: 6 bits Segment Recovery Flags (Seg.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 20, line 40 skipping to change at page 20, line 40
<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> ... ]
8. Security Considerations 8. Security Considerations
This document introduces no additional security considerations. See This document introduces new message objects for use in GMPLS
[RFC3473] for relevant security considerations. signaling [RFC3473]. It does not introduce any new signaling
messages, nor change the relationship between LSRs that are adjacent
in the control plane.
The procedures defined in this document result in an increase in the
amount of topology information carried in signaling messages since
the presence of SEROs and SRROs necessarily means that there is more
information about LSP paths carried than in simple EROs and RROs.
Thus, in the event of the interception of a signaling message,
slightly more could be deduced about the state of the network than
was previously the case, but this is judged to be a very minor
security risk as this information is already available via routing.
Otherwise, this document introduces no additional security
considerations. See [RFC3473] for relevant security considerations.
9. 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. A new
type values and subobjects associated with the Secondary Explicit subobject is also defined for the use with the Secondary Explicit
Route Object should read "Same values as and subobjects as Route Objects and Secondary Record Route Objects. The c-type values
EXPLICIT_ROUTE (C-Num 20)." The c-type values and subobjects and subobjects associated with the Secondary Explicit Route Object
associated with the Secondary Record Route Object should read "Same should read "Same values and subobjects as EXPLICIT_ROUTE (C-Num 20)
values as and subobjects as RECORD_ROUTE (C-Num 21)." object. With the additonal subobject type: 37 Protection." The c-
type values and subobjects associated with the Secondary Record Route
Object should read "Same values as and subobjects as RECORD_ROUTE (C-
Num 21) object. With the additonal subobject type: 37 Protection."
This document defines the following new error codes: This document defines the following new error codes:
o "Routing Problem/LSP Segment Protection Failed" (Suggested value =TBD) o "Routing Problem/LSP Segment Protection Failed" (Suggested value =TBD)
10. Intellectual Property Considerations 10. References
This section is taken from Section 10.4 of [RFC2026].
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
11. References
11.1. Normative References 10.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. April 2005.
[FRR] Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt,
August 2004.
11.2. Informative References 10.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-04.txt, April 2005.
[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-06.txt, March 2005.
12. Authors' Addresses [FRR] Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt,
August 2004.
11. 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 15
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
13. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Intellectual Property 13. Intellectual Property
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 Rights or other rights that might be claimed to Intellectual Property Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at line 1017 skipping to change at line 1018
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
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 that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Generated on: Sun Oct 24 21:29:04 2004 Generated on: Thu May 26 11:03:09 EDT 2005
 End of changes. 

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