M.Iyer Internet Draft A.Jansen Document: draft-iyer-ipvpn-infomodel-req-00.txt Alcatel Expires: August 2001 February 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 RFC2026. 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 An IP VPN is a virtual private network used to deliver IP services implemented over an IP provider network. This document defines the requirements for a policy information model for provisioning IP VPNs. It identifies the network level capabilities that need to be represented in the policy information model. Table of Contents 1. Introduction 2. Service Level Requirements 3. Service Management Requirements 4. Device Configuration Requirements 5. Standardization Requirements 6. References 1. Introduction The goal of IP VPN provisioning is to align the network elements to provide consistent treatment to selected pieces of IP traffic. The network elements will require a combination of capabilities depending largely on their location in the topology and the technology being used. The service provider needs to be protected from the differences between the different technologies that can be used to provide this capability. In addition the service provider needs to be protected from vendor specific implementation of the technology. The use of a standardized information model to represent the IP services is an effective means of mitigating these issues. The current service level definitions can offer a significant amount of cross technology, cross vendor interoperability at the service definition level. There is a need for a standardized network level definition, which maps to the IP services. This would significantly help the network element alignment issues associated with using different technologies and different vendors within the provider network. The following figure 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 level specifications ----------------- | Device Level | --> Device specific configuration ----------------- This document is organized as follows: 1. Section 2 provides a view of the IP service requirements and its mapping to IP network capabilities. 2. Section 3 provides a view of the administrative requirements that need to be addressed. 3. Section 4 provides a view of the related work that needs to be taken into account when creating a policy information model. The IP VPN Policy Information model should provide a standardized network level specification which helps translate service level specifications to device level configuration for IP VPN services. The IP VPN Policy Information model should reuse the policy information models being developed in parallel for specific IP network capabilities. The IP VPN Policy Information model may make references to standardized technologies where applicable to better describe the requirements on the IP network, e.g. IPSEC terms could be used to better describe encryption requirements which is a basic building block for security services. 2. Service Level Requirements The information model should be able to address the requirements of the IP Services to be provisioned. The IP services will be translated to corresponding and IP network capability. The information model should support modeling of the IP network capability. This section lists the broad categories of IP services and their corresponding IP network capability mapping. The IP Services to be offered by service providers can be divided into 3 service areas - End to End Connectivity - End to End Security - End to End QoS The service provider is looking to provide these services to the customer. The following sections describe these components in each of these service areas. It is important to note that there are dependencies that need to be recognized across these areas. The security requirements as well as QoS requirements are placed on the underlying connectivity. The information model needs to recognize the issues generated by this dependency. The purpose of the following section is not to provide a comprehensive list of all the services to be offered which is going to remain an ever-growing list. The objective is to provide a sample of the types of network capabilities that need to be represented in the IP VPN information model. 2.1 End to End Connectivity The customers require that the service provider give the following types of connectivity: 1. Site-Site: Routing of private network traffic over a shared network. The 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. Site-Internet: Routing of private network traffic to and from a public network. This will require the site-site and site-internet routing capabilities to be represented in the information model. 2.2 End to End Security The customers require that the service provider give them the following types of security 1. Access control for Site-Internet traffic to and from the private network 2. Encryption of Site-Site traffic as it travels over the shared network This will require the access control and encryption capabilities to be represented in the information model. If a customer requirement can be addressed by a topology choice then it should be addressed using connectivity rather security rules to for efficiency reasons both in configuration as well as implementation. For example, a requirement to allow all traffic between two LAN segments except for traffic origination from a specific (less secure) sub network is probably addressed using a security rule. If the LAN segment minus the sub network can be captured in a IP subnet definition it might be possible to address this requirement by appropriately defining the _site_ to the added to the VPN to be the corresponding IP subnet. The information model should support this level of flexibility. 2.3 End to End QoS The customers require that the service provider give them the following types of QoS services: 1. DiffServ marking of Site-Site traffic and Site-Internet traffic before it enters the provider network 2. Bandwidth management: Control over the bandwidth utilization of the dedicated access links. The provider will need to rely on .. 3. Traffic management to optimize the usage of bandwidth in the provider network. This would make it easier to deliver the end to end QoS and guarantee it. 4. Constraint based routing of Site-Site traffic within the shared network to deliver requested QoS. 5. Optimization of the traffic paths to handle planned and unplanned network loads This will require the marking, bandwidth management and traffic management capabilities to be represented in the information model. DiffServ has been accepted as the more scalable of the various QoS schemes and may be referenced when specifying the QoS requirements. The information model should provide an object-oriented representation of policy information associated with provisioning IP VPN services such as firewall, address translation, quality of service, encryption. 3. Service Management Requirements This section lists the service management requirements to be met by the information model. 3.1 Service Provider Administrative Requirements The service provider administrative requirements include domain- based administration of policies, domain based distribution of policies, domain based functional partitioning of policies. The IP VPN policy information model should support the notion of administration domain. This domain decides the various intra provider and inter provider administrative boundaries. 3.1.2 Distribution domain The IP VPN policy information model should support the domain based distribution of policies. The information model should enable efficient distribution of policies to policy consumers which will then update the network elements. 3.1.3 Functional domain The IP VPN policy information model should support function based separation of policies to help the distribution process as well as the definition and inheritance of core functional attributes. 3.2 OSS Interaction Requirements The information model would have to provide the OSS with the adequate hooks to correlate service level specifications with network traffic data generated by the 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 OSS interaction requirements. This would require that the information model support references to the SLS entities used to generate the network level specifications. The use of policies includes rules that control the corrective actions taken by OSS components that are responsible for monitoring the network and ensuring that it meets the service requirements. These policies result in _corrective action_ configuration as opposed to device configuration. The component performing the function of translating the network policies into device level configuration may be called up to generate the _corrective actions_ as well. The resulting _corrective actions_ may very well reuse the constructs on the IP VPN policy information model. 4. Device Configuration Requirements The IP VPN policy information model acts as the link between the service level specifications and the device level configuration. The information model should not be dependent on any specific device configuration mechanisms. The information model should reuse the standardized means of capturing network capabilities of physical devices defined in the IETF standardization groups. This information would be used to identify the policy enforcement points. The information model should support references to the policy targets. The device configuration layer should be provided with sufficient information to identify the devices that need to be configured to provision the service. The device configuration layer should be able to provide sufficient information within the framework of the information model so that it can be identified as a policy target. 5. Standardization Requirements The information model should conform to the standards being developed in the IETF and other standardization bodies. This section briefly describes the related work going on in the Policy Framework WG and what is currently a planned Service Level Specifications WG. The IP VPN policy information model should be based on the _Policy Framework Core Information Model_ [PCIM]. The core model should be extended to address the requirement that network elements understand their role in delivering the IP service to the customer. The network elements receive their configuration in the form of policies. The policy storage and distributed models should conform to the policy framework described in [PFRAME]. The IP VPN policy information model should reuse the work done with regards to modeling the individual network capabilities such as the _QoS Policy Information Model_ [QOSIM] and the _IPSEC Configuration Policy Model_ [IPSECIM]. The corresponding LDAP implementations could be built based on the _Policy Framework LDAP Core Schema_ [PCIM-LDAP] and _QoS Policy Schema_[QOSIM-LDAP] implementations. The IP VPN policy information model should interwork with the emerging MPLS related policy informational models wherever necessary. The IP VPN information model should interwork with the Service Level Specifications [SLS] being developed by interested parties within the IETF. The IETF representatives are holding BOF sessions to decide on the setting up of a working group for service level specifications. The IP VPN policy information model should be able to translate service level definitions generated on the basis of the service level specifications. The policy framework WG is also trying to standardize on information models that describe specific function mechanisms, which are common across devices such as [QDDIM] for QoS policy management. The IP VPN information model should provide a mechanism to extend the information model to leverage this work in future. The extensions would make references to the objects in the newly standardized models for specific functions. 6. References [PFRAME] W. Weiss, H. Mahon, B. Moore, J. Strassner , G. Waters, A. Westerinen, J. Wheeler, "Policy Framework", , Sept 99. [PCIM] J. Strassner, E. Ellesson, B. Moore, "Policy Core Information Model _ Version 1 Specification", Internet Draft , Oct 2000 [QPIM] Y. Snir, Y Ramberg, J. Strassner, R. Cohen, _Policy Framework QoS Information Model_, Internet Draft [QOSIM-LDAP] Y. Snir, Y Ramberg, J. Strassner, R. Cohen, _QoS Policy Schema_, Internet Draft , Feb 2000 [IPSECIM] Jamie Jason, _IPsec Configuration Policy Model_, Internet Draft , July 2000 [SLS] Yves T' joens et all _Service Level Specification Semantics and Parameters_, Internet Draft , Oct 2000 [QDDIM] Strassner, et al. _Information Model for Describing Network Device QoS Mechanisms for Differentiated Services_, Internet Draft , Nov 2000 11. Author's Addresses Mahadevan Iyer Alcatel Inc 595 Yosemite Blvd, Milpitas, CA Phone: 408 586 7687 Email: mahadevan.iyer@ind.alcatel.com Arnold Jansen Alcatel Inc 595 Yosemite Blvd, Milpitas, CA Phone: 408 586 7687 Email: arnold.jansen@ind.alcatel.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation 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.