[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
                                                               S. Ganti
                                                             N. Seddigh
                                                               B. Nandy
                                                        Tropic Networks

                                                            N. Harrison

INTERNET DRAFT                                             S. Choudhury
Internet Engineering Task Force                                 Marconi
Traffic Engineering Working Group
Expires August, 2002                                     February, 2002

       DS-TE Requirements for Support of multiple-COS on an E-LSP

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-

   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

   The  list  of  Internet-Draft  Shadow  Directories can be accessed at

   Distribution of this memo is unlimited.


   The  current  DS-TE  requirements  document  [DSTEREQ]   focuses   on
   solutions that enable carrying a single Class of Service on an LSP.

   This document extends the work in [DSTEREQ] by motivating the need to
   support a DS-TE solution that enables multiple COS on an  E-LSP.  The
   document further defines the requirements for such an approach.

   The  requirements  are  developed such that this approach would be an
   optional extension to the existing DS-TE.

1.0 Introduction

   Recently there have emerged a number of initiatives with the goal  of
   improving  on  the  current best-effort service model delivered by IP
   networks. Traffic Engineering (TE) is one key element in the tool-kit
   to  deliver  such improved service. Initial TE solutions [TEREQ] used
   MPLS (Multi-Protocol Label Switching) [MPLSARCH] to steer best-effort
   traffic  away from shortest-path congested links. Such an approach is
   intended to distribute load across the network  and  improve  overall
   network performance.

   At  the  same time, DiffServ [DSARCH] has defined a number of traffic
   conditioning mechanisms and Per-Hop-Behaviour which can  be  combined
   to  provide  QoS  assurance  and  multiple  classes  of service in IP
   networks. The Diff-Serv approach has recently been extended to enable
   multiple  classes  of  service  to  be  carried  over  a  single  LSP
   [DIFFMPLS].  [DIFFMPLS] defines two types of LSPs to support DiffServ
   over   MPLS:   E-LSPs  (EXP-inferred-LSPs)  and  L-LSPs  (Label-Only-
   Inferred-LSPs). The L-LSP approach is  intended  to  carry  a  single
   class  of  traffic  per  LSP.  LSRs  use per-LSP state information to
   determine the PHB to apply against packets of an LSP.   E-LSPs  allow
   multiple  classes of traffic to be carried over a single LSP. In this
   case, the MPLS Label-Stack-Entry EXP bits  indicate  the  PHB  to  be
   applied against a particular packet.  DS-TE using E-LSPs.

   DiffServ-Aware  Traffic  Engineering  (DS-TE)  combines  Diffserv and
   Traffic Engineering  in  an  effort  to  provide  end-to-end  service
   guarantees  within  an  MPLS  network.  Incoming traffic is mapped to
   paths within the network that satisfy certain engineering constraints
   on a per-class basis.

   The  current  DS-TE  Requirements  document  [DSTEREQ] focuses on the
   requirements to support carrying a single class of traffic on LSPs.

   This document expands on [DSTEREQ] to discuss the DS-TE  requirements
   to carry multiple classes of traffic on an LSP. We also elaborate and
   consider various application scenarios where it may be  desirable  to
   support  DS-TE  with  multiple  classes  of  traffic on an LSP. It is
   understood that not all DS-TE networks will want to support  multiple
   classes  of  traffic per LSP. As such the requirements defined herein
   are intended to be optional and to co-exist with [DSTEREQ].

   The terms class and OA (ordered aggregate) are used  inter-changeably
   throughout this document.

2.0 Current DS-TE Requirements

   [DSTEREQ]  presents  the service provider requirements for support of
   Diff-serv aware traffic engineering using the LSPs.  While  [DSTEREQ]
   discusses  requirements  for  a  network  with  multiple  classes  of
   service, it focuses on using LSPs that  carry  essentially  a  single
   class  of service.  In certain parts of the document it discusses use
   of LSP with multiple classes of service however, for the purposes  of
   TE  (route  advertisements,  MPLS  signalling  path  computation  and
   admission control), these multiple classes are treated  as  a  single

   Five  possible  options exist in relation to the usage of  L-LSPs and
   E-LSPs in a general DS-TE framework:

     a)  Using E-LSPs to carry traffic entirely from a single OA
     b)  Using E-LSPs to carry traffic for multiple OAs all sharing a
         single set of traffic parameters and with single set of
         pre-emption/protection attributes
     c)  Using E-LSPs to carry traffic from multiple OAs, each with
         their own set of traffic parameters but with single set of
         pre-emption/protection attributes.
     d)  Using E-LSPs to carry traffic from multiple OAs, each with
         their own set of traffic parameters and pre-emption/protection
     e)  Using L-LSP to carry traffic from a single OA

   [DS-TE-REQ]  describes  mapping  of  single-OA  traffic  on  to  MPLS
   tunnnels  using  options  (a) and (e). It allows support for carrying
   multiple-OA traffic using option (b) on an aggregate basis only.  i.e
   with  a  single set of constraints and thus to treat all the OAs as a
   single class for the purposes of TE.  The document does  not  discuss
   options (c) and (d).

   At the current time, it does not appear that there is any interest in
   supporting option (d) as pre-emption priorities apply to  the  entire
   LSP and not to a subset of traffic on that LSP.

   This  document  therefore presents the requirements to support option
   (c) above as an extension to [DSTEREQ]. The following section focuses
   on various application scenarios where it may be desirable to utilize
   the approach of (c).

