draft-ietf-ccamp-gmpls-segment-recovery-03.txt   rfc4873.txt 
Internet Draft Lou Berger (LabN)
Updates: 3473, [E2E-RECOVERY] Igor Bryskin (Movaz Networks)
Category: Standards Track Dimitri Papadimitriou (Alcatel)
Expiration Date: April 2007 Adrian Farrel (Old Dog Consulting)
October 2006
GMPLS Based Segment Recovery
draft-ietf-ccamp-gmpls-segment-recovery-03.txt
Status of this Memo Network Working Group L. Berger
Request for Comments: 4873 LabN Consulting
By submitting this Internet-Draft, each author represents that any Updates: 3473, 4872 I. Bryskin
applicable patent or other IPR claims of which he or she is aware Category: Standards Track ADVA Optical
have been or will be disclosed, and any of which he or she becomes D. Papadimitriou
aware will be disclosed, in accordance with Section 6 of BCP 79. Alcatel
A. Farrel
Old Dog Consulting
GMPLS Segment Recovery
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The IETF Trust (2007).
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 label switched path (LSP) segment protection and restoration. support label switched path (LSP) segment protection and restoration.
These extensions are intended to complement and be consistent with These extensions are intended to complement and be consistent with
the Extensions for End-to-End GMPLS-based Recovery. Implications and the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).
interactions with Fast Reroute are also addressed. This document Implications and interactions with fast reroute are also addressed.
also updates the handling of Notify_Request objects. This document also updates the handling of NOTIFY_REQUEST objects.
Contents
1 Introduction .............................................. 3
2 Segment Recovery .......................................... 4
2.1 Segment Protection ........................................ 6
2.2 Segment Re-routing and Restoration ........................ 6
3 Association Object ........................................ 6
3.1 Format .................................................... 7
3.2 Procedures ................................................ 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.1 Secondary Explicit Route Object Format .................... 8
4.1.1 Protection Subobject ...................................... 8
4.2 Explicit Control Procedures ............................... 9
4.2.1 Branch Failure Handling ................................... 11
4.2.2 Resv Message Processing ................................... 12
4.2.3 Admin Status Change ....................................... 12
4.2.4 Recovery LSP Tear Down .................................... 12
4.3 Tear Down From Non-Ingress Nodes .......................... 13
4.3.1 Modified Notify Request Object Processing ................. 13
4.3.2 Modified Notify and Error Message Processing .............. 14
5 Secondary Record Route Objects ............................ 15
5.1 Format .................................................... 15
5.2 Path Processing ........................................... 15
5.3 Resv Processing ........................................... 15
6 Dynamic Control of LSP Segment Recovery ................... 16
6.1 Modified Protection Object Format ......................... 16
6.2 Dynamic Control Procedures ................................ 17
7 Updated RSVP Message Formats .............................. 18
8 Security Considerations ................................... 20
9 IANA Considerations ....................................... 21
9.1 New Association Type Assignment ........................... 21
9.2 Definition of Protection Object Reserved Bits ............. 21
9.3 Secondary Explicit Route Object ........................... 21
9.4 Secondary Record Route Object ............................. 22
9.5 New Error Code ............................................ 22
9.6 Use of Not Yet Assigned Protection Object C-type .......... 22
10 References ................................................ 23
10.1 Normative References ...................................... 23
10.2 Informative References .................................... 23
11 Authors' Addresses ........................................ 24
12 Full Copyright Statement .................................. 24
13 Intellectual Property ..................................... 25
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Table of Contents
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In addition, the reader is assumed to be familiar with the 1. Introduction ....................................................3
terminology used in [RFC3209], [RFC3471], [RFC3473] as well as 1.1. Conventions Used in This Document ..........................3
[RFC4427], [RFC4426], [E2E-RECOVERY] and [RFC4090]. 2. Segment Recovery ................................................4
2.1. Segment Protection .........................................6
2.2. Segment Re-routing and Restoration .........................6
3. ASSOCIATION Object ..............................................6
3.1. Format .....................................................7
3.2. Procedures .................................................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.1. Secondary Explicit Route Object Format .....................8
4.1.1. Protection Subobject ................................8
4.2. Explicit Control Procedures ................................9
4.2.1. Branch Failure Handling ............................10
4.2.2. Resv Message Processing ............................11
4.2.3. Admin Status Change ................................12
4.2.4. Recovery LSP Teardown ..............................12
4.3. Teardown From Non-Ingress Nodes ...........................12
4.3.1. Modified NOTIFY_REQUEST Object Processing ..........13
4.3.2. Modified Notify and Error Message Processing .......14
5. Secondary Record Route Objects .................................14
5.1. Format ....................................................14
5.2. Path Processing ...........................................15
5.3. Resv Processing ...........................................15
6. Dynamic Control of LSP Segment Recovery ........................16
6.1. Modified PROTECTION Object Format .........................16
6.2. Dynamic Control Procedures ................................17
7. Updated RSVP Message Formats ...................................18
8. Security Considerations ........................................20
9. IANA Considerations ............................................21
9.1. New Association Type Assignment ...........................21
9.2. Definition of PROTECTION Object Reserved Bits .............21
9.3. Secondary Explicit Route Object ...........................21
9.4. Secondary Record Route Object .............................21
9.5. New Error Code ............................................22
9.6. Use of PROTECTION Object C-type ...........................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................23
1. Introduction 1. Introduction
[RFC4427] covers multiple types of protection, including end-to-end [RFC4427] covers multiple types of protection, including end-to-end
and segment based approaches. [E2E-RECOVERY], RSVP-TE Extensions in and segment-based approaches. "RSVP-TE Extensions in Support of
support of End-to-End GMPLS-based Recovery, defines a set of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)
extensions to support multiple types of recovery. The supported Recovery" [RFC4872] defines a set of extensions to support multiple
types include 1+1 unidirectional/ 1+1 bi-directional protection, LSP types of recovery. The supported types include 1+1 unidirectional/
protection with extra-traffic (including 1:N protection with extra- 1+1 bidirectional protection, LSP protection with extra-traffic
traffic), pre-planned LSP re-routing without extra-traffic (including (including 1:N protection with extra-traffic), pre-planned LSP re-
shared mesh), and full LSP re-routing. In all cases, the recovery is routing without extra-traffic (including shared mesh), and full LSP
provided on an end-to-end basis, i.e., the ingress and egress nodes re-routing. In all cases, the recovery is provided on an end-to-end
of both the protected and the protecting LSP are the same. basis, i.e., the ingress and egress nodes of both the protected and
the protecting LSP are the same.
[RFC4090] provides a form of segment recovery for packet MPLS-TE [RFC4090] provides a form of segment recovery for packet MPLS-TE
networks. Two methods of Fast Reroute are defined in [RFC4090]. The networks. Two methods of fast reroute are defined in [RFC4090]. 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 that 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 [RFC4872].
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 switch capable) 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], but on a segment, set of recovery types supported by [RFC4872], but on a segment, or
or portion of the LSP, basis. The extensions allow (a) the signaling portion of the LSP, basis. The extensions allow (a) the signaling of
of desired LSP segment protection type, (b) upstream nodes to desired LSP segment protection type, (b) upstream nodes to optionally
optionally identify where segment protection starts and stops, (c) identify where segment protection starts and stops, (c) the optional
the optional identification of hops used on protection segments, and identification of hops used on protection segments, and (d) the
(d) the reporting of paths used to protect an LSP. The extensions reporting of paths used to protect an LSP. The extensions also widen
also widen the topological scope over which protection can be the topological scope over which protection can be supported. They
supported. They allow recovery segments that protect against an allow recovery segments that protect against an arbitrary number of
arbitrary number of nodes and links. They enable overlapping nodes and links. They enable overlapping protection and nested
protection and nested protection. These extensions are intended to protection. These extensions are intended to be compatible with fast
be compatible with, and in some cases used with Fast Reroute. reroute, and in some cases used with fast reroute.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In addition, the reader is assumed to be familiar with the
terminology used in [RFC3209], [RFC3471], and [RFC3473], as well as
[RFC4427], [RFC4426], [RFC4872], and [RFC4090].
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 particular portion of a network used by an failure, or failure over a particular portion of a network used by an
LSP. LSP.
Consider the following topology: Consider the following topology:
skipping to change at page 4, line 14 skipping to change at page 4, line 14
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 particular portion of a network used by an failure, or failure over a particular portion of a network used by 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
can be established along the path [C,G,I,E]. This LSP protects can be established along the path [C,G,I,E]. This LSP protects
against failures on spans {C,D} and {D,E} as well as a failure of against failures on spans {C,D} and {D,E}, as well as a failure of
node D. This form of protection/restoration is referred to as node D. This form of protection/restoration is referred to as
Segment Protection and Segment Restoration, or Segment Recovery Segment Protection and Segment Restoration, or as Segment Recovery,
collectively. The LSP providing the protection or restoration is collectively. The LSP providing the protection or restoration is
referred to as a segment protection LSP or a segment restoration LSP. referred to as a segment protection LSP or a segment restoration LSP.
The term segment recovery LSP is used to cover either a segment The term "segment recovery LSP" is used to cover either a segment
protection LSP or a segment restoration LSP. The term branch node is protection LSP or a segment restoration LSP. The term "branch node"
used to refer to a node that initiates a recovery LSP, e.g., node C is used to refer to a node that initiates a recovery LSP, e.g., node
in the figure shown above. This is equivalent to the point of local C in the figure shown above. This is equivalent to the point of
repair (PLR) used in [RFC4090]. As with [RFC4090], the term merge local repair (PLR) used in [RFC4090]. As with [RFC4090], the term
node is used to refer to a node that terminates a recovery LSP, e.g., "merge node" is used to refer to a node that terminates a recovery
node E in the figure shown above. LSP, e.g., node E in the figure shown above.
Segment protection or restoration is signaled using a working LSP and Segment protection or restoration is signaled using a working LSP and
one or more segment recovery LSPs. Each segment recovery LSP is one or more segment recovery LSPs. Each segment recovery LSP is
signaled as an independent LSP. Specifically, the Sender_Template signaled as an independent LSP. Specifically, the Sender_Template
object uses the IP address of the node originating the recovery path, object uses the IP address of the node originating the recovery path,
e.g., node C in the topology shown above, and the Session object e.g., node C in the topology shown above, and the Session object
contains the IP address of the node terminating the recovery path, contains the IP address of the node terminating the recovery path,
e.g., node E shown above. There is no specific requirement on LSP ID e.g., node E shown above. There is no specific requirement on LSP ID
value, Tunnel ID and Extended Tunnel ID. Values for these fields are value, Tunnel ID, and Extended Tunnel ID. Values for these fields
selected normally, including consideration for make-before-break. are selected normally, including consideration for the make-before-
Intermediate nodes follow standard signaling procedures when break concept (as described in [RFC3209]). Intermediate nodes follow
processing segment recovery LSPs. A segment recovery LSP may be standard signaling procedures when processing segment recovery LSPs.
protected itself using segment or end-to-end protection/restoration. A segment recovery LSP may be protected itself using segment or end-
Note, in PSC environments it may be desirable to construct the to-end protection/restoration. Note, in PSC environments, it may be
Sender_Template and Session objects per [RFC4090]. desirable to construct the Sender_Template and Session objects per
[RFC4090].
When [RFC4090] isn't being used, the association between segment When [RFC4090] isn't being used, the association between segment
recovery LSPs with other LSPs is indicated using the Association recovery LSPs with other LSPs is indicated using the ASSOCIATION
object defined in [E2E-RECOVERY]. The Association object is used to object defined in [RFC4872]. The ASSOCIATION object is used to
associate recovery LSPs with the LSP they are protecting. Working associate recovery LSPs with the LSP they are protecting. Working
and protecting LSPs, as well as primary and secondary LSPs, are and protecting LSPs, as well as primary and secondary LSPs, are
identified using LSP Status as described in [E2E-RECOVERY]. The O- identified using LSP Status as described in [RFC4872]. The O-bit in
bit in the segment flags portion of the Protection object is used to the segment flags portion of the PROTECTION object is used to
identify when a recovery LSP is carrying the normal (active) traffic. identify when a recovery LSP is carrying the normal (active) traffic.
An upstream node can permit downstream nodes to dynamically identify An upstream node can permit downstream nodes to dynamically identify
branch and merge points by setting the desired LSP segment protection branch and merge points by setting the desired LSP segment protection
bits in the Protection object. These bits are defined below. bits in the PROTECTION object. These bits are defined below.
Optionally, an upstream node, usually the ingress node, can identify Optionally, an upstream node, usually the ingress node, can identify
the endpoints of a segment recovery LSP. This is accomplished using the endpoints of a segment recovery LSP. This is accomplished using
a new object. This object uses the same format as an ERO and is a new object. This object uses the same format as an Explicit Route
referred to as a Secondary Explicit Route object or SERO, see section Object (ERO) and is referred to as a Secondary Explicit Route object
4.1. SEROs also support a new subobject to indicate the type of (SERO); see Section 4.1. SEROs also support a new subobject to
protection or restoration to be provided. At a minimum an SERO will indicate the type of protection or restoration to be provided. At a
indicate a recovery LSP's initiator, protection/restoration type and minimum, an SERO will indicate a recovery LSP's initiator,
terminator. Standard ERO semantics, see [RFC3209], can optionally be protection/restoration type and terminator. Standard ERO semantics
used within and SERO to explicitly control the recovery LSP. A (see [RFC3209]) can optionally be used within and SERO to explicitly
Secondary Record Route object or SRRO is defined for recording the control the recovery LSP. A Secondary Record Route object (SRRO) is
path of a segment recovery LSP, see section 5. defined for recording the 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. It is also possible to control the handling of a recovery LSP. It is also possible to control the handling of a
failure to establish a recovery LSP. failure to establish a recovery LSP.
SRROs are carried in Path messages between the node terminating a SRROs are carried in Path messages between the node terminating a
recovery LSP, the merge node, and the egress. SRROs are used in Resv recovery LSP, the merge node, and the egress. SRROs are used in Resv
messages between a branch node and the ingress. The merge node of a messages between a branch node and the ingress. The merge node of a
recovery LSP creates an SRRO by copying the RRO from the Path message recovery LSP creates an SRRO by copying the RRO from the Path message
of the associated recovery LSP into a new SRRO object. Any SRROs of the associated recovery LSP into a new SRRO object. Any SRROs
present in the recovery LSP's Path message are also copied. The present in the recovery LSP's Path message are also copied. The
branch node of a recovery LSP creates an SRRO by copying the RRO from 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. 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 for end-to-end protection are defined in [E2E- Three approaches for end-to-end protection are defined in [RFC4872]:
RECOVERY]: 1+1 Unidirectional Protection, see Section 5; 1+1 Bi- 1+1 Unidirectional Protection (Section 5), 1+1 Bidirectional
directional Protection, see Section 6: and 1:1 Protection With Extra Protection (Section 6), and 1:1 Protection With Extra-Traffic
Traffic, see Section 7. The segment protection forms of these (Section 7). The segment protection forms of these protection
protection approaches all operate much like their end-to-end approaches all operate much like their end-to-end counterparts. Each
counterparts. Each behaves just like its end-to-end counterpart, behaves just like its end-to-end counterpart, with the exception that
with the exception that the protection LSP protects only a portion of the protection LSP protects only a portion of the working LSP. The
the working LSP. The type of protection to be used on a segment type of protection to be used on a segment protection LSP is
protection LSP is indicated, to the protection LSP's ingress, using indicated, to the protection LSP's ingress, using the protection SERO
the protection SERO subobject defined in Section 4.1. 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 Bidirectional 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 Sections 6.2 and 7.2 of [RFC4872]
details. for details.
2.2. Segment Re-routing and Restoration 2.2. Segment Re-routing and Restoration
Three re-routing and restoration approaches are defined [E2E- Three re-routing and restoration approaches are defined in [RFC4872]:
RECOVERY]: Re-routing without Extra-Traffic, see Section 8; Shared- Re-routing without Extra-Traffic (Section 8), Shared-Mesh Restoration
Mesh Restoration, see Section 9; (Full) LSP Re-routing, see Section (Section 9), (Full) LSP Re-routing (Section 11). As with protection,
11. As with protection, these approaches are supported on a segment these approaches are supported on a segment basis. The segment forms
basis. The segment forms of re-routing and restoration operate of re-routing and restoration operate exactly like their end-to-end
exactly like their end-to-end counterparts, with the exception that counterparts, with the exception that the restoration LSP recovers
the restoration LSP recovers only a portion of the working LSP. The only a portion of the working LSP. The type of re-routing or
type of re-routing or restoration to be used on a segment restoration restoration to be used on a segment restoration LSP is indicated, to
LSP is indicated, to the restoration LSP's ingress, using the new the restoration LSP's ingress, using the new protection SERO
protection SERO subobject. subobject.
3. Association Object 3. ASSOCIATION Object
The Association object is used association of segment protection LSPs The ASSOCIATION object is used for the association of segment
when [RFC4090] isn't being used. The Association object is defined protection LSPs when [RFC4090] isn't being used. The ASSOCIATION
in [E2E-RECOVERY]. In this document we define a new Association Type object is defined in [RFC4872]. In this document, we define a new
field value to support make before break, formats and procedures Association Type field value to support make-before-break; the
defined in [E2E-RECOVERY] are not otherwise modified. formats and procedures defined in [RFC4872] 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 [RFC4872] for the definition of other fields and 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. The to associate a recovery LSP with the LSP it is protecting. The
Association object is also used to support resource sharing during ASSOCIATION object is also used to support resource sharing during
make-before-break. This object MUST NOT be used when association is make-before-break. This object MUST NOT be used when association is
made according to the methods defined in [RFC4090]. made according to the methods defined in [RFC4090].
3.2.1. Recovery Type Processing 3.2.1. Recovery Type Processing
Recovery type processing procedures are the same as those defined in Recovery type processing procedures are the same as those defined in
[E2E-RECOVERY], but processing and identification occurs with respect [RFC4872], but processing and identification occur with respect to
to segment recovery LSPs. Note that this means that multiple segment recovery LSPs. Note that this means that multiple
Association objects of type recovery may be present on an LSP. ASSOCIATION objects of type recovery may be present on an LSP.
3.2.2. Resource Sharing Association Type Processing 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 endpoint 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 an outgoing 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 originating node's router address. Association Source is set to the originating node's router address.
The Association ID MUST be set to a value that uniquely identifies The Association ID MUST be set to a value that uniquely identifies
the association of LSPs. This MAY be set to the working LSP's LSP the association of LSPs. This MAY be set to the working LSP's LSP
ID. 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.
Any node processing a Path message for which it does not have Any node processing a Path message for which the node does not have a
matching state, and which contains a Association object with a matching state, and which contains an 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, are defined in this Secondary Explicit Route objects, or SEROs, are defined in this
document. They may be used to indicate the branch and merge nodes of document. They may be used to indicate the branch and merge nodes of
recovery LSPs. They may also provide additional information that is recovery LSPs. They may also provide additional information that is
to be carried in a recovery LSP's ERO. When upstream control of to be carried in a recovery LSP's ERO. When upstream control of
branch and merge nodes is not desired, SEROs are not used. branch and merge nodes is not desired, SEROs 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 by IANA (of form 11bbbbbb). SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).
4.1.1. Protection Subobject 4.1.1. Protection Subobject
A new subobject, called the protection subobject, is defined for use A new subobject, called the protection subobject, is defined for use
in the SECONDARY_EXPLICIT_ROUTE object. As mentioned above, the new in the SECONDARY_EXPLICIT_ROUTE object. As mentioned above, 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. Specific procedures related to the protection recovery LSP. Specific procedures related to the protection
subobject are provided in Section 4.2. The protection subobject is subobject are provided in Section 4.2. The protection subobject is
not valid for use with the Explicit and Record Route objects and MUST not valid for use with the Explicit and Record Route objects and MUST
NOT be included in those objects. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | C-Type | |L| Type | Length | Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTECTION Object Contents | | PROTECTION Object Contents |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 36 skipping to change at page 9, line 20
As defined in [RFC3209], Section 4.3.3. As defined in [RFC3209], Section 4.3.3.
Reserved Reserved
This field is reserved. It MUST be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt. 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 LSP, 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.
The decision to create and insert an SERO is a local matter and The decision to create and insert an SERO is a local matter and
outside the scope of this document. outside the scope of this document.
An SERO SHOULD contain at least three subobjects. The first An SERO SHOULD contain at least three subobjects. The first
subobject MUST indicate the node that is to originate the recovery subobject MUST indicate the node that is to originate the recovery
LSP, i.e. the segment branch node. The address used SHOULD also be LSP, i.e. the segment branch node. The address used SHOULD also be
listed in the ERO or another SERO. This ensures that the branch node listed in the ERO or another SERO. This ensures that the branch node
is along the LSP path. The second subobject SHOULD be a protection is along the LSP path. The second subobject SHOULD be a protection
subobject and should indicate the protection or restoration to be subobject and should indicate the protection or restoration to be
provided by the recovery LSP. When the protection subobject is provided by the recovery LSP. When the protection subobject is
present, the LSP Segment Recovery Flags in the Protection subobject present, the LSP Segment Recovery Flags in the protection subobject
MUST be ignored. The final subobject in the SERO MUST be the merge MUST be ignored. The final subobject in the SERO MUST be the merge
node of the recovery LSP, and MAY have the L-bit set. Standard ERO node of the recovery LSP, and MAY have the L-bit set. Standard ERO
subobjects MAY be inserted between the protection subobject and the subobjects MAY be inserted between the protection subobject and the
final subobject. These subobjects MAY be loose or strict. final subobject. These subobjects MAY be loose or strict.
A node receiving a Path message containing one or more SEROs SHOULD A node receiving a Path message containing one or more SEROs SHOULD
examine each SERO to see if it indicates a local branch point. This examine each SERO to see if it indicates a local branch point. This
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.
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 object
updated to use an address on the local node, and the LSP ID MUST be MUST be updated to use an address (in its Tunnel Sender Address
updated to ensure uniqueness. The Session object MUST be updated to field) on the local node, and the LSP ID MUST be updated to ensure
use the address indicated in the final subobject of the SERO as the uniqueness. The Session object MUST be updated to use the address
tunnel endpoint, the tunnel ID MAY be updated, and the extended indicated in the final subobject of the SERO as the tunnel endpoint
tunnel ID MUST be set to the local node. The Protection object is address, the tunnel ID MAY be updated, and the extended tunnel ID
MUST be set to the local node address. 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. In all cases, the R-bit of a new Protection object is 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 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
recovery LSP's outgoing Path message. SEROs MAY be omitted, from the the recovery LSP's outgoing Path message. SEROs MAY be omitted, from
recovery LSP's outgoing Path message as well as the outgoing Path the 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. Branch Failure Handling 4.2.1. Branch Failure Handling
During setup, it is possible that a processing node will be unable to During setup, it is possible that a processing node will be unable to
support a requested branch. Additionally, during setup and during support a requested branch. Additionally, during setup and normal
normal operation, PathErr messages may be received at a branch node. operation, PathErr messages may be received at a branch node. The
The processing of these events depend on a number of factors. processing of these events depend on a number of factors.
When a failure or received PathErr message is associated with the LSP When a failure or received PathErr message is associated with the LSP
being protected, the event is first processed per standard processing being protected, the event is first processed per standard processing
rules. This includes generation of a standard PathErr message. When rules. This includes generation of a standard PathErr message. When
LSP state is removed due to a local failure or the a PathErr message LSP state is removed due to a local failure or a PathErr message with
with the Path_State_Removed flag set (1), the node MUST send a the Path_State_Removed flag set (1), the node MUST send a PathTear
PathTear message downstream on all other branches. message downstream on all other branches.
When a failure or received PathErr message is associated with a When a failure or received PathErr message is associated with a
recovery LSP, processing is based on the R-bit in addition to the 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 Path_State_Removed flag. In all cases, a received PathErr message is
first processed per standard processing rules and the the failure or first processed per standard processing rules and the failure or
received PathErr message SHOULD trigger the generation of a PathErr received PathErr message SHOULD trigger the generation of a PathErr
message upstream for the LSP being protected. The outgoing PathErr message upstream for the LSP being protected. The outgoing PathErr
message SHOULD indicate an error of "Routing Problem/LSP Segment message SHOULD indicate an error of "Routing Problem/LSP Segment
Protection Failed". The outgoing PathErr message MUST include any Protection Failed". The outgoing PathErr message MUST include any
SEROs carried in a received PathErr message. If no SERO is present 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 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 SERO that matches the errored LSP or failed branch MUST be added to
the outgoing PathErr message. the outgoing PathErr message.
When a PathErr message with the Path_State_Removed flag cleared (0) When a PathErr message with the Path_State_Removed flag cleared (0)
is received, the outgoing (upstream) PathErr message SHOULD be sent is received, the outgoing (upstream) PathErr message SHOULD be sent
with the Path_State_Removed flag cleared (0). with the Path_State_Removed flag cleared (0).
When a PathErr message for a recover LSP with the Path_State_Removed When a PathErr message for a recovery LSP with the Path_State_Removed
flag set (1) is received, the processing node MUST examine the R-bit 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 (as defined below) of the LSP being protected. The R-bit is carried
in the protection object that triggered the initiation of the in the PROTECTION object that triggered the initiation of the
recovery LSP. When the R-bit is not set (0), the outgoing (upstream) recovery LSP. When the R-bit is not set (0), the outgoing (upstream)
PathErr message SHOULD be sent with the Path_State_Removed flag PathErr message SHOULD be sent with the Path_State_Removed flag
cleared (0). When the R-bit is set (1), the outgoing (upstream) cleared (0). When the R-bit is set (1), the outgoing (upstream)
PathErr message MUST be sent with the Path_State_Removed flag set PathErr message MUST be sent with the Path_State_Removed flag set
(1). (1).
In all cases where an outgoing (upstream) PathErr message is sent 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 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 being protected MUST be removed, and the node MUST send a PathTear
message downstream on all active branches. message downstream on all active branches.
4.2.2. Resv Message Processing 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
nodes only after a Resv message is received for the protected LSP. branch nodes only after a Resv message is received for the protected
Resv messages on recovery LSPs will typically not trigger LSP. 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.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.
Downstream nodes process the change in the Admin Status object per Downstream nodes process the change in the ADMIN_STATUS object per
[RFC3473], including generation of Resv messages. When the most [RFC3473], including generation of Resv messages. When the most
recently received upstream Admin Status object had the R bit set, recently received upstream ADMIN_STATUS object has the R bit set,
branch nodes wait for a Resv message with a matching Admin Status branch nodes wait for a Resv message with a matching ADMIN_STATUS
object to be received on all branches before relaying a corresponding object to be received on all branches before relaying a corresponding
Resv message upstream. Resv message upstream.
4.2.4. Recovery LSP Tear Down 4.2.4. Recovery LSP Teardown
Recovery LSP removal is follows standard the standard procedures Recovery LSP removal follows standard procedures defined in [RFC3209]
defined in [RFC3209] and [RFC3473]. This includes without and with and [RFC3473]. This includes with and without setting the
setting the administrative status. administrative status.
4.2.4.1. Tear Down Without Admin Status Change 4.2.4.1. Teardown Without Admin Status Change
The node initiating the tear down originates a PathTear message. The node initiating the teardown originates a PathTear message. Each
Each node that receives a PathTear message process the PathTear node that receives a PathTear message processes the PathTear message
message per standard processing, see [RFC3209] and [RFC2205], and per standard processing (see [RFC3209] and [RFC2205]), and MUST also
MUST also relay a PathTear on every recovery LSP. All PathTear relay a PathTear on every recovery LSP. All PathTear messages
messages (received from upstream and locally originated) may be (received from upstream and locally originated) may be concurrently
concurrently sent downstream. sent downstream.
4.2.4.2. Tear Down With Admin Status Change 4.2.4.2. Teardown 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 in Section 4.2.3 MUST then be followed. Once the
Once the ingress receives all expected Resv messages, it MUST follow ingress receives all expected Resv messages, it MUST follow the
the tear down procedure described in Section 4.2.4.1. teardown procedure described in Section 4.2.4.1.
4.3. Tear Down From Non-Ingress Nodes 4.3. Teardown 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.
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 a sends a PathTear message downstream and a PathErr message with a
"Confirmation" indication (error code and value set to zero) and the "Confirmation" indication (error code and value set to zero), and the
Path_State_Removed flag set (1) toward the LSP ingress node. This Path_State_Removed flag set (1) toward the LSP ingress node. This
manner of non-ingress node tear down is NOT RECOMMENDED as it can manner of non-ingress node teardown is NOT RECOMMENDED because in
result in the removal of the LSP being protected in some case. some cases it can result in the removal of the LSP being protected.
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 A parallel set of rules are applied at branch and merge nodes to
Notify Request object in the Path message of the recovery LSP. The enable the branch or merge node to add a NOTIFY_REQUEST object to the
notify node address MUST be set to the router address of the branch Path and Resv messages of protected and recovery LSPs. Branch nodes
node. add NOTIFY_REQUEST objects to Path messages, and merge nodes add
NOTIFY_REQUEST objects to Resv messages.
A branch node SHOULD also add a Notify Request object to the LSP When a node is branching or merging a recovery LSP, the node SHOULD
being protected. The notify node address is set to the address used include a single NOTIFY_REQUEST object in the Path message of the
in the sender template of the recovery LSP. A locally added Notify recovery LSP, in the case of a branch node, or the Resv message of
Request object MUST be listed first in the outgoing message, any the recovery LSP, in the case of a merge node. The notify node
received Notify Request objects MUST then be listed in the message in address MUST be set to the router address of the processing node.
the order that they were received. Note that this can result in a
stack of (or ordered list) of objects. Branch and merge nodes SHOULD also add a NOTIFY_REQUEST object to the
LSP being protected. For branch nodes, the notify node address is
set to the address used in the sender template object of the
associated recovery LSP. For merge nodes, the notify node address is
set to the address used in the session object of the associated
recovery LSP. A locally added NOTIFY_REQUEST object MUST be listed
first in an outgoing message; any received NOTIFY_REQUEST objects
MUST then be listed in the message in the order that they were
received. Note that this can result in a stack (or ordered list) of
objects.
Normal notification procedures are then followed for the LSP being Normal notification procedures are then followed for the LSP being
protected. That is, the notifying node MUST issue a Notify message to protected. That is, the notifying node MUST issue a Notify message
the recipient indicated by the notify address of the first listed to the recipient indicated by the notify address of the first listed
Notify Request object. Under local policy control, a node issuing a NOTIFY_REQUEST object. Under local policy control, a node issuing a
Notify message MAY also send a Notify message to the Notify Node Notify message MAY also send a Notify message to the Notify Node
Address indicated in the last, or any other, Notify Request object Address indicated in the last, or any other, NOTIFY_REQUEST object
carried in the Path message. carried in the Path or Resv message.
Recovery LSP merge nodes remove the object added by the recovery
branch node from outgoing Path messages for the LSP being protected.
This is done by removing the Notify Request object that matches the
source address of the recovery LSP. This will normally be the first
of the listed Notify Request objects. Note, to cover certain
backwards compatibility scenarios the Notify Request object SHOULD
NOT be removed if it is the sole Notify Request object.
A similar set of rules are applied to the processing of Resv message Recovery LSP merge and branch nodes remove the object added by the
objects to enable merge nodes adding a Notify Request to the Resv recovery branch or merge node from outgoing Path and Resv messages
message for the protected LSP, arranging the objects as an ordered for the LSP being protected. This is done by removing the
list or stack. NOTIFY_REQUEST object that, in the case of a merge node, matches the
source address of the recovery LSP and, in the case of a branch node,
matches the tunnel endpoint address of the recovery LSP. The
matching NOTIFY_REQUEST object will normally be the first of the
listed NOTIFY_REQUEST objects. Note, to cover certain backwards
compatibility scenarios, the NOTIFY_REQUEST object SHOULD NOT be
removed if it is the sole NOTIFY_REQUEST object.
Note this requires the following change to [RFC3473], Section 4.2.1: Note this requires the following change to [RFC3473], Section 4.2.1:
o old text: o old text:
If a message contains multiple Notify_Request objects, only the If a message contains multiple NOTIFY_REQUEST objects, only the
first object is meaningful. Subsequent Notify_Request objects first object is meaningful. Subsequent NOTIFY_REQUEST objects MAY
MAY be ignored and SHOULD NOT be propagated. be ignored and SHOULD NOT be propagated.
o new text: o new text:
If a message contains multiple Notify_Request objects, only the If a message contains multiple NOTIFY_REQUEST objects, only the
first object used is in notification. Subsequent Notify_Request first object used is in notification. Subsequent NOTIFY_REQUEST
objects 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 and merge nodes MUST support the following modification to
message processing. When a branch node receives notification of an Notify message processing. When a branch or merge node receives
LSP failure and it is unable to recover from that failure, it MUST notification of an LSP failure and it is unable to recover from that
notify the node indicated in the first Notify_Request object received failure, it MUST notify the node indicated in the first
in the Path message associated with the LSP. NOTIFY_REQUEST object received in the Path message (for branch nodes)
or Resv message (for merge nodes) 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 a 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 by IANA (of form 11bbbbbb). SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).
The protection subobject defined above can also be used in The protection subobject defined above can also be used 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 added and present
a Path message. in 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.
SRROs are inserted in Path messages by recovery LSP merge nodes. The SRROs are inserted in Path messages by recovery LSP merge nodes. The
SRRO is created by copying the contents of an RRO received the SRRO is created by copying the contents of an RRO received by the
recovery LSP into a new SRRO object. This SRRO is added to the recovery LSP into a new SRRO object. This SRRO is added to the
outgoing Path message of the recovered LSP. Note multiple SRROs may outgoing Path message of the recovered LSP. Note that multiple SRROs
be present. The collection of SRROs is controlled via the segment- may be present. The collection of SRROs is controlled via the
recording-desired flag in the SESSION_ATTRIBUTE object. This flag MAY segment-recording-desired flag in the SESSION_ATTRIBUTE object. This
be set even when SEROs are not used. flag MAY be set even when SEROs are not used.
5.3. Resv Processing 5.3. Resv Processing
SRROs may be carried in Resv messages and indicate the presence of SRROs may be carried in Resv messages and indicate the presence of
downstream recovery LSPs. More than one SRRO MAY be add and present downstream recovery LSPs. More than one SRRO MAY be added and
in a Resv message. present in a Resv 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 Resv message. When Resv modification, in the corresponding outgoing Resv message. When Resv
messages are merged, the resulting merged Resv SHOULD contain all messages are merged, the resulting merged Resv SHOULD contain all
SRROs received in downstream Resv messages. SRROs received in downstream Resv messages.
SRROs are inserted in Resv messages by branch nodes of recovery LSPs. SRROs are inserted in Resv messages by branch nodes of recovery LSPs.
The SRRO SHOULD be created with the first two objects being the local The SRRO SHOULD be created with the first two objects being the local
node address followed by a protection subobject with the contents of node address, followed by a protection subobject with the contents of
the recovery LSP's Protection object. The remainder of the SRRO the recovery LSP's PROTECTION object. The remainder of the SRRO
SHOULD be created by copying the contents of the RRO received the SHOULD be created by copying the contents of the RRO received by the
recovery LSP. This SRRO SHOULD be added to the outgoing Resv message recovery LSP. This SRRO SHOULD be added to the outgoing Resv message
of the recovered LSP. Again, multiple SRROs may be present. of the recovered LSP. Again, multiple SRROs may be present.
If the newly added SRRO causes the message to be too big to fit in a If the newly added SRRO causes the message to be too big to fit in a
Resv message, SRRO subobjects SHOULD be removed from any present Resv message, SRRO subobjects SHOULD be removed from any present
SRROs. When removing subobjects, the first two subobjects and the SRROs. When removing subobjects, the first two subobjects and the
last subobject in an SRRO MUST NOT be removed. Note that the sub- last subobject in an SRRO MUST NOT be removed. Note that the
object that followed a removed sub-object MUST be updated with the L- subobject that followed a removed subobject MUST be updated with the
bit set (1). If after removing all but the first and last subobjects L-bit set (1). If after removing all but the first and last
in all SRROs the resulting message is still too large to fit, then subobjects in all SRROs the resulting message is still too large to
whole SRROs SHOULD be removed until the message does fit. fit, then whole SRROs SHOULD be removed until the message does fit.
6. Dynamic Control of LSP Segment Recovery 6. Dynamic Control of LSP Segment Recovery
Dynamic identification of branch and merge nodes is supported via the Dynamic identification of branch and merge nodes is supported via the
LSP Segment Recovery Flags carried in the Protection object. The LSP LSP Segment Recovery Flags carried in the PROTECTION object. The LSP
Segment Recovery Flags are carried within one of Reserved fields Segment Recovery Flags are carried within one of the Reserved fields
defined in the Protection object defined in [E2E-RECOVERY]. LSP defined in the PROTECTION object defined in [RFC4872]. LSP Segment
Segment Recovery Flags are used to indicate when LSP segment recovery Recovery Flags are used to indicate when LSP segment recovery is
is desired. When these bits are set branch and merge nodes are 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 the 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 of LSP Segment Recovery Flags are carried in the PROTECTION object of
the same C-Type defined in [E2E-RECOVERY]. The format of the flags the same C-Type defined in [RFC4872]. The format of the flags are:
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 (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
skipping to change at page 17, line 19 skipping to change at page 16, line 51
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.
Segment Recovery Flags (Seg.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 [RFC4872].
See [E2E-RECOVERY] for the definition of other fields. See [RFC4872] for the definition of other fields.
6.2. Dynamic Control Procedures 6.2. Dynamic Control Procedures
LSP Segment Recovery Flags are set to indicate that LSP segment LSP Segment Recovery Flags are set to indicate that LSP segment
recovery is desired for the LSP being signaled. The type of recovery recovery is desired for the LSP being signaled. The type of recovery
desired is indicated by the flags. The decision to set the LSP desired is indicated by the flags. The decision to set the LSP
Segment Recovery Flags is a local matter and outside the scope of Segment Recovery Flags is a local matter and outside the scope of
this document. A value of zero (0) means that no dynamic this document. A value of zero (0) means that no dynamic
identification of segment recovery branch nodes are needed for the identification of segment recovery branch nodes are needed for the
associated LSP. When the In-Place bit is set, it means that the associated LSP. When the In-Place bit is set, it means that the
desired type of recovery is already in place for that particular LSP. desired type of recovery is already in place for that particular LSP.
A transit node receiving a Path message containing a Protection A transit node receiving a Path message containing a PROTECTION
object with a non-zero LSP Segment Recovery Flags value and the In- object with a non-zero LSP Segment Recovery Flags value and the In-
Place bit clear (0) SHOULD consider if it can support the indicated Place bit clear (0) SHOULD consider if it can support the indicated
recovery type and if it can identify an appropriate merge node for a recovery type and if it can identify an appropriate merge node for a
recovery LSP. Dynamic identification MUST NOT be done when the recovery LSP. Dynamic identification MUST NOT be done when the
processing node is identified as a branch node in an SERO. If a node processing node is identified as a branch node in an SERO. If a node
is unable to provide the indicated recovery type or identify a merge is unable to provide the indicated recovery type or identify a merge
node, the Path message MUST be processed normally and the LSP Segment node, the Path message MUST be processed normally, and the LSP
Recovery Flags MUST NOT be modified. Segment Recovery Flags MUST NOT be modified.
When a node dynamically identifies itself as a branch node and When a node dynamically identifies itself as a branch node and
identifies the merge node for the type of recovery indicated in the identifies the merge node for the type of recovery indicated in the
LSP Segment Recovery Flags, it attempts to setup a recovery LSP. The LSP Segment Recovery Flags, it attempts to setup a recovery LSP. The
dynamically identified information, together with the Path message of dynamically identified information, together with the Path message of
LSP being recovered provides the information to create the recovery LSP being recovered, is used to create the recovery LSP.
LSP.
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 object
updated to use an address on the local node, and the LSP ID MUST be MUST be updated to use an address (in its Tunnel Sender Address
updated to ensure uniqueness. The Session object MUST be updated to field) on the local node, and the LSP ID MUST be updated to ensure
use the address of the dynamically identified merge node as the uniqueness. The Session object MUST be updated to use the address of
tunnel endpoint, the tunnel ID MAY be updated, and the extended the dynamically identified merge node as the tunnel endpoint address,
tunnel ID MUST be set to the local node. The Protection object is the tunnel ID MAY be updated, and the extended tunnel ID MUST be set
updated with the In-Place bit set (1). Any RROs and EROs present in to the local node address. The PROTECTION object is updated with the
the incoming Path message MUST NOT be included in the recovery LSP. A In-Place bit set (1). Any RROs and EROs present in the incoming Path
new ERO MAY be created based on any path information dynamically message MUST NOT be included in the recovery LSP. A new ERO MAY be
computed by the local node. created based on any path information dynamically 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 and unless overridden by local policy, the the recovery LSP exists, the PROTECTION object in the original Path
Protection object in the original Path message MUST also be updated message (unless overridden by local policy) MUST also be updated
with the In-Place bit set (1). From this point on, Standard Path with the In-Place bit set (1). From this point on, Standard Path
message processing is used in processing the resulting and original message processing is used in processing the resulting and original
Path messages. 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 Sections 4.2.1 through 4.2.4.
through 4.2.4.
7. Updated RSVP Message Formats 7. 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> ]
skipping to change at page 21, line 13 skipping to change at page 21, line 7
Thus, in the event of the interception of a signaling message, Thus, in the event of the interception of a signaling message,
slightly more could be deduced about the state of the network than 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 was previously the case, but this is judged to be a very minor
security risk as this information is already available via routing. security risk as this information is already available via routing.
Otherwise, this document introduces no additional security Otherwise, this document introduces no additional security
considerations. See [RFC3473] for relevant security considerations. considerations. See [RFC3473] for relevant security considerations.
9. IANA Considerations 9. IANA Considerations
IANA is requested to administer assignment of new values for IANA has assigned the following values for the namespaces defined in
namespaces defined in this document and reviewed in this section. this document and reviewed in this section.
9.1. New Association Type Assignment 9.1. New Association Type Assignment
Upon approval of this document, the IANA will make the following IANA has made the following assignment to the "Association Types"
assignment to the "Association Types" Registry, see [E2E-RECOVERY], Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the
in the "ASSOCIATION (object)" section of the "RSVP PARAMETERS" "RSVP PARAMETERS" registry located at
registry located at http://www.iana.org/assignments/rsvp-parameters http://www.iana.org/assignments/rsvp-parameters.
Value Type Value Type
----- ---- ----- ----
2 Resource Sharing (R) [RFC-ccamp-gmpls-segment-recovery] 2 Resource Sharing (R) [RFC4873]
9.2. Definition of Protection Object Reserved Bits 9.2. Definition of PROTECTION Object Reserved Bits
This document defines bits carried in the Reserved field of the This document defines bits carried in the Reserved field of the
Protection Object defined in [E2E-RECOVERY]. As no IANA registry for PROTECTION object defined in [RFC4872]. As no IANA registry for
these bits is requested in [E2E-RECOVERY], no IANA action is required these bits is requested in [RFC4872], no IANA action is required
related to this definition. related to this definition.
9.3. Secondary Explicit Route Object 9.3. Secondary Explicit Route Object
Upon approval of this document, the IANA will make the following IANA has made the following assignments in the "Class Names, Class
assignments in the "Class Names, Class Numbers, and Class Types" Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
section of the "RSVP PARAMETERS" registry located at located at http://www.iana.org/assignments/rsvp-parameters.
http://www.iana.org/assignments/rsvp-parameters
A new class named SECONDARY_EXPLICIT_ROUTE will be created in the A new class named SECONDARY_EXPLICIT_ROUTE has been created in the
11bbbbbb range (198 suggested) with the following definition: 11bbbbbb range (200) with the following definition:
Class Types or C-types: Class Types or C-types:
Same values as EXPLICIT_ROUTE object (C-Num 20) Same values as EXPLICIT_ROUTE object (C-Num 20)
For Class 1, C-Type 1, the following additional Sub-object type is For Class 1, C-Type 1, the following additional Subobject type is
defined: defined:
37 Protection [RFC-ccamp-gmpls-segment-recovery] 37 PROTECTION [RFC4873]
9.4. Secondary Record Route Object 9.4. Secondary Record Route Object
Upon approval of this document, the IANA will make the following IANA has made the following assignments in the "Class Names, Class
assignments in the "Class Names, Class Numbers, and Class Types" Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
section of the "RSVP PARAMETERS" registry located at located at http://www.iana.org/assignments/rsvp-parameters.
http://www.iana.org/assignments/rsvp-parameters
A new class named SECONDARY_RECORD_ROUTE has been created in the
11bbbbbb range (201) with the following definition:
A new class named SECONDARY_RECORD_ROUTE will be created in the
11bbbbbb range (198 suggested) with the following definition:
Class Types or C-types: Class Types or C-types:
Same values as RECORD_ROUTE object (C-Num 21) Same values as RECORD_ROUTE object (C-Num 21)
For Class 1, C-Type 1, the following additional Sub-object type is For Class 1, C-Type 1, the following additional Subobject type is
defined: defined:
37 Protection [RFC-ccamp-gmpls-segment-recovery] 37 PROTECTION [RFC4873]
9.5. New Error Code 9.5. New Error Code
Upon approval of this document, the IANA will make the following IANA has made the following assignments in the "Routing Problem"
assignments in the "Routing Problem" subsection of "Error Codes and subsection of "Error Codes and Values" section of the "RSVP
Values" section of the "RSVP PARAMETERS" registry located at PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters http://www.iana.org/assignments/rsvp-parameters.
xx = LSP Segment Protection Failed [RFC-ccamp-gmpls-segment-recovery] 21 = LSP Segment Protection Failed [RFC4873]
9.6. Use of Not Yet Assigned Protection Object C-type 9.6. Use of PROTECTION Object C-type
This document modifies the Protection Object, class number 37, C-Type This document modifies the PROTECTION object, class number 37, C-Type
defined in [E2E-RECOVERY]. Per Section 14.1 of [E2E-RECOVERY], this 2 (defined in Section 14.1. of [RFC4872]).
C-Type is still "TBA", but has a suggested value of 2. Section 6.1
of this document, should be updated to match the assignment made by
IANA for Section 14.1 of [E2E-RECOVERY].
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[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", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
LSP Tunnels", RFC 3209, December 2001. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Label Switching (GMPLS) Signaling Functional and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Description", RFC 3471, January 2003. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L., Ed., "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
RFC 3473, January 2003. 3473, January 2003.
[E2E-RECOVERY] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors, [RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
"RSVP-TE Extensions in support of End-to-End Ed., "RSVP-TE Extensions in support of End-to-End
GMPLS-based Recovery", Work in Progress, Generalized Multi-Protocol Label Switching (GMPLS)
draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt, Recovery", RFC 4872, May 2007.
April 2005.
10.2. Informative References 10.2. Informative References
[RFC4090] Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Tunnels", RFC 4090, May 2005. Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[RFC4426] J.P.Lang and B.Rajagopalan (Editors), "Generalized MPLS [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D.
Recovery Functional Specification," RFC 4426, March 2006. Papadimitriou, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Recovery Functional Specification," RFC
4426, March 2006.
[RFC4427] E.Mannie and D.Papadimitriou (Editors), "Recovery [RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for GMPLS," (Protection and Restoration) Terminology for Generalized
Internet Draft, RFC 4427, March 2006. Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
11. Authors' Addresses Authors' Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1 301-468-9228 Phone: +1 301-468-9228
Email: lberger@labn.net EMail: lberger@labn.net
Igor Bryskin Igor Bryskin
Movaz Networks, Inc. ADVA Optical
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Email: ibryskin@movaz.com
Adrian Farrel EMail: IBryskin@advaoptical.com
Old Dog Consulting
Phone: +44 (0) 1978 860944
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-lucent.be
12. Full Copyright Statement Adrian Farrel
Old Dog Consulting
Copyright (C) The Internet Society (2006). This document is subject Phone: +44 (0) 1978 860944
to the rights, licenses and restrictions contained in BCP 78, and EMail: adrian@olddog.co.uk
except as set forth therein, the authors retain all their rights.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and 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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
13. Intellectual Property 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.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
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
ipr@ietf.org. ietf-ipr@ietf.org.
Generated on: Fri Oct 6 11:36:26 EDT 2006 Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 152 change blocks. 
424 lines changed or deleted 432 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/