One document matched: draft-takeda-l1vpn-applicability-02.txt
Differences from draft-takeda-l1vpn-applicability-01.txt
Network Working Group Tomonori Takeda (Editor)
Internet Draft NTT
Proposed Status: Informational
Expires: August 2005 February 2005
Applicability analysis of GMPLS protocols
to Layer 1 Virtual Private Networks
draft-takeda-l1vpn-applicability-02.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 an applicability analysis on the use of
Generalized Multiprotocol Label Switching (GMPLS) protocols and
mechanisms to satisfy the requirements of Layer 1 Virtual Private
Networks (L1VPNs).
In addition, this document identifies areas where additional
protocol extensions or procedures are needed to satisfy the
requirements of L1VPNs, and provides guidelines for potential
extensions.
T.Takeda, et al. Expires August 2005 [Page 1]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
0. Summary
(This section to be removed before publication as an RFC.)
0.1. Summary
This document describes the applicability of existing GMPLS protocols
and mechanisms to support L1VPNs requirements as described in
[L1VPN-FW]. In addition, this document identifies several areas where
additional protocol extensions are needed to meet the full set of
L1VPN services requirements.
0.2. Where does it fit in the picture of the IETF Work
The IETF is responsible for GMPLS protocols. L1VPNs are a new layer 1
service that adds new requirements for GMPLS as identified in
[L1VPN-FW].
IETF VPN related work areas may also have points of interaction with
the content of this document.
0.3. Justification
The L1VPN mailing list was set up to discuss issues related to
L1VPNs. This document is intended to progress the work by showing the
applicability of existing mechanisms and potential solutions (see
section 0.4) and identifying several areas where additional work is
required.
0.4. Related Internet Documents
This document discusses applicability of existing mechanisms and
potential solutions drafts (listed below) to L1VPN service
requirements as summarized in the following draft.
o draft-takeda-l1vpn-framework-03.txt (Feb 2005)
"Framework for Layer 1 Virtual Private Networks"
This draft examines motivations for L1VPNs, summarizes high level
(service level) requirements, and describes L1VPN architectural
models.
Note this document translates the work of ITU-T Study Group 13
Question 11.
This document discusses the applicability of the following solution
drafts to L1VPN service requirements.
o draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt (May 2004)
T.Takeda, et al. Expires August 2005 [Page 2]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
"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-05.txt (Oct 2004)
"Generalize Multiprotocol Label Switching(GMPLS) User-Network
Interface (UNI): Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Support for the Overlay Model"
This draft addresses the application of GMPLS to the overlay model.
In one section, the draft provides a description of how the overlay
model may be used to support VPN connections across a core GMPLS
network.
Other drafts will be also mentioned when appropriate.
Contents
1. Contributors ............................................. 4
2. Terminology .............................................. 4
3. Introduction ............................................. 4
3.1. Existing Solution Drafts ................................. 5
4. General Guideline ........................................ 6
5. Applicability to Management-based Service Model .......... 7
5.1. Overview of the Service Model ............................ 7
5.2. Applicability of Existing Solutions ...................... 7
5.3. Additional Work Area(s) .................................. 7
6. Applicability to Signaling-based Service Model (Overlay
Service Model) .......................................... 9
6.1. Overview of the Service Model ............................ 9
6.2. Applicability of Existing Solutions ...................... 9
6.3. Additional Work Area(s) .................................. 10
7. Applicability to Signaling and Routing Service Model ..... 12
7.1. Virtual Node Service Model ............................... 12
7.1.1. Overview of the Service Model ............................ 12
7.1.2. Applicability of Existing Solutions ...................... 12
7.1.3. Additional Work Area(s) .................................. 13
7.2. Virtual Link Service Model ............................... 14
7.2.1. Overview of the Service Model ............................ 14
7.2.2. Applicability of Existing Solutions ...................... 14
7.2.3. Additional Work Area(s) .................................. 14
7.3. Per VPN Peer Service Model ............................... 14
7.3.1. Overview of the Service Model ............................ 15
7.3.2. Applicability of Existing Solutions ...................... 15
7.3.3. Additional Work Area(s) .................................. 15
8. Management Aspect ........................................ 16
8.1. Fault Management ......................................... 16
T.Takeda, et al. Expires August 2005 [Page 3]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
8.2. Configuration Management ................................. 17
8.3. Security Management ...................................... 17
9. Discussion ............................................... 18
10. Security Considerations .................................. 19
11. IANA Considerations ...................................... 19
12. Acknowledgement .......................................... 19
13. Normative References ..................................... 19
14. Informative References ................................... 20
15. Authors' Addresses ....................................... 22
Appendix I: Network Usage of L1VPN Service Models ............... 23
Intellectual Property Considerations ............................ 24
Full Copyright Statement ........................................ 24
1. Contributors
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.
Deborah Brungard (AT&T)
Adrian Farrel (Olddog Consulting)
Hamid Ould-Brahim (Nortel Networks)
Dimitri Papadimitriou (Alcatel)
Tomonori Takeda (NTT)
2. Terminology
The reader is assumed to be familiar with the terminology in
[RFC3031], [RFC3209], [RFC3471], [RFC3473], [GMPLS-RTG],
[PPVPN-TERM] and [L1VPN-FW].
3. Introduction
This document shows the applicability of existing Generalized
Multiprotocol Label Switching (GMPLS) protocols and mechanisms to
Layer 1 Virtual Private Networks (L1VPNs). In addition, this document
identifies several areas where additional protocol extensions or
modifications are needed to meet L1VPN service requirements.
In particular, this document shows section by section (from section 5
to 7) the applicability of GMPLS protocols and mechanisms to each
L1VPN service model mentioned in [L1VPN-FW], along with additional
work areas needed to fully support the requirements for each service
model. Note that management aspects, some of which are common over
various service models, are described separately in section 8.
Additional information regarding network usage of L1VPN service
models is provided in the appendix.
T.Takeda, et al. Expires August 2005 [Page 4]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
Note that discussion in this document is limited to areas where GMPLS
protocols and mechanisms are relevant.
As will be described in this document, support of management-based
service model, signaling-based service model and virtual node
service model are well covered by existing documents, with minor
extensions. Virtual link service model and per VPN peer service
model are not explicitly covered by existing documents, but can be
realized by extending current GMPLS protocols and mechanisms.
Also, as will be described, the following are possible work areas
where additional work would be required to fully support the
requirements for each L1VPN service model. Some of the requirements
are optional therefore the additional work is also optional. Also,
some items below may have more than one existing mechanism (with
possible extensions). For those items, choosing the minimum set of
mechanisms is the required additional work.
Commonalities of mechanisms over various service models should be
considered. Also, various mechanisms should be coordinated in such a
way that services are provided in a fully functional manner.
This list of additional work areas will be updated in later versions
of this document along with the development of the additional or
enhanced requirements and increased understanding of the issues.
o MIB module for SPC
o Resource management per VPN
o Signaling mechanisms
o VPN membership information exchange
o CE-PE TE link information exchange
o Routing representation (how a VPN should be represented in routing,
e.g., single area, multi area, multi AS)
o Control plane routing (routing information exchange related to
control plane topology, per VPN control packet routing)
o Signaling and routing for support of per VPN peer service model
o Management aspect (fault management, configuration management,
security management)
A MIB module for possible protocol extensions will also need to be
studied.
3.1 Existing Solutions Drafts
There are two existing solutions documents that describe how L1VPNs
may be constructed using the mechanisms of GMPLS. This document draws
on those solutions and explains their applicability and suggests
further extensions to make the solutions more closely match the
T.Takeda, et al. Expires August 2005 [Page 5]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
framework described in [L1VPN-FW].
o [GVPN] 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 [GMPLS-UNI] addresses the application of GMPLS to the overlay
model. In one section, the document provides a description of how
the overlay model may be used to support VPN connections across a
core GMPLS network.
4. General Guideline
This section provides general guidelines for L1VPN solutions.
Note applicability to specific service models will be separately
described in following sections.
One important general guideline is that solutions should be
incremental. In other words, the same mechanisms should be maximally
reused in various service models, and as service models vary and
additional functionalities are required, delta functionalities should
be added. For example, it is highly desirable that the same signaling
protocols are used in both the signaling-based model and the
signaling and routing service model, and routing functions are added
or enhanced from signaling-based service model to signaling and
routing service model.
In addition, the following are general guidelines.
- Both P and CE devices should be able to use (in most cases) vanilla
GMPLS protocols with no specific L1VPN extensions. If Ps and CEs
need to be extended for L1VPNs, then backward compatibility should
be considered. Details of backward compatibility are for further
study.
- Solutions should be scalable and manageable (it is desirable that
solutions should not require L1VPN state to be maintained on the
Ps)
- Solutions should be secure. (i.e., providers should be able to
screen and protect information based on their operational
policies.)
- Highly desirable for solutions to provide for the customer and
provider a common operational and management perspective in regard
to other VPN services, L2 and L3.
Note that some deployments may wish to support multiple L1 connection
types (such as VC3, VC4, etc.) at the same time. Specific
functionalities may need to be considered for these scenarios. This
is for further study.
T.Takeda, et al. Expires August 2005 [Page 6]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
5. Applicability to Management-based Service Model
5.1. Overview of the Service Model
The customer and the provider communicate via a management interface.
The provider management system(s) communicate with the PE/P to set up
a connection.
5.2. Applicability of Existing Solutions
SNMP MIB modules are one way to realize connection
setup/deletion/modification from the management system(s). In
particular, GMPLS-LSR-STD-MIB [LSR MIB] can control static
connections, while GMPLS-TE-STD-MIB [TE MIB] can control signaled
connections.
As indicated in [L1VPN-FW], the specification of interface(s)
between management system(s) (i.e. customer and provider) is out of
the scope of this document.
5.3. Additional Work Area(s)
The following additional work areas are identified to support the
Management-based Service Model.
o MIB module for SPC (Soft Permanent Connection)
For static connections, there is no required extension to the MIB
modules.
For signaled connections, MIB modules should be able to
inform the ingress and egress PEs which CE-PE TE link should be
used. For the egress side, egress control [EGRESS-CONTROL] can be
used. For the ingress side, there are two alternatives to do this.
Option1: MIB module extension
Define a new MIB object to specify the ingress CE-PE TE link to
be used.
Option2: MIB object usage extension
Use the current MIB objects, but extend the way to use them.
There are two possible ways to do this.
(1) Set mplsTunnelIngressLSRId in mplsTunnelTable, which
corresponds to Tunnel Sender Address in the Sender Template
object of RSVP-TE, to the CE-PE TE link address.
T.Takeda, et al. Expires August 2005 [Page 7]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
(2) Set mplsTunnelHopIpAddr of the first MplsTunnelHopEntry in
mplsTunnelHopTable, which corresponds to the first element
of ERO of RSVP-TE, to the CE-PE TE link address. It may
require to define a new mplsTunnelHopAddrType in
mplsTunnelHopTable, which corresponds to a new ERO
subobject, in order to give precise meaning.
Detailed analysis of option 1 and 2 is for further study.
o Resource management per VPN
In this type of service model, one optional requirement is resource
management for a dedicated Data-Plane (the provider network
partitions link resources per VPN for exclusive use by a particular
VPN), and resource management for sharing the Data-Plane among a
specific set of VPNs (the provider network assigns link resources
to a specific set of VPNs).
There are two alternatives to do this.
Option 1: Policy
A simple way to meet this requirement is to implement resource
management functionalities as a policy solely in the entity that
computes a path. Therefore, no protocol extension is needed.
This scheme is especially effective when path computation is
done in a centralized manner (e.g., in the management
system(s)).
Option 2: Routing extension
The other alternative is to extend the routing protocol to
specify the amount of resources available to each VPN. In this
scheme, the PE/P can compute a path in a distributed way, thus
this scheme is especially beneficial in the case of dynamic
restoration (restoration that does not reserve backup resources
in advance).
Note that link coloring may be used for this purpose, but this
eliminates the opportunity to use link coloring for other
purposes (e.g., link coloring within VPNs).
Detailed analysis of option 1 and 2 is for further study.
o Other considerations
When path computation is done in a centralized entity (e.g.,
management system(s)), it is important that resource information is
synchronized between such an entity and the PE/P.
T.Takeda, et al. Expires August 2005 [Page 8]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
6. Applicability to Signaling-based Service Model (Overlay Service
Model)
6.1. Overview of the Service Model
In this type of service model, there is no routing between the CE
and the PE. Connections are setup by GMPLS signaling between the CE
and the PE, and then across the provider network.
A CE may optionally receive a list of TE link addresses to which it
can request a VPN connection (overlay extension).
6.2. Applicability of Existing Solutions
The following are required in this service model.
- VPN membership information exchange: CE-PE TE link address exchange
between PEs, along with information associated with a VPN. The TE
link addresses may be customer assigned private addresses.
- Signaling: CE-CE LSP setup/deletion/modification
- Others: Resource management per VPN etc.
Additionally, VPN membership information exchange between a CE and PE
is required for overlay extension.
[GVPN] and [GMPLS-UNI] cover most of the requirements.
Specifically, [GVPN] covers VPN membership information exchange by
BGP. Customer assigned private addresses are exchanged along with a
provider network address (which is reachable in the provider
network's routing) and an ID associated with a VPN (i.e., Route
Target). This allows PEs to perform address translation/mapping and
connectivity restriction.
In addition, [GVPN] and [GMPLS-UNI] suggest two signaling mechanisms
for VPN connections.
o Shuffling [GVPN]
Information carried in RSVP messages identifying a LSP (i.e.
SESSION and SENDER_TEMPLATE objects) is translated by the ingress
and egress PE. There is one end-to-end session (i.e., CE-to-CE).
o Nesting [GVPN][GMPLS-UNI][LSP HIER]
When Path message arrives at the ingress PE, the ingress PE checks
whether there is appropriate PE-to-PE connectivity. If there is
not, it initiates a PE-to-PE FA-LSP. On top of this FA-LSP,
T.Takeda, et al. Expires August 2005 [Page 9]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
CE-to-CE LSP is set up. There are two sessions (i.e., CE-to-CE,
and PE-to-PE).
LSP stitching is a particular case of LSP nesting where the
properties of LSP segment are such that exactly one end-to-end LSP
can be stitched with the LSP segment i.e. the PE-to-PE LSP and the
CE-to-CE LSP correspond exactly one to one [STITCHING].
Finally, [GVPN] covers the requirement to exchange membership
information between the CE and the PE by BGP for overlay extension.
The other possibility is to use IGP based VPN membership information
exchange (e.g., similar to as an AS external route, or based on
[OSPF-NODE-ADDR], with extensions for VPN applications). This
requires the implementation of such IGP.
6.3. Additional Work Area(s)
The following additional work areas are identified to support the
Signaling-based Service Model.
o Signaling mechanisms
As described in section 6.1.2, [GMPLS-UNI] and [GVPN] suggest
two signaling mechanisms for VPN connections.
Option 1: Shuffling
In this mechanism, there is no need to set up a PE-to-PE FA-LSP.
Though, for this option, objects need to be translated at the
ingress and egress PEs.
Option 2: Nesting
In this mechanism, there is a need to set up a PE-to-PE FA-LSP.
For this option, objects need not be translated at the ingress
and egress PEs.
In the case of nesting, it is necessary to specify an addressing
space to exchange signaling messages directly between PEs (i.e.,
provider addressing space or VPN addressing space). Associated
mechanisms may need to be specified as well.
Detailed analysis, including under which condition signaling
mechanisms (shuffling or nesting) should be used, is for further
study.
o VPN membership information exchange
T.Takeda, et al. Expires August 2005 [Page 10]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
As described in section 6.2, there are two existing mechanisms
based on which VPN membership information exchange is realized.
Option 1: BGP-based
[GVPN] specifies a BGP-based mechanism to realize VPN membership
information exchange. There is no additional work required,
except for detailed specification of format and encoding.
Option 2: IGP-based
OSPF allows AS external routes to be advertised. In addition,
[OSPF-NODE-ADDR] extends OSPF-TE to advertise a router's local
addresses. These mechanisms can be used to advertise CE-PE TE
link addresses. In order to support customer assigned private
addresses and connectivity restrictions, this mechanism needs to
be extended to exchange information similar to an RT (Route
Target) and possibly an RD (Route Distinguisher), along with
CE-PE TE link addresses.
Detailed analysis of options 1 and 2 is for further study.
o Resource management per VPN
See section 5.2. Note that in option 1 of section 5.2, when path
computation is done in a separate entity, the interface for PCE
(Path Computation Element) [PCE ARCH] needs to be extended for VPN
applications.
o CE-PE TE link information exchange
In Signaling-based Service Model, it may be useful to consider not
only TE link information within the provider network (PE-P, PE-PE
TE links), but also remote CE-PE TE link information in path
computation. This prevents connection setup failure due to lack of
resources of remote CE-PE TE links. Therefore, CE-PE TE link
information should be optionally propagated within the provider
network to be used for path computation.
There are three alternatives for this.
Option1: BGP-based
[GVPN] describes potential use of BGP for exchanging CE-PE TE
link information. Detailed protocol specifications are needed as
additional work.
Option 2: IGP-based
T.Takeda, et al. Expires August 2005 [Page 11]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
The other alternative is to use IGP to advertise CE-PE TE
links. Since a CE does not participate in routing protocol
exchange with the provider network, TE link information must be
properly constructed by only a PE advertising CE-PE TE link
information.
Option 3: LMP
LMP [LMP] can be used to exchange CE-PE TE link information
between PEs, with appropriate extensions.
Detailed analysis of options 1, 2 and 3 is for further study.
o Other considerations
Note, there could be a L1VPN solution where connectivity
restriction, address translation/mapping etc. are performed not in
PEs, but in other entities, such as a centralized server. In this
case, the interface between the PE and the other entity may need to
be specified. This could utilize existing mechanisms such as COPS
or LDAP.
Also note that [GVPN] assumes that, on a PE and a CE, control
channels are separate for each VPN (i.e., a CE-PE control channel
is not shared by multiple VPNs).
7. Applicability to Signaling and Routing Service Model
7.1. Virtual Node Service Model
7.1.1. Overview of the Service Model
In this type of service model, there is private routing between the
CE and the PE, or to be more precise between the CE routing protocol
and the VPN routing protocol instance running on the PE. The provider
network is considered as one private node from the customer's
perspective. The routing information exchanged between the CE and the
PE includes CE-PE TE link information, CE sites, and may include
FA-LSPs (connections between CEs (or Cs)), CE sites routing
information related to control plane topology.
7.1.2. Applicability of Existing Solutions
The followings are required in this service model.
- VPN routing:
- Signaling: CE-CE LSP setup/deletion modification
- Others: Resource management per VPN etc.
T.Takeda, et al. Expires August 2005 [Page 12]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
[GVPN] covers most of the requirements.
Specifically, [GVPN]
handles VPN routing by a per VPN database called the GVSI
(Generalized Virtual Switching Instance) in PEs. GVSIs are inter-
connected by tunnel based control channels, and routing adjacencies
are established between them. BGP is used for auto-discovery of
remote GVSI (VPN auto-discovery) in the same VPN. GVSIs advertise VPN
routing information by using the same ROUTER_ID to represent the
provider network as one node.
In addition, [GVPN] supports signaling by nested signaling (as in the
case of the Signaling-based Service Model).
There are other ways to realize VPN auto-discovery. One such way is
to use an IGP-based mechanism (e.g., based on [OSPF-CAP] or
[OSPF-NODE-ADDR] with extensions). Other possibilities are to use a
server based approach (e.g., DNS, based on [DNS DISCOVERY], RADIUS,
based on [RADIUS DISCOVERY]) and multicast (e.g., based on
[RFC2917]).
7.1.3. Additional Work Area(s)
The following additional work areas are identified to support the
Virtual Node Service Model.
o Routing representation
In the Virtual Node Service Model, one item that should be
considered is how to represent a VPN in routing (e.g., single IGP
area, multiple IGP areas, multiple ASes). Depending on the routing
representation, details may differ (e.g., use of auto-discovery).
This requires further discussion.
o Resource management per VPN
See section 6.1.3
o Control plane routing
The provider network must be carefully designed whether to allow
routing information related to control plane topology of the
provider network to be leaked to the CE. If routing information
related to control plane topology of the provider network is leaked
to the CE, this routing information may need to be assigned private
addresses.
When the provider network supports routing information related to
control plane topology of CE sites to be exchanged between the CE
T.Takeda, et al. Expires August 2005 [Page 13]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
and the PE, and allows control packets to be transferred between CE
sites (e.g., BGP packets), the provider network must be carefully
designed how to route per VPN control packets received from the CE.
7.2. Virtual Link Service Model
7.2.1. Overview of the Service Model
In this type of service model, virtual links are established between
PEs. The routing information exchanged between the CE and the PE
includes CE-PE TE link, CE sites, virtual links, and may include
FA-LSP and CE sites routing information related to control plane
topology.
7.2.2. Applicability of Existing Solutions
Currently, there is no solution document for this type of service
model. However, simple modifications of [GVPN], in addition to
enhancements mentioned in section 7.1.3, may realize this type of
service model. Modifications could be:
- Do NOT modify the ROUTE_ID of the TE link information when
advertising a CE-PE TE link to the CE (in the OSPF packet header as
well as in the LSA header)
- Set up FA-LSPs (GVSI-LSPs in [GVPN] terms) between PEs to construct
virtual links, and advertise these FA-LSPs in VPN routing. Note
these FA-LSPs (virtual links) may be assigned private addresses,
which means customer assigned addresses (or that customers are
allowed to configure addresses). This may require extension to
current IGP behavior.
Note there could be other ways to construct virtual links (e.g.,
virtual links without actually setting up a FA-LSP [MRN REQ]).
7.2.3. Additional Work Area(s)
There is no additional work area beyond the already identified work
area for the Virtual Node Service Model mentioned in section 7.1.3.
Note that resource management for a dedicated Data-Plane is a
mandatory requirement for Virtual Link Service Model. This could be
realized by assigning pre-configured FA-LSPs to each VPN routing
protocol instance (no protocol extensions needed).
Note as in the case of Virtual Node Service Model, depending on
routing representation, details may differ. This requires further
discussion.
7.3. Per VPN Peer Service Model
T.Takeda, et al. Expires August 2005 [Page 14]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
7.3.1. Overview of the Service Model
In this type of service model, the provider partitions TE links
within the provider network per VPN. The routing information
exchanged between the CE and the PE includes CE-PE TE links, CE
sites, as well as partitioned portions of the provider network, and
may include FA-LSPs and CE sites routing information related to
control plane topology. Note that PEs may advertise abstracted
routing information of the provider network to CEs.
Note scalability must be carefully considered for advertising
provider network routing information to the CE [INTER-DOMAIN FW].
7.3.2. Applicability of Existing Solutions
Currently, there is no solution document for this type of service
model. However, [GVPN] provides several functionalities to meet
this type of service model, as described in section 7.1.2. One way is
to extend mechanisms for the Virtual Node Service Model. The other
way is to extend mechanisms for the Virtual Link Service Model.
7.3.3. Additional Work Area(s)
As described in section 7.3.2, there are two approaches for this type
of service model.
Note as in the case of Virtual Node Service Mode, depending on
routing construction, details may differ. This requires further
discussion.
o Signaling and routing for support of per VPN peer service model.
Option 1: Virtual node-based
Per VPN Peer Service Model may be realized by extending virtual
node technique so that PEs selectively advertise provider
internal TE links to CEs. There are several extensions needed for
this.
- Topology filtering
The PE must choose TE links that are assigned to a specific VPN,
and then advertise these TE links to a specific set of CEs
corresponding to that VPN.
- Topology abstraction
The PE may abstract routing information of the provider network,
T.Takeda, et al. Expires August 2005 [Page 15]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
and then advertise abstracted topology information to the CE. It
means that the PE may construct a TE link where a direct physical
link does not exit, or the PE may construct a single node to
represent multiple nodes and TE links.
Note scalability must be carefully considered [INTER-DOMAIN FW].
- ERO/RRO expansion/modification
The CE may specify ERO with abstracted topology. The provider
network must expand this ERO to match the provider network
topology. Note this must be done even if strict route is
specified in ERO passed from the CE.
At the same time, when RRO is requested, the RRO passed to the CE
must be either edited to match the abstracted topology, or
removed.
- Private address
The provider network may support private addresses for routing
information provided to the customer. This means that the
customer is able to assign private addresses to a partitioned
portion of the TE links within the provider network.
o Option 2: Virtual link-based
Per VPN Peer Service Model may be realized by extending virtual
link technique so that not only PEs but also Ps, that contain end
point of virtual links in the abstracted topology, contain VPN
routing instance. There may be no additional protocol extensions
needed from the Virtual Link Service Model.
Detailed analysis of options 1 and 2 is for further study.
8. Management Aspect
8.1. Fault Management
The provider network may support various recovery techniques
mentioned in [P&R TERM]. The customer may be allowed to specify the
desired level of recovery in connection setup requests. The provider
network may constitute a recovery domain (PE-PE recovery).
Following aspects need to be considered relative to L1VPNs.
o Shared recovery
When the provider network supports shared recovery (e.g., shared
T.Takeda, et al. Expires August 2005 [Page 16]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
mesh restoration), the provider network may be able to support
shared recovery only within the same VPN and/or shared recovery
among multiple VPNs. The default mode is to be specified.
If the provider network supports both, the provider network must
provide configuration tools for operators.
o Extra traffic
GMPLS recovery mechanisms support extra traffic. Extra traffic
allows supporting pre-emptible traffic on recovery resources when
these resources are not being used for the recovery of normal
traffic [P&R TERM].
When the provider network supports extra traffic, the provider
network may be able to support extra traffic only within the same
VPN and/or extra traffic among multiple VPNs. The default mode is
to be specified.
If the provider network supports both, the provider network must
provide configuration tools for operators.
8.2. Configuration Management
Some VPN specific configuration aspects must be considered, such as:
o Configuration of resource management per VPN
Physical link resources may be dedicated, shared by a specific set
of VPNs, or shared by any VPNs. The provider network must provide
configuration tools for resource management per VPN.
o Configuration of virtual links
For virtual link service model and per VPN peer service model,
the provider network must provide configuration tools for
operators.
o Configuration of service model for each VPN
When the provider network supports multiple service models, the
provider network must provide configuration tools for operators.
8.3. Security Management
o CE-PE security
When a CE-PE control channel is physically shared by multiple VPNs,
security mechanisms need to be applied for data integrity and
T.Takeda, et al. Expires August 2005 [Page 17]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
confidentiality of control messages exchanged. Furthermore, when a
CE-PE control channel is dynamically setup, authentication need to
be performed. The mechanisms to achieve these include IPsec.
Details for additional work areas are for further study.
9. Discussion
This section summarizes items for which existing solutions may need
to be extended in order to fulfill the full set of L1VPN service
model functionalities.
Note that several of these items are in support of optional features.
For the management-based service model, signaling-based service model
and virtual node service model, the existing solutions can be applied
with few extensions.
As described in section 7.2.2 and 7.2.3, there are no existing
solutions to support the virtual link service model and per VPN peer
service model. For virtual link service model, however, minor
extensions from existing solutions are expected to meet the
requirements.
Note the list of additional work areas will be updated in later
versions of this document with the development of additional or
enhanced requirements and understanding of the issues.
o MIB module for SPC
- Optional, but highly required for management-based service model
- Two alternatives (MIB module extension or MIB object usage
extension)
- Impact: MIB module or none
o Resource management per VPN
- Optional requirement for management-based, signaling-based and
virtual node service models
- Mandatory requirement for virtual link and per VPN peer service
models (support of resource management for dedicated Data-Plane)
- Two alternatives (policy or routing extension)
- For virtual link service model, can be realized by no protocol
extensions (assign pre-configured FA-LSP to each VPN routing
instance).
- Impact: None or IGP
o Signaling mechanisms
- Mandatory requirement for signaling-based service model and
signaling and routing service model
- Two alternatives (shuffling or nesting)
- Impact: Signaling
T.Takeda, et al. Expires August 2005 [Page 18]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
o VPN membership information exchange
- Mandatory requirement for signaling-based service model
- Two alternatives (BGP or IGP)
- Impact: BGP or IGP
o CE-PE TE link information exchange
- Optional requirement for signaling-based service model
- Three alternatives (BGP or IGP or LMP)
- Impact: BGP or IGP or LMP
o Routing representation
- One building block for signaling and routing service model
- Further discussion required (single area, multi areas, multi
ASes, etc.)
- Impact: Details to be studied (routing, use of auto-discovery,
etc.)
o Control plane routing
- Optional requirement for signaling and routing service model
- Impact: Routing
o Signaling and routing for support of per VPN peer service model
- Two options (virtual node-based, virtual link-based)
- Impact: Routing, signaling (details to be studied)
o Management aspects
- Default mode to be specified for shared recovery and extra
traffic
- Support of configuration tools mandatory for fault management and
configuration management
- Details for security management to be studied
- Impact: mostly on operational tools (impacts on protocols to be
studied)
10. Security Considerations
Section 8.3 describes some of security considerations. Details are
for further study.
11. IANA Considerations
TBD
12. Acknowledgement
We would like to thank Marco Carugi, Ichiro Inoue and Takumi Ohba for
their useful comments and suggestions.
13. Normative References
T.Takeda, et al. Expires August 2005 [Page 19]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[L1VPN-FW] Takeda, T., Editor "Framework for Layer 1 Virtual
Private Networks", draft-takeda-l1vpn-framework,
work in progress.
14. 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
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.
[GMPLS-UNI] Swallow, G., et al., "Generalize Multiprotocol
Label Switching(GMPLS) User-Network Interface
(UNI): Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Support for the Overlay
Model", draft-ietf-ccamp-gmpls-overlay, 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.
[LSP HIER] Kompella, K., Rekhter, Y., "LSP Hierarchy with
Generalized MPLS TE", draft-ietf-mpls-lsp-
hierarchy, work in progress.
[STITCHING] Ayyangar, A. (editor), "LSP Stitching with
Generalized MPLS TE", draft-ayyangar-ccamp-lsp-
stitching, work in progress.
[INTER-DOMAIN FW] Farrel, A., et al., "A Framework for Inter-Domain
MPLS Traffic Engineering", draft-ietf-ccamp-
inter-domain-framework, work in progress.
[P&R TERM] Mannie, E., and Papadimitriou, D. (editors),
T.Takeda, et al. Expires August 2005 [Page 20]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
"Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)", draft-ietf-ccamp-gmpls-recovery-
terminology, work in progress.
[LSR MIB] Nadeau, T., et al., "Generalized Multiprotocol
Label Switching (GMPLS) Label Switching Router
(LSR) Management Information Base", draft-ietf-
ccamp-gmpls-lsr-mib, work in progress.
[TE MIB] Nadeau, T., et al., "Generalized Multiprotocol
Label Switching (GMPLS) Traffic Engineering
Management Information Base", draft-ietf-ccamp-
gmpls-te-mib, work in progress.
[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-RTG] Kompella, K., et al., "Routing Extensions in
Support of Generalized MPLS", draft-ietf-ccamp-
gmpls-routing, work in progress.
[EGRESS CONTROL] Berger, L., "GMPLS Signaling Procedure For Egress
Control", draft-ietf-ccamp-gmpls-egress-control,
work in progress.
[OSPF-CAP] Vesseur, J.P., et al., "Extensions to OSPF for
Advertising Optional Router Capabilities",
draft-ietf-ospf-cap, work in progress.
[OSPF-NODE-ADDR] Aggarwal, R., Kompella, K., "Advertising a
Router's Local Addresses in OSPF TE Extensions",
draft-ietf-ospf-te-node-addr, work in progress.
T.Takeda, et al. Expires August 2005 [Page 21]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
[LMP] Lang, J., "Link Management Protocol (LMP)",
draft-ietf-ccamp-lmp, work in progress.
[DNS DISCOVERY] Squire, M., et al., "Using DNS for VPN Discovery",
draft-luciani-ppvpn-vpn-discovery (Expired).
[RADIUS DISCOVERY] Weber, G., Editor "Using RADIUS for PE-Based VPN
Discovery", draft-ietf-l2vpn-radius-pe-discovery
(Expired).
[RFC2917] Muthukrishnan, K., Malis, A., " A Core MPLS IP VPN
Architecture", RFC2917, September 2000.
[PPVPN-TERM] Andersson, L., and Madsen, T., "Provider
Provisioned VPN terminology",
draft-ietf-l3vpn-ppvpn-terminology, work in
progress.
[PCE ARCH] Ash, J., et al., "Path Computation Element (PCE)
Architecture", draft-ash-pce-architecture, work in
progress.
[MRN REQ] Shiomoto, K., et al., "Requirements for GMPLS-
based multi-region and multi-layer networks",
draft-shiomoto-ccamp-gmpls-mrn-reqs, work in
progress.
15. Authors' Addresses
Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 4201573
Email: dbrungard@att.com
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
Email: adrian@olddog.co.uk
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
Dimitri Papadimitriou (Alcatel)
Francis Wellensplein 1,
T.Takeda, et al. Expires August 2005 [Page 22]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
B-2018 Antwerpen, Belgium
Phone: +32 3 2408491
Email: dimitri.papadimitriou@alcatel.be
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
Appendix I: Network Usage of L1VPN Service Models
This appendix provides additional information concerning network
usage of the L1VPN service models.
o Management-based service model
In this model, the provider network can support non-GMPLS capable
CEs. Therefore, this model is best suited when customer networks
are non-GMPLS, e.g., legacy SONET/SDH and IP/MPLS networks.
It is expected that the provider network requires no or minimal
GMPLS extensions for L1VPN specific functions.
o Signaling-based service model
In this model, by implementing GMPLS signaling functions in CEs,
the customer can request an LSP setup/deletion/modification to the
provider by signaling. Customers will receive rapid failure
notifications of an LSP by using notification mechanisms available
in GMPLS RSVP-TE.
There are some L1VPN specific extensions required within the
provider network. Concerning customer network routing information,
since only CE-PE TE link addresses are contained within the
provider network, it is expected that there is less concern on
scalability. Trust relationships between the customer and the
provider may need to be carefully considered.
o Signaling and routing service model
In this model, a customer can seamlessly operate its VPN using
end-to-end GMPLS. Therefore, this model is best suited when
customer networks are operated by GMPLS.
For the service model where the provider network's routing
information is not provided to customers (i.e., Virtual Node
Service Model), a customer can outsource routing complexity within
T.Takeda, et al. Expires August 2005 [Page 23]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
the provider network to the provider. On the other hand, in the
service model where the provider network routing information is
provided to customers (i.e., Virtual Link Service Model and Per VPN
Peer Service Model), customers play more of a role. For example, by
allowing customers to assign SRLG IDs for virtual links, customers
can compute and set up end to end disjoint LSPs in their VPN.
There are some L1VPN specific extensions required within the
provider network. Concerning customer network routing information,
since the customer network routing information is contained within
the provider network, scalability must be carefully considered.
Trust relationships between the customer and the provider may need
to be carefully considered as well.
Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; 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.
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
T.Takeda, et al. Expires August 2005 [Page 24]
Internet Draft draft-takeda-l1vpn-applicability-02.txt February 2005
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 25]| PAFTECH AB 2003-2026 | 2026-04-24 01:32:22 |