3.0 DS-TE Application Scenarios - Multiple COS per LSP

   There are  a  number  of  good  reasons  why  service  providers  are
   interested  in using DS-TE to carry multiple classes of service on an
   LSP. The key reaons can be summarized as follows:

     a)  Ability to carry multiple classes of a single customer
         traffic on the same LSP
     b)  Reduction in number of LSPs in the network (one LSP instead
         of "x" LSPs to carry "x"classes)
     c)  One DS traffic pipe that is easy to manage, apply path protection
         and restoration capabilities.

   The following are application scenarios where E-LSPs can be used in a
   DS-TE  framework to carry multiple classes of traffic each with their
   own set of BW constraints.

3.1 Using E-LSPs based on aggregate traffic requirements:

   An MPLS/IP network may desire to carry its VoIP data  and  signalling
   on  the  same  LSP  yet  treat the two traffic types as two different
   classes. For example, it may want to map its VoIP data to be  treated
   by  the  EF PHB and the VoIP signaling to be treated by the AF1x PHB.
   In such cases, the provider will likely not want  to  send  the  VoIP
   data and signaling on different LSPs as they may have different delay

   It can be argued that if the ratio of two different traffic types  is
   known/constant  then  it can be carried on multiple OAs but signalled
   with  a  single  traffic  parameter  and  advertised  with  a  single
   advertisement.   However,  such  a  scheme  is  extremely inflexible.
   Applications continually evolve as may the ratio  of  traffic  mixes.
   Thus,  it  is unwise to embed assumptions about application behaviour
   in the DS-TE solutions.

3.2 Using E-LSPs with multiple class bandwidth requirements

   A second example involves the use of Layer 2 VPNs.  In this  context,
   service  providers  in  the  Metro  space  are looking to provide TLS
   (Transparent LAN) services. The SP may provide Layer 2 VPNs  for  its
   end customers where the key SLAs revolve around availability and QoS.
   In such cases, the SLA may specify a single protection level for  the
   entire  customer  aggregate  while  specifying  multiple  classes  of
   service within the VPN aggregate. In such networks, sending different
   classes  of  service  on different LSPs will immensely complicate the
   ability to offer robust and measurable availability and QoS  SLAs  to
   such  customers.  Hence  it  is desirable to carry all the customer's
   classes of traffic on a  single LSP  and  yet  to  treat  each  class

   A  third  example  relates to an application where a service provider
   wishes to provide bandwidth borrowing between the  different  classes
   of traffic for a specific customer.  Thus, service providers may want
   to provide SLA gurantees for each of the classes carried  in  the  E-
   LSP.  In  addition,  at the same time, the provider may wish to apply
   queuing technology that allows bandwidth borrowing between the OAs of
   a  customer.  Thus,  if  a  customer  is  not  using his allocated AF
   capacity, he may wish to allow his BE traffic to  use  that  capacity
   that he has purchased from the service provider.

