[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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.