Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric
draft-ietf-tewg-te-metric-igp-02

Francois Le Faucheur 
                                                           Ramesh Uppili 
                                                     Cisco Systems, Inc.  
                                                                         
                                                          Alain Vedrenne 
                                                           Pierre Merckx 
                                                                  Equant 
                                                                         
                                                          Thomas Telkamp 
                                                         Global Crossing 
                                                                         
IETF Internet Draft 
Expires: March, 2003                                                
Document: draft-ietf-tewg-te-metric-igp-02.txt          September, 2002 
 
 
 
       Use of Interior Gateway Protocol (IGP) Metric as a second  
                    MPLS Traffic Engineering Metric 
 
 
 
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026. Internet-Drafts are 
   Working documents of the Internet Engineering Task Force (IETF), its 
   areas, and its working groups.  Note that other groups may also 
   distribute working documents as Internet-Drafts. 
    
   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." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
Abstract 
    
   This document describes a common practice on how the existing metric 
   of Interior Gateway Protocols (IGP) can be used as an alternative 
   metric to the Traffic Engineering (TE) metric for Constraint Based 
   Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering 
   tunnels. This effectively results in the ability to perform 
   Constraint Based Routing with optimization of one metric (e.g. link 
   bandwidth) for some Traffic Engineering tunnels (e.g. Data Trunks) 
   while optimizing another metric (e.g. propagation delay) for some 
   other tunnels with different requirements (e.g. Voice Trunks). 
    
  
Le Faucheur, et. al                                                  1 
 

 
                    IGP Metric as second TE Metric      September 2002 
 
   No protocol extensions or modifications are required. This text 
   documents current router implementations and deployment practices.  
    
    
1.      Introduction 
 
   Interior Gateway Protocol (IGP) routing protocols (OSPF and IS-IS) 
   as well as MultiProtocol Label Switching (MPLS) signaling protocols 
   (RSVP-TE and CR-LDP) have been extended (as specified in [ISIS-TE], 
   [OSPF-TE], [RSVP-TE] and [CR-LDP]) in order to support the Traffic 
   Engineering (TE) functionality as defined in [TE-REQ]. 
    
   These IGP routing protocol extensions currently include 
   advertisement of a single additional MPLS TE metric to be used for 
   Constraint Based Routing of TE tunnels. 
    
   However, the objective of traffic engineering is to optimize the use 
   and the performance of the network. So it seems relevant that TE 
   tunnel placement may be optimized according to different 
   optimization criteria. For example, some Service Providers want to 
   perform traffic engineering of different classes of service 
   separately so that each class of Service is transported on a 
   different TE tunnel. One example motivation for doing so is to apply 
   different fast restoration policies to the different classes of 
   service. Another example motivation is to take advantage of separate 
   Constraint Based Routing in order to meet the different Quality of 
   Service (QoS) objectives of each Class of Service. Depending on QoS 
   objectives one may require either (a) enforcement by Constraint 
   Based Routing of different bandwidth constraints for the different 
   classes of service as defined in [DS-TE], or (b) optimizing on a 
   different metric during Constraint Based Routing or (c) both. This 
   document discusses how optimizing on a different metric can be 
   achieved during Constraint Based Routing. 
    
   The most common scenario for a different metric calls for 
   optimization of a metric reflecting delay (mainly propagation delay) 
   when Constraint Based Routing TE Label Switched Paths (LSPs) that 
   will be transporting voice, while optimizing a more usual metric 
   (e.g. reflecting link bandwidth) when Constraint Based Routing TE 
   LSPs that will be transporting data. 
    
   Additional IGP protocol extensions could be defined so that multiple 
   TE metrics could be advertised in the IGP (as proposed for example 
   in [METRICS]) and would thus be available to Constraint Based 
   Routing in order to optimize on a different metric. However this 
   document describes how optimizing on a different metric can be 
   achieved today by existing implementations and deployments, without 
   any additional IGP extensions beyond [ISIS-TE] and [OSPF-TE], by 
   effectively using the IGP metric as a "second" TE metric. 
    
    
