doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc4873.txt b/doc/rfc/rfc4873.txt
new file mode 100644
index 0000000..8ed7b42
--- /dev/null
+++ b/doc/rfc/rfc4873.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                          L. Berger
+Request for Comments: 4873                               LabN Consulting
+Updates: 3473, 4872                                           I. Bryskin
+Category: Standards Track                                   ADVA Optical
+                                                        D. Papadimitriou
+                                                                 Alcatel
+                                                               A. Farrel
+                                                      Old Dog Consulting
+                                                                May 2007
+
+
+                         GMPLS Segment Recovery
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document describes protocol specific procedures for GMPLS
+   (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource
+   ReserVation Protocol - Traffic Engineering) signaling extensions to
+   support label switched path (LSP) segment protection and restoration.
+   These extensions are intended to complement and be consistent with
+   the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).
+   Implications and interactions with fast reroute are also addressed.
+   This document also updates the handling of NOTIFY_REQUEST objects.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 1]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................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 ............................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
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 2]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+1.  Introduction
+
+   [RFC4427] covers multiple types of protection, including end-to-end
+   and segment-based approaches.  "RSVP-TE Extensions in Support of
+   End-to-End Generalized Multi-Protocol Label Switching (GMPLS)
+   Recovery" [RFC4872] defines a set of extensions to support multiple
+   types of recovery.  The supported types include 1+1 unidirectional/
+   1+1 bidirectional protection, LSP protection with extra-traffic
+   (including 1:N protection with extra-traffic), pre-planned LSP re-
+   routing without extra-traffic (including shared mesh), and full LSP
+   re-routing.  In all cases, the recovery is provided on an end-to-end
+   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
+   networks.  Two methods of fast reroute are defined in [RFC4090].  The
+   one-to-one backup method creates detour LSPs for each protected LSP
+   at each potential point of local repair.  The facility backup method
+   creates a bypass tunnel to protect a potential failure point that is
+   shared by multiple LSPs and uses label stacking.  Neither approach
+   supports the full set of recovery types supported by [RFC4872].
+   Additionally, the facility backup method is not applicable to most
+   non-PSC (packet switch capable) switching technologies.
+
+   The extensions defined in this document allow for support of the full
+   set of recovery types supported by [RFC4872], but on a segment, or
+   portion of the LSP, basis.  The extensions allow (a) the signaling of
+   desired LSP segment protection type, (b) upstream nodes to optionally
+   identify where segment protection starts and stops, (c) the optional
+   identification of hops used on protection segments, and (d) the
+   reporting of paths used to protect an LSP.  The extensions also widen
+   the topological scope over which protection can be supported.  They
+   allow recovery segments that protect against an arbitrary number of
+   nodes and links.  They enable overlapping protection and nested
+   protection.  These extensions are intended to be compatible with fast
+   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].
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 3]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+2.  Segment Recovery
+
+   Segment recovery is used to provide protection and restoration over a
+   portion of an end-to-end LSP.  Such segment protection and
+   restoration is useful to protect against a span failure, a node
+   failure, or failure over a particular portion of a network used by an
+   LSP.
+
+   Consider the following topology:
+
+                        A---B---C---D---E---F
+                                 \     /
+                                  G---I
+
+   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
+   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
+   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
+   node D.  This form of protection/restoration is referred to as
+   Segment Protection and Segment Restoration, or as Segment Recovery,
+   collectively.  The LSP providing the protection or restoration is
+   referred to as a segment protection LSP or a segment restoration LSP.
+   The term "segment recovery LSP" is used to cover either a segment
+   protection LSP or a segment restoration LSP.  The term "branch node"
+   is used to refer to a node that initiates a recovery LSP, e.g., node
+   C in the figure shown above.  This is equivalent to the point of
+   local repair (PLR) used in [RFC4090].  As with [RFC4090], the term
+   "merge node" is used to refer to a node that terminates a recovery
+   LSP, e.g., node E in the figure shown above.
+
+   Segment protection or restoration is signaled using a working LSP and
+   one or more segment recovery LSPs.  Each segment recovery LSP is
+   signaled as an independent LSP.  Specifically, the Sender_Template
+   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
+   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
+   value, Tunnel ID, and Extended Tunnel ID.  Values for these fields
+   are selected normally, including consideration for the make-before-
+   break concept (as described in [RFC3209]).  Intermediate nodes follow
+   standard signaling procedures when processing segment recovery LSPs.
+   A segment recovery LSP may be protected itself using segment or end-
+   to-end protection/restoration.  Note, in PSC environments, it may be
+   desirable to construct the Sender_Template and Session objects per
+   [RFC4090].
+
+
+
+
+Berger, et al.              Standards Track                     [Page 4]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   When [RFC4090] isn't being used, the association between segment
+   recovery LSPs with other LSPs is indicated using the ASSOCIATION
+   object defined in [RFC4872].  The ASSOCIATION object is used to
+   associate recovery LSPs with the LSP they are protecting.  Working
+   and protecting LSPs, as well as primary and secondary LSPs, are
+   identified using LSP Status as described in [RFC4872].  The O-bit in
+   the segment flags portion of the PROTECTION object is used to
+   identify when a recovery LSP is carrying the normal (active) traffic.
+
+   An upstream node can permit downstream nodes to dynamically identify
+   branch and merge points by setting the desired LSP segment protection
+   bits in the PROTECTION object.  These bits are defined below.
+
+   Optionally, an upstream node, usually the ingress node, can identify
+   the endpoints of a segment recovery LSP.  This is accomplished using
+   a new object.  This object uses the same format as an Explicit Route
+   Object (ERO) and is referred to as a Secondary Explicit Route object
+   (SERO); see Section 4.1.  SEROs also support a new subobject to
+   indicate the type of protection or restoration to be provided.  At a
+   minimum, an SERO will indicate a recovery LSP's initiator,
+   protection/restoration type and terminator.  Standard ERO semantics
+   (see [RFC3209]) can optionally be used within and SERO to explicitly
+   control the recovery LSP.  A Secondary Record Route object (SRRO) is
+   defined for recording the path of a segment recovery LSP; see Section
+   5.
+
+   SEROs are carried between the node creating the SERO, typically the
+   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.
+   At this (branch) node, all local objects are removed, and the new
+   protection subobject is used to create the PROTECTION object for the
+   recovery LSP.  It is also possible to control the handling of a
+   failure to establish a recovery LSP.
+
+   SRROs are carried in Path messages between the node terminating a
+   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
+   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
+   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
+   the Resv message of associated recovery LSP into a new SRRO object.
+   Any SRROs present in the recovery LSP's Resv message are also copied.
+
+   Notify request processing is also impacted by LSP segment recovery.
+   Per [RFC3473], only one NOTIFY_REQUEST object is meaningful and
+   should be propagated.  Additional NOTIFY_REQUEST objects are used to
+   identify recovery LSP branch nodes.
+
+
+
+Berger, et al.              Standards Track                     [Page 5]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+2.1.  Segment Protection
+
+   Three approaches for end-to-end protection are defined in [RFC4872]:
+   1+1 Unidirectional Protection (Section 5), 1+1 Bidirectional
+   Protection (Section 6), and 1:1 Protection With Extra-Traffic
+   (Section 7).  The segment protection forms of these protection
+   approaches all operate much like their end-to-end counterparts.  Each
+   behaves just like its end-to-end counterpart, 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 protection LSP is
+   indicated, to the protection LSP's ingress, using the protection SERO
+   subobject defined in Section 4.1.
+
+   The switch-over processing for segment 1+1 Bidirectional protection
+   and 1:1 Protection With Extra-Traffic follows the same procedures as
+   end-to-end protection forms; see Sections 6.2 and 7.2 of [RFC4872]
+   for details.
+
+2.2.  Segment Re-routing and Restoration
+
+   Three re-routing and restoration approaches are defined in [RFC4872]:
+   Re-routing without Extra-Traffic (Section 8), Shared-Mesh Restoration
+   (Section 9), (Full) LSP Re-routing (Section 11).  As with protection,
+   these approaches are supported on a segment basis.  The segment forms
+   of re-routing and restoration operate exactly like their end-to-end
+   counterparts, with the exception that 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 LSP is indicated, to
+   the restoration LSP's ingress, using the new protection SERO
+   subobject.
+
+3.  ASSOCIATION Object
+
+   The ASSOCIATION object is used for the association of segment
+   protection LSPs when [RFC4090] isn't being used.  The ASSOCIATION
+   object is defined in [RFC4872].  In this document, we define a new
+   Association Type field value to support make-before-break; the
+   formats and procedures defined in [RFC4872] are not otherwise
+   modified.
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 6]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+3.1.  Format
+
+   Association Type: 16 bits
+
+      Value       Type
+      -----       ----
+        2         Resource Sharing (R)
+
+   See [RFC4872] for the definition of other fields and values.
+
+3.2.  Procedures
+
+   The ASSOCIATION object is used to associate different LSPs with each
+   other.  In the protection and restoration context, the object is used
+   to associate a recovery LSP with the LSP it is protecting.  The
+   ASSOCIATION object is also used to support resource sharing during
+   make-before-break.  This object MUST NOT be used when association is
+   made according to the methods defined in [RFC4090].
+
+3.2.1.  Recovery Type Processing
+
+   Recovery type processing procedures are the same as those defined in
+   [RFC4872], but processing and identification occur 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
+   Resource Sharing is used to enable resource sharing during make-
+   before-break.  Resource sharing during make-before-break is defined
+   in [RFC3209].  The defined support only works with LSPs that share
+   the same LSP egress.  With the introduction of segment recovery LSPs,
+   it is now possible for an LSP endpoint to change during make-before-
+   break.
+
+   A node includes an ASSOCIATION object with a Resource Sharing
+   Association Type in an outgoing Path message when it wishes to
+   indicate resource sharing across an associated set of LSPs.  The
+   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 of LSPs.  This MAY be set to the working LSP's LSP
+   ID.  Once included, an ASSOCIATION object with a Resource Sharing
+   Association Type SHOULD NOT be removed from the Path messages
+   associated with an LSP.
+
+
+
+
+
+
+Berger, et al.              Standards Track                     [Page 7]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   Any node processing a Path message for which the node does not have a
+   matching state, and which contains an ASSOCIATION object with a
+   Resource Sharing type, examines existing LSPs for matching
+   Association Type, Association Source, and Association ID values.  If
+   any match is found, then [RFC3209] style resource sharing SHOULD be
+   provided between the new and old LSPs.  See [RFC3209] for additional
+   details.
+
+4.  Explicit Control of LSP Segment Recovery
+
+   Secondary Explicit Route objects, or SEROs, are defined in this
+   document.  They may be used to indicate 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.  When upstream control of
+   branch and merge nodes is not desired, SEROs are not used.
+
+4.1.  Secondary Explicit Route Object Format
+
+   The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an
+   EXPLICIT_ROUTE object.  This includes the definition of subobjects
+   defined for EXPLICIT_ROUTE object.  The class of the
+   SECONDARY_EXPLICIT_ROUTE object is 200 (of the form 11bbbbbb).
+
+4.1.1.  Protection Subobject
+
+   A new subobject, called the protection subobject, is defined for use
+   in the SECONDARY_EXPLICIT_ROUTE object.  As mentioned above, the new
+   protection subobject is used to create the PROTECTION object for the
+   recovery LSP.  Specific procedures related to the protection
+   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 be included in those objects.
+
+   The format of the protection subobject is defined as follows:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |L|    Type     |     Length    |    Reserved   |   C-Type      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  PROTECTION Object Contents                   |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      L-bit
+
+         This is defined in [RFC3209] and MUST be set to zero for
+         protection subobjects.
+
+
+
+Berger, et al.              Standards Track                     [Page 8]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+      Type
+
+         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
+
+         The C-Type of the included PROTECTION object.
+
+      PROTECTION Object Contents
+
+         The contents of the PROTECTION object, with the format matching
+         the indicated C-Type, excluding the object header.
+
+4.2.  Explicit Control Procedures
+
+   SEROs are carried in Path messages and indicate at which node a
+   recovery LSP is to be initiated relative to the LSP carrying the
+   SERO.  More than one SERO MAY be present in a Path message.
+
+   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.
+   The decision to create and insert an SERO is a local matter and
+   outside the scope of this document.
+
+   An SERO SHOULD contain at least three subobjects.  The first
+   subobject MUST indicate the node that is to originate the recovery
+   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
+   is along the LSP path.  The second subobject SHOULD be a protection
+   subobject and should indicate the protection or restoration to be
+   provided by the recovery LSP.  When the protection subobject is
+   present, the LSP Segment Recovery Flags in the protection subobject
+   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
+   subobjects MAY be inserted between the protection subobject and the
+   final subobject.  These subobjects MAY be loose or strict.
+
+   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
+
+
+
+Berger, et al.              Standards Track                     [Page 9]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   determination is made by examining the first object of each SERO and
+   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, then the local node is a branch node.  If the
+   local node is not a branch node, all received SEROs MUST be
+   transmitted, without modification, in the corresponding outgoing Path
+   message.
+
+   At a branch node, the SERO, together with the Path message of LSP
+   being recovered, provides the information to create the recovery LSP.
+   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
+   LSP being protected.  Certain objects are replaced or modified in the
+   recovery LSP's outgoing Path message.  The Sender_template object
+   MUST be updated to use an address (in its Tunnel Sender Address
+   field) on the local node, and the LSP ID MUST be updated to ensure
+   uniqueness.  The Session object MUST be updated to use the address
+   indicated in the final subobject of the SERO as the tunnel endpoint
+   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,
+   when present.  In all cases, the R-bit of a new PROTECTION object is
+   reset (0).  Any RROs and EROs present in the incoming Path message
+   MUST NOT be included in the recovery LSP.  A new ERO MUST be
+   included, with the contents of the SERO that indicated a local
+   branch.  As with all EROs, no local information (local address and
+   any protection subobjects) is carried in the ERO carried in the
+   recovery LSP's outgoing Path message.  The SERO that indicated a
+   local branch MUST be omitted from the recovery LSP's outgoing Path
+   message.  Note, by default, all other received SEROs are passed in
+   the recovery LSP's outgoing Path message.  SEROs MAY be omitted, from
+   the recovery LSP's outgoing Path message as well as the outgoing Path
+   message for the LSP being protected, when the SERO does not relate to
+   the outgoing path message.
+
+   The resulting Path message is used to create the recovery LSP.  From
+   this point on, Standard Path message processing is used in processing
+   the resulting Path message.
+
+4.2.1.  Branch Failure Handling
+
+   During setup, it is possible that a processing node will be unable to
+   support a requested branch.  Additionally, during setup and normal
+   operation, PathErr messages may be received at a branch node.  The
+   processing of these events depend on a number of factors.
+
+   When a failure or received PathErr message is associated with the LSP
+   being protected, the event is first processed per standard processing
+
+
+
+Berger, et al.              Standards Track                    [Page 10]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   rules.  This includes generation of a standard PathErr message.  When
+   LSP state is removed due to a local failure or a PathErr message with
+   the Path_State_Removed flag set (1), the node MUST send a PathTear
+   message downstream on all other branches.
+
+   When a failure or received PathErr message is associated with a
+   recovery LSP, processing is based on the R-bit in addition to the
+   Path_State_Removed flag.  In all cases, a received PathErr message is
+   first processed per standard processing rules and the failure or
+   received PathErr message SHOULD trigger the generation of a PathErr
+   message upstream for the LSP being protected.  The outgoing PathErr
+   message SHOULD indicate an error of "Routing Problem/LSP Segment
+   Protection Failed".  The outgoing PathErr message MUST include any
+   SEROs carried in a received PathErr message.  If no SERO is present
+   in a received PathErr message or when the failure is local, then an
+   SERO that matches the errored LSP or failed branch MUST be added to
+   the outgoing PathErr message.
+
+   When a PathErr message with the Path_State_Removed flag cleared (0)
+   is received, the outgoing (upstream) PathErr message SHOULD be sent
+   with the Path_State_Removed flag cleared (0).
+
+   When a PathErr message for a recovery LSP with the Path_State_Removed
+   flag set (1) is received, the processing node MUST examine the R-bit
+   (as defined below) of the LSP being protected.  The R-bit is carried
+   in the PROTECTION object that triggered the initiation of the
+   recovery LSP.  When the R-bit is not set (0), the outgoing (upstream)
+   PathErr message SHOULD be sent with the Path_State_Removed flag
+   cleared (0).  When the R-bit is set (1), the outgoing (upstream)
+   PathErr message MUST be sent with the Path_State_Removed flag set
+   (1).
+
+   In all cases where an outgoing (upstream) PathErr message is sent
+   with the Path_State_Removed flag set (1), all path state for the LSP
+   being protected MUST be removed, and the node MUST send a PathTear
+   message downstream on all active branches.
+
+4.2.2.  Resv Message Processing
+
+   Branch nodes will process Resv messages for both recovery LSPs and
+   LSPs being protected.  Resv messages are propagated upstream of
+   branch nodes only after a Resv message is received for the protected
+   LSP.  Resv messages on recovery LSPs will typically not trigger
+   transmission of upstream Resv messages (for the LSP being protected).
+   Exceptions to this include when RROs/SRROs are being collected and
+   during certain ADMIN_STATUS object processing.  See below for more
+   information on related processing.
+
+
+
+
+Berger, et al.              Standards Track                    [Page 11]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+4.2.3.  Admin Status Change
+
+   In general, objects in a recovery LSP are created based on the
+   corresponding objects in the LSP being protected.  The ADMIN_STATUS
+   object is created the same way, but it also requires some special
+   coordination at branch nodes.  Specifically, in addition to normal
+   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
+   every recovery LSP.  All Path messages MAY be concurrently sent
+   downstream.
+
+   Downstream nodes process the change in the ADMIN_STATUS object per
+   [RFC3473], including generation of Resv messages.  When the most
+   recently received upstream ADMIN_STATUS object has the R bit set,
+   branch nodes wait for a Resv message with a matching ADMIN_STATUS
+   object to be received on all branches before relaying a corresponding
+   Resv message upstream.
+
+4.2.4.  Recovery LSP Teardown
+
+   Recovery LSP removal follows standard procedures defined in [RFC3209]
+   and [RFC3473].  This includes with and without setting the
+   administrative status.
+
+4.2.4.1.  Teardown Without Admin Status Change
+
+   The node initiating the teardown originates a PathTear message.  Each
+   node that receives a PathTear message processes the PathTear message
+   per standard processing (see [RFC3209] and [RFC2205]), and MUST also
+   relay a PathTear on every recovery LSP.  All PathTear messages
+   (received from upstream and locally originated) may be concurrently
+   sent downstream.
+
+4.2.4.2.  Teardown With Admin Status Change
+
+   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
+   procedure defined in Section 4.2.3 MUST then be followed.  Once the
+   ingress receives all expected Resv messages, it MUST follow the
+   teardown procedure described in Section 4.2.4.1.
+
+4.3.  Teardown From Non-Ingress Nodes
+
+   As with any LSP, any node along a recovery LSP may initiate removal
+   of the recovery LSP.  To do this, the node initiating the teardown
+   sends a PathErr message with the appropriate Error Code and the
+   Path_State_Removed flag cleared (0) toward the LSP ingress.  As
+   described above, the recovery LSP ingress will propagate the error to
+
+
+
+Berger, et al.              Standards Track                    [Page 12]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   the LSP ingress, which can then signal the removal of the recovery
+   LSP.
+
+   It is also possible for the node initiating the teardown to remove a
+   Recovery LSP in a non-graceful manner.  In this case, the initiator
+   sends a PathTear message downstream and a PathErr message with a
+   "Confirmation" indication (error code and value set to zero), and the
+   Path_State_Removed flag set (1) toward the LSP ingress node.  This
+   manner of non-ingress node teardown is NOT RECOMMENDED because in
+   some cases it can result in the removal of the LSP being protected.
+
+4.3.1.  Modified NOTIFY_REQUEST Object Processing
+
+   A parallel set of rules are applied at branch and merge nodes to
+   enable the branch or merge node to add a NOTIFY_REQUEST object to the
+   Path and Resv messages of protected and recovery LSPs.  Branch nodes
+   add NOTIFY_REQUEST objects to Path messages, and merge nodes add
+   NOTIFY_REQUEST objects to Resv messages.
+
+   When a node is branching or merging a recovery LSP, the node SHOULD
+   include a single NOTIFY_REQUEST object in the Path message of the
+   recovery LSP, in the case of a branch node, or the Resv message of
+   the recovery LSP, in the case of a merge node.  The notify node
+   address MUST be set to the router address of the processing node.
+
+   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
+   protected.  That is, the notifying node MUST issue a Notify message
+   to the recipient indicated by the notify address of the first listed
+   NOTIFY_REQUEST object.  Under local policy control, a node issuing a
+   Notify message MAY also send a Notify message to the Notify Node
+   Address indicated in the last, or any other, NOTIFY_REQUEST object
+   carried in the Path or Resv message.
+
+   Recovery LSP merge and branch nodes remove the object added by the
+   recovery branch or merge node from outgoing Path and Resv messages
+   for the LSP being protected.  This is done by removing the
+   NOTIFY_REQUEST object that, in the case of a merge node, matches the
+
+
+
+Berger, et al.              Standards Track                    [Page 13]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   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:
+
+   o old text:
+      If a message contains multiple NOTIFY_REQUEST objects, only the
+      first object is meaningful.  Subsequent NOTIFY_REQUEST objects MAY
+      be ignored and SHOULD NOT be propagated.
+
+   o new text:
+      If a message contains multiple NOTIFY_REQUEST objects, only the
+      first object used is in notification.  Subsequent NOTIFY_REQUEST
+      objects MUST be propagated in the order received.
+
+4.3.2.  Modified Notify and Error Message Processing
+
+   Branch and merge nodes MUST support the following modification to
+   Notify message processing.  When a branch or merge node receives
+   notification of an LSP failure and it is unable to recover from that
+   failure, it MUST notify the node indicated in the first
+   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
+
+   Secondary Record Route objects, or SRROs, are used to record the path
+   used by recovery LSPs.
+
+5.1.  Format
+
+   The format of a SECONDARY_RECORD_ROUTE object is the same as a
+   RECORD_ROUTE object, Class number 21.  This includes the definition
+   of subobjects defined for RECORD_ROUTE object.  The class of the
+   SECONDARY_RECORD_ROUTE object is 201 (of the form 11bbbbbb).
+
+   The protection subobject defined above can also be used in
+   SECONDARY_RECORD_ROUTE objects.
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 14]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+5.2.  Path Processing
+
+   SRROs may be carried in Path messages and indicate the presence of
+   upstream recovery LSPs.  More than one SRRO MAY be added and present
+   in a Path message.
+
+   Any received SRRO MUST be transmitted by transit nodes, without
+   modification, in the corresponding outgoing Path message.
+
+   SRROs are inserted in Path messages by recovery LSP merge nodes.  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
+   outgoing Path message of the recovered LSP.  Note that multiple SRROs
+   may be present.  The collection of SRROs is controlled via the
+   segment-recording-desired flag in the SESSION_ATTRIBUTE object.  This
+   flag MAY be set even when SEROs are not used.
+
+5.3.  Resv Processing
+
+   SRROs may be carried in Resv messages and indicate the presence of
+   downstream recovery LSPs.  More than one SRRO MAY be added and
+   present in a Resv message.
+
+   Any received SRRO MUST be transmitted by transit nodes, without
+   modification, in the corresponding outgoing Resv message.  When Resv
+   messages are merged, the resulting merged Resv SHOULD contain all
+   SRROs received in downstream Resv messages.
+
+   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
+   node address, followed by a protection subobject with the contents of
+   the recovery LSP's PROTECTION object.  The remainder of the SRRO
+   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
+   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
+   Resv message, SRRO subobjects SHOULD be removed from any present
+   SRROs.  When removing subobjects, the first two subobjects and the
+   last subobject in an SRRO MUST NOT be removed.  Note that the
+   subobject that followed a removed subobject MUST be updated with the
+   L-bit set (1).  If after removing all but the first and last
+   subobjects in all SRROs the resulting message is still too large to
+   fit, then whole SRROs SHOULD be removed until the message does fit.
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 15]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+6.  Dynamic Control of LSP Segment Recovery
+
+   Dynamic identification of branch and merge nodes is supported via the
+   LSP Segment Recovery Flags carried in the PROTECTION object.  The LSP
+   Segment Recovery Flags are carried within one of the Reserved fields
+   defined in the PROTECTION object defined in [RFC4872].  LSP Segment
+   Recovery Flags are used to indicate when LSP segment recovery is
+   desired.  When these bits are set, branch and merge nodes are
+   dynamically identified.
+
+   Note, the procedures defined in this section parallel the explicit
+   control procedures defined above in Section 4.2.  The primary
+   difference is in the creation of a recovery LSP's ERO.
+
+6.1.  Modified PROTECTION Object Format
+
+   LSP Segment Recovery Flags are carried in the PROTECTION object of
+   the same C-Type defined in [RFC4872].  The format of the flags are:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Length             | Class-Num(37) | C-Type (2)    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |S|P|N|O| Reserved  | LSP Flags |     Reserved      | Link Flags|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |I|R|   Reserved    | Seg.Flags |           Reserved            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      In-Place (I): 1 bit
+
+         When set (1) indicates that the desired segment recovery type
+         indicated in the LSP Segment Recovery Flag is already in place
+         for the associated LSP.
+
+      Required (R): 1 bit
+
+         When set (1) indicates that failure to establish the indicated
+         protection should result in a failure of the LSP being
+         protected.
+
+      Segment Recovery Flags (Seg.Flags): 6 bits
+
+         This field is used to indicate when an upstream node desires
+         LSP Segment recovery to be dynamically initiated where
+         possible.  The values used in this field are identical to the
+         values defined for LSP Flags; see [RFC4872].
+
+
+
+
+Berger, et al.              Standards Track                    [Page 16]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   See [RFC4872] for the definition of other fields.
+
+6.2.  Dynamic Control Procedures
+
+   LSP Segment Recovery Flags are set to indicate that LSP segment
+   recovery is desired for the LSP being signaled.  The type of recovery
+   desired is indicated by the flags.  The decision to set the LSP
+   Segment Recovery Flags is a local matter and outside the scope of
+   this document.  A value of zero (0) means that no dynamic
+   identification of segment recovery branch nodes are needed for 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.
+
+   A transit node receiving a Path message containing a PROTECTION
+   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
+   recovery type and if it can identify an appropriate merge node for a
+   recovery LSP.  Dynamic identification MUST NOT be done when the
+   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
+   node, the Path message MUST be processed normally, and the LSP
+   Segment Recovery Flags MUST NOT be modified.
+
+   When a node dynamically identifies itself as a branch node and
+   identifies the merge node for the type of recovery indicated in the
+   LSP Segment Recovery Flags, it attempts to setup a recovery LSP.  The
+   dynamically identified information, together with the Path message of
+   LSP being recovered, is used to create the recovery LSP.
+
+   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
+   LSP being protected.  Certain objects are replaced or modified in the
+   recovery LSP's outgoing Path message.  The Sender_template object
+   MUST be updated to use an address (in its Tunnel Sender Address
+   field) on the local node, and the LSP ID MUST be updated to ensure
+   uniqueness.  The Session object MUST be updated to use the address of
+   the dynamically identified merge node as the tunnel endpoint address,
+   the tunnel ID MAY be updated, and the extended tunnel ID MUST be set
+   to the local node address.  The PROTECTION object is updated with the
+   In-Place bit set (1).  Any RROs and EROs present in the incoming Path
+   message MUST NOT be included in the recovery LSP.  A new ERO MAY be
+   created based on any path information dynamically computed by the
+   local node.
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 17]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   The resulting Path message is used to create the recovery LSP.  While
+   the recovery LSP exists, the PROTECTION object in the original Path
+   message  (unless overridden by local policy) MUST also be updated
+   with the In-Place bit set (1).  From this point on, Standard Path
+   message processing is used in processing the resulting and original
+   Path messages.
+
+   The merge node of a dynamically controlled recovery LSP SHOULD reset
+   (0) the In-Place bit in the PROTECTION object of the outgoing Path
+   message associated with the terminated recovery LSP.
+
+   Unlike with explicit control, if the creation of a dynamically
+   identified recovery LSP fails for any reason, the recovery LSP is
+   removed, and no error message or indication is sent upstream.  With
+   this exception, all the other procedures for explicitly controlled
+   recovery LSPs apply to dynamically controlled recovery LSPs.  These
+   other procedures are defined above in Sections 4.2.1 through 4.2.4.
+
+7.  Updated RSVP Message Formats
+
+   This section presents the RSVP message related formats as modified by
+   this document.  Where they differ, formats for unidirectional LSPs
+   are presented separately from bidirectional LSPs.
+
+   The format of a Path message is as follows:
+
+   <Path Message> ::=   <Common Header> [ <INTEGRITY> ]
+                        [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
+                        [ <MESSAGE_ID> ]
+                        <SESSION> <RSVP_HOP>
+                        <TIME_VALUES>
+                        [ <EXPLICIT_ROUTE> ]
+                         <LABEL_REQUEST>
+                         [ <PROTECTION> ]
+                         [ <LABEL_SET> ... ]
+                         [ <SESSION_ATTRIBUTE> ]
+                         [ <NOTIFY_REQUEST> ... ]
+                         [ <ADMIN_STATUS> ]
+                         [ <ASSOCIATION> ... ]
+                         [ <SECONDARY_EXPLICIT_ROUTE> ... ]
+                         [ <POLICY_DATA> ... ]
+                         <sender descriptor>
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 18]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   The format of the sender description for unidirectional LSPs is:
+
+   <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
+                            [ <ADSPEC> ]
+                            [ <RECORD_ROUTE> ]
+                            [ <SUGGESTED_LABEL> ]
+                            [ <RECOVERY_LABEL> ]
+                            [ <SECONDARY_RECORD_ROUTE> ... ]
+
+   The format of the sender description for bidirectional LSPs is:
+
+   <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
+                            [ <ADSPEC> ]
+                            [ <RECORD_ROUTE> ]
+                            [ <SUGGESTED_LABEL> ]
+                            [ <RECOVERY_LABEL> ]
+                            <UPSTREAM_LABEL>
+                            [ <SECONDARY_RECORD_ROUTE> ... ]
+
+   The format of a PathErr message is as follows:
+
+   <PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
+                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
+                         [ <MESSAGE_ID> ]
+                         <SESSION> <ERROR_SPEC>
+                         [ <ACCEPTABLE_LABEL_SET> ... ]
+                         [ <SECONDARY_EXPLICIT_ROUTE> ... ]
+                         [ <POLICY_DATA> ... ]
+                         <sender descriptor>
+
+   The format of a Resv message is as follows:
+
+   <Resv Message> ::=    <Common Header> [ <INTEGRITY> ]
+                         [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
+                         [ <MESSAGE_ID> ]
+                         <SESSION> <RSVP_HOP>
+                         <TIME_VALUES>
+                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
+                         [ <NOTIFY_REQUEST> ... ]
+                         [ <ADMIN_STATUS> ]
+                         [ <POLICY_DATA> ... ]
+                         <STYLE> <flow descriptor list>
+
+   <flow descriptor list> ::= <FF flow descriptor list>
+                            | <SE flow descriptor>
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 19]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   <FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
+                            <LABEL> [ <RECORD_ROUTE> ]
+                            [ <SECONDARY_RECORD_ROUTE> ... ]
+                            | <FF flow descriptor list>
+                            <FF flow descriptor>
+
+   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
+                            [ <RECORD_ROUTE> ]
+                            [ <SECONDARY_RECORD_ROUTE> ... ]
+
+   <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> ::=     <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
+                            [ <SECONDARY_RECORD_ROUTE> ... ]
+
+8.  Security Considerations
+
+   This document introduces new message objects for use in GMPLS
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 20]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+9.  IANA Considerations
+
+   IANA has assigned the following values for the namespaces defined in
+   this document and reviewed in this section.
+
+9.1.  New Association Type Assignment
+
+   IANA has made the following assignment to the "GMPLS Signaling
+   Parameters" Registry (see [RFC4872]) located at
+   http://www.iana.org/assignments/gmpls-sig-parameters.
+
+      Value       Type
+      -----       ----
+        2         Resource Sharing (R) [RFC4873]
+
+9.2.  Definition of PROTECTION Object Reserved Bits
+
+   This document defines bits carried in the Reserved field of the
+   PROTECTION object defined in [RFC4872].  As no IANA registry for
+   these bits is requested in [RFC4872], no IANA action is required
+   related to this definition.
+
+9.3.  Secondary Explicit Route Object
+
+   IANA has made the following assignments in the "Class Names, Class
+   Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
+   located at http://www.iana.org/assignments/rsvp-parameters.
+
+   A new class named SECONDARY_EXPLICIT_ROUTE has been created in the
+   11bbbbbb range (200) with the following definition:
+      Class Types or C-types:
+
+      Same values as EXPLICIT_ROUTE object (C-Num 20)
+
+      For Class 1, C-Type 1, the following additional Subobject type is
+      defined:
+
+         37   PROTECTION              [RFC4873]
+
+9.4.  Secondary Record Route Object
+
+   IANA has made the following assignments in the "Class Names, Class
+   Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
+   located at http://www.iana.org/assignments/rsvp-parameters.
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 21]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+   A new class named SECONDARY_RECORD_ROUTE has been created in the
+   11bbbbbb range (201) with the following definition:
+
+      Class Types or C-types:
+
+      Same values as RECORD_ROUTE object (C-Num 21)
+
+      For Class 1, C-Type 1, the following additional Subobject type is
+      defined:
+
+         37   PROTECTION              [RFC4873]
+
+9.5.  New Error Code
+
+   IANA has made the following assignments in the "Routing Problem"
+   subsection of "Error Codes and Values" section of the "RSVP
+   PARAMETERS" registry located at
+   http://www.iana.org/assignments/rsvp-parameters.
+
+   21 = LSP Segment Protection Failed [RFC4873]
+
+9.6.  Use of PROTECTION Object C-type
+
+   This document modifies the PROTECTION object, class number 37, C-Type
+   2 (defined in Section 14.1. of [RFC4872]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 22]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2205]   Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
+               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+               Functional Specification", RFC 2205, September 1997.
+
+   [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+               Tunnels", RFC 3209, December 2001.
+
+   [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
+               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+               3473, January 2003.
+
+   [RFC4872]   Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
+               Ed., "RSVP-TE Extensions in support of End-to-End
+               Generalized Multi-Protocol Label Switching (GMPLS)
+               Recovery", RFC 4872, May 2007.
+
+10.2.  Informative References
+
+   [RFC4090]   Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
+               Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
+               2005.
+
+   [RFC4426]   Lang, J., Ed., Rajagopalan, B., Ed., and D.
+               Papadimitriou, Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Recovery Functional Specification," RFC
+               4426, March 2006.
+
+   [RFC4427]   Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
+               (Protection and Restoration) Terminology for Generalized
+               Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
+               2006.
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 23]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+Authors' Addresses
+
+   Lou Berger
+   LabN Consulting, L.L.C.
+
+   Phone:  +1 301-468-9228
+   EMail:  lberger@labn.net
+
+
+   Igor Bryskin
+   ADVA Optical
+   7926 Jones Branch Drive
+   Suite 615
+   McLean VA, 22102
+
+   EMail:  IBryskin@advaoptical.com
+
+
+   Dimitri Papadimitriou
+   Alcatel
+   Francis Wellesplein 1
+   B-2018 Antwerpen, Belgium
+
+   Phone:  +32 3 240-8491
+   EMail:  dimitri.papadimitriou@alcatel-lucent.be
+
+
+   Adrian Farrel
+   Old Dog Consulting
+
+   Phone:  +44 (0) 1978 860944
+   EMail:  adrian@olddog.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 24]
+
+RFC 4873                 GMPLS Segment Recovery                 May 2007
+
+
+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
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Berger, et al.              Standards Track                    [Page 25]
+