--- 1/draft-ietf-ccamp-te-metric-recording-03.txt 2014-08-20 09:14:36.487851599 -0700 +++ 2/draft-ietf-ccamp-te-metric-recording-04.txt 2014-08-20 09:14:36.519852399 -0700 @@ -1,46 +1,46 @@ CCAMP Working Group Zafar Ali Internet Draft George Swallow Intended status: Standard Track Clarence Filsfils - Expires: August 13, 2014 Matt Hartley + Expires: February 20, 2015 Matt Hartley Cisco Systems Kenji Kumaki KDDI Corporation Ruediger Kunze Deutsche Telekom AG - February 14, 2014 + August 20, 2014 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path - draft-ietf-ccamp-te-metric-recording-03.txt + draft-ietf-ccamp-te-metric-recording-04.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 August 13, 2014. + This Internet-Draft will expire on February 20, 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 @@ -55,21 +55,21 @@ 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. - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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. @@ -90,21 +90,21 @@ 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 - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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, @@ -141,21 +141,21 @@ 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. - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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 @@ -195,21 +195,21 @@ 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 - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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: @@ -247,21 +247,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved (must be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBA1 - Cost subobject (to be assigned by IANA). - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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 @@ -297,21 +297,21 @@ 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 - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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. @@ -348,21 +348,21 @@ 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 - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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. @@ -400,21 +400,21 @@ . 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 - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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: @@ -454,21 +454,21 @@ 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 - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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 @@ -508,21 +508,21 @@ 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 - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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 @@ -563,21 +563,21 @@ 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. - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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 @@ -617,21 +617,21 @@ 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 - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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 @@ -663,21 +663,21 @@ 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. - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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 @@ -713,21 +713,21 @@ 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. - Internet-Draft draft-ietf-ccamp-te-metric-recording-03.txt + Internet-Draft draft-ietf-ccamp-te-metric-recording-04.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.