Jim Guichard, Editor Internet Draft Cisco Systems Inc Expires: April 2006 Martin Halstead Nexagent Inc Requirements for Multi Autonomous System VPN services Draft-halstead-guichard-MAVS-requirements-00 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document defines common requirements exhibited by the parties that contribute towards providing VPN services that span multiple service providers networking footprint. These requirements are not VPN technology specific. 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. Table of Contents 1. Introduction.........................................2 2. Definitions.........................................2 3. Problem Statement....................................3 4. Service Provider MNE Requirements.......................3 4.1. Capital Scaling Requirement........................3 4.2. Operational Scaling Requirement.....................4 4.2.1. Service Independence Requirement................4 4.2.2. Minimize Network Integration Requirement.........4 Halstead/Guichard Expires April 7, 2006 [Page 1] Draft-halstead-guichard-MAVS-requirements October 2005 4.3. Service Provider VPN Policy Control..................5 4.3.1. End-to-end QoS Policy Requirement...............5 4.3.2. VPN Topology Requirement.......................5 4.3.3. Optimal Interconnect Selection Requirement........6 4.3.4. End-to-End Unicast Routing.....................7 4.3.5. End-to-end Unicast Routing Policy Requirement.....7 4.3.6. End-to-End Multicast Routing Requirement.........7 4.3.7. Homogenous Measurement Requirement..............7 4.4. Non-MPLS Technology Requirement.....................8 4.5. Remote Service Interconnect Requirement..............8 4.6. Redundant Interconnect Requirement..................9 4.7. Security Requirement..............................9 4.8. Third Party Interconnect Requirement.................9 5. Policy Authority MNE Requirements......................10 6. Conclusions........................................10 7. Acknowledgments.....................................10 8. References.........................................11 8.1. Normative References.............................11 8.2. Informative References...........................11 9. Author's Addresses...................................11 10. Intellectual Property Statement.......................11 11. Disclaimer of Validity...............................11 12. Copyright Statement.................................12 13. Acknowledgment.....................................12 1. Introduction This document summarizes a list of common requirements specified by all parties involved in the delivery of VPN services that span multiple Autonomous Systems on behalf of their end customers. 2. Definitions In order to fulfill the customers’ requirement for multi service provider VPN services, it is necessary to define the parties that contribute towards providing the VPN service. Some of the terminology used in this document is taken from [PPVPN-TERM] and [RFC4031]. Additional terminology specific to multi provider VPN services is defined as follows: Multi Network Environment (MNE): Two or more Autonomous Systems that share VPN service endpoints (sites) of a common subscriber Service Provider (SP): For the purposes of this document a Service Provider is defined as any operator that utilizes their private network footprint for the delivery of VPN services. Examples include Halstead/Guichard Expires April 7, 2006 [Page 2] Draft-halstead-guichard-MAVS-requirements October 2005 Transport Service Providers, Systems Integrators, Cable Operators, and Mobile Operators. Policy Agent (PA): The authority/authorities responsible for fulfilling the customer’s requirements for the enforcement of a set of policies within a MNE. Typically a PA will exist per SP, and are assumed to communicate between all relevant PA parties to agree upon the enforcement of consistent policies for VPN service provisioning purposes. The customer may be responsible for specifying their MNE service policy. Alternatively, the customer may define their routing requirements and outsource their MNE service policy to a customer agent such as a Service Provider, Systems Integrator, Cable Operator, Mobile Operator or Virtual Network Operator who in this case would be one of the possible PA involved in the enforcement of policies related to the provisioning of a VPN service. VPN Peering Location (VPL): A physical location where two or more SP VPN service domains are connected. Examples of VPLs include a network operator hotel, SP central office, a collocation facility or any building common to two or more SPs. 3. Problem Statement No single network can deliver VPN services that provide optimal price and performance for all customers or all customer locations. For regulatory, resiliency and other reasons, customers may demand that multiple SP networks are used to deliver their VPN services. As a result, customer agents, acting as the PA have started to interconnect multiple service provider networks via a PO to meet their customers’ VPN needs. For a PA’s customers, end-to-end service delivery is paramount. Controllable, predictable and reliable service must be delivered regardless of the MNE. The challenge for the PO in controlling ‘global’ service policy in an MNE environment is the lack of homogenous policy amongst SP networks and the difficulty SPs have in adapting their single SP VPN service domains to the PA owned VPN service policy. This document defines common requirements for implementing and operating an MNE from the perspective of the customer, SP, and PA. 4. Service Provider MNE Requirements 4.1. Capital Scaling Requirement In an MNE, there might be one or more VPLs. In each VPL there may be one or more interconnected SPs. Traditionally, the interconnection of two SPs, the so called bilateral interconnect, has resulted in the Halstead/Guichard Expires April 7, 2006 [Page 3] Draft-halstead-guichard-MAVS-requirements October 2005 deployment of network elements dedicated to those two SPs. Where there is a need for a SP to interconnect with multiple other SPs, a scaling cost-efficiency could result if interconnected network elements could be shared across all SPs. This multilateral approach to network interconnects would have increasing benefit as the number of interconnected SPs at a VPL increased. Interconnected network elements in a MNE must therefore be shared multilaterally. 4.2. Operational Scaling Requirement Cost of operations is of great concern to a SP. Compared to the capital cost of MNE interconnection, operational cost easily dominates. In an MNE of multiple network operators and multiple interconnects, some, and perhaps all, might play a part in an individual customer solution. Within a customer solution, sites, physical and logical connectivity, network operators, interconnects and service policy might be variously moved, added, changed or deleted (MACD) at any time. In fact, different components of the solution will, at times, undergo MACD concurrently. Service MACD lifecycle is part of any customer solution and will happen as needed throughout the service life. As an MNE evolves, with increasing network operators, interconnects and customers, the amount of service MACD will increase and place a continual and increasing burden on service administrators throughout the MNE unless a scalable approach is taken. Some of the more important operational scaling considerations follow. 4.2.1. Service Independence Requirement In an MNE environment, it is inevitable that dependencies will exist between the services of individual SPs. For example, a lack of forethought by the PO by implementing a ‘tightly-coupled’ interconnect environment would result in single SP changes to topology, bandwidth, routing, QoS etc requiring all other SPs to modify their definitions of existing services. Service dependencies amongst SPs in a MNE must therefore be minimized. 4.2.2. Minimize Network Integration Requirement Currently there is no agreement for how SPs will implement the interconnection of their VPN networks. This means that each instance of interconnection by SP pairs will be a unique project with different design goals and compromises. Each unique project will take considerable time and consume highly skilled resources in both organizations. As the number of interconnects increases, so the load on the organizations will increase. In an MNE, the required number of unique interconnection projects could rapidly become untenable. Halstead/Guichard Expires April 7, 2006 [Page 4] Draft-halstead-guichard-MAVS-requirements October 2005 Unique network integration projects amongst SP pairs must therefore be minimized. 4.3. Service Provider VPN Policy Control 4.3.1. End-to-end QoS Policy Requirement Currently, there are no standards for or agreement of service definitions amongst network operators. Consequently, network operators deploy a different number of classes of service (COS) and specify service definitions in proprietary ways. From a customer perspective, fixed mappings of classes of service between any two network operators will result in compromised service across the two. This is in part because fixed mappings cannot utilize the full service envelope available from the interconnected network operators (a network operator with three classes of service can only utilize 3/5ths of the service envelope of a network operator with five classes of service). In part, it is also because a fixed mapping may be adequate for some customers, but not for others. This is because QoS policy is often applied in different ways for each application in each customer. Sometimes application QoS policy can vary within a single customer. When three or more network operators are used to provide connectivity between customer sites, two or more interconnects is required and, therefore, a multiple, compounding service compromise exists. In an MNE of many network operators and many interconnects, it is clear that numerous and compounding compromises in service will take place and end-to-end QoS policy cannot exist. There is a requirement, therefore, for a relationship to exist between network operator classes of service that is variable per customer and that can also utilize the full service envelope of all network operators within an MNE. In addition, for some customers who have implemented a QoS policy amongst some or all of their business locations, it is crucial that an MNE does not modify that policy in any way. Sometimes this need is characterized as QoS transparency, where the transparency in question refers to the passing of the enterprise QoS policy, unmodified, from ingress to egress of a telecommunications service. There is a requirement, therefore, for enterprise QoS policy transparency throughout an MNE. 4.3.2. VPN Topology Requirement Although VPN networks offer the possibility for any customer site to communicate directly with any other customer site, in certain situations this is not desirable. There are many possible reasons why a customer might want to restrict communication amongst sites so that their end-to-end service becomes segmented. For instance, it may be that security is a concern or it may be that company sites or Halstead/Guichard Expires April 7, 2006 [Page 5] Draft-halstead-guichard-MAVS-requirements October 2005 divisions must only use connectivity they have paid for. Furthermore, the traffic flows associated with specific applications may require a partial topology specifically sized to accommodate the aggregate traffic flows. The segmentation might need to exist on a geographical basis, region- by-region, country-by country, or on a corporate basis, division-by- division or site-by-site. Segmentation might even exist within customer sites. However, today, there are no standards for or agreement of how VPN topologies are constructed amongst network operators. Consequently, network operators use different methods for establishing the logical topology of a VPN and use different schemas to define VPN membership. For instance, one network operator might use standard community values to establish layer-2 topology whilst another might use extended community values. Yet another network operator might use a combination of both. Alternatively, network operators might segment VPNs using layer-3 routing techniques. In fact, some network operators might combine layer-2 and layer-3 segmentation techniques. Additionally, each network operator will implement a schema for VPN membership that is proprietary, with membership values that are likely to overlap and conflict with other network operator values. VPN membership schemas tend to be difficult to modify due to the ‘hard coding’ of the schema in each network operator’s OSS and BSS. Conflicting VPN membership schemas and different methods for establishing logical topology make it very difficult for the MNE operator to establish an end-to-end VPN topology. There is therefore, a requirement to be able to establish an end-to-end VPN topology throughout an MNE. 4.3.3. Optimal Interconnect Selection Requirement Network operator multi-homing is the scenario in which a network operator needs to interconnect at two or more VPLs. By ensuring that traffic passes between networks at pre-determined, optimal VPLs, the desired end-to-end service policy can be established and retained for any two customer sites and network operator networks can be utilized most efficiently. As an example, consider a customer site in the middle of the USA. It is connected to a network operator that is interconnected in both New York and Los Angeles. Traffic must be sent to Tokyo via the LA interconnect and not via New York in order to minimize latency. From a network utilization perspective, routing Tokyo-bound traffic via New York incurs an inefficient, resource- consuming round trip traversal of the USA. Similarly, the same site might also send traffic to London. The optimal route for this traffic will be via New York rather than LA. For multi homed network operators, there is therefore, a requirement for interconnects to be Halstead/Guichard Expires April 7, 2006 [Page 6] Draft-halstead-guichard-MAVS-requirements October 2005 optimally selectable for each source-destination site pair within an MNE. 4.3.4. End-to-End Unicast Routing 4.3.5. End-to-end Unicast Routing Policy Requirement Today there are no standards for, or agreement of, how VPN routing policy is implemented amongst network operators. Consequently, network operators implement routing policy within a defined customer topology in different ways. Conflicting routing policies amongst network operators make it very difficult for the MNE operator to establish an end-to-end unicast routing policy. There is, therefore, a requirement to be able to establish an end-to-end unicast routing policy throughout an MNE. 4.3.6. End-to-End Multicast Routing Requirement Multicast has for some time, been used by applications within local area networks, but almost never across wide area networks. That is starting to change and, as a result, some network operators have begun to enable multicast at key nodes in their networks. Today however, there are no standards for, or agreement of, multicast deployment policy amongst network operators. As a result, network operators implement multicast using various different, non- compatible, methods for establishing multicast topologies. Despite these differences, MNE operators must provide multicast service on an end-to-end basis in an MNE. There is therefore, a requirement to be able to establish an end to-end multicast routing policy throughout an MNE. 4.3.7. Homogenous Measurement Requirement Currently, there are no standards for, or agreement of, measurement methods amongst network operators. Network operators define measurements differently and measure different things. In an interconnected environment, measurement methodology differences, particularly differences in the statistical nature of the measurements, make it impossible to combine network operator measurement reports so that end-to-end service can be analysed. In fact, as network operator reports can be so different, it is also laborious and time consuming to analyse whether an individual network operator has met their performance targets. When end-to-end service fails, it is very difficult to analyse network operator measurement data to detect and isolate faults amongst network operators. In an MNE, where the operator is responsible for end-to-end service, this is untenable. In addition, whilst windows for scheduled and Halstead/Guichard Expires April 7, 2006 [Page 7] Draft-halstead-guichard-MAVS-requirements October 2005 unscheduled maintenance will remain difficult for the MNE operator to control or coordinate, any measurement methodology must take these windows into account in any SLA calculations that are made. There is, therefore, a requirement for statistically homogenous measurement throughout an MNE as well as the ability to place measurement instrumentation/sources at interconnects to aid fault detection and isolation. 4.4. Non-MPLS Technology Requirement MPLS technology is undoubtedly the technology of choice in current MNE deployment. But, as MPLS technology is maturing, its widespread deployment is far from complete. Networks based on prior technologies such as ATM and Frame Relay reached near complete deployment many years ago. In some countries, there is little alternative to these prior technologies for site connectivity. In other countries, for certain types of customer sites, the prior technologies have a more optimal price/performance point than MPLS networks because of their more complete deployment. In these countries, it is necessary, therefore, for the prior technologies to be incorporated into an otherwise MPLS dominated end-to-end service whilst in-country MPLS deployment continues and migration takes place from older technologies. Equally, there is a requirement to be able to incorporate access technologies that are just beginning their deployment such as Ethernet and wireless as well as IP based technologies such as L2TPv3 and mGRE into end-to-end service MNEs. 4.5. Remote Service Interconnect Requirement In an MNE, the MNE operator will incorporate network operators in the MNE according to the needs of the commercial MNE use case. Some of those network operators may be collocated at the same VPL; others may not. For those that are collocated at the same VPL, interconnection of VPN services can happen locally. However, in the example of an end-to-end chain of three VPN services and two interconnects, local VPN interconnection will happen twice: once at the first VPL (first to second network operator) and once at the second (second to third network operator). However, in some situations, MNE operators may choose not to use the VPN service of the second (middle) network operator. Instead, they may wish to interconnect the VPN services of the first and third network operators remotely. There is, therefore, a requirement to be able to remotely interconnect services of non- collocated network operators in an MNE. Halstead/Guichard Expires April 7, 2006 [Page 8] Draft-halstead-guichard-MAVS-requirements October 2005 4.6. Redundant Interconnect Requirement Part of the end-to-end service offering provided by an MNE operator involves the provision of appropriate levels of redundancy for their particular MNE use case. In some VPLs, where business justifications exist, the MNE operator may choose to enhance interconnect reliability by implementing a redundant interconnect complex. The resulting interconnects might exist in the same building or in different buildings within a city or in different buildings in different cities. This differs from the Optimal Interconnect Selection Requirement in that a customer service will be designed to traverse each redundant interconnect, rather than a specific, optimal interconnect. There is therefore a requirement to support customer services across redundant interconnects. 4.7. Security Requirement Security is a requirement of any business, but the requirement becomes more important where that business collaborates with others to provide a service. Potential threats might emanate from a number of sources, for instance, other network operators, VPLs and customers. Clearly, the vulnerability of a customer service to threats from these sources is of paramount importance. Of equal importance, is the vulnerability of a network operator backbone to threats from these sources. An attack on a network operator backbone could detrimentally affect numerous customers, including those attached to other operators. There is a requirement, therefore, to secure network operator backbones and customer services in an MNE. 4.8. Third Party Interconnect Requirement Some operators, although they have a need to be able to provide end- to end service in a solution involving multiple network operators, may be unable to operate or have no desire to operate an MNE. In order that an MNE can be established for it and its network operator partners, the operator wants a third party to provide interconnect services to the group. It may be that the third party is another network operator, a systems integrator, a network integrator or another type of service provider. To achieve end-to-end service, it is critical that the third party interconnect service provider is able to control and coordinate global service policy throughout the MNE on behalf the group. There is, therefore, a requirement for the Halstead/Guichard Expires April 7, 2006 [Page 9] Draft-halstead-guichard-MAVS-requirements October 2005 interconnect equipment and procedures to be controllable by a third party interconnect services provider. 5. Policy Authority MNE Requirements 6. Conclusions 7. Acknowledgments Halstead/Guichard Expires April 7, 2006 [Page 10] Draft-halstead-guichard-MAVS-requirements October 2005 8. References 8.1. Normative References 8.2. Informative References 9. Author's Addresses Jim Guichard Cisco Systems, Inc 300 Beaver Brook Rd Boxborough MA Email: jguichar@cisco.com 10. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 11. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE Halstead/Guichard Expires April 7, 2006 [Page 11] Draft-halstead-guichard-MAVS-requirements October 2005 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 13. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Halstead/Guichard Expires April 7, 2006 [Page 12]