Network Working Group F. Zhang, Ed.
Internet-Draft Huawei
Intended status: Standards Track O. Gonzalez de Dios, Ed.
Expires: January 5, 2015 Telefonica Global CTO
D. Li
Huawei
C. Margaria
M. Hartley
Z. Ali
Cisco
July 4, 2014
RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-ccamp-rsvp-te-srlg-collect-05
Abstract
This document provides extensions for the Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) to support automatic
collection of Shared Risk Link Group (SRLG) Information for the TE
link formed by a LSP.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Zhang, et al. Expires January 5, 2015 [Page 1]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 3
3.1. SRLG Collection Indication . . . . . . . . . . . . . . . 3
3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 3
3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 3
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 3
4.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . 4
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 5
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7
6. Manageability Considerations . . . . . . . . . . . . . . . . 7
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 7
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 8
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 8
8.3. Policy Control Failure Error subcodes . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
It is important to understand which TE links in the network might be
at risk from the same failures. In this sense, a set of links may
constitute a 'shared risk link group' (SRLG) if they share a resource
whose failure may affect all links in the set [RFC4202].
On the other hand, as described in [RFC4206] and [RFC6107], H-LSP
(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
Zhang, et al. Expires January 5, 2015 [Page 2]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
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.
This document provides an automatic mechanism to collect the SRLG for
the TE link formed by a LSP. Note that how to use the collected SRLG
information is out of scope of this document
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. RSVP-TE Requirements
3.1. SRLG Collection Indication
The ingress nodes of the LSP must be capable of indicating whether
the SRLG information of the LSP should be collected during the
signaling procedure of setting up an LSP. SRLG information SHOULD
NOT be collected without an explicit request for it being made by the
ingress node.
3.2. SRLG Collection
If requested, the SRLG information should be collected during the
setup of an LSP. The endpoints of the LSP may use the collected SRLG
information and use it for routing, sharing and TE link configuration
purposes.
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 must be capable of updating the SRLG information of
the LSP. This means that that the signaling procedure must be
capable of updating the new SRLG information.
4. Encodings
4.1. SRLG Collection Flag
In order to indicate nodes that SRLG collection is desired, this
document defines a new flag in the Attribute Flags TLV, which is
carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTE Object:
o Bit Number (to be assigned by IANA, recommended bit 12): SRLG
Collection flag
Zhang, et al. Expires January 5, 2015 [Page 3]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
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
should be reported to the ingress and egress node along the setup of
the LSP.
The rules of the processing of the Attribute Flags TLV are not
changed.
4.2. SRLG 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
the RRO sub-objects defined in RFC 3209 [RFC3209].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
The type of the sub-object, to be assigned by IANA, which is
recommended 34.
Length
The Length field contains the total length of the sub-object in
bytes, including the Type and Length fields. The Length depends on
the number of SRLG IDs.
Reserved
This 2 byte field is reserved. It SHOULD be set to zero on
transmission and MUST be ignored on receipt.
SRLG ID
This 4 byte field contains one SRLG ID. There is one SRLG ID field
per SRLG collected.
Zhang, et al. Expires January 5, 2015 [Page 4]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
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
before the node IP address or link identifier. The SRLG-sub-object
SHOULD be pushed after the Attribute subobject, if present, and after
the LABEL subobject, if requested.
A node MUST NOT push a SRLG subobject in the RECORD_ROUTE without
also pushing a IPv4, IPv6 or Unnumbered Interface ID sub-object.
The rules of the processing of the LSP_REQUIRED_ATTRIBUTES,
LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed.
5. Signaling Procedures
5.1. SRLG Collection
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 an ingress node also desires SRLG recording, it MUST set the SRLG
Collection Flag in the Attribute Flags TLV which MAY be carried
either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is
mandatory, or in an LSP_ATTRIBUTES Object when the collection is
desired, but not mandatory
When a node receives a Path message which carries an
LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag set, if
local policy determines that the SRLG information is not to be
provided to the endpoints, it MUST return a PathErr message with
Error Code 2 (policy) and Error subcode "SRLG Recording Rejected"
(value to be assigned by IANA, suggest value 108) to reject the Path
message.
When a node receives a Path message which carries an LSP_ATTRIBUTES
Object and the SRLG Collection Flag set, if local policy determines
that the SRLG information is not to be provided to the endpoints, the
Path message SHOULD NOT be rejected due to SRLG recording restriction
and the Path message SHOULD be forwarded without any SRLG sub-
object(s) in the RRO of the corresponding outgoing Path message.
If local policy permits the recording of the SRLG information, the
processing node SHOULD add local SRLG information, as defined below,
to the RRO of the corresponding outgoing Path message. It then
forwards the Path message to the next node in the downstream
direction.
Following the steps described above, the intermediate nodes of the
LSP can collect the SRLG information in the RRO during the processing
Zhang, et al. Expires January 5, 2015 [Page 5]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
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.
Per RFC 3209 [RFC3209], when issuing a Resv message for a Path
message which contains an RRO, an egress node initiates the RRO
process by adding an RRO to the outgoing Resv message. The
processing for RROs contained in Resv messages then mirrors that of
the Path messages.
When a node receives a Resv message for an LSP for which SRLG
Collection is specified, if local policy determines that the SRLG
information is not to be provided to the endpoints, if the SRLG-
recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a
ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording
Rejected" (value to be assigned by IANA, suggest value 108) MUST be
sent. If the request was in a LSP_ATTRIBUTES object, then a ResvErr
SHOULD NOT be generated, but SRLG information MUST NOT be added in
the RRO. When local policy allows recording SRLG information, the
node SHOULD add SRLG information, as defined below, to the RRO of the
corresponding outgoing Resv message. When the Resv message arrives
at the ingress node, the ingress node can get the SRLG information
from the RRO in the same way as the egress node.
Note that a link's SRLG information for the upstream direction cannot
be assumed to be the same as that in the downstream.
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
only.
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
link and the downstream data link from the local node. In this
case, the node MUST include the information in the same order for
both Path messages and Resv messages. That is, the SRLG sub-
object for the upstream link is added to the RRO before the SRLG
sub-object for the downstream link.
Based on the above procedure, the endpoints can get the SRLG
information automatically. Then the endpoints can for instance
advertise it as a TE link to the routing instance based on the
procedure described in [RFC6107] and configure the SRLG information
of the FA automatically.
Zhang, et al. Expires January 5, 2015 [Page 6]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
5.2. SRLG Update
When the SRLG information of a link is changed, the LSPs using that
link should be aware of the changes. The procedures defined in
Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to refresh the SRLG
information if the SRLG change is to be communicated to other nodes
according to the local node's 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
A node that does not recognize the SRLG Collection Flag in the
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
in a LSP_ATTRIBUTES object, or reject the Path message with the
appropriate Error Code and Value if it appears in a
LSP_REQUIRED_ATTRIBUTES object.
A node that does not recognize the SRLG RRO sub-object is expected to
behave as specified in RFC 3209 [RFC3209]: unrecognized subobjects
are to be ignored and passed on unchanged.
6. Manageability Considerations
6.1. Policy Configuration
In a border node of inter-domain or inter-layer network, the
following SRLG processing policy should be capable of being
configured:
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
whether they should be summarized, mapped to values that are
comprehensible to nodes outside the domain or layer network, or
removed entirely.
6.2. Coherent SRLG IDs
In a multi-layer multi-domain scenario, SRLG ids may be configured by
different management entities in each layer/domain. In such
scenarios, maintaining a coherent set of SRLG IDs is a key
requirement in order to be able to use the SRLG information properly.
Thus, SRLG IDs must be unique. Note that current procedure is
targeted towards a scenario where the different layers and domains
belong to the same operator, or to several coordinated administrative
groups. Ensuring the aforementioned coherence of SRLG IDs is beyond
the scope of this document.
Zhang, et al. Expires January 5, 2015 [Page 7]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
Further scenarios, where coherence in the SRLG IDs cannot be
guaranteed are out of the scope of the present document and are left
for further study.
7. Security Considerations
This document does not introduce any additional security issues above
those identified in [RFC5920][RFC3209][RFC3473]
8. IANA Considerations
8.1. RSVP Attribute Bit Flags
IANA has created a registry and manages the space of attributes bit
flags of Attribute Flags TLV, as described in section 11.3 of
[RFC5420], in the "Attributes TLV Space" section of the "Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters"
registry located in https://www.iana.org/assignments/rsvp-te-
parameters/rsvp-te-parameters.xhtml. It is requested that IANA makes
assignments from the Attribute Bit Flags.
This document introduces a new Attribute Bit Flag:
o Bit number: TBD (10)
o Defining RFC: this I-D
o Name of bit: SRLG Collection Flag
o The meaning of the SRLG Collection Flag is defined in this I-D.
8.2. ROUTE_RECORD Object
IANA has made the following assignments in the "Class Names, Class
Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
located at http://www.iana.org/assignments/rsvp-parameters. We
request that IANA make assignments from the ROUTE_RECORD RFC 3209
[RFC3209] portions of this registry.
This document introduces a new RRO sub-object:
Type Name Reference
--------- ---------------------- ---------
TBD (34) SRLG sub-object This I-D
Zhang, et al. Expires January 5, 2015 [Page 8]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
8.3. Policy Control Failure Error subcodes
IANA has made the following assignments in the "Error Codes and
Globally-Defined Error Value Sub-Codes" section of the "RSVP
PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-
parameters. We request that IANA make assignments from the Policy
Control Failure Sub-Codes registry.
This document introduces a new Policy Control Failure Error sub-code:
o Error sub-code: TBD (108)
o Defining RFC: this I-D
o Name of error sub-code: SRLG Recording Rejected
o The meaning of the SRLG Recording Rejected error sub-code is
defined in this I-D
9. Acknowledgements
The authors would like to thank Igor Bryskin, Ramon Casellas, Lou
Berger and Alan Davey for their useful comments and improvements to
the document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
Zhang, et al. Expires January 5, 2015 [Page 9]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
10.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)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically
Signaled Hierarchical Label Switched Paths", RFC 6107,
February 2011.
Authors' Addresses
Fatai Zhang (editor)
Huawei
F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129
P.R.China
Email: zhangfatai@huawei.com
Oscar Gonzalez de Dios (editor)
Telefonica Global CTO
Don Ramon de la Cruz
Madrid 28006
Spain
Phone: +34 913328832
Email: oscar.gonzalezdedios@telefonica.com
Dan Li
Huawei
F3-5-B RD Center
Bantian, Longgang District, Shenzhen 518129
P.R.China
Email: danli@huawei.com
Zhang, et al. Expires January 5, 2015 [Page 10]
Internet-Draft RSVP-TE Ext for Collecting SRLG July 2014
Cyril Margaria
SabenerStr. 44
Munich 81547
Germany
Phone: +49 89 5159 16934
Email: cyril.margaria@gmail.com
Matt Hartley
Cisco
Email: mhartley@cisco.com
Zafar Ali
Cisco
Email: zali@cisco.com
Zhang, et al. Expires January 5, 2015 [Page 11]