Traffic Engineering Working Group W.S. Lai Internet Draft AT&T Labs Document: July 2000 Expiration Date: January 2001 Capacity Engineering of IP-Based Networks with MPLS 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 Drawing from the experience and work done in ITU-T on traffic engineering, the feasibility of extending telecommunications network dimensioning methods to IP-based networks with MPLS is explored. This version of the document is preliminary, reporting work in progress. 1. Introduction The routing protocols currently used in public IP networks are typically traffic-insensitive in that they do not include network resource utilization information in making routing decisions. As a result of this lack of traffic control, traffic tends to converge onto the same network segments, thereby causing unbalanced network loading with subsets of network resources at the "hot spots" being congested and other resources being underutilized. This shortcoming of network operation, coupled with the phenomenal growth of Internet usage, makes it very difficult to manage IP-based network performance. Hence, current engineering practice sometimes resorts to over-provisioning of network capacity. As IP-based network services evolve from a single best-effort class toward differentiation with multiple levels of quality of service Lai Category - Expiration 1 Capacity Engineering of IP/MPLS Networks July 2000 (QoS), a network infrastructure that offers consistent and predictable network performance is required. To achieve this, proper control and provisioning of network resources would be needed. Recently, it has been proposed that the multiprotocol label switching (MPLS) technology [1, 2] be used to overcome the above limitations of existing destination-based routing protocols so that more effective traffic engineering of IP-based networks can be performed. Such use of MPLS is discussed in the next section. To take full advantage of the mechanisms offered by MPLS, engineering and networking principles for resource management must be established, especially in the support for QoS [3]. This is the subject that is addressed here, with focus on the dimensioning aspect of traffic engineering and its related tasks. Topics covered include general aspects of traffic engineering, capacity engineering, traffic demand characterization, performance objectives and reference connections, and network dimensioning. Much of the materials presented here are adapted and drawn from the experience and work done in ITU-T on traffic engineering of telecommunications networks. 2. The Utility of MPLS Built upon the notion of separating packet forwarding and routing control functions [4], MPLS uses the technique of swapping link local labels to forward packets [5]. Originally, this technique was developed as a way of fast switching, so-called "short-cut routing," to simplify the packet processing tasks within a conventional IP router in a core network. With the advent of hardware-intensive high-speed routers, it now appears that the performance of destination-based network-layer forwarding in an IP router may be comparable to that of MPLS in a label-switching router (LSR). Currently, a major driver of MPLS is its application to traffic engineering. MPLS integrates the connection-oriented label-swapping operation with the connectionless network-layer routing/forwarding functions, thus gaining much of the control capabilities of a connection- oriented network such as ATM-based B-ISDN. In particular, MPLS facilitates the establishment of a set of paths satisfying certain constraints [6]. Such a kind of path, called a constraint-based routing label-switched path (CRLSP), is conceptually very similar to a virtual-path connection in an ATM network for traffic engineering purposes. For example, packets belonging to different traffic flows can be classified and routed through different CRLSPs at the ingress LSRs of an MPLS-capable domain. This enables the implementation of connection control and resource allocation functions on aggregated groups of traffic flows, instead of on individual flows. Such a scheme allows support for different classes of service [6, 7] and fits well with the Differentiated Services (DiffServ) architecture [8, 9]. Note that DiffServ is also achievable by network-layer forwarding, albeit with a different mechanism for classifying traffic into queues at each hop for QoS [10]. Lai Category - Expiration 2 Capacity Engineering of IP/MPLS Networks July 2000 Similar to ATM virtual paths, either administrative provisioning or network signaling can set up CRLSPs. Two signaling protocols are currently proposed for explicitly and dynamically propagating both connectivity and QoS information across MPLS domains. They are based on extensions to RSVP [11], and to the Label Distribution Protocol (LDP) [12], respectively. For large networks, an essential requirement for these protocols is their scalability, in terms of the number of signaling messages and their computational requirements, with network growth. In addition, to minimize the overheads associated with the management of CRLSPs, it may be desirable to conserve CRLSP usage. The ability of MPLS to set up explicitly routed CRLSPs permits source-node control, i.e., source routing, to operate efficiently. This provides network administrators the capability to steer traffic on desired paths, which may be arbitrary non-shortest paths. Such flexibility to direct the traffic to follow engineered paths through a network offers a number of advantages, e.g., load sharing across multiple paths, and shifting traffic away from congested links. Conventional IP routers achieve a somewhat similar effect by either using the equal-cost multipath option of OSPF [13, 14] to distribute traffic as evenly as possible among a selected set of paths with the same cost, or by using IP tunnels to distribute traffic across alternate paths through some intermediate destinations. (IP tunneling, as a means to alter the normal network-layer forwarding, is a datagram encapsulation technique that allows the specification of a tunnel's endpoints, but not the path taken by the tunnel [15].) Network-layer forwarding, such as that based on OSPF routing, also offers some form of load balancing by appropriately adjusting the link costs to trigger some traffic shift. For example, by using this method through a software tool called the NetScope [16], a network operator can reconfigure network-layer routing for network optimization and performance debugging. Given traffic demands, a technique for selecting link costs to optimize OSPF routing is presented in [17]. However, further investigations may be needed to apply this technique for routing in an operational network where traffic, and perhaps capacity (e.g., because of failure), is dynamically changing. Because destination-based routing does not provide a network operator with a precise control of the paths used for traffic flows, it is not easy to obtain network-wide traffic demands from the local interface measurements taken by different IP routers. As explained in [18], information from diverse network measurements and various configuration files are needed to infer the traffic volume. Based on flow-level measurements, this reference describes how to determine the traffic volume from an ingress link to a set of egress links by validating and joining various data sets together. The ability of MPLS to use fixed preferred paths for routing traffic, so-called route pinning, gives the means to measure and capture the statistics of the traffic flows more readily. This can be used to derive point-to-point demands as suggested in [19], but may also Lai Category - Expiration 3 Capacity Engineering of IP/MPLS Networks July 2000 help to correlate the data to derive the type of point-to-multipoint demands as described in [18]. As a result, there is the potential to develop more refined measurement technology so as to obtain a more accurate estimation and characterization of the traffic demands and related statistics for network planning and traffic engineering purposes. Path-based measurements may also enable the development of methodologies for such functions as admission control and performance verification of delivered service. The relative merits of MPLS versus network-layer routing/forwarding notwithstanding, MPLS does offer a standardized set of basic mechanisms that can be used to facilitate traffic engineering. Through these mechanisms, a variety of routing policies can be accommodated in a unified manner. However, to fully realize the potential of MPLS in terms of its generality and flexibility, operational processes for route configuration must be developed. In particular, algorithms are needed: (1) for selecting the CRLSPs that satisfy traffic engineering requirements and other constraints (such as routing policy), (2) for distributing traffic to the selected CRLSPs so as to minimize the possibility for congestion, and (3) for managing network resources so that the QoS for different services can be supported. Topics related to this aspect are to be discussed in what follows. 3. Traffic Engineering of IP-based Networks The issue of IP network traffic engineering has been addressed by two recent documents [20, 21]. As defined in [20], Internet traffic engineering is "that aspect of Internet network engineering that deals with the issue of performance evaluation and performance optimization of operational IP networks." Since network congestion is a primary cause of performance degradation, a major objective of traffic engineering is to increase the efficiency of resource utilization while minimizing the possibility of congestion through capacity and traffic management. Reference [20] also includes a discussion of requirements for routing, traffic mapping, measurement, survivability, and other attributes, from the perspective of traffic engineering. The interactions between traffic and capacity management in controlling a networkÆs response to traffic demands and network failures are further explored in [21]. Real-time traffic management functions such as routing control, path selection, and resource management, ensures that performance objectives are met under all conditions including load shifts and failures. Capacity management, through control of network design, ensures that network provisioning meets performance objectives for a given set of traffic demands at minimum cost. A global problem of network engineering is the choice and implementation of a specific routing strategy for the selection of paths for carrying traffic. Reference [21] provides an overview and Lai Category - Expiration 4 Capacity Engineering of IP/MPLS Networks July 2000 categorization of various routing methods, as well as routing table management methods for different network types and their interworking with each other. Also described are resource management methods to achieve QoS objectives, such as connection admission control and bandwidth reservation. Taking account of the provisioned network capacity, routing patterns (i.e., path sets and rules for path selection) are designed for different traffic streams between different source-destination node pairs. Periodically or possibly on a real-time basis, these routing patterns may be adjusted as necessary to correct service problems. An iterative network design process encompassing both routing- pattern design and capacity allocation is used to determine the minimum network capacity required to meet the performance objectives for given traffic demands. Reference [21] also presents a set of traffic engineering operational requirements. For example, network management controls such as call gapping can be used to assure acceptable network performance in case of overload or failures. 4. Capacity Engineering According to ITU-T Recommendation E.600 [22], traffic engineering includes measurements, forecasting, planning, dimensioning, control, and performance monitoring. Particular emphasis is placed on the control of resource allocation and the use of appropriate traffic models to size the different network elements so that the given performance criteria are satisfied in the support of given traffic demands with cost-effective and efficient resource usage. Specifically, traffic engineering has a goal of ensuring trafficability performance objectives for telecommunications services. Trafficability performance is defined in Recommendation E.800 [23] as follows. For each individual network element or functional subsystem, it is the ability of the element to meet a traffic demand of a given size and other characteristics, under given internal conditions. These internal conditions may be, e.g., any combination of faulty and not faulty parts within the element. Thus, trafficability performance has a direct impact on the accessibility, retainability, and integrity of any given service offered by a network; it is one of the major factors in QoS. Service accessibility refers to the ability of a service to be obtained, within specified tolerances and other given conditions, when requested by the user. Service retainability refers to the ability of a service, once obtained, to continue to be provided under given conditions for a requested duration. Service integrity refers to the degree to which a service is provided without excessive impairments, once obtained. Generally, trafficability performance is an attribute of network performance and can be described in terms of measures such as losses Lai Category - Expiration 5 Capacity Engineering of IP/MPLS Networks July 2000 and delays. However, E.800 has not explicitly provided any specific measures for trafficability performance. In this document, the focus is primarily on the dimensioning aspect of traffic engineering and its related tasks. In mapping given user demands onto network resources, network dimensioning involves the sizing of the network elements, such as links and buffers, so that performance objectives can be met at minimum cost. Thus, two major inputs to the dimensioning process are characterization of user demands and specification of performance objectives. (While cost is an important factor, the development of cost models will not be dealt with in this document.) The term capacity engineering is used here to cover this subset of traffic engineering tasks related to dimensioning. These tasks are covered in more detail in the next three sections. 5. Traffic Demand Characterization Typically, dimensioning procedures are based on models that approximate the statistical behavior of network traffic in large populations of users. To allow straightforward characterization of the traffic demands, these models necessarily adopt some simplifying assumptions concerning the usually complicated traffic processes, such as the arrival patterns of flows and the distribution of flow sizes. For these assumptions to be relevant and applicable, they must give rise to statistical patterns that closely approximate the behavior of aggregate traffic flows in operational networks. Traffic data are collected to validate these assumptions, with modifications being made when needed. Additionally, traffic measurements are used to estimate offered load and to provide forecasting of future demands for capacity planning purposes. Forecasting and planning may result in capacity augmentation or may lead to the introduction of new technology and architecture. Thus, a first step in the dimensioning process is to develop user demand models as input to characterize the offered load to the network. In the context of an ATM-based B-ISDN, ITU-T Recommendation E.716 [24] describes the characterization of user demand as manifested at the user-network interface. Since a CRLSP in MPLS is conceptually similar to a virtual-path connection in ATM for traffic engineering purposes, the methodology of E.716, when suitably modified and extended, may be applicable to MPLS-based IP networks. Further investigation of this feasibility is needed, especially to account for the effects of closed-loop adaptive controls as in a TCP connection. To allow the characterization of traffic offered to an IP-based network, user demands may be modeled as an arrival process of demands for IP-based services of different types. Each such service demand typically generates a set of flows [25, 26], with a flow being a sequence of temporally correlated packets that share some common properties. These properties usually include the source and Lai Category - Expiration 6 Capacity Engineering of IP/MPLS Networks July 2000 destination IP addresses, transport-layer application port numbers, and possibly others such as Type of Service. Flows are terminated either by timeout or through some protocol-specific events. For traffic engineering purposes, a flow in a connectionless network is analogous to a connection in a connection-oriented network. Reference [27] proposes that traffic controls be applied at the flow level to provide QoS guarantees. As each service demand generates a set of flows, each service type may be defined by a set of flow attributes and by a flow pattern as follows. (1) Flow attributes are those attributes of the service demand that identify the resources needed by the service demand in the network. These may include, e.g., access channel rate, communication configuration such as point-to-point or multipoint, and traffic conditioning agreements as defined in DiffServ [9]. (2) A flow pattern describes the packet arrival process in a flow through a set of traffic variables. E.716 presents four approaches for defining these traffic variables to describe the transient nature of rate variations. For example, they may be related to the burst structure of the packet flow, the number of packet arrivals in time intervals of specified length, packet interarrival time, or the number of packet arrivals exceeding a given rate. (Currently, models that describe the self-similar nature of IP traffic have been proposed in the literature. The applicability of these models, and the incorporation of the effect of self-similarity into models that capture the burstiness characteristics of source traffic for capacity engineering purposes, are for further study.) To recapitulate, a set of flow attributes and traffic variables may be used together to characterize a particular service type by setting appropriate values for the parameters. Depending on the different values chosen for these attributes and variables, the number of service types can potentially be very large. To minimize the effort of traffic engineering, especially in the initial stage of deployment, it may be desirable to limit the total number of service types. For example, service types with similar values may possibly be combined to form one representative type that captures the salient features essential for dimensioning. 6. Performance Objectives and Reference Connections Performance objectives can be viewed from two perspectives: the user and the network service provider. Quality of service (QoS), which is performance perceivable by a user of a service, expresses the user's degree of satisfaction of the service [22, 23]. Thus, QoS parameters focus on performance effects that are observable at the service access points and network interfaces, rather than their causes within the network [28]. Different service types usually have different QoS requirements. This allows a network provider to provide different treatment to different service types, to gain higher resource utilization. Lai Category - Expiration 7 Capacity Engineering of IP/MPLS Networks July 2000 Grade of service (GoS) is a number of traffic engineering parameters to provide a measure of adequacy of a group of resources under specified conditions [22]. These GoS parameters may be probability of blocking, probability of delay, etc. They are essential for network internal design and operation, as well as specification of component performance. The latter is related to the trafficability performance described previously. As an example, an important application of MPLS is to provide Virtual Private Network (VPN) services [29, 30]. Here, CRLSPs can possibly be used to emulate private lines by isolating VPNs from one another and by offering various types of QoS guarantees [31]. In particular, in the provision for resource allocation requests (such as for virtual leased line service) with customer-specific minimum bandwidth guarantees by bandwidth routing, a major GoS parameter will be the probability of blocking for these requests. Based on a given set of QoS requirements, a set of GoS parameters are selected and defined on an end-to-end basis within the network boundary, for each major service category provided by a network. The selected GoS parameters are specified in such a way that the GoS can be derived at well-defined reference points, i.e., traffic significant points. This is to allow the partitioning of end-to-end GoS objectives to obtain the GoS objectives for each network stage or component, on the basis of some well-defined reference connections. As defined in E.600, for traffic engineering purposes, a connection is an association of resources providing means for communication between two or more devices in, or attached to, a telecommunication network. There can be different types of connections as the number and types of resources in a connection may vary. Therefore, the concept of a reference connection is used to identify representative cases of the different types of connections without involving the specifics of their actual realizations by different physical means. Typically, different network segments are involved in the path of a connection. For example, a connection may be local, national, or international. The purposes of reference connections are for clarifying and specifying traffic performance issues at various interfaces between different network domains. Each domain may consist of one or more service provider networks. Recommendation E.651 [32] specifies reference connections for IP-access networks. Other reference connections are to be specified. From the QoS objectives, a set of end-to-end GoS parameters and their objectives for different reference connections are derived. For example, end-to-end connection blocking probability and end-to- end packet transfer delay may be relevant GoS parameters. The GoS objectives should be specified with reference to traffic load conditions, such as under normal and high load conditions. The end- to-end GoS objectives are then apportioned to individual resource components of the reference connections for dimensioning purposes. In an operational network, to ensure that the GoS objectives have Lai Category - Expiration 8 Capacity Engineering of IP/MPLS Networks July 2000 been met, performance measurements and performance monitoring are required. 7. Network Dimensioning As discussed previously, network dimensioning involves the optimal (e.g., minimum cost) sizing of the network elements to accommodate given traffic demands, while meeting performance objectives. In using MPLS, this means the assignment of resources such as bandwidth to a set of pre-selected CRLSPs for carrying traffic, and mapping the logical network of CRLSPs onto a physical network of links with capacity constraints. The dimensioning process also determines the link capacity parameters or thresholds associated with the use of some bandwidth reservation scheme for service protection. Service protection controls the GoS for certain service types by restricting access to bandwidth, or by giving priority access to one type of traffic over another. Such methods are essential, e.g., to guarantee a minimum amount of resources for connections with expected short duration, to improve the blocking probabilities for connections with high bandwidth requirements, or to maintain network stability by preventing GoS degradation in case of a local overload. In performing the task of dimensioning, it is assumed that a network topology, both at the logical and physical levels, has been defined. This is because the layout of a network is usually influenced by other factors, such as the network providerÆs policy/administrative constraints, or considerations of an existing network. Also, it is assumed that the network is available, i.e., it does not consider network equipment in a failure state. Routing deals with the selection of network paths for connection requests. To simplify the dimensioning process, a routing-pattern with pre-determined paths for different traffic streams is usually assumed. (This may include the use of dynamic routing, see E.525 [33].) As described previously, the process of routing-pattern design and dimensioning is iterated until an optimal design is reached. The series of ITU-T Recommendations E.735-7 [34, 35, 36] presents a set of general principles and methods for dimensioning ATM-based B- ISDNs. The notion of Equivalent Cell Rate (ECR) has been used effectively therein for dimensioning purposes. The ECR captures the effects of expected traffic mix, cell-level control mechanisms, priority scheduling, bandwidth and buffer capacity limitations, thereby characterizing the estimated amount of resources that needs to be allocated to a connection to satisfy the specified cell-level GoS objectives. Borrowing from this technique, it may be useful to define some Equivalent Bandwidth parameter for dimensioning IP-based networks. Further studies are needed for its definition. Assuming that connection blocking probability is the only GoS parameter at the connection level, and using ECR to account for Lai Category - Expiration 9 Capacity Engineering of IP/MPLS Networks July 2000 cell-level performance, E.737 presents several iterative methods for dimensioning. To reduce computational complexity, approximation methods based on the independence assumption and the principle of decomposition may be developed. For example, if the capacity of a link can be considered as well delimited, independent of the traffic carried by other links, then the global end-to-end decision on connection admission can be decomposed into local decisions. These techniques may be applicable to the dimensioning of CRLSPs in an MPLS-based network, e.g., for the provision of the previously described VPN services. 8. Proposed Work Items From the above discussion, here is a partial list of work items for further study: 1. Use of path-based measurements to help determine traffic demands for traffic engineering, admission control, and performance verification of delivered service 2. Algorithms to select CRLSPs for traffic distribution in the support of QoS 3. A set of equivalent bandwidth definitions for various service types for dimensioning purposes 9. Security Considerations Security considerations are not addressed in this version of the draft. References 1 E.C. Rosen, A. Viswanathan, and R. Callon, ôMultiprotocol Label Switching Architecture,ö Internet-Draft, Work in Progress, August 1999. 2 R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, and A. Viswanathan, ôA Framework for Multiprotocol Label Switching,ö Internet-Draft, Work in Progress, September 1999. 3 G. Huston, ôNext Steps for the IP QoS Architecture,ö Internet- Draft, Work in Progress, June 2000. 4 W.S. Lai, ôPacket Forwarding,ö IEEE Communications Magazine, July 1988. 5 A. Viswanathan, N. Feldman, Z. Wang, and R. Callon, ôEvolution of Multiprotocol Label Switching,ö IEEE Communications Magazine, May 1998. 6 D. Awduche, J. Malcolm, J. Agogbua, M. OÆDell, and J. McManus, ôRequirements for Internet Traffic Engineering Over MPLS,ö RFC 2702, September 1999. Lai Category - Expiration 10 Capacity Engineering of IP/MPLS Networks July 2000 7 T. Li and Y. Rekhter, ôA Provider Architecture for Differentiated Services and Traffic Engineering (PASTE),ö RFC 2430, October 1998. 8 K. Nichols, S. Blake, F. Baker, and D. Black, ôDefinition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,ö RFC 2474, December 1998. 9 S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, ôAn Architecture for Differentiated Services,ö RFC 2475, December 1998. 10 G. Armitage, ôMPLS: The Magic Behind the Myths,ö IEEE Communications Magazine, January 2000. 11 D.O. Awduche, L. Berger, D.H. Gan, T. Li, G. Swallow, and V. Srinivasan, ôRSVP-TE: Extensions to RSVP for LSP Tunnels,ö Internet-Draft, Work in Progress, February 2000. 12 B. Jamoussi (Editor), ôConstraint-Based LSP Setup Using LDP,ö Internet-Draft, Work in Progress, September 1999. 13 J. Moy, ôOSPF Version 2,ö RFC 2328, April 1998. 14 C.E. Hopps, ôAnalysis of an Equal-Cost Multi-Path Algorithm,ö Internet-Draft, Work in Progress, February 2000. 15 C. Perkins, ôIP Encapsulation Within IP,ö RFC 2003, October 1996. Also, C. Perkins, ôMinimal Encapsulation Within IP,ö RFC 2004, October 1996. 16 A. Feldmann, A. Greenberg, C. Lund, N. Reingold, and J. Rexford, ôNetScope: Traffic Engineering for IP Networks,ö IEEE Network, March/April 2000. 17 B. Fortz and M. Thorup, ôInternet Traffic Engineering by Optimizing OSPF Weights,ö Proc. IEEE INFOCOM, March 2000. 18 A. Feldmann, A. Greenberg, C. Lund, N. Reingold, J. Rexford, and F. True, ôDeriving Traffic Demands for Operational IP Networks: Methodology and Experience,ö Proc. ACM SIGCOMM 2000, Stockholm, Swedan. 19 X. Xiao, A. Hannan, B. Bailey, and L.M. Ni, ôTraffic Engineering with MPLS in the Internet,ö IEEE Network, March/April 2000. 20 D.O. Awduche, A. Chiu, A. Elwalid, I. Widjaja, and X. Xiao, ôA Framework for Internet Traffic Engineering,ö Internet-Draft, Work in Progress, May 2000. 21 ITU-T Draft Recommendation E.TE, ôTraffic Engineering and QoS Methods for IP-, ATM-, and TDM-Based Multiservice Networks,ö March 2000. A more up-to-date version of this document appears as Internet-Draft , July 2000, (Contact: G. Ash). 22 ITU-T Recommendation E.600, ôTerms and Definitions of Traffic Engineering,ö March 1993. 23 ITU-T Recommendation E.800, ôTerms and Definitions Related to Quality of Service and Network Performance Including Dependability,ö August 1994. 24 ITU-T Recommendation E.716, ôUser Demand Modelling in Broadband- ISDN,ö October 1996. 25 K.C. Claffy, H. Braun, and G.C. Polyzos, ôA Parameterizable Methodology for Internet Traffic Flow Profiling, ô IEEE JSAC, vol. 13, No. 8, October 1995. Lai Category - Expiration 11 Capacity Engineering of IP/MPLS Networks July 2000 26 A. Feldmann, J. Rexford, and R. Caceres, ôEfficient Policies for Carrying Web Traffic Over Flow-Switched Networks,ö IEEE/ACM Transactions on Networking, December 1998. 27 J.W. Roberts and S. Oueslati-Boulahia, ôQuality of Service by Flow Aware Networking,ö to appear in Philosophical Transactions. 28 ITU-T Recommendation E.430, ôQuality of Service Framework,ö June1992. 29 E.C. Rosen, S.J. Brannon, M. Carugi, C.J. Chase, E. Dean, P. Hitchin, M. Leelanivas, L. Martini, V. Srinivasasn, and A. Vedrenne, ôBGP/MPLS VPNs,ö Internet-Draft, Work in Progress, May 2000. 30 K. Muthukrishnan and A. Malis, ôA Core MPLS IP VPN Architecture,ö Internet-Draft, Work in Progress, May 2000. 31 B. Gleeson, A. Lin, J. Heinanen, G. Armitage, and A. Malis, ôA Framework for IP Based Virtual Private Networks,ö RFC 2764, February 2000. 32 ITU-T Recommendation E.651, ôReference Connections for Traffic Engineering of IP Access Networks,ö March 2000. 33 ITU-T Recommendation E.525, ôDesigning Networks to Control Grade of Service,ö June 1992. 34 ITU-T Recommendation E.735, ôFramework for Traffic Control and Dimensioning in B-ISDN,ö May 1997. 35 ITU-T Recommendation E.736, ôMethods for Cell Level Traffic Control in B-ISDN,ö May 1997. 36 ITU-T Recommendation E.737, ôDimensioning Methods for B-ISDN,ö May 1997. Acknowledgments The support of Gerald Ash on this work and his comments are much appreciated. An earlier version of this document was presented to the ITU-T Study Group 2, Working Party 3 (WP 3/2: Traffic Engineering) meeting in March 2000. The author is most grateful of the support and comments from WP 3/2 members, in particular, Toshikane Oda, Bruce Pettitt, James Roberts, and Manuel Villen- Altamirano. The author would also like to thank the input from Christopher Chase, Jennifer Rexford, and Herbert Shulman. Author's Addresses Wai Sum Lai AT&T Labs Room D5-3D18 200 Laurel Avenue Middletown, New Jersey 07748, USA Phone: 732-420-3712 Email: wlai@att.com Full Copyright Statement Lai Category - Expiration 12 Capacity Engineering of IP/MPLS Networks July 2000 Copyright (C) The Internet Society (2000). 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 implmentation 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. Lai Category - Expiration 13