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