TEAS Working Group Zafar Ali Internet Draft George Swallow Intended status: Standard Track Clarence Filsfils Expires: June 10, 2015 Matt Hartley Cisco Systems Kenji Kumaki KDDI Corporation Ruediger Kunze Deutsche Telekom AG December 11, 2014 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path draft-ietf-teas-te-metric-recording-00.txt 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 June 10, 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 (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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Ali, Swallow, Filsfils, et al Expires June 2015 [Page 1] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt Abstract There are many scenarios in which Traffic Engineering (TE) metrics such as cost, latency and latency variation associated with a Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched Path (LSP) are not available to the ingress and egress nodes. This draft provides extensions for the Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) for the support of the discovery of cost, latency and latency variation of an LSP. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction................................................3 2. RSVP-TE Requirement.........................................4 2.1. Cost, Latency and Latency Variation Collection Indication.4 2.2. Cost, Latency and Latency Variation Collection............4 2.3. Cost, Latency and Latency Variation Update................4 3. RSVP-TE signaling extensions................................5 3.1. Cost, Latency, and Latency Variation Collection Flags.....5 3.4. Cost subobject............................................5 3.5. Latency subobject.........................................6 3.6. Latency Variation subobject...............................7 3.7. Signaling Procedures......................................8 4. Security Considerations....................................12 5. IANA Considerations........................................12 5.1. RSVP Attribute Bit Flags.................................12 Ali, Swallow, Filsfils Expires June 2015 [Page 2] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 5.2. New RSVP error sub-code..................................13 6. Acknowledgments............................................14 7. References.................................................14 7.1. Normative References.....................................14 7.2. Informative References...................................14 1. Introduction In certain networks, such as financial information networks, network performance information (e.g. latency, latency variation) is becoming as critical to data path selection as other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If cost, latency or latency variation associated with a Forwarding Adjacency (FA) or a Routing Adjacency (RA) LSP is not available to the ingress or egress node, it cannot be advertised as an attribute of the FA or RA. There are scenarios in packet and optical networks where the route information of an LSP may not be provided to the ingress node for confidentiality reasons and/or the ingress node may not run the same routing instance as the intermediate nodes traversed by the path. In such scenarios, the ingress node cannot determine the cost, latency and latency variation properties of the LSP's route. One possible way to address this issue is to configure cost, latency and latency variation values manually. However, in the event of an LSP being rerouted (e.g. due to re-optimization), such configuration information may become invalid. Consequently, in cases where that an LSP is advertised as a TE-Link, the ingress and/or egress nodes cannot provide the correct latency, latency variation and cost attribute associated with the TE-Link automatically. In summary, there is a requirement for the ingress and egress nodes to learn the cost, latency and latency variation attributes of an FA or RA LSP. This draft provides extensions to the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) for the support of the automatic discovery of these attributes. 1.1. Use Cases 1.1.1. GMPLS In Generalized Multi-Protocol Label Switching (GMPLS) networks signaling bidirectional LSPs, the egress node cannot determine the cost, latency and latency variation properties of the LSP path. A multi-domain or multi-layer network is an example of such networks. A GMPLS User-Network Interface (UNI) [RFC4208] is also an example of such networks. Ali, Swallow, Filsfils Expires June 2015 [Page 3] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 1.1.2. Inter-area tunnels with loose-hops When a LSP is established over multiple IGP-areas using loose hops in the ERO, the ingress node only has knowledge of the first IGP-area traversed by the LSP. In this case, it cannot determine the cost, latency and latency variation properties of the LSP path. 2. RSVP-TE Requirements This section outlines RSVP-TE requirements for the support of the automatic discovery of cost, latency and latency variation attributes of an LSP. These requirements are very similar to the requirement of discovering the Shared Risk Link Groups (SRLGs) associated with the route taken by an LSP [DRAFT-SRLG- RECORDING]. 2.1. Cost, Latency and Latency Variation Collection Indication The ingress node of the LSP must be capable of indicating whether the cost, latency and latency variation attributes of the LSP should be collected during the signaling procedure of setting up the LSP. No cost, latency or latency variation information is collected without an explicit request being made by the ingress node. 2.2. Cost, Latency and Latency Variation Collection If requested, cost, latency and latency variation is collected during the setup of an LSP. The endpoints of the LSP may use the collected information for routing, flooding and TE link configuration and other purposes. 2.3. Cost, Latency and Latency Variation Update When the cost, latency or latency variation property of a TE link along the route of a LSP for which that property was collected changes (e.g., if the administrator changes the cost of a TE link traversed by the LSP), the node where the change occurred needs to be capable of updating the cost, latency and latency variation information of the path and signaling this to the end-points. Similarly, if a path segment of the LSP is rerouted, the endpoints of the re-routed segment need to be capable of updating the cost, latency and latency variation information of the path. Any node which adds cost, latency or latency variation information to an LSP during initial setup, needs to signal changes to these values to both endpoints. 2.4. Cost Definition Although the terms latency and latency variation are well understood, "cost" may be ambiguous; in particular, in the Ali, Swallow, Filsfils Expires June 2015 [Page 4] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt context of a LSP that traverses nodes and links operated by different entities, there may be no common definition of cost. However, there are situations in which the entire LSP may be within a single AS (e.g. inter-area LSPs) in which cost discovery is useful. The precise meaning and interpretation of numerical costs is a matter for the network operator. For the purposes of this document, two constraints are assumed: . A higher cost represents an inferior path . Simple addition of costs for different sections of a path must make sense. 3. RSVP-TE signaling extensions 3.1. Cost, Latency and Latency Variation Collection Flags In order to indicate nodes that cost, latency and/ or latency variation collection is desired, the following three Attribute flags are defined in the Attribute Flags TLV: - Cost Collection flag (to be assigned by IANA) - Latency Collection flag (to be assigned by IANA) - Latency Variation Collection flag (to be assigned by IANA) These flags are set and carried in either the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Objects in a Path message. 3.2. Cost Subobject The Cost subobject is a new RRO (ROUTE_RECORD OBJECT) sub-object used to record the cost information of the LSP. Its format is similar to the other RRO subobjects defined in [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 (must be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBA1 - Cost subobject (to be assigned by IANA). Ali, Swallow, Filsfils Expires June 2015 [Page 5] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt Length: The Length value is set to 8 or 12 depending on the presence of Upstream Cost information. It MUST NOT be set to any other value. Reserved: This field is reserved for future use. It MUST be set to 0 on transmission and MUST be ignored when received. Downstream Cost: Cost of the local link along the route of the LSP in the direction of the tail-end node, encoded as a 32-bit integer. This approach has been taken to avoid defining a flag for each cost type in the Attribute-Flags TLV. Upstream Cost: Cost of the local link along the route of the LSP in the direction of the head-end node, encoded as a 32- bit integer. 3.3. Latency Subobject The Latency subobject is a new RRO sub-object to record the latency information of the LSP. Its format is similar the other RRO subobjects defined in [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 (must be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Downstream Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Upstream Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBA2 - Latency subobject (to be assigned by IANA). Length: 8 or 12 depending on the presence of Upstream Delay information. A-bit: These fields represent the Anomalous (A) bit associated with the Downstream and Upstream Delay respectively, as defined in [DRAFT-OSPF-TE-METRIC]. Reserved: These fields are reserved for future use. They MUST be set to 0 when sent and MUST be ignored when received. Downstream Delay: Delay of the local link along the route of the LSP in the direction of the tail-end node, encoded as 24- bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set Ali, Swallow, Filsfils Expires June 2015 [Page 6] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt to the maximum value 16,777,215 (16.777215 sec), the delay is at least that value and may be larger. Upstream Delay: Delay of the local link along the route of the LSP in the direction of the head-end node, encoded as 24- bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set to the maximum value 16,777,215 (16.777215 sec), the delay is at least that value and may be larger. 3.4. Latency Variation Subobject The Latency Variation subobject is a new RRO sub-object to record the Latency Variation information of the LSP. Its format is similar to the other RRO subobjects defined in [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 (must be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Downstream Delay Variation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved | Upstream Delay Variation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBA3 - Latency Variation subobject (to be assigned by IANA). Length: 8 or 12 depending on the presence of Upstream Latency Variation information. A-bit: These fields represent the Anomalous (A) bit associated with the Downstream and Upstream Delay Variation respectively, as defined in [DRAFT-OSPF-TE-METRIC]. Reserved: These fields are reserved for future use. It SHOULD be set to 0 when sent and MUST be ignored when received. Downstream Delay Variation: Delay Variation of the local link along the route of the LSP in the direction of the tail-end node, encoded as 24-bit integer, as defined in [DRAFT-OSPF- TE-METRIC]. When set to the maximum value 16,777,215 (16.777215 sec), the delay is at least that value and may be larger. Upstream Delay Variation: Delay Variation of the local link along the route of the LSP in the direction of the head-end node, encoded as 24-bit integer. When set to 0, it has not been measured. When set to the maximum value 16,777,215 Ali, Swallow, Filsfils Expires June 2015 [Page 7] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt (16.777215 sec), the delay is at least that value and may be larger. 4. Signaling Procedures The rules for processing the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES Objects and RRO defined in [RFC5420] are not changed. 4.1. Collection request Typically, the ingress node learns the route of an LSP by adding a RRO in the Path message. If an ingress node also desires cost, latency and/or latency variation recording, it MUST set the appropriate flag(s) in the Attribute Flags TLV of the LSP_ATTRIBUTES (if recording is desired but not mandatory) or LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object. None, all or any of the Cost Collection, Latency Collection or Latency Variation Collection flags MAY be set in the Attribute Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Object. These flags affect both Path and Resv RRO processing, as described below. The Cost Collection, Latency Collection or Latency Variation Collection flags SHOULD NOT be set in an Attribute Flags TLV in a Resv message. If any of these flags is set in a received Attribute Flags TLV in a Resv message, it MUST be ignored. The Cost Collection, Latency Collection or Latency Variation Collection flags SHOULD NOT be set in an Attribute Flags TLV in a RRO. If any of these flags is set in a received Attribute Flags TLV in a RRO, it MUST be ignored. 4.2. Path and Resv message processing 4.2.1. Cost If a node receives a Path message containing a LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag set in the Attribute Flags TLV: . If local policy disallows providing the requested information to the endpoints, the node MUST return a Path Error message with error code "Policy Control Failure" (2) and subcode "Cost Recording Rejected" (value to be assigned by IANA, suggested value 105). . It SHOULD add a Cost subobject to the Path and Resv RROs for the LSP. It SHOULD supply only downstream information for a unidirectional LSP, and SHOULD provide both upstream Ali, Swallow, Filsfils Expires June 2015 [Page 8] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt and downstream information if a bidirectional LSP is being signaled. . If Cost information is not known, a Cost subobject SHOULD NOT be added to either the Path or Resv RRO. If a node receives a Path message containing a LSP_ATTRIBUTES Object with the Cost Collection Flag set in the Attribute Flags TLV: . If local policy disallows providing the requested information to the endpoints, the Path message SHOULD NOT be rejected. A Cost subobject is not added to the Path or Resv RRO. . If local policy permits, it SHOULD add a Cost subobject to the Path and Resv RROs for the LSP. It SHOULD supply only downstream information for a unidirectional LSP, and SHOULD provide both upstream and downstream information if a bidirectional LSP is being signaled. . If Cost information is not known, a Cost subobject SHOULD NOT be added to either the Path or Resv RRO. When adding a Cost subobject to a Path or Resv RRO: . The Downstream Cost is set to the cost of the local link used by the LSP in the direction of the egress node. It SHOULD be set to zero by the egress node. . The Upstream Cost, if set, is set to the cost of the local link used by the LSP in the direction of the ingress node. It SHOULD be set to zero by the ingress node. . The cost of a local link is the Interior Gateway Protocol (IGP) metric or TE metric of the link in question, depending on the policy of the processing node. 4.2.2. Latency If a node receives a Path message containing a LSP_REQUIRED_ATTRIBUTES Object with the Latency Collection Flag set in the Attribute Flags TLV: . If local policy disallows providing the requested information to the endpoints, the node MUST return a Path Error message with error code "Policy Control Failure" (2) and subcode "Latency Recording Rejected" (value to be assigned by IANA, suggested value 106). . It SHOULD add a Latency subobject to the Path and Resv RROs for the LSP. It SHOULD supply only downstream Ali, Swallow, Filsfils Expires June 2015 [Page 9] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt information for a unidirectional LSP, and SHOULD provide both upstream and downstream information if a bidirectional LSP is being signaled. . If Latency information is not known, a Latency subobject SHOULD NOT be added to either the Path or Resv RRO. If a node receives a Path message containing a LSP_ATTRIBUTES Object with the Latency Collection Flag set in the Attribute Flags TLV: . If local policy disallows providing the requested information to the endpoints, the Path message SHOULD NOT be rejected. A Latency subobject is not added to the Path or Resv RRO. . If local policy permits, it SHOULD add a Latency subobject to the Path and Resv RROs for the LSP. It SHOULD supply only downstream information for a unidirectional LSP, and SHOULD provide both upstream and downstream information if a bidirectional LSP is being signaled. . If Latency information is not known, a Latency subobject SHOULD NOT be added to either the Path or Resv RRO. When adding a Latency subobject to a Path or Resv RRO: . The Downstream Delay is set to the delay of the local link used by the LSP in the direction of the egress node. It SHOULD be set to zero by the egress node. . The Upstream Delay, if set, is set to the delay of the local link used by the LSP in the direction of the ingress node. It SHOULD be set to zero by the ingress node. . The A-bit for the downstream and upstream latency SHOULD be set as described in [DRAFT-OSPF-TE-METRIC]. 4.2.3. Latency Variation If a node receives a Path message containing a LSP_REQUIRED_ATTRIBUTES Object with the Latency Variation Collection Flag set in the Attribute Flags TLV: . If local policy disallows providing the requested information to the endpoints, the node MUST return a Path Error message with error code "Policy Control Failure" (2) and subcode "Latency Variation Recording Rejected" (value to be assigned by IANA, suggested value 107). . It SHOULD add a Latency Variation subobject to the Path and Resv RROs for the LSP. It SHOULD supply only downstream Ali, Swallow, Filsfils Expires June 2015 [Page 10] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt information for a unidirectional LSP, and SHOULD provide both upstream and downstream information if a bidirectional LSP is being signaled. . If Latency Variation information is not known, a Latency subobject SHOULD NOT be added to either the Path or Resv RRO. If a node receives a Path message containing a LSP_ATTRIBUTES Object with the Latency Variation Collection Flag set in the Attribute Flags TLV: . If local policy disallows providing the requested information to the endpoints, the Path message SHOULD NOT be rejected. A Latency Variation subobject is not added to the Path or Resv RRO. . If local policy permits, it SHOULD add a Latency Variation subobject to the Path and Resv RROs for the LSP. It SHOULD supply only downstream information for a unidirectional LSP, and SHOULD provide both upstream and downstream information if a bidirectional LSP is being signaled. . If Latency Variation information is not known, a Latency subobject SHOULD NOT be added to either the Path or Resv RRO. When adding a Latency Variation subobject to a Path or Resv RRO: . The Downstream Latency Variation is set to the latency of the local link used by the LSP in the direction of the egress node. It SHOULD be set to zero by the egress node. . The Upstream Latency Variation, if set, is set to the latency of the local link used by the LSP in the direction of the ingress node. It SHOULD be set to zero by the egress node. . The A-bit for the downstream and upstream latency SHOULD be set as described in [DRAFT-OSPF-TE-METRIC]. 4.3. Metric Update When the cost, latency and/or latency variation information of a link is changed, the corresponding metric values for the LSPs using that link should also be updated. If node has added Cost, Latency and/or Latency Variation subobjects to the Path or Resv RRO, the procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be used to communicate any changes to relevant information to the other nodes on the LSP's path. The node need not send an update for changes to information which has not been added to the RRO. Ali, Swallow, Filsfils Expires June 2015 [Page 11] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 5. Endpoint processing The ingress and egress nodes of a LSP may calculate the end-to- end cost, latency and/or latency variation properties of the LSP from the supplied values in the Resv or Path RRO respectively. Typically, cost and latency are additive metrics, but latency variation is not an additive metric. The means by which the ingress and egress nodes compute the end-to-end cost, latency and latency variation metric from information recorded in the RRO is a local decision and is beyond the scope of this document. Based on the local policy, the ingress and egress nodes can advertise the calculated end-to-end cost, latency and/or latency variation properties of the FA or RA LSP in TE link advertisement to the routing instance based on the procedure described in [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. Based on the local policy, a transit node (e.g. the edge node of a domain) may edit a Path or Resv RRO to remove route information (e.g. node or interface identifier information) before forwarding it. A node that does this SHOULD summarize the cost, latency and latency variation data and SHOULD follow procedure defined in [DRAFT-RRO-EDIT]. How a node that performs the RRO edit operation calculates the cost, latency o and/or latency variation metric is beyond the scope of this document. 6. Security Considerations This document does not introduce any additional security issues above those identified in [RFC5920], [RFC5420], [RFC2205], [RFC3209], and [RFC3473]. 7. IANA Considerations 7.1. RSVP Attribute Bit Flags The 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]. It is requested that the IANA makes assignments from the Attribute Bit Flags defined in this document. This document introduces the following three new Attribute Bit Flag: - Bit number: TBD (recommended bit position 11) - Defining RFC: this I-D - Name of bit: Cost Collection Flag Ali, Swallow, Filsfils Expires June 2015 [Page 12] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt - Bit number: TBD (recommended bit position 12) - Defining RFC: this I-D - Name of bit: Latency Collection Flag - Bit number: TBD (recommended bit position 13) - Defining RFC: this I-D - Name of bit: Latency Variation Flag 5.2. ROUTE_RECORD subobject This document introduces the following three new RRO subobject: Type Name Reference --------- ---------------------- --------- TBD (35) Cost subobject This I-D TBD (36) Latency subobject This I-D TBD (37) Latency Variation subobject This I-D 7.2. New RSVP error sub-code For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the following sub-code is defined. Sub-code Value -------- ----- Cost Recoding Rejected To be assigned by IANA. Suggested Value: 105. Latency Recoding Rejected To be assigned by IANA. Suggested Value: 106. Latency Variation Recoding Rejected To be assigned by IANA. Suggested Value: 107. Ali, Swallow, Filsfils Expires June 2015 [Page 13] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 8. Acknowledgments Authors would like to thank Ori Gerstel, Gabriele Maria Galimberti, Luyuan Fang and Walid Wakim for their review comments. 9. References 9.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. [RFC5420] Farrel, A., Ed., 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. [DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", draft-ietf-ospf-te-metric- extensions, work in progress. [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. Drake, A. Atlas, C. Filsfils, "IS-IS Traffic Engineering (TE) Metric Extensions", draft-ietf-isis- te-metric-extensions, work in progress. 9.2. Informative References [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997. [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. Ali, Swallow, Filsfils Expires June 2015 [Page 14] Internet-Draft draft-ietf-teas-te-metric-recording-00.txt [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. Margaria,, "RSVP-TE Extensions for Collecting SRLG Information", draft-ietf-ccamp-rsvp-te-srlg- collect.txt, work in progress. Authors' Addresses Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com George Swallow Cisco Systems, Inc. swallow@cisco.com Clarence Filsfils Cisco Systems, Inc. cfilsfil@cisco.com Matt Hartley Cisco Systems Email: mhartley@cisco.com Kenji Kumaki KDDI Corporation Email: ke-kumaki@kddi.com Rudiger Kunze Deutsche Telekom AG Ruediger.Kunze@telekom.de Ali, Swallow, Filsfils Expires June 2015 [Page 15]