Martin Halstead IETF Internet Draft Nexagent Ltd Jim Guichard Cisco Systems, Inc. Expires: May 2006 November 17, 2005 draft-Halstead-Guichard-MAVS-Requirements-00 Requirements for Multi Autonomous System VPN services 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 complements [RFC4031] and defines requirements that are specific to the provisioning of VPN services, potentially at the scale of the Internet. These requirements are independent of underlying technologies or the number of Autonomous Systems such VPNs may span. In addition, it lists the requirements of the different entities that are involved in the administration of these Autonomous Systems and may therefore be involved in the provisioning processes 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...................................................2 2. Contributing Authors...........................................3 3. Definitions....................................................3 Halstead Expires May 17, 2006 [Page 1] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 4. Multi Network Environment Reference Model......................6 4.1. Distributed Agent Multi Network Environment...............6 4.2. Centralized Agent Multi Network Environment...............7 4.2.1. Enterprise IT Department as the Centralized Agent....7 4.2.2. Integration Service Provider as the Centralized Agent7 5. Problem Statement..............................................7 6. Customer Agent MNE Requirements................................8 6.1. Capital Scaling Requirement...............................8 6.2. Operational Scaling Requirement...........................8 6.2.1. Service Independence Requirement.....................8 6.2.2. Minimize Network Integration Requirement.............9 What's the "transitivity" problem? The impact of a bilateral agreement (interconnect design) on other agreements?......Error! Bookmark not defined. 6.3. Service Provider VPN Policy Control.......................9 6.3.1. VPN Topology Requirement.............................9 6.3.2. End-to-end QoS Policy Requirement...................10 6.3.3. Optimal Interconnect Selection Requirement..........11 6.3.4. End-to-end Unicast Routing Policy Requirement.......11 6.3.5. End-to-End Multicast Routing Requirement............12 6.3.6. Homogenous Measurement Requirement..................12 6.4. Remote Service Interconnect Requirement..................12 6.5. Redundant Interconnect Requirement.......................13 6.6. Security Requirement.....................................13 6.7. Third Party Interconnect Requirement.....................13 7. Conclusions...................................................14 8. Acknowledgments...............................................14 9. References....................................................14 9.1. Normative References.....................................14 9.2. Informative References...................................14 Author's Addresses...............................................14 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................15 Copyright Statement..............................................15 Acknowledgment...................................................15 1. Introduction This document summarizes a list of requirements specified by all parties involved in the delivery of VPN services that span multiple Autonomous Systems on behalf of their end customers. Such parties include, but are not limited to, Enterprise IT departments, Network Service Providers (NSP), Systems Integrators (SI), Network Integrators (NI) and Virtual Network Operators (VNO). Section 3 specifies the roles of these parties, while section 4 details examples of each operator type and how these operators interact to Halstead Expires May 17, 2006 [Page 2] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 deliver VPN services. Section 6 lists the requirements of the parties involved in the delivery of multi-AS specific VPN services. 2. Contributing Authors This document is the combined effort of the two co-editors and the following contributing authors: Christian Jacquenet Dimitri Papadimitriou James Humphris Colin Simpson 3. Definitions In order to clarify the requirements listed in this document, it is necessary to define the parties that contribute towards delivering the multi provider 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 interconnect VPN service endpoints (sites) of a common subscriber VPN Peering Location (VPL): A physical location where two or more NSP VPN service domains are interconnected. An NSP or SP may operate the VPL. Examples of VPLs include a network operator hotel, SP central office, a collocation facility or any building common to two or more SPs. Customer: A customer is a single organization, corporation, or enterprise that administratively controls a set of sites. The customer for the purposes of this document has their VPN services delivered via a MNE. Examples of customers include Multi National Corporations and Small to Medium Enterprises. Service Provider (SP): A SP is an operator who delivers some aspect of a VPN service to a customer. In delivering the VPN service, the SP may or may not own networking footprint. Examples of SPs include Network Service Providers (NSP), Systems Integrators (SI), Network Integrator (NI), Cable Operator (CO), Mobile Operator (MO) and Virtual Network Operators (VNO). Halstead Expires May 17, 2006 [Page 3] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 Network Service Provider (NSP): A NSP is defined as any operator that utilizes their private network footprint for the delivery of VPN services. NSPs typically operate one or more Packet Switched Networks (PSNs). Examples include Transport Service Providers, Systems Integrators, Cable Operators, and Mobile Operators. Agent: An Agent is a set of SPs and/or NSPs designated by a customer who have the authorization to manage a customer's VPN service offering. The management relationship the Agent has with the customer could be business (contractual) and/or operational. The contractual management relationship mandates that the Agent will be responsible for fulfilling the customer’s requirements for the enforcement of a set of policies within a MNE. This Policy Agent function could, in addition include an operational management capability that allows them to operationally agree or coordinate policies across the parties involved in delivering the end-to-end service via a MNE. This additional operational (Ops) agent function may be distributed or centralized. Where the Ops Agent is a NSP, the NSP Ops Agent may communicate between all relevant NSP Ops Agents to agree upon the enforcement of consistent policies for VPN service provisioning purposes. In this case, the function of the Ops Agent is distributed across multiple SPs. Alternatively, the customer or policy agent may define their routing requirements and outsource their MNE service policy to an Ops Agent, such as a NSP, SI, VNO, CO or MO, who will centrally coordinate the enforcement of policies related to the provisioning of a VPN service. In contrast to the distributed Ops Agent, the centralized Ops Agent may not require end-to-end agreement of service policy across all parties that supply services to his MNE. In addition, it is of importance to introduce the notion of Policy Repository. The Policy Repository may be co-located with the Ops Agent or exist as separate entities. 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. Policy Agents are usually driven by Policy Managers (here referred to as a policy orchestrator (PO)); in addition to this it is of importance to Halstead Expires May 17, 2006 [Page 4] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 introduce the notion of Policy repository; they may be co-located with the PO or be separate entities. Policy Orchestrator (PO): The authority responsible for the physical and logical integration of the MNE. In addition, the PO is responsible for the operation and multi party business process definitions on behalf of the PA. The PA may directly fulfill the multi-provider VPN service by performing the integration of the multi providers VPN environment themselves - in this case the PA would also be the PO. Alternatively, the PA may outsource the physical and logical fulfillment as well as interconnect processes of the multi-provider VPN service to a third party ‘trading club’. The ‘trading club’ operator would then be the PO on behalf of the PA. Halstead Expires May 17, 2006 [Page 5] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 4. Multi Network Environment Reference Model Figure 1 shows a generic reference model for a Multi Network Environment. It shows the relationships that exist between the various parties involved in the establishment of VPN services that span multiple provider networks. |<------------Multi Network Environment---------->| | | | Users | | | | | Customer | | | | | Agent | | | | | | Policy Agent | | | | | | | +---------------Ops Agent(s) --------------+ | | | | | | | | | | NSP1 VPL1 NSP2 | | | | ^ ^ ^ | | | 1..n 1..n 1..n 1..n 1..n | | V V V V V | |Site1 <---> PSN1<--->(VPL1)<---> PSN2 <---> Site2| Figure 1 - - MNE Reference Model The following section details examples of the coordination of the various parties in the enforcement of a set of policies including, but not necessarily limited to addressing, routing, QoS and security for the provisioning of an inter-domain VPN service that will comply with a customers service requirements. 4.1. Distributed Agent Multi Network Environment. In this model, the MNE consists of a community of SPs and/or NSPs that use and operate the network resources of a MNE facility to deploy and exploit a VPN service offering. The Customer will define their routing requirements and let the SP and/or NSP enforce the corresponding policy that addresses such requirements. An Ops Agent will exist per SP and/or NSP, all of which will agree upon the enforcement of consistent policies. With reference to Figure 1, the Policy Agent is a single NSP (either NSP1 or NSP2). Ops Agents then consist of SP1 and SP2, both of which share the management of VPL1. Halstead Expires May 17, 2006 [Page 6] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 4.2. Centralized Agent Multi Network Environment The following are examples of an Agent centrally coordinating services across a MNE. These MNE environments are dedicated to the commercial purposes of a single Agent in fulfilling a VPN service on behalf of their customer(s). 4.2.1. Enterprise IT Department as the Centralized Agent The Agent could be an Enterprise IT department who holds the Commercial Agent relationship with the customer. In addition, the IT department is responsible for the enforcement of the customer’s network policy by acting as the Ops Agent. The IT department manages the VPLs and processes involved in interconnecting the VPL to the NSP VPN domains. NSP1 and NSP2 independently provide VPN services via their PSNs to the Ops Agent who is responsible for integrating each NSPs VPN service offering. 4.2.2. Integration Service Provider as the Centralized Agent In this model, the Commercial Agent could be an Enterprise IT department. The IT department outsource their customer’s network policy to an Ops Agent who is a SP such as a SI, NI, VNO or NSP. The Ops Agent will manage the VPL and associated VPN services interconnects, as well as coordinate end-to-end VPN services delivered by SP1 and SP2’s PSN networks. 5. Problem Statement No single network can deliver VPN services that provide optimal price and performance for all customers or all customer locations, if such locations are connected through domains administered by different entities. For regulatory, resiliency and other reasons, customers may demand that multiple NSP networks are used to deliver their VPN services. As a result, 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 VPN service must be delivered regardless of the MNE. The challenge for the Agent in controlling ‘global’ service policy in an MNE environment is the lack of homogenous policy amongst NSP networks and the difficulty SPs have in adapting their single NSP VPN service domains to the PA owned VPN service policy. This document defines common requirements for implementing and operating an MNE. Halstead Expires May 17, 2006 [Page 7] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 6. Customer Agent MNE Requirements 6.1. Capital Scaling Requirement In an MNE, there might be one or more VPLs. At each VPL there may be one or more interconnected NSPs, or a single operator that uses the VPL for connectivity between their own Autonomous Systems. Traditionally, the interconnection of two NSPs, the so called bilateral interconnect, has resulted in the deployment of network element resources that are either dedicated to those two NSPs, or leased from the owner of the peering point. Where there is a need for a SP to interconnect with multiple other NSPs, 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. 6.2. Operational Scaling Requirement Cost of operations is of great concern to a NSP, whether or not VPN services span their own Autonomous Systems or those of partners. Compared to the capital cost of MNE interconnection, operational cost easily dominates. In an MNE, some, and perhaps all SPs, might play a part in an individual customer solution. Within a customer solution, sites, physical and logical connectivity, SPs, 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 SPs, 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. 6.2.1. Service Independence Requirement In an MNE, it is inevitable that dependencies will exist between the services of individual SPs. For example, a lack of forethought by the Ops agent by implementing a ‘tightly-coupled’ interconnect environment would result in single NSP 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. Halstead Expires May 17, 2006 [Page 8] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 6.2.2. Minimize Network Integration Requirement Currently there is no common agreement for how SPs implement the interconnection of their VPN networks. This means that each instance of interconnect 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. Unique network integration projects amongst NSP pairs must therefore be minimized. 6.3. Service Provider VPN Policy Control 6.3.1. VPN Topology Requirement Although VPN networks 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 company 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, 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 Halstead Expires May 17, 2006 [Page 9] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 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. Moreover, an inventory of this topology consisting of elements such as the network elements/interfaces and the set of paths that traffic may take through the network should be made available. These elements will most likely constitute a partial topological view of the network but would be sufficient for the purpose of QOS policy definition. There is therefore, a requirement to be able to establish an end-to-end VPN topology, including network elements and interfaces throughout an MNE. 6.3.2. End-to-end QoS Policy Requirement Currently, there are no standards for or agreement of service definitions amongst network SPs. [RFC3644] defines QoS policy as being dependent upon three types of information; The topology of the network devices under management (e.g. Diffserv), the particular type of QoS methodology used and the business rules and requirements for specifying service(s) delivered by the network. These information types vary across SP/NSP and customer domains. Consequently, network operators deploy a different number of classes of service (COS) and specify service definitions in proprietary ways. 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 of a QoS policy can vary within a single customer. Indeed, as depicted in RFC3644, the definition of QoS policy is dependent on three types of information: 1) the topology of the network devices under management, 2) the particular type of QoS methodology used and 3) the business rules and requirements for specifying service(s) delivered by the network. 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 enforcement may be hard to achieve. There is a requirement, therefore, for a relationship to exist between network operator classes of service that may vary from one customer Halstead Expires May 17, 2006 [Page 10] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 to another, 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 may be desirable for the customer 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. [RFC4031] describes this requirement as a ‘Carrier’s Carrier’ model where one SP is the customer of another L3VPN SP. Such an SP should be able to resell VPN service to their VPN customers independently of the DSCP mapping solution employed by the ‘Carrier’s Carrier’ SP. There is a requirement, therefore, for enterprise QoS policy transparency throughout an MNE. 6.3.3. Optimal Interconnect Selection Requirement SP multi-homing is the scenario in which an SP needs to interconnect at two or more VPLs. By ensuring that traffic passes between networks at pre-determined VPLs, the desired end-to-end service policy can be established and retained for any customer sites and SP networks can be utilized more efficiently. As an example, consider a customer site in the middle of the USA. It is connected to a SP 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 SPs, there is therefore, a requirement for interconnects to be optimally selectable for each source-destination site pair within an MNE. 6.3.4. End-to-end Unicast Routing Policy Requirement Today there are no standards for, or agreement of, how VPN routing policy based on the policing of the admission and distribution of routing information (classification and filtering of routing information) is implemented amongst SPs. Consequently, SPs implement routing policy within a defined customer topology in different ways. Conflicting routing policies amongst network operators make it very difficult to establish an end-to-end unicast routing policy throughout an MNE. There is, therefore, a requirement to be able to establish a consistent IGP and BGP-based unicast routing policy throughout an MNE. Halstead Expires May 17, 2006 [Page 11] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 6.3.5. 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 SPs 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 SPs. As a result, SPs implement multicast using various different, non-compatible, methods and protocols 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. 6.3.6. Homogenous Measurement Requirement Currently, there are no standards for, or agreement of, measurement methods amongst SPs. SPs define measurements differently and measure different things. In a MNE environment, measurement methodology differences, particularly differences in the statistical nature of the measurements, make it impossible to combine network operator measurement reports so that the overall quality of the VPN service can be qualified. In fact, as SP reports can be so different, it is also tedious and time consuming to analyze whether an individual SP has met their performance targets. When end-to-end service fails, it is very difficult to analyze SP measurement data to detect and isolate faults amongst SPs. In an MNE, where the Ops 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 Ops 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 MNE as well as the ability to place measurement instrumentation/sources at interconnects to aid fault detection and isolation. 6.4. Remote Service Interconnect Requirement In an MNE, agent(s) will incorporate NSPs according to the needs of the customer. Some of these NSPs 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 SP) and once at the second (second to third SP). However, in some situations, MNE operators may choose not Halstead Expires May 17, 2006 [Page 12] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 to use the VPN service of the second (middle) SP. 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 SPs in an MNE. 6.5. Redundant Interconnect Requirement Part of the end-to-end service offering provided by one or more Ops agents involves the provision of appropriate levels of redundancy for their particular MNE use case. In some VPLs, where business justifications exist, the Ops agent 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. 6.6. 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 SPs, 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 NSP backbone to threats from these sources. An attack on a NSP backbone could detrimentally affect numerous customers, including those attached to other SPs. There is a requirement, therefore, to secure NSP backbones and customer services in an MNE. 6.7. 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 SPs, 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 SP partners, the operator wants a third party to provide interconnect services to the group. It may be that the third party is another SP, 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 Halstead Expires May 17, 2006 [Page 13] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 requirement for the interconnect equipment and procedures to be controllable by a third party interconnect services provider. 7. Conclusions 8. Acknowledgments 9. References 9.1. Normative References 9.2. Informative References Author'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 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 Halstead Expires May 17, 2006 [Page 14] Internet-Draft draft-halstead-guichard-MAVS-requirements November 2005 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 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Halstead Expires May 17, 2006 [Page 15]