Internet DRAFT - draft-ali-ccamp-rc-objective-function-metric-bound

draft-ali-ccamp-rc-objective-function-metric-bound










     CCAMP Working Group                                       Zafar Ali 
     Internet Draft                                       George Swallow 
     Intended status: Standard Track                   Clarence Filsfils 
     Expires: August 13, 2014                              Cisco Systems 
                                                             Luyuan Fang 
                                                               Microsoft 
                                                            Kenji Kumaki 
                                                        KDDI Corporation 
                                                          Ruediger Kunze 
                                                     Deutsche Telekom AG 
                                                      Daniele Ceccarelli 
                                                                Ericsson 
                                                              Xian Zhang 
                                                                  Huawei 
                                                       February 14, 2014  
                                                                             
                                         
      
          Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 
          Extension for Signaling Objective Function and Metric Bound 
           draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 


     Status of this Memo 

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

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

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

     This Internet-Draft will expire on August 13, 2014.  
         
     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       Expires April 2014        [Page 1] 






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

         
     Abstract 

     In particular networks such as those used by financial 
     institutions, network performance criteria such as latency are 
     becoming critical to data path selection.  However cost is still an 
     important consideration.  This leads to a situation where path 
     calculation involves multiple metrics and more complex objective 
     functions. 

     When using GMPLS control plane, there are many scenarios in which a 
     node may need to request a remote node to perform path computation 
     or expansion, like for example multi-domain LSP setup, Generalized 
     Multi-Protocol Label Switching (GMPLS) User-Network Interface (UNI) 
     or simply the utilization of a loose ERO in intra domain signaling. 
     In such cases, the node requesting the setup of an LSP needs to 
     convey the required objective function to the remote node, to 
     enable it to perform route computation in the desired fashion. 
     Similarly, there are cases where the ingress node needs to indicate 
     a TE metric bound for a loose segment that is expanded by a remote 
     node.  

     This document defines extensions to the RSVP-TE Protocol to allow 
     an ingress node to request the required objective function for the 
     route computation, as well as a metric bound to influence route 
     computation decisions at a remote node(s). 



      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 2] 
      






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

     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 
     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 Function.7 
           2.2. Metric subobject.......................................7 
           2.3. Processing Rules for the OF Subobjects.................8 
           2.4. Processing Rules for the Metric subobject..............9 
     3. Security Considerations.......................................11 
     4. IANA Considerations...........................................11 
     5. Acknowledgments...............................................12 
     6. References....................................................12 
           6.1. Normative References..................................12 
           6.2. Informative References................................13 
      
     1. Introduction 

       As noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain 
       networks such as financial information networks, performance 
       criteria such as latency are becoming critical to data path 
       selection along with other metrics. Such networks may require 
       selection of a path that minimizes end-to-end latency. Or a path 
       may need to be found that minimizes some other TE metric(s), 
       while subject to a latency bound. In summary, there is a 
       requirement to find end-to-end paths with different optimization 
       criteria while subjected to a metric bound. 

       When the entire route for an LSP is computed at the ingress node, 
       this 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), 
          including intra-domain LSPs.  
      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 3] 
      






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

       .  GMPLS-UNI where route computation may be performed by the 
          UNI-Network (server) node [RFC 4208]; 

       .  Multi domain LSP setup with per domain path computation;  

       In these scenarios, there is a need for the ingress node to 
       convey the optimization criteria (e.g., IGP cost, TE cost, hop 
       counts, latency, etc.) to be used for the path computation to the 
       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 a remote node.  

        This draft defines mechanisms for the RSVP-TE protocol allowing 
        an ingress node to indicate in a Path request the desired 
        objective function along with any associated TE metric bound(s). 
        The nodes performing route expansion use this information to 
        find the "best" candidate route. 

     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. Their 
        purpose is as follows.  

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

       .  Metric Bound subobject indicates the bound on the path metric 
          that needs to be observed 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 
        and its scope is limited to the node performing the expansion 
        for loose ERO and the subsequent ERO subobject that identifies 

      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 4] 
      






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

        an abstract node. For more details please refer to the 
        Processing Rules for the OF Subobjects section. 

        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    | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         

        The fields of OF subobject are defined as follows:  

           L bit: The L bit MUST be set to represent 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. The Length 
        of the subobject is 4. 

           OF Code (8 bits): 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 MTCP 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 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.  


      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 5]






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

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

        Other objective functions may be defined in future.  

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

     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.  
         
      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 6] 
      






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

     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.  
      
     2.2. Metric Bound subobject 

        The ERO subobject type Metric Bound (MB) is optional. It MAY be 
        carried within an ERO object of RSVP-TE Path message and its 
        scope is limited to the node performing the expansion for loose 
        ERO and the subsequent ERO subobject that identifies an abstract 
        node. It is possible to identify different Metric Bound 
        subobjects for different loose hops of the ERO to be expanded. 
        For more details please refer to the Processing Rules for the 
        Metric Bound Subobjects section. 

        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|B|    Reserved     | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       |                          metric-bound                         | 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        The fields of the Metric subobject are defined as follows:  

          L bit: The L bit is set if the subobject represents a loose 
          hop in the explicit route. If the bit is not set, the 
          subobject represents a strict hop in the explicit route. 
          Please note that use of MB subobject is also applicable to 
          strict hops, e.g., in selecting a component link within a 
          heterogeneous bundled TE link.  
           
          Type: The Type is to be assigned by IANA (suggested value: 
          67).  

           Length: The Length is 8.  

           Metric-type (6 bits):  Specifies the metric type associated 
           with the bound. The following values are currently defined: 

      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 7] 
      






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

                 *  T=1: cumulative IGP cost 

                 *  T=2: cumulative TE cost 

                 *  T=3: Hop Count 

                 *  T=4: Cumulative Latency 

                 *  T=5: Cumulative Latency Variation 

           B bit: Best-effort bit. When the best-effort (B) bit is set, 
           it means that the ingress node allows loose hop expansion 
           that does not meeting the MB requirement. When the best-
           effort (B) bit is not set, it means that the MB MUST be 
           observed.  

           Reserved (9 bits): 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 
           metric bound for the loose hop. The metric bound is encoded 
           in 32 bits using IEEE floating point format as defined in 
           [IEEE.754.1985]). When it indicates a time value (i.e. 
           Latency or Latency Variation) it is expressed in 
           milliseconds. 

     2.3. Processing rules 

     2.3.1. Processing Rules for the OF Subobjects 

        A single OF subobjects SHOULD be used between a pair of abstract 
        nodes in ERO. Same OF SHOULD be identified for each hop 
        expansion.  

        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. However, only first 
        OF subobject is analyzed and others are ignored.  
      
        The following conditions SHOULD result in Path Error with error 
        code "Routing Problem" and error subcode "Bad EXPLICIT_ROUTE 
        object": 
      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 8] 
      






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

         
       .  If the first OF subobject is not preceded by an ERO subobject 
          identifying the next hop.  
       .  If the OF subobject follows an ERO subobject identifying the 
          next hop that does not have the L-bit set.  
      
       If the processing node does not understand the OF subobject, it 
       SHOULD send 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, the node expands the 
          loose hop using the requested OF as optimization criterion 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 
          the requested OF, 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.  
       .  If the OF 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.  
     2.3.2. Processing Rules for the MB subobject 

          Multiple Metric Bound subobjects MAY be indicated for each hop 
          to be expanded and MUST be placed after each abstract node 
          subobject. Different Metric Bounds MAY be identified for each 
          hop expansion. 


      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 9] 
      






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

        The basic processing rules of an ERO are not altered. Please 
        refer to [RFC3209] for details.  
         
        The scope of the MB subobject is between the previous ERO 
        subobject that identifies an abstract node, and the subsequent 
        ERO subobject that identifies an abstract node.  Multiple MB 
        subobjects may be present between any pair of abstract nodes.  
        
       If the processing node does not understand the MB subobject, it 
       SHOULD send 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 MB 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 MB subobject(s), the node expands the ERO 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 ERO processing follow procedure outlined in 
          [RFC3209].  
       .  If the node understands the MB subobject but cannot find a 
          route to the next abstract node such that the requested metric 
          bound(s) can be satisfied and the best-effort (B) bit is not 
          set, 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 (See IANA section for details).  
       .  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 and the best-effort (B) bit 
          is set, it SHOULD send a Path Error message with error code 
          "Notify Error" and a new error subcode "Route not matching the 
          requested metric bounds" is to be assigned by IANA (See IANA 
          section for details).   


      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 10] 
      






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

       .  The ERO expanding node SHOULD respect the Metric Bound 
          constraints in realizing any segment recovery procedure to 
          change the route of the segment expanded by the said node.  If 
          best-effort (B) bit is set and the new recovery segment 
          violates the Metric Bound constraints, the ERO expanding 
          SHOULD send a Path Error message with error code "Notify 
          Error" and a new error subcode "Route not matching the 
          requested metric bounds" is to be assigned by IANA (See IANA 
          section for details).  
        
     3. Security Considerations 

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

     4. IANA Considerations 

     4.1. ERO Subobject 

        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.  

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

     4.2. New RSVP error sub-code  

        For Error Code = 24 "Routing Problem" (see [RFC2205]) the 
        following sub-code is defined. 
         
           Sub-code                              Value 
           --------                              ----- 
      
           No route available toward destination To be assigned by IANA. 
      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 11] 
      






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

           with the requested metric bounds       Suggested Value: TBA.   
      
        For Error Code = 25 "Notify Error" (see [RFC2205]) the following 
        sub-code is defined. 
         
           Sub-code                              Value 
           --------                              ----- 
      
           Route not matching the requested      To be assigned by IANA. 
           metric bounds                         Suggested Value: TBA.   
      

     5. Acknowledgments 

        Authors would like to thank Matt Hartley, Ori Gerstel, Gabriele 
        Maria Galimberti, 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. 
      
        [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. 

      
      




      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 12] 
      






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

     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. 

        [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 
                  Computation Element (PCE) Communication Protocol 
                  (PCEP)", RFC 5440, March 2009. 

        [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 
                  Objective Functions in the Path Computation Element 
                  Communication Protocol (PCEP)", RFC 5541, June 2009. 

        [ID-SERVICE-AWARE] D. Dhody, V. Manral, Z. Ali, G. Swallow, K. 
                  Kumaki, " Extensions to the Path Computation Element 
                  Communication Protocol (PCEP) to compute service aware 
                  Label Switched Path (LSP)", draft-ietf-pce-pcep-
                  service-aware, work in progress.  

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

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

         

     Authors' Addresses 

         
        Zafar Ali 
        Cisco Systems. 
        Email: zali@cisco.com 
      
        George Swallow 
        Cisco Systems. 
        swallow@cisco.com 
         
        Clarence Filsfils  

      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 13] 
      






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

        Cisco Systems. 
        cfilsfil@cisco.com 
         
        Luyuan Fang 
        Microsoft 
        lufang@microsoft.com  
         
        Kenji Kumaki 
        KDDI Corporation 
        Email: ke-kumaki@kddi.com  
         
        Rudiger Kunze 
        Deutsche Telekom AG 
        Ruediger.Kunze@telekom.de  
         
        Daniele Ceccarelli 
        Ericsson 
        Email: daniele.ceccarelli@ericsson.com 
         
        Xian Zhang 
        Huawei Technologies 
        Email: zhang.xian@huawei.com 
         
      























      
      
     Ali, Swallow, Filsfils      Expires August 2014          [Page 14]