2.      Common Practice 
 
 Le Faucheur et. al                                                  2 
 

 
                    IGP Metric as second TE Metric      September 2002 
 
    
   In current MPLS TE deployments, network administrators often want 
   Constraint Based Routing of TE LSPs carrying data traffic to be 
   based on the same metric as the metric used for Shortest Path 
   Routing. Where this is the case, this practice allows the Constraint 
   Based Routing algorithm running on the Head-End LSR to use the IGP 
   metric advertised in the IGP to compute paths for data TE LSPs 
   instead of the advertised TE metric. The TE metric can then be used 
   to convey another metric (e.g. a delay-based metric) which can be 
   used by the Constraint Based Routing algorithm on the Head-End LSR 
   to compute path for the TE LSPs with different requirements (e.g. 
   Voice TE LSP). 
    
   In some networks, network administrators configure the IGP metric to 
   a value factoring the link propagation delay. In that case, this 
   practice allows the Constraint Based Routing algorithm running on 
   the Head-End LSR to use the IGP metric advertised in the IGP to 
   compute paths for delay-sensitive TE LSPs (e.g. Voice TE LSPs) 
   instead of the advertised TE metric. The TE metric can then be used 
   to convey another metric (e.g. bandwidth based metric) which can be 
   used by the Constraint Based Routing algorithm to compute paths for 
   the data TE LSPs. 
    
   More generally, the TE metric can be used to carry any arbitrary 
   metric that may be useful for Constraint Based Routing of the set of 
   LSPs which need optimization on another metric than the IGP metric. 
    
2.1.    Head-End LSR Implementation Practice 
    
   A Head-End LSR implements the current practice by:  
    
   (i)    Allowing configuration, for each TE LSP to be routed, of 
          whether the IGP metric or the TE metric is to be used by the 
          Constraint Based Routing algorithm. 
    
   (ii)   Enabling the Constraint Based Routing algorithm to make use 
          of either the TE metric or the IGP metric, depending on the 
          above configuration for the considered TE-LSP 
    
2.2.    Network Deployment Practice 
    
   A Service Provider deploys this practice by: 
    
   (i)    Configuring, on every relevant link, the TE metric to reflect 
          whatever  metric is appropriate (e.g. delay-based metric) for 
          Constraint Based Routing of some LSPs as an alternative 
          metric to the IGP metric 
           
   (ii)   Configuring, for every TE LSP, whether this LSP is to be 
          constraint based routed according to the TE metric or IGP 
          metric 
    
 
 Le Faucheur et. al                                                  3 
 

 
                    IGP Metric as second TE Metric      September 2002 
 
2.3.    Constraints 
 
   The practice described in this document has the following 
   constraints: 
    
   (i)    it only allows TE tunnels to be routed on either of two 
          metrics (i.e. it cannot allow TE tunnels to be routed on one 
          of three, or more, metrics). Extensions (for example such as 
          those proposed in [METRICS]) could be defined in the future 
          if necessary to relax this constraints, but this is outside 
          the scope of this document. 
           
   (ii)   it can only be used where the IGP metric is appropriate as 
          one of the two metrics to be used for constraint based 
          routing (i.e. it cannot allow TE tunnels to be routed on 
          either of two metrics while allowing IGP SPF to be based on a 
          third metric). Extensions (for example such as those proposed 
          in [METRICS]) could be defined in the future if necessary to 
          relax this constraints, but this is outside the scope of this 
          document. 
           
   (iii)  it can only be used on links which support an IGP adjacency 
          so that an IGP metric is indeed advertised for the link. For 
          example, this practice can not be used on Forwarding 
          Adjacencies (see [LSP-HIER]). 
    
   Note that, as with [METRICS], this practice does not recommend that 
   the TE metric and the IGP metric be used simultaneously during path 
   computation for a given LSP. This is known to be an NP-complete 
   problem. 
 
2.4.    Interoperability 
    
   Where path computation is entirely performed by the Head-End (e.g. 
   intra-area operations with path computation on Head-end), this 
   practice does not raise any interoperability issue among LSRs since 
   the use of one metric or the other is a matter purely local to the 
   Head-End LSR. 
    
   Where path computation involves another component than the Head-End 
   (e.g. with inter-area operations where path computation is shared 
   between the Head-End and Area Boundary Routers or a Path Computation 
   Server), this practice requires that which metric to optimize on, be 
   signaled along with the other constraints (bandwidth, affinity) for 
   the LSP. See [PATH-COMP] for an example proposal on how to signal 
   which metric to optimize, to another component involved in path 
   computation when RSVP-TE is used as the protocol to signal path 
   computation information. 
    
    
