Network Working Group Waldemar Augustyn Internet Draft (Nortel Networks) Document: draft-augustyn-vmi-m2m-arch-00.txt Category: Informational Tissa Senevirathne (Force10) Himanshu Shah (Tenor Networks) June 2001 Architecture and Model for L2 many-to-many VMI 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: See reference. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This ID is intended for the PPVPN WG. Augustyn, et. al. Expires-December 2001 1 draft-augustyn-vmi-m2m-arch-00.txt June 2001 WHY IS IT TARGETED AT THIS WG(s) PPVPN deals with provider provisioned VPNs. This document describes an architecture and model of one particular case of such PPVPN. This case is a subset of Virtual Metropolitan Internetworks (VMI) which, in turn is considered a case of PPVPN as stated in [2]. JUSTIFICATION This architecture and model document helps organizing the effort to solve complex issues surrounding L2, broadcast domain networks, such as VMI. There are several drafts related to VMI which describe certain aspects of the solution and which need a common reference model. There are more draft in-progress that relate to VMI in one way or another. These, too, need a good reference for proper evaluation and placement in the overall solution. 1. Abstract This document describes an architecture and model for an unrestricted interconnect, "many-to-many", case of Virtual Metropolitan Internetworks (VMI). This model most closely resembles LAN operations of L2 services offered by many Providers. It is intended to facilitate the continuing effort to specify the set of protocols and capabilities necessary for implementation of provider provisioned, broadcast domain, L2 networks (VMI)[4]. VMI is a case of a Provider Provisioned Virtual Private Network (PPVPN)[2]. 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 The Virtual Metropolitan Internetworks refer to a customerĘs remote LAN interconnect through service providerĘs network infrastructure. The framework for VMI [4] describes the requirements and issues that pertain to building of high speed metro data networks through providerĘs infrastructure. A particular subset of VMI framework refers to a many-to-many or full-mesh LAN network topology model which closely resemble in behavior, management, configuration and maintenance the ubiquitous Ethernet networks, commonly popular amongst all customers Augustyn, et. al. Expires-December 2001 2 draft-augustyn-vmi-m2m-arch-00.txt June 2001 In this document we present a model for the many-to-many case of VMI network services. This model is the reference for protocols involved in the implementation. It can also be useful in designing service capabilities, features, and business operations models. The model is intended to conform to the L2 NBVPN requirements laid out in [5] 4. Network Reference Model As the standardization effort in the area of VMI intensifies, it becomes necessary to provide a reference model for each services. This document presents a reference model for many-to-many, unrestricted interconnect, VMI topology which meet following characteristics: o L2 broadcast domain networks o Many-to-many topology o Transparent deployment (a.k.a. PE-based) All devices in the model represent a logical functionality. The actual implementations may, and frequently do, involve more than one physical unit. Conversely, combining functionality within a single device is possible. 4.1. Local Domain VPN Model The first, most essential, capability is to provide a robust many- to-many connectivity between sites. A Local Domain VPN model, while not general, serves this purpose well. In this model, the emphasis is placed on redundant configurations. A solution must work well with redundant paths and take full advantage of their existence. Many known L2 solutions have trouble with multipath connectivity and multi-home access to customers. This model is intended to be a test for the fundamentals of proposed solutions. 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-December 2001 3 draft-augustyn-vmi-m2m-arch-00.txt June 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 builds on the Local Domain VPN by adding other representative elements as shown in Figure 2. The second essential capability is to give the Providers an orderly access to the CustomersĘ VMIs for the purpose of supplying optional value added services. These include L2 services such as bridging between different VMIs, but most often L3 and higher services such as DHCP, L3 VPN gateway, etc. One distinctly important case of that service is the access to the public Internet. In this model, the provider has opportunity to offer these services by gaining orderly access to customerĘs VMIs. It does so by becoming a virtual node on the customerĘs VMI. The connection is done in a redundant manner. For the customer, the access appears as a single node on the network, but the infrastructure must use two or more physical service nodes backing up each other. In Figure 2, these nodes are represented by a pair PS6 and PS7. The third essential capability is the ability to create a VMI system that consists of several, interconnected VPN domains. Figure 2 shows a pair of Provider Peering nodes (PP8, PP9) serving as interface to another Local Domain VPN network via their counterparts (PP10, PP11). The function of these nodes is to make possible extending connectivity within a VMI to Customer sites connected to another Domain (CE4). As usual, the nodes are connected to the rest of the network in a redundant manner. Augustyn, et. al. Expires-December 2001 4 draft-augustyn-vmi-m2m-arch-00.txt June 2001 The fourth essential capability is the ability operate the service in a secure manner providing proper separation of customer traffic and maintaining immunity from malformed or maliciously constructed packets sent by the customer. One common topological complication is the creation of back-door connections between sites served by a providerĘs VMI network. In Figure 2, the link between Customer sites CE2 and CE4 represents such part of VMI topology that is beyond control of the Provider. The link may appear and disappear at any time without any notice to the Provider. To cover a more general case, the link is shown to span sites belonging to different ProvidersĘ VMI domains. The solution must be able to deal with these types of common complications. : : : +-----+ +-----+ : +-----+ : |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-December 2001 5 draft-augustyn-vmi-m2m-arch-00.txt June 2001 5. Processing Reference Model The Service Reference Model designates distinct functionality to the nodes in the network. Here, each node type is analyzed. The functionality and order of processing is logical only, there is no intention to suggest any particular implementation. In many cases, depending on chosen scope and set of capabilities, the designated functionality may be combined into a single device, distributed to several devices, or be null altogether. 5.1. CE Node Processing Model This model describes a case of transparent deployment of the VMI, sometimes referred to as PE-based. The CE is only a node on a VMI network and does not take any part in the operations of the VMI itself. The CE could be a switch, a router, or even an end station. The only function designated to the CE, as far as VMI is concerned, is the control of the demarcation point for the Customer. v ingress egress ^ | | +-------+ +-------+ | DMRC | Demarcation Point Control | DMRC | +-------+ +-------+ | | +----------> . . . . . . . . . >----------+ Fig. 3. CE Node Processing Model 5.1.1. DMRC. Demarcation Point Control The DMRC monitors, perhaps tests, the physical connectivity to the Provider. The details of functionality and implementation are a local matter. 5.2. PE Node Processing Model The PE node plays a prominent role in the implementation of many-to- many transparent VMI networks. 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 VMI. Most of the operational functionality is designated to this node. Augustyn, et. al. Expires-December 2001 6 draft-augustyn-vmi-m2m-arch-00.txt June 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 | VMI Forwarding | VFWD | +-------+ +-------+ | | +-------+ +-------+ | PFWD | Path Forwarding | PFWD | +-------+ +-------+ | | +----------> . . . . . . . . . >----------+ Fig. 4. PE Node Processing Model 5.2.1. DMRC. Demarcation Point Control The DMRC function of PE is similar to the DMRC function of CE, i.e. making sure connectivity exists. Unlike CE DMRC, the PE DMRC is not a local matter. The health of the link to the Customer is a critical item in the Operations Management. It is also a trigger for VMI join/leave operations. The DMRC can be applicable to a single Customer or an aggregate of Customers. The PE DMRC performs the following: o Customer access monitoring and management o Customer link monitoring o L1 loopbacks DMRC functionality must be agreed upon, implementation is a local matter. Augustyn, et. al. Expires-December 2001 7 draft-augustyn-vmi-m2m-arch-00.txt June 2001 5.2.2. PCLSS. Packet Classification The PE PCLSS deals with allocation of CustomersĘ packets to their VMIs. There could be several criteria for this classification: 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.) Classification type must be agreed upon, the implementation is a local matter. 5.2.3. HCONV. Header Conversion Once a packet is classified as belonging to a particular VMI, the PE may elect to modify the header. HCONV may include: o Header extension o Header compression o QTAG mapping The type of HCONV and resulting header formats must be agreed upon. 5.2.4. PDIS. Packet Discrimination The PDIS 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, 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 PDIS criteria must be agreed upon. In many cases, PDIS is part of a protocol serving particular objective, such as loop prevention, or multi-homing. In these cases, the related protocols must be agreed upon as well. Augustyn, et. al. Expires-December 2001 8 draft-augustyn-vmi-m2m-arch-00.txt June 2001 5.2.5. QCTRL. Quality Control The quality control in question refers to promises to the Customers regarding a particular type of service offered to them. QCTRL is per VMI, it does not deal directly with the issue of QoS/CoS in the VMI infrastructure. QCTRL includes: o Queue allocation o Policing o Shaping o Packet drop counts o Committed Service Topology o SLA parameters The functionality of QCTRL must be agreed upon, the implementation is a local matter. 5.2.6. VFWD. VMI Forwarding The VFWD deals with all issues related to the transport of packets within a VMI. In this model, there are two forwarding systems. The VFWD deals only with VMI specifics such as unicast, unknown unicast, broadcast, multicast, etc. It assumes the existence of tunnels, or paths, connecting relevant nodes. VFWD is also concerned with meeting SLA parameters such as bandwidth requirements, priorities, etc. Several important aspect are 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 VMI encryption, proxy encryption In many cases, a related protocol is defined. All details of VFWD, elected protocols and packet formats must be agreed upon. 5.2.7. PFWD. Path Forwarding The PFWD deals with the transport capabilities of the entire VMI infrastructure. The VFWD, discussed earlier, uses paths provided by PFWD. PFWD is not concerned with meeting any particular SLA requirements or any VMI specifics. It can be thought of as the general forwarding infrastructure. o Packet transfer method, data plane Augustyn, et. al. Expires-December 2001 9 draft-augustyn-vmi-m2m-arch-00.txt June 2001 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 VMI inter domain control o Bandwidth/Resource quota allocation and control o Path encryption Here, too, related protocols are defined. All details of PFWD, elected protocols and packet formats must be agreed upon. 5.3. P Node Processing Model The P nodes do not have any specific function other than participating in the PFWD for the VMI infrastructure v ingress egress ^ | | +-------+ +-------+ | PFWD | Path Forwarding | PFWD | +-------+ +-------+ | | +----------> . . . . . . . . . >----------+ Fig. 5. P Node Processing Model 5.3.1. PFWD. Path Forwarding Same requirements as 5.2.7. 5.4. PS Processing Model The Provider Service Access node employs all functionality that is directly related to providing value added services. In many cases, a customer VMI will have a logical access point on that node. The services range can be quite wide: o Inter-VMI connectivity o VMI extranet clearinghouse o Access to public Internet o Network services (DHCP, NAT, DNS, etc.) o Security (Public Key management, Certificate server, etc.) o etc. The PS node, despite its distinguished function of providing value added services, plays a similar role to the PE node as far as VMI is Augustyn, et. al. Expires-December 2001 10 draft-augustyn-vmi-m2m-arch-00.txt June 2001 concerned. For that reason, all requirements under 5.2 are applicable. 5.5. PP Node Processing Model The PP nodes facilitates multi domain VMI operations. Its primary function is in the PFWD area. Additionally, it has demarcation control responsibility due to the direct connectivity to another VMI domain. v ingress egress ^ | | +-------+ +-------+ | DMRC | Path Demarcation Point Control | DMRC | +-------+ +-------+ | | +-------+ +-------+ | PFWD | Path Forwarding | PFWD | +-------+ +-------+ | | +----------> . . . . . . . . . . . . >----------+ Fig. 6. PP Node Processing Model 5.5.1. DMRC. Path Demarcation Point Control The DMRC function of PP is similar to the DMRC function of PE, making sure connectivity exists. In case of PP DMRC, the Customer could be another Provider, or perhaps another domain within the same Provider. In each case, this is an aggregate demarcation point. The PP DMRC performs the following: o Peer carrier access monitoring and administration o Peer carrier link monitoring o L1 loopbacks The PP DMRC functionality must be agreed upon, implementation is a local matter. 5.5.2. PFWD. Path Forwarding The PFWD is similar to PE PFWD but concentrates on exchange of necessary information for inter domain transport: Hierarchical domain control Reachability information Peering method, policies Augustyn, et. al. Expires-December 2001 11 draft-augustyn-vmi-m2m-arch-00.txt June 2001 Typically, related protocols are defined. All details of PFWD, 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 [5]. 7. 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. Senevirathne, T., et. al., "Framework For Virtual Metropolitan Internetworks (VMI)", Work in Progress, February 2001. 5. Senevirathne, T., et. al., "Requirements for Layer 2 Network Based VPN", Work in Progress, May 2001. 8. Acknowledgments The on going 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. 9. AuthorsĘ Addresses Waldemar Augustyn Nortel Networks 600 Technology Park Billerica, MA 01821 Phone: 978 288 4993 Email: waldemar@nortelnetworks.com Tissa Senevirathne Force10 Networks 1440 McCarthy Blvd Milpitas, CA 95035 Phone: 408-965-5103 Email: tissa@force10networks.com Augustyn, et. al. Expires-December 2001 12 draft-augustyn-vmi-m2m-arch-00.txt June 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 Augustyn, et. al. Expires-December 2001 13