PPVPN M. Iyer Internet Draft Alcatel Document: draft-iyer-ipvpn-infomodel-01.txt C. Jacquenet Category: Informational France Telecom R & D Expires January 2001 P.Lago Politecnico di Torino R.Scandariato Politecnico di Torino July 2001 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 specifies the object oriented information model for representing policy information associated with the provisioning of IP VPN services, and this may 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 ([2]) and the extensions to the core policy information model([3])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 the kind of IP VPN technology ([4]) that may be used to deploy the corresponding service offering. Iyer et al. Informational - Expires December 2001 [Page 1] Internet Draft An IP VPN Policy Information Model July 2001 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]. Table of Contents 1. Introduction 2. UML Conventions & Terminology 3. IP VPN Information Model 4. Inheritance Hierarchy 5. Policy Class Definitions 6. Topology Class Definitions 7. IpvpnServicePolicyRule Membership And Reachability 8. Generation of device configuration and VPN topology 9. Device Capabilities Model 10.Reliability & Scalability Information in the Model 11.Extending the IP VPN information model 12.Security Considerations 13.References 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 - Iyer et al. Informational - Expires December 2001 [Page 2] Internet Draft An IP VPN Policy Information Model July 2001 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), - 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, Iyer et al. Informational - Expires December 2001 [Page 3] Internet Draft An IP VPN Policy Information Model July 2001 - 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 an informative description of how policy servers would generate device configuration information as well as IP VPN topologies using instances of the ipvpnServicePolicvRule class, - 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. 1. Boxes represent classes, 2. An _o_ denotes an aggregation. An aggregation is essentially a reference, 3. An _x_ denotes containment. A contained object is owned entirely by the container, 4. 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". Iyer et al. Informational - Expires December 2001 [Page 4] Internet Draft An IP VPN Policy Information Model July 2001 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. 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. Iyer et al. Informational - Expires December 2001 [Page 5] Internet Draft An IP VPN Policy Information Model July 2001 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. 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 _ Iyer et al. Informational - Expires December 2001 [Page 6] Internet Draft An IP VPN Policy Information Model July 2001 3.3. IP VPN Information Model - Policy components The IP VPN information model consists of a core IP VPN class that references various other classes, which form the rest of the information model. The core IP VPN class is shown below (figure 3) in the form of a containment tree. The figure references certain classes defined in [2]. The ipvpnServicePolicyRule binds the membership and reachability information for the IP VPN. These are described in greater detail in the subsequent sections. +-----------------+ |PolicyRepository | +-----------------+ x |1..n(placement) +------------------+ |ipvpnPolicyRoot | +------------------+ x x 1..n(placement) | | +---------------+ | |1..n(placement) | | | +---------------------------------------------+ | | | ipvpnServicePolicyRule |x-+ | +---------------------------------------------+ | o o o o o o | | | | | | | | |1 | | | | | | +----------------------+ | | | | | | |ipvpnServiceMembership| | | | | | | +----------------------+ | | | | | | |1..n | | | | | +------------------------+ | | | | | |ipvpnServiceReachability| | | | | | +------------------------+ | | | | | |1..n | | | | +---------------------+ | | | | |ipvpnTrafficTrunkReq | | | | | +---------------------+ | | | | |1..n | | | +------------------+ | | | |ipvpnAccessLinkReq| | | | +------------------+ | | | |1 | | +-----------------+ | | | PolicyGroup | | | +-----------------+ | | o | | | +--------------------+ | | |ipvpnPolicyPartition| | | +--------------------+ | |1..n +----------------------------+ +-----------+ Iyer et al. Informational - Expires December 2001 [Page 7] Internet Draft An IP VPN Policy Information Model July 2001 | ipvpnPolicyReusableRoot | |PolicyRule | +----------------------------+ +-----------+ x x |1..n(placement) |1..n(placement) +---------------+ +---------------+ |PolicyCondition| | PolicyAction | +---------------+ +---------------+ - Figure 3. IP VPN information model: policy components - The important aspects to be highlighted in the containment tree are: - The ipvpnServiceMembership decides which network elements are required to be aware of the IP VPN. This object references physical topology information objects. The topology objects are described in detail in subsequent sections, - The ipvpnServiceReachability provides a description of the IP VPN topology according to the connectivity requirements that have been expressed by the customer for implementing the IP VPN service e.g. hub and spoke, full mesh, partial mesh, point-to-point, etc. This component provides a complete description of the connectivity requirements of the IP VPN service. This object can reference physical topology information objects. The IP VPN connectivity capabilities will have to meet the requirements specified in this draft, - The ipvpnTrafficTrunkReq aggregates the requirements for the traffic trunks that can be used to transport the IP VPN traffic over the provider network, - The ipvpnAccessLinkReq aggregates the requirements for the access links that can be used to carry traffic related to this IP VPN, - The gpsPolicyGroup aggregates the complete set of policy rules to be enforced for the forwarding of the traffic within the IP VPN. These rules will be instantiated as per the customer requirements. This includes a complete description of the security and QoS requirements of the IP VPN service, - The ipvpnPolicyPartition reflects the administrative, functional and policy enforcement information related to the IP VPN service organization. The administrative partition specifies who is allowed to modify the definition of this IP VPN. The functional partition calls out the various functions being requested. The enforcement partition is related to any grouping of the physical nodes based on geographical location considerations and/or ownership of the nodes. The membership and reachability components of the ipvpnServicePolicyRule will address the topology, addressing and routing information that are related to the requirements of the Iyer et al. Informational - Expires December 2001 [Page 8] Internet Draft An IP VPN Policy Information Model July 2001 information model. These components will reference the physical topology components to be described later in this section. The policies grouped under the gpsPolicyGroup will address the security and QoS-related requirements of the IP VPN policy information model. The subsequent sections later on in this document provide details on the various classes referenced by the above-mentioned core IP VPN classes. 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. 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 Iyer et al. Informational - Expires December 2001 [Page 9] Internet Draft An IP VPN Policy Information Model July 2001 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). 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 Iyer et al. Informational - Expires December 2001 [Page 10] Internet Draft An IP VPN Policy Information Model July 2001 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 interfaces are interconnected by Core Links, which represent the transmission resources that interconnect routers. These physical topology classes are referenced by the membership and reachability attributes of the ipvpnServicePolicyRule class. 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: (l) EdgeProviderNodeInIPVPN Iyer et al. Informational - Expires December 2001 [Page 11] Internet Draft An IP VPN Policy Information Model July 2001 (m) VirtualEndPointInEdgeProviderNode (n) VFIInEdgeProviderNode (o) VirtualLink (p) AccessEndPointInVFI (q) 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 access links to the correct paths and vice-versa. A Virtual Forwarding Instance accomplishes this task. 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] | | | +----ipvpnServicePolicyRule [this document] | +----ipvpnPolicyPartition[this document] | +----PolicyConditionInPolicyRule[PCIM] | +----PolicyCondition[PCIM] | | | +-------PolicyTimePeriodCondition[PCIM] | | | +-------VendorPolicyCondition[PCIM] | | | +-------PolicySimpleCondition[PCIMe] | | | +-------PolicyCompoundCondition[PCIMe] | +----qoSPolicyTokenBucketTrfcProf[QPIM] | +----ipvpnTrafficTrunk[this document] | Iyer et al. Informational - Expires December 2001 [Page 12] Internet Draft An IP VPN Policy Information Model July 2001 +----ipvpnAccessLink[this document] | +----PolicyVariable[PCIMe] | +----PolicyValue[PCIMe] | | | +-------PolicyIPv4AddrValue[PCIMe] | | | +-------PolicyIPv6AddrValue[PCIMe] | | | +-------ipvpnApplicationSignatureValue[this document] | | | +-------ipvpnEnforcerProfileValue[this document] | +----PolicyActionInPolicyRule[PCIM] | | +----PolicyAction[PCIM] | +-------VendorPolicyAction[PCIM] | +-------ipvpnPolicyForwardingAction[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: - ipvpnServicePolicyRule which extends the gpsPolicyRule class to include the semantics required to define an IP VPN service, - ipvpnApplicationSignatureValue, ipvpnEnforcerProfileValue which extend the gpsPolicyValue class to capture the application level classification requirements and the enforcer capabilities respectively, Iyer et al. Informational - Expires December 2001 [Page 13] Internet Draft An IP VPN Policy Information Model July 2001 - ipvpnPolicyForwardingAction to capture the IP VPN routing policy which will provide the IP VPN routers with the appropriate configuration information (e.g. link metric assignment), so that they dynamically enforce the routing policy of a given IP VPN, - ipvpnPolicyNATAction, ipvpnPolicyFirewallAction, ipvpnPolicyEncryptionAction which extends PolicyAction to capture NAT, Firewall and Encryption requirements of the IP VPN service, - ipvpnForwardingAction, which captures the information used to configure the VPN specific forwarding tables. 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. Informational - Expires December 2001 [Page 14] Internet Draft An IP VPN Policy Information Model July 2001 +----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. Informational - Expires December 2001 [Page 15] Internet Draft An IP VPN Policy Information Model July 2001 5. Policy Class Definitions The PolicyRule class represents the core policy class, which is defined in [2]. The attributes of the PolicyRule are mentioned once again in this document for convenience. The ipvpnServicePolicyRule extends this core class to meet the requirements of an IP VPN information model. NAME PolicyRule DESCRIPTION The core class for representing the "If Condition then Action" semantics associated with a policy rule. DERIVED FROM Policy ABSTRACT FALSE PROPERTIES CIM_System.CreationClassName[key] CIM_System.Name[key] CreationClassName[key] PolicyRuleName[key] Enabled ConditionListType RuleUsage Priority Mandatory SequencedActions PolicyRoles 5.1 The Class ipvpnServicePolicyRule The ipvpnServicePolicyRule represents the policies corresponding to an ipvpnService definition. It is associated with a gpsPolicyCompondCondition object and a gpsPolicyGroup object. It extends the semantics of the gpsPolicyRule by means of a contained ipvpnPolicyPartition object. The ipvpnServicePolicyRule can contain nested ipvpnServicePolicyRule(s). NAME ipvpnServicePolicyRule DESCRIPTION The class for holding the conditions and policies required to implement the ipvpnService. DERIVED FROM gpsPolicyRule ABSTRACT FALSE PROPERTIES ipvpnServiceMembership [ref EdgeNode[2..n]], IpvpnServiceReachability[ ref ipvpnPolicyForwardingAction[1..n]], IpvpnTrafficTrunkReq[ref ipvpnTrafficTrunk[1..n]], IpvpnAccessLinkReq[ref ipvpnAccessLink[1..n]], IpvpnServicePolicyGroup [ref gpsPolicyGroup[1]], IpvpnServicePolicyPartition [ref ipvpnServicePolicyPartition[1]] Iyer et al. Informational - Expires December 2001 [Page 16] Internet Draft An IP VPN Policy Information Model July 2001 The aggregation gpsPolicyRuleInPolicyRule provides nesting of ipvpnServicePolicyRule(s). The aggregation PolicyRuleInPolicyGroup provides association of an unordered list of PolicyRules. This section provides the basic definitions for the components of the ipvpnServicePolicyRule. The membership and reachability attributes are explained in greater detail in section 7. 5.1.1. The Reference ipvpnServiceMembership A member of an IP VPN is a physical entity (router) that is aware of the IP VPN and participates in making decisions relating to the forwarding of the traffic associated to this IP VPN. The IP VPN members could for example correspond to the Border Nodes, which are potential homes for the virtual routers mentioned in the [6] draft. This attribute is used to specify all the physical topology objects that need to be aware of a given IP VPN. The member objects referenced are instance(s) of EdgeNode. This identifier could be an IP address or any "Router ID/Interface ID" which identifies the device or interface. 5.1.2. The Reference ipvpnServiceReachability This is a reference to one or more ipvpnPolicyForwardingAction(s), which implement the IP VPN service topology. The routing actions will enable the administrator to create point-to-point, hub and spoke, full mesh and partial mesh topologies. The routing actions capture the connectivity requirements of the IP VPN service. The policy routing ipvpnForwardingActions capture the end-to-end connectivity requirements for the traffic that will be conveyed by a given IP VPN. The "members" listed in the ipvpnServiceMembership attribute or the nodes that are aware of this IP VPN SHOULD use this information to set up the required routes and forward datagrams along these routes. 5.1.3. The Reference ipvpnTrafficTrunkReq This is a reference to one or more ipvpnTrafficTrunk(s), which collectively describe the traffic trunk requirements of the IP VPN. The IP VPN traffic is aggregated at the EdgeNode(s) and is carried over the traffic trunks across the provider network to a peering EdgeNode. 5.1.4. The Reference ipvpnAccessLinkReq This is a reference to one or more ipvpnAccessLink(s), which collectively describe the access link requirements of the IP VPN. The IP VPN traffic originates behind the access links and is carried over the access links to the edge node. The ipvpnAccessLink is a Iyer et al. Informational - Expires December 2001 [Page 17] Internet Draft An IP VPN Policy Information Model July 2001 requirement which will be realized in a topology AccessLink object. The relationship between the ipvpnAccessLink and the topology AccessLink is explained in section 5.10. 5.1.5. The Reference ipvpnServicePolicyGroup This is a reference to a gpsPolicyGroup, which contains the PolicyRules required to implement the ipvpnService. This is a collection of rules that reflect the customers' requirements in terms of architecture (including forwarding and routing considerations), QoS (including PHB (Per Hop Behavior, [18]) instantiation), security (including traffic filters definition and IP VPN user identification/authentication) and management (including the definition of the statistical information that needs to be retrieved, as well as the retrieval frequency). 5.1.6. The Reference ipvpnServicePolicyPartition This is a reference to an ipvpnPolicyPartition object that holds various partition attributes of the ipvpnServicePolicyRule. The partition attributes are inherited by the nested ipvpnServicePolicyRule(s). The nested containers can override them. The overriding values cannot exceed the scope of the values in the parent ipvpnServicePolicyRule. 5.2. 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.2.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 Iyer et al. Informational - Expires December 2001 [Page 18] Internet Draft An IP VPN Policy Information Model July 2001 5.3. The Class ipvpnEnforcerProfileValue Specifies the profile of the enforcer, which is supposed to implement the policy. The enforcerProfileValue is specified within a qosPolicySimpleCondition for a qosPolicyVariable named _EnforcerProfile_ NAME ipvpnEnforcerProfileValue DESCRIPTION The class for representing the profile of the enforcers which are expected to implement the policy. DERIVED FROM qoSPolicyValue ABSTRACT FALSE PROPERTIES enforcerProfile 5.3.1. The Property enforcerProfile NAME enforcerProfile DESCRIPTION The property that provides a profile used to identify the types of enforcers, which are expected to enforce the policy. SYNTAX String 5.4. The class ipvpnPolicyForwardingAction NAME ForwardingActionipvpnPolicyForwardingAction DESCRIPTION The class for representing the forwarding actions. The forwarding actions should support point-to- point, hub and spoke, full mesh and partial mesh topology requirements. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES ipvpnPolicyRoutingSource[ref AccessEndPoint[1]] IpvpnPolicyRoutingDestination[ref AccessEndPoint[1]] IpvpnPolicyRoutingMandatoryHops[ref EdgeNode[2..n]] 5.4.1. The reference ipvpnPolicyRoutingSource This is a reference to an object of type AccessEndPoint. 5.4.2. The reference ipvpnPolicyRoutingDestination This is a reference to an object of type AccessEndPoint. 5.4.3. The reference ipvpnPolicyRoutingMandatoryHops 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 Iyer et al. Informational - Expires December 2001 [Page 19] Internet Draft An IP VPN Policy Information Model July 2001 The objects referenced are instance(s) of EdgeNode. 5.5. The class ipvpnPolicyNATAction This class specifies which source addresses need to be translated and what should be the results of this translation. NAME NATAction 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 5.5.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.5.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.6. The class ipvpnTrafficTrunk This class indicates the requirements on the traffic trunk to be used to transport the IP VPN traffic. NAME ipvpnTrafficTrunk DESCRIPTION The class for representing the requirements of the traffic trunk to be used to transport the VPN traffic DERIVED FROM Policy ABSTRACT FALSE PROPERTIES Ingress[ref EdgeNode] Egress[ref EdgeNode] Priority[Integer] Iyer et al. Informational - Expires December 2001 [Page 20] Internet Draft An IP VPN Policy Information Model July 2001 Preemption[Integer (1-4)] Resilience[boolean] TrafficProfile[QosPolicyTokenBucketTrfcProf] 5.6.1. The reference Ingress This attribute references the Edge Node, which will be the ingress node for the trunk. 5.6.2. The reference Egress This attribute references the Edge Node, which will be the egress node for the trunk. 5.6.3. The property Priority This attribute indicates the priority requirement for the trunk. NAME Priority DESCRIPTION The priority requirement for the trunk. SYNTAX Integer 5.6.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.6.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.6.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.7. The class ipvpnPolicyFirewallAction Iyer et al. Informational - Expires December 2001 [Page 21] Internet Draft An IP VPN Policy Information Model July 2001 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.7.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 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.8. 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 Iyer et al. Informational - Expires December 2001 [Page 22] Internet Draft An IP VPN Policy Information Model July 2001 5.8.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.8.2. The property IkeEncryption The property specifies the encryption algorithm to be used. NAME IkeEncryption DESCRIPTION The property that specifies the encryption algorithm. SYNTAX String 5.8.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.8.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.8.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.8.6. The property IPSECAuthentication Iyer et al. Informational - Expires December 2001 [Page 23] Internet Draft An IP VPN Policy Information Model July 2001 The property specifies the authentication algorithm to be used. NAME IPSECAuthentication DESCRIPTION The property that specifies the authentication algorithm. SYNTAX String 5.8.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.8.8. The property IPSECDHGroup 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.8.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.8.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.8.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. Iyer et al. Informational - Expires December 2001 [Page 24] Internet Draft An IP VPN Policy Information Model July 2001 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 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.9. The Class ipvpnPolicyPartition This class holds all the non policy-related information for the ipvpnServicePolicyRule. This pertains to the administration, the function and the enforcement partitions of the ipvpnServicePolicyRule. The partitioning could be on the basis of who can modify what information (administrative), which IP VPN policies are related to a particular function e.g. QoS, which subset of network is impacted by the policies(enforcement). The policy consumer partition will typical line up with the enforcement domain. NAME ipvpnPolicyPartition DESCRIPTION The ipvpnPolicyPartition holds all the non policy-related information for the policies contained in an ipvpnNamedPolicyContainer. DERIVED FROM Policy PROPERTIES policyAdministratorPartition policyFunctionPartition policyEnforcementPartition 5.9.1. The Property policyAdministratorPartition This property relates to the administrative rights to the ipvpnServicePolicy. Iyer et al. Informational - Expires December 2001 [Page 25] Internet Draft An IP VPN Policy Information Model July 2001 NAME policyAdministratorPartition DESCRIPTION An administrator who belongs to the partition mentioned in this property has administration rights over the ipvpnNamedPolicyContainer. SYNTAX String 5.9.2. The Property policyFunctionPartition This property relates to the function of the ipvpnServicePolicy. NAME policyFunctionPartition DESCRIPTION The property relates to the function of the ipvpnServicePolicy such as firewall, QoS, etc. SYNTAX String 5.9.3. The Property policyEnforcementPartition This property relates to the enforcers who need to implement the policies in the ipvpnServicePolicyRule. NAME policyEnforcementPartition DESCRIPTION This property relates to enforcers that need to implement the policies defined in the ipvpnServicePolicyRule. SYNTAX String 5.10. The class ipvpnAccessLink This class indicates the requirements on the access link used to transport the IP VPN traffic from the AccessEndPoint to the Edge Node. The ipvpnAccessLink represents access link requirements of a single IP VPN. The access link requirements of several IP VPN related to a single access end point, can be aggregated to generate the specifications for the topology AccessLink object. NAME ipvpnAccessLink DESCRIPTION The class for representing the requirements of the access link used to transport the IP VPN traffic from the AccessEndPoint to the EdgeNode. DERIVED FROM Policy ABSTRACT FALSE PROPERTIES ipvpnAccessEndPoint[AccessEndPoint] ipvpnEdgeNode[EdgeNode] TrafficProfile[QosPolicyTokenBucketTrfcProf] ipvpnAccessDirection[Integer] 5.10.1. The reference ipvpnAccessEndPoint This attribute indicates the AccessEndPoint at the start of the access link. Iyer et al. Informational - Expires December 2001 [Page 26] Internet Draft An IP VPN Policy Information Model July 2001 5.10.2. The reference ipvpnEdgeNode This attribute indicates the EdgeNode at the end of the access link. 5.10.3. The property TrafficProfile This attribute indicates the traffic profile requirement for the access link. NAME TrafficProfile DESCRIPTION The Traffic Profile requirement for the trunk SYNTAX QoSPolicyTokenBucketTrfcProf 5.10.4. The property ipvpnAccessDirection This attribute indicates the direction for which the access links requirements are specified in the containing ipvpnAccessLink. NAME ipvpnAccessDirection DESCRIPTION The direction for which access link requirements are specified. SYNTAX INTEGER VALUE The direction can take the following values 0 _ Access to Edge, CPE to PE 1 _ Edge to Access, PE to CPE 2 _ Bidirectional, between PE and CPE 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 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 Iyer et al. Informational - Expires December 2001 [Page 27] Internet Draft An IP VPN Policy Information Model July 2001 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 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" Iyer et al. Informational - Expires December 2001 [Page 28] Internet Draft An IP VPN Policy Information Model July 2001 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: NAME ProtocolEndPoint DESCRIPTION A communication point. DERIVED FROM ServiceAccessPoint ABSTRACT FALSE PROPERTIES ProtocolType Iyer et al. Informational - Expires December 2001 [Page 29] Internet Draft An IP VPN Policy Information Model July 2001 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_ 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 Iyer et al. Informational - Expires December 2001 [Page 30] Internet Draft An IP VPN Policy Information Model July 2001 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 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. Iyer et al. Informational - Expires December 2001 [Page 31] Internet Draft An IP VPN Policy Information Model July 2001 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 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]] Iyer et al. Informational - Expires December 2001 [Page 32] Internet Draft An IP VPN Policy Information Model July 2001 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 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 Iyer et al. Informational - Expires December 2001 [Page 33] Internet Draft An IP VPN Policy Information Model July 2001 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 PROPERTIES GroupComponent [ref Node[0..*]] PartComponent [ref ProtocolEndPoint[0..*]] 6.23. The Aggregation "AccessEndPointInEdgeNode" Iyer et al. Informational - Expires December 2001 [Page 34] Internet Draft An IP VPN Policy Information Model July 2001 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 DESCRIPTION A class representing the aggregation of virtual interfaces by PEs. DERIVED FROM ProtocolEndPointInNode ABSTRACT FALSE PROPERTIES GroupComponent [ref EdgeNode[1..1]] Iyer et al. Informational - Expires December 2001 [Page 35] Internet Draft An IP VPN Policy Information Model July 2001 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. IpvpnServicePolicyRule Membership And Reachability This section provides some important clarifications on key aspects of the ipvpnServicePolicyRule class, namely the membership and reachability components. This explanation for the membership and reachability is in addition to the basic definition provided in the previous section. The purpose is to clarify the definition using some of the information provided subsequent to the first mention of these classes. 7.1. The ipvpnServiceMembership attribute This attribute specifies the physical nodes, which will be aware of the IP VPN and participate in routing traffic over the IP VPN. These sets of nodes are referred to as "members" of the IP VPN. A member is thus an entity who is aware of the IP VPN and participates in making forwarding decisions relating to of the traffic that will be conveyed by the IP VPN. The members would correspond to the physical routers, which are candidates to implement the IP VPN-based forwarding of datagrams required by the IP VPN. The physical router(s) are instances of EdgeNode that need to be aware of the IP VPN to provide the necessary forwarding functionality. The EdgeNode, upon receipt of this information, will instantiate the required routing related resources that will forward the traffic related to a given IP VPN. Iyer et al. Informational - Expires December 2001 [Page 36] Internet Draft An IP VPN Policy Information Model July 2001 7.2. The ipvpnServiceReachability attribute This is a reference to one or more ipvpnPolicyForwardingAction(s) that implement the IP VPN service topology. The routing actions will enable to administrator to create/deploy point-to-point, hub and spoke, full mesh and partial mesh topologies. The forwarding actions capture the connectivity requirements of the IP VPN service (This has been repeated from the class definition for convenience). The policy routing actions capture the end-to-end forwarding requirements for the traffic that belongs to a given IP VPN. The members listed in the ipvpnServiceMembership attribute or the nodes that are aware of this IP VPN would use this information to set up the required connections and forward the datagrams along these connections. The mandatory hops are instance(s) of EdgeNode. This could be the physical identifier for a device and/or interface. A member may instantiate a virtual router that is configured with information provided in the ipvpnServiceReachability attribute. The ipvpnPolicyForwardingAction class includes specification of L2 and L3 identifiers for source and destination. These identifiers can be references to the IP addresses or the L2 identifiers of an AccessEndPoint. The L2 identifier is used to associate a virtual forwarding instance with specific virtual interfaces. The virtual interface identifier will be dependent on the access technology e.g. VPI/VCI for ATM, VLAN for Ethernet etc. +--------------------------+ +------------------------+ |ipvpnServiceMembership | |ipvpnServiceReachability| +--------------------------+ +------------------------+ | | | | | 2..* | +----------+ +------------------------+ | EdgeNode | | | | +----------+ +---------+ +-----------+ +------------+ |Source | |Destination| |MandatoryHop| +---------+ +-----------+ +------------+ | | | | | | | | | | 1 | 1 | 2..* +--------------+ +--------------+ +--------+ |AccessEndPoint| |AccessEndPoint| |EdgeNode| +--------------+ +--------------+ +--------+ - Figure 10: Referencing of physical topology classes in ipvpnServicePolicyRule - Iyer et al. Informational - Expires December 2001 [Page 37] Internet Draft An IP VPN Policy Information Model July 2001 8. 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 ipvpnServicePolicyRule. 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. 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 9. 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. Iyer et al. Informational - Expires December 2001 [Page 38] Internet Draft An IP VPN Policy Information Model July 2001 This section of the draft is to be updated with a detailed capabilities model in future revisions. 10. Reliability and Scalability Information 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. 11. 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 the [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) Iyer et al. Informational - Expires December 2001 [Page 39] Internet Draft An IP VPN Policy Information Model July 2001 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. 12. 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. 13. 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-01.txt, Work in Progress, April 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. Iyer et al. Informational - Expires December 2001 [Page 40] Internet Draft An IP VPN Policy Information Model July 2001 [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. [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 R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000 14. 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 Iyer et al. Informational - Expires December 2001 [Page 41] Internet Draft An IP VPN Policy Information Model July 2001 France Phone: +33 2 31 75 94 28 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 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 December 2001 [Page 42]