3.      Migration Considerations 
    
 
 Le Faucheur et. al                                                  4 
 

 
                    IGP Metric as second TE Metric      September 2002 
 
   Service Providers need to consider how to migrate from the current 
   implementation to the new one supporting this practice.  
    
   Although the head-end routers act independently from each other, 
   some migration scenarios may require that all head-end routers be 
   upgraded to the new implementation to avoid any disruption on 
   existing TE-LSPs before two metrics can effectively be used by TE. 
   The reason is that routers with current implementation are expected 
   to always use the TE metric for Constraint Based Routing of all 
   tunnels; so when the TE metric is reconfigured to reflect the 
   "second metric" (say to a delay-based metric) on links in the 
   network, then all TE-LSPs would get routed based on the "second 
   metric" metric, while the intent may be that only the TE-LSPs 
   explicitly configured so should be routed based on the "second 
   metric". 
    
   A possible migration scenario would look like this: 
    
        1) upgrade software on all head-end routers in the network to 
           support this practice. 
            
        2) change the TE-LSPs configuration on the head-end routers to 
           use the IGP metric (e.g. bandwidth-based) for Constraint 
           Based Routing rather than the TE metric. 
            
        3) configure TE metric on the links to reflect the "second 
           metric" (e.g. delay-based). 
            
        4) modify the LSP configuration of the subset of TE-LSPs which 
           need to be Constraint Based routed using the "second metric" 
           (e.g. delay-based), and/or create new TE-LSPs with such a 
           configuration. 
    
   It is desirable that step 2 is non-disruptive (i.e. the routing of a 
   LSP will not be affected in any way, and the data transmission will 
   not be interrupted) by the change of LSP configuration to use "IGP 
   metric" as long as the actual value of the "IGP metric" and "TE 
   metric" are equal on every link at the time of LSP reconfiguration 
   (as would be the case at step 2 in migration scenario above which 
   assumed that TE metric was initially equal to IGP metric).  
    
    
4.      Security Considerations 
    
   The practice described in this document does not raise specific 
   security issues beyond those of existing TE. Those are discussed in 
   the respective security sections of [TE-REQ], [RSVP-TE] and [CR-
   LDP]. 
    
    
5.      Acknowledgment 
    
 
 Le Faucheur et. al                                                  5 
 

 
                    IGP Metric as second TE Metric      September 2002 
 
   This document has benefited from discussion with Jean-Philippe 
   Vasseur. 
    
 
6.      Normative References 
    
   [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 
   MPLS, RFC2702, September 1999. 
    
   [OSPF-TE] Katz et al, Traffic Engineering Extensions to OSPF Version 
   2, draft-katz-yeung-ospf-traffic-07.txt, August 2002.  
    
   [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
   ietf-isis-traffic-04.txt, August 2001. 
    
   [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 
   Tunnels", RFC3209, December 2001. 
    
   [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 
   RFC3212, January 2002 
    
    
7.      Informative References 
    
   [METRICS] Fedyk et al, "Multiple Metrics for Traffic Engineering 
   with IS-IS and OSPF", draft-fedyk-isis-ospf-te-metrics-01.txt, 
   November 2000. 
    
   [DIFF-TE] Le Faucheur et al, "Requirements for support of Diff-Serv-
   aware MPLS Traffic Engineering", draft-ietf-tewg-diff-te-reqts-
   05.txt, June 2002. 
    
   [PATH-COMP] Vasseur et al, "RSVP Path computation request and reply 
   messages",  draft-vasseur-mpls-path-computation-rsvp-03.txt, June 
   2002. 
    
   [LSP-HIER] Kompella et al, "LSP Hierarchy with Generalized MPLS TE", 
   draft-ietf-mpls-lsp-hierarchy-07.txt, June 2002. 
    
    
Authors' Address: 
    
   Francois Le Faucheur 
   Cisco Systems, Inc. 
   Village d'Entreprise Green Side - Batiment T3 
   400, Avenue de Roumanille 
   06410 Biot-Sophia Antipolis 
   France 
   Phone: +33 4 97 23 26 19 
   Email: flefauch@cisco.com 
    
   Ramesh Uppili  
 
 Le Faucheur et. al                                                  6 
 

 
                    IGP Metric as second TE Metric      September 2002 
 
   Cisco Systems, Inc. 
   300 Apollo Drive 
   Chelmsford, Massachussets 01824 
   USA 
   Phone: +1 978 244-4949 
   Email: ruppili@cisco.com 
    
   Alain Vedrenne 
   EQUANT 
   400 Galleria Parkway 
   Atlanta, Georgia 30339 
   USA 
   Phone: +1 (678)-346-3466  
   Email: alain.vedrenne@equant.com 
    
   Pierre Merckx 
   EQUANT 
   1041 route des Dolines - BP 347 
   06906 SOPHIA ANTIPOLIS Cedex 
   FRANCE 
   Phone: +33 (0)492 96 6454 
   Email: pierre.merckx@equant.com 
    
   Thomas Telkamp 
   Global Crossing 
   Oudkerkhof 51 
   3512 GJ Utrecht 
   The Netherlands  
   Phone: +31 30 238 1250  
   E-mail: telkamp@gblx.net 
    

 
 Le Faucheur et. al                                                  7