M. Iyer Internet Draft A. Gonguet Document: draft-iyer-ipvpn-infomodel-03.txt Alcatel Expires: August - 2002 C. Jacquenet France Telecom R&D P. Lago R. Scandariato Politecnico di Torino February 2002 IPVPN 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 specifies the object oriented information model for representing policy information associated with the provisioning of IP VPN services, that include the configuration information related to the setup of the IP VPN connectivity, and may also include the configuration information related to the activation of the following elementary functions: firewall, address translation, quality of service, encryption. As such, this draft extends the core policy information model and the extensions to the core policy information model to cover the policies that need to be enforced to configure all the network elements that will participate in the deployment of the above- mentioned IP VPN services. The information model is independent from Iyer et al. Expires August - 2002 [Page 1] Internet Draft IP VPN February 2002 Policy Information Model the kind of IP VPN technology that may be used to deploy the corresponding service offering. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 0 Conventions used in this document...............................4 1 Introduction....................................................4 2 UML Notation & Terminology......................................6 2.1 UML Notation..................................................6 2.2 Terminology...................................................6 3 IP VPN Information Model........................................7 3.1 Use of policies to define rules...............................8 3.2 Instantiation of IP VPN Information Model classes.............8 3.3 IP VPN Information Model - Policy components..................8 3.4 IP VPN Information Model - Topology components...............10 3.4.1 Physical Topology Components................................12 3.4.2 Virtual Topology Components.................................13 4 Inheritance Hierarchy..........................................14 4.1 Inheritance hierarchy for policy classes.....................14 4.2 Inheritance tree for topology classes........................16 5 Policy Class Definitions.......................................18 5.1 The class ipvpnPolicyVFICreationAction.......................18 5.1.1 The reference AttachedInterface.............................18 5.2 The class ipvpnPolicyRouteDistributionAction.................18 5.2.1 The reference DistributionSource............................18 5.2.2 The reference DistributionDestination.......................18 5.2.3 The reference DistributionMandatoryHops.....................18 5.3 The class ipvpnPolicyVPNTopologyDescriptionAction............19 5.3.1 The reference RoutingSource.................................19 5.3.2 The reference RoutingDestination............................19 5.3.3 The reference RoutingMandatoryHops..........................19 5.4 The class ipvpnPolicyNATAction...............................19 5.4.1 The property TranslateFromIPv4Address.......................20 5.4.2 The property TranslateToIPv4Address.........................20 5.5 The class ipvpnPolicyTrafficTrunkAction......................20 5.5.1 The reference Ingress.......................................20 5.5.2 The reference Egress........................................20 5.5.3 The property Priority.......................................20 5.5.4 The property Preemption.....................................21 5.5.5 The property Resilience.....................................21 5.5.6 The property TrafficProfile.................................21 5.6 The class ipvpnPolicyFirewallAction..........................21 5.6.1 The property Action.........................................21 Iyer et al. Expires August - 2002 [Page 2] Internet Draft IP VPN February 2002 Policy Information Model 5.7 The class ipvpnEncryptionAction..............................22 5.7.1 The property IkeAuthentication..............................22 5.7.2 The property IkeEncryption..................................22 5.7.3 The property IkeDHGroup.....................................23 5.7.4 The property IkeTimeout.....................................23 5.7.5 The property IkeTrafficBasedExpiry..........................23 5.7.6 The property IPSECAuthentication............................23 5.7.7 The property IPSECEncryption................................23 5.7.8 The property IPSECDHGroup...................................23 5.7.9 The property IPSECTimeout...................................24 5.7.10 The property IPSECTrafficBasedExpiry......................24 5.7.11 The property IkePeerAuthenticationMethod..................24 5.8 The Class ipvpnApplicationSignatureValue.....................25 5.8.1 The Property applicationSignature...........................25 6 Topology Class Definitions.....................................25 6.1 The Abstract Class "Node"....................................25 6.2 The Class "CoreNode".........................................26 6.3 The Class "EdgeNode".........................................26 6.4 The Class "LogicalNetwork"...................................26 6.5 The Class "Partition"........................................27 6.6 The Class "IP VPN"...........................................27 6.7 The Class "ProtocolEndPoint".................................27 6.8 The Class "AccessEndPoint"...................................28 6.9 The Class "CoreEndPoint".....................................28 6.10 The Class "VirtualEndPoint".................................28 6.11 The Abstract Class "NetworkService".........................28 6.12 The Class "VirtualForwardingInstance".......................29 6.13 The Abstract Association "Link".............................29 6.14 The Association "CoreLink"..................................30 6.15 The Association "AccessLink"................................30 6.16 The Association "VirtualLink"...............................30 6.17 The Abstract Association "NodeInPartition"..................31 6.18 The Association "EdgeNodeInPartition".......................31 6.19 The Association "CoreNodeInPartition".......................31 6.20 The Association "AccessEndPointInVFI".......................32 6.21 The Association "VirtualEndPointInVFI"......................32 6.22 The Abstract Aggregation "ProtocolEndPointInNode"...........32 6.23 The Aggregation "AccessEndPointInEdgeNode"..................33 6.24 The Aggregation "CoreEndPointInEdgeNode"....................33 6.25 The Aggregation "CoreEndPointInCoreNode"....................33 6.26 The Aggregation "VirtualEndPointInEdgeNode".................33 6.27 The Aggregation "VFIInEdgeNode".............................34 6.28 The Aggregation "EdgeNodeInIPVPN"...........................34 7 Generation of device configuration information and IP VPN topology..........................................................34 8 Device Capabilities Model......................................35 Iyer et al. Expires August - 2002 [Page 3] Internet Draft IP VPN February 2002 Policy Information Model 9 Reliability and Scalability in the Information Model...........35 10 Extending the IP VPN policy information model..................36 11 Security Considerations........................................37 12 References.....................................................37 13 Authors' Addresses.............................................38 Full Copyright Statement..........................................39 0 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]. 1 Introduction An IP Virtual Private Network (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 shared IP infrastructure, hereafter called "the network". The IP VPN information model aims at providing a common understanding on how the corresponding IP VPN service is to be deployed over the network. This objective is achieved by identifying the various kinds of configuration information that needs to be provided for defining an IP VPN. The following figure provides a graphical view of where the information model fits in, with respect to the service goals and the device configuration. ----------------- | 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 ----------------- - Figure 1. Positioning of an IP VPN information model - An IP VPN network is deployed according to (policy) provisioning data that can be classified into the following categories of information: - Topology information (e.g. location of the sites that will be interconnected via the IP VPN), Iyer et al. Expires August - 2002 [Page 4] Internet Draft IP VPN February 2002 Policy Information Model - 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 ([6]), 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, [7]). These pieces of information will be captured in the form of rules. The rules reflect the customer requirements at the service level translated into network requirements. The generation of device configuration information based on these rules will ensure that the network elements are aligned to service customer's requirements, as far as the actual provisioning of the IP VPN service offering is concerned. The network elements configured using this information will be able to provide consistent treatment to the relevant IP traffic. The dynamic provisioning of the appropriate configuration information to the appropriate network elements has significant advantages. It will introduce a high level of automation in the actual provisioning of the IP VPN service offering. It will provide some guarantees as far as the consistency of such configuration information is concerned, thanks to the use of the IP VPN policy information model being described in this document. This draft is organized as follows: - Section 2 provides a quick introduction to the Unified Modeling Language (UML, [8]) graphical notation used in this document and the terminology used in this document, - Section 3 provides an overview of the IP VPN information model, - Section 4 provides the inheritance hierarchy for the classes in the IP VPN information model, - Section 5 provides details on the classes defined in the information model, - Section 6 provides details on the topology components of the information model, - Section 7 provides details on the generation of device configuration information and IP VPN topology. Iyer et al. Expires August - 2002 [Page 5] Internet Draft IP VPN February 2002 Policy Information Model - Section 8 provides details on the device capabilities model to be supported by physical nodes that can be referenced by the IP VPN, - Section 9 provides details on the reliability and scalability information available in the information model, - Finally, section 10 deals with extending the IP VPN policy schema. 2 UML Notation & Terminology 2.1 UML Notation The information model is presented in this document using UML notation since it is a well accepted standard and it provides a task-independent way to model systems. - Boxes represent classes, - An "o" denotes an aggregation. An aggregation is essentially a reference, - An "x" denotes containment. A contained object is owned entirely by the container, - The association line may be annotated with "multiplicity" which indicates the number of objects aggregated or contained. - A range of the form "a..b" indicates the minimum and maximum number of objects, - An asterisk indicates any number of objects. 2.2 Terminology This section lists some of the terms used in this document and the definitions corresponding to the usage of these terms in the document. IP VPN: 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 shared IP infrastructure, hereafter called "the network". IP VPN awareness: IP VPN awareness is the collection of knowledgeable information that needs to be maintained by a component that participates in the deployment and the maintenance of a given IP VPN. Such knowledge includes the routes for every destination prefix that is part of the IP VPN topology. Iyer et al. Expires August - 2002 [Page 6] Internet Draft IP VPN February 2002 Policy Information Model Partition: The provider network is organized into partitions. A partition is an administrative entity defined on the basis of one or more of the following criteria: - Technology boundaries (to aggregate network segments within the same network and/or tunneling technology), - Administrative boundaries, - Scalability requirements. SLA: Service Level Agreement. An SLA is a contractual document that a customer and a service provider have agreed upon. SLS: Service Level Specification. An SLS is the technical and detailed specification of an SLA. Traffic Trunk: A traffic trunk is a logical pipe between two network elements. This logical pipe handles point-to-point traffic between the network elements. It is realized in the network using the appropriate link type e.g. MPLS (Multi-Protocol Label Switching, [9]) LSP (Label Switched Path), ATM (Asynchronous Transfer Mode) PVC (Permanent Virtual Circuit), etc. The usage of traffic trunks in this document extends the definition of traffic trunks in [10] to include non-MPLS-capable implementations of the trunk. 3 IP VPN Information Model The IP VPN information model includes policy components and topology components. The policies make references to the physical topology components. The provisioning system creates a virtual topology to meet the requirements captured in the policies. The information required for the provisioning of an IP VPN service offering, and which have been organized in the introduction section of this draft, are captured in the form of rules. The rules reflect the customer requirements at the service level translated into network requirements. The device configuration information is generated using these rules. The device configuration information results in the creation of a virtual topology over the physical topology. The physical topology identifies policy targets for IP VPN deployment. The virtual topology is used by the provisioning system to track the current status of the network resource allocation, due to previous IP VPN related configuration. This section provides an overview of the IP VPN policy information model. Subsequent sections will elaborate on the components of the IP VPN policy information model identified in this section. Iyer et al. Expires August - 2002 [Page 7] Internet Draft IP VPN February 2002 Policy Information Model 3.1 Use of policies to define rules There are different ways of defining rules. The rule definition approach adopted in this draft is based on policies as defined by the policy framework WG [2]. The core classes defined by this WG address common rule definition requirements such as prioritization and reuse of rule building blocks such as conditions and actions. The core classes have been extended to address the requirements that are specific to the IP VPN domain. The storage and distribution recommendations in [11] can be applied to the storage and distribution of IP VPN policies. The corresponding LDAP (Lightweight Directory Access Protocol, [12]) implementations could be built based on the "Policy Core LDAP Schema" ([13]) and "Policy QoS Information Model"([14]) implementations. There is ongoing work in the policy framework WG, which aims at defining the policy extensions for QoS, IPSec (IP Secure, [15]) and MPLS. The IP VPN policy information model references these classes where appropriate. Some of the work in this area is directed at device configuration. The IP VPN policy information however aims at capturing the network requirements for deploying IP VPN networks, whereas the generation of the device configuration information is delegated to policy servers. 3.2 Instantiation of IP VPN Information Model classes The IP VPN provisioning system can instantiate the required classes to capture the network requirements for an IP VPN. The provisioning system needs to use the customer requirements and the physical topology to instantiate the classes with the appropriate values, as depicted in Figure 2. Customer Requirements | | Physical Topology V Information +----------------------------+ --------------> |IP VPN Provisioning System | IP VPN Information +----------------------------+ Model Classes | | V IP VPN Information Model Instances/Network Policies - Figure 2. Instantiation of IP VPN Information Model Classes - 3.3 IP VPN Information Model - Policy components The IP VPN information model consists of a set of IP VPN configuration action classes that are combined together with the Iyer et al. Expires August - 2002 [Page 8] Internet Draft IP VPN February 2002 Policy Information Model rule and condition classes defined in [2] and [3] in order to obtain the IP VPN provisioning rules. These are described in greater detail in the subsequent sections. +-------------+ | PolicyGroup | +-------------+ | |1..n +--------------+ | PolicyRule | +--------------+ | | | | +---------------+ +---------------+ |PolicyCondition| | PolicyAction | +---------------+ +---------------+ | | +--------------+ | | +----------------------------+ |PolicyVariable|-+ +--------------|ipvpnPolicyVFICreationAction| +--------------+ | | +----------------------------+ +-----------+ | | +----------------------------------+ |PolicyValue|----+ +--------|ipvpnPolicyRouteDistributionAction| +-----------+ | +----------------------------------+ | | +---------------------------------------+ | +---|ipvpnPolicyVPNTopologyDescriptionAction| | | +---------------------------------------+ | | +--------------------+ | +----------------------|ipvpnPolicyNATAction| | | +--------------------+ | | +-----------------------------+ | +-------------|ipvpnPolicyTrafficTrunkAction| | | +-----------------------------+ | | +-------------------------+ | +-----------------|ipvpnPolicyFirewallAction| | | +-------------------------+ | | +---------------------------+ | +---------------|ipvpnPolicyEncryptionAction| | +---------------------------+ | | +------------------------------+ +---|ipvpnApplicationSignatureValue| +------------------------------+ - Figure 3. IP VPN information model: policy components - The important classes to be highlighted in the diagram are: Iyer et al. Expires August - 2002 [Page 9] Internet Draft IP VPN February 2002 Policy Information Model - The ipvpnPolicyVFICreationAction specifies the VFI to be created on the edge nodes if the chosen IP VPN implementation is compliant with RFC 2547 [23], - The ipvpnPolicyRouteDistributionAction specifies the connectivity between the edge nodes in the IP VPN and enables to implement the IP VPN as specified in RFC 2547 [23], - The ipvpnPolicyVPNTopologyDescriptionAction provides a description of the IP VPN topology according to the connectivity requirements of the IP VPN service and enables to implement CE-based IP VPNs with IPSec, as described in [24], - The ipvpnPolicyNATAction enables to capture NAT requirements of an IP VPN, - The ipvpnPolicyTrafficTrunkAction aggregates the requirements for the traffic trunks that can be used to transport the IP VPN traffic over the provider network, - The ipvpnPolicyFirewallAction enables to capture Firewall requirements of an IP VPN, - The ipvpnPolicyEncryptionAction enables to capture Encryption requirements of an IP VPN, - The ipvpnApplicationSignatureValue specifies the Layer 4 to Layer 7 characteristics of the packet. This class enables the policies to capture the application layer requirements of the customer with regards to treatment for specific IP traffic, The subsequent sections later on in this document provide details on the various classes referenced. The details will include the inheritance hierarchy and description of the purpose and attributes of these classes. The policy components make references to physical topology components, which are defined as part of the complete set of topology components in the following section. 3.4 IP VPN Information Model - Topology components The topology information model seizes the network status from a dual standpoint: the physical and the virtual one. Physical topology classes represent the physical structure of the network that supports the IP VPN service offering. The IP VPN policy information model uses them in order to identify policy targets for the IP VPN deployment. The end result of such deployment is the creation of a virtual topology. This latter is captured by the virtual topology classes. Iyer et al. Expires August - 2002 [Page 10] Internet Draft IP VPN February 2002 Policy Information Model This model assumes that the IP VPN is provisioned over a provider network as depicted in [16], and according to the "CPE- based"/"Network-based" taxonomy. This is summarized by the following reference models (Figure 4): Network-based : CPE-based : +---------+ +------------ : ------------+ +---------+ | | | : | | | | | | : | | | | +------+ +-----+ : +-----+ +------+ +------+ +----+ | EN | | C N | : | C N | | CN | | EN | | CE |---:--| |========== : =======================| | +----+ | (PE) | | (P) | : | (P) | | (PE) | | (CE) | | +------+ +-----+ : +-----+ +------+ +------+ | | | : | | | +---------+ +------------ : ------------+ +---------+ : | Access | | Provider | | Provider | | Access | | network | | network | | network | | network | - Figure 4. Reference models for IP VPN - The IP VPN policy information model supports both network-based and CPE-based types of IP VPN networks. In order to have a single model for both types, we adopt the following generalization: as far as IP VPNs are concerned, devices can be divided into IP VPN-aware nodes and IP VPN-unaware nodes. The former are grouped as "edge nodes", while the latter are grouped as "core nodes", irrespective of where devices physically reside (be they located at a provider network border, or at customer premises). Iyer et al. Expires August - 2002 [Page 11] Internet Draft IP VPN February 2002 Policy Information Model 3.4.1 Physical Topology Components The physical topology components are used to capture the physical topology of the network, as showed by the following figure 5. (a) 1 +-----------+ 1 (b) +------------| Partition |-----------+ | +-----------+ | | | | | | 2..* 0..* | +---------------+ 1 +---------------+ | Edge Node |o-------+ | Core Node | +---------------+ | +---------------+ 1 o | o 1 | (d)| | |(C) | (e)| 1..* | | | 2..* +-------------------+ | +-------------------+ +----| Access End Point | +--| Core End Point |---+ | 1 +-------------------+ 1..* +-------------------+ 1 | (f)| | 1 1 | |(g) +---------+ +--------+ - Figure 5. Overview of physical topology classes and relationships - In figure 5, relationships are labeled as follows: (a) EdgeNodeInPartition (b) CoreNodeInPartition (c) AccessEndPointInEdgeNode (d) CoreEndPointInEdgeNode (e) CoreEndPointInCoreNode (f) AccessLink (g) CoreLink Network nodes are classified as Core Nodes (P or PE) and Edge Nodes (PE or CE). Edge Nodes provide IP VPN connectivity to customers by means of one or more AccessEndPoints. The set of AccessEndPoints represent the set of interfaces toward IP VPN customers; interfaces can be either virtual or physical. Note that the term "interface" does not refer to physical adapters. Edge Nodes are also associated to a second set of interfaces, called Core End Points, which represent the attachment points to the core network (note that "core" is defined with respect to the IP VPN service). On the contrary, Core Nodes are associated to core interfaces only (see the aggregation labeled as (e) in Figure 5). Core interfaces are represented by instances of the Core End Point class. Core Iyer et al. Expires August - 2002 [Page 12] Internet Draft IP VPN February 2002 Policy Information Model interfaces are interconnected by Core Links, which represent the transmission resources that interconnect routers. These physical topology classes are referenced by the different policy action classes defined in this information model. These classes are described in further detail in subsequent sections under topology class definitions. 3.4.2 Virtual Topology Components The configuration generated as a result of the enforcement of IP VPN policies will result in a virtual topology, which can be modeled using the classes and relationships described in this section. Figure 6 depicts the class diagram of virtual topology entities. +--------+ | IP VPN | +--------+ 0..* o | |(h) 2..* | (c) +-----------+ (i) +--------o| Edge Node |o---------+ | 1 +-----------+ 1 | | o 1 | | | | 1..* | | | 0..* +------------------+ | +-------------------+ +----| Access End Point | | | Virtual End Point |---+ | 1 +------------------+ | +-------------------+ 1 | | 1 | 1..* | (l)| | 1..* | 1 |(m) +---------+ |(n) | (o)| +--------+ (f) | | | 1 | | 0..* | 1 +-----------------------------+ | Virtual Forwarding Instance | +-----------------------------+ - Figure 6. Overview of virtual topology classes and relationships - In figure 6, relationships are labeled as follows: (h) EdgeProviderNodeInIPVPN (i) VirtualEndPointInEdgeProviderNode (l) VFIInEdgeProviderNode (m) VirtualLink (n) AccessEndPointInVFI (o) VirtualEndPointInVFI An IP VPN is identified as a set of Edge Nodes (EN) that participate in the interconnection of IP VPN sites. As far as the IP VPN service is concerned, the role of an EN is to forward IP VPN traffic from Iyer et al. Expires August - 2002 [Page 13] Internet Draft IP VPN February 2002 Policy Information Model access links to the correct paths and vice-versa. A Virtual Forwarding Instance can be defined to accomplish this task, if the chosen implementation of IP VPN is compliant with [23]. Hence, VFI works on Access and Virtual End Points. 4 Inheritance Hierarchy The inheritance hierarchy shows the various classes used to define the IP VPN policy information model. This information model is policy-driven so we start with the classes derived from the policy base class. 4.1 Inheritance hierarchy for policy classes Policy | +----PolicyGroup[PCIM] | | | +-------PolicyGroup[PCIMe] | +----PolicyRule[PCIM] | | | +-------PolicyRule[PCIMe] | +----PolicyConditionInPolicyRule[PCIM] | +----PolicyCondition[PCIM] | | | +-------PolicyTimePeriodCondition[PCIM] | | | +-------VendorPolicyCondition[PCIM] | | | +-------PolicySimpleCondition[PCIMe] | | | +-------PolicyCompoundCondition[PCIMe] | +----qoSPolicyTokenBucketTrfcProf[QPIM] | +----PolicyVariable[PCIMe] | +----PolicyValue[PCIMe] | | | +-------PolicyIPv4AddrValue[PCIMe] | | | +-------PolicyIPv6AddrValue[PCIMe] | | | +-------ipvpnApplicationSignatureValue[this document] | +----PolicyActionInPolicyRule[PCIM] | Iyer et al. Expires August - 2002 [Page 14] Internet Draft IP VPN February 2002 Policy Information Model +----PolicyAction[PCIM] | +-------VendorPolicyAction[PCIM] | +-------ipvpnPolicyVFICreationAction[this document] | +-------ipvpnPolicyRouteDistributionAction[this document] | +-------ipvpnPolicyVPNTopologyDescriptionAction[this document] | +-------ipvpnPolicyNATAction[this document] | +-------ipvpnPolicyTrafficTrunkAction[this document] | +-------ipvpnPolicyFirewallAction[this document] | +-------ipvpnPolicyEncryptionAction[this document] | +-------qoSPolicyPRAction[QPIM] | +-------qoSPolicyRSVPAction[QPIM] | +-------qoSPolicyRSVPAdmissionAction[QPIM] - Figure 7. Inheritance hierarchy for policy components - The detailed descriptions of the classes mentioned Figure 7 are provided in section 5. The new classes introduced in this draft are: - The ipvpnPolicyVFICreationAction specifies the VFI to be created on the edge nodes if the chosen IP VPN implementation is compliant with RFC 2547 [23], - The ipvpnPolicyRouteDistributionAction specifies the connectivity between the edge nodes in the IP VPN and enables to implement the IP VPN as specified in RFC 2547 [23], - The ipvpnPolicyVPNTopologyDescriptionAction provides a description of the IP VPN topology according to the connectivity requirements of the IP VPN service and enables to implement CE-based IP VPNs with IPSec, as described in [24], - The ipvpnPolicyNATAction enables to capture NAT requirements of an IP VPN, - The ipvpnPolicyTrafficTrunkAction aggregates the requirements for the traffic trunks that can be used to transport the IP VPN traffic over the provider network, Iyer et al. Expires August - 2002 [Page 15] Internet Draft IP VPN February 2002 Policy Information Model - The ipvpnPolicyFirewallAction enables to capture Firewall requirements of an IP VPN, - The ipvpnPolicyEncryptionAction enables to capture Encryption requirements of an IP VPN, - The ipvpnApplicationSignatureValue specifies the Layer 4 to Layer 7 characteristics of the packet. This class enables the policies to capture the application layer requirements of the customer with regards to treatment for specific IP traffic. 4.2 Inheritance tree for topology classes Classes related to the topology model are shown below. They are derived from the classes mentioned in [17]. ManagedSystemElement [17] | +----LogicalElement [17] | | | +----System [17] | | | | | +----ComputerSystem [17] | | | | | +----Node [this document] | | | | | +----CoreNode [this document] | | | | | +----EdgeNode [this document] | | | +----ServiceAccessPoint [17] | | | | | +----ProtocolEndPoint [17] | | | | | +----AccessEndPoint [this document] | | | | | +----CoreEndPoint [this document] | | | | | +----VirtualEndPoint [this document] | | | +----Service [17] | | | +----NetworkService [17] | | | +----VirtualForwardingInstance [this document] | +----Collection [17] | +----CollectionOfMSEs [17] | +----LogicalNetwork [17] | Iyer et al. Expires August - 2002 [Page 16] Internet Draft IP VPN February 2002 Policy Information Model +----Partition [this document] | +----IP VPN [this document] - Figure 8. Class inheritance for topology components - The following inheritance hierarchy shows the various classes used to define relationships between topology classes. [unrooted] | +----Dependency [17] | | | +----Link [this document] | | | | | +----VirtualLink [this document] | | | | | +----CoreLink [this document] | | | | | +----AccessLink [this document] | | | +----NodeInPartition [this document] | | | | | +----EdgeNodeInPartition [this document] | | | | | +----CoreNodeInPartition [this document] | | | +----AccessEndPointInVFI [this document] | | | +----VirtualEndPointInVFI [this document] | +----Component [17] | +----ProtocolEndPointInNode [this document] | | | +----AccessEndPointInEdgeNode [this document] | | | +----CoreEndPointInEdgeNode [this document] | | | +----CoreEndPointInCoreNode [this document] | | | +----VirtualEndPointInEdgeNode [this document] | +----VFIInEdgeNode [this document] | +----EdgeNodeInIPVPN [this document] - Figure 9. Association inheritance for topology components - The detailed description of the classes mentioned in Figure 8 and Figure 9 is provided in section 6. Iyer et al. Expires August - 2002 [Page 17] Internet Draft IP VPN February 2002 Policy Information Model 5 Policy Class Definitions 5.1 The class ipvpnPolicyVFICreationAction This class specifies the VFI to be created in order to implement a RFC2547-like IP VPN [23]. NAME ipvpnPolicyVFICreationAction DESCRIPTION The class for specifying the VFI to be created. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES AttachedInterface[ref AccessEndPoint [1..n]] 5.1.1 The reference AttachedInterface This is a reference to one or several objects of class AccessEndPoint. 5.2 The class ipvpnPolicyRouteDistributionAction This action represents the routes distribution process of an IP VPN routing tables, that is implemented by means of RouteTarget and results in the definition of Routes with/without RouteDistinguisher. This action is intended to be used to implement RFC2547-like IP VPNs [23]. NAME ipvpnPolicyRouteDistributionAction DESCRIPTION The class for representing the routes distribution actions. The distribution actions should support point-to-point, hub and spoke, full mesh and partial mesh topology requirements. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES DistributionSource[ref AccessEndPoint [1]] DistributionDestination[ref AccessEndPoint [1]] DistributionMandatoryHops[ref AccessEndPoint [0..n]] 5.2.1 The reference DistributionSource This is a reference to an object of class AccessEndPoint. 5.2.2 The reference DistributionDestination This is a reference to an object of class AccessEndPoint. 5.2.3 The reference DistributionMandatoryHops This is a reference to zero or more objects, which points to mandatory hops to be used for the traffic flowing from the Iyer et al. Expires August - 2002 [Page 18] Internet Draft IP VPN February 2002 Policy Information Model DistributionSource to the DistributionDestination. The objects referenced are instances of the class AccessEndPoint. 5.3 The class ipvpnPolicyVPNTopologyDescriptionAction This class specifies the IP VPN service topology and reachability, and is intended to be used for configuring an IP VPN database for implementing IP VPNs as specified in [24]. NAME ipvpnPolicyVPNTopologyDescriptionAction DESCRIPTION The class for representing the topology and reachability description actions. The actions should support point-to-point, hub and spoke, full mesh and partial mesh topology requirements. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES RoutingSource[ref AccessEndPoint[1]] RoutingDestination[ref AccessEndPoint[1]] RoutingMandatoryHops[ref EdgeNode[2..n]] 5.3.1 The reference RoutingSource This is a reference to an object of type AccessEndPoint. 5.3.2 The reference RoutingDestination This is a reference to an object of type AccessEndPoint. 5.3.3 The reference RoutingMandatoryHops This is a reference to zero or more objects, which points to mandatory hops to be used for the traffic flowing from the ipvpnPolicyRoutingSource to the ipvpnPolicyRoutingDestination The objects referenced are instance(s) of EdgeNode. 5.4 The class ipvpnPolicyNATAction This class specifies which source addresses need to be translated and what should be the results of this translation. NAME ipvpnPolicyNATAction DESCRIPTION The class that represents the network address translation action of the "If Condition then Action" semantics associated with a policy rule. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES TranslateFromIPv4Address TranslateToIPv4Address Iyer et al. Expires August - 2002 [Page 19] Internet Draft IP VPN February 2002 Policy Information Model 5.4.1 The property TranslateFromIPv4Address Specifies the original set of IPv4 addresses that needs to be translated. NAME TranslateFromIPv4Address DESCRIPTION The original IPv4 address that needs to be translated. SYNTAX PolicyIPv4AddrValue 5.4.2 The property TranslateToIPv4Address Specifies the final set of IPv4 addresses that needs to be translated to. NAME TranslateToIPv4Address DESCRIPTION The final IPv4 address that needs to be translated to. SYNTAX PolicyIPv4AddrValue 5.5 The class ipvpnPolicyTrafficTrunkAction This class indicates the requirements on the traffic trunk to be used to transport the IP VPN traffic. NAME ipvpnPolicyTrafficTrunkAction DESCRIPTION The class for representing the requirements of the traffic trunk to be used to transport the VPN traffic DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Ingress[ref EdgeNode] Egress[ref EdgeNode] Priority[Integer] Preemption[Integer (1-4)] Resilience[boolean] TrafficProfile[QosPolicyTokenBucketTrfcProf] 5.5.1 The reference Ingress This attribute references the Edge Node, which will be the ingress node for the trunk. 5.5.2 The reference Egress This attribute references the Edge Node, which will be the egress node for the trunk. 5.5.3 The property Priority This attribute indicates the priority requirement for the trunk. Iyer et al. Expires August - 2002 [Page 20] Internet Draft IP VPN February 2002 Policy Information Model NAME Priority DESCRIPTION The priority requirement for the trunk. SYNTAX Integer 5.5.4 The property Preemption This attribute indicates the preemption requirement for the trunk. The preemption is related to whether the trunk can be preempted to accommodate a new higher priority trunk. NAME Preemption DESCRIPTION The preemption requirement for the trunk. SYNTAX Integer(1-4) 5.5.5 The property Resilience This attribute indicates the resilience requirement for the trunk. NAME Resilience DESCRIPTION The resilience requirement for the trunk. SYNTAX boolean 5.5.6 The property TrafficProfile This attribute indicates the traffic profile requirement for the trunk. NAME TrafficProfile DESCRIPTION The Traffic Profile requirement for the trunk. SYNTAX QoSPolicyTokenBucketTrfcProf 5.6 The class ipvpnPolicyFirewallAction Specifies the firewall action to be enforced such as "drop", "pass", "log", "alert", etc. The list of possible actions is limited by the attributes in the action object. NAME ipvpnPolicyFirewallAction DESCRIPTION The class for representing the firewall action of the "If Condition then Action" semantics associated with a policy rule. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Action 5.6.1 The property Action The action defines the type of firewall action to be enforced. NAME Action DESCRIPTION The firewall action to be enforced SYNTAX INTEGER Iyer et al. Expires August - 2002 [Page 21] Internet Draft IP VPN February 2002 Policy Information Model VALUES The action can take the following values 0 = Allow 1 = Allow & Log 2 = Allow and Alarm 3 = Deny 4 = Deny & Log 5 = Deny and Alarm 5.7 The class ipvpnEncryptionAction The encryption standard is assumed to be IPSec. This class provides the IPSec parameters that will be used to set up the security association required to handle the encryption and decryption of packets. NAME ipvpnEncryptionAction DESCRIPTION The class for representing the encryption action of the "If Condition then Action" semantics associated with a policy rule. DERIVED FROM PolicyAction ABSTRACT TRUE PROPERTIES IkeAuthentication IkeEncryption IkeDHGroup IkeTimeout IkeTrafficBasedExpiry IpsecAuthentication IpsecEncryption IpsecDHGroup IpsecTimeout IpsecTrafficBasedExpiry IkePeerAuthenticationMethod 5.7.1 The property IkeAuthentication The property specifies the authentication algorithm to be used. The IkeAuthentication parameters can be used to generate the corresponding ISAKMP (I S A Key Management Protocol) parameters in cases where ISAKMP is still being used. This draft does not describe a separate set of parameters for ISAKMP. It is left to the policy servers generating the configuration to handle the corresponding translation. NAME IkeAuthentication DESCRIPTION The property that specifies the authentication algorithm. SYNTAX String 5.7.2 The property IkeEncryption The property specifies the encryption algorithm to be used. Iyer et al. Expires August - 2002 [Page 22] Internet Draft IP VPN February 2002 Policy Information Model NAME IkeEncryption DESCRIPTION The property that specifies the encryption algorithm. SYNTAX String 5.7.3 The property IkeDHGroup The property specifies the DHGroup to be used during IKE negotiations NAME IkeDHGroup DESCRIPTION The property that specifies the DHGroup to be used during IKE negotiations. SYNTAX String 5.7.4 The property IkeTimeout The property specifies the IKE Timeout to be used. NAME IkeTimeout DESCRIPTION The property that specifies the IKE timeout. SYNTAX Integer 5.7.5 The property IkeTrafficBasedExpiry The property specifies the IKE Traffic based expiry to be used. NAME IkeTrafficBasedExpiry DESCRIPTION The property that specifies the IKE traffic based expiry to be used. SYNTAX Integer 5.7.6 The property IPSECAuthentication The property specifies the authentication algorithm to be used. NAME IPSECAuthentication DESCRIPTION The property that specifies the authentication algorithm. SYNTAX String 5.7.7 The property IPSECEncryption The property specifies the encryption algorithm to be used. NAME IPSECEncryption DESCRIPTION The property that specifies the encryption algorithm. SYNTAX String 5.7.8 The property IPSECDHGroup Iyer et al. Expires August - 2002 [Page 23] Internet Draft IP VPN February 2002 Policy Information Model The property specifies the DHGroup to be used during IPSec negotiations. NAME IPSECDHGroup DESCRIPTION The property that specifies the DHGroup to be used during the IKE Phase II negotiations. SYNTAX String 5.7.9 The property IPSECTimeout The property specifies the IPSEC Key Timeout to be used. NAME IPSECTimeout DESCRIPTION The property that specifies the IPSEC Key timeout. SYNTAX Integer 5.7.10 The property IPSECTrafficBasedExpiry The property specifies the IPSEC Traffic based Key expiry to be used. NAME IPSECTrafficBasedExpiry DESCRIPTION The property that specifies the IPSec traffic based Key expiry to be used. SYNTAX Integer 5.7.11 The property IkePeerAuthenticationMethod The IKE peers are the IKE processes that are at the two ends of a control channel related to encryption of traffic at the data layer. The method used by the IKE [Internet Key Exchange, [19]) peers to authenticate each other. The IKE peers are running on the IP VPN nodes. NAME IkePeerAuthenticationMethod DESCRIPTION The property that specifies the method used by the IKE peers to authenticate each other. SYNTAX unsigned 16-bit integer VALUE The possible values are listed below. 0 = ProposalList is to be used(see below) 1 = Pre-shared key 2 = DSS (D S S) signatures 3 = RSA (R S A) signatures 4 = Encryption with RSA 5 = Revised encryption with RSA 6 = Kerberos (has this number been assigned???) A value of 0 is a special value that indicates that this particular proposal should be repeated once for each authentication method that corresponds to the credentials installed on the machine. For example, if the system has Iyer et al. Expires August - 2002 [Page 24] Internet Draft IP VPN February 2002 Policy Information Model a pre-shared key and a certificate, a proposal list could be constructed which includes a proposal that specifies pre-shared key and proposals for any of the public-key authentication methods. DSS and RSA are encryption algorithms which are explained in several encryption specific books such as "Applied Cryptography". 5.8 The Class ipvpnApplicationSignatureValue Specifies the Layer 4 to Layer 7 characteristics of the packet including application level decodes which require stateful inspection of the packet e.g. HTTP, FTP, SMTP, TELNET, etc. This class enables the policies to capture the application layer requirements of the customer with regards to treatment for specific IP traffic. NAME ipvpnApplicationSignatureValue DESCRIPTION The class for representing application signature to be matched against the traffic DERIVED FROM qoSPolicyValue ABSTRACT FALSE PROPERTIES applicationSignature This class can have several subclasses, which reflect the application protocol classification granularity. 5.8.1 The Property applicationSignature NAME applicationSignature DESCRIPTION The property that provides a signature used to identify the application by examining the payload of the PDU (Protocol Data Unit). SYNTAX String 6 Topology Class Definitions 6.1 The Abstract Class "Node" The abstract class Node is a representation of a generic network node. The class definition is as follows: NAME Node DESCRIPTION An abstract class representing a network node entity. DERIVED FROM ComputerSystem ABSTRACT TRUE PROPERTIES PEPID Iyer et al. Expires August - 2002 [Page 25] Internet Draft IP VPN February 2002 Policy Information Model The PEPID single-valued property corresponds to the node identifier. It is a globally unique identifier. The property definition is as follows: NAME PEPID DESCRIPTION A user-friendly name (e.g. DNS name or primary IP public address) of a node object. SYNTAX string 6.2 The Class "CoreNode" The class CoreNode is a representation of a router residing at the network core (with respect to the IP VPN service). The class definition is as follows: NAME CoreNode DESCRIPTION A class representing a network core router. DERIVED FROM Node ABSTRACT FALSE PROPERTIES NONE 6.3 The Class "EdgeNode" The class EdgeNode is a representation of a router residing at the network edge (with respect to the IP VPN service). The class definition is as follows: NAME EdgeNode DESCRIPTION A class representing a network edge router. DERIVED FROM Node ABSTRACT FALSE PROPERTIES NONE 6.4 The Class "LogicalNetwork" The class LogicalNetwork is defined by [17]. It is reported here for convenience. A LogicalNetwork groups together a set of ProtocolEndpoints of a given type that are able to communicate with each other directly. A LogicalNetwork represents the ability to send and/or receive data over a network. The class definition is as follows: NAME LogicalNetwork DESCRIPTION An class representing a logical network. DERIVED FROM CollectionOfMSEs ABSTRACT FALSE PROPERTIES NetworkType The NetworkType single-valued property provides additional information that can be used to help categorize and classify different instances of this class. The property takes values from an Iyer et al. Expires August - 2002 [Page 26] Internet Draft IP VPN February 2002 Policy Information Model enumeration. Some possible values are "Unknown", "Other", "IPv4", "IPv6", "IPX", etc. The property definition is as follows: NAME NetworkType DESCRIPTION Specify the network type. SYNTAX string 6.5 The Class "Partition" The provider network is partitioned into domains called "partitions". A Partition is an administrative entity. The class definition is as follows: NAME Partition DESCRIPTION An class representing a (logical) partition. DERIVED FROM LogicalNetwork ABSTRACT FALSE PROPERTIES PartitionID The PartitionID single-valued property corresponds to the partition identifier. It is unique within the scope of a provider domain. The property definition is as follows: NAME PartitionID DESCRIPTION A user-friendly name of a partition object. SYNTAX string 6.6 The Class "IP VPN" The class IP VPN represents an IP Virtual Private Network deployed within the provider network. The class definition is as follows: NAME IP VPN DESCRIPTION An class representing an IP VPN. DERIVED FROM LogicalNetwork ABSTRACT FALSE PROPERTIES VPNID The VPNID single-valued property corresponds to the globally unique VPN identifier as defined by IETF [20]. The property definition is as follows: NAME VPNID DESCRIPTION The standard VPNID. SYNTAX octet[7] 6.7 The Class "ProtocolEndPoint" The class ProtocolEndpoint is defined by [17]. It is reported here for convenience. The class represents a communication point from which data may be sent or received. ProtocolEndpoints link router interfaces and switch ports to LogicalNetworks. The class definition is as follows: Iyer et al. Expires August - 2002 [Page 27] Internet Draft IP VPN February 2002 Policy Information Model NAME ProtocolEndPoint DESCRIPTION A communication point. DERIVED FROM ServiceAccessPoint ABSTRACT FALSE PROPERTIES ProtocolType The ProtocolType single-valued property provides additional information that can be used to help categorize and classify different instances of this class. The property takes values from an enumeration. Some possible values are "Unknown", "Other", "IPv4", "IPv6", "IPX", etc. The property definition is as follows: NAME ProtocolType DESCRIPTION Specify the protocol of end point. SYNTAX string 6.8 The Class "AccessEndPoint" The class AccessEndPoint represents an access IP interface. The class definition is as follows: NAME AccessEndPoint DESCRIPTION A class representing an access interface. DERIVED FROM ProtocolEndPoint ABSTRACT FALSE PROPERTIES NONE 6.9 The Class "CoreEndPoint" The class CoreEndPoint represents a core IP interface. The class definition is as follows: NAME CoreEndPoint DESCRIPTION A class representing a core interface. DERIVED FROM ProtocolEndPoint ABSTRACT FALSE PROPERTIES IPAddress 6.10 The Class "VirtualEndPoint" The class VirtualEndPoint represents a virtual interface (e.g. a tunnel end point). The class definition is as follows: NAME VirtualEndPoint DESCRIPTION A class representing a virtual interface. DERIVED FROM ProtocolEndPoint ABSTRACT FALSE PROPERTIES NONE 6.11 The Abstract Class "NetworkService" Iyer et al. Expires August - 2002 [Page 28] Internet Draft IP VPN February 2002 Policy Information Model The class NetworkService is defined by [17]. It is reported here for convenience. This is an abstract base class. It serves as the root of the network hierarchy. Network services represent generic functions that are available from the network that configure and/or modify the traffic being sent. The class definition is as follows: NAME NetworkService DESCRIPTION A class representing a base network service. DERIVED FROM Service ABSTRACT TRUE PROPERTIES NONE //string StartupConditions [ ] //string StartupParameters [ ] 6.12 The Class "VirtualForwardingInstance" This class represents a VFI. A VFI is a dedicated forwarding process that runs on a border router (i.e. a PE or a CE). VFI forwards customer traffic of a given IP VPN to the virtual links and vice- versa. Hence a VFI is associated to a subset of the access interfaces and virtual interfaces of a border node. The class definition is as follows: NAME VirtualForwardingInstance DESCRIPTION An class representing a VFI. DERIVED FROM NetworkService ABSTRACT FALSE PROPERTIES VPNID The VPNID property is similar to the one defined in section 6.6. The following sections contain the definition of relationships belonging to the topology model. 6.13 The Abstract Association "Link" This abstract association is used to represent a bi-directional link. The class definition for the association is as follows: NAME Link DESCRIPTION A generic association used to establish a one- to-one bi-directional relationship between the subclasses of ProtocolEndPoint. DERIVED FROM Dependency ABSTRACT TRUE PROPERTIES Antecedent[ref ProtocolEndPoint[1..1]] Dependent[ref ProtocolEndPoint [1..1]] This abstract association inherits two object references from a higher-level CIM association class, Dependency. It overrides these object references to make them references to instances of the class ProtocolEndPoint. Subclasses of Link then override these object Iyer et al. Expires August - 2002 [Page 29] Internet Draft IP VPN February 2002 Policy Information Model references again, to make them references to concrete "interface" classes. Note that the semantic of Dependent and Antecedent properties are changed. These properties just represent a pair of unordered association ends. The [1..1] cardinality indicates that a pair of ProtocolEndpoints can be connected by exactly one Link. 6.14 The Association "CoreLink" This association is used to represent a direct reachability between two core interfaces. Interfaces can belong to either ENs or CNs. The class definition for the association is as follows: NAME CoreLink DESCRIPTION A logical representation of a one-hop reachability between two nodes. DERIVED FROM Link ABSTRACT FALSE PROPERTIES Antecedent[ref CoreEndPoint[1..1]] Dependent[ref CoreEndPoint[1..1]] This association is a concrete class and can be instantiated. It inherits two object references from the Link class and overrides these object references to make them references to instances of the class CoreEndPoint. 6.15 The Association "AccessLink" This association is used to represent a direct reachability between two access interfaces. The class definition for the association is as follows: NAME AccessLink DESCRIPTION A logical representation of a one-hop reachability between a border node and a customer node. DERIVED FROM Link ABSTRACT FALSE PROPERTIES Antecedent[ref AccessEndPoint[1..1]] Dependent[ref AccessEndPoint[1..1]] This association is a concrete class. It inherits two object references from the Link class and overrides these object references to make them references to instances of the class AccessEndPoint. 6.16 The Association "VirtualLink" This association is used to represent a virtual one-hop reachability (e.g. a tunnel or a MPLS LSP) between two virtual interfaces. The class definition for the association is as follows: NAME VirtualLink Iyer et al. Expires August - 2002 [Page 30] Internet Draft IP VPN February 2002 Policy Information Model DESCRIPTION A logical representation of a virtual connection traversing the core network. DERIVED FROM Link ABSTRACT FALSE PROPERTIES Antecedent[ref VirtualEndPoint[1..1]] Dependent[ref VirtualEndPoint[1..1]] This association inherits two object references from the Link class. It overrides these object references to make them references to instances of the class VirtualEndPoint. 6.17 The Abstract Association "NodeInPartition" The class definition for the association is as follows: NAME NodeInPartition DESCRIPTION A generic association used to establish a relationship between a generic node and its pertaining partition. DERIVED FROM Dependency ABSTRACT TRUE PROPERTIES Antecedent[ref Node[0..*]] Dependent[ref Partition[1..1]] This abstract association inherits two object references from a higher-level CIM association class, Dependency. It overrides these object references to make them references to instances of the class Node and Partition. Subclasses of NodeInPartition then override the antecedent references again, to make them references to concrete subclasses of Node. 6.18 The Association "EdgeNodeInPartition" The class definition for the association is as follows: NAME EdgeNodeInPartition DESCRIPTION The association represents the relationship between an EdgeNode and its pertaining Partition. DERIVED FROM NodeInPartition ABSTRACT FALSE PROPERTIES Antecedent[ref EdgeNode[2..*]] 6.19 The Association "CoreNodeInPartition" The class definition for the association is as follows: NAME CoreNodeInPartition DESCRIPTION The association represents the relationship between a CoreNode and its pertaining Partition. DERIVED FROM NodeInPartition ABSTRACT FALSE Iyer et al. Expires August - 2002 [Page 31] Internet Draft IP VPN February 2002 Policy Information Model PROPERTIES Antecedent[ref CoreNode [0..*]] 6.20 The Association "AccessEndPointInVFI" The class definition for the association is as follows: NAME AccessEndPointInVFI DESCRIPTION An association used to establish a relationship between a VFI and the access interfaces it serves. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref AccessEndPoint[1..*]] Dependent[ref VirtualForwardingInstance[1..1]] This association inherits two object references from a higher-level CIM association class, Dependency. It overrides these object references to make them references to instances of the classes AccessEndPoint and VirtualForwardingInstance. 6.21 The Association "VirtualEndPointInVFI" The class definition for the association is as follows: NAME VirtualEndPointInVFI DESCRIPTION A generic association used to establish a relationship a VFI and the virtual interfaces it works on. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref VirtualEndPoint[1..*]] Dependent[ref VirtualForwardingInstance[1..1]] This association inherits two object references from a higher-level CIM association class, Dependency. It overrides these object references to make them references to instances of the classes VirtualEndPoint and VirtualForwardingInstance. 6.22 The Abstract Aggregation "ProtocolEndPointInNode" This abstract aggregation defines two object references that will be overridden in each of five subclasses, to become references to the subclasses of Node and ProtocolEndPoint. From a general viewpoint, this aggregation express what interfaces (physical or virtual) belong to a given node. The class definition for the aggregation is as follows: NAME ProtocolEndPointInNode DESCRIPTION A generic association used to establish a relationship between a generic node and its interfaces. DERIVED FROM Component ABSTRACT TRUE Iyer et al. Expires August - 2002 [Page 32] Internet Draft IP VPN February 2002 Policy Information Model PROPERTIES GroupComponent [ref Node[0..*]] PartComponent [ref ProtocolEndPoint[0..*]] 6.23 The Aggregation "AccessEndPointInEdgeNode" The AccessEndPointInEdgeNode aggregation enables access interfaces to be assigned to a given EN. The class definition for the aggregation is as follows: NAME AccessEndPointInEdgeNode DESCRIPTION A class representing the aggregation of access interfaces by ENs. DERIVED FROM ProtocolEndPointInNode ABSTRACT FALSE PROPERTIES GroupComponent [ref EdgeNode[1..1]] PartComponent [ref AccessEndPoint[1..*]] 6.24 The Aggregation "CoreEndPointInEdgeNode" The CoreEndPointInEdgeNode aggregation enables core interfaces to be assigned to a given EN. The class definition for the aggregation is as follows: NAME CoreEndPointInEdgeNode DESCRIPTION A class representing the aggregation of core interfaces by ENs. DERIVED FROM ProtocolEndPointInNode ABSTRACT FALSE PROPERTIES GroupComponent [ref EdgeNode[1..1]] PartComponent [ref CoreEndPoint[1..*]] 6.25 The Aggregation "CoreEndPointInCoreNode" The CoreEndPointInCoreNode aggregation enables core interfaces to be assigned to a given core router. The class definition for the aggregation is as follows: NAME CoreEndPointInCoreNode DESCRIPTION A class representing the aggregation of core interfaces by CNs. DERIVED FROM ProtocolEndPointInNode ABSTRACT FALSE PROPERTIES GroupComponent [ref CoreNode[1..1]] PartComponent [ref CoreEndPoint[2..*]] 6.26 The Aggregation "VirtualEndPointInEdgeNode" The VirtualEndPointInEdgeNode aggregation enables virtual interfaces to be assigned to a given EN. The class definition for the aggregation is as follows: NAME VirtualEndPointInEdgeNode Iyer et al. Expires August - 2002 [Page 33] Internet Draft IP VPN February 2002 Policy Information Model DESCRIPTION A class representing the aggregation of virtual interfaces by PEs. DERIVED FROM ProtocolEndPointInNode ABSTRACT FALSE PROPERTIES GroupComponent [ref EdgeNode[1..1]] PartComponent [ref VirtualEndPoint[0..*]] 6.27 The Aggregation "VFIInEdgeNode" Each VFI works in an EN. This class associates VFIs to corresponding border routers. The class definition for the aggregation is as follows: NAME VFIInEdgeNode DESCRIPTION Aggregation between a VFI and an EN. DERIVED FROM Component ABSTRACT FALSE PROPERTIES GroupComponent [ref EdgeNode [1..1]] PartComponent [ref VirtualForwardingInstance[0..*]] 6.28 The Aggregation "EdgeNodeInIPVPN" This association identifies which border routers are serving an IP VPN. The class definition for the aggregation is as follows: NAME EdgeNodeInIPVPN DESCRIPTION Aggregation between an EN and an IP VPN. DERIVED FROM Component ABSTRACT FALSE PROPERTIES GroupComponent [ref IP VPN[1..1]] PartComponent [ref EdgeNode[2..*]] 7 Generation of device configuration information and IP VPN topology The physical topology reflects the physical layout of the devices and their interfaces. They are referenced by the policy action classes defined in this model. The role of the policy server in the policy management framework is explained in detail in [22]. The policy servers use this information to generate the device configuration information. The device configuration information will be used by the IP VPN routers to actually deploy and maintain a (set of )IP VPN networks. The topology of an IP VPN is an implicit result of the (device) configuration information, i.e. the topology is displayed/described once the devices have been configured accordingly, in terms of architecture, QoS, security and management, as per a "global" IP VPN deployment policy. Iyer et al. Expires August - 2002 [Page 34] Internet Draft IP VPN February 2002 Policy Information Model The individual routers involved in forwarding the IP VPN traffic and virtual links generated by the configuration represent the IP VPN topology. The physical topology components have been discussed in earlier sections. This section provides an insight into the overall view of the provider network and the generation of the IP VPN topology. The entire provider network is broken up into partitions based on one or more of the following criteria: 1. Technology boundaries 2. Administrative boundaries 3. Scalability requirements 8 Device Capabilities Model The device capabilities model is used to validate the policies. A policy may indicate that a specific action is to be performed on a given network node. The administrator does the selection of the network node. There is a possibility that the network node does not support the required action. The device capabilities model will enable the provisioning system to ensure that this error is trapped at the time of creation of the policy. The device capabilities model should indicate whether a network node is capable of supporting an action. The list of actions is defined in the draft. The capabilities model can be included in the definition of the node in the topology information model. The capabilities model should allow for the addition of new actions and corresponding new capability attributes. There are capabilities models defined under the CIM[17] for certain functions which relate to the action classes. This section of the draft is to be updated with a detailed capabilities model in future revisions. 9 Reliability and Scalability in the Information Model The IPVPN policy information model captures the network requirements related to a VPN services. The service definition may very well include reliability and scalability information, which translates to additional costs for the provider. This information needs to be translated to policies. The currently defined policy classes need to be enhanced with components related to the reliability and scalability requirements. This section of the draft is to be updated with the reliability and scalability classes and/or attributes in future revisions. Iyer et al. Expires August - 2002 [Page 35] Internet Draft IP VPN February 2002 Policy Information Model 10 Extending the IP VPN policy information model The IP VPN information model is derived from [2]. It extends the classes defined in the [2]. It is a policy application which uses the building blocks provided by the [2]. The IP VPN information model reuses a number of extensions defined in [3]. The policy framework group is currently focused on defining the QoS information model to flush out the constructs before using them in other functional areas. The IP VPN information model is an attempt to satisfy the more immediate requirements of the IP VPN technology vendors keeping in mind the goals of the [3]. This draft will try to track the changes being made to the [3] wherever appropriate. This will ensure a parallel evolution of the IP VPN information model on the lines of PCIMe [3]. The IP VPN information model can be extended to adapt to the changing landscape of technologies and classification criteria. The important areas, which are most likely to see extensions, are listed below. 1. PolicyAction[3] The policy action class will be extended to include new functionality being addressed in the service provider requirements field for IP VPNs. These extensions could extend from the action classes defined in this document if they fit within the action categories identified by the policy actions defined in this document. 2. IpvpnApplicationSignatureValue[this document] The application signature value class could be extended to satisfy requirements of new applications to be supported within IP VPNs, e.g. SLA support for new VOIP (Voice Over IP) application schemes for identifying a network as well as new applications. The Application tag is an abstract class and needs to be extended with protocol specific filters. The IP VPN policy information model describes the IP VPN basic features - namely connectivity, security and QoS. The IP VPN Policy Information model can be extended to support new requirements generated as a result of new functions for the deployment of value- added IP VPN services, like the integration of IP multicast transmission schemes within the IP VPN. Iyer et al. Expires August - 2002 [Page 36] Internet Draft IP VPN February 2002 Policy Information Model 11 Security Considerations The IP VPN policy provisioning data as they are described in this document will be used for configuring the appropriate network elements that will be involved in the dynamic provisioning of IP VPN networks, by means of a secured communication that will convey this information between the policy servers and the above-mentioned network elements. The function of dynamically provisioning network elements with such configuration information implies that only an authorized communication take place. From this perspective, it is recommended that the IPSec ([21]) protocol suite be used to secure the above-mentioned authorized communication. 12 References [1] Bradner S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Moore B. et al., "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [3] Moore B. et al., "Policy Core Information Model Extensions", draft-ietf-policy-pcim-ext-06.txt, Work in Progress, November 2001. [4] Muthukrishnan K., Malis A., "A Core MPLS IP VPN Architecture", RFC 2917, September 2000. [5] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] 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-01.txt, Work in Progress, July 2001. Check http://www.ist-tequila.org for additional information. [7] Mahdavi J., Paxson V., "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [8] Please see the following web page for the latest (1.3 as of this writing) UML specification: http://www.rational.com/uml/resources/documentation/index.jsp [9] Rosen E., et al., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [10] Awduche D. et al., "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [11] Yavatkar R. et al., "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [12] Sermersheim J. et al., "Lightweight Directory Access Protocol (v3)", draft-ietf-ldapbis-protocol-01.txt, Work in Progress, February 2001. Iyer et al. Expires August - 2002 [Page 37] Internet Draft IP VPN February 2002 Policy Information Model [13] Strassner J. et al., "Policy Core LDAP Schema", draft-ietf- policy-core-schema-11.txt, Work in Progress, May 2001. [14] Snir Y. et al., "Policy QoS Information Model÷, draft-ietf- policy-qos-info-model-03.txt, Work in Progress, April 2001. [15] Kent S., Atkinson R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [16] Gleeson B. et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. [17] Distributed Management Task Force, Inc., "DMTF Technologies: CIM Standards CIM Schema: Version 2.5", available via links on the following DMTF web page: http://www.dmtf.org/spec/cim_schema_v25.html. [18] Blake S. et al., "An Architecture for Differentiated Services", RFC 2475, December 1998. [19] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [20] Fox B., Gleeson B., "Virtual Private Networks Identifier", RFC 2685, September 1999. [21] Kent S., Atkinson R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [22] Yavatkar R., Pendarakis D. and Guerin R., "A Framework for Policy-based Admission Control", RFC 2753, January 2000 [23] Rosen E.C., "BGP/MPLS VPNs", draft-ietf-ppvpn-rfc2547bis-00, Work In Progress, July 2001. [24] De Clercq J., "A Framework for Provider Provisioned CE-based Virtual Private Network using IPSec", draft-ietf-ppvpn-ce- based-01.txt, November 2001, Work in progress. 13 Authors' Addresses Mahadevan Iyer Alcatel Inc 595 Yosemite Blvd, Milpitas, CA Phone: 408 586 7687 E-Mail: mahadevan.iyer@ind.alcatel.com Arnaud Gonguet Alcatel Research & Innovation Route de Nozay F-91461 Marcoussis - France Phone : +33 (0)1 69 63 42 17 E-Mail: Arnaud.Gonguet@alcatel.fr 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 Iyer et al. Expires August - 2002 [Page 38] Internet Draft IP VPN February 2002 Policy Information Model E-Mail: christian.jacquenet@francetelecom.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 or assist in 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. Expires August - 2002 [Page 39]