Skip to main content

Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for signaling Objective Function and Metric Bound
draft-ali-ccamp-rc-objective-function-metric-bound-00

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
Last updated 2012-03-05
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ali-ccamp-rc-objective-function-metric-bound-00
CCAMP Working Group                                       Zafar Ali 
     Internet Draft                                       George Swallow 
     Intended status: Standard Track                   Clarence Filsfils 
     Expires: September 04, 2012                           Cisco Systems 
                                                          March 05, 2012 
                                                                             
                                         
      
          Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 
          extension for signaling Objective Function and Metric Bound 
           draft-ali-ccamp-rc-objective-function-metric-bound-00.txt
 

     Status of this Memo 

     This Internet-Draft is submitted in full conformance with the 
     provisions of BCP 78 and BCP 79. 

     Internet-Drafts are working documents of the Internet Engineering 
     Task Force (IETF).  Note that other groups may also distribute 
     working documents as Internet-Drafts.  The list of current 
     Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 

     Internet-Drafts are draft documents valid for a maximum of six 
     months and may be updated, replaced, or obsoleted by other 
     documents at any time.  It is inappropriate to use Internet-Drafts 
     as reference material or to cite them other than as "work in 
     progress." 

     This Internet-Draft will expire on September 04, 2012.  
         
     Copyright Notice 
         

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

      

      

      
      
      
      
     Ali, Swallow, Filsfils       Expires September 2012        [Page 1] 


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

     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. 

         
     Abstract 

     There are scenarios where an ingress node requests remote node(s)
     to perform route computation or expansion. In such cases, there is
     a need for the ingress node to convey the required objective 
     function for the path computation algorithm to the remote node 
     performing route computation or expansion. Similarly, there is a 
     need for the ingress node to indicate a TE metric bound for the 
     loose segment expanded by the remote node(s). This document defines 
     extensions to the RSVP-TE Protocol to allow an ingress node to 
     request the required objective function for the path computation, 
     as well as a metric bound to influence route computation decisions 
     at a remote node(s).  

     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 signaling extensions...................................4 
           2.1. Objective Function (OF) Subobject......................4 
              2.1.1. Minimum TE Metric Cost Path Objective Function....6 
              2.1.2. Minimum IGP Metric Cost Path Objective Function...6 
              2.1.3. Minimum Latency Path Objective Function...........6 
              2.1.4. Minimum Latency Variation Path Objective Functinn.6 
           2.2. Metric subobject.......................................7 
           2.3. Processing Rules for the OF Subobjects.................8 
           2.4. Processing Rules for the Metric subobject..............9 
      
      
     Ali, Swallow, Filsfils       Expires September 2012        [Page 2] 
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

     3. Security Considerations.......................................10 
     4. IANA Considerations...........................................10 
     5. Acknowledgments...............................................11 
     6. References....................................................11 
           6.1. Normative References..................................11 
           6.2. Informative References................................11 
      
     1. Introduction 

       As noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain 
       networks such as financial information networks (e.g. stock 
       market data providers), network performance criteria (e.g. 
       latency) are becoming as critical to data path selection as other 
       metrics. In other words, such networks often require finding a 
       path that is computed to minimize end-to-end latency. Even if 
       paths are computed to minimize some other TE metric, it is often 
       required to specify an acceptable latency bound as a constraint. 
       In summary, there is a requirement to be able to find an end-to-
       end path with different optimization criteria and with 
       performance bound(s) on the TE metric.  

       When the entire route for an LSP is computed at the ingress node, 
       the above-mentioned requirement can be met by a local decision at 
       that node. However, there are scenarios where partial or full 
       route computations are performed by remote nodes. The scenarios 
       include (but are not limited to): 

       .  LSPs with loose hops in the Explicit Route Object (ERO), e.g. 
          inter-domain LSPs.   

       .  Generalized Multi-Protocol Label Switching (GMPLS) User-
          Network Interface (UNI) where route computation may be 
          performed by the UNI-Network (server) node [RFC 4208]; 

       In these scenarios, there is a need for the ingress node to 
       convey TE metrics (e.g., IGP metric, TE metric, hop counts, 
       latency, etc.) to be optimized by the path computation algorithm 
       at the remote node performing route computation or expansion. 
       Similarly, there is a need for the ingress node to indicate a TE 
       metric bound for the loose segment being expanded by the remote 
       node.  

       [RFC5541] defines extensions to the Path Computation Element 
       communication Protocol (PCEP) to allow a Path Computation Client 
       (PCC) indicate in a path computation request the desired 
       objective function. [RFC5440] defines extension to the PCEP to 
       allow a PCC indicate in a path computation request a bound on 
       given TE metric(s). This draft defines a similar mechanism to 
      
      
     Ali, Swallow, Filsfils       Expires September 2012        [Page 3] 
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

        the RSVP-TE protocol to allow an ingress node to indicate in a 
        Path request the desired objective function at the loose hops. 
        The objective function is used by the node performing route 
        expansion to find the "best" candidate paths. The draft also 
        defines a RSVP-TE protocol mechanism to allow an ingress node to 
        indicate TE metric bound(s) associated with the route expansion 
        request.  

     2. RSVP-TE signaling extensions 

        This section defines RSVP-TE signaling extensions required to 
        address the above-mentioned requirements.  Two new ERO subobject 
        types, Objective Function (OF) and Metric, are defined for this 
        purpose. Their purpose is as follows.  

       .  OF subobject conveys a set of one or more specific 
          optimization criteria that MUST be followed in expanding route 
          of a TE-LSP in MultiProtocol Label Switching (MPLS) and GMPLS 
          networks.  

       .  Metric subobject indicates the bound on the path metric that 
          MUST NOT be exceeded for the loose segment to be considered as 
          acceptable by the ingress node.  

       The scope of the Metric and OF subobjects is the node performing 
       the expansion for loose ERO and the subsequent ERO subobject that 
       identifies an abstract node. The following subsection provides 
       the details.  

     2.1. Objective Function (OF) Subobject 

        A new ERO subobject type Objective Function (OF) is defined in 
        order for the ingress node to indicate the required objective 
        function on a loose hop. The ERO subobject type OF is optional. 
        It MAY be carried within an ERO object of RSVP-TE Path message. 
        The OF subobject has the following format: 

        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 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |L|    Type     |     Length    |    OF Code    |   Reserved    | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                                                               | 
       //              Optional TLV(s)                                // 
       |                                                               | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    
         

        The fields of OF subobject are defined as follows:  
      
      
     Ali, Swallow, Filsfils       Expires September 2012        [Page 4] 
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

           L bit: The L bit SHOULD be set, so that the subobject 
        represents a loose hop in the explicit route.  

           Type: The Type is to be assigned by IANA (suggested value: 
        66).  

           Length: The Length contains the total length of the subobject 
        in bytes, including the Type field, the Length field and the 
        length of the optional TLV(s). When there is no optional TLV, 
        the Length is 4. 

           OF Code (1 byte): The identifier of the objective function. 
        The following OF code values are suggested. These values are to 
        be assigned by IANA.   

           * OF code value 0 is reserved. 

           * OF code value 1 (to be assigned by IANA) is for Minimum TE 
             Metric Cost Path (MTMCP) OF defined in this document. See 
             definition of MTMCP OF in the following. 

           * OF code value 2 (to be assigned by IANA) is for Minimum 
             Interior Gateway Protocol (IGP) Metric Cost Path (MIMCP) 
             OF defined in this document. See definition of MTMCP OF 
             in the following.  

           * OF code value 3 (to be assigned by IANA) is for Minimum 
             Load Path (MLP) OF as defined in [RFC5541].  

           * OF code value 4 (to be assigned by IANA) is for Maximum 
             Residual Bandwidth Path (MBP) OF as defined in [RFC5541].  

           * OF code value 5 (to be assigned by IANA) is for Minimize 
             Aggregate Bandwidth Consumption (MBC) OF as defined in 
             [RFC5541].  

           * OF code value 6 (to be assigned by IANA) is for Minimize 
             the Load of the most loaded Link (MLL) OF as defined in 
             [RFC5541].  

           * OF code value 7 is skipped (to keep the objective function 
             code values consistent between [RFC5541] and this draft.  

           * OF code value 8 (to be assigned by IANA) is for Minimum 
             Latency Path (MLP) OF defined in this document. See 
             definition of MLP OF in the following. 

           * OF code value 9 (to be assigned by IANA) is for Minimum 
             Latency Variation Path (MLVP) OF defined in this document. 
             See definition of MLVP OF in the following.  

      
      
     Ali, Swallow, Filsfils       Expires September 2012        [Page 5] 
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

        Other objective functions may be defined in future.  

           Reserved (1 byte): This field MUST be set to zero on 
        transmission and MUST be ignored on receipt. 

           Optional TLVs may be defined in the future to encode 
        objective function parameters. 

     2.1.1. Minimum TE Metric Cost Path Objective Function 

        Minimum TE Metric Cost Path (MTMCP) OF is defined as an 
        Objective Function where a path is computed such that the sum of 
        the TE metric of the links along the path is minimized. In the 
        context of loose hop expansion, the ERO expanding node MUST try 
        to find a route such that the sum of the TE metric of the links 
        along the route is minimized.  
         
     2.1.2. Minimum IGP Metric Cost Path Objective Function 

        Minimum IGP Metric Cost Path (MIMCP) OF is defined as an 
        Objective Function where a path is computed such that the sum of 
        the IGP metric of the links along the path is minimized. In the 
        context of loose hop expansion, the ERO expanding node MUST try 
        to find a route such that the sum of the IGP metric of the links 
        along the route is minimized.  
         
     2.1.3. Minimum Latency Path Objective Function 

        Minimum Latency Path (MLP) OF is defined as an Objective 
        Function where a path is computed such that latency of the path 
        is minimized. In the context of loose hop expansion, the ERO 
        expanding node MUST try to find a route such that overall 
        latency of the loose hop is minimized.  
         
     2.1.4. Minimum Latency Variation Path Objective Function 

        Minimum Latency Variation Path (MLVP) OF is defined as an 
        Objective Function where a path is computed such that latency 
        variation in the path is minimized. In the context of loose hop 
        expansion, the ERO expanding node MUST try to find a route such 
        that overall latency variation of the loose hop is minimized.  
      

      
      
     Ali, Swallow, Filsfils       Expires September 2012        [Page 6] 
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

     2.2. Metric subobject 

        The ERO subobject type Metric is optional. It MAY be carried 
        within an ERO object of RSVP-TE Path message. This subobject has 
        the following format: 

        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 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |L|    Type     |     Length    | metric-type |     Reserved    | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                          metric-bound                         | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        The fields of the Metric subobject are defined as follows:  

           L bit: The L bit SHOULD be set, so that the subobject 
          represents a loose hop in the explicit route.  

           Type: The Type is to be assigned by IANA (suggested value: 
          67).  

           Length: The Length is 8.  

           Metric-type (8 bits):  Specifies the metric type associated 
           with the partial route expended by the node processing the 
           loose ERO. The following values are currently defined: 

                 *  T=1: cumulative IGP cost 

                 *  T=2: cumulative TE cost 

                 *  T=3: Hop Counts 

                 *  T=4: Cumulative Latency 

                 *  T=5: Cumulative Latency Variation 

           Reserved:  This field MUST be set to zero on transmission and 
        MUST be ignored on receipt. 

           Metric-bound (32 bits):  The metric-bound indicates an upper 
        bound for the path metric that MUST NOT be exceeded for the ERO 
        expending node to consider the computed path as acceptable. The 
        metric bound is encoded in 32 bits using IEEE floating point 
        format as defined in [IEEE.754.1985]).  

      
      
     Ali, Swallow, Filsfils       Expires September 2012        [Page 7] 
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

     2.3. Processing Rules for the OF Subobjects 

        The basic processing rules of an ERO are not altered. Please 
        refer to [RFC3209] for details.  
         
        The scope of the OF subobject is the previous ERO subobject that 
        identifies an abstract node, and the subsequent ERO subobject 
        that identifies an abstract node.  Multiple OF subobjects may be 
        present between any pair of abstract nodes.  
      
        The following conditions SHOULD result in Path Error with error 
        code "Routing Problem" and error subcode "Bad EXPLICIT_ROUTE 
        object": 
         
       .  If the first OF subobject is not preceded by a subobject 
          identifying the next hop.  
       .  If the OF subobject follows a subobject that does not have 
          the L-bit set.  
        
       If the processing node does not understand the OF subobject, it 
       SHOULD sends a PathErr with the error code "Routing Error" and    
       error value of "Bad Explicit Route Object" toward the sender 
       [RFC3209].  
        
       If the processing node understands the OF subobject and the ERO 
       passes the above mentioned sanity check and any other sanity 
       checks associated with other ERO subobjects local to the node, 
       the node takes the following actions:  
      
       .  If the node supports the requested OF(s), the node expands 
          the loose hop using the requested Objective Functions(s) as 
          minimization criterion (criteria) for computing the route to 
          the next abstract node. After processing, the OF subobjects 
          are removed from the ERO. The rest of the steps for the loose 
          ERO processing follow procedures outlined in [RFC3209].  
       .  If the node understands the OF subobject but does not support 
          any or all of the requested OF(s), it SHOULD send a Path Error 
          with error code "Routing Problem" and a new error subcode 
          "Unsupported Objective Function". The error subcode 
          "Unsupported Objective Function" for Path Error code "Routing 
          Problem" is to be assigned by IANA (Suggested Value: 107).  

      
      
     Ali, Swallow, Filsfils       Expires September 2012        [Page 8] 
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

       .  If the node understands the OF subobject and supports all of 
          the requested OF(s) but cannot perform route computation with 
          all objective functions considered together as optimization 
          criteria for the path computation, it SHOULD send a Path Error 
          with error code "Routing Problem" and a new error subcode 
          "Objective Function too complex". The error subcode "Objective 
          Function too complex" for Path Error code "Routing Problem" is 
          to be assigned by IANA (Suggested Value: 108). 
       .  If the objective function is supported but policy does not 
          permit applying it, the processing node SHOULD send a Path 
          Error with error code "Policy control failure" (value 2) and 
          subcode "objective function not allowed". The error subcode 
          "objective function not allowed" for Path Error code "Policy 
          control failure" is to be assigned by IANA (Suggested Value: 
          105).  
      
     2.4. Processing Rules for the Metric subobject 

        The basic processing rules of an ERO are not altered. Please 
        refer to [RFC3209] for details.  
         
        The scope of the Metric subobject is between the previous ERO 
        subobject that identifies an abstract node, and the subsequent 
        ERO subobject that identifies an abstract node.  Multiple Metric 
        subobjects may be present between any pair of abstract nodes.  
      
        The following conditions SHOULD result in Path Error with error 
        code "Routing Problem" and error subcode "Bad EXPLICIT_ROUTE 
        object": 
         
       .  If the first Metric subobject is not preceded by a subobject 
          identifying the next hop.  
       .  If the Metric subobject follows a subobject that does not 
          have the L-bit set.  
        
       If the processing node does not understand the Metric subobject, 
       it SHOULD sends a PathErr with the error code "Routing Error" and    
       error value of "Bad Explicit Route Object" toward the sender 
       [RFC3209].  
        

      
      
     Ali, Swallow, Filsfils       Expires September 2012        [Page 9] 
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

       If the processing node understands the Metric subobject and the 
       ERO passes the above mentioned sanity check and any other sanity 
       checks associated with other ERO subobjects local to the node, 
       the node takes the following actions:  
      
       .  For all the Metric subobject(s), the node expands the loose 
          hop such that the requested metric bound(s) are met for the 
          route between the two abstract nodes in the ERO. After 
          processing, the Metric subobjects are removed from the ERO. 
          The rest of the steps for the loose ERO processing follow 
          procedure outlined in [RFC3209].  
       .  If the node understands the Metric subobject but cannot find 
          a route to the next abstract node such that the requested 
          metric bound(s) can be satisfied, it SHOULD send a Path Error 
          with error code "Routing Problem" and a new error subcode "No 
          route available toward destination with the requested metric 
          bounds". The error subcode "No route available toward 
          destination with the requested metric bounds" for Path Error 
          code "Routing Problem" is to be assigned by IANA (Suggested 
          Value: 109).  
      
     3. Security Considerations 

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

     4. IANA Considerations 

        This document adds the following two new subobject of the 
        existing entry for ERO (20, EXPLICIT_ROUTE):  

        Value                         Description 

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

        TBA (suggest value: 66)       Objective Function (OF) subobject 

        TBA (suggest value: 67)       Metric subobject 

        These subobject may be present in the Explicit Route Object, but 
        not in the Route Record Object.  

      
      
     Ali, Swallow, Filsfils       Expires September 2012     [Page 10]
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

        OF Code values carried in OF subobject requires an IANA entry 
        with suggested values as defined in section 2.1.  

     5. Acknowledgments 

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

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

        [RFC3473] Berger, L., "Generalized Multi-Protocol Label 
                  Switching (GMPLS) Signaling Resource ReserVation 
                  Protocol-Traffic Engineering (RSVP-TE) Extensions", 
                  RFC 3473, January 2003.  

        [IEEE.754.1985] IEEE Standard 754, "Standard for Binary 
     Floating-Point Arithmetic", August 1985. 
      
     6.2. Informative References 

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

     Authors' Addresses 

         
        Zafar Ali 
        Cisco Systems, Inc. 
        Email: zali@cisco.com 
      
        George Swallow 
        Cisco Systems, Inc. 
        swallow@cisco.com 
      
      
     Ali, Swallow, Filsfils       Expires September 2012     [Page 11] 
      


     ID     draft-ali-ccamp-rc-objective-function-metric-bound-00.txt 
         

         
        Clarence Filsfils  
        Cisco Systems, Inc. 
        cfilsfil@cisco.com 
         

         

      
      
     Ali, Swallow, Filsfils       Expires September 2012      [Page 12]