PPVPN Working Group Waldemar Augustyn Internet Draft Document: draft-augustyn-vpls-bw-00.txt Category: Informational November, 2001 Bandwidth Management in VPLS Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Summary for Sub-IP related Internet Drafts RELATED DOCUMENTS: Requirement for PPVPN, Requirements for VPLS, See references. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This ID is intended for the PPVPN WG. WHY IS IT TARGETED AT THIS WG(s) This document discusses bandwidth management issues vital to L2 Virtual Private Network solutions such as Virtual Private LAN Service, (VPLS) [4]. VPLS is a class of Provider Provisioned VPN, (PPVPN)[2]. Augustyn, W. Expires May 2002 1 draft-augustyn-vpls-bw-00.txt November 2001 JUSTIFICATION The bandwidth management issues are of paramount importance in L2 VPN services. This document proposes a solution suitable for a many-to-many L2 VPNs such as VPLS. 1. Abstract This document describes a method for controlling customer traffic for L2 VPN services which support broadcast, multicast or implied broadcast such as Virtual Private LAN Service (VPLS), or other L2 Provider Provisioned VPNs. The method guarantees stability of the provider network regardless of the behavior of customer traffic, benign or malicious. 2. Conventions used in this document. 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 RFC-2119 [3]. 3. Introduction. A proper bandwidth management, always an important topic in data networks, becomes a critical issue in designing scalable L2 networks services, such as VPLS [4]. Customer broadcast traffic, whether explicit or implicit due to unknown L2 destinations, as well as certain native L2 protocols run by customers, are frequently seen as a threat to the stability of providers' networks. The solution described in this document places the provider in the position to control all customer L2 traffic. In this way, a provider can guarantee its network's stability regardless of the stability, or lack thereof, of its customers' networks. Additionally, the solution makes it easier to structure commercial services that can properly match the requested level of service with the cost of providing it. The focus of the document is on the operations of provider networks but a provider, as a value added service, may also offer help maintaining stable networks to its customers. 4. Service Capacity. The starting point for all considerations regarding bandwidth management is the context of Provider Provisioned VPNs [2]. In this Augustyn, W. Expires May 2002 2 draft-augustyn-vpls-bw-00.txt November 2001 context, a provider builds a network for a commercial purpose of selling its capabilities to customers. A provider makes binding promises with respect to the particular characteristics of the network services being offered. This leads to key observations: o Known total capacity. A provider knows the total available service capacity of its network prior to offering any service. o Known capacity share of services. A provider knows how much of the total capacity the offered services take. The actual capacity may fluctuate and a provider may use various technological means to determine available capacity at any given time and place in the network, but all discovery and determination is made prior to offering services. 5. Transport Modes. Once services have been offered to customers, a provider's concern is to make sure customer traffic, whether benign or malicious, does not exceed the allocated share of network capacity. This can be accomplished by dividing all transfers into two modes of operations and then by proper management of each of the modes: o Committed Rate Transport Mode, CRTM. o Best Effort Transport Mode, BETM. 5.1. Committed Rate Transport Mode, CRTM. The CRTM mode represents a provider's commitment to a particular service level. All packets falling into the CRTM category will be forwarded according to the advertised characteristics associated with them. These could include delay, bandwidth, jitter, etc. In this mode, all transport parameters have been determined and all necessary network resources have been allocated and guaranteed for the duration of the service prior to offering it to the customer. 5.2. Best Effort Transport Mode, BETM. In contrast, the BETM mode is representative of a provider's unwillingness to commit to any specific characteristics of the service beyond a promise to try. The packets could be forwarded as intended but they could just as well be delayed or dropped altogether based on arbitrary decisions made by the provider's network. In this mode, the transport parameters are not Augustyn, W. Expires May 2002 3 draft-augustyn-vpls-bw-00.txt November 2001 deterministic and may change at any time after the service has been offered. 5.3. Transport Priorities. There is no priority relationship between the transport modes. The CRTM is not "higher" priority than BETM. These two fundamental modes are independent of each other. Vendors may utilize priority schemes available in their devices' hardware for implementation but the resulting transport modes must remain independent. The prioritization of traffic is strictly a value added option for customers and applicable only in the context of their traffic. There is no priority relationship between traffic belonging to different customers, or even belonging the same customer that uses two or more disjoint VPN services. 6. Service Topology. Many L2 service requirements specify some particular types of connectivity between sites without mandating uniformity in the traffic parameters. Such is the case with VPLS. It defines the service as LAN-style, many-to-many connectivity between all points but it does not require the traffic characteristics be identical between all points in a VPLS. For services such as VPLS and other with similar issues, the precise specification of traffic characteristics is made in terms of the transport modes discussed in the previous section. In addition to network connectivity topology, a service topology is supplied. The service topology refers to commercial offer from the provider to the customer. 6.1. Base Service Topology. The base service topology describes the existence of direct connectivity between nodes as mandated by particular type of L2 service. For VPLS, the base service topology is a full mesh or many-to-many. The transport mode for base service topology is BETM. This is the default. 6.2. Committed Service Topology. With BETM being the default, a provider only needs to specify those parts of the network that operates in the committed rate mode, CRTM. The configuration of the network where CRTM is applicable is referred to as Committed Service Topology. Augustyn, W. Expires May 2002 4 draft-augustyn-vpls-bw-00.txt November 2001 In case of VPLS, this means the many-to-many connectivity topology will be covered at least by the best effort mode, BETM. A provider may guarantee certain traffic characteristics on this network through CRTM. For example, it can offer CRTM for traffic from one particular site, say company headquarters, to all others, say company branches. All traffic to and from the headquarters is guaranteed, but traffic between the branches is best effort. The Committed Service Topology can take all forms: point-to-point, point-to-multipoint a.k.a. hub-and-spoke, partial mesh, and full mesh. 6.3. Preferred Service Topology Construct. It is useful to select a simple base construct for describing complex service topologies. A good candidate is a symmetric hub- and-spoke. A symmetric hub and spoke lists all relevant traffic characteristics between a single customer access point, the hub, and a number of connecting access points, spokes. The traffic going from the hub has the same characteristics as the traffic going to the hub. A provider can use this construct to describe all possible service configurations: o Point-to-point. A special case of hub-and-spoke, only one hub and only one spoke. o Point-to-multipoint. Exact hub-and-spoke, probably the most common configuration. o Partial mesh. A collection of hub-and-spoke where some spokes are also hubs. o Full mesh. A collection of hub-and-spoke where all spokes are also hubs. 7. Traffic Policing and Shaping. 7.1. Traffic Policing. The solution requires traffic policing at certain strategic points in the provider's network. The details depend on implementation. A good guideline is to drop excess traffic as soon as it is known to be exceeding committed rate. Augustyn, W. Expires May 2002 5 draft-augustyn-vpls-bw-00.txt November 2001 Typically there are three logical policing points in the network. For example, let's assume a VPLS network where all PEs are fully meshed with one another. The policing points are: o provider ingress o tunnel ingress o provider egress Customer traffic is first checked at the entry to the provider's network. Soon after that, it is evaluated again after the tunnel to the destination PE has been determined. If the packet is following a Committed Service Topology path, it is evaluated against committed traffic characteristics and it could be dropped if it exceeds them. If the packet travels along a best effort path, it is still evaluated and possibly dropped with the difference that the criteria are totally at the discretion of the provider. After the packet reaches the destination PE, it is evaluated for the last time before it is sent to the customer CE. Unlike the previous policing points, this one does not play any vital role in protecting the stability of the provider's network, rather, it enforces the terms of the agreement with the customer. Of course, a provider may elect to let all traffic go to the customer if it has already made it to the destination PE. However, the service should offer means to control it fully. 7.2. Traffic Shaping. Traffic shaping is encouraged but it is not required for proper operation of the service. It is easy to see that the arrangement of traffic policing benefits the customer sites that employ shaping. A provider managed traffic shaping can be offered as a value added service. 8. Security Considerations. This memo does not discuss security issues. 9. Intellectual Property Considerations. The author may seek patents or other intellectual property protection for some or all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to the author, the author intends to disclose those patents and license them on reasonable and non-discriminatory terms. Augustyn, W. Expires May 2002 6 draft-augustyn-vpls-bw-00.txt November 2001 10. References. 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. Carugi, M., et. al., "Service requirements for Provider Provisioned Virtual Private Networks", Work in Progress, June 2001. 3. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 4. Augustyn, W., et al., "Requirements for Virtual Private LAN Services (VPLS)", Work in Progress, October 2001. 11. Author's Contact. Waldemar Augustyn email: waldemar@nxp.com Full Copyright Statement "Copyright (C) The Internet Society (2001). 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." Augustyn, W. Expires May 2002 7