Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Zafar Ali , George Swallow , Clarence Filsfils , Matt Hartley , Kenji Kumaki , Ruediger Kunze
Last updated 2015-06-08
Replaces draft-ietf-ccamp-te-metric-recording
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-teas-te-metric-recording-01
TEAS Working Group                                        Zafar Ali 
     Internet Draft                                       George Swallow 
     Intended status: Standard Track                   Clarence Filsfils 
     Expires: December 7, 2015                              Matt Hartley  
                                                           Cisco Systems 
                                                                         
                                                            Kenji Kumaki 
                                                        KDDI Corporation 
                                                                         
                                                          Ruediger Kunze 
                                                     Deutsche Telekom AG  
                                                                         
                                                            June 8, 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 
                                         
     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. 
         
     Copyright Notice 
         

     Copyright (c) 2014 IETF Trust and the persons identified as the 
     document authors.  All rights reserved. 

     This document is subject to BCP 78 and the IETF Trust's Legal 
     Provisions Relating to IETF Documents 
     (http://trustee.ietf.org/license-info) in effect on the date of 
     publication of this document.  Please review these documents 
     carefully, as they describe your rights and restrictions with 
     respect to this document.  Code Components extracted from this 
     document must include Simplified BSD License text as described in 
     Section 4.e of the Trust Legal Provisions and are provided without 
     warranty as described in the Simplified BSD License. 

     This document may contain material from IETF Documents or IETF 
     Contributions published or made publicly available before November 
     10, 2008.  The person(s) controlling the copyright in some of this 
     material may not have granted the IETF Trust the right to allow 
     modifications of such material outside the IETF Standards Process. 
     Without obtaining an adequate license from the person(s) 
     controlling the copyright in such materials, this document may not 
     be modified outside the IETF Standards Process, and derivative 
     works of it may not be created outside the IETF Standards Process, 
     except to format it for publication as an RFC or to translate it 
     into languages other than English.
      
     Ali, Swallow, Filsfils, et al     Expires Dec. 2015         [Page 1] 
      


     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 and latency variation associated with a 
     Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched 
     Path (LSP) are not available to the ingress and egress nodes. This 
     draft provides extensions for the Resource ReserVation Protocol-
     Traffic Engineering (RSVP-TE) for the support of the discovery of 
     cost, latency and latency variation of an LSP.  

         
     Conventions used in this document 

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 
     this document are to be interpreted as described in RFC 2119 
     [RFC2119]. 

     Table of Contents 

         
        1. Introduction................................................3 
        2. RSVP-TE Requirement.........................................4 
        2.1. Cost, Latency and Latency Variation Collection Indication.4 
        2.2. Cost, Latency and Latency Variation Collection............4 
        2.3. Cost, Latency and Latency Variation Update................4 
        3. RSVP-TE signaling extensions................................5 
        3.1. Cost, Latency, and Latency Variation Collection Flags.....5 
        3.4. Cost subobject............................................5 
        3.5. Latency subobject.........................................6 
        3.6. Latency Variation subobject...............................7 
        3.7. Signaling Procedures......................................8 
        4. Security Considerations....................................12 
        5. IANA Considerations........................................12 
        5.1. RSVP Attribute Bit Flags.................................12 
     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 2] 


     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. Normative References.....................................14 
        7.2. Informative References...................................14 
         
     1. Introduction 

        In certain networks, such as financial information networks, 
        network performance information (e.g. latency, latency 
        variation) is becoming as critical to data path selection as 
        other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If 
        cost, latency or latency variation associated with a Forwarding 
        Adjacency (FA) or a Routing Adjacency (RA) LSP is not available 
        to the ingress or egress node, it cannot be advertised as an 
        attribute of the FA or RA. There are scenarios in packet and 
        optical networks where the route information of an LSP may not 
        be provided to the ingress node for confidentiality reasons 
        and/or the ingress node may not run the same routing instance as 
        the intermediate nodes traversed by the path. In such scenarios, 
        the ingress node cannot determine the cost, latency and latency 
        variation properties of the LSP's route.  

        One possible way to address this issue is to configure cost, 
        latency and latency variation values manually. However, in the 
        event of an LSP being rerouted (e.g. due to re-optimization), 
        such configuration information may become invalid. Consequently, 
        in cases where that an LSP is advertised as a TE-Link, the 
        ingress and/or egress nodes cannot provide the correct latency, 
        latency variation and cost attribute associated with the TE-Link 
        automatically.  

        In summary, there is a requirement for the ingress and egress 
        nodes to learn the cost, latency and latency variation 
        attributes of an FA or RA LSP. This draft provides extensions to 
        the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 
        for the support of the automatic discovery of these attributes.  

     1.1. Use Cases 

     1.1.1. GMPLS  

        In Generalized Multi-Protocol Label Switching (GMPLS) networks 
        signaling bidirectional LSPs, the egress node cannot determine 
        the cost, latency and latency variation properties of the LSP 
        path.  A multi-domain or multi-layer network is an example of 
        such networks. A GMPLS User-Network Interface (UNI) [RFC4208] is 
        also an example of such networks. 

     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 3] 


     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 and latency variation properties of 
        the LSP path. 

     2. RSVP-TE Requirements  

        This section outlines RSVP-TE requirements for the support of 
        the automatic discovery of cost, latency and latency variation 
        attributes of an LSP. These requirements are very similar to the 
        requirement of discovering the Shared Risk Link Groups (SRLGs) 
        associated with the route taken by an LSP [DRAFT-SRLG-
        RECORDING].  

     2.1. Cost, Latency and Latency Variation Collection Indication 

           The ingress node of the LSP must be capable of indicating 
        whether the cost, latency and latency variation attributes of 
        the LSP should be collected during the signaling procedure of 
        setting up the LSP. No cost, latency or latency variation 
        information is collected without an explicit request being made 
        by the ingress node. 

     2.2. Cost, Latency and Latency Variation Collection 

           If requested, cost, latency and latency variation is 
        collected during the setup of an LSP. The endpoints of the LSP 
        may use the collected information for routing, flooding and TE 
        link configuration and other purposes. 

     2.3. Cost, Latency and Latency Variation Update 

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

     2.4. Cost Definition 

        Although the terms latency and latency variation are well 
        understood, "cost" may be ambiguous; in particular, in the 
     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 4] 


     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 

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

     3. RSVP-TE signaling extensions 

     3.1. Cost, Latency and Latency Variation Collection Flags 

        In order to indicate nodes that cost, latency and/ or latency 
        variation collection is desired, the following three Attribute 
        flags are defined in the Attribute Flags TLV:  

        - Cost Collection flag (to be assigned by IANA) 

        - Latency Collection flag (to be assigned by IANA) 

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

        These flags are set and carried in either the LSP_ATTRIBUTES or 
        LSP_REQUIRED_ATTRIBUTES Objects in a Path message. 

     3.2. Cost Subobject 

        The Cost subobject is a new RRO (ROUTE_RECORD OBJECT) sub-object 
        used to record the cost information of the LSP. Its format is 
        similar to the other RRO subobjects defined in [RFC3209]. 

            
        0                   1                   2                   3 
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |     Type      |    Length     |    Reserved (must be zero)    | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                       Downstream Cost                         | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                        Upstream Cost                          | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
      
           Type: TBA1 - Cost subobject (to be assigned by IANA). 

     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 5] 


     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt 
      
           Length: The Length value is set to 8 or 12 depending on the 
           presence of Upstream Cost information. It MUST NOT be set to 
           any other value. 

           Reserved: This field is reserved for future use. It MUST be 
           set to 0 on transmission and MUST be ignored when received. 

           Downstream Cost: Cost of the local link along the route of 
           the LSP in the direction of the tail-end node, encoded as a 
           32-bit integer. This approach has been taken to avoid 
           defining a flag for each cost type in the Attribute-Flags 
           TLV.  
            
           Upstream Cost: Cost of the local link along the route of the 
           LSP in the direction of the head-end node, encoded as a 32-
           bit integer.  
            
     3.3. Latency Subobject 

        The Latency subobject is a new RRO sub-object to record the 
        latency information of the LSP. Its format is similar the other 
        RRO subobjects defined in [RFC3209].  

        0                   1                   2                   3 
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |   Type        |   Length      |    Reserved (must be zero)    | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |A|  Reserved   |               Downstream Delay                |              
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |A|  Reserved   |                Upstream Delay                 | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         

           Type: TBA2 -  Latency subobject (to be assigned by IANA). 

           Length: 8 or 12 depending on the presence of Upstream Delay 
           information. 

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

           Reserved: These fields are reserved for future use. They MUST 
           be set to 0 when sent and MUST be ignored when received. 

           Downstream Delay: Delay of the local link along the route of 
           the LSP in the direction of the tail-end node, encoded as 24-
           bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set 

     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 6] 


     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: Delay of the local link along the route of 
           the LSP in the direction of the head-end node, encoded as 24-
           bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set 
           to the maximum value 16,777,215 (16.777215 sec), the delay is 
           at least that value and may be larger.  

               

     3.4. Latency Variation Subobject 

        The Latency Variation subobject is a new RRO sub-object to 
        record the Latency Variation information of the LSP. Its format 
        is similar to the other RRO subobjects defined in [RFC3209].  

        0                   1                   2                   3 
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |   Type        |   Length      |    Reserved (must be zero)    | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |A|  Reserved   |          Downstream Delay Variation           |              
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |A|  Reserved   |           Upstream Delay Variation            | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         

           Type: TBA3 - Latency Variation subobject (to be assigned by 
           IANA). 

           Length: 8 or 12 depending on the presence of Upstream Latency 
           Variation information. 

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

           Reserved: These fields are reserved for future use. It SHOULD 
           be set to 0 when sent and MUST be ignored when received. 

           Downstream Delay Variation: Delay Variation of the local link 
           along the route of the LSP in the direction of the tail-end 
           node, encoded as 24-bit integer, as defined in [DRAFT-OSPF-
           TE-METRIC]. When set to the maximum value 16,777,215 
           (16.777215 sec), the delay is at least that value and may be 
           larger.  

           Upstream Delay Variation: Delay Variation of the local link 
           along the route of the LSP in the direction of the head-end 
           node, encoded as 24-bit integer. When set to 0, it has not 
           been measured. When set to the maximum value 16,777,215 
     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 7] 


     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt 
      
           (16.777215 sec), the delay is at least that value and may be 
           larger.  

            

     4. Signaling Procedures 

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

     4.1. Collection request 

        Typically, the ingress node learns the route of an LSP by adding 
        a RRO in the Path message. If an ingress node also desires cost, 
        latency and/or latency variation recording, it MUST set the 
        appropriate flag(s) in the Attribute Flags TLV of the 
        LSP_ATTRIBUTES (if recording is desired but not mandatory) or 
        LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object.  
        None, all or any of the Cost Collection, Latency Collection or 
        Latency Variation Collection flags MAY be set in the Attribute 
        Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 
        Object. These flags affect both Path and Resv RRO processing, as 
        described below. 

        The Cost Collection, Latency Collection or Latency Variation 
        Collection flags SHOULD NOT be set in an Attribute Flags TLV in 
        a Resv message. If any of these flags is set in a received 
        Attribute Flags TLV in a Resv message, it MUST be ignored. 

        The Cost Collection, Latency Collection or Latency Variation 
        Collection flags SHOULD NOT be set in an Attribute Flags TLV in 
        a RRO. If any of these flags is set in a received Attribute 
        Flags TLV in a RRO, it MUST be ignored. 

     4.2. Path and Resv message processing 

     4.2.1. Cost 

        If a node receives a Path message containing a 
        LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag set 
        in the Attribute Flags TLV: 

          .  If local policy disallows providing the requested 
             information to the endpoints, the node MUST return a Path 
             Error message with error code "Policy Control Failure" (2) 
             and subcode "Cost Recording Rejected" (value to be assigned 
             by IANA, suggested value 105). 

          .  It SHOULD add a Cost subobject to the Path and Resv RROs 
             for the LSP. It SHOULD supply only downstream information 
             for a unidirectional LSP, and SHOULD provide both upstream 
     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 8] 


     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 to either the Path or Resv RRO. 

        If a node receives a Path message containing a LSP_ATTRIBUTES 
        Object with the Cost Collection Flag set in the Attribute Flags 
        TLV: 

          .  If local policy disallows providing the requested 
             information to the endpoints, the Path message SHOULD NOT 
             be rejected. A Cost subobject is not added to the Path or 
             Resv RRO. 

          .  If local policy permits, it SHOULD add a Cost subobject to 
             the Path and Resv RROs for the LSP. It SHOULD supply only 
             downstream information for a unidirectional LSP, and SHOULD 
             provide both upstream and downstream information if a 
             bidirectional LSP is being signaled. 

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

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

          .  The Downstream Cost is set to the cost of the local link 
             used by the LSP in the direction of the egress node. It 
             SHOULD be set to zero by the egress node. 

          .  The Upstream Cost, if set, is set to the cost of the local 
             link used by the LSP in the direction of the ingress node. 
             It SHOULD be set to zero by the ingress node. 

          .  The cost of a local link is the Interior Gateway Protocol 
             (IGP) metric or TE metric of the link in question, 
             depending on the policy of the processing node. 

     4.2.2. Latency 

        If a node receives a Path message containing a 
        LSP_REQUIRED_ATTRIBUTES Object with the Latency Collection Flag 
        set in the Attribute Flags TLV: 

          .  If local policy disallows providing the requested 
             information to the endpoints, the node MUST return a Path 
             Error message with error code "Policy Control Failure" (2) 
             and subcode "Latency Recording Rejected" (value to be 
             assigned by IANA, suggested value 106). 

          .  It SHOULD add a Latency subobject to the Path and Resv 
             RROs for the LSP. It SHOULD supply only downstream 
     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 9] 


     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt 
      
             information for a unidirectional LSP, and SHOULD provide 
             both upstream and downstream information if a bidirectional 
             LSP is being signaled. 

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

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

          .  If local policy disallows providing the requested 
             information to the endpoints, the Path message SHOULD NOT 
             be rejected. A Latency subobject is not added to the Path 
             or Resv RRO. 

          .  If local policy permits, it SHOULD add a Latency subobject 
             to the Path and Resv RROs for the LSP. It SHOULD supply 
             only downstream information for a unidirectional LSP, and 
             SHOULD provide both upstream and downstream information if 
             a bidirectional LSP is being signaled. 

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

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

          .  The Downstream Delay is set to the delay of the local link 
             used by the LSP in the direction of the egress node. It 
             SHOULD be set to zero by the egress node. 

          .  The Upstream Delay, if set, is set to the delay of the 
             local link used by the LSP in the direction of the ingress 
             node. It SHOULD be set to zero by the ingress node. 

          .  The A-bit for the downstream and upstream latency SHOULD 
             be set as described in [DRAFT-OSPF-TE-METRIC]. 

     4.2.3. Latency Variation 

        If a node receives a Path message containing a 
        LSP_REQUIRED_ATTRIBUTES Object with the Latency Variation 
        Collection Flag set in the Attribute Flags TLV: 

          .  If local policy disallows providing the requested 
             information to the endpoints, the node MUST return a Path 
             Error message with error code "Policy Control Failure" (2) 
             and subcode "Latency Variation Recording Rejected" (value 
             to be assigned by IANA, suggested value 107). 

          .  It SHOULD add a Latency Variation subobject to the Path 
             and Resv RROs for the LSP. It SHOULD supply only downstream 
     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 10] 


     Internet-Draft    draft-ietf-teas-te-metric-recording-01.txt 
      
             information for a unidirectional LSP, and SHOULD provide 
             both upstream and downstream information if a bidirectional 
             LSP is being signaled. 

          .  If Latency Variation information is not known, a Latency 
             subobject SHOULD NOT be added to either the Path or Resv 
             RRO. 

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

          .  If local policy disallows providing the requested 
             information to the endpoints, the Path message SHOULD NOT 
             be rejected. A Latency Variation subobject is not added to 
             the Path or Resv RRO. 

          .  If local policy permits, it SHOULD add a Latency Variation 
             subobject to the Path and Resv RROs for the LSP. It SHOULD 
             supply only downstream information for a unidirectional 
             LSP, and SHOULD provide both upstream and downstream 
             information if a bidirectional LSP is being signaled. 

          .  If Latency Variation information is not known, a Latency 
             subobject SHOULD NOT be added to either the Path or Resv 
             RRO. 

        When adding a Latency Variation subobject to a Path or Resv RRO: 

          .  The Downstream Latency Variation is set to the latency of 
             the local link used by the LSP in the direction of the 
             egress node. It SHOULD be set to zero by the egress node. 

          .  The Upstream Latency Variation, if set, is set to the 
             latency of the local link used by the LSP in the direction 
             of the ingress node. It SHOULD be set to zero by the egress 
             node. 

          .  The A-bit for the downstream and upstream latency SHOULD 
             be set as described in [DRAFT-OSPF-TE-METRIC]. 

     4.3. Metric Update 

        When the cost, latency and/or latency variation information of a 
        link is changed, the corresponding metric values for the LSPs 
        using that link should also be updated.  If node has added Cost, 
        Latency and/or Latency Variation subobjects to the Path or Resv 
        RRO, the procedures defined in Section 4.4.3 of RFC 3209 
        [RFC3209] MUST be used to communicate any changes to relevant 
        information to the other nodes on the LSP's path. The node need 
        not send an update for changes to information which has not been 
        added to the RRO.  
     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 11] 


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

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

        Typically, cost and latency are additive metrics, but latency 
        variation is not an additive metric. The means by which the 
        ingress and egress nodes compute the end-to-end cost, latency 
        and latency variation metric from information recorded in the 
        RRO is a local decision and is beyond the scope of this 
        document.   

        Based on the local policy, the ingress and egress nodes can 
        advertise the calculated end-to-end cost, latency and/or latency 
        variation properties of the FA or RA LSP in TE link 
        advertisement to the routing instance based on the procedure 
        described in [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. 

        Based on the local policy, a transit node (e.g. the edge node of 
        a domain) may edit a Path or Resv RRO to remove route 
        information (e.g. node or interface identifier information) 
        before forwarding it. A node that does this SHOULD summarize the 
        cost, latency and latency variation data and SHOULD follow 
        procedure defined in [DRAFT-RRO-EDIT]. How a node that performs 
        the RRO edit operation calculates the cost, latency o and/or 
        latency variation metric is beyond the scope of this document.  

     6. Security Considerations 

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

     7. IANA Considerations 

     7.1. RSVP Attribute Bit Flags 

           The IANA has created a registry and manages the space of 
        attributes bit flags of Attribute Flags TLV as described in 
        section 11.3 of [RFC5420]. It is requested that the IANA makes 
        assignments from the Attribute Bit Flags defined in this 
        document. 

           This document introduces the following three new Attribute 
        Bit Flag: 

              - Bit number: TBD (recommended bit position 11) 

              - Defining RFC: this I-D 

              - Name of bit: Cost Collection Flag 
     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 12] 


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

              - Bit number: TBD (recommended bit position 12) 

              - Defining RFC: this I-D 

              - Name of bit: Latency Collection Flag 

         

              - Bit number: TBD (recommended bit position 13) 

              - Defining RFC: this I-D 

              - Name of bit: Latency Variation Flag 

         

        5.2. ROUTE_RECORD subobject 

           This document introduces the following three new RRO 
        subobject: 

                     Type       Name                        Reference 

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

                     TBD (35)   Cost subobject              This I-D 

                     TBD (36)   Latency subobject           This I-D 

                     TBD (37)   Latency Variation subobject This I-D 

     7.2. New RSVP error sub-code  

        For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the 
        following sub-code is defined. 
         
           Sub-code                              Value 
           --------                              ----- 
      
           Cost Recoding Rejected                To be assigned by IANA. 
                                                 Suggested Value: 105.   
         
           Latency Recoding Rejected             To be assigned by IANA. 
                                                 Suggested Value: 106.   
      
           Latency Variation Recoding Rejected   To be assigned by IANA. 
                                                 Suggested Value: 107.   
      

     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 13] 


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

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

     9.1. Normative References 

        [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate                 
                  Requirement Levels", BCP 14, RFC 2119, March 1997. 

        [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 
                  V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 
                  LSP Tunnels", RFC 3209, December 2001. 

        [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 
                  A. Ayyangarps, "Encoding of Attributes for MPLS LSP 
                  Establishment Using Resource Reservation Protocol 
                  Traffic Engineering (RSVP-TE)", RFC 5420, February 
                  2009. 

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

        [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. 
                  Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 
                  Engineering (TE) Metric Extensions", draft-ietf-isis-
                  te-metric-extensions, work in progress. 

     9.2. Informative References 

        [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 
                  "Generalized Multiprotocol Label Switching (GMPLS) 
                  User-Network Interface (UNI): Resource ReserVation 
                  Protocol-Traffic Engineering (RSVP-TE) Support for the 
                  Overlay Model", RFC 4208, October 2005. 

        [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 
                  Protocol (RSVP) -- Version 1 Message Processing 
                  Rules", RFC 2209, September 1997. 

        [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 
                  Networks", RFC 5920, July 2010. 

     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 14] 


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

     Authors' Addresses 

         
        Zafar Ali 
        Cisco Systems, Inc. 
        Email: zali@cisco.com 
      
        George Swallow 
        Cisco Systems, Inc. 
        swallow@cisco.com 
         
        Clarence Filsfils  
        Cisco Systems, Inc. 
        cfilsfil@cisco.com 
         
        Matt Hartley 
        Cisco Systems 
        Email: mhartley@cisco.com  
         
        Kenji Kumaki 
        KDDI Corporation 
        Email: ke-kumaki@kddi.com  
         
        Rudiger Kunze 
        Deutsche Telekom AG 
        Ruediger.Kunze@telekom.de  
         

         

     Ali, Swallow, Filsfils         Expires Dec. 2015         [Page 15]