draft-ietf-teas-rsvp-te-srlg-collect-02.txt   draft-ietf-teas-rsvp-te-srlg-collect-03.txt 
TEAS Working Group F. Zhang, Ed. TEAS Working Group F. Zhang, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track O. Gonzalez de Dios, Ed. Intended status: Standards Track O. Gonzalez de Dios, Ed.
Expires: December 25, 2015 Telefonica Global CTO Expires August 14, 2016 Telefonica Global CTO
M. Hartley M. Hartley
Z. Ali Z. Ali
Cisco Cisco
C. Margaria C. Margaria
June 25, 2015 February 11, 2016
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-teas-rsvp-te-srlg-collect-02 draft-ietf-teas-rsvp-te-srlg-collect-03
Abstract Abstract
This document provides extensions for the Resource ReserVation This document provides extensions for the Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) to support automatic Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support
collection of Shared Risk Link Group (SRLG) information for the TE automatic collection of Shared Risk Link Group (SRLG) information for
link formed by a Label Switched Path (LSP). the TE 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2015. This Internet-Draft will expire on December 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability Example: Dual Homing . . . . . . . . . . . 3 1.1. Applicability Example: Dual Homing . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . 5
3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 5
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. SRLG ID Definition . . . . . . . . . . . . . . . . . . . 6
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 5 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 6
4.2. RRO SRLG sub-object . . . . . . . . . . . . . . . . . . . 6 4.2. RRO SRLG sub-object . . . . . . . . . . . . . . . . . . . 6
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 7 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 8
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 7 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Domain Boundaries . . . . . . . . . . . . . . . . . . . . 10
6. Manageability Considerations . . . . . . . . . . . . . . . . 9 5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 9 6. Manageability Considerations . . . . . . . . . . . . . . . . 10
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 9 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 11 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 11
8.3. Policy Control Failure Error subcodes . . . . . . . . . . 11 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. Policy Control Failure Error subcodes . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
It is important to understand which TE links in the network might be It is important to understand which Traffic Engineering (TE) links in
at risk from the same failures. In this sense, a set of links can the network might be at risk from the same failures. In this sense,
constitute a 'shared risk link group' (SRLG) if they share a resource a set of links can constitute a 'shared risk link group' (SRLG) if
whose failure can affect all links in the set [RFC4202]. they share a resource whose failure can affect all links in the set
[RFC4202].
On the other hand, as described in [RFC4206] and [RFC6107], H-LSP On the other hand, as described in [RFC4206] and [RFC6107], H-LSP
(Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying (Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying
one or more other LSPs. Both of the H-LSP and S-LSP can be formed as one or more other LSPs. Both of the H-LSP and S-LSP can be formed as
a TE link. In such cases, it is important to know the SRLG 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 mechanism to collect the SRLGs used by a This document provides a mechanism to collect the SRLGs used by a
LSP, which can then be advertized as properties of the TE-link formed LSP, which can then be advertized as properties of the TE-link formed
by that LSP. Note that specification of the the use of the collected by that LSP. Note that specification of the the use of the collected
skipping to change at page 4, line 17 skipping to change at page 4, line 21
on collected SRLG information. As the two connections (LSPs) enter on collected SRLG information. As the two connections (LSPs) enter
the provider network at different PE devices, the PE device that the provider network at different PE devices, the PE device that
receives the connection request for the second connection needs to receives the connection request for the second connection needs to
know the additional path computation constraints such that the path know the additional path computation constraints such that the path
of the second LSP is disjoint with respect to the already established of the second LSP is disjoint with respect to the already established
first connection. first 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. For example, CE1 in Figure 1 may have requested an LSP1 to homed. The RSVP extensions for collecting SRLG information defined
CE2 via PE1 that is routed via PE3 to CE2. CE1 can then subsequently in this document make it possible to retrieve SRLG information for an
request an LSP2 to CE2 via PE2 with the constraint that it needs to LSP and hence solve the dual-homing LSP diversity problem. For
be maximally SRLG disjoint with respect to LSP1. PE2, however, does example, CE1 in Figure 1 may have requested an LSP1 to CE2 via PE1
not have any SRLG information associated with LSP1, which is needed that is routed via PE3 to CE2. CE1 can then subsequently request an
as input for its constraint-based path computation function. If CE1 LSP2 to CE2 via PE2 with the constraint that it needs to be maximally
is capable of retrieving the SRLG information associated with LSP1 SRLG disjoint with respect to LSP1. PE2, however, does not have any
from PE1, it can pass this information to PE2 as part of the LSP2 SRLG information associated with LSP1, which is needed as input for
setup request (RSVP PATH message), and PE2 can now calculate a path its constraint-based path computation function. If CE1 is capable of
for LSP2 that is SRLG disjoint with respect to LSP1. The SRLG retrieving the SRLG information associated with LSP1 from PE1, it can
information associated with LSP1 can already be retrieved when LSP1 pass this discovered information to PE2 as part of the LSP2 setup
is setup or at any time before LSP2 is setup. request (RSVP PATH message) in an EXCLUDE_ROUTE Object (XRO) or
Explicit Exclusion Route Subobject (EXRS) as described in [RFC4874],
and PE2 can now calculate a path for LSP2 that is SRLG disjoint with
respect to LSP1. The SRLG information associated with LSP1 can be
retrieved when LSP1 is established or at any time before LSP2 is
setup.
The RSVP extensions for collecting SRLG information defined in this When CE1 sends the setup request for LSP2 to PE2, it can also request
document make it possible to retrieve SRLG information for an LSP and the collection of SRLG information for LSP2 and send that information
hence solve the dual-homing LSP diversity problem. When CE1 sends to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's
the setup request for LSP2 to PE2, it can also request the collection discovered SRLGs. This will ensure that the two paths for the two
of SRLG information for LSP2 and send that information to PE1. This LSPs remain mutually diverse, which is important when the provider
will ensure that the two paths for the two LSPs remain mutually network is capable of restoring connections that failed due to a
diverse, which is important, when the provider network is capable to network failure (fiber cut) in the provider network.
restore connections that failed due to a 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 devices to derive the provider network topology does not allow a CE device to derive the provider network topology
based on the collected SRLG information. based on the collected SRLG information.
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 RFC 2119 [RFC2119].
3. RSVP-TE Requirements 3. RSVP-TE Requirements
The SRLG-collection process takes place in three stages:
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 (RROs)
by all nodes during signaling;
o Changes to previously-signaled SRLG data are made by sending
updated Path and Resv messages as required.
3.1. SRLG Collection Indication 3.1. SRLG Collection Indication
The ingress node of the LSP SHOULD 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. SRLG information SHOULD signaling procedure of setting up an LSP. There is no need for
NOT be collected without an explicit request for it being made by the SRLG information to be collected without an explicit request for
ingress node. it being made by the ingress node.
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 the LSP to be established successfully even if it
traverses nodes that cannot supply SRLG information or have not
implemented the procedures specified in this document. It is
desirable for the ingress node to make the SRLG collection request
in a manner that best suits its own policy.
When SRLG collection has been requested by the ingress node, the
egress node reflects this by including the collection request in
the Resv message.
3.2. SRLG Collection 3.2. SRLG Collection
If requested, the SRLG information SHOULD be collected during the If requested, the SRLG information is collected during the setup
setup of an LSP. The endpoints of the LSP can use the collected SRLG of an LSP. SRLG information is for each hop is added to the Path
information, for example, for routing, sharing and TE link RRO during Path message processing. The same information is also
configuration purposes. added to the Resv RRO during Resv processing at each hop. The
endpoints of the LSP can make use of the collected SRLG
information, for example, for routing, sharing and TE link
configuration purposes.
3.3. SRLG Update 3.3. SRLG Update
When the SRLG information of an existing LSP for which SRLG
information was collected during signaling changes, the relevant
nodes of the LSP need to be capable of updating the SRLG
information of the LSP. This means that that the signaling
procedure needs to be capable of updating the new SRLG
information.
When the SRLG information of an existing LSP for which SRLG 3.4. SRLG ID definition
information was collected during signaling changes, the relevant
nodes of the LSP SHOULD be capable of updating the SRLG information The identifier of an SRLG (SRLG ID) is defined as a 32-bit
of the LSP. This means that that the signaling procedure SHOULD be quantity in [RFC4202]. This definition is used in this document.
capable of updating the new SRLG information.
4. Encodings 4. Encodings
4.1. SRLG Collection Flag 4.1. SRLG Collection Flag
In order to indicate nodes that SRLG collection is desired, this In order to indicate to nodes that SRLG collection is desired,
document defines a new flag in the Attribute Flags TLV (see RFC 5420 this document defines a new flag in the Attribute Flags TLV (see
[RFC5420]), which MAY be carried in an LSP_REQUIRED_ATTRIBUTES or RFC 5420 [RFC5420]), which MAY be carried in an
LSP_ATTRIBUTES Object: LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES Object:
o Bit Number (temporarily 12, an early allocation has been made by o Bit Number (specified in Section 8.1): SRLG Collection flag
IANA, see Section 8.1 for more details): 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 of 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 sub-object
This document defines a new RRO sub-object (ROUTE_RECORD sub-object) This document defines a new RRO sub-object (ROUTE_RECORD sub-object)
to record the SRLG information of the LSP. Its format is modeled on to record the SRLG information of the LSP. Its format is modeled on
the RRO sub-objects defined in RFC 3209 [RFC3209]. the RRO sub-objects defined in RFC 3209 [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 | Reserved | | Type | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 bytes) | | SRLG ID 1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~ ~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 bytes) | | SRLG ID n (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
The type of the sub-object. The value is temporarily 34. An early The type of the sub-object. The value is specified in Section 8.2.
allocation has been made by IANA (see Section 8.2 for more details).
Length Length
The Length field contains the total length of the sub-object in The Length field contains the total length of the sub-object in
bytes, 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)
If not set, the SRLGs contained in this sub-object apply to the
downstream direction. If set, they apply to the upstream direction.
Reserved Reserved
This 2 byte 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 SRLG ID
This 4 byte field contains one SRLG ID. There is one SRLG ID field This 4 octet field contains one SRLG ID. There is one SRLG ID field
per SRLG collected. There MAY be multiple SRLG ID fields in an SRLG per SRLG collected. There MAY be multiple SRLG ID fields in an SRLG
sub-object sub-object.
A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without
also pushing either a IPv4 sub-object, a IPv6 sub-object, a
Unnumbered Interface ID sub-object or a Path Key sub-object.
As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is
managed as a stack. The SRLG sub-object SHOULD be pushed by the node managed as a stack. The SRLG sub-object SHOULD be pushed by the node
before the node IP address or link identifier. The SRLG-sub-object before the node IP address or link identifier. The SRLG-sub-object
SHOULD be pushed after the Attribute subobject, if present, and after SHOULD be pushed after the Attribute sub-object, if present, and
the LABEL subobject, if requested. after the LABEL sub-object, if requested. It MUST be pushed within
the hop to which it applies.
RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub- RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub-
object) in the RRO so as to facilitate confidentiality in the object) in the RRO so as to facilitate confidentiality in the
signaling of inter-domain TE LSPs, and allows the path segment that signaling of inter-domain TE LSPs, and allows the path segment that
needs to be hidden (that is, a Confidential Path Segment (CPS)) to be needs to be hidden (that is, a Confidential Path Segment (CPS)) to be
replaced in the RRO with a PKS. If the CPS contains SRLG Sub- replaced in the RRO with a PKS. If the CPS contains SRLG Sub-
objects, these MAY be retained in the RRO by adding them again after objects, these MAY be retained in the RRO by adding them again after
the PKS Sub-object in the RRO. The CPS is defined in RFC 5520 the PKS Sub-object in the RRO. The CPS is defined in RFC 5520
[RFC5520] [RFC5520].
A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without
also pushing either a IPv4 sub-object, a IPv6 sub-object, a
Unnumbered Interface ID sub-object or a Path Key sub-object.
The rules of 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_ATTRIBUTE 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
SRLG information of the LSP is to be collected during the signaling
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 RFC 3209 [RFC3209], an ingress node initiates the recording of
the route information of an LSP by adding a RRO to a Path message. If the route information of an LSP by adding a RRO to a Path message. If
an ingress node also desires SRLG recording, it MUST set the SRLG an 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
either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is
mandatory, or in an LSP_ATTRIBUTES Object when the collection is mandatory, or in an LSP_ATTRIBUTES Object when the collection is
desired, but not mandatory. desired, but not mandatory.
When a node receives a Path message which carries an When a node receives a Path message which carries an
LSP_REQUIRED_ATTRIBUTES Object and 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" (value 31, an early o Error subcode "SRLG Recording Rejected" (see Section 8.3 for
allocation of the value has been done by IANA, see Section 8.3 for value)
more details)
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 which carries an LSP_ATTRIBUTES
Object and 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 SHOULD NOT be rejected due to SRLG recording restriction Path message SHOULD NOT be rejected due to the SRLG recording
and the Path message SHOULD be forwarded without any SRLG sub- restriction and the Path message SHOULD be forwarded without any SRLG
object(s) in the RRO of the corresponding outgoing Path message. sub-object(s) added to the RRO of the corresponding outgoing Path
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 sub-objects to the RRO if
necesary. 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. downstream direction. The processing node MUST retain a record of the
SRLG recording request for reference during Resv processing 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. If
the SRLG collection request was contained in an 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 specified by RFC 3209 [RFC3209] and drop the RRO from the Path
message entirely. If the SRLG collection request was contained in an message entirely. If the SRLG collection request was contained in an
LSP_ATTRIBUTES Object, the processing node MAY omit some or all of LSP_ATTRIBUTES Object, the processing node MAY omit some or all of
the requested SRLGs from the RRO; otherwise it MUST behave as the requested SRLGs from the RRO; otherwise it MUST behave as
specified by RFC 3209 [RFC3209] and drop the RRO from the Path specified by [RFC3209] and drop the RRO from the Path message
message entirely. entirely.
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 RFC 3209 [RFC3209], when issuing a Resv message for a Path
message which contains an RRO, an egress node initiates the RRO message which contains an RRO, an egress node initiates the RRO
process by adding an RRO to the outgoing Resv message. The process by adding an RRO to the outgoing Resv message. The
processing for RROs contained in Resv messages then mirrors that of processing for RROs 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 is specified, then when local policy allows recording SRLG Collection was specified in the corresponding Path message, then when
information, the node SHOULD add SRLG information, to the RRO of the local policy allows recording SRLG information, the node SHOULD add
corresponding outgoing Resv message, as specified below. When the SRLG information to the RRO of the corresponding outgoing Resv
Resv message arrives at the ingress node, the ingress node can message as specified below. When the Resv message arrives at the
extract the SRLG information from the RRO in the same way as the ingress node, the ingress node can extract the SRLG information from
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 in the downstream.
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 sub-objects 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 sub-objects in the RRO for both the upstream data
link and the downstream data link from the local node. In this link and the downstream data link from the local node. In this
case, the node MUST include the information in the same order for case, the node MUST include the information in the same order for
both Path messages and Resv messages. That is, the SRLG sub- both Path messages and Resv messages. That is, the SRLG sub-
object for the upstream link is added to the RRO before the SRLG object for the upstream link is added to the RRO before the SRLG
sub-object for the downstream link. sub-object for the downstream link.
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-
objects. A single SRLG sub-object MUST NOT contain a mixture of
upstream and downstream SRLGs. When adding a SRLG sub-object to an
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
be added to both the upstream and downstream SRLG sub-objects.
A node SHOULD NOT add SRLG information without an explicit request
for it being made by the ingress node in the Path message.
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 the endpoints can for instance
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 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 LSPs using that When the SRLG information of a link is changed, the endpoints of LSPs
link need to be aware of the changes. The procedures defined in using that link need to be made aware of the changes. When a change
Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG to the set of SRLGs associated with a link occurs, the procedures
information if the SRLG change is to be communicated to other nodes defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to
according to the local node's policy. If local policy is that the refresh the SRLG information for each affected LSP if the SRLG change
SRLG change SHOULD be suppressed or would result in no change to the is to be communicated to other nodes according to the local node's
previously signaled SRLG-list, the node SHOULD NOT send an update. policy. If local policy is that the SRLG change SHOULD be suppressed
or would result in no change to the previously signaled SRLG-list,
the node SHOULD NOT send an update.
5.3. Compatibility 5.3 Domain Boundaries
If mandated by local policy, a 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 map them to other SRLG values.
However, this SHOULD NOT be done unless explicitly mandated by local
policy.
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 RFC 5420
[RFC5420]. It is expected to pass the TLV on unaltered if it appears [RFC5420]. It is expected to pass the TLV on unaltered if it appears
in a LSP_ATTRIBUTES object, or reject the Path message with the in a LSP_ATTRIBUTES object, or 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 sub-object is expected to
behave as specified in RFC 3209 [RFC3209]: unrecognized subobjects behave as specified in RFC 3209 [RFC3209]: unrecognized sub-objects
are to be ignored and passed on unchanged. are to be 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 inter-domain or inter-layer network, the
following SRLG processing policy SHOULD be capable of being following SRLG processing policy SHOULD be capable of being
configured: configured:
o Whether the SRLG IDs of the domain or specific layer network can o Whether the node is allowed to participate in SRLG collection. o
Whether the node should notify changes to collected SRLG
information to endpoint nodes as described in section 5.2. 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. removed entirely as described in section 5.3.
A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy. A node using RFC 5553 [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 by
different management entities in each layer/domain. In such different management entities in each layer/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 procedure is
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
skipping to change at page 10, line 38 skipping to change at page 12, line 8
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 RFC 5420 [RFC5420], in the "Attribute Flags" section 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 in http://www.iana.org/assignments/rsvp-te-
parameters". IANA has made an early allocation in the "Attribute parameters".
Flags" section of the mentioned registry that expires on 2015-09-11.
This document introduces a new Attribute Bit Flag: This document introduces a new Attribute Bit Flag:
Bit No Name Attribute Attribute RRO Reference Bit No Name Attribute Attribute RRO Reference
Flags Path Flags Resv Flags Path Flags Resv
----------- ---------- ---------- ----------- --- --------- -------------- ---------- ---------- ----------- --- ---------
12 (tempo- SRLG Yes Yes Yes This I-D TBD; suggested SRLG Yes No Yes This I-D
rary expires collection value: 12 Flag
2015-09-11) Flag
8.2. ROUTE_RECORD Object 8.2. ROUTE_RECORD Object
IANA manages the "RSVP PARAMETERS" registry located at IANA manages the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters. IANA has made an http://www.iana.org/assignments/rsvp-parameters. This document
early allocation in the Sub-object type 21 ROUTE_RECORD - Type 1 introduces a new RRO sub-object:
Route Record registry. The early allocation expires on 2015-09-11.
This document introduces a new RRO sub-object:
Value Description Reference Value Description Reference
--------------------- ------------------- --------- --------------------- ------------------- ---------
34 (temporary, SRLG sub-object This I-D TBD; suggested SRLG sub-object This I-D
expires 2015-09-11) 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 "RSVP PARAMETERS" registry
located at http://www.iana.org/assignments/rsvp-parameters. IANA has located at http://www.iana.org/assignments/rsvp-parameters.
made an early allocation in the "Sub-Codes - 2 Policy Control
Failure" subsection of the the "Error Codes and Globally-Defined
Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry. The
early allocation expires on 2015-09-11.
This document introduces a new Policy Control Failure Error sub-code: This document introduces a new Policy Control Failure Error sub-code:
Value Description Reference Value Description Reference
--------------------- ----------------------- --------- --------------------- ----------------------- ---------
21 (temporary, SRLG Recording Rejected This I-D TBD; suggested SRLG Recording Rejected This I-D
expires 2015-09-11) value: 21
9. Contributors 9. Contributors
Dan Li Dan Li
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 P.R.China
Email: danli@huawei.com Email: danli@huawei.com
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Igor Bryskin, Ramon Casellas, Lou The authors would like to thank Igor Bryskin, Ramon Casellas, Lou
Berger, Alan Davey, Dhruv Dhody and Dieter Beller for their useful Berger, Alan Davey, Elwyn Davies, Dhruv Dhody and Dieter Beller for
comments and improvements to this document. their useful comments and improvements to this document.
11. References 11. References
11.1. Normative References 11.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, March 1997.
[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, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
skipping to change at page 12, line 17 skipping to change at page 13, line 26
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., 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, February 2009.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path Computation Topology Confidentiality in Inter-Domain Path Computation
Using a Path-Key-Based Mechanism", RFC 5520, April 2009. Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource [RFC5553] Farrel, A., 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, May 2009.
11.2. Informative References 11.2. Informative References
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[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, October 2005.
[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, October 2005.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically
Signaled Hierarchical Label Switched Paths", RFC 6107, Signaled Hierarchical Label Switched Paths", RFC 6107,
February 2011. February 2011.
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 P.R.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
 End of changes. 61 change blocks. 
152 lines changed or deleted 217 lines changed or added

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