Network Working Group Tissa Senevirathne(Force10) Internet Draft Waldemar Augustyn Document: draft-senevirathne-vmi-frame-02.txt Pascal Menezes (TeraBeam) Category: Informational Marc Lasserre (RiverStone) February 2002 A Framework for Virtual Metropolitan Internetworks (VMI) 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 1. Abstract In this document we present framework for VPLS (Virtual Private LAN services) and point-to-point Layer 2 VPN services. These two models are collectively referred to as VMI (Virtual Metropolitan Internetworks). Senevirathne, et al., Expires-August 2002 draft-senevirathne-vmi-frame-02.txt February 2002 2. Introduction Over the last several years, the available bandwidth in the core networks has increased dramatically, at the same time offering price per Mbyte has gone down. Most businesses today have multi site office complexes. Some of these organizations are exploring the opportunity of outsourcing their inter site enterprise network to Service Providers. With the opportunities in this segment increasing, Service Providers are building a new class of network service based on Metropolitan Area Networks. This new class of services intends to provide a virtual Internetwork for customers who wish to connect their geographically dispersed sites using public networks at very high speeds. In this document we define these networks as Virtual Metropolitan Internetwork or VMI. The service that provides VMI is defined as Virtual Metropolitan Internetwork Services, VMIS. In the past, both the service and the business models were mainly dictated by the network infrastructure installed by the Service Providers. Here, we envision the opposite relationship. A ProviderÆs business model and its customer service requirements would derive the network infrastructure and its capabilities. The architecture of a ProviderÆs infrastructure consists of a backbone transport mechanism, network management and accounting, traffic engineering and QoS capabilities etc. Hence, with a given infrastructure a Provider may only be able to satisfy some subset of requirements and business models. In this document we present, different infrastructure models and identify the types of requirements and business models that can be satisfied within the architecture. 2.1. VMI Taxonomy In this section we define Taxonomy and Analogy of Virtual Metropolitan Internetworkto facilitate considerations of problems at hand. o VMI Infrastructure. A collection of VMI Service ProviderÆs equipment and methods used to implement VMI service. All VMI networks share a common infrastructure. o VMI Network. A virtual network service offered by a VMI Service Provider, as seen by a Customer. Multiple, mutually exclusive networks exist within the same, shared infrastructure. o VMI Service Management. A VMI Service ProviderÆs means of managing operations of VMI networks. Given the above taxonomy, VMI can be viewed as a stack of disks on a base or "Tower of Disks". Each of the disks represents a separate Senevirathne, et al. Expires-August 2002 2 draft-senevirathne-vmi-frame-02.txt February 2002 virtual network. The base represents the Infrastructure. The pin in the middle represents the Service Management. | ----------------- | | VMI-2 ----------------- | | | <--------- Service Management | | ----------------- | | VMI-1 ----------------- | --------------------- | | Infrastructure --------------------- 2.2. Network Service Model for Virtual Metropolitan Internetwork Presently there are several models that are used to provide VMI Services. Each of these models may suit customers based on their requirement. Some service providers exclusively support only one model; such providers may not be able to accommodate some customer requirement. In this section we summarize possible service models that different customers may require. o Full mesh, many-to-many network model o Partial mesh model o point-to-multipoint (hub and spoke) model o point-to-point model o hierarchical, multi domain model 3. Building blocks (Elements) of VMI Building blocks of VMI can be broadly classified into following elements. o Backbone Transport methods o Access methods Senevirathne, et al. Expires-August 2002 3 draft-senevirathne-vmi-frame-02.txt February 2002 o VMI configuration, membership and end-point discovery o Network Management and accounting o VMI Forwarding instance o Encapsulation o Quality of service 4. VMIS Specifications VMIS specifications derive the service model. VMIS specifications can be broadly classified into several areas. o number of sites that required to be connected. o Required network topology; hub and spoke with sites connecting to the data center, fully meshed Local Area Network or combination. o Type of connectivity required; Layer 2 or IP routing. o Traffic engineering and QoS requirements. o Security; traffic separation, payload encryption and authentication. o Billing requirements; wholesale models vs. per byte billing. o Service Level Agreement (SLA); Time of the day bandwidth vs. flat bandwidth o Traffic reporting and accounting; statistics, exceptions, etc. o Gateway Functions; option for the Provider to offer extra services on the private VMI networks. 5. Service Characteristics 5.1. Network Models 5.1.1. Many-to-many network model Many-to-many VMI network model is ideally suited for customers who want to have multiple sites connected, via a public network, to form a one single network. In this topology, either they extend their Local Network as a layer 2 connectivity or may choose to introduce to create a routed virtual core. Many-to-many Virtual Metropolitan Internetwork model is particularly useful for the environment where Senevirathne, et al. Expires-August 2002 4 draft-senevirathne-vmi-frame-02.txt February 2002 service offering is to extend the customer's enterprise network using the shared network. Many-to-many VMI model is by far the most general model. Using this model, one may construct any of the other models. ------ ------- Customer 1| | | | Customer 1 --------- | PE A | | PE B |------ Site A | | --- | | Site B ------ | | ------- | \ | | / | | -----| | ----------- | | ----|---|-------- | | | | | | | | | -----| Metro Core |------- | | ----|---|-------- | | | | Virtual|Internet --- | | | | | ------- | Customer 1 | | | -------------- | PE C |-- Site C | | ------- Simple many-to-many Virtual Metropolitan Internetwork 5.1.2. Point-to-multipoint or hub and spoke network model The point-to-multipoint model is a subset the of many-to-many-point model. Point-to-multi-point model may be used for services that requires connectivity to a centralized site from several remote sites. Such a service is very similar to more traditional frame relay deployment. Unlike frame relay networks, VMI point-to- multipoint network may provide additional services that are beyond the capabilities of classical frame relay networks. 5.1.3. Point-to-point network model The point-to-point network model is the simplest of all VMI network models. Due to its simplicity, point-to-point model can be used for a variety of services that could not be provisioned using other service models. As an example, providing video or voice services require strict end-to-end timing. Providing such end-to-end timing Senevirathne, et al. Expires-August 2002 5 draft-senevirathne-vmi-frame-02.txt February 2002 using other service models may not be possible. VMI point-to-point services are classified into two categories: o The VMI services that require data services, either in packet or cell form are called Data service VMI (DSVMI). o The VMI service that require emulation of some characteristics of a transport media, such as SONET are called, in this document, Circuit Emulation VMI (CEVMI). 5.2. Hierarchical Interconnection model In situations where connectivity spans different administrative domains, or the complexity of the infrastructure warrants subdivisions, a hierarchical interconnection model is applicable. Here we assume that there is a remote service provider that has agreed to participate in VMI services. ^ | to pop(4L) | ---------- | | <-------| pop(3L) |---------> to other pop(3L) ---------- / \ / \ / \ / \ --------- ---------- | | | | to other <-----| pop(2L) | -------------------- | pop (2L)|-----> --------- ---------- pop (2L) | UNION | UNION --------------------------- ------------------------- | | | | | -------- -------- | | | | | | | || | | | | pop(1L)| ----| pop(1L) || | | | -------- -------- | | | | | | | | | | --------- --------- | | | | | Local | | Local | | | | | | confederate | confederate | | | | | | | | | | | -------- --------- | | | --------------------------- -------------------------- Sample Hierarchical Interconnection model Senevirathne, et al. Expires-August 2002 6 draft-senevirathne-vmi-frame-02.txt February 2002 The above diagram depicts a hierarchical interconnection model. The local confederates are the more traditional VMI service providers. The first level POP connects multiple of local confederates. collection of local confederates that are below a single first level pop is considered as a "UNION". The Unions are interconnected using second level POP. 5.3. Deployments 5.3.1. Transparent Deployment In the transparent model, customers may consider the VMI as a virtual and transparent extension to their Local Network. In other words; all the sites appear as access points in the same Local Network. The Transparent point-to-multi-point and many-to-many models are mainly used by the customers who wish to extend the Local Network over the VMI without any network layer address translation. Due to the anatomy of these models, network edge devices that provide interface between the customer sites may require to implement specific forwarding policies. In more traditional frame relay networks; when deploying hub and spoke models; concepts such as split horizon may be implemented to prevent reflection of broadcast traffic. However when providing transparent deployment model customers may wish to have connectivity from remote site to a remote site. Cost concern customers who do not wish to purchase fully meshed many-to-many network and yet achieve many-to-many reachability may also use point-to-multi-point deployment. VMI service providers who wish to offer transparent deployment model MUST have forwarding policies defined to properly forward inter-site traffic. A simple such policy is to treat each virtual connection as a separate circuit. A more complex forwarding policies may require to be defined if all the virtual links to be treated like a single interface and yet achieve inter-site forwarding. 5.3.2. Routable deployment In the routable model the VMI access points may be considered as belonging to the same sub-network. Thus VMI edge devices providing routing functionality. However, customers may wish to maintain their private address space shielded from the VMI control plane. At the same time, VMI Service Providers may not wish to maintain customer address space. As such, VMI infrastructure may require having technologies that could transport customer's traffic using some local addressing and transport mechanisms. Senevirathne, et al. Expires-August 2002 7 draft-senevirathne-vmi-frame-02.txt February 2002 5.4. Demarcation Point The VMI service recognizes the need for proper demarcation between the administrative entities involved in the service. Each entity participating in the service must be able to extend its operations management and monitoring system to guarantee the delivery of its obligations. o Customer-Provider. This type of relationship is sometimes referred to as ôretailö. In this case, the Provider must have the means for proving with reasonable certainty that the service, as described in SLA, is provided throughout the Providers network up to the demarcation points. These demarcation points are typically devices owned by the provider that directly connect to customerÆs equipment. In cases of transparent deployment of VMI services, these devices can be very simple supporting little more than Layer 1 loopbacks. In cases of routed deployment of VMI services, the devices are considerably more complex. Typically, these are switches or routers that are Provider owned or managed but reside on customer premise. o Provider-Provider. This type of relationship is sometimes referred to as ôwholesaleö. In this case, too, the essential objective is to prove with reasonable certainty that the service provided to another Provider is operational throughout the network up to the demarcation point. o Service domain-Service domain. Even within a single organization, it is useful to define demarcation points between major service domains. This type of demarcation is similar to Provider-Provider. 5.5. Scaling It is important that the VMIS architecture is able to support a large number of customers with each customer having multiple sites requiring unconstraint connectivity. Typically, scalable solutions attempt to place per-VMI parameters in the edge devices while keeping core networks free from the need to maintain any state or VMI specific data. The basic premise behind this strategy is that the infrastructure can grow, potentially indefinitely, by adding edge devices with all per-VMI data localized in these devices. This strategy works well if the solution can further localize the per-site data to the devices directly attaching to the customer site. As an example if an edge device needs to learn MAC addresses of the nodes participating in a VMI, it is more scalable if the learning is limited to the MAC addresses originating in the site directly attached to the device. Otherwise, if that device has to learn all MAC addresses, including those originating at other sites, Senevirathne, et al. Expires-August 2002 8 draft-senevirathne-vmi-frame-02.txt February 2002 the device may be overwhelmed by some large sites, perhaps connected via large edge devices. 5.6. Data Security and Authentication In VMI Services, customer's data is exposed to the shared network at the Provider side. A VMI service provider might use services from other upstream providers for global backbone connectivity. Hence, privacy may be an issue. Traditionally, it has been the responsibility of the customer to use their own technology, such as IPSec, to provide privacy, but with VMI service offerings of speeds in the range of 1Gbps, the performance of CE based solutions becomes an issues. It is quite attractive if the VMI service provider can offer encryption and security. It is quite possible, a customer sharing the infrastructure with the competitors. Hence, it is required that customers have ability to protect and authenticate data. o Simple Traffic Separation. In many situations a simple, virtual separation of traffic may be sufficient. This style of security, frequently referred to as Frame-Relay-like, has gained wide acceptance in the market place. The provider is entrusted with making sure VMI traffic remains inaccessible to other customers. The level of security protects against attacks from other Customers, but not from the Provider itself. o Advanced Security. For more sensitive applications, more secure means, involving encryption and authentication techniques, are necessary. Essentially there are two approaches to solve this. In the first approach, customers may choose to install on premise data encryption devices. Here, there needs to be an out of band management connectivity between encryption devices. In the second approach Service provider edge devices may themselves provide data encryption and authentication. In the case of many-to-many connectivity, Security Association establishment and Encryption key distribution become more complex. The security solution for point-to-point VMI depends on the type of VMI service provided. Hence, the security solution provided for DSVMI may be different from the CEVMI. Within the DSVMI, based on the payload types different security solution may be needed. As an example, when transporting IP only payloads one may choose IP Sec solution whereas when transporting Layer 2 payloads, service providers may require to provide a security solution that is protocol agnostic. Regardless, some customers may wish to have an on premise security solution. Especially, CEVMI customers may use a front-end scramblers/encryptors. Senevirathne, et al. Expires-August 2002 9 draft-senevirathne-vmi-frame-02.txt February 2002 5.7. Transport mechanisms in the core There are multiple transport mechanisms capable of providing the necessary connectivity. Choice of the appropriate transport depends on the set of requirements that a given Service Provider wants to address. As an example, a Provider may choose to have a complete Layer 2 topology with simpler layer 2 protocol to provide redundancy and reconfiguration. On the other hand, if a Provider chooses to support the entire set of requirements, he may choose more sophisticated protocol such as MPLS. In theory, it is possible that multiple transport mechanisms are supported in the core. It is possible that a VMI Service Provider enrolls a customer where all the sites are NOT within the footprint of the provider. This would be the case if the VMI service provider uses one set of transport mechanisms (e.g. MPLS) within its footprint and another (e.g. IP-Sec, GRE, etc.) for service consistency through some public backbone (Internet). Obviously various usage policies (QoS) would have to be different based on the available resources. When providing a CEVMI service, the transport method should be able to tunnel the circuits over the VMI infrastructure. The transport in the VMI core should be capable of supporting emulation of Time Division Multiplexed (TDM) circuits. The chosen transport method should be able to provide required reliability, end-to-end timing, service provisioning etc., as agreed upon in the SLA. When providing a DSVMI service, at least the following issues must be taken into consideration when selecting a Transport Mechanism: end-to-end QoS, type of payload (Layer 2/ IP), reliability, reconfiguration. 5.8. QoS and Traffic Engineering Customers may now wish to have the same QoS and Traffic Engineering characteristics as they do in a locally connected network. Hence, now the problem is not providing end-to-end QoS service but providing network wide QoS and traffic engineering. In general, a given flow, whether Layer 2 or 3, is point-to-point in nature. The broadcast and multicast nature of local networks can be emulated using set of fully meshed point-to-point networks. This approach simplifies the problem and reduces the issue to providing required QoS level per point-to-point link. If all sites are symmetric in QoS and Traffic Engineering requirements, the management of QoS and parameters becomes simple. However, in practice, different sites may have varying Traffic engineering parameters. In such configurations, it is important that participating nodes have knowledge of the requirements of the other nodes and impose shaping and policing appropriately. Senevirathne, et al. Expires-August 2002 10 draft-senevirathne-vmi-frame-02.txt February 2002 Consider the deployment scenario below. When, node A is sourcing broadcast traffic it is required not to over-subscribe the link between A-C, which is only 50% incoming rate of ingress port A'. Hence, it is essential that participating nodes are capable of performing egress traffic shaping, as required. B(node) / | 5 Mbits/sec / | / | / | 5 Mbits/sec / | --------A'-- A(node) | 5 Mbits/sec \ | \ | \ | 2.5 Mbits/sec \ | \C(node) The discovery of these parameters can be either via an automatic process or via manual configuration. It is possible that some of these information can be piggy backed to routing protocols such as OSPF and BGP and advertised to other devices, thereby reducing the management burden. Alternatively, one may have a system wide management system that would provision the services. The QoS and Traffic Engineering service in Circuit emulation VMI (CEVMI) may require satisfying different Traffic Engineering parameters than Data Service VMI (DSVMI). Exact set of parameters depends on the Type of circuit emulation service offered and customer requirements. As an example, if the ATM circuits are emulated customer may wish to have only UBR service or CBR service. Another example is a customer who wishes to extend Frame Relay network over the VMI. When offering Circuit Emulation services, transport protocol in the VMI core should be capable of satisfying different requirements of different categories of circuits. 5.9. Reliability Different customers may require different levels of reliability. The reliability is here defined as protection against service infrastructure failures. The protection against such failures should be built into the infrastructure and backbone transport protocols. The protection can be defined in many flavors such as Primary/Secondary, Fast Reroute. Protection can also have additional attributes such as time to restore (50 msec) as well. As an example, MPLS fast reroute and backup path protection may be needed for some customers who mandate higher level of reliability. The methods for providing desired level of reliability for Circuit Emulation VMI (CEVMI) may be different from methods for providing desired level of reliability for Data Service VMI (DSVMI). When providing certain Senevirathne, et al. Expires-August 2002 11 draft-senevirathne-vmi-frame-02.txt February 2002 Circuit Emulation VMI, providers must maintain timing requirements. The committed levels of reliability may be included in Service Level Agreement. Thus, Service Providers are legally bound to satisfy these requirements. Inability to provide agreed upon reliability levels may have financial and/or legal ramifications. At the same time, these levels of protection may be essential for operation of their applications. Providing redundancy in point-to-multipoint deployments may be much simpler than many-to-many deployment model. It is anticipated that when purchasing a SLA, the redundancy is specified for the entire VMI service rather than per site basis. Hence provisioning such redundancy in a many-to-many network may cause serious complexities and expenses to the VMI service providers. 5.10. Reconfiguration It is important to provide uninterrupted services to the customers during maintenance and upgrades. Thus, methods are essential to be built into the infrastructure for graceful reconfiguration during maintenance. Unlike redundancy provided to address required reliability, the redundancy required during maintenance is temporary and may be configured manually. 5.11. Service Provisioning and End Point Discovery A system wide network provisioning may be administratively prohibitive due to the number and diversity of the end points. A more suitable approach for large providers is to perform provisioning only at the end points and use control protocol or signaling method to automatically provision the required service parameters. 5.12. Service Gateway For many providers, it is desirable to offer additional services beyond the standard, private network connectivity. VMI can allow an orderly access to customersÆ VMI networks for the purpose of supplying value added services. One important service of that kind is connecting the entire VMI to the public Internet. Other services can offer DHCP, local DNS, NAT, etc. 6. Security Considerations This document does not discuss specific security solutions. This document, however, identifies and states the security requirements in Virtual Metropolitan Internetworks. Senevirathne, et al. Expires-August 2002 12 draft-senevirathne-vmi-frame-02.txt February 2002 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 8. Acknowledgments The on going work at the IETF and the work presented in the cited references has greatly influenced the work presented in this document. Authors also wish to extend appreciations to their respective employers and various other people who volunteered to review this work and provided comments and feedback. 9. Author's Addresses Tissa Senevirathne Nortel Networks 2305 Great America Pkwy Santa Clara, CA 95051 Phone: 408 565 2571 Email: tsenevir@nortelnetworks.com Waldemar Augustyn Email: waldemar@nxp.com Pascal Menezes TeraBeam Networks 2300 Seventh Ave Seattle, WA 98121 Email: Pascal.Menezes@Terabeam.com Marc Lasserre RiverStone Networks 5200 Great America Parkway Santa Clara, CA 95054 USA Phone: (408) 878-6500 Email: marc@riverstonenet.com Senevirathne, et al. Expires-August 2002 13 draft-senevirathne-vmi-frame-02.txt February 2002 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 Senevirathne, et al. Expires-August 2002 14