PPVPN Working Group Waldemar Augustyn Internet Draft Document: draft-augustyn-vpls-arch-00.txt Tissa Senevirathne Category: Informational (Force10 Networks) November 2001 Himanshu Shah Expires: May 2002 (Tenor Networks) Architecture and Model for Virtual Private LAN Services (VPLS) 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: PPPVPN Requirements, VPLS Requirements, See references. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This ID is intended for the PPVPN WG. Augustyn, et al. Expires-May 2002 1 draft-augustyn-vpls-arch-00.txt November 2001 WHY IS IT TARGETED AT THIS WG(s) PPVPN deals with provider provisioned VPNs. This document describes an architecture and model for Virtual Private LAN Services (VPLS), a class of PPVPN. JUSTIFICATION This architecture and model document helps organizing the effort to solve complex issues surrounding L2, broadcast domain network services, such as VPLS. There are several drafts related to VPLS which describe certain aspects of the solution and which need a common reference model. There are more drafts that are indirectly applicable to VPLS. These, too, need a good reference for proper evaluation and placement in the overall solution. 1. Abstract. This document describes the architecture and model for Virtual Private LAN Services (VPLS), a class of L2 Provider Provisioned Virtual Private Networks (PPVPN). This model most closely resembles LAN services that are attractive to many providers. It is intended to facilitate the continuing effort to specify the set of protocols and capabilities necessary for implementation of VPLS. 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 [2]. 3. Introduction. Layer 2 network services, that resemble behavior of Local Area Networks, LANs, have always been attractive to providers. However, the available technologies proved inadequate for building systems that could support a large number of L2 broadcast domain customer networks. A new approach was needed where technologies would be developed from the grounds up specifically with support for L2, LAN- style services in mind. A concept for such system was originally described in the VMI framework document [3], later crystallized and closely scoped in the requirements document for Virtual Private LAN Services (VPLS) [4]. A VPLS service is a class of Provider Provisioned Virtual Private Network (PPVPN) [5]. Augustyn, et al. Expires-May 2002 2 draft-augustyn-vpls-arch-00.txt November 2001 A number of solutions targeting certain aspects of the VPLS service have been proposed with several more are still remaining to be properly addressed. The presented model is intended to serve as a reference for the development of solutions comprising a full implementation of VPLS. This model can also be useful in designing service capabilities and features, as well as in planning commercial business operations. The focus is placed on the fundamental aspects of the service: o Robust, many to many connectivity o Orderly access to customer VPLS for value added services o Multi-domain VPLS interconnect system o Secure service operations o Full control over customer traffic 4. Network Reference Model. There are two network reference models. The simpler one is intended for designing core transport solutions. The more general model helps with developing service operations solutions. All devices depicted in the model represent logical functions, not physical units. An actual implementation may, of course, dedicate several physical units for each particular function. Conversely, it may combine functionality within a single physical device. 4.1. Local Domain VPN Model. This model is intended for testing basic transport capabilities. The emphasis is placed on redundant configurations. The solution must work well with, and take full advantage of, the redundant paths in the provider network as well as the mulitpath access to the customer edge devices. All requirements [4] with respect to unicast, broadcast, multicast and unknown unicast must be met. Figure 1 depicts a typical network scenario. Starting from the Customer side, there are two most prevalent connectivity styles: a non-redundant single link access (CE2, CE3), and a redundant multi home access (CE1). In each case, the first node on the Provider side plays a special role. These are Provider Edge nodes (PE3, PE4, PE5). The other nodes on the Provider side do not directly attach to Customers. These are designated as simply Provider nodes (P1, P2). The connectivity within a Provider is arranged in a redundant manner so that a removal of one node or link does not break connectivity between Customer sites. Of course, the non-redundant single link to sites CE2 and C3 has a single failure point in PE5. Augustyn, et al. Expires-May 2002 3 draft-augustyn-vpls-arch-00.txt November 2001 ........................................ : : : +-----+ : : | PE3 | +----+ : ---| |------------| P2 | : +-----+ / : +-----+ -------| |-- : | |- : \ / +----+ \ : +-----+ | CE1 | : ------------ / \ ---| CE2 | | |- : / \ / +-----+ / : +-----+ +-----+ \ : +-----+ +----+ | PE5 |- : --------| PE4 |----| P1 |-----| |- : : +-----+ +----+ +-----+ \ : +-----+ : ---| CE3 | : : +-----+ :......................................: CE - Customer Edge Node PE - Provider Edge Node P - Provider Node Fig. 1. Local Domain VPN Model 4.2. Service Reference Model. The more general Service Reference Model is intended for testing the remaining aspects of the VPLS service: orderly access to customer VPNs for value added services, multi-domain VPLS interconnections, secure service operations, and control over customer traffic. The typical scenario is depicted in Figure 2. This model builds on the Local Domain VPN by adding other representative elements. A provider has an option to gain access to customer VPLS for the purpose of offering additional services. These could be L2 services such as bridging between different VPLS segments, or it could be L3 and higher services such as DHCP, L3 VPN gateway, etc. One distinctly important case is the access to the public Internet. A provider can offer these services by becoming a virtual node on a customer VPLS. For redundancy, the solution must be able to support at least a pair of physical devices backing up each other. These devices are represented as PS6 and PS7. A complete VPLS solution cannot be limited to a single, closed, local domain. The solution must support interconnection of different VPLS domains, perhaps traversing third party carriers. A pair of peering nodes, PP8 and PP9, represent the interface to another VPLS domain. As usual, the solution must support redundant connectivity to the peer domains. A VPLS solution must operate in a secure manner providing proper separation of customer traffic and maintaining immunity from Augustyn, et al. Expires-May 2002 4 draft-augustyn-vpls-arch-00.txt November 2001 malformed or maliciously constructed packets sent by the customer. One common topological complication is a customer back-door connection between sites that belong to the same VPLS. In Figure 2, the link between Customer sites CE2 and CE4 represents such a situation. The link is outside of provider's control. It may appear and disappear at any time without notice. To cover a more general case, the link is shown to span sites belonging to different VPLS domains. Proper bandwidth management is critical to the stability of VPLS networks. The service reference model depicted in Figure 2 should be used for evaluation bandwidth control mechanisms. : : : +-----+ +-----+ : +-----+ : |PP10 | |PP11 | ----| CE4 | : +-----+ +-----+ : +-----+ : | | Peer Domain | | : | :.........|.|...............|.|........: | | | | | | ..........|.|...............|.|......... | : | | | | : | : +---+ | | : | back : --|PP8|------ | | : | door : / +---+ \ +---+ : | link : / ------------|PP9| : | : +-----+ / \ +---+ : | : | PE3 |----- +----+ / : | ---| |------------| P2 |-- : | +-----+ / : +-----+ -------| |-- : | | |- : \ / +----+ \ : +-----+ | CE1 | : ------------ / \ ---| CE2 | | |- : / \ / +-----+ / : +-----+ +-----+ \ : +-----+ +----+ | PE5 |- : --------| PE4 |----| P1 |-----| |- : : +-----+ +----+ +-----+ \ : +-----+ : \ / \ / ---| CE3 | : \ ---- ---- / : +-----+ : \ / \ / : : +---+ +---+ : : |PS6| |PS7| : : +---+ +---+ : :......................................: CE - Customer Edge Node PE - Provider Edge Node P - Provider Node PP - Provider Peering Node PS - Provider Service Access Node Fig. 2. Service Reference Model Augustyn, et al. Expires-May 2002 5 draft-augustyn-vpls-arch-00.txt November 2001 5. Node Functionality Reference Model. The Service Reference Model designates distinct functionality to certain representative nodes in the network. It useful to analyze each node's function to determine whether standardization is necessary. 5.1. CE Node Functional Model. The VPLS service is transparent to customer edge nodes, CE. It is sometimes referred to as PE-based. The CE is only a node on a VPLS network and does not take any part in the operations of the VPLS itself. The CE could be a switch, a router, or even an end station. The only function designated to the CE, as far as VPLS is concerned, is the control of the demarcation point for the Customer. v ingress egress ^ | | +-------+ +-------+ | DMRC | Demarcation Point Control | DMRC | +-------+ +-------+ | | +----------> . . . . . . . . . >----------+ Fig. 3. CE Node Functional Model 5.1.1. Demarcation Point Control. The Demarcation Point Control monitors, perhaps tests, the physical connectivity to the provider. The details of the functionality and the implementation are a local matter. 5.2. PE Node Functional Model. The PE node plays a prominent role in the implementation of the vPLS service. This is the node a customer has direct connectivity to, hence there is always at least one logical PE node per each customer site participating in a VPLS. Most of the operational functionality of VPLS is designated to this node. Augustyn, et al. Expires-May 2002 6 draft-augustyn-vpls-arch-00.txt November 2001 v ingress egress ^ | | +-------+ +-------+ | DMRC | Demarcation Point Control | DMRC | +-------+ +-------+ | | +-------+ +-------+ | PCLSS | Packet Classification | PCLSS | +-------+ +-------+ | | +-------+ +-------+ | HCONV | Header Conversion | HCONV | +-------+ +-------+ | | +-------+ +-------+ | PDIS | Packet Discrimination | PDIS | +-------+ +-------+ | | +-------+ +-------+ | QCTRL | Quality of Service Control | QCTRL | +-------+ +-------+ | | +-------+ +-------+ | VFWD | VPLS Forwarding | VFWD | +-------+ +-------+ | | +-------+ +-------+ | TFWD | Tunnel Forwarding | TFWD | +-------+ +-------+ | | +----------> . . . . . . . . . >----------+ Fig. 4. PE Node Functional Model 5.2.1. Demarcation Point Control. The demarcation point control function of PE is similar to that of a CE node, i.e. making sure connectivity exists. Unlike CE, the functionality of the PE demarcation point is not a local matter. The status of the link to the Customer is a critical item in the VPLS operations management. It is also a trigger for VPLS membership. The demarcation point can be applicable to a single customer or to an aggregate of several customers. The PE demarcation point performs the following: o Customer access monitoring and management o Customer link monitoring o L1 loopbacks Augustyn, et al. Expires-May 2002 7 draft-augustyn-vpls-arch-00.txt November 2001 The functionality of the PE demarcation point must be agreed upon. 5.2.2. Packet Classification. The PE deals with allocation of customers' packets to particular VPLS segments. Several criteria could be used: o Interface number o Layer 2 Classification (MAC address, VLAN tag, p-bits, etc.) o Layer 3 and above (IP address, port, protocol, TOS byte, etc.) o Other criteria (packet length, time of day, etc.) The type of classification must be agreed upon. 5.2.3. Header Conversion. Once a packet is classified as belonging to a particular VPLS, the PE may elect to modify the header. Typical conversions include: o Header extension o Header compression o QTAG mapping The type of conversion and the resulting header formats must be agreed upon. 5.2.4. Packet Discrimination. The packet discrimination function validates packets and determines whether they should be dropped or processed. It is represented here logically as a single block even though its actions can take place at more than one stage of packet processing. There could be several reasons for dropping packets. o Duplicate packets o Error packets o Validation, such as Ethernet type, packet length, etc. o Loop prevention and/or control o Multilink control (such as 802.1ad, etc.) o Multi-homing control o Access List or other policies The discrimination criteria must be agreed upon. In many cases, it is part of a protocol serving a particular objective, such as loop prevention, or multi-homing. In those cases, the related protocols must be agreed upon as well. Augustyn, et al. Expires-May 2002 8 draft-augustyn-vpls-arch-00.txt November 2001 5.2.5. Quality of Service Control. The quality of service control in question refers to the particular traffic characteristics, or priority mechanisms, committed to the customer by the provider. The quality service control is per VPLS. It includes: o Queue allocation o Policing o Shaping o Packet drop counts o Committed Service Topology o SLA parameters The functionality of the quality service control must be agreed upon. 5.2.6. VPLS Forwarding. The VPLS forwarding deals with all issues related to the transport of packets within a VPLS. In this model, there are two forwarding systems. The VPLS forwarding deals only with VPLS specifics such as unicast, unknown unicast, broadcast, multicast, etc. It assumes the existence of tunnels connecting relevant nodes. VPLS forwarding is also concerned with meeting SLA parameters such as bandwidth requirements, priorities, etc. Several important aspect must be addressed: o Packet transfer method, data plane o Packet transfer parameters and signaling, control plane o MAC learning o MAC caching o Packet replication for broadcast/multicast o End point discovery mechanisms o End point add/delete o Encryption, proxy encryption In many cases, related protocols are defined. All details of VPLS forwarding, elected protocols, and packet formats must be agreed upon. 5.2.7. Tunnel Forwarding. The tunnel forwarding deals with the transport capabilities of the entire VPLS infrastructure. The tunnel forwarding is used by the VPLS forwarding, discussed earlier. The tunnel forwarding is not directly concerned with meeting any particular SLA requirements, rather, it provides the robust infrastructure for VPLS forwarding. Several important aspects must be addressed: Augustyn, et al. Expires-May 2002 9 draft-augustyn-vpls-arch-00.txt November 2001 o Packet transfer method, data plane o Packet transfer parameters and signaling, control plane o Infrastructure node discovery o Infrastructure node add/delete o Redundancy o Failure restoration o Graceful reconfiguration o Hierarchical VPLS inter domain control o Bandwidth/Resource quota allocation and control o Path encryption The tunnel forwarding may define related protocols. All details of tunnel forwarding, elected protocols, and packet formats must be agreed upon. 5.3. P Node Functional Model. The P nodes do not have any specific function in the VPLS networks other than participating in the tunnel forwarding. v ingress egress ^ | | +-------+ +-------+ | TFWD | Tunnel Forwarding | TFWD | +-------+ +-------+ | | +----------> . . . . . . . . . >----------+ Fig. 5. P Node Functional Model 5.3.1. Tunnel Forwarding. Same considerations as in 5.2.7 above. 5.4. PS Functional Model. The Provider Service Access node employs all functionality that is directly related to providing value added services. In many cases, a customer VPLS will have a logical access point on that node. The services range can be quite wide: o Inter-VPLS connectivity o VPLS extranet clearinghouse o Access to public Internet o Network services (DHCP, NAT, DNS, etc.) o Security (Public Key management, Certificate server, etc.) Augustyn, et al. Expires-May 2002 10 draft-augustyn-vpls-arch-00.txt November 2001 The PS node, despite its distinguished function, plays a similar role to the PE node. For that reason, all requirements under 5.2 above are applicable. 5.5. PP Node Functional Model. The PP nodes facilitates multi domain VPLS operations. Its primary function is in the tunnel forwarding area. Additionally, it has demarcation control responsibility due to the direct connectivity to another VPLS domain. v ingress egress ^ | | +-------+ +-------+ | DMRC | Peer Demarcation Point Control | DMRC | +-------+ +-------+ | | +-------+ +-------+ | TFWD | Tunnel Forwarding | TFWD | +-------+ +-------+ | | +----------> . . . . . . . . . . . . >----------+ Fig. 6. PP Node Functional Model 5.5.1. Peer Demarcation Point Control. The peer demarcation control point function is similar to that of a PE, i.e. making sure connectivity exists. In case of peer demarcation, the customer could be another provider, or perhaps another domain within the same provider. In either case, this is an aggregate demarcation point. The functionality incudes: o Peer carrier access monitoring and administration o Peer carrier link monitoring o L1 loopbacks The functionality of peer demarcation must be agreed upon. 5.5.2. TFWD. Tunnel Forwarding. The PP tunnel forwarding is similar to PE tunnel forwarding but concentrates on exchange of necessary information for inter domain transport: o Hierarchical domain control o Reachability information o Peering method, policies Augustyn, et al. Expires-May 2002 11 draft-augustyn-vpls-arch-00.txt November 2001 Typically, related protocols are defined. All details of PP tunnel forwarding, elected protocols, and packet formats must be agreed upon. 6. Security Considerations. This document does not discuss specific security solutions. Applicable security requirements are presented in [Error! Bookmark not defined.]. 7. Acknowledgments. The ongoing work at the IETF has greatly influenced the work presented in this document. Authors wish to extend appreciations to their respective employers and various other people who volunteered to review this work and provided comments and feedback. 8. References. 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3. Senevirathne, T., et. al., "Framework For Virtual Metropolitan Internetworks (VMI)", Work in Progress, July 2001. 4. Augustyn, W., et al., "Requirements for Virtual Private LAN Services (VPLS)", Work in Progress, October 2001. 5. Carugi, M., et al., "Service requirements for Provider Provisioned Virtual Private Networks", Work in Progress, August 2001. 9. Authors' Addresses. Waldemar Augustyn Email: waldemar@nxp.com Tissa Senevirathne Force10 Networks 1440 McCarthy Blvd Milpitas, CA 95035 Phone: 408-965-5103 Email: tissa@force10networks.com Augustyn, et al. Expires-May 2002 12 draft-augustyn-vpls-arch-00.txt November 2001 Himanshu Shah Tenor Networks, Inc. 100 Nagog Park Acton, MA 01720 Phone 978-264-4900 Email: hshah@tenornetworks.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, et al. Expires-May 2002 13