draft-ietf-mpls-traffic-eng-01.txt   rfc2702.txt 
Internet Engineering Task Force
INTERNET-DRAFT
MPLS Working Group Daniel O. Awduche
Category: Informational Joe Malcolm
Expiration Date: December 1999 Johnson Agogbua
Mike O'Dell
Jim McManus
UUNET (MCI Worldcom)
June, 1999
Requirements for Traffic Engineering Over MPLS Network Working Group D. Awduche
Request for Comments: 2702 J. Malcolm
Category: Informational J. Agogbua
M. O'Dell
J. McManus
UUNET (MCI Worldcom)
September 1999
draft-ietf-mpls-traffic-eng-01.txt Requirements for Traffic Engineering Over MPLS
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (1999). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document presents a set of requirements for Traffic Engineering This document presents a set of requirements for Traffic Engineering
over Multiprotocol Label Switching (MPLS). It identifies the over Multiprotocol Label Switching (MPLS). It identifies the
functional capabilities required to implement policies that functional capabilities required to implement policies that
facilitate efficient and reliable network operations in an MPLS facilitate efficient and reliable network operations in an MPLS
domain. These capabilities can be used to optimize the utilization of domain. These capabilities can be used to optimize the utilization of
network resources and to enhance traffic oriented performance network resources and to enhance traffic oriented performance
characteristics. characteristics.
Table of Contents Table of Contents
1.0 Introduction .................................... 3 1.0 Introduction ............................................. 2
1.1 Terminology .................................... 4 1.1 Terminology .............................................. 3
1.2 Document Organization .................................... 4 1.2 Document Organization .................................... 3
2.0 Traffic Engineering ...................................... 4 2.0 Traffic Engineering ...................................... 4
2.1 Traffic Engineering Performance Objectives ............... 5 2.1 Traffic Engineering Performance Objectives ............... 4
2.2 Traffic and Resource Control ............................. 6 2.2 Traffic and Resource Control ............................. 6
2.3 Limitations of Current IGP Control Mechanisms ............ 7 2.3 Limitations of Current IGP Control Mechanisms ............ 6
3.0 MPLS and Traffic Engineering ............................. 8 3.0 MPLS and Traffic Engineering ............................. 7
3.1 Induced MPLS Graph ....................................... 9 3.1 Induced MPLS Graph ....................................... 9
3.2 The Fundamental Problem of Traffic Engineering Over MPLS . 10 3.2 The Fundamental Problem of Traffic Engineering Over MPLS . 9
4.0 Augmented Capabilities for Traffic Engineering Over MPLS . 10 4.0 Augmented Capabilities for Traffic Engineering Over MPLS . 10
5.0 Traffic Trunk Attributes and Characteristics ........... 11 5.0 Traffic Trunk Attributes and Characteristics ........... 10
5.1 Bidirectional Traffic Trunks ............................. 12 5.1 Bidirectional Traffic Trunks ............................. 11
5.2 Basic Operations on Traffic Trunks ....................... 13 5.2 Basic Operations on Traffic Trunks ....................... 12
5.3 Accounting and Performance Monitoring .................... 13 5.3 Accounting and Performance Monitoring .................... 12
5.4 Basic Attributes of Traffic Trunks ....................... 13 5.4 Basic Attributes of Traffic Trunks ....................... 13
5.5 Traffic Parameter Attributes ............................ 14 5.5 Traffic Parameter Attributes ............................ 14
5.6 Generic Path Selection and Management Attributes ......... 15 5.6 Generic Path Selection and Management Attributes ......... 14
5.6.1 Administratively Specified Explicit Paths ................ 15 5.6.1 Administratively Specified Explicit Paths ................ 15
5.6.2 Hierarchy of Preference Rules for Multi-paths ............ 16 5.6.2 Hierarchy of Preference Rules for Multi-paths ............ 15
5.6.3 Resource Class Affinity Attributes ....................... 16 5.6.3 Resource Class Affinity Attributes ....................... 16
5.6.4 Adaptivity Attribute ..................................... 17 5.6.4 Adaptivity Attribute ..................................... 17
5.6.5 Load Distribution Across Parallel Traffic Trunks ......... 18 5.6.5 Load Distribution Across Parallel Traffic Trunks ......... 18
5.7 Priority Attribute ....................................... 19 5.7 Priority Attribute ....................................... 18
5.8 Preemption Attribute ..................................... 19 5.8 Preemption Attribute ..................................... 18
5.9 Resilience Attribute ..................................... 20 5.9 Resilience Attribute ..................................... 19
5.10 Policing Attribute ...................................... 21 5.10 Policing Attribute ...................................... 20
6.0 Resource Attributes ...................................... 22 6.0 Resource Attributes ...................................... 21
6.1 Maximum Allocation Multiplier ............................ 22 6.1 Maximum Allocation Multiplier ............................ 21
6.2 Resource Class Attribute ................................ 22 6.2 Resource Class Attribute ................................ 22
7.0 Constraint-Based Routing ................................ 23 7.0 Constraint-Based Routing ................................ 22
7.1 Basic Features of Constraint-Based Routing ............... 24 7.1 Basic Features of Constraint-Based Routing ............... 23
7.2 Implementation Considerations ............................ 25 7.2 Implementation Considerations ............................ 24
8.0 Conclusion ............................................. 26 8.0 Conclusion ............................................. 25
9.0 Security Considerations .................................. 27 9.0 Security Considerations .................................. 26
10.0 References ............................................. 27 10.0 References ............................................. 26
11.0 Acknowledgments .......................................... 28 11.0 Acknowledgments .......................................... 27
12.0 Author's Address ......................................... 28 12.0 Authors' Addresses ....................................... 28
13.0 Full Copyright Statement ................................. 29
1.0 Introduction 1.0 Introduction
Multiprotocol Label Switching (MPLS) [1,2] integrates a label Multiprotocol Label Switching (MPLS) [1,2] integrates a label
swapping framework with network layer routing. The basic idea swapping framework with network layer routing. The basic idea
involves assigning short fixed length labels to packets at the involves assigning short fixed length labels to packets at the
ingress to an MPLS cloud (based on the concept of forwarding ingress to an MPLS cloud (based on the concept of forwarding
equivalence classes [1,2]). Throughout the interior of the MPLS equivalence classes [1,2]). Throughout the interior of the MPLS
domain, the labels attached to packets are used to make forwarding domain, the labels attached to packets are used to make forwarding
decisions (usually without recourse to the original packet headers). decisions (usually without recourse to the original packet headers).
skipping to change at page 4, line 25 skipping to change at page 3, line 44
The remainder of this document is organized as follows: Section 2 The remainder of this document is organized as follows: Section 2
discusses the basic functions of Traffic Engineering in the Internet. discusses the basic functions of Traffic Engineering in the Internet.
Section 3, provides an overview of the traffic Engineering potentials Section 3, provides an overview of the traffic Engineering potentials
of MPLS. Sections 1 to 3 are essentially background material. Section of MPLS. Sections 1 to 3 are essentially background material. Section
4 presents an overview of the fundamental requirements for Traffic 4 presents an overview of the fundamental requirements for Traffic
Engineering over MPLS. Section 5 describes the desirable attributes Engineering over MPLS. Section 5 describes the desirable attributes
and characteristics of traffic trunks which are pertinent to Traffic and characteristics of traffic trunks which are pertinent to Traffic
Engineering. Section 6 presents a set of attributes which can be Engineering. Section 6 presents a set of attributes which can be
associated with resources to constrain the routability of traffic associated with resources to constrain the routability of traffic
trunks and LSPs through them. Section 7 advocates trunks and LSPs through them. Section 7 advocates the introduction of
the introduction of a "constraint-based routing" framework in MPLS a "constraint-based routing" framework in MPLS domains. Finally,
domains. Finally, Section 8 contains concluding remarks. Section 8 contains concluding remarks.
2.0 Traffic Engineering 2.0 Traffic Engineering
This section describes the basic functions of Traffic Engineering in This section describes the basic functions of Traffic Engineering in
an Autonomous System in the contemporary Internet. The limitations of an Autonomous System in the contemporary Internet. The limitations of
current IGPs with respect to traffic and resource control are current IGPs with respect to traffic and resource control are
highlighted. This section serves as motivation for the requirements highlighted. This section serves as motivation for the requirements
on MPLS. on MPLS.
Traffic Engineering (TE) is concerned with performance optimization Traffic Engineering (TE) is concerned with performance optimization
skipping to change at page 17, line 10 skipping to change at page 16, line 22
traffic trunk. Resource class affinity attributes for a traffic can traffic trunk. Resource class affinity attributes for a traffic can
be specified as a sequence of tuples: be specified as a sequence of tuples:
<resource-class, affinity>; <resource-class, affinity>; .. <resource-class, affinity>; <resource-class, affinity>; ..
The resource-class parameter identifies a resource class for which an The resource-class parameter identifies a resource class for which an
affinity relationship is defined with respect to the traffic trunk. affinity relationship is defined with respect to the traffic trunk.
The affinity parameter indicates the affinity relationship; that is, The affinity parameter indicates the affinity relationship; that is,
whether members of the resource class are to be included or excluded whether members of the resource class are to be included or excluded
from the path of the traffic trunk. Specifically, the affinity from the path of the traffic trunk. Specifically, the affinity
parameter MAY be a binary variable which takes one of the following parameter may be a binary variable which takes one of the following
values: (1) explicit inclusion, and (2) explicit exclusion. values: (1) explicit inclusion, and (2) explicit exclusion.
If the affinity attribute is a binary variable, it may be possible to If the affinity attribute is a binary variable, it may be possible to
use Boolean expressions to specify the resource class affinities use Boolean expressions to specify the resource class affinities
associated with a given traffic trunk. associated with a given traffic trunk.
If no resource class affinity attributes are specified, then a "don't If no resource class affinity attributes are specified, then a "don't
care" affinity relationship is assumed to hold between the traffic care" affinity relationship is assumed to hold between the traffic
trunk and all resources. That is, there is no requirement to trunk and all resources. That is, there is no requirement to
explicitly include or exclude any resources from the traffic trunk's explicitly include or exclude any resources from the traffic trunk's
skipping to change at page 27, line 15 skipping to change at page 26, line 15
9.0 Security Considerations 9.0 Security Considerations
This document does not introduce new security issues beyond those This document does not introduce new security issues beyond those
inherent in MPLS and may use the same mechanisms proposed for this inherent in MPLS and may use the same mechanisms proposed for this
technology. It is, however, specifically important that manipulation technology. It is, however, specifically important that manipulation
of administratively configurable parameters be executed in a secure of administratively configurable parameters be executed in a secure
manner by authorized entities. manner by authorized entities.
10.0 References 10.0 References
[1] E. Rosen, A. Viswanathan, R. Callon, "A Proposed Architecture [1] Rosen, E., Viswanathan, A. and R. Callon, "A Proposed
for MPLS", Work in Progress. Architecture for MPLS", Work in Progress.
[2] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow,
A. Viswanathan, "A Framework for Multiprotocol Label
Switching", Work in Progress.
[3] T. Li and Y. Rekhter, "Provider Architecture for Differentiated [2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.
Services and Traffic Engineering (PASTE)," RFC 2430, and A. Viswanathan, "A Framework for Multiprotocol Label
October 1998. Switching", Work in Progress.
[4] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, "Cisco [3] Li, T. and Y. Rekhter, "Provider Architecture for Differentiated
Systems' Tag Switching Architecture - Overview", RFC 2105, Services and Traffic Engineering (PASTE)", RFC 2430, October
February 1997. 1998.
[5] Z. Zhang, C. Sanchez, B. Salkewicz, E. Crawley "Quality of [4] Rekhter, Y., Davie, B., Katz, D., Rosen, E. and G. Swallow,
Service Extensions to OSPF", Work in Progress. "Cisco Systems' Tag Switching Architecture - Overview", RFC
2105, February 1997.
[6] E. Crawley, R. Nair, B. Rajagopalan, H. Sandick, "A framework [5] Zhang, Z., Sanchez, C., Salkewicz, B. and E. Crawley "Quality of
for QoS Based Routing in the Internet," RFC 2386, August 1998 Service Extensions to OSPF", Work in Progress.
[7] R. Guerin, S. Kamat, A. Orda, T. Przygienda, D. Williams, [6] Crawley, E., Nair, F., Rajagopalan, B. and H. Sandick, "A
"QoS Routing Mechanisms and OSPF Extensions," Work in Progress. Framework for QoS Based Routing in the Internet", RFC 2386,
August 1998.
[8] C. Yang and A. Reddy, "A Taxonomy for Congestion Control [7] Guerin, R., Kamat, S., Orda, A., Przygienda, T. and D. Williams,
Algorithms in Packet Switching Networks," IEEE Network "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August
Magazine, Volume 9, Number 5, July/August 1995, 1999.
[9] W. Lee, M. Hluchyi, and P. Humblet, "Routing Subject to [8] C. Yang and A. Reddy, "A Taxonomy for Congestion Control
Quality of Service Constraints in Integrated Communication Algorithms in Packet Switching Networks," IEEE Network Magazine,
Networks," IEEE Network, July 1995, pp 46-55. Volume 9, Number 5, July/August 1995.
[10] ATM Forum, "Traffic Management Specification: Version 4.0" [9] W. Lee, M. Hluchyi, and P. Humblet, "Routing Subject to Quality
April 1996. of Service Constraints in Integrated Communication Networks,"
IEEE Network, July 1995, pp 46-55.
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement [10] ATM Forum, "Traffic Management Specification: Version 4.0" April
Levels", BCP 14, RFC 2119, March 1997. 1996.
11.0 Acknowledgments 11.0 Acknowledgments
The authors would like to thank Yakov Rekhter for his review of an The authors would like to thank Yakov Rekhter for his review of an
earlier draft of this document. The authors would also like to thank earlier draft of this document. The authors would also like to thank
Louis Mamakos and Bill Barns for their helpful suggestions, and Louis Mamakos and Bill Barns for their helpful suggestions, and
Curtis Villamizar for providing some useful feedback. Curtis Villamizar for providing some useful feedback.
12.0 AUTHORS' ADDRESSES 12.0 Authors' Addresses
Daniel O. Awduche Daniel O. Awduche
UUNET (MCI Worldcom) UUNET (MCI Worldcom)
3060 Williams Drive 3060 Williams Drive
Fairfax, VA 22031 Fairfax, VA 22031
Email: awduche@uu.net
Voice: +1 703-208-5277 Phone: +1 703-208-5277
EMail: awduche@uu.net
Joe Malcolm Joe Malcolm
UUNET (MCI Worldcom) UUNET (MCI Worldcom)
3060 Williams Drive 3060 Williams Drive
Fairfax, VA 22031 Fairfax, VA 22031
Email: jmalcolm@uu.net
Voice: +1 703-206-5895 Phone: +1 703-206-5895
EMail: jmalcolm@uu.net
Johnson Agogbua Johnson Agogbua
UUNET (MCI Worldcom) UUNET (MCI Worldcom)
3060 Williams Drive 3060 Williams Drive
Fairfax, VA 22031 Fairfax, VA 22031
Email: ja@uu.net
Voice: +1 703-206-5794 Phone: +1 703-206-5794
EMail: ja@uu.net
Mike O'Dell Mike O'Dell
UUNET (MCI Worldcom) UUNET (MCI Worldcom)
3060 Williams Drive 3060 Williams Drive
Fairfax, VA 22031 Fairfax, VA 22031
Email: mo@uu.net
Voice: +1 703-206-5890 Phone: +1 703-206-5890
EMail: mo@uu.net
Jim McManus Jim McManus
UUNET (MCI Worldcom) UUNET (MCI Worldcom)
3060 Williams Drive 3060 Williams Drive
Fairfax, VA 22031 Fairfax, VA 22031
jmcmanus@uu.net
Voice: +1 703-206-5607 Phone: +1 703-206-5607
EMail: jmcmanus@uu.net
13.0 Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 33 change blocks. 
95 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/