3.3 Using E-LSPs to reduce number of LSPs in the network

   A fourth example relates to path protection and restoration which are
   2 key requirements in next generation IP networks.  Sending a  single
   customer's traffic on multiple LSPs causes a larger number of LSPs in
   the network. It also causes issues with ensuring that the SONET  like
   restoration  times  are met due to the sheer volume of LSPs that have
   to be resignalled or redialed when links go down.   These  mechanisms
   are more easily applied to a single LSP than to a group of LSPs.

   Yet  another  application  scenario, as a fifth example could be, the
   case of a small service provider with a simple network topology and a
   limited  set  of service classes. Such a provider could be interested
   in limited DS-TE capabilities (i.e. simple aggregate load balancing).
   In  this  case,  a  simple path computation algorithm that routes all
   classes together can be used to select a single LSP (e.g. a  shortest
   path  applied  on  the  pruned  network). Limiting each LSP to only a
   single OA would, at minimum, double the number of LSPs in the network
   - which may be highly undesirable for the SP.

   Another  key  benefit  of E-LSPs has to do with scalability. L-LSP or
   single OA per E-LSP will cause the number of LSPs in the  network  to
   increase  by  a factor of at least two and in some cases, three, four
   or larger.  The number of LSPs is a scalability concern for a  number
   of  reasons.  Firstly,  it increases the time required during hitless
   restart. Secondly, it is of concern for RSVP state management.Another
   important  advantage  of E-LSPs is in the area of network maintenance
   and  administration.   When  trouble-shooting  issues  related  to  a
   customer's  traffic, it is easier for the network operator to examine
   a single LSP instead of multiple LSPs.

4.0 Technical Requirements To Support DS-TE with multiple COS per LSP

   In general, the requirements to support DS-TE with multiple  COS  can
   be considered as extensions to the existing requirements.  To support
   such an approach, the following are required:

      (i)  IGP extensions to advertise reserved or available
           bandwidth on a per-OA, PSC or per-class or per-ClassType basis for
           each link.
     (ii)  A path computation algorithm that computes a path at the LER
    (iii)  Extensions to allow signaling of per-class parameters
           within an E-LSP
     (iv)  A Pre-emption priority (setup and hold) which is applied
           to the whole E-LSP together (not per-OA).
      (v)  Admission Control is applied per-class per-link when the E-LSP
           is signalled.
     (vi)  Traffic Conditioning is applied at the LER against traffic
           mapped to the E-LSP.
    (vii)  EXP bits are used to signal the PHB treatment
           for individual packets within the E-LSP
    (viii) Diffserv PHB mechanisms are used in LSR routers
           to differentially treat the traffic within a
           single E-LSP.

   There are no new requirements for IGP protocol extensions other  than
   the  one  already  described  in the document Protocol extensions for
   support of DS-TE [DSPROTO].

   Requirement  (ii)   is   typically   satisfied   by   a   proprietary
   implementation  by vendor devices. When setting up an E-LSP, the path
   is computed based on the available resources in the network  and  the
   path  that  fits  best  the  resource  requirements  of  all  the OAs
   together, i.e, the  path  computation  procedure  has  to  a  take  a
   bandwidth  vector  of all OAs, bandwidth vector of all available link
   bandwidths per-OA and compute the path based on certain  constraints.

   Requirement  (iii)  is  discussed  in  section  4.1 below. The per-OA
   signaling is needed for proper bandwidth accounting and to  advertise
   available resources in the node to the network.

   Requirement (iv), (v), (vi), (vii) and (viii) are currently addressed
   by the mechanisms specified in [DIFF-MPLS].

