Internet DRAFT - draft-augustyn-vpls-bw

draft-augustyn-vpls-bw





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