ppvpn working group M. Iyer Internet Draft Alcatel Document: draft-iyer-ipvpn-infomodel-req-01.txt C. Jacquenet Category: Informational France Telecom R & D Expires December 2001 A. Jansen Alcatel P. Lago Politecnico di Torino R. Scandariato Politecnico di Torino June 2001 Requirements for an IP VPN Policy Information Model Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines the requirements for a policy information model that should help service providers in dynamically provisioning IP Virtual Private Networks (VPN). From this perspective, this draft aims at identifying the basic capabilities that need to be supported by an IP VPN service offering and thus reflected in an IP VPN policy information model, so that IP VPN networks may be dynamically deployed according to the corresponding configuration information. Iyer et al. Informational - Expires Dec. 2001 [Page 1] Internet Draft Reqts. for an IP VPN Information Model June 2001 1. Introduction An IP Virtual Private Networks (IP VPN) can be defined as the collection of switching and transmission resources that will be used by a dedicated set of authorized users to exchange information over a public IP infrastructure, like the Internet. IP VPN networks may use different and complex technologies ([2]), thus yielding the need for a high level of automation to dynamically provision such networks. To do so, the network resources that will be involved in the forwarding of the traffic for a given (set of) IP VPN will have to process quite a large amount of configuration information: - Topology information (e.g. location of the sites that will be interconnected via the IP VPN), - Addressing information (e.g. identification of the IP networks and hosts that will access the IP VPN facility), - Routing information (e.g. definition of a routing policy within the IP VPN, and how the Internet can be accessed through the IP VPN), - Security information (e.g. establishment and activation of filters), - Quality of service (QoS) information related to the service offering (e.g. the QoS parameters that will conveyed in a particular Service Level Specification (SLS) template ([3]), and that will be (dynamically) negotiated and invoked between the customer and the service provider, like the bandwidth, the one-way delay, the inter-packet delay variation, [4]). The end result of the configuration is to align the network elements to provide consistent treatment of the selected pieces of IP traffic that will reflect the deployment of an IP VPN. The network elements will require a combination of capabilities depending largely on their location in the topology and the technology being used. In addition, the IP VPN policy information model can help in defining a standard interface to VPN facilities supported by an IP network. This interface is useful for dynamic and customizable definition of provided VPN services based upon customer needs. Therefore, the purpose of this draft is to develop a motivation for an IP VPN policy information model that will aim at providing a common understanding on how the corresponding IP VPN service is to be deployed over the network according to instances of the above information, between the service level and the network level associated to the above-mentioned definition of an IP VPN. Iyer et al. Informational - Expires Dec. 2001 [Page 2] Internet Draft Reqts. for an IP VPN Information Model June 2001 This document is organized as follows: - Section 3 provides basic assumptions and requirements as far as the motivation for an IP VPN policy information model is concerned, - Section 4 provides a list of requirements as far as the IP VPN service level is concerned, - Section 5 provides a list of requirements as far as the IP VPN network level is concerned, - Section 6 provides some elaboration as far as the compliance with existing and ongoing standardization effort is concerned. 2. 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 [5]. 3. Basic assumptions and requirements The IP VPN Policy Information model SHOULD provide a standardized view of the network-related information that will be expressed in terms of network element configuration information, and which will help the mapping of the information conveyed in the (IP VPN) service level specifications (SLS) to the device level configuration information for the provisioning of IP VPN services. The following figure 1 explains the positioning and role of the IP VPN policy information model in relation to the service level specifications and the device level specifications. ----------------- | Service Level | --> SLS capture customer requirement/service goals ----------------- <>---------> Service goal to network policy translation ----------------- | Network Level | --> IP VPN policies capture network requirements ----------------- <>---------> Network policy to devices configuration information ----------------- | Device Level | --> Device specific configuration information ----------------- - Fig. 1: positioning of an IP VPN information model. - The IP VPN policy information model SHOULD provide a standardized network level specification, which will aim at translating the Iyer et al. Informational - Expires Dec. 2001 [Page 3] Internet Draft Reqts. for an IP VPN Information Model June 2001 service level specifications information into device level configuration information. To this aim, the IP VPN policy information model SHOULD be able to cope with different needs brought up by various provisioned IP VPN services. The integration of these needs at the information model design stage leads to a straightforward translation of service specifications into network policy instances at the deployment stage. On the other hand, the IP VPN policy information model SHOULD be able to capture network-related information in order to enable policy- based management systems to translate policies into device configuration files. Network information hereby refers to both device capabilities and topology information: - The device capabilities information is needed to perform controls against requirements like serviceability (e.g. to check if the provider has the appropriate resources to deploy an IP VPN service that will comply with customer's requirements) and feasibility (e.g. to check if resources are available), - The topology information is needed to identify which nodes are involved in the IP VPN service deployment. The IP VPN policy information model SHOULD also be able to reflect the fact that the IP VPN service offering SHOULD benefit from the intrinsic security and quality of service capabilities of the network. This can be made possible by using extensions and appropriate placeholders within the IP VPN policy information model. 4. Service Level Requirements The service parameters that describe the IP VPN service offering, in terms of routing, QoS, security information, etc. will be mapped to corresponding network parameters, like tunnel endpoints identification and link metrics for IP forwarding and routing considerations respectively, PHB (Per Hop Behaviors,[6]) for QoS considerations, and access control lists for security considerations, etc. The IP VPN service offering to be provided by an ISP (Internet Service Provider) SHOULD include the ability to specify service requirements related to connectivity, security and QoS considerations. It is important to note that there are dependencies that need to be taken into account across these service parameters. For example, the security requirements as well as the QoS requirements could be described with respect to an underlying connectivity requirement. The IP VPN policy information model MUST recognize the issues generated by that kind of dependency. Iyer et al. Informational - Expires Dec. 2001 [Page 4] Internet Draft Reqts. for an IP VPN Information Model June 2001 In addition, the IP VPN policy information model SHOULD be able to capture information related to the following parameters: - Reliability: IP VPN services should address reliability issues that can be compared to those addressed by IP networks. The IP VPN policy information model MUST therefore take care of these aspects. - Scalability: at the service level, the IP VPN policy information model SHOULD be scalable enough to take into account both large- scale and small-scale IP VPN networks. Additionally, it SHOULD be flexible in order to support changes of virtual network dimensions with no disruption of former deployed services. - Multi-protocol support: whatever the IP routing policy that may be enforced within a location that will be connected to others via an IP VPN, the IP VPN policy information model should be able to reflect the information related to this IP routing policy. The purpose of the following sections 4.x is not to provide a comprehensive list of all the parameters to be serviced, since it is going to remain an ever-growing list. The objective is to provide a sample of the capabilities that SHOULD be represented in the IP VPN policy information model. 4.1. Forwarding and routing considerations Customers of an IP VPN service offering may require that the service provider provision the following types of connectivity: 1. Site-to-Site: forwarding of the private traffic (i.e. the traffic that will correspond to private communications within the IP VPN) over a shared network. The IP VPN policy information model SHOULD support various possible topologies for site-to-site connectivity e.g. point-to-point, hub and spoke, full mesh, partial mesh, etc. 2. Access to the IP VPN for residential and nomadic users: forwarding of private traffic to and from (dial-up) users, according to a VPDN (Virtual Private Dial-up Network, [2]) scheme is a MUST for an IP VPN service offering. 3. Access the Internet from the IP VPN: forwarding of private and public traffic within the IP VPN is a MAY for an IP VPN service offering. 4. Deployment of IP VPN networks for communities of interest: within the context of supporting extranet applications, i.e. applications that may be used by different customers within a single IP VPN, the IP VPN policy information model SHOULD include this facility. Iyer et al. Informational - Expires Dec. 2001 [Page 5] Internet Draft Reqts. for an IP VPN Information Model June 2001 This will require the corresponding forwarding parameters to be represented in the IP VPN policy information model. 4.2. Security considerations Customers of an IP VPN service offering MAY require that some guarantees be provided as far as the following aspects are concerned: 1. Identification and authentication of the users that will have the ability to access the IP VPN, including those users that belong to a given community of interest (please refer to point 4 of the above section 4.1 of this draft), 2. Preservation of the confidentiality of the information that will be conveyed by the IP VPN, 3. Identification and authentication of the switching resources that will participate in the forwarding of the traffic associated to a given IP VPN, 4. Secured access to the sites that will be interconnected by the IP VPN: site protection against malicious attacks, including spoofing communications. This will require the corresponding security parameters (filters, encryption aspects, firewall configuration information, etc.) to be represented in the IP VPN policy information model. 4.3. QoS considerations Customers of an IP VPN service offering may require that the IP VPN be provisioned with a given level of quality, that can be defined in terms of ([6]): 1. Traffic identification, classification and marking parameters, 2. Traffic scheduling parameters, 3. Traffic discarding parameters, 4. Traffic policing parameters. The provisioning of such QoS-based IP VPN networks may therefore gracefully rely upon DiffServ-based and traffic engineering techniques that will aim at selecting and installing the IP VPN routes that will comply with the above-mentioned QoS requirements, including load sharing and restoration capabilities in case of link failure, for example (see [7] as a possible reference). Iyer et al. Informational - Expires Dec. 2001 [Page 6] Internet Draft Reqts. for an IP VPN Information Model June 2001 This will require the marking, scheduling, bandwidth management and traffic management capabilities to be represented in the IP VPN policy information model, especially because the DiffServ architecture has been widely promoted as the most scalable architecture of the various QoS schemes and it SHOULD be referenced when specifying the QoS requirements. 4.4. Management considerations 4.4.1. Domain-wide considerations The deployment of IP VPN services over the Internet raises the inter- domain issue, where all the network resources that may be involved in the forwarding of the IP VPN traffic do not belong to the service provider who deploys the IP VPN. From this standpoint, the service provider requirements include at least domain-wide administration of (routing) policies, domain-wide distribution of (routing) policies, domain-wide functional partitioning of policies, i.e. the logical separation between the management of a routing policy, a QoS policy, a security policy, etc., so as to reflect the management organization of the service provider. 4.4.1.1. Administrative domain considerations The IP VPN policy information model MUST support the notion of administrative domain. In particular, this implies the definition of inter-domain boundaries. 4.4.1.2. Enforcing policies within a domain The IP VPN policy information model SHOULD enable the enforcement of various policies (a routing policy, a QoS policy, a security policy, etc.) on a domain scale. The IP VPN policy information model SHOULD be designed so that the enforcement of such policies be efficient. The policies are distributed to agents who act as policy consumers ([8]). The policy consumers will in turn update the relevant network elements. 4.4.1.3. Design considerations The IP VPN policy information model SHOULD also be designed on a per policy basis, so as to optimize the distribution process (e.g. update the policy provisioning data that need to be updated, and only this information). 4.4.2. Service management platform interaction Requirements The IP VPN policy information model MAY provide the service management platform with the adequate hooks to correlate service level specifications with network traffic data generated by the Iyer et al. Informational - Expires Dec. 2001 [Page 7] Internet Draft Reqts. for an IP VPN Information Model June 2001 network elements. There are no specific requirements coming out of this, other than the need to ensure that there is a reversible mapping of the network level specifications to the service level specifications. This would be a basic requirement regardless of the management platform interaction requirements. This would require that the IP VPN policy information model support references to the SLS templates whose parameters will be used to generate/map to the network level parameters. The use of policies includes rules that control the corrective actions taken by management components that are responsible for monitoring the network and ensuring that it meets the IP VPN service requirements. These policies result in corrective action configuration information as opposed to device configuration information. The component performing the function of translating the policy provisioning data into device level configuration information MAY be called up to generate the corrective actions as well. The resulting corrective actions MAY reuse the classes defined in the IP VPN policy information model. 5. Network level Requirements The IP VPN policy information model SHOULD also support the modeling information related to the IP network-based capabilities that will participate in the deployment of a given IP VPN, as well as the configuration information related to the forwarding of the traffic associated to a given IP VPN. 5.1. Network topology considerations The IP VPN policy information model SHOULD provide a means of capturing the network topology information, including the components of the network topology (links, routers, etc.). From this standpoint, the IP VPN policy information model SHOULD consist of policy data, which reference objects that have been specified in a network topology part of the model. The network topology part of the IP VPN policy information model SHOULD be able to trace the status of the network in terms of available physical resources and to tail resource allocation needed for IP VPN provisioning. The topology information SHOULD be as generic as possible in order to be applicable in different network scenarios. In particular: - The model SHOULD consider both permanently connected users (e.g. users who always work in their office) and nomadic users (e.g. users who can access the IP VPN from home). Iyer et al. Informational - Expires Dec. 2001 [Page 8] Internet Draft Reqts. for an IP VPN Information Model June 2001 - The model SHOULD be applicable within the context of a multi- provider environment. Additionally, the topology part of the model SHOULD allow the disjoined definition of physical and virtual entities (e.g. physical and virtual interfaces of an IP VPN router). However, the IP VPN policy information model SHOULD track mappings between physical and virtual entities to allow identification of policy targets. For instance, the topology part of the model SHOULD allow the identification of tunnels that will be established over the Internet without implying the routers of the core of the network. However, the model SHOULD maintain mappings between tunnels and links that are used by the tunnel. This allows the identification of "intermediate" policy targets (the core routers in the above example), e.g. for QoS provisioning purposes. 5.2. Device capability considerations The IP VPN policy information model SHOULD re-use the standardized means of capturing network capabilities of physical devices defined in the IETF and DMTF standardization groups. This information is related to capabilities that are supported by network elements. The IP VPN information model SHOULD support references to the corresponding policy targets. 5.3. Device configuration considerations The IP VPN policy information model acts as the link between the service level specifications and the device level configuration information. The IP VPN policy information model SHOULD not depend on any specific device configuration mechanisms. The entity that will be involved in the enforcement of an IP VPN policy should be provided with sufficient information to identify the devices that need to be configured to provision the service. This is one of the goals of topology part of the model: this entity should be able to provide sufficient information within the framework of the information model so that it can be identified as a policy target. The device configuration layer MAY then rely upon one of the candidate protocols to update the configuration information of the network elements, and these protocols include SNMP (Simple Network Management Protocol, [9]), and COPS (Common Open Policy Service, [10]). 6. Compliance with existing and ongoing standardization efforts The IP VPN policy information model SHOULD conform to the standards being developed in the IETF and other standardization bodies. As an example, the IP VPN policy information model SHOULD reference Iyer et al. Informational - Expires Dec. 2001 [Page 9] Internet Draft Reqts. for an IP VPN Information Model June 2001 standardized technologies wherever applicable, to adequately describe specific requirements, e.g. IPSec (IP Secure, [11]) terminology could be used to accurately describe encryption requirements that will reflect part of the security considerations (please refer to the section 4.2 of the current draft). Furthermore, the IP VPN policy information model SHOULD be based upon the ôPolicy Framework Core Information Modelö [8] and its extensions ([12]). The IP VPN policy information model should reuse the work done with regards to modeling the individual network capabilities such as the ôPolicy Framework QoS Information Modelö [13] and the ôIPSEC Configuration Policy Modelö [14]. The possible LDAP (Lightweight Directory Access Protocol, [15]) implementations of the IP VPN policy information model COULD be built based on the ôPolicy Core LDAP Schemaö [16] and ôPolicy QoS Information Modelö[17] implementations. The IP VPN policy information model SHOULD also inter-work with the emerging MPLS (Multi-Protocol Label Switching, [18]) related policy informational models wherever necessary. The policy framework WG is also aiming at standardizing information models that describe specific function mechanisms, which are common across devices such as [19] for QoS policy management. Finally, the IP VPN information model SHOULD provide a mechanism to extend the information model to leverage this work in future. The extensions would reference additional objects in the newly standardized models for specific functions. 7. Security Considerations There is a strong requirement for ensuring security related to the provisioning of configuration information. The IP VPN policy information model SHOULD provide the ability to specify administrative rights associated to the use and the transmission of the provisioning information. It SHOULD also support the flexibility required to reflect administrative boundaries, which could in turn be divided into functional boundaries. There are also security concerns associated with the propagation of the IP VPN policy provisioning data to the network elements, that MUST participate in the global enforcement of an IP VPN provisioning policy, and to the customers (including service providers within an inter-domain context) who may access such data. 8. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Iyer et al. Informational - Expires Dec. 2001 [Page 10] Internet Draft Reqts. for an IP VPN Information Model June 2001 [2] Gleeson, B. et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. [3] Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G., Egan R., Griffin D., Georgatsos P., Georgiadis L., "Specification of a Service Level Specification (SLS) Template", draft-tequila-sls-00.txt, Work in Progress, November 2000. Check http://www.ist-tequila.org for additional information. [4] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Blake, S. et al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [7] Awduche, D., et al., "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [8] Moore, B. et al., "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [9] Harrington, D. et al., "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [10] Yavatkar, R., et al., "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [11] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [12] Moore, B., et al., "Policy Core Information Model Extensions", draft-ietf-policy-pcim-ext-01.txt, Work in Progress, April 2001. [13] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., ôPolicy Framework QoS Information Modelö, draft-ietf-policy-qos-info- model-03.txt, Work in Progress, April 2001. [14] Jason, J., et al., "IPsec Configuration Policy Modelö, draft- ietf-ipsp-config-policy-model-02.txt, Work in Progress, March 2001. [15] Sermersheim, J., et al., "Lightweight Directory Access Protocol (v3)", draft-ietf-ldapbis-protocol-01.txt, Work in Progress, February 2001. [16] Strassner, J. et al., "Policy Core LDAP Schema", draft-ietf- policy-core-schema-11.txt, Work in Progress, May 2001. [17] Snir, Y., et al., "Policy QoS Information Modelö, draft-ietf- policy-qos-info-model-03.txt, Work in Progress, April 2001. [18] Rosen, E., et al., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. Iyer et al. Informational - Expires Dec. 2001 [Page 11] Internet Draft Reqts. for an IP VPN Information Model June 2001 [19] Moore, B., et al., "Information Model for Describing Network Device QoS Datapath Mechanisms", draft-ietf-policy-qos-device- info-model-03.txt, Work in Progress, May 2001. 9. Authors' Addresses Mahadevan Iyer Alcatel Inc 595 Yosemite Blvd, Milpitas, CA Phone: 408 586 7687 E-Mail: mahadevan.iyer@ind.alcatel.com Christian Jacquenet France Telecom R & D DMI/SIR 42, rue des Coutures BP6243 14066 Caen Cedex 4 France Phone: +33 2 31 75 94 28 E-Mail: christian.jacquenet@francetelecom.com Arnold Jansen Alcatel Inc 595 Yosemite Blvd, Milpitas, CA Phone: 408 586 7687 E-Mail: arnold.jansen@ind.alcatel.com Patricia Lago Politecnico di Torino Dip. Automatica e Informatica Corso Duca degli Abruzzi, 24 10129 Torino, Italy Phone: +39 011 564 7008 E-Mail: patricia.lago@polito.it Riccardo Scandariato Politecnico di Torino Dip. Automatica e Informatica Corso Duca degli Abruzzi, 24 10129 Torino, Italy Phone: +39 011 564 7091 E-Mail: riccardo.scandariato@polito.it Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it Iyer et al. Informational - Expires Dec. 2001 [Page 12] Internet Draft Reqts. for an IP VPN Information Model June 2001 or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Iyer et al. Informational - Expires Dec. 2001 [Page 13]