4.1 LSP Signalling Extensions

   The current Diffserv-MPLS extensions  allow  only  a  single  set  of
   traffic  parameters  to  be  signalled per LSP. e.g in RSVP-TE, it is
   allowable to signal only  a  single  Tspec.  To  support  E-LSP,  the
   signalling  protocols  need  to be extended to allow specification of
   multiple traffic parameters. Further, there needs to be  a  means  of
   mapping these traffic parameters to an OA, PSC or class.

   There  exist two current proposals to address this issue: [GANTI] and

   This document uses the terms BA, OA, PSC, E-LSP, L-LSP,  and  PHB  as
   they are defined in [DIFF-MPLS] and [DIFFTERM].

5.0 Other Requirements

   The following are additional requirements for solutions to support
   multiple COS on DS-TE:

     (i) Any protocol extensions should be optional.
    (ii) The solution should be an extension of the current [DSTEREQ]
   (iii) The solution should be backwards compatible with DS-TE, TE
         and Diffserv
    (iv) It should not introduce major scalability issues above and
         beyond what is introduced by the current DS-TE
     (v) It should allow dynamic adjustment of parameters for the
         LSR's scheduler
    (vi) It should satisfy the application scenarios outlined in [DSTEREQ]

6.0  Security Considerations

   This document does not introduce any new security issues beyond those
   inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms
   proposed for those technologies.

7.0 References

   [TEREQ]     Awduche D et al, "Requirements for Traffic Engineering
               Over MPLS", RFC 2702, January 2001

   [DIFFMPLS]  Rosen E et al, "MPLS Support of Differentiated Services"
               draft-ietf-mpls-diff-ext-08.txt, February 2001.

   [DIFFTERM]  Grossman D, "New Terminology for Diffserv", Internet
               Draft, draft-ietf-diffserv-new-terms-04.txt, March 2001

   [RSVP-TE]   Awduche et al, "RSVP-TE: Extensions to RSVP for
               LSP Tunnels", Internet draft,
               <draft-ietf-mpls-rsvp-lsp-tunnel-08.txt>, February 2001

   [CR-LDP]    Jamoussi et al, "Constraint-Based LSP Setup using LDP",
               Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
               February 2001.

   [PHBID]     Brim S et al, "Per Hop Behaviour Identification Code",
               RFC 2836, May 2000.

   [MPLSARCH]  Rosen E et al, "Multi-Protocol Label Switching
               Architecture", RFC 3031, January 2001

   [DSTEREQ]   Le Faucheur F et al, "Requirements for support of Diff-
               Serv-aware MPLS Traffic Engineering",
               draft-ietf-tewg-diff-te-reqts-03.txt, February 2002.

   [DS-PROTO]  Le Faucheur F et al, "Protocol Extensions for support of
               Diffserv-Aware MPLS Traffic Engineering,
               draft-ietf-tewg-diff-te-proto-00.txt, February 2002

   [GANTI]     Ganti, Seddigh, Nandy, "MPLS Support of Differentiated
               Services using E-LSP",
               draft-ganti-mpls-diffserv-elsp-01.txt, November 2001.

   [IOVANNA]   Iovanna, et al, "Definition of the MPLS FlowSpec for
               draft-iovanna-rsvp-mpls-flowspec-00.txt, October 2001.

8.0 Author's Address

       Sudhakar Ganti
       Tropic Networks Inc.
       135 Michael Cowpland Drive
       Kanata, Ontario, Canada, K2M 2E9
       Email: sganti@tropicnetworks.com

       Nabil Seddigh
       Tropic Networks Inc.
       135 Michael Cowpland Drive
       Kanata, Ontario, Canada, K2M 2E9
       Email: nseddigh@tropicnetworks.com

       Biswajit Nandy
       Tropic Networks Inc.
       135 Michael Cowpland Drive
       Kanata, Ontario, Canada, K2M 2E9
       Email: bnandy@tropicnetworks.com

       Sanjaya Choudhury
       Email: sanjaya.choudhury@marconi.com

       Neil Harrison
       British Telecom
       Heath Bank, Iugby Road, Harleston
       South Hampton, UK
       Email: neil.2.Harrison@bt.com