TBD M.Halstead, Ed Internet Draft Nexagent Ltd Expires: July 2006 Jim Guichard, Ed Cisco Systems, Inc. Christian Jacquenet, Ed France Telecom February 1, 2006 IETF Internet Draft Document: draft-halstead-guichard-mavs-requirements-00 Requirements for Multi Autonomous System VPN Services Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Abstract This document complements [RFC4031] and defines requirements that are specific to the delivery of BGP/MPLS-based [RFC-2547bis] VPN services across multiple administrative domains. These requirements are independent of underlying technologies or the number of Autonomous Systems such VPNs may span. It lists the requirements of the Expires July 1, 2006 [Page 1] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 different parties that are involved in the administration of these Autonomous Systems and may therefore be involved in the delivery of the VPN service offerings. 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................................................3 2. Definitions.................................................5 2.1. Multi Domain Environment (MDE)..........................5 2.2. VPN Service Provider (VSP)..............................5 2.3. VPN Peering Location (VPL)..............................6 2.4. Agent..................................................6 3. Problem Statement...........................................6 4. Multi Domain Environment Reference Model.....................7 4.1. Distributed Policy Enforcement Example..................8 4.2. Centralized Policy Enforcement Example..................8 5. Topological Requirements.....................................8 5.1. Remote Service Interconnect Requirement.................8 5.2. Optimal Interconnect Selection Requirement..............8 5.3. Redundant Interconnect Requirement.....................10 5.4. VPN Topology Requirement...............................10 5.5. End-to-end Unicast and Multicast Routing Requirements...11 5.5.1. Generic Routing Considerations....................11 5.5.2. IGP Routing Considerations........................12 5.5.3. BGP Routing Considerations........................12 5.5.3.1. BGP AS_PATH Attribute Considerations..........12 5.5.3.2. Route Distinguisher Allocation Considerations.13 5.5.3.1. Route Target Allocation Considerations........13 5.5.3.2. Traffic Load Balancing Considerations.........13 5.5.4. Multicast Routing Considerations..................14 6. QoS Requirements...........................................14 6.1. Differentiated Services Policy Considerations..........15 6.1.1. QoS Policy Transparency...........................16 6.2. Consistent Metric Considerations.......................16 6.3. Traffic Engineering/Routing Policy Considerations.......17 6.4. Metrology Considerations...............................17 7. Security Requirements.......................................18 7.1. Encryption Requirements................................19 7.2. Label Spoofing Protection..............................20 7.3. Authentication Requirements............................20 Expires July 1, 2006 [Page 2] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 7.3.1. Authentication of Network Elements................20 7.3.2. VPN Route Authentication and Filtering............20 8. Management Requirements.....................................22 8.1. Performance Metric Statistic Requirements..............22 8.2. Capital Scaling Requirements...........................22 8.3. Operational Scaling Requirements.......................22 8.3.1. Service Independence Requirements.................23 8.3.2. Minimize Network Integration Requirements..........23 8.3.3. Third Party Interconnect Requirements.............24 8.4. IPVPN Services Demarcation Requirements................24 8.4.1. Fully Managed Service Demarcation.................24 8.4.2. Mixed Management Service Demarcation..............25 8.5. Remote CE Management Requirement.......................25 8.6. End-to-End Combined Services Requirement...............26 8.6.1. Combined VPN and Internet Access Requirement.......26 8.6.2. Combined IP and non-IP Application Transport Requirement ........................................................26 9. Conclusions................................................27 10. Acknowledgements..........................................27 11. References................................................27 11.1. Normative References..................................27 11.2. Informative References................................28 Editor's Addresses............................................29 12. Intellectual Property Statement............................29 Disclaimer of Validity........................................30 Copyright Statement...........................................30 1. Introduction This document summarizes requirements that apply to all parties involved in the delivery of BGP/MPLS-based [RFC-2547bis] VPN services that span multiple Autonomous Systems (ASes). Such parties include, but are not limited to, Network Service Providers (NSP), Systems Integrators (SI), Network Integrators (NI), Cable Operators (CO), Mobile Operators (MO) and Virtual Network Operators (VNO). BGP/MPLS-based [RFC-2547bis] services may be delivered between ASes of the same company (commonly referred to as "Inter-AS" services), or different companies (commonly referred to as "Inter-provider" services). This document aims to provide requirements for either type of service delivery. BGP/MPLS-based [RFC-2547bis] VPN services are deployed and operated due to the combined activation of a set of elementary capabilities. This document is organized to take the requirements for activating Expires July 1, 2006 [Page 3] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 these capabilities across multiple ASes into account using the following taxonomy: - Topological considerations: These correspond to the information needed for the deployment of BGP/MPLS-based [RFC-2547bis] VPN topologies. This information includes, but is not limited to, identification of the endpoints that will be interconnected via the VPN, forwarding and routing policies to be enforced by the VPN network elements, and the topology of VPN membership. - QoS considerations: These correspond to the information, with QoS parameters, that may characterize the level of quality provided with the VPN service offering. QoS parameters include, but are not limited to, VPN traffic classification and marking capabilities, traffic conditioning and scheduling capabilities, as well as VPN traffic engineering capabilities. - Security considerations: Any BGP/MPLS-based [RFC-2547bis] VPN that is deployed and operated across multiple ASes may require the need for identification, authentication and potentially, VPN traffic encryption capabilities. This includes the possible identification and authentication of the resources that participate in the establishment and operation of a VPN, as well as the ability to check the integrity of VPN route announcements exchanged between ASes. - Management considerations: It is assumed that the operation of QoS-based BGP/MPLS-based [RFC-2547bis] VPN services is part of the management tasks performed by service providers within their own ASes. Additional operational tasks are however needed in order to enable the management of VPN services across multiple ASes. - Measurement and monitoring considerations: the ability to measure and monitor service delivery is of paramount importance, especially when such services span multiple ASes. This document is therefore organized as follows: - Section 2 defines terminology specific to the delivery of BGP/MPLS-based [RFC-2547bis] VPN services that span multiple ASes. This terminology aims at facilitating the overall understanding of the issues and requirements expressed in this document. - Section 3 describes some of the drivers for the deployment of Multi-AS BGP/MPLS-based [RFC-2547bis] VPN services. Expires July 1, 2006 [Page 4] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 - Section 4 introduces a reference model that depicts the context for the deployment and the operation of BGP/MPLS-based [RFC- 2547bis] VPN service offerings that span multiple ASes. In addition, use cases illustrate examples of different business and operational process interaction between the various parties. - Section 5 describes topological requirements that include traffic forwarding and routing considerations, VPN traffic load balancing capabilities, as well as VPL-specific interconnect design considerations. - Section 6 describes VPN-specific Multi-AS QoS policy enforcement requirements which include forwarding, routing and measurement considerations. - Section 7 describes VPN-specific Multi-AS security policy enforcement requirements which include identification, authentication and encryption considerations. - Section 8 describes VPN-specific Multi-AS management policy enforcement requirements which include configuration, fault detection, performance and accounting management tasks. 2. Definitions Some of the terminology used in this document is taken from [RFC- 4026] and [RFC-4031]. "VPN" in the context of this document refers specifically to BGP/MPLS-based [RFC-2547bis] VPN services. In order to clarify the requirements listed in this document, it is necessary to further define and introduce new terminology, specific to multi provider VPN services as follows: 2.1. Multi Domain Environment (MDE) Two or more Autonomous Systems that may or may not be owned by separate administrative authorities, and which are used to interconnect service endpoints (sites) of one or more VPNs. 2.2. VPN Service Provider (VSP) A VSP is an operator who participates in the delivery of a single domain, or multi-domain (MDE-wide) VPN service. In delivering the VPN service, the VSP may own a subset, or all of the participating network elements. Examples of VSPs include Network Service Providers (NSP), Systems Integrators (SI), Network Integrator (NI), Cable Operator (CO), Mobile Operator (MO) and Virtual Network Operators (VNO). Expires July 1, 2006 [Page 5] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 2.3. VPN Peering Location (VPL) A VPL is a physical location where VPN services delivered by one or more VSPs are interconnected. Examples of VPLs include a network operator hotel, SP central offices, a collocation facility or any building common to one or more VSPs. A VPL could be operated by a single VSP, consortium of VSPs or a neutral 3rd-party.. 2.4. Agent For the purposes of this document, an Agent is a VSP who is responsible for the management of multi-party business processes, negotiations and fulfillment that allow the multi-provider VPN to function. The Agent manages this responsibility by either operationally complying with or coordinating policies across all parties involved in delivering their customer's end-to-end service. Policy compliance or multi-party policy coordination is achieved either in a distributed or centralized manner. For distributed policy enforcement, cooperating VSPs agree upon the enforcement of consistent policies for VPN service provisioning purposes. In this case, end-to-end policy enforcement is distributed across multiple VSPs, each of which is a stakeholder in the supply and enforcement of a fixed set of policies within the shared MDE. A VPN customer defines their VPN service requirements with an Agent who then maps these requirements to the set of pre-agreed policies. For centralized policy enforcement, the Agent coordinates per customer, a set of policies related to the management of the customer's VPN service. In contrast to a shared MDE where policy enforcement is distributed across multiple VSPs, this Agent will coordinate policies and integrate VPN services per customer, thereby creating a MDE that is dedicated to the Agent's customers only. The Agent may independently agree and manage SLSs with each partner VSP and offer an aggregated end-to-end SLS to their customer's. 3. Problem Statement No single network can deliver VPN services that provide optimal price and performance for all customers and all customer locations. For regulatory, commercial, resiliency and other reasons, customer requirements for VPN services may not be compatible with a single VSP owned network infrastructure. Alternatively, some customers may have requirements for VPNs that are difficult and/or expensive for a single VSP to deliver. In this case Expires July 1, 2006 [Page 6] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 the VSP has incentives to cooperate with other VSPs that may offer similar VPN services, along with broadly compatible SLSs. For customers (whether they solicit an Agent or not), end-to-end VPN service delivery is paramount. Controllable, predictable and reliable VPN service must be delivered regardless of the characteristics of the MDE. The challenge however for the Agent in controlling 'global' service policy in an MDE is the lack of homogenous policies amongst VSPs and the difficulty VSPs have in adapting their VPN service domains to the customer's Agent-defined VPN service policy. 4. Multi Domain Environment Reference Model Figure 1 shows a generic reference model for a Multi Domain Environment. It shows the relationships that exist between the various parties involved in the establishment of VPN services that span multiple VSP-administered networks. |<------------Multi Domain Environment----------->| | | | Customer | | | | | +----------------- Agent ------------------+ | | | | | | | | | | VSP1 VPL1 VSP2 | | | | ^ ^ ^ | | | 1..n 1..n 1..n 1..n 1..n | | V V V V V | |Site1 <---> AS1<---> (VPL1) <---> AS2 <---> Site2| Figure 1 - MDE Reference Model The MDE consists of sites, interconnected via ASes. ASes are then interconnected via VPLs, within the context of delivering VPN service offerings. There is potentially a one-to-many relationship between VSPs and ASes, similarly there is potentially a one-to-many relationship between VPL operators and VPLs. With reference to Figure 1, the following sections detail examples of the coordination of the various parties in the enforcement of a set of policies. These policies relate to the provisioning of an MDE-wide VPN service and include (but are not limited to) addressing, routing, QoS and security. Expires July 1, 2006 [Page 7] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 4.1. Distributed Policy Enforcement Example The customer's Agent is a single VSP (VSP1 in this example). VSP1 manages the relationship with the customer, which includes the specification, instantiation, possible negotiation and invocation of the customer's SLS (Service Level Specification). Cooperating VSPs, VSP1 and VSP2 have pre-agreed an enforced set of policies, including the management of VPL1. The customer's requirements are mapped by VSP1 to the pre-agreed policies of VSP1 and VSP2. 4.2. Centralized Policy Enforcement Example The customer's Agent is a Systems Integrator (SI). The SI does not own the network infrastructure (the VPN networking elements), but manages the VPLs, as well as the processes involved in connecting the VPLs with each relevant VSP owned AS. VSP1 and VSP2 independently provide customer-specific VPN services and associated SLS instantiated templates to the SI who is then responsible for integrating each VSP's VPN service components and negotiating/invoking an end-to-end SLS with/for their customer. 5. Topological Requirements 5.1. Remote Service Interconnect Requirement In an MDE, Agent(s) will select VSPs according to the needs of their customer. VSP owned ASes may or may not be collocated at the same VPL. For those ASes that are collocated at the same VPL, interconnection of VPN services can take place locally. However, in the example of an end-to-end chain of three VSP owned ASes and two VPLs, local VPN interconnection will happen twice; once at the first VPL (first to second AS) and once at the second (second to third AS). However, in some situations, the Agent may choose not to use the VPN service of the second (middle) VSP. Instead, the Agent may wish to interconnect the VPN services of the first and third VSPs remotely. There is, therefore, an Agent-driven requirement to be able to remotely interconnect services of non-collocated VSP owned ASes in an MDE. 5.2. Optimal Interconnect Selection Requirement VSP multi-homing is the scenario in which a VSP needs to interconnect their AS at two or more VPLs. By ensuring that traffic passes between ASes at pre-determined VPLs, the desired end-to-end VPN service Expires July 1, 2006 [Page 8] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 delivery can be established and retained for any customer sites. VSP networks can therefore be utilized more efficiently. As an example, consider a customer site in the middle of the USA. It is connected to a VSP's AS that is interconnected at VPLs in both New York and Los Angeles. In order to minimize latency, traffic must be sent to Tokyo via the LA VPL and not via New York. 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. Although this scenario may be taken care of by standard IP routing, the specifics of a VSPs BGP routing policy, or traffic engineering implementation, may force some traffic to be forwarded away from the best path. Therefore, for multi-homed ASes, there is a requirement for interconnects at multiple VPLs to be optimally selectable for each source-destination site pair within an MDE. Nevertheless, the notion of optimality should not necessarily be expressed in terms of hop count metrics. The selection of the optimal interconnecting points should rely upon a variety of criteria that include (but are not necessarily limited to): - The minimum number of hops that need to be crossed to reach a given (set of) VPN destination(s), - The minimum value of the one-way transit delay to reach a given (set of) VPN destination(s), - The minimum value of the inter-packet delay variation to reach a given (set of) VPN destination(s), - The minimum value of the packet loss rate to reach a given (set of) VPN destination(s), - The preservation of the confidentiality of the traffic that may be exchanged between a given set of VPN locations, - The maximum VPN prefix length that should be announced at VPL locations, - The use of VPL locations that should not share network resources involved in the forwarding of Internet traffic, - The required traffic symmetry to allow a given source-destination pair to be forwarded on the same path in both directions so as to avoid packet mis-ordering Expires July 1, 2006 [Page 9] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 - The available bandwidth capacity at the VPL (in the case where overbooking policies are in effect at the VPL) - Any combination of the above criteria. 5.3. Redundant Interconnect Requirement Part of the end-to-end VPN service offering provided by one or more Agents involves the provision of appropriate levels of redundancy for their MDE use case. In some VPLs, where business justifications exist, Agents or VSPs 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 is in addition to 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. 5.4. VPN Topology Requirement Although VSP owned ASes offer the possibility for any customer site to communicate 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 customer sites or 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 and country-by country. Alternatively, segmentation might need to exist 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 VSPs. Consequently, VSPs use different methods for establishing the logical topology of a VPN and use different schemas to define VPN membership. For instance, one VSP might use standard community values to establish layer-2 topologies whilst another might use extended Expires July 1, 2006 [Page 10] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 community values. Yet another VSP may use a combination of both techniques. Alternatively, VSPs may segment VPNs using layer-3 routing techniques. In fact, some VSPs might combine layer-2 and layer-3 segmentation techniques. Additionally, each VSP will implement a schema for VPN membership that is proprietary, with membership values that are likely to overlap and conflict with other VSP assigned values. VPN membership allocation schemas tend to be difficult to modify due to the 'hard coding' of the schema in each network operator's OSS and BSS systems. Conflicting VPN membership schemas and different methods for establishing logical topologies make it very difficult for the Agent to establish an end-to-end VPN service. Moreover, an inventory of the topology consisting of the network elements/interfaces and set of paths that traffic may take through the network could in addition be difficult for the VSP to be made available to the Agent. These elements will most likely constitute a partial topological view of the network but may be sufficient and required for the purpose of QoS policy definition. There is therefore, a requirement to be able to establish an end-to- end VPN topology, including the publishing of network elements and interface inventories per VSP throughout an MDE. 5.5. End-to-end Unicast and Multicast Routing Requirements 5.5.1. Generic Routing Considerations Routing and forwarding configuration information deals with the decision criteria that should be taken by a network element in order to forward VPN specific traffic according to a given VPN routing policy. From this perspective, VSP owned network elements should be provided as a minimum with the following information: - Relevant metric information so that network elements can dynamically assign these metric values. Such metric values could be assigned on either long or (very) short-term basis. Examples of assigned 'long-term' metrics include packet loss and delay thresholds, usually expressed as percentiles of available resources. Short-term metrics may include available or reserved bandwidth, typically provided via real-time or near real-time SNMP MIB queries. Expires July 1, 2006 [Page 11] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 - The configuration information related to any static route that may identify a VPN endpoint (or VPL) as the next hop to reach a given VPN destination prefix. 5.5.2. IGP Routing Considerations Today there are no standards for, or agreement of, how VPN routing policy based upon the policing of the admission and distribution of VPN routing information (classification and filtering of routing information) is implemented amongst VSPs. Consequently, VSPs enforce VPN routing policies within a defined customer topology in different ways. For example, in an MDE, where the EF-inferred IGP policy [RFC2676] of AS1 relies upon the computation of routes with a maximum one-way transit delay of 120 ms in order to reach a set of destination prefixes, and AS2 defines the equivalent EF-inferred IGP policy with a different QoS parameter (e.g. maxLossRate=0%), then there is a risk of jeopardizing the overall quality of service of the multi-AS VPN. Conflicting routing policies amongst VSPs therefore make it difficult to establish an end-to-end unicast routing policy throughout an MDE. There is, therefore, a requirement to be able to enforce a consistent IGP routing policy throughout an MDE. 5.5.3. BGP Routing Considerations VSP owned network elements should be provided with relevant BGP-4 [RFC-1771] reachability information, including the attributes taken into account by the network element's route selection process in order to decide whether or not traffic should be forwarded along a given VPN route. 5.5.3.1. BGP AS_PATH Attribute Considerations Where BGP-4 is used as the PE-CE routing protocol, the use of a single private [RFC-1930] AS Number (ASN) across all customer sites hosted by multiple VSPs could raise issues for each VSP as they commonly use the 'as-override' command on PE-CE neighbors. Where VPN-IPv4 routes are advertised across multiple ASes, VSP owned public Autonomous System Numbers (ASNs) could be pre-pended to private route updates. The 'as-override' feature will not then operate over PE-CE IPv4 links where public and private ASN numbers are advertised within the same VPN address prefix. Expires July 1, 2006 [Page 12] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 Network elements located at a VPL should therefore be capable of removing or changing public or private ASNs from the BGP AS_PATH attribute on a per neighbor basis. This per neighbor AS path match and removal policy should be capable of being performed on ingress or egress across the entire AS path. 5.5.3.2. Route Distinguisher Allocation Considerations VPN-IPv4 routes [RFC2547bis] are made unique across a domain by combining an IPv4 address with an 8 byte 'Route Distinguisher' (RD) value. The advertisement of RD values end-to-end between VSPs, combined with the customer's use of private [RFC1918] addressing could result in Route Reflectors (RR) making incorrect best path decisions for identical routes received from external as well as internal PE network elements. This will occur where RD and customer address space overlap across VSP ASes. Although the probability of this scenario is small, the consequences could be severe and difficult to isolate, therefore VSP owned RRs and PE's SHOULD NOT receive VPN-IPv4 routes that have RD values assigned by another VSP. In order to ensure that RD values that transit VPLs are unique, RD values MUST be pre-pended by a public registered AS number ([RFC- 2547bis], section (4.1). 5.5.3.1. Route Target Allocation Considerations VSPs usually have difficulty in provisioning extended (Route Target) or standard BGP community values on their PE network elements that are assigned by external parties such as the end customers Agent or another VSP. This difficulty is due to the VSP having automated or manual OSS systems and operational procedures that typically apply to per VSP ASes only. These systems and processes are difficult to change due to schema conflicts brought about by attempting to incorporate externally assigned RT allocation schemas. In addition, not all VSPs allocate RT values that are pre-pended with a publicly registered ASN or IP address. RT values to be applied on VSP PEs therefore should be assigned by the operator of the PE. In order to ensure that BGP extended community values are unique between ASes, RT values that are advertised across the VPL MUST be pre-pended by a public registered ASN. This follows the specification detailed in the 'Identifiers' section of [RFC-4031] and assists in the prevention of cross-connection for VPN services. 5.5.3.2. Traffic Load Balancing Considerations VSPs use various traffic load-balancing techniques between customer sites to optimize traffic flows within their own ASes. As described in [RFC2547bis], this necessitates the use of different RD values Expires July 1, 2006 [Page 13] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 provisioned across VRFs to which the customer is multi-homed. Similar mechanisms SHOULD be available when VSP owned ASes are multi-homed across multiple VPLs and where the VSP wishes to optimize customer traffic via load balancing. Such mechanisms may require that the signaling protocol support the advertisement of all available paths so that optimal path selection is available as well as backup paths in case of optimal path failure. 5.5.4. Multicast Routing Considerations IP multicast transmission schemas may be used by some applications such as videoconferencing or TV broadcasting in order to optimize VPN network resources. As a result, VSP owned network elements should support multicast routing capabilities for the dynamic establishment and maintenance of distribution trees within the VPN and should therefore be provisioned with the relevant yet consistent configuration information. There are currently however no standards for, or agreement of, an enforcement of consistent multicast routing policies amongst VSPs. There is therefore a requirement to be able to enforce an end-to-end multicast routing policy for the sake of the establishment and maintenance of consistent distribution trees throughout an MDE. 6. QoS Requirements Quality of service is a very generic term, which is sometimes misused, especially when applied to IP/MPLS environments. In this document, the design and the enforcement of a QoS policy within VPN- specific MDE environments relies upon the following dimensions: - A forwarding dimension, which consists of ensuring that a VSP owned network element behaves differently, depending on the kind of traffic it has to process and subsequently forward. This yields a need for VPN traffic identification, classification and possibly activation of traffic conditioning, policing, scheduling and optionally, discarding mechanisms. The forwarding dimension of a QoS policy is a notion that is local to a network element, independent from the expected behaviors of the other network elements within the MDE. The DiffServ (Differentiated Services) architecture, as described in [RFC-2475], is generally seen as the cornerstone of the forwarding dimension, introducing the notion of classes of service as well as Behavior Aggregates (BA). Expires July 1, 2006 [Page 14] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 - A metric definition dimension, which consists of defining consistent metrics such as delay, jitter and loss, so as to support QoS meaningfully across multiple VSPs. - A routing dimension, which consists of enforcing a VPN-specific traffic engineering policy at the scale of a MDE. Traffic engineering is a set of capabilities that allow the (hopefully dynamic) computation and selection of paths that will be used to convey different kinds of VPN traffic. It may be necessary to route QoS-sensitive traffic to different VSPs or along different paths other than those selected by best effort traffic. Path selection is dependant on the (QoS) characteristics of such paths, which comply with the QoS requirements that have been expressed and negotiated by the Agent with their VPN customers. - A monitoring dimension, which consists of qualifying how efficient a QoS policy is enforced within a MDE, based upon the use and measurement of well-defined indicators. Due to the multiple parties involved in the delivery of QoS, it is necessary to have well defined methods for measurement of QoS, ways to monitor the performance of different network elements, and ways to report performance consistently among VSPs. Such indicators include (but may not be limited to) one-way transit delay, one- way inter-packet delay variation (sometimes called jitter), one- way packet loss rate or any combination of such indicators. 6.1. Differentiated Services Policy Considerations Currently, there are no standards for or agreement of service definitions as defined in the Diffserv architecture amongst VSPs. [RFC-3644] defines QoS policy within a single Diffserv domain as being dependent upon three types of information: - The topology of the network elements under management; - The particular type of QoS methodology used (e.g. Diffserv), and; - The business rules and requirements for specifying service(s) delivered by the network. These information types vary across VSP ASes. Consequently, VSPs deploy different numbers of classes of service (COS) and specify service definitions in proprietary ways. Fixed mappings of classes of service between any two VSPs may result in compromised service across the two. This is in part because fixed mappings cannot always utilize Expires July 1, 2006 [Page 15] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 the full service envelope available from the interconnected VSPs (a VSP with three classes of service can only utilize 3/5ths of the service envelope of a VSP with five classes of service). Furthermore, fixed mappings may be adequate for some Agent's customers, but not for others. This is because QoS policy is often applied in different ways for each application used in each customer environment When three or more VSP ASes are used to provide connectivity between customer sites, two or more VPLs are required and, therefore, a multiple, compounding service compromise exists. In an MDE of many VSP ASes and VPLs, it is clear that numerous and compounding compromises in service will take place and end-to-end QoS policy enforcement may be hard to achieve. There is a requirement, therefore, for a relationship to exist between VSP classes of service that may vary from one customer to another, and that can also utilize the full service envelope of all VSPs within an MDE. 6.1.1. QoS Policy Transparency There is general agreement that customer packets should not be remarked (that is, have their DSCP values modified) as they transit the MDE. At the same time, it is often necessary for the VSP to impose a QoS treatment on customer packets that differs from that which might be indicated by the customer's DSCP (such as is the case for non-conforming traffic downgraded to best effort). However, even if the packets are treated as best effort by the VSP, the customer wishes to retain the original DSCP marking for their own use when the packets arrive at their remote site. This requirement is defined as "QoS transparency", where the transparency in question refers to the tunneling of the customer QoS policy, unmodified, from ingress to egress across an MDE. [RFC-4031] describes this requirement as a 'Carrier's Carrier' model where one VSP is the customer of another VSP. Such a VSP should be able to resell VPN services to their customers independent of the DSCP mapping solution employed by the 'Carrier's Carrier' VSP. There is a requirement, therefore, for enterprise QoS policy transparency throughout an MDE. 6.2. Consistent Metric Considerations Currently, there are no standards for, or agreement of metric definitions between VSPs. As an example, the Low Latency service class is generally characterized by three network performance Expires July 1, 2006 [Page 16] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 metrics; latency, packet loss, and jitter. These metrics are generally reported as two-way or one-way derived from two-way measurements, but are generally defined differently between VSPs. There is therefore a requirement to produce service classes with metrics that can be meaningfully concatenated, so as to provide reasonable commonality of metrics across VSPs. 6.3. Traffic Engineering/Routing Policy Considerations In a true MDE environment there may be many alternate paths between customer sites. The preferred path among VSPs is typically determined by BGP policies. However, when multiple classes of service exist, it may be desirable to route some traffic preferentially via VSPs who support the enhanced QoS class(es) while best effort traffic takes the conventional route. That is to say, there may be cases in which the current route selection capabilities of BGP, which yield only a single best path for a given prefix, may not be sufficient. The deployment of traffic engineering capabilities in VPL owned network elements is of importance when considering the joint forwarding of "triple-play" services where data, video and voice traffic is forwarded within a given VPN. Within a MDE, VSPs or Agents should provide configuration information parameters that will allow network elements to choose appropriate VPN paths to a given destination based on "Service Contexts". These paths are chosen according to application-specific constraints, available service characteristics and/or requirements. These constraints and/or requirements may be expressed in terms of time duration (e.g. the use of a VPN route on a weekly basis), traffic characterization (e.g. all IP multicast traffic should be forwarded along a set of specific VPN routes), security concerns (e.g. use trusted network elements along the path towards specific destinations), and/or QoS considerations (e.g. marked VPN traffic with a specific DiffServ Code Point (DSCP) value should always use a configured set of traffic-engineered VPN routes, or available exit point that exhibits the desired "Service Context"). 6.4. Metrology Considerations Currently, there are no standards for, or agreement of, measurement methods amongst VSPs. VSPs define measurements differently and measure different service end points. In a MDE environment, measurement methodology differences, particularly differences in the statistical nature of the measurements, make it impossible to combine Expires July 1, 2006 [Page 17] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 VSP measurement reports so that the overall quality of the VPN service can be qualified. As VSP reports can be so different, it is tedious and time consuming to analyze whether an individual VSP or VPL operator has met its performance targets. When end-to-end services fail, it may be very difficult to analyze VSP measurement data in order to detect and isolate faults amongst VSPs or VPL operators. In an MDE, where the customer's Agent(s) are responsible for end-to- end service, this may be untenable. In addition, whilst windows for scheduled and unscheduled maintenance will remain difficult for the Agent(s) to control or coordinate, any measurement methodology must take these windows into account in any performance assessments of the QoS policy that are made. There is, therefore, a requirement for statistically homogenous measurement throughout an MDE as well as the ability to place measurement instrumentation/sources at VPL locations in order to aid fault detection and isolation. 7. Security Requirements Security is a requirement of any business, but the requirement becomes more important where that business collaborates with others to provide a service [RFC-4111]. Potential threats might emanate from a number of sources, for instance, other VSPs, VPL operators 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 VSP AS to threats from these sources. An attack on a VSP AS could detrimentally affect numerous customers, including those attached to other VSP owned ASes. Enforcement of a security policy at the scale of a MDE assumes the availability of the following capabilities as a minimum: - The identification and the authentication of the users who may be entitled to access the VPN service, - The identification and authentication of network elements that will not only participate in the deployment and the operation of the VPN, but also in VPN route information propagation, - The preservation of the confidentiality of information within a VPN. Expires July 1, 2006 [Page 18] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 VSPs should therefore be provided with configuration information related to the aforementioned security parameters. This does not mean that VSP owned network elements have to maintain a dynamically updated user database, rather, they should be provided with the following configuration information as a minimum: - Identification information for IP networks that may exchange data through the VPN and/or the configuration information required for the activation of an identification/authentication mechanism such as RADIUS (Remote Authentication Dial-In User Service), [RFC- 2865], - Identification information for VSP owned network elements that support endpoint(s) of the MP-BGP peer and possibly configuration information related to the activation of a mechanism for identifying and authenticating such peers (such a mechanism could be based upon the use of a SHA-1 (Secure Hash Algorithm) digital signature for example), - Configuration information required for encryption purposes. This requirement is further expanded on in section 7.1. There is a requirement, therefore, to secure VSP ASes and customer services in an MDE as well as securely forward VPN related security parameters between VSPs and Agents. 7.1. Encryption Requirements VPN customers may require all or part of their encrypted traffic to be preserved, independent of the number of VSP owned ASes within the MDE supporting their VPN service. There is therefore a need for the MDE to support any relevant encryption technique that preserves the confidentiality of the VPN traffic. This implies that: - The VSP owned network elements that compose the MDE should support protocols of the IPsec suite [RFC-4301], - The MDE should be capable of supporting an adequate means for identifying and authenticating any participating device involved in the forwarding of VPN traffic, - The MDE should be capable of supporting an adequate means for identifying and authenticating any participating VSP owned network element involved in the enforcement of the VPN-specific routing policy. Such means should enable any VSP owned network Expires July 1, 2006 [Page 19] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 element to check the integrity of received VPN route announcements, - The MDE should be capable of supporting and enforcing any dynamic key management scheme suitable for the dynamic establishment of Secure Associations (SA) between relevant VSP owned network elements, - VSPs that are involved in the dynamic establishment of SA associations across their ASes should be provided with relevant configuration information (keys, passwords) in a timely manner, that is, the provisioning of such configuration information should not jeopardize the time to deliver the VPN service offering to the customer with the required level of security. 7.2. Label Spoofing Protection Whenever labels are exchanged between two VSP peers it is possible that the spoofing of such labels may occur either toward the internal infrastructure of the said VSPs, or within the VPNs that are supported by such VSPs. There is therefore a requirement to provide mechanisms that prevent the spoofing of labels in the forwarding path. 7.3. Authentication Requirements 7.3.1. Authentication of Network Elements Within a MDE, every VSP owned network element that participates in the deployment and the operation of a VPN service offering should be trusted. There is therefore a requirement to provide acceptable authentication processes in order for a network element to participate in the deployment and operation of a VPN service. This implies that every VSP owned network element must be identified and authenticated typically via processes owned by relevant Agents or VSPs. 7.3.2. VPN Route Authentication and Filtering Within a MDE, every VSP owned network element is permitted to announce VPN routes to some or all of its pre-authenticated peers, assuming the requirements expressed in section 8.2.1. have been addressed. VSPs have existing mechanisms and operational processes that prevent the cross connection of VPNs within their own ASes. These mechanisms include manual or automated systems for VPN membership allocations Expires July 1, 2006 [Page 20] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 that include per customer RT values. Where the VSP extends VPN services via an MDE, incorrect or malicious configuration of VPN membership information could result in cross connection or incorrect announcement of VPN membership attributes across an MDE. These route announcements could in addition expose the VPN topology of the VSP. The integrity of the contents of such VPN route announcements must be authenticated by any receiving peer and/or by some kind of VPN route server capability that could be embedded in the relevant Agent or VSP owned facility before the receiving peer accepts the announced route. Draft [VPN-VERIFICATION] could assist with this route authentication requirement. It should be possible to enforce further VPN route-specific filtering policies at appropriate locations within an MDE. Additional route filtering criteria could be based upon (but not necessarily limited to): - Intra-VPL communication restriction where, for example, RT value announcements are filtered such that they only include interested parties across VPL locations. This filtering policy is particularly relevant where the VSP owned network elements peer with more than one network element at a VPL. This function is described further in [RT-CONSTRAIN] - Intra-VPN communication restrictions, where, for example, not all sites are permitted to communicate - The contracted metrics with the VPN customer and between VSPs for routing table size, routing protocol type, and end-to-end routing policy. - The required end-to-end convergence time to avoid the case where restoration policies, timer values, or fast convergence protocols (such as BFD), differ between VSPs. - Inter-AS routing restrictions, where, for example, some VPN traffic shouldn't be transported across one or more ASes within an MDE - Time based restrictions, where, for example, some destinations cannot be reached during working hours, - QoS based restrictions, where, for example, traffic should not be bound for VPN route sources that experience more than a 100 ms one-way transit delay. Traffic route sources that experience Expires July 1, 2006 [Page 21] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 delay over a certain threshold should not then be announced at selected VPLs. 8. Management Requirements 8.1. Performance Metric Statistic Requirements Agents have stringent usage requirements for an MDE. From this perspective, VSPs should permit an Agent to have access to statistical information based upon, (but not necessarily limited to): - The volume of traffic that has been conveyed by the entire VPN, a specific VPN route, forwarded by a specific network element or over a given period of time that may include a distinction between incoming and outgoing traffic, - The volume of VPN traffic that has been dropped by network elements within a given period of time, - IPPM (IP Performance Metrics) [RFC-2330] related information that is relevant to tunnel usage: such information includes one-way transit delay, inter-packet delay variation etc. 8.2. Capital Scaling Requirements In an MDE, there might be one or more VPLs. At each VPL there may be one or more interconnected VSP ASes, or a single VSP that uses the VPL for connectivity between their own ASes. Traditionally, the interconnection of two VSP ASes has resulted in the deployment of network element resources that are either dedicated to those two VSPs, or leased from the VPL operator. Where there is a need for a VSP to interconnect with multiple other VSPs, scaling cost efficiency could result if interconnected network elements could be shared across all VSPs. This multilateral approach to VPL design will have increasing benefit as the number of interconnected VSPs at a VPL increases. Interconnected network elements at VPLs must therefore be shared multilaterally. 8.3. Operational Scaling Requirements Cost of operations is of great concern to a VSP, whether or not VPN services span their own ASes or those of their VSP partners. Compared to the capital cost of MDE interconnection at a VPL, operational cost Expires July 1, 2006 [Page 22] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 easily dominates. In an MDE, some, and perhaps all VSPs, might play a part in delivering services to an individual customer's VPN. Within a customer VPN, sites, physical and logical connectivity, VSPs, VPLs and VPN-specific policies might be variously moved, added, changed or deleted (MACD) at any time. In fact, different components of the VPN will, at times, undergo MACD concurrently. Service MACD lifecycle is part of any customer VPN and will happen as needed throughout the VPN's service life. As an MDE evolves, with increasing numbers of VSPs, VPLs and customers, the amount of service MACD will increase and place a continual and increasing burden on VSP operators throughout an MDE unless a scalable approach is taken. Operational scaling criteria could be based upon (but are not necessarily limited to) the following sections. 8.3.1. Service Independence Requirements In an MDE, it is inevitable that dependencies will exist between the services of individual VSPs. For example, a lack of forethought by the VPL operator by implementing a 'tightly-coupled' VPL interconnect environment would result in single VSP changes to topology, bandwidth, routing, QoS, etc., requiring all other VSPs to modify their definitions of existing services. Service dependencies amongst VSPs in a MDE must therefore be minimized. 8.3.2. Minimize Network Integration Requirements Currently there is no common agreement for how VSPs implement the interconnection of their VPN networks. This means that each inter-AS interconnect agreement at a VPL by VSP pairs will be a unique project, each of which potentially having different design goals and compromises. Each unique inter-AS interconnect agreement will usually take considerable time and consume highly skilled resources in both organizations. As the number of VPLs increases, so the load on the organizations will increase. In an MDE, the required number of unique inter-AS interconnect agreements could rapidly become untenable. Unique network inter-AS interconnect agreements amongst VSP pairs must therefore be minimized. Expires July 1, 2006 [Page 23] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 8.3.3. Third Party Interconnect Requirements Agents or VSPs require the ability to provide end-to-end services within an MDE. These Agents or VSPs may however have no desire or be unable to administer the coordination of business and operational processes involved in establishing an MDE. In order for an MDE to be established, the Agent or VSP may therefore require a third party operator to provide these business and operational process services. It may be that the third party is another VSP, 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 operator is able to control and coordinate global service business and operational process policy throughout the MDE. There is, therefore, a requirement for the business and operational processes involved in establishing an MDE to be administered by a third party operator. 8.4. IPVPN Services Demarcation Requirements 8.4.1. Fully Managed Service Demarcation [RFC-2547bis]-based VPN services may encompass a 'fully managed' Customer Edge (CE) to CE service with associated SLSs. In an MDE, this 'fully managed' service is interconnected to other VSP-owned services via VPLs. For SLS demarcation purposes, the VSP may express a preference to collocate a dedicated network element at each VPL. The VPL collocated network elements will, from an operational perspective function identically to a CE. In contrast to a standard CE however, each VPL collocated network element will usually support more than a single VPN across one or more customers and/or VSPs. From a scalability perspective, this is particularly advantageous for the VSP when interconnecting multiple VPN services at each VPL on behalf of one or more Agents. The SLS offered by the VSP to each Agent partner will in addition to CE-to-CE connectivity, include connectivity from each CE to one or more VPL collocated network elements. For contractual and/or technical reasons, the VSP may decide for example to collocate a network element per Agent, per group of Agents or per VPN. In all cases, consistent, unambiguous service boundaries for the fully managed service offering are essential. There is a requirement, therefore for consistent SLS demarcation points across 'fully managed' VPN service offerings within an MDE. Expires July 1, 2006 [Page 24] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 8.4.2. Mixed Management Service Demarcation In addition to 'fully managed' services, VSPs also offer VPN services that allow for a third party such as the VSPs customers to manage their own CE network elements. IPVPN connectivity of the customers' CEs via the VSP-owned ASes is done via VSP-owned access facilities. This type of VPN network outsourcing is known as an 'unbundled' or 'wires-only' service. SLSs are negotiated between the VSP and their customers that allow the customer managed CE's to intercommunicate. In an MDE, when an 'unbundled' service is procured from a VSP by an Agent, the Agent may want to use the 'unbundled' service to extend the geographic reach of their VPN footprint by connecting this service to one or more VPLs. Again, for SLS demarcation purposes, the VSP may express a preference to collocate a network element at each VPL. SLS demarcation points for the selling VSP may then include VPL collocated network elements that are shared across one or more Agents and/or VPNs, access facilities linking the Agent-owned CEs, and common [RFC-2547bis]-based VPN services that span the VSP-owned AS(es). The Agent must then offer SLSs to their customer that encompass the VSPs 'unbundled' service and associated SLS(s), as well as their managed CE offering. There is a requirement, therefore, for consistent 'unbundled' service SLS demarcation points across an MDE. 8.5. Remote CE Management Requirement For contractual and/or technical reasons, Agents or customers have a requirement to manage Customer Edge (CE) network elements that are interconnected as part of a [RFC-2547bis]-based VPN service. In an MDE, the ASes supporting these VPNs may or may not be operated by the Agent. The Agent will in addition to managing VPN services on behalf of their customers, usually operate a management network to which their end customers have restricted or no access. The management network is used to provide as a minimum IP-based connectivity between CEs and the Agent's operations staff, typically located in one or more operations centers. In order for an Agent to directly manage CEs connected to ASes that they do not operate, the Agent will procure 'unbundled' VPN services from one or more VSP partners. In addition to SLSs that are negotiated between the Agent and the selling VSP for CE-to-CE communication, the Agent requires SLSs that encompass the connection of each CE to the Agent's management network. Expires July 1, 2006 [Page 25] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 There is a requirement, therefore, for an Agent to remotely manage CE network elements that are directly interconnected through one or more ASes that are operated by the Agent's VSP partners. The VSP partner should therefore be capable of supporting one or more common management network connectivity methods selected by the Agent. 8.6. End-to-End Combined Services Requirement 8.6.1. Combined VPN and Internet Access Requirement It is common for VSPs to offer combined Internet access and VPN services via a shared networking infrastructure, e.g. based upon [RFC-2547bis]. In an MDE, when an Agent offers this service, it is sometimes advantageous for the Agent if their VSP partners could support the local 'breakout' of traffic destined for the Internet within the VSPs own ASes. An alternative to this is for all customers Internet and VPN traffic to be transported by the Agent's VSP partners across VPLs to Internet 'breakout' location(s) in other ASes. These traffic paths are inevitably suboptimal, raising performance concerns with the Agent's customers. In addition, the service is potentially expensive to deliver for the Agent, as there is little or no differentiation between traffic paths carrying mission-critical VPN traffic and Internet destined best effort traffic as all traffic will be forwarded by the VSP partner across one or more VPLs. There is a requirement, therefore, in an MDE for VSPs to provide consistent Internet 'breakout' services that are compatible with an Agents combined Internet access and VPN services. These compatibility requirements include (but are not limited to): - Security, Authentication, Intrusion Detection, Virus protection services etc. - Consistent QoS policies across VSPs for best effort or better than best effort Internet-destined traffic. 8.6.2. Combined IP and non-IP Application Transport Requirement Some VSPs offer managed services that include the transporting of non-IP application traffic across a shared networking infrastructure based on [RFC-2547bis]. These 'legacy' applications use networking protocols (for example X.25, SNA and IPX) that typically do not support an IP network layer header and therefore cannot natively be transported across VSP operated ASes. The non-IP packets must therefore be 'tunneled' across VSP ASes by adding IP and MPLS headers to the packets. Either end of a 'legacy' application transport tunnel Expires July 1, 2006 [Page 26] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 must support configurations that are based on non-IP application specific configuration parameters for mapping non-IP network layer application sources to destination tunnel network element IP addresses. In an MDE, the non-IP transport tunnel could span one or more VSP-owned ASes. Network elements that originate and terminate packets that are forwarded across these non-IP tunnels could therefore be operated by different VSPs. There is a requirement, therefore, in an MDE for consistent non-IP application transport tunnels to be supported by participating VSPs in an MDE. Tunnel transport consistency per non-IP protocol must take into account amongst others, agreements on MTU sizing, SLS conformance, vendor proprietary and standardized encapsulation techniques etc. 9. Conclusions 10. Acknowledgements This document is the combined effort of the co-editors and the following contributing authors: Dimitri Papadimitriou, James Humphris, Colin Simpson, Matthew Ford, William Copeland and David Page. 11. References 11.1. Normative References [RFC-1771] Rekhter, Y., Li, T., et al., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC-1930] Hawkinson, J., Bates, T., "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996. [RFC-2330] Paxson, V., et al., "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC-2475] Blake, S., et al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC-2865] Rigney, C., et al., "Remote Authentication Dial-In User Service (RADIUS)", RFC 2865, June 2000. [RFC-3644] Snir, Y., et al., "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003. Expires July 1, 2006 [Page 27] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 [RFC-4026] Andersson, L., Madsen, T., "Provider-Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC-4031] Carugi, M., et al., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005. [RFC-4111] Fang, L., et al., "Security Framework for Provider- Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. [RFC-4301] Kent, S., Seo, K., "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 11.2. Informative References [RFC-2547bis] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", draft-ietf- l3vpn-rfc2547bis-03.txt, Work in Progress, October 2004. [Option-d] Kulmala, M., Halstead, M., Soyni, J., "Inter-AS Option for BGP/MPLS IP VPN", draft-kulmala-l3vpn-interas-option- d-01.txt, Work in Progress, October 2005. [VPN-VERIFICATION] Behringer, M., et al., "Layer-3 VPN Import/Export Verification", draft- -ietf-l3vpn-vpn-verification- 00.txt, Work in Progress, March 2005. Expires July 1, 2006 [Page 28] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 Editor's Addresses Jim Guichard Cisco Systems, Inc 300 Beaver Brook Rd Boxborough MA Email: jguichar@cisco.com Martin Halstead Nexagent Ltd Thames Tower 37-45 Station Road Reading Berkshire UK RG1 1LX Email: mhalstead@nexagent.com Christian Jacquenet France Telecom 4, rue du Clos Courtel BP 91226 35512 Cesson-Sévigné Cedex France Email: christian.jacquenet@francetelecom.com 12. 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. Expires July 1, 2006 [Page 29] Internet-Draft draft-halstead-guichard-mavs-requirements-00 January 2006 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. 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 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). 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. Expires July 1, 2006 [Page 30]