One document matched: draft-jacquenet-ip-vpn-needs-00.txt
Internet Engineering Task Force C. Jacquenet
INTERNET-DRAFT France Telecom R & D
Document: draft-jacquenet-ip-vpn-needs-00.txt
Category: informational
Expires: January 2001
Functional requirements for the deployment of an IP VPN service
offering
<draft-jacquenet-ip-vpn-needs-00.txt>
1. Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 ([RFC-2026]).
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.
2. Abstract
This document aims at identifying the requirements which should be
taken into consideration by a service provider, when considering the
deployment of an IP VPN service offering. From this perspective,
this document does not specify any technical means which could be
used to deploy an IP VPN service offering, unlike the [VPN-FRAME]
document.
This document tries to express a service provider perspective,
according to its own experience of IP-based service offerings, and
to its own perception of the (constantly) evolving needs of the
customers of such services. To some extent, this document can be
viewed as a complementary taxonomy effort of the [TAXONOMY] draft.
3. 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 ([RFC-
2119]).
4. Glossary
IP VPN requirements July 2000
CPE: Customer Premises Equipment.
Customer: See " subscriber ".
SLA: Service Level Agreement. A SLA is a contractual document
which a subscriber and a service provider have
agreed upon.
SLS: Service Level Specification. A SLS is the technical and
detailed specification of an SLA.
SMFA: Specific Management Functional Area, such as
configuration management, performance management,
security management, alarm management and accounting
management.
SoHo: Small office Home office.
Subscriber:A subscriber (or a customer) is a legal representative
who has the (legal) ability to subscribe to a service
offering.
User: A user is an entity (a human being or a process, from a
general perspective) who has been named by a subscriber
and appropriately identified by a service provider, so
that he might benefit from a service according to his
associated rights and duties.
VPN: Virtual Private Network. A collection of switching
resources (namely routers) and transmission resources
which will be used over an IP backbone to process the IP
traffic which will reflect the data oriented-
communication service of an enterprise (VPNs which are
designed to support intranet-based applications) or a set
of enterprises (VPNs which are designed to support
extranet-based applications). An IP VPN may also provide
an access to the Internet, from a service offering
perspective.
5. Some basic definitions
5.1. What's an IP VPN ?
An IP VPN is a set of IP switching and transmission resources which
is dedicated to the use of a set of authorized users, and which is
deployed over a public IP backbone.
5.2. What's an IP VPN service offering ?
An IP VPN service offering is one of the services which may be
provided by a service provider, and which consists in engineering,
deploying and managing one or more IP VPN(s) for the corresponding
subscriber, and according to the needs which have been expressed by
this subscriber before the contractual agreement has been signed
between the subscriber and the service provider, AND during the
contractual lifetime of the above-mentioned agreement.
5.3. The customers of an IP VPN service offering
An IP VPN service offering is designed to address some of the needs
of the corporate enterprises. From that perspective, an IP VPN
IP VPN requirements July 2000
service offering will have to consider the following categories of
subscribers:
- a single enterprise which may subscribe to the IP VPN service
offering to exclusively address its internal data communication
needs, within the context of running intranet applications;
- a set of enterprises which may subscribe to the IP VPN service
offering to exclusively address their data communication needs
between themselves, within the context of running extranet
applications. Some or all of these enterprises may also subscribe to
the IP VPN service offering to address their own internal data
communication needs, without any kind of interference.
In any case, the subscriber of an IP VPN service offering is an
administrative entity which has been granted to represent an
enterprise or a set of enterprises, at least from a legal
perspective. Subscribing to an IP VPN service offering also means
that there will be at least one IP VPN which will be deployed for
the subscriber.
5.4. The users of an IP VPN service offering
The users of an IP VPN service offering are the human beings (or
processes) which will communicate with other human beings (or
processes) thanks to the use of workstations (PCs, Unix
workstations, whatever) to exchange information between them by
using the resources of the IP VPN service offering. From this
perspective, the users can be classified into two categories:
- static users, i.e. users who will communicate with the other users
(or part of) by using the resources of the IP VPN service offering
without moving from their office and by always using the same
workstation. This office can be precisely identified, at least
according to some basic geographical considerations;
- mobile users, i.e. users who will communicate with the other users
(or part of) by using the resources of the IP VPN service offering
wherever they may be and, more precisely, one can distinguish:
* the mobile users who may move within a single location among the
various locations which will be used/granted by the IP VPN service
offering subscriber (e.g. one of the sites of a given enterprise
which will be interconnected by at least one IP VPN which is part of
the contract the subscriber and the IP VPN service provider have
agreed upon). That kind of mobile user may use a given set of
workstations within the above-mentioned location and may make use of
the IP VPN service offering resources only when moving within this
location;
* the mobile users who may move between the set of (or part of)
locations which will be used/granted by the IP VPN service offering
subscriber. That kind of mobile user may make use of the IP VPN
service offering resources only when moving within this set of
locations;
IP VPN requirements July 2000
* the mobile users who may make use of the IP VPN service offering
resources wherever they may be, including accessing these resources
through the Internet network or from their home, within the context
of SoHo workers.
6. Description of the requirements for an IP VPN service offering
6.1. Architectural considerations
6.1.1. The network components of an IP VPN service offering
According to the definition which has been given in chapter 5.1, the
network components of an IP VPN service offering will have to
process the IP traffic that will be exchanged between the users of
the IP VPN service offering, and that will reflect the use of an as
widest as possible range of applications, ranging from electronic
mail to video-conferencing applications.
Moreover, since an IP VPN service offering will have to consider the
connection of sites which may belong to an enterprise (or a set of
enterprises), there should be no kind of limitation in terms of
link-layer-based access technology (1), such as PSTN, ISDN, xDSL,
leased line, ATM, Frame Relay, etc. If there is such a limitation,
this will have to be clearly and precisely stated when defining the
technical specifications of the IP VPN service offering.
From this access perspective, it should be possible to provide a
back-up capability (2) whenever the primary access link from a site
to one of the IP VPN(s) which may have been deployed for the
subscriber fails to be operational.
As far as IP traffic is concerned, an IP VPN service offering will
obviously make use of an IP forwarding and routing global resource
which may be distributed among various locations, including customer
and service provider premises. Nevertheless, since an IP VPN service
offering belongs to the range of internetworking service offerings
which are (to be) provided by a service provider, the limit of
responsibility will have to be clearly identified between both
parties - namely the customer and the IP VPN service provider.
(1): considering the link layer technology which is used (or yet to
be used) by the IP backbone which will support the IP VPNs that will
be deployed within the context of an IP VPN service offering is, by
definition, out of the scope of this document. Nevertheless, the
engineering characteristics of such an IP backbone will have to be
taken into account when specifying the IP VPN service offering.
(2): this back-up capability should obviously be as dynamic as
possible, i.e. the back-up link should be dynamically established as
soon as the primary access link fails to be operational, and should
become dynamically idle as soon as the primary access link comes
back up.
6.1.1.1. Numerical considerations
IP VPN requirements July 2000
The dimensioning considerations which may characterize an IP VPN
service offering can be expressed as the number of expected
customers, the number of expected users per customer, and/or the
number of expected IP VPNs to be deployed.
From that perspective, the technical specification of an IP VPN
service offering should consider the following assumptions:
- it should be possible to deploy more than one IP VPN per
subscriber, especially when considering the IP layer as the multi-
service layer of the subscriber;
- the number of sites which may be interconnected by a given IP VPN
is obviously a function of the size of the subscriber (in terms of
turnover or number of employees, for example), and it may also
reflect the organization of the subscriber (e.g. national banks
which are composed of thousands of agencies which may have a
permanent access to a central site, and a record manufacturing
company, which may have a couple of production sites, an R and D
location, and its headquarters). From that perspective, the number
of sites may dramatically vary from one subscriber to another,
typically ranging from 2 or 3 sites, up to several thousands of
locations, both national and international.
6.1.1.2. Permanent access and temporary access
The IP VPN service offering should allow both permanent and
temporary access (to one or several IP VPNs) for its users,
according to their very own rights (see the corresponding " security
considerations " chapter). Once again, there should be no limitation
in the type of access technology which may be used as the IP
transportation technology.
6.1.1.3. IP traffics considerations
The IP VPN service offering should handle any kind of IP traffic -
namely broadcast, anycast, multicast and unicast, and may also have
the ability to activate the appropriate filtering capabilities
whenever required, and whatever the filter may be, upon request of
the customer.
An example of such a request would consist in optimizing as far as
possible the time needed for an authorized user to become a member
of a video-conferencing service according to some specific
scheduling requirements which may have an impact on the processing
functions of the corresponding IP multicast trafic (wherever these
functions may be located), if the video-conferencing application has
been built so that it may gracefully benefit from the activation of
such multicast processing capabilities.
6.1.1.4. IP numbering schemes considerations
The IP VPN service offering should gracefully take care of the
following cases :
IP VPN requirements July 2000
- the subscriber has deployed its own private numbering scheme on
every location which may benefit from the IP VPN service offering,
and this IP numbering scheme should never be changed in any case;
- the subscriber has deployed a globally unique IP numbering scheme
composed of public IP addresses which have been delivered by the
IANA;
- the subscriber has deployed NO IP numbering scheme, and has made
no specific request either : in this case, the IP VPN service
offering should be able to address this need, whatever the
corresponding provisioning may be (i.e. private and/or public -
including an IPv6-based numbering scheme, if appropriate).
The IP VPN service offering should also provide the following
capabilities:
- a dynamic IP address allocation mechanism whenever requested by
the user, and whatever the access may be, i.e. either permanent or
temporary;
- an IP numbering scheme outsourcing feature, which may consist for
the service provider in managing the IP numbering scheme which has
been deployed by or allocated to the subscriber, including the
multicast addressing scheme.
The appropriate DNS service which may be provided to the subscriber
will have to be taken into consideration as well, whenever
appropriate (e.g. when connecting a new location to one of the IP
VPNs which have been deployed for the subscriber).
6.1.1.5. Accessing the Internet
The IP VPN service offering may also provide an access to the
Internet network for all the authorized users which have been
declared by the subscriber(3).
The IP VPN(s) which may be deployed for the subscriber may either
process the corresponding IP traffic (i.e. the traffic which is
destined to or comes from the Internet network) or reject the
corresponding traffic thanks to the activation of the appropriate
filtering capabilities (4).
(3): the subscriber may also request that some of his " Web-based
communication" servers which would be installed in one of the sites
connected to one of his IP VPNs, might be accessed from the Internet
network. This probably yields some security considerations which are
detailed in paragraph 6.1.3. of the present document.
(4): it's important to note that BOTH cases (at least one of the IP
VPNs which have been deployed for the subscriber will process the
"Internet" traffic, or none of these IP VPNs will process the
"Internet" traffic) may very well correspond to the " Internet
access " capability (or, more suitably, option) of the IP VPN
service offering.
IP VPN requirements July 2000
6.1.1.6. Migration considerations
Subscribers of the IP VPN service offering who have already deployed
their own private network (whatever the technology) should not
suffer from migration considerations (whatever they are), when
evolving from the above-mentioned network towards one or more IP
VPNs. This migration should be as smooth as possible, both from an
economical and technical perspectives.
6.1.2. Quality of service considerations
6.1.2.1. The basic nature of applications
Applications that may be run over the IP VPN(s) which has(ve) been
deployed for the subscriber can be classified into two categories
(it is obviously the responsibility of the subscriber to decide
whether an application is "critical" or "not that critical"):
- there are applications which are critical either to delay, jitter,
throughput or reliability (or a combination of the above-mentioned
criteria). Real-time applications (such as voice over IP) are
generally considered as sensitive applications, for example;
- there are applications which are not that critical, i.e. they can
accept an affordable degradation when being transmitted, even from a
user perspective. For example, a transaction process thanks to the
use of the Telnet protocol can accept some delay variations (which
may even cause the loss of a given set of datagrams), because the
integrity of the transaction is not that damaged, especially when
considering the fact that the Telnet protocol relies upon the TCP
layer. On the other hand, the loss of a single IP datagram during an
FTP-based file transfer may have a dramatic impact on the integrity
of the file, so that the user could simply be unable to use this
file.
This critical/not that critical kind of typology for the
applications which are to be run over the IP VPN(s) which will be
deployed for a given subscriber will have to be taken into account
by the IP VPN service offering, at least from a quality of service
perspective, so that it will have to consider the deployment of QOS-
based IP VPNs.
6.1.2.2. Dealing with congestion
Whenever a congestion is experienced in the IP backbone which will
support the IP VPNs (and wherever this congestion may take place),
it may affect the transmission of the IP datagrams. Some of these
datagrams will reflect the activation of sensitive applications,
others will reflect the activation of not-that-sensitive
applications.
It is therefore the responsibility of the IP VPN service provider to
provide any means which may be appropriate so that:
IP VPN requirements July 2000
- sensitive applications-based IP datagrams will never have to
suffer from any kind of congestion, either in the IP VPN which
processes such datagrams, or somewhere in the IP backbone, provided
it has been clearly stated (by any means appropriate) that the
responsibility of such a congestion is the IP VPN service provider's
responsibility. This means that no such datagrams will be lost
during their transmission over the IP VPN, which yields the notion
of quality of service guarantees for such datagrams. Such guarantees
will have to be expressed in terms of QOS indicators, and these
indicators will have to be as precisely as possible defined and
measured on a regular basis (e.g. one month), so that they might be
used as part of the contract which will be signed between the
subscriber and the service provider;
- not-that-sensitive applications-based IP datagrams may
occasionally suffer from any kind of congestion. This "suffering"
might be expressed in terms of classes of service, which may allow
the service provider to:
* process (i.e. transmit) some datagrams more rapidly than others,
according to a scheduling policy which may be part of the contract
between the subscriber and the service provider;
* discard some datagrams rather than others, according to a
discarding policy which may be part of the contract between the
subscriber and the service provider;
* commit in providing a maximum loss rate (or some equivalent
indicator), which may vary according to the number of classes of
service that may be defined and activated by the service provider
within the network resources he's responsible of (e.g. a one out of
a thousand datagrams for the "economy" class of service, a one out
of a million datagrams for the "business" class of service, and a
one out of a billion datagrams for the "first" class of service).
6.1.2.3. Service guarantees
According to what has been mentioned in the above chapter, the IP
VPN service provider will have to commit in some specific service
guarantees which will be part of the contract that will be signed
between the subscriber and the service provider. This yields the
notion of SLA both parties will have to agree upon, and the
corresponding specification is the SLS.
The IP VPN service offering should therefore have the ability to
provide a range of SLAs/SLSes to address the needs of its
subscribers.
6.1.3. Security considerations
6.1.3.1. Identifying and authenticating the users
The IP VPN(s) to be deployed will be used by human beings (or
processes) who will have to be precisely authorized and
authenticated. In other words, the IP VPN service offering will have
to provide any appropriate means which will help both parties in
IP VPN requirements July 2000
being convinced that no unexpected/unauthorized user will access the
IP VPN resources which might be deployed for the subscriber.
Identifying the user means that the service provider will have to
provide an as precise as possible answer to the following question:
"who does the (requesting) user claim to be ?"
Authenticating the user means that the service provider will have to
provide an as precise as possible answer to the following question:
"since the identity of the user has been (somewhat) confirmed (by
answering to the previous question), who is the actual human being
according to the identification information he has provided and what
are his rights ?"
6.1.3.2. Protecting the resources of the subscriber
When deploying one or several IP VPNs for the subscriber, the IP VPN
service offering will have to provide the appropriate guarantees
that the corresponding resources have the ability to deny any kind
of malicious intrusion, especially by protecting the access to the
locations (by " location ", the author means either a site which may
have a permanent access to the IP VPN resources, or a site which may
have a temporary access to the IP VPN resources, including mobile
hosts) of the subscriber which might be interconnected by the IP
VPN(s), and also by ensuring that the IP VPN resources will deny the
access to the locations of the subscriber which are not even
connected to the IP VPN(s).
6.1.3.3. Preserving the data confidentiality within the IP VPN(s)
The IP VPN service offering will have to preserve the
confidentiality of the information which is to be transmitted over
the IP VPN resources. Moreover, if several IP VPNs are to be
deployed for a given subscriber, the IP VPN service offering will
have to preserve the confidentiality of the information which is to
be transmitted through the various IP VPNs so that any kind of
interference might never occur between these IP VPNs.
6.1.3.4. Identifying and authenticating the network resources
The IP VPN service offering will have to guarantee that, for a given
IP VPN (or a set of IP VPN(s)) which has (have) been deployed for a
given subscriber, all of the network resources that will be used by
this (these) IP VPNs have been appropriately identified and
authenticated, so that they have the right to process (i.e. mainly
forward and route) the corresponding IP traffic.
As far as the security is concerned, the less the (network)
resources involved in the processing of the IP traffic of a given IP
VPN, the more secure this IP VPN will be.
6.1.4. Service management considerations
The management of an IP VPN service offering will have to comply
with the following requirements:
IP VPN requirements July 2000
- engineer, deploy and manage the switching and transmission
resources which will support the IP VPN service offering, from a
network perspective. This features reflects the network element
management part of the service management activity;
- manage the IP VPNs which have been deployed over the above-
mentioned resources. This feature reflects the network management
part of the service management activity;
- manage the IP VPN service offering itself (this reflects the
service management part of the service management activity). From
a general perspective, the service management should at least
include the global activation of the five classical SMFAs which have
been specified by ISO - namely alarm, security, configuration,
performance and accounting management. This means in particular:
* the specification and the establishment of SLAs between the
service provider and the various subscribers, according to the
corresponding SLSes;
* the measurement of the indicators which have been defined within
the context of the above-mentioned SLAs, on a regular basis (namely
one day, one week, one month, one quarter, one year, or else);
* the management of the users which have been identified and granted
by the subscriber, so that they may benefit from the IP VPN(s) which
have been deployed accordingly. This should also include the
integration of the management of possible user/subscriber
directories.
- finally manage the IP VPN business, which mainly consists in
provisioning administrative and accounting information related to
the IP VPN service offering subscribers. This feature reflects the
business management part of the service management activity.
7. Constraints and selection criteria of an IP VPN service offering
7.1. Functional constraints
It is assumed the service provider already operates an IP backbone,
which could support an IP VPN service offering. This implies that
the technical choices must be taken in accordance to the
technologies and equipment which are already in use in this
backbone. Nevertheless, the technical solutions which will be
considered must be supported by the Internet standardization process
for compatibility, modularity and backward compatibility purposes.
Furthermore, some security functions are needed to ensure that the
IP VPN(s) which is (are) provided to the customer is (are) actually
"private", and these specific requirements may have an impact on the
functional features which are currently supported by the equipment
of the IP backbone.
7.2. Selection criteria
7.2.1. Performances
IP VPN requirements July 2000
As far as the performances are concerned, the IP VPN service
offering should support the following characteristics :
- the time to access the service from a user standpoint should be
expressed in milliseconds.
7.2.2. Quality of service
To be defined according to the SLAs which should be provided along
with the provisioning of the IP VPN service offering itself,
according to the " quality of service considerations " paragraph
(6.1.2) of the present document.
8. References
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[VPN-FRAME]Gleeson, B., Heinanen, J., Armitage, G., Malis, A., "A
Framework for IP Based Virtual Private Networks ", RFC
2764, February 2000
[TAXONOMY] Berkowitz, H., "Requirements Taxonomy for Virtual
Private Networks",draft-berkowitz-vpn-tax-00.txt, work
in progress, March 1999
9. Author's address
Christian Jacquenet
France Telecom Research and Development
42, rue des Coutures
BP 6243
14066 Caen cedex 04
France
Phone: + 33 2 31 75 94 28
Fax: + 33 2 31 73 56 26
Email: christian.jacquenet@francetelecom.fr
10. Full copyright statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
IP VPN requirements July 2000
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.
| PAFTECH AB 2003-2026 | 2026-04-24 04:17:11 |