One document matched: draft-takeda-l1vpn-framework-00.txt
Network Working Group Tomonori Takeda (Editor)
Internet Draft NTT
Expires: August 2004 February 2004
Framework for Layer 1 Virtual Private Networks
draft-takeda-l1vpn-framework-00.txt
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC 2026
[RFC2026].
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
Abstract
This document 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.)
0.1. Summary
This document describes a framework for Layer 1 VPNs (L1VPNs).
T.Takeda, et al. Expires August 2004 [Page 1]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
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.L1VPNARCH]. However, some Internet drafts are related to this topic
and the following three ones are relevant ones.
o draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-04.txt (October 2003)
"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.
o draft-ietf-ccamp-gmpls-overlay-02.txt (October 2003)
"GMPLS UNI: RSVP 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
T.Takeda, et al. Expires August 2004 [Page 2]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
model may be used to support VPN connections across a core GMPLS
network.
o draft-andersson-ppvpn-terminology-04.txt (September 2003)
"PPVPN 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 ............................................... 4
3.1 Overview ................................................... 4
3.1.1 Network Topology ........................................... 5
3.1.2 Introducing Layer 1 VPNs ................................... 5
3.1.3 Current Technologies for Dynamic Layer 1 Provisioning ...... 5
3.2 Relationship with ITU-T .................................... 6
4. Motivations ................................................ 6
4.1 Basic Layer 1 Services ..................................... 7
4.1.1 L1VPN for Dynamic Layer 1 Provisioning ..................... 8
4.2 Merits of L1VPN ............................................ 8
4.2.1 Customer Merits ............................................ 8
4.2.2 Provider Merits ............................................ 8
4.3 L1VPN Deployment Scenarios ................................. 9
4.3.1 Multi-Service Backbone ..................................... 9
4.3.2 Carrier's Carrier .......................................... 9
4.3.3 L1 Resource Trading ........................................ 10
4.3.4 Inter-SP L1 VPN ............................................ 10
5. Reference models ........................................... 10
5.1 CE/PE/P Terminology ........................................ 11
5.2 Customer/Provider Terminology .............................. 12
5.3 Management Systems ......................................... 12
6. Generic Service Description ................................ 12
6.1 CE Construct ............................................... 13
6.2 Generic Service Features ................................... 13
7. Service Models ............................................. 13
7.1 Management-based Service Models ............................ 13
7.2 Signaling-based Service Models (Overlay Service Models)..... 14
7.3 Signaling and Routing Service Models ....................... 15
7.3.1 Virtual Link Models ........................................ 16
7.3.2 Per VPN Peer Models ........................................ 16
8. Service Models and Service Requirements .................... 17
9. Security Considerations .................................... 18
10. Acknowledgements ........................................... 18
11. Intellectual Property Consideration ........................ 18
12. Normative References ....................................... 19
13. Informative References ..................................... 19
T.Takeda, et al. Expires August 2004 [Page 3]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
14. Authors' Addresses ......................................... 20
15. Full Copyright Statement ................................... 21
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].
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
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
T.Takeda, et al. Expires August 2004 [Page 4]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
3.1.1 Network Topology
The layer 1 network, made of Optical Cross-Connects (OXCs) or Time
Division Multiplex (TDM) capable switches, 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 between the CE and PE devices. It is at
this interface (between CE and PE devices) that the L1VPN service is
provided.
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.
T.Takeda, et al. Expires August 2004 [Page 5]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
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 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
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
T.Takeda, et al. Expires August 2004 [Page 6]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
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 quality of the 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: For example, the number of error-seconds per month.
The layer 1 services may be categorized based on the combination of
connectivity features (U-plane) and service control capability
features (C-plane) available to the customer. A CE is associated with
the service interface between a customer site and the 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
network is responsible for the management of both the network
T.Takeda, et al. Expires August 2004 [Page 7]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
infrastructure and the end user connections. For dynamic services, the
network is only responsible for the configuration of the
infrastructure; end user connections are established dynamically by
the network.
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).
Compared to the first type of service, the L1VPN service has features
such as a separate policy per VPN, and distribution of information
about which CEs can participate in which VPNs.
4.2 Merits of L1VPN
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.
T.Takeda, et al. Expires August 2004 [Page 8]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
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
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 (U-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.
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:
- more limited view of L1VPN service provider network
- more limited control over L1VPN service provider network.
T.Takeda, et al. Expires August 2004 [Page 9]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
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, i.e. 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.
5. Reference models
Figure 5.1 describes the L1VPN reference model.
T.Takeda, et al. Expires August 2004 [Page 10]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
+--------------------------------+
| |
| | : +------+
| +------------+ | : | 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 CE's physical interfaces
within the same VPN. In Figure 5.1, a connection is provided between
the lefthand CE of VPN A and the upper righthand CE of VPN A, and
another connection is provided between the lefthand CE of VPN B and
lower righthand CE of VPN B (shown as "=" mark).
5.1 CE/PE/P Terminology
In the reference model, the following three types of network devices
are described. Note that these terminologies are from PPVPN works
[PPVPN-TERM].
o CE (Customer Edge) device
A CE device is a customer device that receives L1VPN service from the
T.Takeda, et al. Expires August 2004 [Page 11]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
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.
o 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 TDM or optical cross connect. Or a PE device may be
an EPL (Ethernet Private Line) type of device, that maps Ethernet
frames on L1 connections.
o 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 or optical
cross connect.
5.2 Customer/Provider Terminology
In this document, the following two types of administrative entities
are described.
o 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.
o Provider
A Provider has authority over the management of the provider network.
5.3 Management Systems
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's
management system(s) may also communicate with customer's 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.
T.Takeda, et al. Expires August 2004 [Page 12]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
6.1 CE Construct
- The CE device may contain multiple VPN instances.
- CE-PE physical links (between physical interfaces) may be shared by
multiple VPNs. (assuming that each CE-PE logical link maps one-to-
one to a VPN, and maps one-to-one or many-to-one to the physical
link)
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 physical interfaces. (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
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 between the CE and PE devices. A CE and a PE are
connected by one or more GMPLS Traffic Engineering (TE) links as
defined in [GMPLS-ROUTING]. The ends of each link are usually
represented as GMPLS-capable interfaces.
7.1 Management-based Service Models
Figure 7.1 describes the management-based service models.
T.Takeda, et al. Expires August 2004 [Page 13]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
+--------------------+
| |
+----------+ | +----------+ |
|Management| : | |Management| |
| system(s)|-:-----|----| system(s)| |
+----------+ : | +----------+ |
: | |
: | |
+----+ : +----+ +----+ +----+ : +----+
| CE |-------:---| PE |----| P |----| PE |---:-------| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.1: Management-based service models
In this service model, customer's management system(s) and provider's
management system(s) communicate with each other. Customer's
management system(s) access provider's management system(s) to request
L1 connection setup/deletion between a pair of CEs. Customer's
management system(s) may obtain additional information, such as
resource availability information and monitoring information, from
provider's 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.
7.2 Signaling-based Service Models (Overlay Service Models)
Figure 7.2 describes the signaling-based service models.
T.Takeda, et al. Expires August 2004 [Page 14]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
+--------------------+
| |
+----+ : +----+ +----+ : +----+
| CE |-------:---| PE | | PE |---:-------| CE |
+----+ : +----+ +----+ : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.2: Signaling-based service models
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 CE sites, nor routing information of the
provider network. The CE's interface may be assigned a public or
private address, that designates connection end points.
A CE may optionally receive a list of TE link addresses to which it
can request a connection (a list of addresses within the same VPN)
(overlay ext.).
Note that in addition, there may be communication between customer's
management system(s) and provider's management system(s) in order to
provide detailed monitoring and fault information etc. to customers.
7.3 Signaling and Routing Service Models
In this service model, the customer interface is based on GMPLS
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. By
using traffic engineering-based routing information obtained,
customers 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 CE sites, and not
necessarily between CEs.
Note that in addition, there may be communication between customer's
management system(s) and provider's management system(s) in order to
provide detailed monitoring and fault information etc. to customers.
There are two more detailed signaling and routing service models,
virtual link models and per VPN peer models.
T.Takeda, et al. Expires August 2004 [Page 15]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
7.3.1 Virtual Link Models
Figure 7.3 describes the virtual link models.
+--------------------+
| Virtual |
+----+ : +----+ link +----+ : +----+
| CE |-------:---| PE |**************| PE |---:-------| CE |
+----+ : +----+ +----+ : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.3: Virtual link models
In this service model, a virtual link is constructed between PEs. A
virtual link is a TE link connecting two devices where a direct
physical link does not exist. The CE receives routing information of
PE-CE links, remote CE sites, as well as virtual links. A virtual
link's TE attributes may be derived from physical links within the
provider network.
As a special case, the provider may choose not to advertise virtual
links to customers. The CE receives routing information of CE-PE links
and remote CE sites only. This corresponds to advertising a whole
provider network as one node, i.e. Generalized Virtual Private Cross-
Connect (GVPXC) [GVPN].
7.3.2 Per VPN Peer Models
Figure 7.4 describes per VPN peer models.
+--------------------+
| |
+----+ : +----+ +----+ +----+ : +----+
| CE |-------:---| PE |----| P |----| PE |---:-------| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 7.4: Per VPN peer models
In this service model, the provider partitions TE links within the
T.Takeda, et al. Expires August 2004 [Page 16]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
provider network per VPN, and discloses per VPN TE link information to
corresponding CEs. As such, a CE receives routing information of PE-CE
links, remote CE 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".
Note that when inter-area/AS solutions are available, it may be
valuable to consider inter-area/AS interfaces to be the basis for
customer interface.
8. Service Models and Service Requirements
Service models mentioned in section 7 is related to what information
is exchanged between the CE and the PE. In addition, service models
vary depending on how U-Plane resources are allocated for each VPN.
Specifically, service models are described by combining following
service requirements.
NOTE: Later version of this document may include more detailed service
requirements from Y.1312.
o U-Plane resource allocation
- Shared or dedicated : Shared means that provider network physical
links are shared by multiple VPNs.(Physical links are allocated to
each VPN when connection is requested, and physical links
allocated to one VPN at one time can be allocated to another VPN
at another time.) Dedicated means that provider network physical
links are partitioned per VPN. (Physical links allocated to one
VPN can not be used by other VPNs.)
o Information exchanged between the CE and the PE
- Signaling
- Membership information : A list of TE link addresses within the
same VPN (connection end points)
- Customer network routing information
- Provider network routing information
Table 1 shows combination of service requirements and service models.
T.Takeda, et al. Expires August 2004 [Page 17]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
| U-Plane shared | U-Plane dedicated
---------------------------+------------------+-------------------
Signaling | Overlay | Overlay
---------------------------+------------------+-------------------
Signaling + | Overlay (ext.) | Overlay (ext.)
Membership information | |
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | Virtual link | Virtual link
Customer network routing | |
information (Note1) | |
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | |
Customer network routing | Not applicable | Per VPN peer
information + | |
Provider network routing | |
information | |
Table 1: Combination of service requirements and service models
Note1: In virtual link models, to be precise, PE-PE virtual link
information, which is part of provider network routing information, is
advertised from a PE to CE.
9. Security Considerations
TBD
10. Acknowledgements
The material in this document is based on the work of the ITU-T Study
Group 13, and it has been submitted to meet the 00 ID deadline.
Further related communication will be provided after the closure of
Study Group 13 February 2004 meeting in the form of liaison statement.
11. Intellectual Property Consideration
The IETF takes no position regarding the validity or scope
of any intellectual property or other rights that might be
claimed 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; neither does it represent that it has made any
effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track
and standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication
and any assurances of licenses to be made available, or the
T.Takeda, et al. Expires August 2004 [Page 18]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by
implementors or users of this specification can be obtained
from the IETF Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may
be required to practice this standard. Please address the
information to the IETF Executive Director.
12. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process
-- Revision 3", RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic
requirements and architecture elements, ITU-T
Recommendation, September 2003.
13. Informative References
[Y.L1VPNARCH] Y.l1vpnarch - Layer 1 Virtual Private Network service
and network architectures, ITU-T draft Recommendation.
[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.
T.Takeda, et al. Expires August 2004 [Page 19]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
[GMPLS-ROUTING] Kompella, K., et al., "Routing Extensions in Support
of Generalized MPLS", draft-ietf-ccamp-gmpls-routing,
work in progress.
[L2VPN-FRAME] Andersson, L., and Rosen, E. (editors), "L2VPN
Framework", draft-ietf-l2vpn-l2-framework, work in
progress.
[L3VPN-FRAME] Callon, R., et al., "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-andersson-ppvpn-terminology, work in progress.
[GVPN] Ould-Brahim, H., and Rekhter, Y. (editors), "GVPN
Services: Generalized VPN Services using BGP and
GMPLS Toolkit", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls,
work in progress.
14. 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-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - FRANCE
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
T.Takeda, et al. Expires August 2004 [Page 20]
Internet Draft draft-takeda-l1vpn-framework-00.txt February 2004
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
15. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may
be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns. This document and the information
contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
T.Takeda, et al. Expires August 2004 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 01:54:42 |