Internet DRAFT - draft-iyer-ipvpn-infomodel
draft-iyer-ipvpn-infomodel
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
<draft-iyer-ipvpn-infomodel-03.txt>
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]
