draft-ietf-teas-rsvp-te-srlg-collect-08.txt   rfc8001.txt 
TEAS Working Group F. Zhang, Ed. Internet Engineering Task Force (IETF) F. Zhang, Ed.
Internet-Draft Huawei Request for Comments: 8001 Huawei
Intended status: Standards Track O. Gonzalez de Dios, Ed. Category: Standards Track O. Gonzalez de Dios, Ed.
Expires February 24, 2017 Telefonica Global CTO ISSN: 2070-1721 Telefonica Global CTO
C. Margaria
Juniper
M. Hartley M. Hartley
Z. Ali Z. Ali
Cisco Cisco
C. Margaria January 2017
August 24, 2016
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting
draft-ietf-teas-rsvp-te-srlg-collect-08 Shared Risk Link Group (SRLG) Information
Abstract Abstract
This document provides extensions for the Resource ReserVation This document provides extensions for Resource Reservation Protocol -
Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support Traffic Engineering (RSVP-TE), including GMPLS, to support automatic
automatic collection of Shared Risk Link Group (SRLG) information for collection of Shared Risk Link Group (SRLG) information for the TE
the TE link formed by a Label Switched Path (LSP). link formed by a Label Switched Path (LSP).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 24, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8001.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Example: Dual Homing . . . . . . . . . . . . 3 1.1. Applicability Example: Dual-Homing . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . . 5 3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.1. SRLG Collection Indication . . . . . . . . . . . . . . . . 5 3.1. SRLG Collection Indication . . . . . . . . . . . . . . . . 5
3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5 3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 6
3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. SRLG ID definition . . . . . . . . . . . . . . . . . . . . 6 3.4. SRLG ID Definition . . . . . . . . . . . . . . . . . . . . 6
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . . 6 4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . . 6
4.2. RRO SRLG sub-object . . . . . . . . . . . . . . . . . . . 6 4.2. RRO SRLG Subobject . . . . . . . . . . . . . . . . . . . 7
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 8 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 8
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10 5.3 Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10
5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 11
6. Manageability Considerations . . . . . . . . . . . . . . . . . 10 6. Manageability Considerations . . . . . . . . . . . . . . . . . 11
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 11 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 11
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 11 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 12
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12
8.3. Policy Control Failure Error subcodes . . . . . . . . . . 12 8.3. Policy Control Failure Error Subcodes . . . . . . . . . . 13
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 13 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
It is important to understand which Traffic Engineering (TE) links in It is important to understand which Traffic Engineering (TE) links in
the network might be at risk from the same failures. In this sense, a given network might be at risk from the same failures. In this
a set of links can constitute a 'shared risk link group' (SRLG) if sense, a set of links can constitute a Shared Risk Link Group (SRLG)
they share a resource whose failure can affect all links in the set if they share a resource whose failure can affect all links in the
[RFC4202]. set [RFC4202].
On the other hand, as described in [RFC4206] and [RFC6107], H-LSP On the other hand, as described in [RFC4206] and [RFC6107], a
(Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying Hierarchical LSP (H-LSP) or stitched LSP (S-LSP) can be used for
one or more other LSPs. Both of the H-LSP and S-LSP can be formed as carrying one or more other LSPs. Both the H-LSP and S-LSP can be
a TE link. In such cases, it is important to know the SRLG formed as a TE link. In such cases, it is important to know the SRLG
information of the LSPs that will be used to carry further LSPs. information of the LSPs that will be used to carry further LSPs.
This document provides a signaling mechanism to collect the SRLGs This document provides a signaling mechanism that collects the SRLGs
used by a LSP, which can then be advertized as properties of the TE- that are used by an LSP and can then be advertised as properties of
link formed by that LSP. the TE link formed by that LSP.
1.1. Applicability Example: Dual Homing 1.1. Applicability Example: Dual-Homing
An interesting use case for the SRLG collection procedures defined in An interesting use case for the SRLG collection procedures defined in
this document is achieving LSP diversity in a dual homing scenario. this document is achieving LSP diversity in a dual-homing scenario.
The use case is illustrated in Figure 1, when the overlay model is The use case is illustrated in Figure 1, when the overlay model is
applied as defined in RFC 4208 [RFC4208] . In this example, the applied as defined in [RFC4208]. In this example, the exchange of
exchange of routing information over the User-Network Interface (UNI) routing information over the User-Network Interface (UNI) is
is prohibited by operator policy. prohibited by operator policy.
+---+ +---+ +---+ +---+
| P |....| P | | P |....| P |
+---+ +---+ +---+ +---+
/ \ / \
+-----+ +-----+ +-----+ +-----+
+---+ | PE1 | | PE3 | +---+ +---+ | PE1 | | PE3 | +---+
|CE1|----| | | |----|CE2| |CE1|----| | | |----|CE2|
+---+\ +-----+ +-----+ /+---+ +---+\ +-----+ +-----+ /+---+
\ | | / \ | | /
\ +-----+ +-----+ / \ +-----+ +-----+ /
\| PE2 | | PE4 |/ \| PE2 | | PE4 |/
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
\ / \ /
+---+ +---+ +---+ +---+
| P |....| P | | P |....| P |
+---+ +---+ +---+ +---+
Figure 1: Dual Homing Configuration Figure 1: Dual-Homing Configuration
Single-homed customer edge (CE) devices are connected to a single Single-homed customer edge (CE) devices are connected to a single
provider edge (PE) device via a single UNI link (which could be a provider edge (PE) device via a single UNI link (which could be a
bundle of parallel links, typically using the same fiber cable). This bundle of parallel links, typically using the same fiber cable).
single UNI link can constitute a single point of failure. Such a This single UNI link can constitute a single point of failure. Such
single point of failure can be avoided if the CE device is connected a single point of failure can be avoided if the CE device is
to two PE devices via two UNI interfaces as depicted in Figure 1 connected to two PE devices via two UNI interfaces for CE1 and CE2,
above for CE1 and CE2, respectively. respectively, as depicted in Figure 1.
For the dual-homing case, it is possible to establish two connections For the dual-homing case, it is possible to establish two connections
(LSPs) from the source CE device to the same destination CE device (LSPs) from the source CE device to the same destination CE device
where one connection is using one UNI link to PE1, for example, and where one connection is using one UNI link to PE1, for example, and
the other connection is using the UNI link to PE2. In order to avoid the other connection is using the UNI link to PE2. In order to avoid
single points of failure within the provider network, it is necessary single points of failure within the provider network, it is necessary
to also ensure path (LSP) diversity within the provider network in to also ensure path (LSP) diversity within the provider network to
order to achieve end-to-end diversity for the two LSPs between the achieve end-to-end diversity for the two LSPs between the two CE
two CE devices CE1 and CE2. This use case describes how it is devices CE1 and CE2. This use case describes how it is possible to
possible to achieve path diversity within the provider network based achieve path diversity within the provider network based on collected
on collected SRLG information. As the two connections (LSPs) enter SRLG information. As the two connections (LSPs) enter the provider
the provider network at different PE devices, the PE device that network at different PE devices, the PE device that receives the
receives the connection request for the second connection needs to connection request for the second connection needs to know the
know the additional path computation constraints such that the path additional path computation constraints such that the path of the
of the second LSP is disjoint with respect to the already established second LSP is disjoint with respect to the already established first
first connection. connection.
As SRLG information is normally not shared between the provider As SRLG information is normally not shared between the provider
network and the client network, i.e., between PE and CE devices, the network and the client network, i.e., between PE and CE devices, the
challenge is how to solve the diversity problem when a CE is dual- challenge is how to solve the diversity problem when a CE is dual-
homed. The RSVP extensions for collecting SRLG information defined homed. The RSVP extensions for collecting SRLG information defined
in this document make it possible to retrieve SRLG information for an in this document make it possible to retrieve SRLG information for an
LSP and hence solve the dual-homing LSP diversity problem. For LSP and hence solve the dual-homing LSP diversity problem. For
example, CE1 in Figure 1 may have requested an LSP1 to CE2 via PE1 example, CE1 in Figure 1 may have requested an LSP1 to CE2 via PE1
that is routed via PE3 to CE2. CE1 can then subsequently request an that is routed via PE3 to CE2. CE1 can then subsequently request an
LSP2 to CE2 via PE2 with the constraint that it needs to be maximally LSP2 to CE2 via PE2 with the constraint that it needs to be maximally
SRLG disjoint with respect to LSP1. PE2, however, does not have any SRLG disjoint with respect to LSP1. PE2, however, does not have any
SRLG information associated with LSP1, which is needed as input for SRLG information associated with LSP1, and this is needed as input
its constraint-based path computation function. If CE1 is capable of for its constraint-based path computation function. If CE1 is
retrieving the SRLG information associated with LSP1 from PE1, it can capable of retrieving the SRLG information associated with LSP1 from
pass this discovered information to PE2 as part of the LSP2 setup PE1, it can pass this discovered information to PE2 as part of the
request (RSVP PATH message) in an EXCLUDE_ROUTE Object (XRO) or LSP2 setup request (RSVP PATH message) in an EXCLUDE_ROUTE Object
Explicit Exclusion Route Subobject (EXRS) as described in [RFC4874], (XRO) or Explicit Exclusion Route Subobject (EXRS) as described in
and PE2 can now calculate a path for LSP2 that is SRLG disjoint with [RFC4874], and PE2 can now calculate a path for LSP2 that is SRLG
respect to LSP1. The SRLG information associated with LSP1 can be disjoint with respect to LSP1. The SRLG information associated with
retrieved when LSP1 is established or at any time before LSP2 is LSP1 can be retrieved when LSP1 is established or at any time before
setup. LSP2 is set up.
When CE1 sends the setup request for LSP2 to PE2, it can also request When CE1 sends the setup request for LSP2 to PE2, it can also request
the collection of SRLG information for LSP2 and send that information the collection of SRLG information for LSP2 and send that information
to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's
discovered SRLGs. This will ensure that the two paths for the two discovered SRLGs. This will ensure that the two paths for the two
LSPs remain mutually diverse, which is important when the provider LSPs remain mutually diverse; this is important when the provider
network is capable of restoring connections that failed due to a network is capable of restoring connections that failed due to a
network failure (fiber cut) in the provider network. network failure (fiber cut) in the provider network.
Note that the knowledge of SRLG information even for multiple LSPs Note that the knowledge of SRLG information even for multiple LSPs
does not allow a CE device to derive the provider network topology does not allow a CE device to derive the provider network topology
based on the collected SRLG information. It would, however, be based on the collected SRLG information. It would, however, be
possible for an entity controlling multiple CE devices to derive some possible for an entity controlling multiple CE devices to derive some
information related to the topology. This document therefore allows information related to the topology. This document therefore allows
PE devices to control the communication of SRLGs outside the provider PE devices to control the communication of SRLGs outside the provider
network if desired. network if desired.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. RSVP-TE Requirements 3. RSVP-TE Requirements
The SRLG-collection process takes place in three stages: The SRLG collection process takes place in three stages:
o The LSP's ingress node requests that SRLG collection take place; o The LSP's ingress node requests that SRLG collection take place;
o SRLG data is added to the Path and Resv ROUTE_RECORD Objects o SRLG data is added to the Path and Resv ROUTE_RECORD Objects
(RROs) by all nodes during signaling; (RROs) by all nodes during signaling;
o Changes to previously-signaled SRLG data are made by sending o Changes to previously signaled SRLG data are made by sending
updated Path and Resv messages as required. updated Path and Resv messages as required.
3.1. SRLG Collection Indication 3.1. SRLG Collection Indication
The ingress node of the LSP needs be capable of indicating whether The ingress node of the LSP needs be capable of indicating whether
the SRLG information of the LSP is to be collected during the the SRLG information of the LSP is to be collected during the
signaling procedure of setting up an LSP. There is no need for SRLG signaling procedure of setting up an LSP. There is no need for SRLG
information to be collected without an explicit request for it being information to be collected without an explicit request by the
made by the ingress node. ingress node.
It may be preferable for the SRLG collection request to be understood It may be preferable for the SRLG collection request to be understood
by all nodes along the LSP's path, or it may be more important for by all nodes along the LSP's path, or it may be more important for
the LSP to be established successfully even if it traverses nodes the LSP to be established successfully even if it traverses nodes
that cannot supply SRLG information or have not implemented the that cannot supply SRLG information or have not implemented the
procedures specified in this document. It is desirable for the procedures specified in this document. It is desirable for the
ingress node to make the SRLG collection request in a manner that ingress node to make the SRLG collection request in a manner that
best suits its own policy. best suits its own policy.
3.2. SRLG Collection 3.2. SRLG Collection
If requested, the SRLG information is collected during the setup of If requested, the SRLG information is collected during the setup of
an LSP. SRLG information is added by each hop to the Path RRO during an LSP. SRLG information is added by each hop to the Path RRO during
Path message processing. The same information is also added to the Path message processing. The same information is also added to the
Resv RRO during Resv processing at each hop. Resv RRO during Resv processing at each hop.
3.3. SRLG Update 3.3. SRLG Update
When the SRLG information of an existing LSP for which SRLG When the SRLG information of an existing LSP for which SRLG
information was collected during signaling changes, the relevant information was collected during signaling changes, the relevant
nodes of the LSP need to be capable of updating the SRLG information nodes of the LSP need to be capable of updating the SRLG information
of the LSP. This means that the signaling procedure needs to be of the LSP. This means that the signaling procedure needs to be
capable of updating the new SRLG information. capable of updating the new SRLG information.
3.4. SRLG ID definition 3.4. SRLG ID Definition
The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity
in [RFC4202]. This definition is used in this document. in [RFC4202]. This definition is used in this document.
4. Encodings 4. Encodings
4.1. SRLG Collection Flag 4.1. SRLG Collection Flag
In order to indicate to nodes that SRLG collection is desired, this In order to indicate to nodes that SRLG collection is desired, this
document defines a new flag in the Attribute Flags TLV (see RFC 5420 document defines a new flag in the Attribute Flags TLV (see
[RFC5420]). This document defines a new SRLG collection flag in the [RFC5420]). This document defines a new SRLG Collection Flag in the
Attribute Flags TLV (see RFC 5420 [RFC5420]). A node that wishes to Attribute Flags TLV. A node that wishes to indicate that SRLG
indicate that SRLG collection is desired MUST set this flag in an collection is desired MUST set this flag in an Attribute Flags TLV in
Attribute Flags TLV in an LSP_REQUIRED_ATTRIBUTES Object if an LSP_REQUIRED_ATTRIBUTES object (if collection is to be mandatory)
collection is to be mandatory, or an LSP_ATTRIBUTES Object if or an LSP_ATTRIBUTES object (if collection is desired but not
collection is desired but not mandatory. mandatory).
o Bit Number (specified in Section 8.1): SRLG Collection flag o Bit Number (specified in Section 8.1): SRLG Collection Flag
The SRLG Collection flag is meaningful on a Path message. If the The SRLG Collection Flag is meaningful on a Path message. If the
SRLG Collection flag is set to 1, it means that the SRLG information SRLG Collection Flag is set to 1, it means that the SRLG information
SHOULD be reported to the ingress and egress node along the setup of SHOULD be reported to the ingress and egress node along the setup of
the LSP. the LSP.
The rules for the processing of the Attribute Flags TLV are not The rules for the processing of the Attribute Flags TLV are not
changed. changed.
4.2. RRO SRLG sub-object 4.2. RRO SRLG Subobject
This document defines a new RRO sub-object (ROUTE_RECORD sub-object) This document defines a new RRO subobject (ROUTE_RECORD subobject) to
to record the SRLG information of the LSP. Its format is modeled on record the SRLG information of the LSP. Its format is modeled on the
the RRO sub-objects defined in RFC 3209 [RFC3209]. RRO subobjects defined in [RFC3209].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |D| Reserved | | Type | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 octets) | | SRLG ID 1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~ ~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 octets) | | SRLG ID n (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits) Type (8 bits)
The type of the sub-object. The value is specified in Section 8.2. The type of the subobject. The value is specified in Section 8.2.
Length (8 bits) Length (8 bits)
The Length field contains the total length of the sub-object in The Length field contains the total length of the subobject in
octets, including the Type and Length fields. The Length depends on octets, including the Type and Length fields. The Length depends on
the number of SRLG IDs. the number of SRLG IDs.
Direction bit (D-bit) (1 bit) Direction bit (D-bit) (1 bit)
If not set, the SRLGs contained in this sub-object apply to the If not set, the SRLGs contained in this subobject apply to the
downstream direction. If set, they apply to the upstream direction. downstream direction. If set, they apply to the upstream direction.
Reserved (15 bits) Reserved (15 bits)
This 15-bit field is reserved. It SHOULD be set to zero on This 15-bit field is reserved. It SHOULD be set to zero on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
SRLG ID (4 octets) SRLG ID (4 octets)
This field contains one SRLG ID. There is one SRLG ID field per SRLG This field contains one SRLG ID. There is one SRLG ID field per SRLG
collected. There MAY be multiple SRLG ID fields in an SRLG sub- collected. There MAY be multiple SRLG ID fields in an SRLG
object. subobject.
A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without A node MUST NOT push an SRLG subobject in the ROUTE_RECORD without
also pushing either a IPv4 sub-object, a IPv6 sub-object, a also pushing either an IPv4 subobject, an IPv6 subobject, an
Unnumbered Interface ID sub-object or a Path Key sub-object. Unnumbered Interface ID subobject, or a Path Key Subobject (PKS).
As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is As described in [RFC3209], the ROUTE_RECORD object is managed as a
managed as a stack. The SRLG sub-object MUST be pushed by the node stack. The SRLG subobject MUST be pushed by the node before the node
before the node IP address or link identifier. The SRLG-sub-object IP address or link identifier. The SRLG subobject SHOULD be pushed
SHOULD be pushed after the Attribute sub-object, if present, and after the Attribute subobject, if present, and after the LABEL
after the LABEL sub-object, if requested. It MUST be pushed within subobject, if requested. It MUST be pushed within the hop to which
the hop to which it applies. it applies.
RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub- [RFC5553] describes mechanisms to carry a PKS in the RRO so as to
object) in the RRO so as to facilitate confidentiality in the facilitate confidentiality in the signaling of inter-domain TE LSPs.
signaling of inter-domain TE LSPs, and allows the path segment that RFC 5553 allows the path segment that needs to be hidden (that is, a
needs to be hidden (that is, a Confidential Path Segment (CPS)) to be Confidential Path Segment (CPS)) to be replaced in the RRO with a
replaced in the RRO with a PKS. If the CPS contains SRLG Sub- PKS. If the CPS contains SRLG subobjects, these MAY be retained in
objects, these MAY be retained in the RRO by adding them again after the RRO by adding them again after the PKS in the RRO. The CPS is
the PKS Sub-object in the RRO. The CPS is defined in RFC 5520 defined in [RFC5520].
[RFC5520].
The rules for the processing of the LSP_REQUIRED_ATTRIBUTES, The rules for the processing of the LSP_REQUIRED_ATTRIBUTES,
LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. LSP_ATTRIBUTES, and ROUTE_RECORD objects are not changed.
5. Signaling Procedures 5. Signaling Procedures
The ingress node of the LSP MUST be capable of indicating whether the The ingress node of the LSP MUST be capable of indicating whether the
SRLG information of the LSP is to be collected during the signaling SRLG information of the LSP is to be collected during the signaling
procedure of setting up an LSP. procedure of setting up an LSP.
5.1. SRLG Collection 5.1. SRLG Collection
Per RFC 3209 [RFC3209], an ingress node initiates the recording of Per [RFC3209], an ingress node initiates the recording of the route
the route information of an LSP by adding a RRO to a Path message. If information of an LSP by adding an RRO to a Path message. If an
an ingress node also desires SRLG recording, it MUST set the SRLG ingress node also desires SRLG recording, it MUST set the SRLG
Collection Flag in the Attribute Flags TLV which MAY be carried Collection Flag in the Attribute Flags TLV, which MAY be carried in
either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is either an LSP_REQUIRED_ATTRIBUTES object (when the collection is
mandatory, or in an LSP_ATTRIBUTES Object when the collection is mandatory) or an LSP_ATTRIBUTES object (when the collection is
desired, but not mandatory. desired, but not mandatory).
A node MUST NOT add SRLG information without an explicit request for A node MUST NOT add SRLG information without an explicit request by
it being made by the ingress node in the Path message. the ingress node in the Path message.
When a node receives a Path message which carries an When a node receives a Path message that carries an
LSP_REQUIRED_ATTRIBUTES Object with the SRLG Collection Flag set, if LSP_REQUIRED_ATTRIBUTES object with the SRLG Collection Flag set, if
local policy determines that the SRLG information is not to be local policy determines that the SRLG information is not to be
provided to the endpoints, it MUST return a PathErr message with: provided to the endpoints, it MUST return a PathErr message with
o Error Code 2 (policy) and o Error Code 2 (policy) and
o Error subcode "SRLG Recording Rejected" (see Section 8.3 for o Error subcode "SRLG Recording Rejected" (see Section 8.3 for
value) value)
to reject the Path message. to reject the Path message.
When a node receives a Path message which carries an LSP_ATTRIBUTES When a node receives a Path message that carries an LSP_ATTRIBUTES
Object with the SRLG Collection Flag set, if local policy determines object with the SRLG Collection Flag set, if local policy determines
that the SRLG information is not to be provided to the endpoints, the that the SRLG information is not to be provided to the endpoints, the
Path message MUST NOT be rejected due to the SRLG recording Path message MUST NOT be rejected due to the SRLG recording
restriction and the Path message MUST be forwarded without any SRLG restriction, and the Path message MUST be forwarded without any SRLG
sub-object(s) added to the RRO of the corresponding outgoing Path subobject(s) added to the RRO of the corresponding outgoing Path
message. message.
If local policy permits the recording of the SRLG information, the If local policy permits the recording of the SRLG information, the
processing node SHOULD add local SRLG information, as defined below, processing node SHOULD add local SRLG information, as defined below,
to the RRO of the corresponding outgoing Path message. The to the RRO of the corresponding outgoing Path message. The
processing node MAY add multiple SRLG sub-objects to the RRO if processing node MAY add multiple SRLG subobjects to the RRO if
necessary. It then forwards the Path message to the next node in the necessary. It then forwards the Path message to the next node in the
downstream direction. The processing node MUST retain a record of the downstream direction. The processing node MUST retain a record of
SRLG recording request for reference during Resv processing described the SRLG recording request for reference during Resv processing
below. described below.
If the addition of SRLG information to the RRO would result in the If the addition of SRLG information to the RRO would result in the
RRO exceeding its maximum possible size or becoming too large for the RRO exceeding its maximum possible size or becoming too large for the
Path message to contain it, the requested SRLGs MUST NOT be added. If Path message to contain it, the requested SRLGs MUST NOT be added.
the SRLG collection request was contained in an If the SRLG collection request was contained in an
LSP_REQUIRED_ATTRIBUTES Object, the processing node MUST behave as LSP_REQUIRED_ATTRIBUTES object, the processing node MUST behave as
specified by RFC 3209 [RFC3209] and drop the RRO from the Path
message entirely. If the SRLG collection request was contained in an
LSP_ATTRIBUTES Object, the processing node MAY omit some or all of
the requested SRLGs from the RRO; otherwise it MUST behave as
specified by [RFC3209] and drop the RRO from the Path message specified by [RFC3209] and drop the RRO from the Path message
entirely. Subsequent processing of the LSP proceeds as further entirely. If the SRLG collection request was contained in an
specified in RFC 3209 [RFC3209]. LSP_ATTRIBUTES object, the processing node MAY omit some or all of
the requested SRLGs from the RRO; otherwise, it MUST behave as
specified by [RFC3209] and drop the RRO from the Path message
entirely. Subsequent processing of the LSP proceeds as further
specified in [RFC3209].
Following the steps described above, the intermediate nodes of the Following the steps described above, the intermediate nodes of the
LSP can collect the SRLG information in the RRO during the processing LSP can collect the SRLG information in the RRO during the processing
of the Path message hop by hop. When the Path message arrives at the of the Path message hop by hop. When the Path message arrives at the
egress node, the egress node receives SRLG information in the RRO. egress node, the egress node receives SRLG information in the RRO.
Per RFC 3209 [RFC3209], when issuing a Resv message for a Path Per [RFC3209], when issuing a Resv message for a Path message that
message which contains an RRO, an egress node initiates the RRO contains an RRO, an egress node initiates the RRO process by adding
process by adding an RRO to the outgoing Resv message. The an RRO to the outgoing Resv message. The processing for RROs
processing for RROs contained in Resv messages then mirrors that of contained in Resv messages then mirrors that of the Path messages.
the Path messages.
When a node receives a Resv message for an LSP for which SRLG When a node receives a Resv message for an LSP for which SRLG
Collection was specified in the corresponding Path message, then when Collection was specified in the corresponding Path message, then when
local policy allows recording SRLG information, the node MUST add local policy allows recording SRLG information, the node MUST add
SRLG information to the RRO of the corresponding outgoing Resv SRLG information to the RRO of the corresponding outgoing Resv
message as specified below. When the Resv message arrives at the message as specified below. When the Resv message arrives at the
ingress node, the ingress node can extract the SRLG information from ingress node, the ingress node can extract the SRLG information from
the RRO in the same way as the egress node. the RRO in the same way as the egress node.
Note that a link's SRLG information for the upstream direction cannot Note that a link's SRLG information for the upstream direction cannot
be assumed to be the same as that in the downstream. be assumed to be the same as that for the downstream direction.
o For Path and Resv messages for a unidirectional LSP, a node SHOULD o For Path and Resv messages for a unidirectional LSP, a node SHOULD
include SRLG sub-objects in the RRO for the downstream data link include SRLG subobjects in the RRO for the downstream data link
only. only.
o For Path and Resv messages for a bidirectional LSP, a node SHOULD o For Path and Resv messages for a bidirectional LSP, a node SHOULD
include SRLG sub-objects in the RRO for both the upstream data include SRLG subobjects in the RRO for both the upstream data link
link and the downstream data link from the local node. In this and the downstream data link from the local node. In this case,
case, the node MUST include the information in the same order for the node MUST include the information in the same order for both
both Path messages and Resv messages. That is, the SRLG sub- Path messages and Resv messages. That is, the SRLG subobject for
object for the upstream link is added to the RRO before the SRLG the upstream link is added to the RRO before the SRLG subobject
sub-object for the downstream link. for the downstream link.
If SRLG data is added for both the upstream and downstream links, If SRLG data is added for both the upstream and downstream links,
the two sets of SRLG data MUST be added in separate SRLG sub- the two sets of SRLG data MUST be added in separate SRLG
objects. A single SRLG sub-object MUST NOT contain a mixture of subobjects. A single SRLG subobject MUST NOT contain a mixture of
upstream and downstream SRLGs. When adding a SRLG sub-object to an upstream and downstream SRLGs. When adding a SRLG subobject to an
RRO, the D-bit MUST be set appropriately to indicate the direction RRO, the D-bit MUST be set appropriately to indicate the direction
of the SRLGs. If an SRLG ID applies in both directions, it SHOULD of the SRLGs. If an SRLG ID applies in both directions, it SHOULD
be added to both the upstream and downstream SRLG sub-objects. be added to both the upstream and downstream SRLG subobjects.
Based on the above procedure, the endpoints can get the SRLG Based on the above procedure, the endpoints can get the SRLG
information automatically. Then the endpoints can for instance information automatically. Then, for instance, the endpoints can
advertise it as a TE link to the routing instance based on the advertise it as a TE link to the routing instance based on the
procedure described in [RFC6107] and configure the SRLG information procedure described in [RFC6107] and configure the SRLG information
of the Forwarding Adjacency (FA) automatically. of the Forwarding Adjacency (FA) automatically.
5.2. SRLG Update 5.2. SRLG Update
When the SRLG information of a link is changed, the endpoints of LSPs When the SRLG information of a link is changed, the endpoints of LSPs
using that link need to be made aware of the changes. When a change using that link need to be made aware of the changes. When a change
to the set of SRLGs associated with a link occurs, the procedures to the set of SRLGs associated with a link occurs, the procedures
defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to defined in Section 4.4.3 of [RFC3209] MUST be used to refresh the
refresh the SRLG information for each affected LSP if the SRLG change SRLG information for each affected LSP if the local node's policy
is to be communicated to other nodes according to the local node's dictates that the SRLG change be communicated to other nodes.
policy.
5.3 Domain Boundaries 5.3 Domain Boundaries
If mandated by local policy as specified by the network operator, a If mandated by local policy as specified by the network operator, a
node MAY remove SRLG information from any RRO in a Path or Resv node MAY remove SRLG information from any RRO in a Path or Resv
message being processed. It MAY add a summary of the removed SRLGs or message being processed. It MAY add a summary of the removed SRLGs
map them to other SRLG values. However, this SHOULD NOT be done or map them to other SRLG values. However, this SHOULD NOT be done
unless explicitly mandated by local policy. unless explicitly mandated by local policy.
5.4. Compatibility 5.4. Compatibility
A node that does not recognize the SRLG Collection Flag in the A node that does not recognize the SRLG Collection Flag in the
Attribute Flags TLV is expected to proceed as specified in RFC 5420 Attribute Flags TLV is expected to proceed as specified in [RFC5420].
[RFC5420]. It is expected to pass the TLV on unaltered if it appears It is expected to pass the TLV on unaltered if it appears in an
in a LSP_ATTRIBUTES object, or reject the Path message with the LSP_ATTRIBUTES object or to reject the Path message with the
appropriate Error Code and Value if it appears in a appropriate Error Code and Value if it appears in a
LSP_REQUIRED_ATTRIBUTES object. LSP_REQUIRED_ATTRIBUTES object.
A node that does not recognize the SRLG RRO sub-object is expected to A node that does not recognize the SRLG RRO subobject is expected to
behave as specified in RFC 3209 [RFC3209]: unrecognized sub-objects behave as specified in [RFC3209]: unrecognized subobjects are to be
are to be ignored and passed on unchanged. ignored and passed on unchanged.
6. Manageability Considerations 6. Manageability Considerations
6.1. Policy Configuration 6.1. Policy Configuration
In a border node of inter-domain or inter-layer network, the In a border node of an inter-domain or inter-layer network, the
following SRLG processing policy MUST be capable of being configured: following SRLG processing policy MUST be capable of being configured:
o Whether the node is allowed to participate in SRLG collection and o Whether the node is allowed to participate in SRLG collection and
notify changes to collected SRLG information to endpoint nodes as notify changes to collected SRLG information to endpoint nodes as
described in section 5.2. described in Section 5.2.
o Whether the SRLG IDs of the domain or specific layer network can o Whether the SRLG IDs of the domain or specific layer network can
be exposed to the nodes outside the domain or layer network, or be exposed to the nodes outside the domain or layer network, or
whether they SHOULD be summarized, mapped to values that are whether they SHOULD be summarized, mapped to values that are
comprehensible to nodes outside the domain or layer network, or comprehensible to nodes outside the domain or layer network, or
removed entirely as described in section 5.3. removed entirely as described in Section 5.3.
A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy. A node using [RFC5553] and PKS MAY apply the same policy.
6.2. Coherent SRLG IDs 6.2. Coherent SRLG IDs
In a multi-layer multi-domain scenario, SRLG IDs can be configured by In a multi-layer, multi-domain scenario, SRLG IDs can be configured
different management entities in each layer/domain. In such by different management entities in each layer or domain. In such
scenarios, maintaining a coherent set of SRLG IDs is a key scenarios, maintaining a coherent set of SRLG IDs is a key
requirement in order to be able to use the SRLG information properly. requirement in order to be able to use the SRLG information properly.
Thus, SRLG IDs SHOULD be unique. Note that current procedure is Thus, SRLG IDs SHOULD be unique. Note that current procedures are
targeted towards a scenario where the different layers and domains targeted towards a scenario where the different layers and domains
belong to the same operator, or to several coordinated administrative belong to the same operator or to several coordinated administrative
groups. Ensuring the aforementioned coherence of SRLG IDs is beyond groups. Ensuring the aforementioned coherence of SRLG IDs is beyond
the scope of this document. the scope of this document.
Further scenarios, where coherence in the SRLG IDs cannot be Further scenarios, where coherence in the SRLG IDs cannot be
guaranteed are out of the scope of the present document and are left guaranteed, are out of the scope of the present document and are left
for further study. for further study.
7. Security Considerations 7. Security Considerations
This document builds on the mechanisms defined in [RFC3473], which This document builds on the mechanisms defined in [RFC3473], which
also discusses related security measures. In addition, [RFC5920] also discusses related security measures. In addition, [RFC5920]
provides an overview of security vulnerabilities and protection provides an overview of security vulnerabilities and protection
mechanisms for the GMPLS control plane. The procedures defined in mechanisms for the GMPLS control plane. The procedures defined in
this document permit the transfer of SRLG data between layers or this document permit the transfer of SRLG data between layers or
domains during the signaling of LSPs, subject to policy at the layer domains during the signaling of LSPs, subject to policy at the layer
or domain boundary. As described in section 5.3 and section 6.1, or domain boundary. As described in Sections 5.3 and 6.1, local
local policy as specified by the network operator will explicitly policy as specified by the network operator will explicitly mandate
mandate the processing of information at domain or layer boundaries. the processing of information at domain or layer boundaries.
8. IANA Considerations 8. IANA Considerations
8.1. RSVP Attribute Bit Flags 8.1. RSVP Attribute Bit Flags
IANA has created a registry and manages the space of the Attribute IANA has created a registry and manages the space of the Attribute
bit flags of the Attribute Flags TLV, as described in section 11.3 of bit flags of the Attribute Flags TLV, as described in Section 11.3 of
RFC 5420 [RFC5420], in the "Attribute Flags" section of the "Resource [RFC5420], in the "Attribute Flags" subregistry of the "Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters"
registry located in http://www.iana.org/assignments/rsvp-te- registry located at
parameters". <http://www.iana.org/assignments/rsvp-te-parameters>.
This document introduces a new Attribute Bit Flag: This document introduces a new Attribute bit flag:
Bit No Name Attribute Attribute ERO RRO Reference Bit No Name Attribute Attribute RRO ERO Reference
Flags Path Flags Resv Flags Path Flags Resv
--------- ---------- ---------- ----------- --- --- --------- --------- ---------- ---------- ----------- --- --- ---------
TBD; SRLG Yes No No Yes This I-D 12 SRLG Yes No Yes No RFC 8001,
suggested Collection Collection [RFC7570]
value: 12 Flag Flag
8.2. ROUTE_RECORD Object 8.2. ROUTE_RECORD Object
IANA manages the "RSVP PARAMETERS" registry located at IANA manages the "Resource Reservation Protocol (RSVP) Parameters"
http://www.iana.org/assignments/rsvp-parameters. This document registry located at
introduces a new RRO sub-object: <http://www.iana.org/assignments/rsvp-parameters>. This document
introduces a new RRO subobject under the "Sub-object type - 21
ROUTE_RECORD - Type 1 Route Record" subregistry:
Value Description Reference Value Description Reference
--------------------- ------------------- --------- ----- ------------------- ---------
TBD; suggested SRLG sub-object This I-D 34 SRLG subobject RFC 8001
value: 34
8.3. Policy Control Failure Error subcodes 8.3. Policy Control Failure Error Subcodes
IANA manages the assignments in the "Error Codes and Globally-Defined IANA manages the assignments in the "Error Codes and Globally-Defined
Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry Error Value Sub-Codes" section of the "Resource Reservation Protocol
located at http://www.iana.org/assignments/rsvp-parameters. (RSVP) Parameters" registry located at
<http://www.iana.org/assignments/rsvp-parameters>.
This document introduces a new Policy Control Failure Error sub-code:
Value Description Reference
--------------------- ----------------------- ---------
TBD; suggested SRLG Recording Rejected This I-D
value: 21
9. Contributors
Dan Li
Huawei
F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129
P.R.China
Email: danli@huawei.com
10. Acknowledgements This document introduces a new value under "Sub-Codes - 2 Policy
Control Failure":
The authors would like to thank Dieter Beller, Vishnu Pavan Beeram, Value Description Reference
Lou Berger, Deborah Brungard, Igor Bryskin, Ramon Casellas, Niclas ----- ----------------------- ---------
Comstedt, Alan Davey, Elwyn Davies, Dhruv Dhody, Himanshu Shah and 21 SRLG Recording Rejected RFC 8001
Xian Zhang for their useful comments and improvements to this
document.
11. References 9. References
11.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation Protocol-
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Support of Generalized Multi-Protocol Label Switching Extensions in Support of Generalized Multi-Protocol Label
(GMPLS)", RFC 4202, October 2005. Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202,
October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009. Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
Topology Confidentiality in Inter-Domain Path Computation "Preserving Topology Confidentiality in Inter-Domain Path
Using a Path-Key-Based Mechanism", RFC 5520, April 2009. Computation Using a Path-Key-Based Mechanism", RFC 5520,
DOI 10.17487/RFC5520, April 2009,
<http://www.rfc-editor.org/info/rfc5520>.
[RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource
Reservation Protocol (RSVP) Extensions for Path Key Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009. Support", RFC 5553, DOI 10.17487/RFC5553, May 2009,
<http://www.rfc-editor.org/info/rfc5553>.
11.2. Informative References 9.2. Informative References
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005,
<http://www.rfc-editor.org/info/rfc4206>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User- "Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol- Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005. Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<http://www.rfc-editor.org/info/rfc4208>.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007. Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874,
April 2007, <http://www.rfc-editor.org/info/rfc4874>.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
[RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically [RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
Signaled Hierarchical Label Switched Paths", RFC 6107, Dynamically Signaled Hierarchical Label Switched Paths",
February 2011. RFC 6107, DOI 10.17487/RFC6107, February 2011,
<http://www.rfc-editor.org/info/rfc6107>.
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B.
Wright, "Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)", RFC 7570,
DOI 10.17487/RFC7570, July 2015,
<http://www.rfc-editor.org/info/rfc7570>.
Acknowledgements
The authors would like to thank Dieter Beller, Vishnu Pavan Beeram,
Lou Berger, Deborah Brungard, Igor Bryskin, Ramon Casellas, Niclas
Comstedt, Alan Davey, Elwyn Davies, Dhruv Dhody, Himanshu Shah, and
Xian Zhang for their useful comments and improvements to this
document.
Contributors
Dan Li
Huawei
F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129
China
Email: danli@huawei.com
Authors' Addresses Authors' Addresses
Fatai Zhang (editor) Fatai Zhang (editor)
Huawei Huawei
F3-5-B RD Center F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129 Bantian, Longgang District, Shenzhen 518129
P.R.China China
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Oscar Gonzalez de Dios (editor) Oscar Gonzalez de Dios (editor)
Telefonica Global CTO Telefonica Global CTO
Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045 Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045
Madrid 28050 Madrid 28050
Spain Spain
Phone: +34 913129647 Phone: +34 913129647
Email: oscar.gonzalezdedios@telefonica.com Email: oscar.gonzalezdedios@telefonica.com
Cyril Margaria Cyril Margaria
Suite 4001, 200 Somerset Corporate Blvd. Juniper
200 Somerset Corporate Blvd., Suite 4001
Bridgewater, NJ 08807 Bridgewater, NJ 08807
US United States of America
Email: cyril.margaria@gmail.com
Email: cmargaria@juniper.net
Matt Hartley Matt Hartley
Cisco Cisco
Email: mhartley@cisco.com Email: mhartley@cisco.com
Zafar Ali Zafar Ali
Cisco Cisco
Email: zali@cisco.com Email: zali@cisco.com
 End of changes. 119 change blocks. 
280 lines changed or deleted 313 lines changed or added

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