Network Working Group Tissa Senevirathne(Nortel) Internet Draft Waldemar Augustyn (Nortel) Pascal Menezes (TeraBeam) Category: Informational Marc Lasserre (RiverStone) February 2001 A Framework for Virtual Metropolitan Internetworks (VMI) draft-senevirathne-vmi-frame-00.txt 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 Abstract This document tries to identify requirements, issues, and solutions for Virtual Metropolitan Internetworks. Different VMI models are discussed. The strengths and weakness of each model against customer requirements are analyzed. Senevirathne, et.al, Expires-July 2001 1 draft-vmi-frame-00.txt January 2001 Table of Content 1. Conventions used in this document..................................3 2. Introduction.......................................................3 1.1 VMI Taxonomy and Analogy..........................................4 1.2 Network format(Service Model) for Virtual Metropolitan Internetwork ......................................................................6 1.3 VPN vs. VMI.......................................................6 1.4 VMIS Requirements.................................................6 2.0 VMI Network Model: Many-to-Many network model.....................7 2.0.1 QoS and traffic Engineering.....................................8 2.0.2 Reliability.....................................................9 2.0.3 Reconfiguration.................................................9 2.0.4 Data Security and Authentication................................9 2.0.5 Broadcast and Multicast forwarding.............................10 2.0.6 Transport Mechanism in the core................................10 2.0.7 Layer 2 Address Learning.......................................10 2.0.8 Scaling........................................................11 2.0.9 Service provisioning...........................................11 2.0.10 End point discovery...........................................11 2.0.11 Virtual Service Provisioning..................................12 2.0.12 Address Transparency..........................................12 2.0.13 Class of Service..............................................12 2.0.14 Class of Service Classification...............................12 2.0.15 Bandwidth Allocation and Policing.............................12 2.0.16 End User Packet immunity......................................13 2.0.17 Packet Loss Reports...........................................13 2.0.18 Zero Cost Service Access......................................13 2.0.19. Internet Gateway Function....................................13 2.0.20 Service Gateway Function......................................13 2.0.21 Service Instantiation.........................................13 2.0.22 Service Infrastructure Configuration..........................14 2.0.23 Service Operations Management.................................14 2.0.24 Service Gradation.............................................14 3.0 VMI Network Model: point-to-multipoint or hub and spoke model....15 3.0.1 Transparent Deployment.........................................15 3.0.2 Routable model.................................................15 3.0.3 QoS and Traffic Engineering....................................16 3.0.4 Broadcast and Multicast........................................16 3.0.5 Scaling........................................................16 3.0.6 Redundancy.....................................................16 4.0 VMI Network Model: point-to-point network model..................17 4.0.1 QoS and Traffic Engineering Requirements.......................17 4.0.2 Reliability....................................................18 4.0.3 Data Security and Authentication...............................18 4.0.4 Transport Mechanism in the Core................................18 Senevirathne, et.al. Expires-July 2001 2 draft-vmi-frame-00.txt January 2001 4.0.5 Service Provisioning...........................................19 5.0 Providing VMI for Geographically Distributed Sites...............19 5.1 Native Long Haul.................................................19 5.2 Non-native long haul.............................................20 5.3 Hierarchical Interconnection model...............................20 5.3.1 Transport Layer................................................21 5.3.2 Layer 2 Address Learning.......................................21 5.3.3 Reliability....................................................21 5.3.4 Scalability....................................................21 5.3.5 Administration.................................................21 5.3.6 Accounting.....................................................21 5.3.7 Service Provisioning and end-point discovery...................22 5.3.8 Virtual Service Provisioning...................................22 8. Security Considerations...........................................22 9. References........................................................22 10. Acknowledgments..................................................23 11. Author's Addresses...............................................23 Full Copyright Statement.............................................24 1. 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]. 2. Introduction Over the last several years, the available bandwidth in the core networks has increased dramatically, in the same time offering price per Mbyte has gone down. Most business today has multi site office complexes. Some of these organizations are exploring the opportunity of outsourcing their inter site enterprise network to Application Service Providers. With the possible opportunities in this segment increasing, Service Providers are now rushing to build a new class of networks based on Metropolitan Area Networks. This new class of network intends to provide a virtual Internetwork for customers who wish to connect there geographically dispersed sites using public networks at very high speeds (10Mbps and above). 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). Issues, requirements, architecture and business model of VMI is significantly different than that of the better known Virtual Private Network (VPN) or traditional Internetwork. This document intends to provide a framework for VMIS and documents Issues, requirements, architecture and business model when providing VMIS. Senevirathne, et.al. Expires-July 2001 3 draft-vmi-frame-00.txt January 2001 In addition, several equipment vendors are building products to address this growing market in the Metropolitan Network space. However, there is lack of coordination and definition of the problem. In that aspect, this document attempts to consolidate widely used models and defines the problem space and identifies different solutions. At present there are several infrastructure models used in providing VMIS. In this document we present each of these models separately. Under each model, issues, requirements, architecture and business model is discussed. Both customers and providers define requirements. As an example, a customer may wish to obtain a service that connect multiple sites and requires multiprotocol transport. Based on these requirements, the Service Provider may define that either a need for a CPE (Customer Premise Equipment) or separate connection per service or combination of both. As another example, customer may wish to have end-to-end guaranteed bandwidth. In order to provide this service, provider may have different set of requirements that customer have to meet. Business model, in the past, was mainly dictated by the service providers. Here we envision that, business model is something that is customized based on the requirements. The architecture and issues are direct dependents of the requirements and business model. Hence, it is important to well define and understand the requirements and the business model. Architecture of the VMIS defines the entire infrastructure that requires satisfying the requirements within an agreed business model. The architecture of the infrastructure include, but not limited to, the backbone transport layer mechanism, network management and accounting, Traffic Engineering and QoS issues etc. Hence, with a given infrastructure one may only be able to satisfy some subset of requirements and business models. Hence in this document we presents, different infrastructure models and try to identify and underline the types of requirements and business models that can be satisfied within the architecture. When delivering requirements within a business model with a given infrastructure, there are always issues and problems, we try to identify and present those issues in this document. This document is considered a living document and may change, as more information and deployment scenarios become available. 1.1 VMI Taxonomy and Analogy In this section we define Taxonomy and Analogy of Virtual Metropolitan Internetwork. Defining the taxonomy facilitates proper Senevirathne, et.al. Expires-July 2001 4 draft-vmi-frame-00.txt January 2001 definition of the problem in hand; Virtual Metropolitan Internetwork. VMI Taxonomy: 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 an End User. 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. In general, a VMI is composed of point-to-point, point-to-multipoint and multi-point-to-multi-point. Any combination of these topologies can be accommodated in a VMI. VMI Analogy: Given the above taxonomy or the definition of the Virtual Metropolitan Internetwork, following analogy is drawn. VMI is considered as stack of dices on a base, or "Tower of Hanoi". Each of these dices represents a separate virtual network. The base represents the Infrastructure. Pin in the middle represents the management plane. | ----------------- | | VMI-2 ----------------- | | | <--------- Service Management | | ----------------- | | VMI-1 ----------------- | ----------------- | | Infrastructure Senevirathne, et.al. Expires-July 2001 5 draft-vmi-frame-00.txt January 2001 ----------------- 1.2 Network format(Service Model) for Virtual Metropolitan Internetwork Presently there are several models that are used to provide VMI Services. Each of these models may suites to 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 customer may need based on the requirements. In subsequent sections each of these service model is analyzed in detail. o Fully meshed; many-to-many network model o Partially meshed; point-to-multipoint(hub and spoke) model o point-to-point model o hierarchical, multi domain model 1.3 VPN vs. VMI Understanding the key differences between VPN and VMI is important. This understanding facilitates one to appreciate the problems, issues, and strength and business model of VMI clearly. o Service. In simple terms, VMI is a service, while VPN is a technology. A VMI specification is broader than that of a VPN, covering areas that VPNs typically consider beyond their scope. o User/Provider Context. VMI recognizes the demarcation between the User and the Provider and the consequences of asymmetric responsibilities and expectations. The Provider is the entity that offers its services to the receiving entity, the User. o Gateway Functions. VMI networks, similarly to VPNs, are private, intended for interconnecting sites belonging to the same administrative entity. Unlike VPNs, however, VMIs define optional Provider Gateway Functions, which are methods for secure access to VMI networks for the purpose of supplying additional network services. 1.4 VMIS Requirements VMIS requirements derive the service model. VMIS requirements can be broadly classified into several areas. o number of sites that required to be connected. Senevirathne, et.al. Expires-July 2001 6 draft-vmi-frame-00.txt January 2001 o Required network topology; hub and spoke with all sites connecting to the data center or fully meshed emulated Local Area Network or combination. o Type of connectivity required; Layer 2 or IP routing. o Traffic engineering and QoS requirements; end-to-end guaranteed bandwidth. 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, faults, etc. o Gateway Functions; option for the Provider to offer extra services on the private VMI networks. 2.0 VMI Network Model: Many-to-Many network model ------ ------- 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 Senevirathne, et.al. Expires-July 2001 7 draft-vmi-frame-00.txt January 2001 Many-to-Many VMI network model is ideally suited for customers who wanted 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 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. The PE devices providing Many-to- Many service model requires handling some special situations, these issues are presented in this section. 2.0.1 QoS and traffic Engineering Customers may now wish to have same QoS and Traffic Engineering characteristics as they are in a Locally connected network. Hence, now the problem is not providing end-to-end QoS service but an issue of providing Network wide QoS and traffic engineering. However, in general, a given flow, whether Layer 2 or 3, is point-to-point in nature. On the other hand, broadcast and multicast nature of Local networks can be emulated using set of fully meshed point-to-point networks. In theory, this simplifies the problem and it is an issue of 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 theory, it is possible to have different sites with varying Traffic engineering parameters. In such a configuration it is important that participating nodes have knowledge of the requirements of the other nodes and impose shaping and policing appropriately. 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 Senevirathne, et.al. Expires-July 2001 8 draft-vmi-frame-00.txt January 2001 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. 2.0.2 Reliability Different customers may require different levels of reliability. The reliability here defined as, protection against in advent infrastructure or control plane failures. Protection against such failures needed to be built in to the infrastructure and backbone transport protocol. 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. On the other hand, these levels of reliability may be included in Service Level Agreement (SLA) and may be part of the contractual 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. In the same time, these levels of protection may be essential for operation of their applications. 2.0.3 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. 2.0.4 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 (IPSec) to provide privacy, but with VMI service offerings of 1Gbps this opens a new set of performance 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 end users. The Senevirathne, et.al. Expires-July 2001 9 draft-vmi-frame-00.txt January 2001 level of security is low, it protects against attacks from other End Users, but not 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. Due to the many-to-many connectivity nature of the topology under discussion in this section, Security Association establishment and Encryption key distribution become more complex. Security Architecture for many-to-many networks is presented in [3]. It discusses security architecture of common access networks based on a case study related to VMI. 2.0.5 Broadcast and Multicast forwarding In the many-to-many network not all links have the same transport layer characteristics. Broadcast, multicast packets are required to be replicated to multiple links with different characteristics. When providing Layer 2 connectivity the Provider Edge devices are required to replicate unknown unicast packets as well. Hence, the Provider Edge devices that are providing many-to-many connectivity MUST have methods to replicates packets over different transport layer characteristics. 2.0.6 Transport Mechanism in the core There are multiple transport layer mechanisms that are capable of providing the many-to-many network layer connectivity. Choice of the appropriate transport layer depends on the set of above requirements that a given service provider address. As an example, on the simple side one 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 service provider chooses to support the entire set of requirements, he may choose more sophisticated protocol like MPLS. In theory, it is possible that multiple transport layer protocols 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 layer mechanisms (MPLS) within its footprint and another (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. Obviously, various usage policies (QoS) would have to be different based on the available resources. However, it is perceived that most Service Providers would implement a single transport layer mechanism in the core. 2.0.7 Layer 2 Address Learning Senevirathne, et.al. Expires-July 2001 10 draft-vmi-frame-00.txt January 2001 If the transport mechanism used in the core is based on layer 2, it is possible that the devices in the middle are required to learn a large number of MAC addresses. In addition they may be required to perform forwarding based on different customer contexts. If this is chosen then the MAC Forwarding data MUST remain unique per VLAN to eliminate multiple sites having the same MAC address (Decnet, SNA etc..) If one choose to tunnel layer 2 traffic across the core, the address learning and forwarding decisions are only limited to the Provider Edge devices. Thus helping to scale better. Most devices have a finite number of MAC addresses they can support. A Denial of Service attack can be easily performed by blasting large amount of MAC addresses into the network. Hence, PE devices should have methods to limit the number of MAC addresses learned from a given port. 2.0.8 Scaling It is important that the many-to-many VMIS architecture is able to support larger number of customers with each customer having multiple sites that require many-to-many connectivity. The summation of number of sites per customer over the number of customers provides a benchmark for scaling. This benchmarking parameter is defined as the "gold weight". The larger the "Gold Weight" the better profit margin and growth of the business for Service Providers. 2.0.9 Service provisioning Based on the transport layer mechanism that is deployed it may be required to perform service provisioning along the path taken between the site. If there is a need for larger customer base with complex requirements, manual provisioning may be administratively prohibitive. In such a situation, use of automatic discovery and signaling protocols facilitates network management. Any automatic signaling of provisioning must have the ability to scale across a global network and affect all the providers involved (hierarchical switching would provide this solution). Additionally, the signaling layer must have visibility into path creation to enforce any constrains required. 2.0.10 End point discovery End points of participating sites may be required to establish the transport layer connectivity. These end-points may be either manually configured or learned via some routing protocol. OSPF Opaque LSA are one such popular protocol extension that is used to learn end points of the participating devices. [4] Presents how OSPF Opaque LSA may be used to discover different Layer 2 reachability. Senevirathne, et.al. Expires-July 2001 11 draft-vmi-frame-00.txt January 2001 2.0.11 Virtual Service Provisioning A customer may wish to perform his own assignments and administration of the addressing, including layer VLAN tagging. Customers ability to perform such administration, creates a truly Virtual Enterprise network extension. All the building blocks in the VMI architecture, including the transport layer, need to participate in order to build a VMI service with virtual service provisioning requirement. A customer's VLAN tag must be able to be encapsulated in the transport layer mechanism, to provide transparency. 2.0.12 Address Transparency An end user considers a VMI to be a totally transparent network. Packets, headers and payload, are transferred unaltered. Broadcast, and multicast addresses are recognized and treated accordingly. VLAN tags are preserved, if present. 2.0.13 Class of Service A VMI recognizes a range of traffic categories. The categories have significance only within a given VMI. The availability and allocation of different traffic categories is defined by a Service Level Agreement and enforced by the Providers VMI Infrastructure. 2.0.14 Class of Service Classification A VMI distinguishes guaranteed delivery traffic and best effort traffic. Within each of these two categories, one or more priorities can be further distinguished. The guaranteed category of traffic may also allocate particular latency and jitter commitments to one of its stated priorities. The ProviderĘs VMI Infrastructure implements a traffic classification filter that allocates end users traffic to each category based on pre-determined SLA. The classification and enforcement is significant only within a VMI. 2.0.15 Bandwidth Allocation and Policing The amount of traffic bandwidth allowed to flow within a VMI, total as well as for each traffic category, is determined by a SLA agreement. The provider implements traffic policing mechanisms to enforce the SLA. For the traffic coming into the ProviderĘs network, the maximum bandwidth limits are enforced. The end user may implement traffic shaping mechanisms to avoid unnecessary packet drops. Senevirathne, et.al. Expires-July 2001 12 draft-vmi-frame-00.txt January 2001 For the traffic leaving the ProviderĘs network, the maximum bandwidth limits are enforced. The Provider may offer a back-off signaling mechanism to aide traffic shaping for the source. 2.0.16 End User Packet immunity VMI services do not rely on the global uniqueness of end users addresses, such as MAC addresses, or any addresses. Of course, the addresses must remain consistent within each VMI for useful service. Nevertheless, the ProviderĘs infrastructure is immune to the End User misaddressed, invalid, corrupted, or maliciously altered packets. 2.0.17 Packet Loss Reports A VMI service provides an integrated packet loss reporting system for signaling legitimate packet drops. A legitimate packet drop is defined as a discard of an end userĘs packet for reasons other than network failure. The typical reasons are: o Source rate higher than VMI SLA o Destination VMI SLA below source rate o Destination flooded by traffic from many sources o Best effort congestion Packet drops due to network failures are not reported. A packet drop due to congestion for a guaranteed traffic is considered a failure. 2.0.18 Zero Cost Service Access A VMI service is offered to the end user without a need for any devices located on the end user premises. This is called zero cost service access, the Provider can provision and modify the service without the need to install or modify any equipment on the customer premises. A physical connectivity means, e.g. a fiber cable, must exist. 2.0.19. Internet Gateway Function A VMI is quintessentially a private network service. The Internet gateway function is a Provider side facility which allows to tie a VMI to the Internet at large. This is applicable only to IP traffic. 2.0.20 Service Gateway Function Similarly, the Service gateway function is a Provider side facility which allows the Provider to inject extra services to a VMI which otherwise remains private. It could be used for offering popular IP services such as DNS, DHCP, etc. 2.0.21 Service Instantiation Senevirathne, et.al. Expires-July 2001 13 draft-vmi-frame-00.txt January 2001 It is possible to create several instances of VMI service infrastructures sharing the same equipment within a network provider. For example different wavelength can be dedicated to different VMI service instances in a WDM systems. Similarly, SONET transport system can be partitioned based on STS-1 frames for different VMI systems. This capability extends wholesale opportunities for Providers. 2.0.22 Service Infrastructure Configuration The infrastructure for VMI services, the base of the Tower of Hanoi, is a collection of a wide range of network equipment. Typically, a combination of SNMP, TL1, and CLI tools are used for setting this equipment up. It is beyond the scope of this draft to define what tools should be used for this purpose. 2.0.23 Service Operations Management The operations of VMI services are managed through a set of directory based protocols and servers. The equipment participating in the VMI operations pulls the necessary service parameters and configuration from directory based servers. This function represents the pin in the Tower of Hanoi. 2.0.24 Service Gradation Not all VMI deployments will support all VMI features. If certain features are not supported by the infrastructure, the related SLAs would denote these exceptions. For example, it is conceivable that in certain situation, the infrastructure would not be redundant but still provide useful, perhaps less expensive, VMI service. Similarly, guaranteed service may not be offered by many infrastructures but the remaining best effort service could still be offered as a VMI service. It is useful to list major gradation of VMI service capabilities o High or standard reliability o Ability to offer guaranteed service o Limited distance scope or global reach o Internet gateway function availability o Service gateway function availability o Packet drop reporting o Traffic encryption or simple separation Conversely, it is useful to list the minimum set of capabilities o L2 private network service o Full support for L2 unicast, broadcast and multicast o Preservation of L2 headers, including VLAN tags if present o Ingress/Egress bandwidth policing o Full end user traffic separation Senevirathne, et.al. Expires-July 2001 14 draft-vmi-frame-00.txt January 2001 o Full MAC address space independence 3.0 VMI Network Model: point-to-multipoint or hub and spoke model The point-to-multi-point model is subset of multi-point-to-multi- point model that was presented earlier. Point-to-multi-point model may be used by 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-multi-point network may provide, additional services that were beyond the capability of classical frame relay networks. The point-to-multi-point VMI deployment model may be used either as address transparent model or routable model. In the address transparent model, customers may consider the VMI as a virtual and transparent extension to their Local Network, or in other words, VMI infrastructure appears as a physical connection. In the routable model the VMI access points may be considered as belong to the same sub-network. Thus VMI edge devices providing routing functionality. However, customers may wish to maintain there private address space shielded from the VMI control plane. In the same time, VMI service providers may not wish to maintain customer address space. As such, VMI infrastructure may require to have technologies that could transport customer's traffic using some local addressing and transport mechanisms. 3.0.1 Transparent Deployment The Transparent point-to-multi-point deployment model is mainly used by the customers who wish to extend the Local Network over the VMI without any network layer address translation. In other words; all the sites appears as access point in the same Local Network. Due to the anatomy of the point-to-multipoint 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. 3.0.2 Routable model Senevirathne, et.al. Expires-July 2001 15 draft-vmi-frame-00.txt January 2001 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. In 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. 3.0.3 QoS and Traffic Engineering There are two QoS and traffic models used in point-to-multipoint deployments. The remote sites maintain the same QoS and Traffic model as the point-to-point deployment and the issues, and requirements are similar. The central site or the hub site is analogues to a site in many-to-many network. Hence, the issues, requirements and solutions are similar to that of many-to-many deployment model. 3.0.4 Broadcast and Multicast Broadcast and multicast forwarding issues are different at remote sites and hub site. At the remote sites the forwarding policies are similar to those applied in point-to-point networks. At the hub site forwarding policies becomes more complex based on whether remote- site to-remote site connectivity needed and whether transparent deployment model or routable model is in place. Such forwarding polices may be include as part of the Service Level Agreement (SLA). 3.0.5 Scaling For the VMI service providers point-to-multi point model give a better "Gold weight" (Gold Weight is defined in section 2.0.8) as compared to many-to-many networks. This is mainly due to reduction in number of circuits that are deployed in the core. Such spare connections may be sold to other customers. In the perspective of customers; they may save lots of dollars if connectivity between significantly larger amount of sites are needed. However if customer requires inter site connectivity in a point-to-multipoint deployment then VMI service provide is required to define and apply some complex set of forwarding policies. VMI service providers may charge extra for such specialized service policies. On the other hand, VMI service providers may require supporting large amount of such policies if they wish to increase the rate of return or the "Gold Weight". 3.0.6 Redundancy 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 Senevirathne, et.al. Expires-July 2001 16 draft-vmi-frame-00.txt January 2001 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. On the other hand, in point to multipoint deployment scenarios redundancy is required to be provided between the hub site and the remote sites. Thus offered SLA may be cheaper for the customer and administratively simpler for the VMI service 4.0 VMI Network Model: 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 to provide variety of service 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 using other service models may not be possible. In order to better discuss the requirements and issues in point-to-point networks, in this document, VMI services are broadly classified in to two categories. 1. The VMI services that require data services, either in packet or cell form are called Data service VMI (DSVMI). 2. 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). The point-to-point VMI service is different to tradition VPN in several fronts. The Virtual Private Networks (VPN) are considered a transport method between two end points. Where as point-to-point VMI services are a service provided between two end points. The service provided may not limited to data only. In traditional VPN, redundancy, reconfiguration etc were the responsibility of the end users. In the point-to-point VMI services such services are provided by the VMI service provider and may be part of the Service Level Agreement (SLA). Most traditional VPN services are IP centric. Whereas VMI services are not only protocol agnostic it can also provide virtual extensions to different Layer 1 circuit such as TDM circuits. The VMI services are considered to be extension to the Local Network. Where as VPN are considered an Inter Network connection. Thus certain requirements, such as QoS, in VMI require being of the same level as Local Area Network, where as such requirements may be considered in terms of Wide Area Network Perspective in VPN. 4.0.1 QoS and Traffic Engineering Requirements The QoS and Traffic engineering service in Data Service VMI is to provide end-to-end QoS and Traffic Engineering requirements as per the SLA. The Service provider may offer several flavors of SLA with different QoS and Traffic Engineering characteristics. Or Service Provider may customize the SLA around the customer business needs. In either case VMI infrastructure is require to have capabilities to Senevirathne, et.al. Expires-July 2001 17 draft-vmi-frame-00.txt January 2001 cater for these different QoS and Traffic Engineering need. These capabilities include the Transport Layer, Network Management and end equipment. 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. Customers who wish to extend transparently connect two geographically dispersed data networks may choose DSVMI. They may wish to consider the extension transparent to the users, in terms of latency, delays etc.. As such SLA may require VMI service providers to offer QoS and Traffic Engineering characteristics as in the Local Networks. 4.0.2 Reliability The customers who purchase VMI services may request the VMI service provider to support the needed Reliability. The method of providing the required reliability level depends on several factors. Firstly, the SLA specifies the required reliability parameters such as fail over time and accepted data loss. Secondly, the type of VMI service that is needed. As an example, methods for providing reliability service for Circuit Emulation VMI (CEVMI) may be different from methods for providing Data Service VMI (DSVMI). When providing certain Circuit Emulation VMI, providers are required to maintain timing requirements. 4.0.3 Data Security and Authentication 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. On the other hand some customers may wish to have an on premise security solution. Specially, CEVMI customers may use a front-end scramblers/encrypters. 4.0.4 Transport Mechanism in the Core The choice of the proper transport mechanism depends on the requirements of the SLA and the technology. Senevirathne, et.al. Expires-July 2001 18 draft-vmi-frame-00.txt January 2001 When providing CEVMI the transport layer should be able to tunnel the circuits over the VMI infrastructure. The transport layer in the VMI core should be capable of supporting, end-to-end timing, and emulation of Time Division Multiplexed (TDM) circuits. Generalized MPLS presented in [], provide a solution based on MPLS. Chosen Transport method should be able to provide, required reliability, end-to-end timing, service provisioning etc, as agreed upon the SLA. When providing DSVMI, at least, following issue are required to be taken into consideration to select a Transport Mechanism; end-to-end QoS, type of payload (Layer 2/ IP), reliability, reconfiguration. 4.0.5 Service Provisioning Based on the Service Level agreement, it may be required to provide end-end service provisioning. Service provisioning in point-to-point networks may be simpler than many-to-many networks. However, when maintaining large customer base such manual configurations may be administratively prohibitive. It may be beneficial to have some automatic service provisioning methods. The automatic service provisioning may appear as either a signaling protocol (such a RSVP- TE) or system wide network management system. 5.0 Providing VMI for Geographically Distributed Sites In general, VMIs are intended for connectivity between sites located within a metropolitan reach. However the notion of metropolitan reach may not necessarily imply geographic proximity. Geographic distances may vary significantly, in many cases exceeding the limits of the underlying technologies used to build the VMI infrastructure. In these cases, additional technologies may be employed for the sole purpose of spanning wide geographic distances. These technologies are called long haul. 5.1 Native Long Haul Here, we define Native Long Haul as the ability to extend the geographic reach while keeping the same, common infrastructure and preserving the service management of the original local network. Referring to the analogy of the Tower of Hanoi, if the base of the tower and its pin remain the same, the long haul extension is native.. As an example, if the local network is based on optical technology and if there exists an optical technology based means to connect the sites that are located outside the local domain, but comprise the same infrastructure and are managed by the same operations system, that is considered a native long haul. On the other hand if the sites are connected using some other technology (such as frame relay_in the otherwise all Ethernet network) then it is considered a non-native long haul. Senevirathne, et.al. Expires-July 2001 19 draft-vmi-frame-00.txt January 2001 Native long haul may not be well suited for all network models. When connecting sites that require many-to-many connectivity then native long haul may not be financially viable. On the other hand if the network model is point-to-multipoint (hub and spoke) and there are only relatively few sites that requires longer geographic reach, then native long haul is financially viable and technologically feasible. 5.2 Non-native long haul It is possible to extend the geographic reach using non-native long haul methods. However, these methods must meet the same requirements applicable to native methods, such as end-to-end traffic engineering, reliability etc. 5.3 Hierarchical Interconnection model In some situations, like many-to-may connectivity model, native long reach may not be feasible. The hierarchical interconnection model presented here provides a method to achieve VMI service across geographically dispersed site. 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 | | | | | | | | | | | -------- --------- | | | --------------------------- -------------------------- Senevirathne, et.al. Expires-July 2001 20 draft-vmi-frame-00.txt January 2001 Sample Hierarchical Interconnection model 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.1 Transport Layer The transport layer method outside the confederates should be able to provide required services. This may include, but not limited to, end to end traffic engineering, tunneling of non-native data, reliability and resilience. In order to have a non-fragmented consistent network service, all devices are required to support common and adequate transport layer mechanism. MPLS appears to be a promising choice for this environment. However, this document does not limit the scope of selection of such transport layer methods. 5.3.2 Layer 2 Address Learning In the above hierarchical Internetwork model, the device outside the local confederate should not perform forwarding based on customer MAC addresses. Instead, when providing layer 2 services, forwarding should be performed using some other mechanism. In other words, devices outside the local confederate provide tunneling services. 5.3.3 Reliability The reliability of the local confederate depends on the chosen VMI model and SLA. The devices outside the local confederate should be able to provide required reliability. This may include the equipment level and transport layer level. 5.3.4 Scalability The network topology outside the local confederate requires to scale to potentially large amount of inter site transit tunnels and traffic. 5.3.5 Administration With the type of diversity in the hierarchical interconnection model, it is possible that the local confederates belong to different autonomous systems. Hence, the routing, control plane and discovery should have knowledge of the inter AS nature. 5.3.6 Accounting There should be a comprehensive accounting system so customers can be eventually charged properly. Flat service model or bandwidth wholesale may not work well in the hierarchical network model. Senevirathne, et.al. Expires-July 2001 21 draft-vmi-frame-00.txt January 2001 5.3.7 Service Provisioning and end-point discovery Due to the diversity of end points, system wide network provisioning may be administratively prohibitive. It may be better if the provisioning is performed at the end points and control protocol or signaling method be used to automatically provision the service requirements. A good example for this is MPLS RSVP-TE and CR-LDP. On the other hand it is important to discover the endpoints. This may be achieved either using IGP or some EGP protocol. [4] presents how end points may be discovered using OPSF opaque LSA. [5] presents how these discoveries are done across Autonomous Systems using BGP-MP extensions. 5.3.8 Virtual Service Provisioning Some customers require a SLA that allows self-provisioning and administration of the inter site VMI. Virtual Service provisioning requires that all-participating providers and equipment has capabilities to support Virtual Provisioning. Supporting such a SLA in a multi-vendor, multi-owner, geographically dispersed infrastructure may be a difficult task. As such it is anticipated, at least for now, Virtual Service Provisioning may not be available in hierarchical inter-connection model. 8. Security Considerations This document does not discuss specific security solutions. This document, however identify and state the security requirements in Virtual Metropolitan Internetworks. 9. 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., and et.al., "Security Architecture for Common Access Data Networks - A Case Study based on Virtual Metropolitan Internetwork", Work In Progress, December 2000. 4 Senevirathne, T., and Billinghurst, P., "Distribution of 802.1Q VLAN information using OSPF Opaque LSA", Work In Progress, October 2000. 5 Senevirathne, T., and et.al., "Distribution of 802.1Q VLAN information using BGP-MP extensions", Work in Progress, November 2000. Senevirathne, et.al. Expires-July 2001 22 draft-vmi-frame-00.txt January 2001 10. Acknowledgments The on going work at the IETF and the work presented in the sighted 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. 11. 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 Nortel Networks 600 Technology Park Billerica, MA 01821 Phone: 978 288 4993 Email: waldemar@nortelnetworks.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-July 2001 23 draft-vmi-frame-00.txt January 2001 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-July 2001 24