draft-ietf-ccamp-rsvp-te-srlg-collect-06.txt   draft-ietf-ccamp-rsvp-te-srlg-collect-07.txt 
Network Working Group F. Zhang, Ed. Network 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: February 1, 2015 Telefonica Global CTO Expires: February 27, 2015 Telefonica Global CTO
D. Li D. Li
Huawei Huawei
C. Margaria C. Margaria
M. Hartley M. Hartley
Z. Ali Z. Ali
Cisco Cisco
July 31, 2014 August 26, 2014
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-ccamp-rsvp-te-srlg-collect-06 draft-ietf-ccamp-rsvp-te-srlg-collect-07
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) to support automatic
collection of Shared Risk Link Group (SRLG) Information for the TE collection of Shared Risk Link Group (SRLG) Information for the TE
link formed by a LSP. link formed by a LSP.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 February 1, 2015. This Internet-Draft will expire on February 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 3
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 3 4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . 3
4.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . 4 4.2. SRLG sub-object . . . . . . . . . . . . . . . . . . . . . 4
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 5 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 5
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 5
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7
6. Manageability Considerations . . . . . . . . . . . . . . . . 7 6. Manageability Considerations . . . . . . . . . . . . . . . . 7
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 7 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 7
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 7 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 8 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 8
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 8 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 9
8.3. Policy Control Failure Error subcodes . . . . . . . . . . 9 8.3. Policy Control Failure Error subcodes . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
It is important to understand which TE links in the network might be 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 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 constitute a 'shared risk link group' (SRLG) if they share a resource
whose failure may affect all links in the set [RFC4202]. whose failure may affect all links in the set [RFC4202].
skipping to change at page 3, line 50 skipping to change at page 3, line 50
capable of updating the new SRLG information. 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 nodes that SRLG collection is desired, this
document defines a new flag in the Attribute Flags TLV, which is document defines a new flag in the Attribute Flags TLV, which is
carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTE Object: carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTE Object:
o Bit Number (to be assigned by IANA, recommended bit 12): SRLG o Bit Number (to be assigned by IANA, early allocation requested,
Collection flag 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 of the processing of the Attribute Flags TLV are not
changed. changed.
4.2. SRLG sub-object 4.2. SRLG sub-object
skipping to change at page 4, line 33 skipping to change at page 4, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 bytes) | | SRLG ID 1 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~ ~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 bytes) | | SRLG ID n (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
The type of the sub-object, to be assigned by IANA, which is The type of the sub-object. The value is to be assigned by IANA. An
recommended 34. early allocation is requested (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 bytes, including the Type and Length fields. The Length depends on
the number of SRLG IDs. the number of SRLG IDs.
Reserved Reserved
This 2 byte field is reserved. It SHOULD be set to zero on This 2 byte field is reserved. It SHOULD be set to zero on
skipping to change at page 5, line 11 skipping to change at page 5, line 11
This 4 byte field contains one SRLG ID. There is one SRLG ID field This 4 byte field contains one SRLG ID. There is one SRLG ID field
per SRLG collected. per SRLG collected.
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 subobject, if present, and after
the LABEL subobject, if requested. the LABEL subobject, if requested.
A node MUST NOT push a SRLG subobject in the RECORD_ROUTE without RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub-
also pushing a IPv4, IPv6 or Unnumbered Interface ID sub-object. object) in the RRO so as to facilitate confidentiality in the
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
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
the PKS Sub-object in the RRO.
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 of 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
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. the route information of an LSP by adding a RRO to a Path message.
skipping to change at page 5, line 34 skipping to change at page 5, line 43
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 and 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
Error Code 2 (policy) and Error subcode "SRLG Recording Rejected" Error Code 2 (policy) and Error subcode "SRLG Recording Rejected"
(value to be assigned by IANA, suggest value 108) to reject the Path (value to be assigned by IANA, early allocation of the value
requested, see Section 8.3 for more details) to reject the Path
message. 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 and 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 SRLG recording restriction
and the Path message SHOULD be forwarded without any SRLG sub- and the Path message SHOULD be forwarded without any SRLG sub-
object(s) in the RRO of the corresponding outgoing Path message. object(s) in 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
skipping to change at page 6, line 18 skipping to change at page 6, line 27
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, if local policy determines that the SRLG Collection is specified, if local policy determines that the SRLG
information is not to be provided to the endpoints, if 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 recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a
ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording
Rejected" (value to be assigned by IANA, suggest value 108) MUST be Rejected" (value to be assigned by IANA, early allocation of the
sent. If the request was in a LSP_ATTRIBUTES object, then a ResvErr value requested, see Section 8.3 for more details) MUST be sent. If
SHOULD NOT be generated, but SRLG information MUST NOT be added in the request was in a LSP_ATTRIBUTES object, then a ResvErr SHOULD NOT
the RRO. When local policy allows recording SRLG information, the be generated, but SRLG information MUST NOT be added in the RRO.
node SHOULD add SRLG information, as defined below, to the RRO of the 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 corresponding outgoing Resv message. When the Resv message arrives
at the ingress node, the ingress node can get the SRLG information at the ingress node, the ingress node can get the SRLG information
from the RRO in the same way as the egress node. from 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.
skipping to change at page 7, line 42 skipping to change at page 7, line 48
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 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.
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 may be configured by In a multi-layer multi-domain scenario, SRLG ids may 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 must be unique. Note that current procedure is Thus, SRLG IDs must 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
skipping to change at page 8, line 25 skipping to change at page 8, line 37
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. It is recommended that domain/layer boundary or domain boundary. It is recommended that domain/layer boundary
policies take the implications of releasing SRLG information into policies take the implications of releasing SRLG information into
consideration and behave accordingly during LSP signaling. consideration and behave accordingly during LSP signaling.
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 attributes bit IANA has created a registry and manages the space of the Attribute
flags of Attribute Flags TLV, as described in section 11.3 of bit flags of the Attribute Flags TLV, as described in section 11.3 of
[RFC5420], in the "Attributes TLV Space" 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 https://www.iana.org/assignments/rsvp-te- registry located in https://www.iana.org/assignments/rsvp-te-
parameters/rsvp-te-parameters.xhtml. It is requested that IANA makes parameters/rsvp-te-parameters.xhtml. It is requested that IANA makes
assignments from the Attribute Bit Flags. an early allocation in the "Attribute Flags" section of the mentioned
registry.
This document introduces a new Attribute Bit Flag: This document introduces a new Attribute Bit Flag:
o Bit number: TBD (early allocation requested) Bit No Name Attribute Attribute RRO Reference
Flags Path Flags Resv
o Defining RFC: this I-D ----------- ---------- ---------- ----------- --- ---------
TBD(early SRLG Yes Yes Yes This I-D
o Name of bit: SRLG Collection Flag allocation collection
requested) Flag
o The meaning of the SRLG Collection Flag is defined in this I-D.
8.2. ROUTE_RECORD Object 8.2. ROUTE_RECORD Object
IANA has made the following assignments in the "Class Names, Class IANA manages the "RSVP PARAMETERS" registry located at
Numbers, and Class Types" section of the "RSVP PARAMETERS" registry http://www.iana.org/assignments/rsvp-parameters. We request IANA to
located at http://www.iana.org/assignments/rsvp-parameters. We make an early allocation in the Sub-object type 21 ROUTE_RECORD -
request that IANA make assignments from the ROUTE_RECORD RFC 3209 Type 1 Route Record registry
[RFC3209] portions of this registry.
This document introduces a new RRO sub-object: This document introduces a new RRO sub-object:
Type Name Reference Value Description Reference
--------- ---------------------- --------- --------------------- ------------------- ---------
TBD (early SRLG sub-object This I-D TBD (early allocation SRLG sub-object This I-D
allocation requested, suggested
requested) value 34)
8.3. Policy Control Failure Error subcodes 8.3. Policy Control Failure Error subcodes
IANA has made the following assignments in the "Error Codes and IANA manages the assignments in the "Error Codes and Globally-Defined
Globally-Defined Error Value Sub-Codes" section of the "RSVP Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry
PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- located at http://www.iana.org/assignments/rsvp-parameters. We
parameters. We request that IANA make assignments from the Policy request IANA to make an early allocation in the "Sub-Codes - 2 Policy
Control Failure Sub-Codes registry. Control Failure" subsection of the the "Error Codes and Globally-
Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS"
registry.
This document introduces a new Policy Control Failure Error sub-code: This document introduces a new Policy Control Failure Error sub-code:
o Error sub-code: TBD (early allocation requested) Value Description Reference
--------------------- ----------------------- ---------
o Defining RFC: this I-D TBD (early allocation SRLG Recording Rejected This I-D
requested)
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 9. Acknowledgements
The authors would like to thank Igor Bryskin, Ramon Casellas, Lou The authors would like to thank Igor Bryskin, Ramon Casellas, Lou
Berger and Alan Davey for their useful comments and improvements to Berger, Alan Davey and Dhruv Dhody for their useful comments and
the document. improvements to the document.
10. References 10. References
10.1. Normative References 10.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
skipping to change at page 10, line 10 skipping to change at page 10, line 25
[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.
[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.
[RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource
Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009.
10.2. Informative References 10.2. Informative References
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005. (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.
 End of changes. 22 change blocks. 
56 lines changed or deleted 70 lines changed or added

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