GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4127

Network Working Group F. Le Faucheur, Ed. Request for Comments: 4127 Cisco Systems, Inc. Category: Experimental June 2005

          Russian Dolls Bandwidth Constraints Model for
              Diffserv-aware MPLS Traffic Engineering

Status of This Memo

 This memo defines an Experimental Protocol for the Internet
 community.  It does not specify an Internet standard of any kind.
 Discussion and suggestions for improvement are requested.
 Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document provides specifications for one Bandwidth Constraints
 Model for Diffserv-aware MPLS Traffic Engineering, which is referred
 to as the Russian Dolls Model.

Table of Contents

 1. Introduction ....................................................2
    1.1. Specification of Requirements ..............................2
 2. Contributing Authors ............................................3
 3. Definitions .....................................................4
 4. Russian Dolls Model Definition ..................................5
 5. Example Formulas for Computing "Unreserved TE-Class [i]" with
    Russian Dolls Model .............................................7
 6. Receiving Both Maximum Reservable Bandwidth and Bandwidth
    Constraints sub-TLVs ............................................8
 7. Security Considerations .........................................8
 8. IANA Considerations .............................................8
 9. Acknowledgements ................................................9
 Appendix A: Addressing [DSTE-REQ] Scenarios .......................10
 Normative References ..............................................11
 Informative References ............................................12

Le Faucheur Experimental [Page 1] RFC 4127 Russian Dolls Model for DS-TE June 2005

1. Introduction

 [DSTE-REQ] presents the Service Providers requirements for support of
 Diffserv-aware MPLS Traffic Engineering (DS-TE).  This includes the
 fundamental requirement to be able to enforce different Bandwidth
 Constraints for different classes of traffic.
 [DSTE-REQ] also defines the concept of Bandwidth Constraints Model
 for DS-TE and states that "The DS-TE technical solution MUST specify
 at least one Bandwidth Constraints Model and MAY specify multiple
 Bandwidth Constraints Models".
 This document provides a detailed description of one particular
 Bandwidth Constraints Model for DS-TE which is introduced in
 [DSTE-REQ] and called the Russian Dolls Model (RDM).
 [DSTE-PROTO] specifies the Interior Gateway Protocol (IGP) and RSVP-
 TE signaling extensions for support of DS-TE.  These extensions
 support RDM.

1.1. Specification of Requirements

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

Le Faucheur Experimental [Page 2] RFC 4127 Russian Dolls Model for DS-TE June 2005

