TEAS Working Group                                        Zafar Ali
     Internet Draft                                       George Swallow
     Intended status: Standard Track                   Clarence Filsfils
     Expires: December 7, 2015 January 5, 2016                               Matt Hartley
                                                           Cisco Systems

                                                            Kenji Kumaki
                                                        KDDI Corporation

                                                          Ruediger Kunze
                                                     Deutsche Telekom AG

                                                            June 8,

                                                           July 6, 2015

          Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
           extension for recording TE Metric of a Label Switched Path
                  draft-ietf-teas-te-metric-recording-01.txt
                     draft-ietf-teas-te-metric-recording-02

     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 December 7, 2015. January 5, 2016.

     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

     Copyright Notice

     Copyright (c) 2014 2015 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.

     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt

     Abstract

     There are many scenarios in which Traffic Engineering (TE) metrics
     such as cost, latency Delay and latency Delay variation associated with a
     Forwarding Adjacency (FA) or Routing Adjacency (RA) the TE link
     formed by 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 to
     support of the discovery automatic collection of cost, latency Delay and latency Delay variation of an
     information for the TE link formed by a 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

        Copyright Notice............................................1
        1. Introduction................................................3 Introduction.............................................3
        1.1. Use Cases..............................................4
              1.1.1. GMPLS..........................................4
              1.1.2. Inter-area tunnels with loose-hops.............4
        2. RSVP-TE Requirement.........................................4 Requirement......................................4
        2.1. Cost, Latency Delay and Latency Delay Variation Collection Indication.4 Indication..4
        2.2. Cost, Latency Delay and Latency Delay Variation Collection............4 Collection.............4
        2.3. Cost, Latency Delay and Latency Delay Variation Update................4 Update.................5
        2.4. Cost Definition........................................5
        3. RSVP-TE signaling extensions................................5 extensions.............................5
     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

        3.1. Cost, Latency, Delay and Latency Delay Variation Collection Flags.....5
        3.4. Flags.......5
        3.2. Cost subobject............................................5
        3.5. Latency subobject.........................................6
        3.6. Latency Subobject.........................................6
        3.3. Delay Subobject........................................6
        3.4. Delay Variation subobject...............................7
        3.7. Signaling Procedures......................................8 Subobject..............................7
        4. Security Considerations....................................12 Signaling Procedures.....................................8
        4.1. Cost, Delay and Delay Variation Collection Request.....8
        4.2. Cost, Delay and Delay Variation Recoding...............8
        4.3. Metric Update..........................................10
        4.4. Compatibility..........................................10
        5. Endpoint processing......................................11
        6. Manageability Considerations.............................11
        6.1. Policy Configuration...................................11
        7. Security Considerations..................................12
        8. IANA Considerations........................................12
        5.1. Considerations......................................12
        8.1. RSVP Attribute Bit Flags.................................12
     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt

        5.2. New RSVP error sub-code..................................13
        6. Acknowledgments............................................14
        7. References.................................................14
        7.1. Flags...............................12
        8.2. Policy Control Failure Error subcodes..................13
        9. Acknowledgments..........................................13
        10. References..............................................14
        10.1. Normative References.....................................14
        7.2. References..................................14
        10.2. Informative References...................................14 References................................14

     1. Introduction

        In certain networks, such as financial information networks,
        network performance information (e.g. latency, latency Delay, Delay variation) is
        becoming as critical to data path selection as other metrics [DRAFT-OSPF-TE-METRIC], RFC
        7471 [RFC7471], [DRAFT-ISIS-TE-METRIC]. If cost, latency Delay or latency Delay
        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 TE
        link (FA or RA. 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. Similarly, there are
        scenarios in which measuring Delay and/ or Delay variation on a
        TE link formed by a LSP is not supported. In such scenarios, the
        ingress node cannot determine the cost, latency Delay and latency Delay
        variation properties of the LSP's route.

        One possible way to address this issue is to configure cost,
        latency
        Delay and latency Delay 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 Delay, Delay
        variation and cost attribute information associated with the TE-Link
        automatically.

        In summary, there is a requirement for the ingress and egress
        nodes to learn the cost, latency Delay and latency Delay variation
        attributes information
        of an FA or RA the TE link formed by a LSP. This draft document provides extensions a
        mechanism to collect the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
        for cost, Delay and Delay variation
        information of a LSP, which can then be advertised as properties
        of the support TE-link formed by that LSP.  Note that specification of
     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

        the automatic discovery use of these attributes. the collected cost, Delay and Delay variation
        information is outside the scope of this document.

     1.1. Use Cases

        This section describes some of the use cases for TE metric
        recording.

     1.1.1. GMPLS

        In Generalized Multi-Protocol Label Switching (GMPLS) networks
        signaling bidirectional LSPs, the egress node cannot determine
        the cost, latency Delay and latency Delay 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-teas-te-metric-recording-01.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 Delay and latency Delay variation properties of the
        LSP path.

     2. RSVP-TE Requirements Requirement

        This section outlines RSVP-TE requirements for the support of
        the automatic discovery of cost, latency Delay and latency Delay variation
        attributes
        information 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 Delay and Latency Delay Variation Collection Indication

        The ingress node of the LSP must SHOULD be capable of indicating
        whether the cost, latency and latency cost and/or delay and/ or delay variation attributes
        information of the LSP should is to be collected during the signaling
        procedure of setting up the an LSP. No cost, latency or latency variation
        information is A separate collection indication
        flag for each of this attribute is required. Cost, delay and
        delay variation information SHOULD NOT be collected without an
        explicit request for it being made by the ingress node.

     2.2. Cost, Latency Delay and Latency Delay Variation Collection

        If requested, cost, latency and latency the cost and/or delay and/ or delay variation is
        information SHOULD be collected during the setup of an LSP. Each
        of the cost, delay or delay variation can be collected
        independently. The endpoints of the LSP
        may can use the collected information
        information, for example, for routing, flooding and TE
        link configuration and other
        purposes.

     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

     2.3. Cost, Latency Delay and Latency Delay Variation Update

        When the cost, latency cost and/or delay and/ or latency delay variation property of a TE
        link along the route information
        of a an existing LSP for which that property corresponding information was
        collected changes (e.g., if the administrator changes during signaling changes, the cost relevant nodes of a TE link traversed by the LSP), the node where the change
        occurred needs to
        LSP SHOULD be capable of updating the cost, latency and
        latency variation associated information of
        the path and signaling this to
        the end-points. Similarly, if a path segment of the LSP is
        rerouted, the endpoints of LSP.  This means that the re-routed segment need to signaling procedure SHOULD be
        capable of updating the cost, latency and latency variation
        information of the path. Any node which adds cost, latency new cost and/or delay and/ or
        latency delay
        variation information to an LSP during initial setup,
        needs to signal changes to these values to both endpoints. information.

     2.4. Cost Definition

        Although the terms latency Delay and latency Delay variation are well
        understood, "cost" may be ambiguous; in particular, in the
     Internet-Draft    draft-ietf-teas-te-metric-recording-01.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 path.

          .  Simple addition of costs for different sections of a path
             must make sense.

     3. RSVP-TE signaling extensions

     3.1. Cost, Latency Delay and Latency Delay Variation Collection Flags

        In order to indicate nodes that cost, latency cost and/or Delay and/ or latency Delay
        variation collection is desired, the following three Attribute this document defines a new
        flags are defined in the Attribute Flags TLV: TLV (see RFC 5420 [RFC5420]), which
        MAY be carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES
        Object:

        - Cost Collection flag (to (Bit number to be assigned by IANA)

        - Latency Delay Collection flag (to (Bit number to be assigned by IANA)

        - Latency Delay Variation Collection flag (to (Bit number to be assigned by
        IANA)

        These flags are set

        The Cost, Delay and carried in either the LSP_ATTRIBUTES or
        LSP_REQUIRED_ATTRIBUTES Objects in Delay Variation Collection flag is
        meaningful on a Path message.

     3.2. Cost Subobject

        The  If the Cost subobject Collection flag is a new RRO (ROUTE_RECORD OBJECT) sub-object
        used
        set to record 1, it means that the cost information SHOULD be reported
        to the ingress and egress node along the setup of the LSP. Its format
        Similarly, if the Delay Collection flag is
        similar set to the other 1, it means
        that the Delay information SHOULD be reported to the ingress and
     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

        egress node along the setup of the LSP. Likewise, if the Delay
        Variation Collection flag is set to 1, it means that the Delay
        Variation 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.

     3.2. Cost Subobject

        This document defines a new RRO subobjects sub-object (ROUTE_RECORD sub-
        object) to record the cost 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 (must be zero)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Downstream Cost                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Upstream                              Cost                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Type: TBA1 - Cost subobject (to The type of the sub-object (value to be assigned by
           IANA).

     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt

           Length: The Length value is set to 8 or 12 depending on field contains the
           presence total length of Upstream Cost information. It MUST NOT be the
           sub-object in bytes, including the Type and Length fields.
           The Length value is set to
           any other value. 8.

           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 TE link along the route of the
           LSP in the direction of the head-end node, encoded as a 32-
           bit integer. LSP.

     3.3. Latency Delay Subobject

        The Latency subobject is

        This document defines a new RRO sub-object (ROUTE_RECORD sub-
        object) to record the
        latency delay information of the LSP.  Its format
        is similar modeled on the other RRO subobjects 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 (must be zero)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|  Reserved   |               Downstream Delay                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|  Reserved   |                Upstream                      Delay                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

           Type: TBA2 -  Latency subobject (to The type of the sub-object (value to be assigned by
           IANA).

           Length: 8 or 12 depending on The Length field contains the presence total length of Upstream Delay
           information. the
           sub-object in bytes, including the Type and Length fields.
           The Length value is set to 8.

           A-bit: These fields represent the Anomalous (A) bit
           associated with the Downstream and Upstream Delay
           respectively, as defined in [DRAFT-OSPF-TE-METRIC]. RFC 7471 [RFC7471].

           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 TE link along the route of the LSP in the direction of the tail-end node, LSP,
           encoded as 24-
           bit 24-bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. RFC 7471 [RFC7471].
           When set
     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt to the maximum value 16,777,215 (16.777215 sec), the
           delay is at least that value and may be larger.

           Upstream Delay:

     3.4. 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

        This document defines a new RRO sub-object (ROUTE_RECORD sub-
        object) to record the Latency Variation delay variation information of the LSP.
        Its format is similar to modeled on the other RRO subobjects 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 (must be zero)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|  Reserved   |          Downstream Delay Variation           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|  Reserved   |           Upstream                 Delay Variation               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Type: TBA3 - Latency Variation subobject (to The type of the sub-object (value to be assigned by
           IANA).

           Length: 8 or 12 depending on The Length field contains the presence total length of Upstream Latency
           Variation information. the
           sub-object in bytes, including the Type and Length fields.
           The Length value is set to 8.

           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]. RFC 7471 [RFC7471].

           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 TE link along
           the route of the LSP in the direction of the tail-end
           node, LSP, 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. RFC 7471 [RFC7471]. When set to the maximum value 16,777,215
     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt    draft-ietf-teas-te-metric-recording-02.txt

           16,777,215 (16.777215 sec), the delay variation is at least
           that value and may be larger.

     4. Signaling Procedures

        The rules for of the processing of the LSP_ATTRIBUTES LSP_REQUIRED_ATTRIBUTES,
        LSP_ATTRIBUTE and
        LSP_REQUIRED_ATTRIBUTES ROUTE_RECORD Objects and RRO defined in [RFC5420] are not changed.

        As signaling procedure for cost, delay and delay variation
        collection is similar, many parts of this section are written
        such that they apply equally to cost, delay and delay variation
        collection. There is also very strong similarity of these
        procedures with SRLG recording [DRAFT-SRLG-RECORDING].

     4.1. Cost, Delay and Delay Variation Collection request

        Typically, the Request

        Per RFC 3209 [RFC3209], an ingress node learns initiates the recording
        of the route information of an LSP by adding a RRO in the to a Path
        message. If an ingress node also desires cost,
        latency Cost and/or latency variation Delay
        and/or Delay Variation recording, it MUST set the appropriate
        flag(s) in the Attribute Flags TLV of which MAY be carried either
        in an LSP_REQUIRED_ATTRIBUTES Object when the
        LSP_ATTRIBUTES (if recording collection is desired but not mandatory)
        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 LSP_ATTRIBUTES Object when the collection is set in a received Attribute
        Flags TLV in a RRO, it MUST be ignored.
        desired, but not mandatory.

     4.2. Path Cost, Delay and Resv message processing

     4.2.1. Cost

        If Delay Variation Recoding

        When a node receives a Path message containing a which carries an
        LSP_REQUIRED_ATTRIBUTES Object with and the Cost Collection Flag set
        in the Attribute Flags TLV:

          .  If set,
        if local policy disallows providing determines that the requested cost information is not to
        be provided to the endpoints, endpoints or the node information is not known, it
        MUST return a Path
             Error PathErr message with error code "Policy Control Failure" (2) 2 (policy) and
        error 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-teas-te-metric-recording-01.txt

             and downstream information if a bidirectional LSP is being
             signaled.

          .  If Cost information is not known, a Cost subobject SHOULD
             NOT be added
        IANA) to either reject the Path or Resv RRO.

        If message. Similarly, when a node
        receives a Path message containing a LSP_ATTRIBUTES which carries an LSP_REQUIRED_ATTRIBUTES
        Object with and the Cost Delay Collection Flag set in the Attribute Flags
        TLV:

          .  If set, if local policy disallows providing
        determines that the requested Delay information is not to be provided to
        the endpoints, the Path message SHOULD NOT
             be rejected. A Cost subobject is not added to the Path endpoints 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, it MUST return 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
        PathErr message with error code 2 (policy) and error subcode
        "Delay Recording Rejected" (value 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 assigned by the LSP in the direction of the ingress node.
             It SHOULD be set IANA) 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
        reject the policy of the processing node.

     4.2.2. Latency

        If Path message. Likewise, when a node receives a Path
        message containing a which carries an LSP_REQUIRED_ATTRIBUTES Object with and the Latency
        Delay Variation Collection Flag
        set in the Attribute Flags TLV:

          .  If set, if local policy disallows providing determines
        that the requested Delay Variation information is not to be provided to
        the endpoints, endpoints or the node information is not known, it MUST return a Path
             Error
        PathErr message with error code "Policy Control Failure" (2) 2 (policy) and error subcode "Latency
        "Delay Variation Recording Rejected" (value to be assigned by IANA, suggested value 106).

          .  It SHOULD add a Latency subobject
        IANA) to reject the Path message.

        When a node receives a Path message which carries an
        LSP_ATTRIBUTES Object and Resv
             RROs for the LSP. It SHOULD supply only downstream Cost and/or Delay and/or Delay
        Variation Collection Flag set, if local policy determines that
     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt

             information for a unidirectional LSP, and SHOULD provide
             both upstream and downstream    draft-ietf-teas-te-metric-recording-02.txt

        the corresponding information if a bidirectional
             LSP is being signaled.

          .  If Latency not to be provided to the
        endpoints, or the information is not known, a Latency subobject the Path message
        SHOULD NOT be added rejected due to either the Path or Resv RRO.

        If a node receives a recording restriction and the
        Path message containing a LSP_ATTRIBUTES
        Object with the Latency Collection Flag set SHOULD be forwarded without any Cost and/or Delay
        and/or Delay Variation sub-object(s) in the Attribute
        Flags TLV:

          . RRO of the
        corresponding outgoing Path message.

        If local policy disallows providing permits the requested
             information to recording of the endpoints, Cost and/or Delay
        and/or Delay Variation information, the Path message processing node SHOULD NOT
             be rejected. A Latency subobject is not added to
        add corresponding information for the Path
             or Resv RRO.

          .  If local policy permits, it SHOULD add a Latency subobject TE link, as defined
        below, to the RRO of the corresponding outgoing Path and Resv RROs message.
        The A-bit for the LSP. It SHOULD supply
             only downstream information Delay MUST be set as described in RFC 7471
        [RFC7471]. Similarly, the A-bit for a unidirectional LSP, and
             SHOULD provide both upstream and the Delay Variation MUST be
        set as described in RFC 7471 [RFC7471]. It then forwards the
        Path message to the next node in the downstream information if
             a bidirectional LSP is being signaled.

          . direction.

        If Latency the addition of Cost and/or Delay and/or Delay Variation
        information is not known, a Latency subobject
             SHOULD NOT be added to either the Path RRO would result in the RRO exceeding its
        maximum possible size or Resv RRO.

        When adding a Latency subobject becoming too large for the Path message
        to a contain it, the requested information MUST NOT be added. If
        the Cost and/or Delay and/or Delay Variation collection request
        was contained in an LSP_REQUIRED_ATTRIBUTES Object, the
        processing node MUST behave as specified by RFC 3209 [RFC3209]
        and drop the RRO from the Path or Resv RRO:

          .  The Downstream message entirely.  If the Cost
        and/or Delay is set to and/or Delay Variation collection request was
        contained in an LSP_ATTRIBUTES Object, the delay processing node MAY
        omit some or all of the local link
             used corresponding information from the RRO;
        otherwise it MUST behave as specified by RFC 3209 [RFC3209] and
        drop the RRO from the Path message entirely.

        Following the steps described above, the intermediate nodes of
        the LSP can collect the Cost and/or Delay and/or Delay Variation
        information in the direction RRO during the processing of the egress node. It
             SHOULD be set to zero Path message
        hop by hop.  When the egress node.

          .  The Upstream Delay, if set, is set to Path message arrives at the delay of egress node,
        the
             local link used by egress node receives the LSP corresponding information in the direction of
        RRO.

        Per RFC 3209 [RFC3209], when issuing a Resv message for a Path
        message, which contains an RRO, an egress node initiates the ingress
             node. It SHOULD be set to zero RRO
        process by adding an RRO to the ingress node.

          . outgoing Resv message.  The A-bit
        processing for the downstream and upstream latency SHOULD
             be set as described RROs contained in [DRAFT-OSPF-TE-METRIC].

     4.2.3. Latency Variation

        If Resv messages then mirrors that
        of the Path messages.

        When a node receives a Path Resv message containing a
        LSP_REQUIRED_ATTRIBUTES Object with the Latency for an LSP for which Cost
        and/or Delay and/or Delay Variation Collection Flag set in the Attribute Flags TLV:

          .  If is requested,
        then when local policy disallows providing allows recording of the requested
             information to the endpoints,
        information, 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 corresponding information, to
        the Path
             and RRO of the outgoing Resv RROs message, as specified below.  The
        A-bit for the LSP. It SHOULD supply only downstream
     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt

             information Delay MUST be set as described in RFC 7471
        [RFC7471]. Similarly, the A-bit for a unidirectional LSP, and SHOULD provide
             both upstream and downstream information if a bidirectional
             LSP is being signaled.

          .  If Latency the Delay Variation information is not known, a Latency
             subobject SHOULD NOT MUST be added to either
        set as described in RFC 7471 [RFC7471]. When the Path or Resv
             RRO.

        If a node receives a Path message containing a LSP_ATTRIBUTES
        Object with
        arrives at the Latency Variation Collection Flag set in ingress node, the
        Attribute Flags TLV:

          .  If local policy disallows providing ingress node can extract the
     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

        requested information to from the endpoints, RRO in the Path message SHOULD NOT
             be rejected. same way as the egress
        node.

        A Latency node MUST NOT push a Cost, Delay or Delay Variation subobject is not added to sub-object
        in the Path RECORD_ROUTE without also pushing an IPv4 sub-object, an
        IPv6 sub-object, an Unnumbered Interface ID sub-object or Resv RRO.

          .  If local policy permits, it SHOULD add a Latency Path
        Key sub-object.

        Note that a link's Cost and/or Delay and/or Delay Variation
             subobject
        information for the upstream direction cannot be assumed to be
        the same as that in the downstream.

        .  For Path and Resv RROs messages for the LSP. It a unidirectional LSP, a node
          SHOULD
             supply only include Cost and/or Delay and/or Delay Variation sub-
          objects in the RRO for the downstream information data link only.

        .  For Path and Resv messages for a unidirectional bidirectional LSP, and a node
          SHOULD provide include Cost and/or Delay and/or Delay Variation 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 if a bidirectional LSP is being signaled.

          .  If Latency in the same order for both
          Path messages and Resv messages.  That is, the Cost and/or
          Delay and/or Delay Variation information sub- object for the upstream link
          is not known, a Latency
             subobject SHOULD NOT be added to either the Path or Resv
             RRO. RRO before the corresponding sub-object for
          the downstream link.

     4.3. Metric Update

        When adding a Latency the Cost and/or Delay and/or Delay Variation subobject to information of
        a Path or Resv RRO:

          .  The Downstream Latency Variation link is set to the latency of changed, the local LSPs using that link used by need to be aware of
        the LSP changes.  The procedures defined in the direction Section 4.4.3 of the
             egress node. It SHOULD RFC
        3209 [RFC3209] MUST be set used to zero by refresh the egress node.

          .  The Upstream Latency Variation, Cost and/or Delay
        and/or Delay Variation information if set, the corresponding change
        is set to the
             latency of be communicated to other nodes according to the local link used by the LSP in the direction
             of
        node's policy.  If local policy is that the ingress node. It Cost and/or Delay
        and/or Delay Variation change SHOULD be set suppressed or would
        result in no change to zero by the egress
             node.

          .  The A-bit for previously signaled information, the downstream and upstream latency
        node SHOULD
             be set NOT send an update.

     4.4. Compatibility

        A node that does not recognize the Cost and/or Delay and/or
        Delay Variation Collection Flag in the Attribute Flags TLV is
        expected to proceed as described specified in [DRAFT-OSPF-TE-METRIC].

     4.3. Metric Update

        When RFC 5420 [RFC5420].  It is
        expected to pass the cost, latency and/or latency variation information of TLV on unaltered if it appears in a
        link is changed,
        LSP_ATTRIBUTES object, or reject the corresponding metric values for Path message with the LSPs
        using that link should also be updated.  If
        appropriate Error Code and Value if it appears in a
        LSP_REQUIRED_ATTRIBUTES object.

     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

        A node has added Cost,
        Latency that does not recognize the Cost and/or Delay and/or Latency
        Delay Variation RRO sub-object is expected to behave as
        specified in RFC 3209 [RFC3209]: unrecognized subobjects are to the Path or Resv
        RRO,
        be ignored and passed on unchanged.

     5. Endpoint processing

        Based on the procedures defined mentioned in Section 4.4.3 of RFC 3209
        [RFC3209] MUST be used to communicate any changes to relevant 4, the endpoints
        can get the Cost and/or Delay and/or Delay Variation information
        automatically.  Then the endpoints can for instance advertise it
        as a TE link to the other nodes routing instance based on the LSP's path. The node need
        not send an update for changes to procedure
        described in [RFC6107]. How the end point uses the collected
        information which has not been
        added to is outside the RRO.

     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt

     5. Endpoint processing scope of this document.

        The ingress and egress nodes of a LSP may calculate the end-to-
        end cost, latency Delay and/or latency Delay variation properties of the LSP
        from the supplied values in the Resv or Path RRO respectively.

        Typically, cost and latency Delay are additive metrics, but latency Delay
        variation is not an additive metric. The means by which the
        ingress and egress nodes compute the end-to-end cost, latency Delay and latency
        Delay 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 Delay and/or latency Delay
        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], RFC 7471 [RFC7471], [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 Delay and SHOULD follow
        procedure defined in [DRAFT-RRO-EDIT]. Delay Variation data. How a node that performs
        the RRO edit operation calculates performs
        the RRO edit operation calculates the cost, Delay o and/or Delay
        variation metric is beyond the scope of this document.

     6. Manageability Considerations

     6.1. Policy Configuration

        In a border node of inter-domain or inter-layer network, the
        following Cost and/or Delay and/or Delay Variation processing
        policy SHOULD be capable of being configured:

     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

        o  Whether the Cost and/or Delay and/or Delay Variation 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 cost, latency o and/or
        latency variation metric is beyond domain or layer network, or removed entirely.

        A node using RFC 5553 [RFC5553] and PKS MAY apply the scope of this document.

     6. same
        policy.

     7. Security Considerations

        This document does not introduce any additional builds on the mechanisms defined in [RFC3473],
        which also discusses related security issues
        above those identified measures.  In addition,
        [RFC5920] provides an overview of security vulnerabilities and
        protection mechanisms for the GMPLS control plane.  The
        procedures defined in [RFC5920], [RFC5420], [RFC2205],
        [RFC3209], this document permit the transfer of Cost
        and/or Delay and/or Delay Variation data between layers or
        domains during the signaling of LSPs, subject to policy at the
        layer or domain boundary.  It is recommended that domain/layer
        boundary policies take the implications of releasing Cost and/or
        Delay and/or Delay Variation information into consideration and [RFC3473].

     7.
        behave accordingly during LSP signaling.

     8. IANA Considerations

     7.1.

     8.1. RSVP Attribute Bit Flags

           The

        IANA has created a registry and manages the space of
        attributes the
        Attribute bit flags of the Attribute Flags TLV TLV, as described in
        section 11.3 of [RFC5420]. It is requested that RFC 5420 [RFC5420], in the IANA makes
        assignments from "Attribute Flags"
        section of the Attribute Bit Flags defined "Resource Reservation Protocol-Traffic
        Engineering (RSVP-TE) Parameters" registry located in this
        document.
        http://www.iana.org/assignments/rsvp-te- parameters".

        This document introduces the following three new Attribute Bit Flag:

              -
        Flags:

        Bit number: TBD (recommended bit position 11)

              - Defining RFC: this I-D

              - No      Name of bit:        Attribute   Attribute   RRO  Reference

                                Flags Path  Flags Resv

        ----------- ----------  ----------  ----------- ---  -------

        TBA by      Cost        Yes         Yes         Yes  This I-D
        IANA        Collection
                    Flag
     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt

              - Bit number: TBD (recommended bit position 12)

              - Defining RFC: this

        TBA by      Delay       Yes         Yes         Yes  This I-D

              - Name of bit: Latency
        IANA        Collection
                    Flag

              - Bit number: TBD (recommended bit position 13)

              - Defining RFC: this
     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

        TBA by      Delay       Yes         Yes         Yes  This I-D

              - Name of bit: Latency
        IANA        Variation
                    Collection
                    Flag

        5.2. ROUTE_RECORD subobject

        IANA manages the "RSVP PARAMETERS" registry located at
        http://www.iana.org/assignments/rsvp-parameters. This document
        introduces the following three new RRO subobject:

             Type         Name                        Reference

             ---------    ----------------------      ---------

                     TBD (35)

             TBA by IANA  Cost subobject              This I-D

                     TBD (36)   Latency

             TBA by IANA  Delay subobject             This I-D

                     TBD (37)   Latency

             TBA by IANA  Delay Variation subobject   This I-D

     7.2. New RSVP error sub-code

        For Error Code = 2 "Policy

     8.2. Policy Control Failure" (see [RFC2205]) Failure Error subcodes

        IANA manages the 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. This document introduces the following sub-code is defined.

           Sub-code three new
        Policy Control Failure Error sub-code:

        Value
           --------           Description                          Reference
        -----           -----------                          ---------
        TBA by IANA     Cost Recoding Rejected                To be assigned               This I-D
        TBA by IANA.
                                                 Suggested Value: 105.

           Latency IANA     Delay Recoding Rejected             To be assigned              This I-D
        TBA by IANA.
                                                 Suggested Value: 106.

           Latency IANA     Delay Variation Recoding Rejected   To be assigned by IANA.
                                                 Suggested Value: 107.

     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt

     8.    This I-D

     9. Acknowledgments

        Authors would like to thank Ori Gerstel, Gabriele Maria
        Galimberti, Luyuan Fang and Walid Wakim for their review
        comments.

     9.

     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

     10. References

     9.1.

     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.

        [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]

        [RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi,
                  Previdi., "OSPF Traffic Engineering (TE) Metric
                  Extensions", draft-ietf-ospf-te-metric-
                  extensions, work in progress. RFC 7471, March 2015.

        [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.

     10.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.

     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt

        [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, M.
                  Hartley, Z. Ali, C.
                  Margaria,, Margaria, "RSVP-TE Extensions for
                  Collecting SRLG Information", draft-ietf-ccamp-rsvp-te-srlg-
                  collect.txt, draft-ietf-teas-rsvp-te-
                  srlg-collect.txt, work in progress.

     Authors' Addresses
     Internet-Draft    draft-ietf-teas-te-metric-recording-02.txt

        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