CCAMP Working Group                                       Zafar Ali
     Internet Draft                                       George Swallow
     Intended status: Standard Track                   Clarence Filsfils
     Expires: January August 13, 2014                               Matt Hartley
                                                           Cisco Systems

                                                            Kenji Kumaki
                                                        KDDI Corporation

                                                          Ruediger Kunze
                                                     Deutsche Telekom AG
                                                           July

                                                      February 14, 2013 2014

          Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
           extension for recording TE Metric of a Label Switched Path
                  draft-ietf-ccamp-te-metric-recording-02.txt
                  draft-ietf-ccamp-te-metric-recording-03.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 January August 13, 2014.

     Copyright Notice

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

     Internet-Draft    draft-ietf-ccamp-te-metric-recording-02.txt    draft-ietf-ccamp-te-metric-recording-03.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

        Copyright Notice..................................................1

        1. Introduction...................................................3 Introduction................................................3
        2. RSVP-TE Requirement............................................3 Requirement.........................................4
        2.1. Cost, Latency and Latency Variation Collection Indication....4 Indication.4
        2.2. Cost, Latency and Latency Variation Collection...............4 Collection............4
        2.3. Cost, Latency and Latency Variation Update...................4 Update................4
        3. RSVP-TE signaling extensions...................................4 extensions................................5
        3.1. Cost, Latency Latency, and Latency Variation Collection Flags.........4
        3.2. Flags.....5
        3.4. Cost Subobject...............................................5
        3.3. subobject............................................5
        3.5. Latency Subobject............................................6
        3.4. subobject.........................................6
        3.6. Latency Variation Subobject..................................7
        3.5. subobject...............................7
        3.7. Signaling Procedures.........................................8 Procedures......................................8
        4. Security Considerations........................................9 Considerations....................................12
        5. IANA Considerations............................................9 Considerations........................................12
        5.1. RSVP Attribute Bit Flags.....................................9 Flags.................................12
     Internet-Draft    draft-ietf-ccamp-te-metric-recording-02.txt    draft-ietf-ccamp-te-metric-recording-03.txt

        5.2. New RSVP error sub-code.....................................10 sub-code..................................13
        6. Acknowledgments...............................................11 Acknowledgments............................................14
        7. References....................................................11 References.................................................14
        7.1. Normative References........................................11 References.....................................14
        7.2. Informative References......................................12 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 many 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. Similarly, in Generalized Multi-
        Protocol Label Switching (GMPLS) networks signaling
        bidirectional LSP, the egress node cannot determine the

        One possible way to address this issue is to configure cost,
        latency and latency variation properties of values manually. However, in the LSP route.  A
        multi-domain or multi-layer network is an example
        event of such
        networks. Similarly, a GMPLS User-Network Interface (UNI)
        [RFC4208] is also an example of such networks.

        In certain networks, LSP being rerouted (e.g. due to re-optimization),
        such as financial information networks,
        network performance configuration information (e.g. latency, latency
        variation) may become invalid. Consequently,
        in cases where that an LSP 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 an FA or an
        RA LSP is not available to the ingress or egress node, it cannot
        be advertised as an attribute of the FA or RA. 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 case where that
        an LSP is advertised 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.

     Internet-Draft    draft-ietf-ccamp-te-metric-recording-03.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 Requirement 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].

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

     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 and or latency variation property of a TE
        link along the route of a LSP for which that property was
        collected changes, e.g., changes (e.g., if the administrator changes the cost
        of a TE link, 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 re-routed segment need to be
        capable of updating the cost, latency and latency variation
        information of the path. Any node, 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

        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

        Three

        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,
        which can be set and carried in either the LSP_ATTRIBUTES or
        LSP_REQUIRED_ATTRIBUTES Objects.

        - Cost Collection flag (to 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 meaningful in a Path message. If the Cost
        Collection flag is set to 1, the transit nodes SHOULD report the
        cost information in the Record Route Objects (RRO) of both the
        Path and Resv messages.

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

        If the Cost Collection flag is set to 1, the transit nodes
        SHOULD report latency variation information in the Record Route
        Objects (RRO) of both the Path and Resv messages.

        If the Latency Collection flag is set to 1, the transit nodes
        SHOULD report latency variation information carried in either the Record Route LSP_ATTRIBUTES or
        LSP_REQUIRED_ATTRIBUTES Objects (RRO) of both the Path and Resv messages.

        If the Latency Variation Collection flag is set to 1, the
        transit nodes SHOULD report latency variation information in the
        Record Route Objects (RRO) of both the a Path and Resv messages.

        The procedure for the processing the Attribute Flags TLV follows
        [RFC5420]. message.

     3.2. Cost Subobject

        The cost Cost subobject is defined for the 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 (ROUTE_RECORD sub-object) 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).

     Internet-Draft    draft-ietf-ccamp-te-metric-recording-03.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 when sent 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. Based on the policy at the recording node,
           the cost value can be set to the Interior Gateway Protocol
           (IGP) metric or TE metric of the link in question. This approach has been taken to avoid
           defining a flag for each cost type in the Attribute-Flags
           TLV. It is assumed that,
           based on policy, all nodes report the same cost-type and that
     Internet-Draft    draft-ietf-ccamp-te-metric-recording-02.txt

           the ingress and egress nodes know the cost type reported in
           the RRO.

           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. Based on the policy at the recording node, the
           cost value can be set

     3.3. Latency Subobject

        The Latency subobject is a new RRO sub-object to record the Interior Gateway Protocol (IGP)
           metric or TE metric
        latency information of the link in question. This approach
           has been taken to avoid defining a flag for each cost type in
           the Attribute-Flags TLV. It is assumed that, based on policy,
           all nodes report the same cost-type and that the ingress and
           egress nodes know the cost type reported in the RRO.

     3.3. Latency Subobject

        The Latency subobject is defined for RRO to record the latency
        information of the LSP. Its format is similar the RRO subobjects
        defined 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 Cost 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.  When set to 0, it has not been measured. integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set
     Internet-Draft    draft-ietf-ccamp-te-metric-recording-03.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-
     Internet-Draft    draft-ietf-ccamp-te-metric-recording-02.txt
           bit integer. When set to 0, it has not been measured. 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 defined for 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 MUST 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.  When set to 0, it has not
           been measured. 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

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

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

     3.5.

     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 sets 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 MAY be set in the Attribute
        Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
        Object.  The rules for processing the LSP_ATTRIBUTES and
        LSP_REQUIRED_ATTRIBUTES Objects These flags affect both Path and Resv RRO are not changed. processing, as
        described below.

        The
        corresponding sub-objects 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 included ignored.

        The Cost Collection, Latency Collection or Latency Variation
        Collection flags SHOULD NOT be set in the an Attribute Flags TLV in
        a RRO. If any of these flags is set in a received Attribute
        Flags TLV in a RRO, with the
        Downstream (only) information filled in.

        When it MUST be ignored.

     4.2. Path and Resv message processing

     4.2.1. Cost

        If a node receives a Path message which carries an containing a
        LSP_REQUIRED_ATTRIBUTES Object and with the Cost, Latency and/or
        Latency Variation Cost Collection Flag(s) is (are) set, if 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)" Failure" (2)
             and one of the following error
        subcodes:

        . subcode "Cost Recoding Recording Rejected" (value to be assigned
             by IANA, suggested value 105) if Cost Collection Flag is set. 105).

          . "Latency Recording Rejected" (value  It SHOULD add a Cost subobject to be assigned by IANA,
          suggested value 106) 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

             and downstream information if Latency Collection Flag a bidirectional LSP is set. being
             signaled.

          . "Latency Variation Recording Rejected" (value to be assigned
          by IANA, suggested value 107) if Latency Variation Collection
          Flag  If Cost information is set.

        When not known, a Cost subobject SHOULD
             NOT be added to either the Path or Resv RRO.

        If a node receives a Path message which carries an containing a LSP_ATTRIBUTES
        Object and with the Cost, Latency and/or Latency
        Variation Cost Collection Flag(s) is (are) set, if Flag set in the Attribute Flags
        TLV:

          .  If local policy disallows providing the requested
             information to the endpoints, the Path message SHOULD NOT rejected due to Metric recording
        restriction and the Path message
             be rejected. A Cost subobject is forwarded without the
        appropriate sub-object(s) in not added to the Path or
             Resv RRO.

          .  If local policy permits the recording of the requested
        information, the processing node permits, it SHOULD add the requested
        subobject(s) with the cost, latency and/or latency variation
        metric value(s) associated with the local hop a Cost subobject to
             the Path RRO.
        If and Resv RROs for the LSP being setup is bidirectional, LSP. It SHOULD supply only
             downstream information for a unidirectional LSP, and SHOULD
             provide both Downstream upstream and
        Upstream downstream information SHOULD be included.  If the if a
             bidirectional LSP is
        unidirectional, only Downstream being signaled.

          .  If Cost information is not known, a Cost subobject SHOULD
             NOT be included.

        Following added to either the steps described above, Path or Resv RRO.

        When adding a Cost subobject to a Path or Resv RRO:

          .  The Downstream Cost is set to the intermediate nodes cost of the local link
             used by the LSP provide in the requested 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 value(s) associated 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
     Internet-Draft    draft-ietf-ccamp-te-metric-recording-02.txt    draft-ietf-ccamp-te-metric-recording-03.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 hop 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
     Internet-Draft    draft-ietf-ccamp-te-metric-recording-03.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 the Path RRO. [DRAFT-OSPF-TE-METRIC].

     4.3. Metric Update

        When the egress node receives the
        Path message, it can calculate the end-to-end cost, latency and/or latency variation properties information of the LSP.

        Before the Resv message a
        link is sent to changed, the upstream node, corresponding metric values for the egress LSPs
        using that link should also be updated.  If node adds the requested subobject(s) with the downstream cost,
        latency has added Cost,
        Latency and/or latency variation metric value(s) associated with
        the local hop Latency Variation subobjects to the Path or Resv RRO in a similar manner to that
        specified above for
        RRO, the addition procedures defined in Section 4.4.3 of Path RRO sub-objects by
        transit nodes.

        Similarly, RFC 3209
        [RFC3209] MUST be used to communicate any changes to relevant
        information to the intermediate other nodes of the LSP provide the
        requested metric value(s) associated with on the local hop in LSP's path. The node need
        not send an update for changes to information which has not been
        added to the
        Resv RRO. When the

     Internet-Draft    draft-ietf-ccamp-te-metric-recording-03.txt

     5. Endpoint processing

        The ingress node receives the Resv message, it can and egress nodes of a LSP may calculate the end-to-end end-to-
        end cost, latency and/or latency variation properties of the LSP. 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 removed as a single
        value for each for the loose hop that is summarized by the
        transit node. and SHOULD follow
        procedure defined in [DRAFT-RRO-EDIT]. How a transit node that performs
        the RRO edit operation calculates the cost, latency o and/or
        latency variation metric for the segment summarized by
        the transit node is beyond the scope of this document.

     4.

     6. Security Considerations

        This document does not introduce any additional security issues
        above those identified in [RFC5920], [RFC5420], [RFC2205],
        [RFC3209], and [RFC3473].

     5.

     7. IANA Considerations

     5.1.

     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
     Internet-Draft    draft-ietf-ccamp-te-metric-recording-02.txt
        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
     Internet-Draft    draft-ietf-ccamp-te-metric-recording-03.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

     5.2.

     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
           --------                              -----
     Internet-Draft    draft-ietf-ccamp-te-metric-recording-02.txt

           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.

     6.

     Internet-Draft    draft-ietf-ccamp-te-metric-recording-03.txt

     8. Acknowledgments

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

     7.

     9. References

     7.1.

     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.

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

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

     7.2.

     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.

     Internet-Draft    draft-ietf-ccamp-te-metric-recording-03.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