2. Contributing Authors

 This document was the collective work of several authors.  The text
 and content were contributed by the editor and the co-authors listed
 below. (The contact information for the editor appears in the
 Editor's Address section.)
 Jim Boyle                               Kireeti Kompella
 Protocol Driven Networks, Inc.          Juniper Networks, Inc.
 1381 Kildaire Farm Road #288            1194 N. Mathilda Ave.
 Cary, NC 27511, USA                     Sunnyvale, CA 94099
 Phone: (919) 852-5160                   EMail: kireeti@juniper.net
 EMail: jboyle@pdnets.com
 William Townsend                        Thomas D. Nadeau
 Tenor Networks                          Cisco Systems, Inc.
 100 Nagog Park                          250 Apollo Drive
 Acton, MA 01720                         Chelmsford, MA 01824
 Phone: +1-978-264-4900                  Phone: +1-978-244-3051
 EMail: btownsend@tenornetworks.com      EMail: tnadeau@cisco.com
 Darek Skalecki
 Nortel Networks
 3500 Carling Ave,
 Nepean K2H 8E9
 Phone: +1-613-765-2252
 EMail: dareks@nortelnetworks.com

Le Faucheur Experimental [Page 3] RFC 4127 Russian Dolls Model for DS-TE June 2005

3. Definitions

 For readability a number of definitions from [DSTE-REQ] are repeated
 here:
 Class-Type (CT): the set of Traffic Trunks crossing a link that is
                  governed by a specific set of bandwidth constraints.
                  CT is used for the purposes of link bandwidth
                  allocation, constraint-based routing and admission
                  control.  A given Traffic Trunk belongs to the same
                  CT on all links.
 TE-Class:        A pair of:
                  i.  a Class-Type
                  ii. a preemption priority allowed for that Class-
                  Type.  This means that an LSP transporting a Traffic
                  Trunk from that Class-Type can use that preemption
                  priority as the setup priority, the holding
                  priority, or both.
 A number of recovery mechanisms under investigation or specification
 in the IETF take advantage of the concept of bandwidth sharing across
 particular sets of LSPs.  "Shared Mesh Restoration" in [GMPLS-RECOV]
 and "Facility-based Computation Model" in [MPLS-BACKUP] are example
 mechanisms that increase bandwidth efficiency by sharing bandwidth
 across backup LSPs protecting against independent failures.  To
 ensure that the notion of "Reserved (CTc)" introduced in [DSTE-REQ]
 is compatible with such a concept of bandwidth sharing across
 multiple LSPs, the wording of the "Reserved (CTc)" definition
 provided in [DSTE-REQ] is generalized into the following:
 Reserved (CTc):  For a given Class-Type CTc ( 0 <= c <= MaxCT ), let
                  us define "Reserved(CTc)" as the total amount of the
                  bandwidth reserved by all the established LSPs which
                  belong to CTc.
 With this generalization, the Russian Dolls Model definition provided
 in this document is compatible with Shared Mesh Restoration defined
 in [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can
 operate simultaneously.  This assumes that Shared Mesh Restoration
 operates independently within each DS-TE Class-Type and does not
 operate across Class-Types (for example, backup LSPs protecting
 Primary LSPs of CTx also need to belong to CTx; Excess Traffic LSPs
 sharing bandwidth with Backup LSPs of CTx also need to belong to
 CTx).

Le Faucheur Experimental [Page 4] RFC 4127 Russian Dolls Model for DS-TE June 2005

 We also introduce the following definition:
 Reserved(CTb,q): Let us define "Reserved(CTb,q)" as the total amount
                  of the bandwidth reserved by all the established
                  LSPs that belong to CTb and have a holding priority
                  of q.  Note that if q and CTb do not form one of the
                  8 possible configured TE-Classes, then there cannot
                  be any established LSPs that belongs to CTb and has
                  a holding priority of q; therefore, in this case,
                  Reserved(CTb,q) = 0.

4. Russian Dolls Model Definition

 RDM is defined in the following manner:
      o Maximum Number of Bandwidth Constraints (MaxBC)=
           Maximum Number of Class-Types (MaxCT) = 8
      o for each value of b in the range 0 <= b <= (MaxCT - 1):
           SUM (Reserved (CTc)) <= BCb,
           where the SUM is across all values of c in the
           range b <= c <= (MaxCT - 1)
      o BC0= Maximum Reservable Bandwidth, so that
           SUM (Reserved(CTc)) <= Max-Reservable-Bw,
           where the SUM is across all values of c in the
           range  0 <= c <= (MaxCT - 1)
 A DS-TE LSR implementing RDM MUST support enforcement of Bandwidth
 Constraints in compliance with this definition.
 Both preemption within a CT and across CTs is allowed.
 Where 8 CTs are active, the RDM Bandwidth Constraints can also be
 expressed in the following way:
  1. All LSPs from CT7 use no more than BC7
  1. All LSPs from CT6 and CT7 use no more than BC6
  1. All LSPs from CT5, CT6 and CT7 use no more than BC5
  1. etc.
  1. All LSPs from CT0, CT1, …, CT7 use no more than BC0 = "Maximum

Reservable Bandwidth"

Le Faucheur Experimental [Page 5] RFC 4127 Russian Dolls Model for DS-TE June 2005

 Purely for illustration purposes, the diagram below represents the
 Russian Dolls Bandwidth Constraints Model in a pictorial manner when
 3 Class-Types are active:
 I------------------------------------------------------I
 I-------------------------------I                      I
 I--------------I                I                      I
 I    CT2       I    CT2+CT1     I      CT2+CT1+CT0     I
 I--------------I                I                      I
 I-------------------------------I                      I
 I------------------------------------------------------I
 I-----BC2------>
 I----------------------BC1------>
 I------------------------------BC0=Max Reservable Bw--->
 While simpler Bandwidth Constraints models or, conversely, more
 flexible/sophisticated Bandwidth Constraints models can be defined,
 the Russian Dolls Model is attractive in some DS-TE environments for
 the following reasons:
  1. Although it is a little less intuitive than the Maximum

Allocation Model (see [DSTE-MAM]), RDM is still a simple model

      to conceptualize.
  1. RDM can be used simultaneously to ensure bandwidth efficiency

and to protect against QoS degradation of all CTs, whether

      preemption is used or not.
  1. RDM can be used in conjunction with preemption to simultaneously

achieve (i) isolation across CTs (so that each CT is guaranteed

      its share of bandwidth no matter the level of contention by
      other classes), (ii) bandwidth efficiency, and (iii) protection
      against QoS degradation of all CTs.
  1. RDM only requires limited protocol extensions such as the ones

defined in [DSTE-PROTO].

 RDM may not be attractive in some DS-TE environments for the
 following reasons:
  1. if the usage of preemption is precluded for some administrative

reason, while RDM can still ensure bandwidth efficiency and

      protection against QoS degradation of all CTs, RDM cannot
      guarantee isolation across Class-Types.
 Additional considerations on the properties of RDM can be found in
 [BC-CONS] and [BC-MODEL].

Le Faucheur Experimental [Page 6] RFC 4127 Russian Dolls Model for DS-TE June 2005

 As a simple example usage of the "Russian Dolls" Bandwidth
 Constraints Model, a network administrator, using one CT for Voice
 (CT1) and one CT for data (CT0), might configure on a given link:
  1. BC0 = Max-Reservable - Bw = 2.5 Gb/s (i.e., Voice + Data is

limited to 2.5 Gb/s)

  1. BC1 = 1.5 Gb/s (i.e., Voice is limited to 1.5 Gb/s).

5. Example Formulas for Computing "Unreserved TE-Class [i]" with

  Russian Dolls Model
 As specified in [DSTE-PROTO], formulas for computing "Unreserved TE-
 Class [i]" MUST reflect all of the Bandwidth Constraints relevant to
 the CT associated with TE-Class[i], and thus, depend on the Bandwidth
 Constraints Model.  Thus, a DS-TE LSR implementing RDM MUST reflect
 the RDM Bandwidth Constraints defined in section 4 above when
 computing "Unreserved TE-Class [i]".
 As explained in [DSTE-PROTO], the details of admission control
 algorithms, as well as formulas for computing "Unreserved TE-Class
 [i]", are outside the scope of the IETF work.  Keeping that in mind,
 we provide in this section an example for illustration purposes, of
 how values for the unreserved bandwidth for TE-Class[i] might be
 computed with RDM.  In the example, we assume the basic admission
 control algorithm, which simply deducts the exact bandwidth of any
 established LSP from all of the Bandwidth Constraints relevant to the
 CT associated with that LSP.
 We assume that:
      TE-Class [i] <--> < CTc , preemption p>
 in the configured TE-Class mapping.
 For readability, formulas are first shown assuming only 3 CTs are
 active.  The formulas are then extended to cover the cases where more
 CTs are used.
 If CTc = CT0, then "Unreserved TE-Class [i]" =
    [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
 If CTc = CT1, then "Unreserved TE-Class [i]" =
    MIN  [
    [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
    [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
           ]

Le Faucheur Experimental [Page 7] RFC 4127 Russian Dolls Model for DS-TE June 2005

 If CTc = CT2, then "Unreserved TE-Class [i]" =
    MIN  [
    [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 2,
    [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
    [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
           ]
 The formula can be generalized to 8 active CTs and expressed in a
 more compact way in the following:
   "Unreserved TE-Class [i]" =
    MIN  [
  [ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7,
  [ BC(c-1) - SUM ( Reserved(CTb,q) ) ] for q <= p and (c-1)<= b <= 7,
      . . .
  [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7,
         ]
    where:
      TE-Class [i] <--> < CTc , preemption p>
      in the configured TE-Class mapping.

6. Receiving Both Maximum Reservable Bandwidth and Bandwidth

  Constraints sub-TLVs
 [DSTE-PROTO] states that "A DS-TE LSR, which does advertise BCs, MUST
 use the new "Bandwidth Constraints" sub-TLV (in addition to the
 existing Maximum Reservable Bandwidth sub-TLV) to do so."
 With RDM, BC0 is equal to the Maximum Reservable Bandwidth because
 they both represent the aggregate constraint across all CTs.  Thus, a
 DS-TE LSR, receiving both the "Maximum Reservable Bw" sub-TLV and the
 new "Bandwidth Constraints" sub-TLV (which contains BC0) for a given
 link where the RDM model is used, MAY ignore the "Maximum Reservable
 Bw" sub-TLV.

7. Security Considerations

 Security considerations related to the use of DS-TE are discussed in
 [DSTE-PROTO].  Those apply independently of the Bandwidth Constraints
 Model, including RDM specified in this document.

8. IANA Considerations

 [DSTE-PROTO] defines a new name space for "Bandwidth Constraints
 Model Id".  The guidelines for allocation of values in that name
 space are detailed in section 13.1 of [DSTE-PROTO].  In accordance

Le Faucheur Experimental [Page 8] RFC 4127 Russian Dolls Model for DS-TE June 2005

 with these guidelines, the IANA has assigned a Bandwidth Constraints
 Model Id for RDM from the range 0-239 (which is to be managed as per
 the "Specification Required" policy defined in [IANA-CONS]).
 Bandwidth Constraints Model Id 0 was allocated by IANA to RDM.

9. Acknowledgements

 We thank Martin Tatham for his key contribution in this work.
 Tatiana Renko is also warmly thanked for her instantiation of the
 Russian Doll.

Le Faucheur Experimental [Page 9] RFC 4127 Russian Dolls Model for DS-TE June 2005

Appendix A: Addressing [DSTE-REQ] Scenarios

 This appendix provides examples of how the Russian Dolls Bandwidth
 Constraints Model can be used to support each of the scenarios
 described in [DSTE-REQ].

A.1. Scenario 1: Limiting Amount of Voice

 By configuring on every link:
  1. Bandwidth Constraint 1 (for CT1 = Voice) = "certain percentage"

of link capacity

  1. BC0 (for CT1=Voice + CT0=Data) = link capacity
 By configuring:
  1. every CT1/Voice TE-LSP with preemption = 0
  1. every CT0/Data TE-LSP with preemption = 1
 DS-TE with the Russian Dolls Model will address all the requirements:
  1. amount of Voice traffic limited to desired percentage on every

link

  1. data traffic capable of using all remaining link capacity
  1. voice traffic capable of preempting other traffic

A.2. Scenario 2: Maintain Relative Proportion of Traffic Classes

 By configuring on every link:
  1. BC2 (for CT2) = e.g., 45%
  1. BC1 (for CT1+CT2) = e.g., 80%
  1. BC0 (for CT0+CT1+CT2) = e.g., 100%
 DS-TE with the RDM will ensure that the amount of traffic of each CT
 established on a link is within acceptable levels as compared to the
 resources allocated to the corresponding Diffserv Per Hop Behaviors
 (PHBs) regardless of which order the LSPs are routed in, regardless
 of which preemption priorities are used by which LSPs and regardless
 of failure situations.

Le Faucheur Experimental [Page 10] RFC 4127 Russian Dolls Model for DS-TE June 2005

 By also configuring:
  1. every CT2/Voice TE-LSP with preemption = 0
  1. every CT1/Premium Data TE-LSP with preemption = 1
  1. every CT0/Best-Effort TE-LSP with preemption = 2
 DS-TE with the Russian Dolls Model will also ensure that:
  1. CT2 Voice LSPs always have first preemption priority in order to

use the CT2 capacity

  1. CT1 Premium Data LSPs always have second preemption priority in

order to use the CT1 capacity

  1. Best-Effort can use up to link capacity of what is left by CT2

and CT1.

 Optional automatic adjustment of Diffserv scheduling configuration
 could be used for maintaining very strict relationships between the
 amounts of established traffic of each Class Type and corresponding
 Diffserv resources.

A.3. Scenario 3: Guaranteed Bandwidth Services

 By configuring on every link:
  1. BC1 (for CT1) = "given" percentage of link bandwidth

(appropriate to achieve the Guaranteed Bandwidth service's QoS

      objectives)
  1. BC0 (for CT0+CT1) = 100% of link bandwidth
 DS-TE with the Russian Dolls Model will ensure that the amount of
 Guaranteed Bandwidth Traffic established on every link remains below
 the given percentage so that it will always meet its QoS objectives.
 At the same time, it will allow traffic engineering of the rest of
 the traffic such that links can be filled up.

Normative References

 [DSTE-REQ]    Le Faucheur, F. and W. Lai, "Requirements for Support
               of Differentiated Services-aware MPLS Traffic
               Engineering", RFC 3564, July 2003.

Le Faucheur Experimental [Page 11] RFC 4127 Russian Dolls Model for DS-TE June 2005

 [DSTE-PROTO]  Le Faucheur, F., Ed., "Protocol Extensions for Support
               of Diffserv-aware MPLS Traffic Engineering", RFC 4124,
               June 2005.
 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 [IANA-CONS]   Narten, T. and H. Alvestrand, "Guidelines for Writing
               an IANA Considerations Section in RFCs", BCP 26, RFC
               2434, October 1998.

Informative References

 [BC-CONS]     Le Faucheur, F., "Considerations on Bandwidth
               Constraints Model for DS-TE", Work in Progress, June
               2002.
 [BC-MODEL]    Lai, W., "Bandwidth Constraints Models for
               Differentiated Services (Diffserv)-aware MPLS Traffic
               Engineering:  Performance Evaluation", RFC 4128, June
               2005.
 [DSTE-MAM]    Le Faucheur, F. and W. Lai, "Maximum Allocation
               Bandwidth Constraints Model for Diffserv-aware MPLS
               Traffic Engineering", RFC 4125, June 2005.
 [GMPLS-RECOV] Lang, et al., "Generalized MPLS Recovery Functional
               Specification", Work in Progress.
 [MPLS-BACKUP] Vasseur, et al., "MPLS Traffic Engineering Fast
               Reroute:  Bypass Tunnel Path Computation for Bandwidth
               Protection", Work in Progress.

Editor's 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

Le Faucheur Experimental [Page 12] RFC 4127 Russian Dolls Model for DS-TE June 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Le Faucheur Experimental [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4127.txt · Last modified: 2005/06/27 19:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki