Network Working Group Tomonori Takeda (Editor)
Internet Draft NTT
Expires: August 2005 February 2005
Framework for Layer 1 Virtual Private Networks
draft-takeda-l1vpn-framework-03.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document provides a framework for Layer 1 Virtual Private
Networks (L1VPNs). This framework is intended to aid in developing
and standardizing protocols and mechanisms to support interoperable
L1VPNs.
The document examines motivations for L1VPNs, high level (service
level) requirements, and outlines some of the architectural models
that might be used to build L1VPNs.
0. Summary
(This section to be removed before publication as an RFC.)
T.Takeda, et al. Expires August 2005 [Page 1]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
0.1. Summary
This document describes a framework for Layer 1 VPNs (L1VPNs).
L1VPNs provide services over layer 1 networks, such as WDM and TDM
networks. This document provides a framework for L1VPNs and the
realization of the framework by those networks being controlled by
GMPLS protocols.
0.2. Where does it fit in the picture of the IETF Work
Services may be provisioned across layer 1 networks using GMPLS
protocols. L1VPNs may be managed and operated using these protocols
as described in this document. GMPLS protocols were developed within
the IETF using IP addressing and based on IP and other Internet
protocols. The IETF continues to work with GMPLS protocols, enhancing
them and applying them to new requirements.
VPN related work areas might also have points of interaction with the
content of this document.
0.3. Justification
This document exists to demonstrate the service level requirements
for L1VPNs and to create a framework for L1VPNs within the existing
Internet architectures. As such, this document is the justification
for better understanding of L1VPNs within the IETF.
Study Group 13 of the ITU-T has been investigating the service level
requirements for L1VPNs with input from major network service
providers and equipment vendors. There is a strong feeling within
SG13 that the desirability of L1VPN services is growing and that
there is a need for a minimum set of common approaches that will
lead to interoperable solutions.
0.4. Related Internet Documents
Much of the background work for this document has been directly
developed within the ITU-T and is presented as [Y.1312] and
[Y.1313]. However, some Internet drafts are related to this topic
and the following three ones are relevant ones.
o draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt (May 2004)
"GVPN Services: Generalized VPN Services using BGP and GMPLS
Toolkit"
This draft describes a suite of port-based Provider-provisioned VPN
services called Generalized VPNs (GVPNs) that uses BGP as a VPN
auto-discovery and GMPLS as a signaling mechanism.
T.Takeda, et al. Expires August 2005 [Page 2]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
o draft-ietf-ccamp-gmpls-overlay-05.txt (October 2004)
"Generalize Multiprotocol Label Switching(GMPLS) User-Network
Interface (UNI): Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Support for the Overlay Model"
This memo addresses the application of GMPLS to the overlay model.
In one section, the memo provides a description of how the overlay
model may be used to support VPN connections across a core GMPLS
network.
o draft-ietf-l3vpn-ppvpn-terminology-04.txt (September 2004)
"Provider Provisioned VPN terminology"
This draft sets out terminology common to all Provider Provisioned
VPNs. Although this draft specifically targets L2VPNs and L3VPNs,
the terminology may be used to L1VPNs as well.
Contents
1. Contributors ............................................... 4
2. Terminology ................................................ 4
3. Introduction ............................................... 5
3.1 Overview ................................................... 6
3.1.1 Network Topology ........................................... 6
3.1.2 Introducing Layer 1 VPNs ................................... 6
3.1.3 Current Technologies for Dynamic Layer 1 Provisioning ...... 7
3.2 Relationship with ITU-T .................................... 7
4. Motivations ................................................ 8
4.1 Basic Layer 1 Services ..................................... 8
4.1.1 L1VPN for Dynamic Layer 1 Provisioning ..................... 9
4.2 Merits of L1VPN ............................................ 10
4.2.1 Customer Merits ............................................ 10
4.2.2 Provider Merits ............................................ 10
4.3 L1VPN Deployment Scenarios ................................. 10
4.3.1 Multi-Service Backbone ..................................... 11
4.3.2 Carrier's Carrier .......................................... 11
4.3.3 L1 Resource Trading ........................................ 12
4.3.4 Inter-SP L1 VPN ............................................ 12
4.3.5 Other Scenarios ............................................ 13
5. Reference models ........................................... 13
5.1 Management Systems ......................................... 14
6. Generic Service Description ................................ 14
6.1 CE Construct ............................................... 14
6.2 Generic Service Features ................................... 14
7. Service Models ............................................. 15
7.1 Management-based Service Model ............................. 15
7.2 Signaling-based Service Model (Overlay Service Model) ...... 16
7.3 Signaling and Routing Service Model ........................ 17
7.3.1 Virtual Node Service Model ................................. 17
7.3.2 Virtual Link Service Model ................................. 18
T.Takeda, et al. Expires August 2005 [Page 3]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
7.3.3 Per VPN Peer Service Model ................................. 18
8. Service Models and Service Requirements .................... 19
9. Security Considerations .................................... 21
9.1 Types of Information ....................................... 22
9.2 Security Features .......................................... 22
9.3 Scenarios .................................................. 23
10. Acknowledgements ........................................... 23
11. Normative References ....................................... 24
12. Informative References ..................................... 24
13. Authors' Addresses ......................................... 25
14. Intellectual Property Consideration ........................ 26
15. Full Copyright Statement ................................... 26
1. Contributors
This document is based heavily on the work of ITU-T Study Group 13
Question 11. SG13/Q11 has been investigating the service requirements
and architecture for Layer 1 VPNs for some time, and this document
is a summary and development of the conclusions they have reached. As
such, ITU-T SG13 should be seen as a major contributor to this
document.
The details of this document are the result of contributions from
several authors who are listed here in alphabetic order. Contact
details for these authors can be found in a separate section near
the end of this document.
Raymond Aubin (Nortel)
Marco Carugi (Nortel)
Ichiro Inoue (NTT)
Hamid Ould-Brahim (Nortel)
Tomonori Takeda (NTT)
2. Terminology
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 [RFC2119].
The reader is assumed to be familiar with the terminology in
[RFC3031], [RFC3209], [RFC3471], [RFC3473], [GMPLS-ROUTING] and
[PPVPN-TERM].
In addition, following new terms are used within this document.
- Virtual link: A provider network TE link provided to customers in
routing information for purposes which include path computation. A
data link may or may not exist between two end points of a
virtual link.
T.Takeda, et al. Expires August 2005 [Page 4]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
- Virtual node: A provider network logical node provided to customers
in routing information. A virtual node may represent a single
physical node or multiple physical nodes and links.
- VPN end point: CE's data plane interface, connected to a PE device,
which is part of the VPN membership. Note, a data plane interface
is the transmission unit associated with a connection, and includes
a channel in a channelized interface.
- VPN connection (or connection in L1VPN context): A connection
between a pair of VPN end points. Note in some scenarios, a
connection may be established between a pair of Cs (customer
devices), using this CE-CE VPN connection as a segment or
forwarding adjacency.
Note following terms are aligned with PPVPN terminology, and in this
document, have a meaning in the context of L1VPNs, unless specified.
- CE (Customer Edge) device: A CE device is a customer device that
receives L1VPN service from the provider. A CE device is connected
to at least one PE device. A CE device can be a variety of devices,
for example, TDM cross connect, router and L2 switch. A CE device
may also be attached to one or more C devices on the customer site.
- PE (Provider Edge) device: A PE device is a provider device that
provides L1VPN service to the customer. A PE device is connected to
at least one CE device. A layer 1 PE device is a Time Division
Multiplex (TDM) switch, Optical Cross-Connect (OXC) or Fiber
Switch (FXC). Or a PE device may be an EPL (Ethernet Private Line)
type of device, that maps Ethernet frames on L1 connections.
- P (Provider) device: A P device is a provider device, which is
connected only to other provider devices (P or PE devices). A layer
1 P is a TDM switch, OXC, or FXC.
- Customer: A Customer has authority over a set of CE devices within
the same VPN (e.g., the owner of CE devices). Note that a customer
may outsource the management of CE devices to other organizations,
including to the provider itself.
- Provider: A Provider has authority over the management of the
provider network.
3. Introduction
The document examines motivations for Layer 1 Virtual Private
Networks (L1VPNs), provides high level (service level) requirements,
and outlines some of the architectural models that might be used to
T.Takeda, et al. Expires August 2005 [Page 5]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
build L1VPNs.
The objective of the document is mainly to present the requirements
and architecture work in this field that has been undertaken within
the ITU-T.
L1VPNs provide services over layer 1 networks. This document provides
a framework for L1VPNs and the realization of the framework by those
networks being controlled by GMPLS protocols.
3.1 Overview
3.1.1 Network Topology
The layer 1 network, made of Optical Cross-Connects (OXCs), Time
Division Multiplex (TDM) capable switches, or Fiber Switches (FXCs)
may be seen as consisting of provider edge (PE) devices that give
access from outside of the network, and provider (P) devices that
operate only within the core of the network. Similarly, outside the
layer 1 network is the customer network consisting of customer (C)
devices with access to the layer 1 network made through customer edge
(CE) devices.
A CE and PE are connected by one or more links. A CE may also be
connected to more than one PE, and a PE may have more than one CE
connected to it.
3.1.2 Introducing Layer 1 VPNs
The concept of a provider provisioned VPN (PPVPN) has been
established through many previous documents such as [L2VPN-FRAME] and
[L3VPN-FRAME]. Terminology for PPVPNs is set out in [PPVPN-TERM] with
special reference to layer 2 and layer 3 VPNs.
The realization of Layer 1 VPNs (L1VPNs) can be based on extensions
of the concepts of the PPVPN to the layer 1 network. It must be
understood that meeting the requirements set out in this document may
necessitate modifications to the existing mechanisms both for the
control plane within the layer 1 network and for service provisioning
at the edge of the network (CE and PE devices). It is at the
interface between CE and PE devices that the L1VPN service is
provided.
Note that one of the fundamental differences between L1VPNs and L2/L3
VPNs is that in L1VPNs data plane connectivity does not guarantee
control plane connectivity (and vice versa). CE-PE control plane
connectivity is essential, and CE-CE data plane connectivity is
maintained by signaling mechanisms based on this control plane
connectivity. The provision of CE-CE control plane connectivity over
T.Takeda, et al. Expires August 2005 [Page 6]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
the provider network is also an unique aspect of the L1VPN services,
by which control packets can be exchanged between CEs over the
control plane of the provider network (e.g., to exchange signaling
messages, using VPN connection as a segment of FA)
3.1.3 Current Technologies for Dynamic Layer 1 Provisioning
Pre-existing efforts at standardization have focused on the provision
of dynamic connections within the layer 1 network (signaling and
routing), and the interfaces for requesting services between the CE
and PE or between PEs at network boundaries (UNI and E-NNI
respectively).
No change in principle would be required to the operation within the
network, and the E-NNI is not in scope for current L1VPN
considerations. But the UNI is very relevant since it is a means by
which the CE can make service requests to the PE to establish
services (that is, connections) across the layer 1 network to remote
CEs.
Current UNIs include features to facilitate requests for end-to-end
(that is, CE to CE) service requests that include the specification
of constraints such as explicit paths, bandwidth requirements,
protection needs, and (of course) destinations.
The UNIs, however, do not provide a sufficiently high level of
service to support VPNs without some additions. For example, there is
no way to distinguish between control messages received over a shared
control link (i.e., a control link shared by multiple VPNs) at a UNI,
and these messages must be disambiguated with respect to the L1VPN to
which they apply.
Further, there is currently no leakage of routing information across
the PE to CE boundary. While this restriction may be considered
desirable from the perspective of network separation, VPN operation
may benefit from the dynamic exchange of routing information
between CEs that provide access to the VPNs.
In order that L1VPNs can be supported in a fully functional manner,
these deficiencies and other requirements set out later in this
document must be addressed.
3.2 Relationship with ITU-T
This document is based on the work of the ITU-T Study Group 13
Question 11. This group has been researching and specifying both the
requirements and the architecture of L1VPNs for some time. In this
context, this document is a representation of the findings of the
ITU-T, and a presentation of those findings in terms and format that
T.Takeda, et al. Expires August 2005 [Page 7]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
are familiar to the IETF.
In particular, this document is limited to the areas of concern of
the IETF. That is, it is limited to layer 1 networks that utilize
IP as the underlying support for their control plane.
The intention of this document is to present the requirements and
architectures developed within the ITU-T to the IETF for better
understanding and further cooperation between the two bodies.
Some work related to L1VPN solution space has already been done
within the IETF. This document intends to set a framework of
requirements and architectures into which all possible solutions can
fit.
4. Motivations
In this discussion many merits and motivations may be taken for
granted.
The general benefits and desirability of VPNs has been described
many times and in many places. This document does not dwell on the
merits of VPNs as such, but focuses entirely on the applicability
of the VPN concept to layer 1 networks.
Similarly, the utility and value of a control plane for the
configuration, management and operation of a layer 1 network is
well-rehearsed.
4.1 Basic Layer 1 Services
Basic layer 1 services may be characterized in terms that include:
- Connectivity: Between a pair of CEs.
- Capacity: For example, the bit rate for a TDM service or the
capacity of a lambda.
- Transparency: For example, for an SDH network, overhead
transparency.
- Availability: The percentage of time that the offered service
meets the agreed criteria. To achieve the required level of
availability for the customer connections the service provider's
network may use restoration or protected resources.
- Performance: The quality of the service delivered to customers,
e.g., the number of error-seconds per month.
The layer 1 services may be categorized based on the combination of
connectivity features (data plane) and service control capability
features (control plane) available to the customer. A CE is
associated with the service interface between a customer site and the
T.Takeda, et al. Expires August 2005 [Page 8]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
network, and the categorization can be seen in the context of this
service interface as follows.
1. A single connection between a pair of CEs.
- Static Service
The classic private line service achieved through a permanent
connection.
- Dynamic Service
Either a switched connection service, or a customer-controlled
soft permanent connection service
2. Multiple connections among a set of CEs.
- Static Service
A private network service consisting of a mesh of permanent
connections.
- Dynamic Service
A dynamic private network service consisting of any combination
of switched connection services and customer-controlled soft
permanent connection services.
For both service types, connections are point-to-point, and can be
permanent, soft-permanent, or switched. For a static service, the
management plane of the provider network is responsible for the
management of both the network infrastructure and the end user
connections. For dynamic services, the management plane the provider
network is only responsible for the configuration of the
infrastructure; end user connections are established dynamically via
the control plane of the provider network through customer request.
Note that the ITU-T allows the second categorization of service type
to embrace a variety of C-plane types.
4.1.1 L1VPN for Dynamic Layer 1 Provisioning
Private network services in the second category (above) can be
enhanced so that multiple private networks are supported across the
layer 1 network as virtual private networks. These are Layer 1
Virtual Private Networks (L1VPNs). Note the first category would
include L1VPNs for VPNs with only two CEs as a special case.
Compared to the first type of service, the L1VPN service has features
such as connectivity restriction, a separate policy per VPN, and
distribution of membership information.
4.2 Merits of L1VPN
T.Takeda, et al. Expires August 2005 [Page 9]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
4.2.1 Customer Merits
From the customer's perspective, there are two main benefits to a
L1VPN. These benefits apply over and above the advantages of access
to a dynamically provisioned network.
- The customer can outsource the direct management of an optical
network by placing the VPN management in the control of a third
party. This frees the customer from the need to configure and
manage the connectivity information for the CEs that participate
in the VPN.
- The customer can make small-scale use of an optical network. So,
for example, by sharing access to the optical network with many
other users, the customer sites can be connected together across
the optical network without bearing the full cost of deploying
and managing the optical network.
To some extent, the customer may also gain from the provider's
benefits (see below). That is, if the provider is able to extract
more value from the layer 1 network, and provide better
differentiated services, the customer will benefit from lower
priced services that are better tailored to the customer's needs.
4.2.2 Provider Merits
The provider benefits from the customer's perception of benefits.
In particular, the provider can build on dynamic, on-demand services
by offering new VPN services and off-loading the CE-to-CE
configuration requirements from the customers
Additionally, a more flexible VPN structure applied to the optical
network allows the provider to make more comprehensive use of the
spare (that is, previously unused) resources within the network. In
particular, since the PE could be responsible for routing the
connection through the optical network, the optical network can
reclaim control of how resources are used and adjust the paths so
that optimal use is made of all available resources.
4.3 L1VPN Deployment Scenarios
In large carrier networks providing various kinds of service, it is
often the case that multiple service networks are supported over a
shared transport network. L1VPNs are expected to support this type of
network architecture. Namely, by applying L1VPNs, multiple internal
service networks, which may be managed and operated separately, can
be supported over a shared layer 1 transport network controlled and
T.Takeda, et al. Expires August 2005 [Page 10]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
managed by GMPLS. In addition, L1VPNs can support capabilities to
offer innovative services to external clients.
Some more specific deployment scenarios are as follows.
4.3.1 Multi-Service Backbone
A multi-service backbone is characterized in terms such that one
service department of a carrier receiving the carrier's L1VPN service
provides different kinds of higher-layer service. The customer
receiving the L1VPN service (i.e., each service department) can offer
its own services whose payloads can be any layer (e.g., ATM, IP,
TDM). From the L1VPN service provider point of view, these services
are not visible and are not part of the L1VPN service. That is, the
type of service being carried within the L1 payload is not known by
the service provider.
The benefit is that the same L1 core network resources are shared by
multiple services. A large capacity backbone network (data plane) can
be built economically by having the resources shared by multiple
services usually with flexibility to modify topologies, while
separating the control functions. Thus, each customer can select a
specific set of features that are needed to provide their own
service.
Note it is also possible to control and manage these service networks
and the L1 core network by using GMPLS as a unified control plane,
instead of using L1VPNs. However, using L1VPNs is beneficial in
following points.
- Independent address space for each of the service networks
- Network isolation (topology information isolation, fault isolation
among service networks)
- Independent L1 resource view for each of the service networks
- Independent policies that could be applied for each of the service
networks
4.3.2 Carrier's Carrier
A carrier's carrier is characterized in terms such that one carrier
that receives another carrier's L1VPN service provides its own
services. In this scenario, two carriers may be in different
organizations (or may be separately managed within the same
organization). It is, therefore, expected that the information
provided at the service demarcation points is more limited than in
the multi-service backbone case. Similarly, more less control of the
L1VPN service is given at the service demarcation points. For
example, customers of L1VPN service receive:
T.Takeda, et al. Expires August 2005 [Page 11]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
- more limited view of L1VPN service provider network
- more limited control over L1VPN service provider network.
One of the merits is that each carrier can concentrate on a specific
service. For example, the customer of the L1VPN service may focus on
L3 services, e.g., providing secure access to the Internet, leaving
the L1VPN provider to focus on the L1 service, e.g., providing a long
haul bandwidth between cities. The L1VPN customer can construct its
own network using L1 resources supplied by the L1VPN provider,
usually with flexibility to modify topologies, and utilize dedicated
C-Plane functionalities.
4.3.3 L1 Resource Trading
In addition to the scenarios where the second tier service provider
is using a single core service provider as mentioned above, it is
possible for the second tier provider to receive services from more
than one core service provider. In this scenario, there are some
benefits for the second tier service provider such as dynamic carrier
selection based on the price and route redundancy.
The second tier service provider can support a function that enables
a L1 resource trading service. Using resource information published
by its core service providers, a second tier service providers can
decide how to best use those providers. For example, if one core
service provider is no longer able to satisfy requests for service,
an alternate service provider can be used. Or the second tier service
provider could choose to respond to price changes over time.
Another example of second tier service provider use is to reduce
exposure to failures in each provider (improve availability).
4.3.4 Inter-SP L1 VPN
In addition to the scenarios where a single connection between two
CEs is routed over a single service provider, it is possible that a
connection is routed over multiple service providers. This service
scenario is called Inter-SP L1VPN.
This scenario can be used to construct a single L1VPN from services
provided by multiple regional providers. There could be a variety
of business relationships among providers and customers.
4.3.5 Other scenarios
There can be some more complex L1VPN scenarios such as:
- The case when one or both CE-PE links of a L1VPN connection are not
T.Takeda, et al. Expires August 2005 [Page 12]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
static, but are based on L1VPN connections in their own right
provided by the same or different L1VPN service provider;
5. Reference models
Figure 5.1 describes the L1VPN reference model.
+--------------------------------+
| |
| | : +------+
| +------------+ | : | CE |
| | Management | | : |device|
| | system(s) | +------+ : | of |
| +------------+ | |==:=|VPN A|
| | | : +------+
+------+ : | L1 | PE | : +------+
| CE | : | connection |device| : | CE |
|device| : +------+ +------+ | | : |device|
| of |=:==| |==========| |==========| |--:-| of |
|VPN A| : | | | | +------+ : |VPN B|
+------+ : | PE | | P | | : +------+
+------+ : |device| |device| | : +------+
| CE | : | | | | +------+ : | CE |
|device|=:==| |==========| |==========| |--:-|device|
| of | : +------+ +------+ | | : | of |
|VPN B| : | | PE | : |VPN A|
+------+ : | |device| : +------+
: | | | : +------+
: | | |==:=| CE |
: | +------+ : |device|
: | | : | of |
: | | : |VPN B|
: | | : +------+
Customer | | Customer
interface | | interface
+--------------------------------+
|<------ Provider network ------>|
| |
Figure 5.1: L1VPN reference model
In L1VPN, L1 connections are provided between CEs' data plane
interfaces within the same VPN. In Figure 5.1, a connection is
provided between the left-hand CE of VPN A and the upper right-hand
CE of VPN A, and another connection is provided between the left-hand
CE of VPN B and lower right-hand CE of VPN B (shown as "=" mark).
These L1 connections are called VPN connections.
5.1 Management Systems
T.Takeda, et al. Expires August 2005 [Page 13]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
As shown in the reference model, a provider network may contain a
management system(s). A management system(s) may support functions
including provisioning, monitoring, billing and recording. Provider
management system(s) may also communicate with customer management
system(s) in order to provide services.
6. Generic Service Description
This section describes generic service descriptions. More detailed
service description is described as specific service models in
section 7.
6.1 CE Construct
- The CE device may support more than one customer VPN.
- CE-PE data plane links (between data plane interfaces) may be
shared by multiple VPNs. (assuming that each CE-PE control plane
link maps one-to-one to a VPN, and maps one-to-one or many-to-one
to the data plane link)
Note that the requirement to have a separate CE-PE control channel
per VPN is because current reference points (UNI, E-NNI) do not
provide a way to disambiguate signaling messages that belong to
different VPNs. This requirement might go away (that is, a CE-PE
control channel may be allowed to be shared between multiple VPNs) if
a new VPN reference point is introduced in future, or if suitable
modifications are made to the UNI or E-NNI reference points.
6.2 Generic Service Features
L1VPN has following two generic service features.
- Connectivity restriction: Layer 1 connectivity is provided to a
limited set of CE's data plane interfaces, called VPN end points.
(This set forms the L1VPN membership.)
- Per VPN control and management: Some level of control and
management capability is provided to the customer. Details differ
depending on service models described in section 7.
7. Service Models
This section describes Layer 1 VPN service models, derived from the
generic service description presented above, that can be supported by
Generalized MPLS (GMPLS) protocols enabled networks.
Such layer 1 networks are managed and controlled using GMPLS as
described in [RFC3471] and [RFC3473]. It must be understood that
meeting the requirements set out in this document may necessitate
T.Takeda, et al. Expires August 2005 [Page 14]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
modifications to the existing GMPLS protocols both for the control
plane within the layer 1 network and for service provisioning at the
edge of the network (CE and PE devices). Such modifications are
discussed in [L1VPN-APP]. A CE and a PE are connected by one or more
data links. The ends of each link are usually represented as
GMPLS-capable interfaces.
Note in this document, service models are classified by semantics of
information exchanged over the customer interface.
7.1 Management-based Service Model
Figure 7.1 describes the management-based service model.
+--------------------+
| |
+----------+ | +----------+ |
| Customer | | | Provider | |
|Management| : | |Management| |
| system(s)|-:-----|----| system(s)| |
+----------+ : | +----------+ |
: | |
: | |
+----+ : +----+ +----+ +----+ : +----+
| CE |-------:---| PE |----| P |----| PE |---:-------| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.1: Management-based service model
In this service model, customer management system(s) and provider
management system(s) communicate with each other. Customer
management system(s) access provider management system(s) to request
L1 connection setup/deletion between a pair of CEs. Customer
management system(s) may obtain additional information, such as
resource availability information and monitoring information, from
provider management system(s). There is no control message exchange
between a CE and PE.
The provider network may be based on GMPLS. In this case, existing
protocols to meet this service model may need to be extended (e.g.,
to support soft permanent connections). However, interfaces between
management systems are not within the scope of this document.
Interfaces between management systems and network devices may need to
be studied further.
T.Takeda, et al. Expires August 2005 [Page 15]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
7.2 Signaling-based Service Model (Overlay Service Model)
Figure 7.2 describes the signaling-based service model.
+--------------------+
| |
+----+ : +----+ +----+ : +----+
| CE |-------:---| PE | | PE |---:-------| CE |
+----+ : +----+ +----+ : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.2: Signaling-based service model
In this service model, the customer interface is based on GMPLS UNI
overlay. The CE requests L1 connection setup/deletion to a remote CE.
There is no routing between a CE and PE. The CE does not receive
routing information of remote customer sites, nor routing information
of the provider network. The CE's interface may be assigned a public
or private address, that designates VPN end points.
A CE may optionally receive a list of TE link addresses to which it
can request a VPN connection (a list of addresses within the same
VPN) (overlay extension). Furthermore, this document does not
preclude the case that a CE receives additional information
concerning these TE links (e.g., switching type). Note, in the
overlay extension service model, information a CE can receive is
limited to the CE-PE TE link.
There are various ways that customers perceive the provider network.
In one example, the whole provider network may be considered as one
node - the path specified and recorded in signaling messages reflects
this. Note that this is distinct from the Virtual Node service model
described in section 7.3.1 because such a model requires that the
network is represented to the VPN sites as a virtual node - that is,
some form of routing advertisement is implied, and this is not in
scope for the Signaling-based service model.
Note that in addition, there may be communication between customer
management system(s) and provider management system(s) in order to
provide detailed monitoring, fault information etc. to customers.
7.3 Signaling and Routing Service Model
In this service model, the customer interface is based on GMPLS
T.Takeda, et al. Expires August 2005 [Page 16]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
signaling and routing. The CE requests L1 connection setup/deletion
to a remote CE. There is routing between a CE and PE, or more
precisely between a CE and the VPN routing context instantiated on
the PE. This solves a so-called N-square routing problem [GVPN].
In addition, by using the received traffic engineering-based routing
information, a customer can use traffic engineering capabilities
within his portion of the provider network. For example, a customer
can setup two disjoint connections between a pair of CEs. Another
example is that a customer can request a connection between a pair of
devices within customer sites, and not necessarily between CEs, with
more effective traffic engineering.
Link state routing information would be needed to implement the above
two example scenarios. Some scenarios may be satisfied with
reachability routing information only.
Note that in addition, there may be communication between customer
management system(s) and provider management system(s) in order to
provide detailed monitoring, fault information etc. to customers.
Three specific types of the signaling and routing service model are
the virtual node service model, the virtual link service model and
the per VPN peer service model, depending on how customers perceive
the provider network in routing and signaling.
7.3.1 Virtual Node Service Model
Figure 7.3 describes the virtual node service model.
+--------------------+
| |
+----+ : | | : +----+
| CE |-------:-----| Virtual Node |-----:-------| CE |
+----+ : | | : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.3: Virtual node service model
In this type of service model, the whole provider network is
represented by a virtual node (defined in section 2). The customer
perceives the provider network as one single node, i.e., a
Generalized Virtual Private Cross-Connect (GVPXC) [GVPN]. The CE
receives routing information of CE-PE links and remote customer
sites.
T.Takeda, et al. Expires August 2005 [Page 17]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
7.3.2 Virtual Link Service Model
Figure 7.4 describes the virtual link service model.
+--------------------+
| Virtual |
+----+ : +----+ link +----+ : +----+
| CE |-------:---| PE |**************| PE |---:-------| CE |
+----+ : +----+ +----+ : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.4: Virtual link service model
In this service model, a virtual link is constructed between PEs.
For the definition of a virtual link, please refer to terminology in
section 2. The CE receives routing information of CE-PE links, remote
customer sites, as well as virtual links. A special property of the
virtual links used in this service model is that the provider network
allocates data plane link resources for the exclusive use of each
virtual link. The TE attributes of a virtual link are determined
according to data plane link resources allocated to this virtual
link. Virtual links are abstraction of the provider network to
customers, for administrative purposes, as well as for excluding
"unnecessary information".
7.3.3 Per VPN Peer Service Model
Figure 7.5 describes the per VPN peer service model.
+--------------------+
| |
+----+ : +----+ +----+ +----+ : +----+
| CE |-------:---| PE |----| P |----| PE |---:-------| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.5: Per VPN peer service model
In this service model, the provider partitions the TE links within
the provider network per VPN, and discloses per VPN TE link
T.Takeda, et al. Expires August 2005 [Page 18]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
information to corresponding CEs. As such, a CE receives routing
information of CE-PE links, remote customer sites, as well as
partitioned portions of the provider network.
Note that PEs may advertise abstracted routing information of the
provider network to CEs, for administrative purpose, as well as for
excluding "unnecessary information". In other words, virtual links
may be constructed between two nodes where direct data links do
not exist, or virtual nodes may be constructed to represent multiple
physical nodes and links.
In the per VPN peer service model, at least one virtual node
corresponding to P devices (one single P or a set of Ps) must be
visible to customers. In the virtual link service model, every end
point of virtual links must be a PE device. In the virtual node
service model, there must be one single virtual node, and this
virtual node must be connected with every CE in the VPN.
8. Service Models and Service Requirements
Service models mentioned in section 7 are related to which
information is exchanged between CE and PE. In addition, service
models differ in how data plane resources are allocated for each VPN.
Note in original ITU-T documents, the term "U-Plane" is used instead
of "data plane".
o Data plane resource allocation
- Shared or dedicated :
Shared means that provider network data plane links are shared by
multiple (i.e., any or a specific set of) VPNs. (Data plane links
are allocated to a VPN when a VPN connection is requested, and
data plane links allocated to one VPN at one time can be
allocated to another VPN at another time.)
Dedicated means that provider network data plane links are
partitioned per VPN. (Data plane links allocated to one VPN can
not be used by other VPNs.)
o Information exchanged between CE and PE
- Signaling
- Membership information : A list of TE link addresses within the
same VPN (associated with VPN end points)
- Customer network routing information
- Provider network routing information
T.Takeda, et al. Expires August 2005 [Page 19]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
Table 1 shows combination of service requirements and service models.
| Data plane | Data plane
| shared | dedicated
---------------------------+------------------+-------------------
Signaling | Overlay | Overlay
---------------------------+------------------+-------------------
Signaling + | Overlay | Overlay
Membership information | (extension) | (extension)
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | Virtual node | Virtual node
Customer network routing | |
information | |
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | | Virtual link
Customer network routing | Not applicable |
information + | | Per VPN peer
Provider network routing | |
information | |
Table 1: Combination of service requirements and service models
As described in section 7.3.3, the difference between the virtual
link service model and the per VPN peer service model is whether
customers have visibility of P devices. In the virtual link service
model, every end point of virtual links must be a PE device, thus P
devices are not visible to customers. In the per VPN peer service
model, at least one virtual node corresponding to P devices (one
single P or a set of Ps) is visible to customers.
Note when provider network routing information is provided to
customers, customers must be able to specify explicit links for a VPN
connection over the provider network.
Some additional and more detailed service requirements are provided
below. They are generally common to the various service models.
- Selection of layer 1 class of service: Customers may be optionally
allowed to specify a layer 1 class of service (e.g., availability
level) for a VPN connection.
- Reception of performance information: Customers may be optionally
allowed to receive performance information of their VPN
connections (e.g., performance monitoring data). When data plane
links are dedicated, customers may be optionally allowed to receive
T.Takeda, et al. Expires August 2005 [Page 20]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
performance information of links dedicated to them.
- Reception of fault information: Customers may be optionally allowed
to receive fault information of their VPN connections (e.g.,
failures, data plane alarms, rejections). When data plane links are
dedicated, customers may be optionally allowed to receive fault
information of links dedicated to them.
- Reception of connection information: Customers may be optionally
allowed to receive information of current VPN connections.
- Reception of accounting information: Customers receive accounting
information of each VPN.
- Specification of policy: Customers may be optionally allowed to
specify policies (e.g., path computation policies, recovery
policies including parameters) for each VPN.
- Security: The communication between the customer and the provider
must be secure. Further details are described in section 9.
- Filtering: Unnecessary information (e.g., information concerning
other VPNs) must not be provided to each customer. Further details
are described in section 9.
- Requests/indications for arbitrary CE-CE control plane information
delivery
9. Security Considerations
Security is clearly one of essential requirements in L1VPNs. In this
section, key security requirements are highlighted. Security
considerations for L3VPNs and L2VPNs are described in existing
documents, such as in [L3VPN-FRAME] and [L2VPN-FRAME] respectively.
These security considerations should also be applied in L1VPNs, and
these aspects are described in this section. In addition, there are
some specific security considerations for L1VPNs, such as
connectivity restriction and shared control links.
This section first describes types of information to be secured.
Then, security features or aspects are described. Finally, some
considerations concerning scenarios where security mechanisms are
applied is described.
9.1 Types of Information
The information exchanged between the customer and the provider must
be secured. This includes data plane information, control plane
information and management plane information. At Layer 1, data plane
T.Takeda, et al. Expires August 2005 [Page 21]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
information is normally assumed to be secured by default. In L1VPNs,
VPN connections must be restricted within the same VPN, as described
in section 6.2.
In addition, information contained in the provider network must be
secured. This includes VPN service contract information, current VPN
connection information, VPN membership information, and system
information. Note these types of information may be accessible to
authorized entities.
9.2 Security Features
Security features includes followings:
o Data integrity
The information exchanged between the customer and the provider
must be identical.
o Confidentiality
The information exchanged between the customer and the provider
must not be retrieved by the third party.
o Authentication
The entity requesting the service to the provider must be
identified.
o Access control
Access to the information contained in the provider network must be
restricted to the authorized entity.
9.3 Scenarios
There are mainly two scenarios (or occasions) that security
mechanisms are applied. One is service contract phase, where security
mechanisms are applied once in service contract phase. The other is
service access phase, where security mechanisms are applied every
time service is requested.
o Service contract scenario (static)
This scenario includes addition of new physical devices, such as CE
devices, data links and control links. It must be guaranteed that
these physical devices are connected to the right entity. In
addition, authority to access specific information is given to each
customer as a part of service contract.
T.Takeda, et al. Expires August 2005 [Page 22]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
o Service access scenario (dynamic)
This scenario includes reception of connection request, routing
information exchange request, and management information retrieval
request. If communication channel between the customer and the
provider (control channel, management interface) is physically
separate per customer, and the entity connected over this
communication channel is identified in the service contract phase,
the provider can ensure who is requesting the service. Also, the
communication channel could be considered as secure. However, when
communication channel is physically shared among customers,
security mechanisms should be enforced. Note even in the case of
physically separate communication channel, customers may wish to
apply security mechanisms, such as IPsec, for assuring higher
security.
When the entity requesting the service is identified, the provider
must ensure that the request is authorized for that entity. This
includes assuring that connection request is between VPN end points
belonging to the same VPN.
Also note that customers may wish to apply their own security
mechanisms for data plane information (CE-CE security). This
includes IPsec for IP traffic. Those security mechanisms must be
transparent to customers as much as possible.
10. Acknowledgements
The material in this document is based on the work of the ITU-T Study
Group 13.
We would like to thank Dimitri Papadimitriou, Deborah Brungard and
Yakov Rekhter for their useful comments and suggestions.
11. Normative References
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12. Informative References
For information on the availability of this document, please see
http://www.itu.int.
[Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic
T.Takeda, et al. Expires August 2005 [Page 23]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
requirements and architecture elements, ITU-T
Recommendation, September 2003.
For information on the availability of this document, please see
http://www.itu.int.
[Y.1313] Y.1313 - Layer 1 Virtual Private Network service and
network architectures, ITU-T Recommendation, July
2004.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol label switching Architecture", RFC
3031, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[GMPLS-UNI] Swallow, G., et al., "GMPLS UNI: RSVP Support for the
Overlay Model", draft-ietf-ccamp-gmpls-overlay, work
in progress.
[GMPLS-ROUTING] Kompella, K., and Rekhter, Y. (editors), "Routing
Extensions in Support of Generalized MPLS", draft-
ietf-ccamp-gmpls-routing, work in progress.
[L2VPN-FRAME] Andersson, L., and Rosen, E. (editors), "Framework
for Layer 2 Virtual Private Networks (L2VPNs)",
draft-ietf-l2vpn-l2-framework, work in progress.
[L3VPN-FRAME] Callon, R., and Suzuki, M. (editors), "A Framework
for Layer 3 Provider Provisioned Virtual Private
Networks", draft-ietf-l3vpn-framework, work in
progress.
[PPVPN-TERM] Andersson, L., and Madsen, T., "PPVPN terminology",
draft-ietf-l3vpn-ppvpn-terminology, work in progress.
[GVPN] Ould-Brahim, H., and Rekhter, Y. (editors), "GVPN
Services: Generalized VPN Services using BGP and
T.Takeda, et al. Expires August 2005 [Page 24]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
GMPLS Toolkit", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls,
work in progress.
[L1VPN-APP] T. Takeda (Ed.), "Applicability analysis of GMPLS
protocols to Layer 1 Virtual Private Networks",
draft-takeda-l1vpn-applicability, work in progress.
13. Authors' Addresses
Raymond Aubin
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7 Canada
Phone: +1 (613) 763 2208
Email: aubin@nortelnetworks.com
Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Chateaufort
Les Jeunes Bois - MS CTF 32B5 - Chateaufort
78928 YVELINES Cedex 9 - FRANCE
Phone: +33 1 6955 7027
Email: marco.carugi@nortelnetworks.com
Ichiro Inoue
NTT Network Service Systems Laboratories, NTT Corporation
3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 6076
Email: inoue.ichiro@lab.ntt.co.jp
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
Email: hbrahim@nortelnetworks.com
Tomonori Takeda
NTT Network Service Systems Laboratories, NTT Corporation
3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 7434
Email : takeda.tomonori@lab.ntt.co.jp
14. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
T.Takeda, et al. Expires August 2005 [Page 25]
Internet Draft draft-takeda-l1vpn-framework-03.txt February 2005
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
15. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
T.Takeda, et al. Expires August 2005 [Page 26]