One document matched: draft-takeda-l1vpn-applicability-00.txt
Network Working Group Tomonori Takeda (Editor)
Internet Draft NTT
Proposed Status: Informational
Expires: January 2005 July 2004
Applicability of GMPLS protocols and architectures
to Layer 1 Virtual Private Networks
draft-takeda-l1vpn-applicability-00.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.
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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document provides materials to show how existing Generalized
Multiprotocol Label Switching (GMPLS) protocols and architectures,
and current proposals for modifications to those protocols and
architectures can be used to satisfy the requirements of Layer 1
Virtual Private Networks (L1VPNs).
In addition, this document identifies any areas where additional
protocol extensions or procedures are necessary so that GMPLS
T.Takeda, et al. Expires January 2005 [Page 1]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
protocols can be used to satisfy the requirements of L1VPNs, and sets
guidelines for possible solution work.
0. Summary
(This section to be removed before publication as an RFC.)
0.1. Summary
This document shows applicability of existing GMPLS protocols and
architectures to L1VPNs. In addition, this document identifies several
items where additional protocol extensions are necessary to meet the
full set of L1VPN services.
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
L1VPN mailing list is setup to discuss issues related to L1VPNs. This
document is intended to progress the work by showing applicability of
existing documents (in 0.4), as well to identify several items where
additional work is required.
0.4. Related Internet Documents
The present draft discusses applicability of existing solutions drafts
below to L1VPN service requirements mentioned in the following draft.
o draft-takeda-l1vpn-framework-00.txt (Feb 2004)
"Framework for Layer 1 Virtual Private Networks"
This draft examines motivations for L1VPNs, high level (service
level) requirements, and outlines some of the architectural models
that might be used to build L1VPNs.
Note this document is based heavily on the work of ITU-T Study
Group 13 Question 11.
This draft mainly discusses applicability of following solution
drafts to L1VPN service requirements mentioned in the above draft.
o draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-05.txt (May 2004)
"GVPN Services: Generalized VPN Services using BGP and GMPLS
T.Takeda, et al. Expires January 2005 [Page 2]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
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-04.txt (April 2004)
"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
model may be used to support VPN connections across a core GMPLS
network.
Contents
1. Contributors ............................................. 4
2. Terminology .............................................. 4
3. Introduction ............................................. 4
4. General Guideline ........................................ 5
5. Applicability to Management-based Service Models ......... 5
5.1. Overview of the Service Models ........................... 6
5.2. Applicability of Existing Solutions ...................... 6
5.3. Additional Work Area(s) .................................. 6
6. Applicability to Signaling-based Service Models .......... 7
6.1. Overlay Service Models ................................... 7
6.1.1. Overview of the Service Models ........................... 7
6.1.2. Applicability of Existing Solutions ...................... 7
6.1.3. Additional Work Area(s) .................................. 7
6.2. Overlay Extension Service Models ......................... 8
6.2.1. Overview of the Service Models ........................... 8
6.2.2. Applicability of Existing Solutions ...................... 8
6.2.3. Additional Work Area(s) .................................. 9
7. Applicability to Signaling and Routing Service Models .... 9
7.1. Virtual Node Service Models .............................. 9
7.1.1. Overview of the Service Models ........................... 9
7.1.2. Applicability of Existing Solutions ...................... 9
7.1.3. Additional Work Area(s) .................................. 9
7.2. Virtual Link Service Models .............................. 10
7.2.1. Overview of the Service Models ........................... 10
7.2.2. Applicability of Existing Solutions ...................... 10
7.2.3. Additional Work Area(s) .................................. 10
7.3. Per VPN Peer Service Models .............................. 10
7.3.1. Overview of the Service Models ........................... 11
7.3.2. Applicability of Existing Solutions ...................... 11
7.3.3. Additional Work Area(s) .................................. 11
8. Management Aspect ........................................ 12
8.1. Fault Management ......................................... 12
8.2. Configuration Management ................................. 13
9. Discussion ............................................... 13
10. Security Considerations .................................. 14
11. IANA Considerations ...................................... 14
12. Acknowledgement .......................................... 14
T.Takeda, et al. Expires January 2005 [Page 3]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
13. Normative References ..................................... 14
14. Informative References ................................... 14
15. Authors' Addresses ....................................... 16
16. Intellectual Property Considerations ..................... 17
17. Full Copyright Statement ................................. 17
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.
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 architectures to
Layer 1 Virtual Private Networks (L1VPNs). In addition, this document
identifies several items where additional protocol extensions or
modifications are necessary to meet L1VPN services.
In particular, this document shows section by section (from section 5
to 7) the applicability of GMPLS protocols and architectures 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 management aspects some of which are common over various
service models will be described separately in section 8.
Note that discussion in this document is limited to areas where GMPLS
protocols and architectures are relevant.
As will be described in detail in this document, support of
management-based service models, signaling-based service models and
virtual node service models are well covered by existing documents,
with minor extensions. Virtual link service models and per VPN peer
service models are not explicitly covered by existing documents, but
would be well realized by extending current GMPLS protocols and
architectures.
Also, as will be described in detail, the following are possible work
T.Takeda, et al. Expires January 2005 [Page 4]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
areas where additional work would be required to fully support the
requirements for each L1VPN service model. Some of the requirements
are optional meaning that the additional work is also optional. The
list of additional work areas will be updated in later versions of
this document along with development of the additional or enhanced
requirements and increased understanding of the issues.
o MIB module for SPC
o Resource management per VPN
o Tunnel mechanisms
o CE-PE TE link information
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 models
o Management aspect (fault management, configuration management)
A MIB module for possible protocol extensions will also need to be
studied.
4. General Guideline
This section provides several general guidelines for L1VPN solutions.
In other words, this section provides general requirements that any
solution for any service model should consider. 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, in signaling-based service models and
signaling and routing service models, it is highly desirable that the
same signaling protocols are used, and routing
functions are added or enhanced from signaling-based service models
to signaling and routing service models.
In addition, the following are general guidelines.
- Solutions should consider interoperability with non-VPN devices
(devices that do not support any specific L1VPN extension).
- Solutions should be scalable and manageable.
- Solutions should be secure. (i.e., providers should be able to
screen and protect information based on their operational policies.)
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.
5. Applicability to Management-based Service Models
T.Takeda, et al. Expires January 2005 [Page 5]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
5.1. Overview of the Service Models
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) 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 Models.
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 may need to be extended to
inform the ingress PE which CE-PE TE link should be used.
Note that there are several other ways to control signaled
connections without MIB module extensions. One such way is:
(1) Use GMPLS-LSR-STD-MIB for CE-PE TE link and PE-P/PE TE link
cross-connect at the ingress PE
(2) Then use GMPLS-TE-STD-MIB to request signaling with egress
control [EGRESS-CONTROL]
However, this increases overhead in terms of message exchange and
required states. As an alternative, extension of MIB modules for
SPC is highly desirable.
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). Note in [L1VPN-FW], the term U-Plane is
T.Takeda, et al. Expires January 2005 [Page 6]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
generally used for Data-Plane.
A simple way to meet this requirement is to implement resource
management functionalities in the management system(s). However, if
the PE/P need path computation locally, not relying on the
management system(s), then support of resource management in PE/P
(e.g., routing protocol extension) is necessary. This is especially
beneficial in the case of dynamic restoration (restoration that does
not reserve backup resources in advance).
Note 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).
When path computation is done in the management system(s), it would
be important that resource information is synchronized between the
management system(s) and PE/P.
6. Applicability to Signaling-based Service Models
6.1. Overlay Service Models
6.1.1. Overview of the Service Models
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.
6.1.2. Applicability of Existing Solutions
[GVPN] and [GMPLS-UNI] cover most of the requirements.
Specifically, [GVPN] and [GMPLS-UNI] suggest signaling procedures for
VPN connections (i.e., nesting). In addition, [GVPN] covers auto-
discovery of VPN instances, and CE-PE pair address exchange between
PEs by BGP. This allows PEs to perform address translation/mapping and
connectivity restriction. [GVPN] calls the equivalent service model
GVPW (Generalized Virtual Private Wire).
The other possibility is to use IGP based node capability
advertisement for auto-discovery and CE-PE pair addresses exchange
(e.g., based on [OSPF-TE-CAP] with extensions). This requires
implementation of such IGP.
6.1.3. Additional Work Area(s)
The following additional work areas are identified to support the
Overlay Service Models.
o Resource management per VPN
T.Takeda, et al. Expires January 2005 [Page 7]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
This is an optional requirement.
Note there could be L1VPN solutions where path computation is
conducted in centralized fashion (e.g., in management system(s),
PCE). In this case, it is possible to implement resource
management functionalities solely in those entities. However,
implementing resource management functionality in PE/P is
beneficial in certain scenarios, especially in restoration. See
section 5.1.3 for related description.
o Tunnel mechanism
[GMPLS-UNI] and [GVPN] propose to use control plane tunnels between
PEs. In addition, [GVPN] proposes to use BGP for auto-discovery of
tunnel end points. However, [GMPLS-UNI] and [GVPN] do not specify a
specific tunnel mechanism for default. Since tunnel mechanisms are
strongly related to what information should be carried in auto-
discovery mechanisms, a default tunnel mechanism may need to be
specified. By doing this, required information to be exchanged by
auto-discovery mechanisms can be identified.
o CE-PE TE link information
In signaling-based service models, 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.
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 utilise existing mechanisms such as COPS or
LDAP.
Also note [GVPN] assumes that on a PE and a CE, control channels are
separate for each VPN (i.e., CE-PE control channel is not shared by
multiple VPNs).
6.2. Overlay Extension Service Models
6.2.1. Overview of the Service Models
Requirements for this type of service models are almost the same as
the ones for overlay service models. One additional requirement is
membership information exchange between the CE and the PE.
6.2.2. Applicability of Existing Solutions
T.Takeda, et al. Expires January 2005 [Page 8]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
[GVPN] covers the requirement to exchange membership information
between the CE and the PE by BGP.
6.2.3. Additional Work Area(s)
There is no additional work area beyond those identified for the
Overlay Service Models.
7. Applicability to Signaling and Routing Service Models
7.1. Virtual Node Service Models
7.1.1. Overview of the Service Models
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 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
[GVPN] covers most of requirements.
Specifically, [GVPN] handles VPN routing by a per VPN database called
GVSI (Generalized Virtual Switching Instance) in PEs. GVSIs are inter-
connected by tunnel based control channel, and routing adjacency is
established between them. BGP is used for auto-discovery of remote
GVSI in the same VPN. GVSIs advertise VPN routing information by
using the same ROUTER_ID to represent the provider network as one
node. [GVPN] calls the equivalent service model GVPXC (Generalized
Virtual Private Cross-Connect).
7.1.3. Additional Work Area(s)
The following additional work areas are identified to support the
Virtual Node Service Models.
o Tunnel mechanism
See section 6.1.3
o Resource management per VPN
See section 6.1.3
o Control plane routing
T.Takeda, et al. Expires January 2005 [Page 9]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
The provider network must carefully design 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
and the PE, and allows control packet transferring between CE sites
(e.g., BGP packets), the provider network must carefully design how
to route per VPN control packets received from the CE.
7.2. Virtual Link Service Models
7.2.1. Overview of the Service Models
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 ROUTE_ID of TE link information when advertising TE
link to the CE (in OSPF packet header as well as in LSA header)
- Setup FA-LSPs (GVSI-LSPs in [GVPN] term) 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 customers
are allowed to configure addresses). This may require extension
from current IGP behavior.
Note there could be other ways to construct virtual links (e.g.,
virtual link without actually setting up a FA-LSP).
7.2.3. Additional Work Area(s)
There is no additional work area from virtual node service models
mentioned in section 7.1.3. Note resource management for dedicated
Data-Plane is a mandatory requirement for virtual link service models.
7.3. Per VPN Peer Service Models
T.Takeda, et al. Expires January 2005 [Page 10]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
7.3.1. Overview of the Service Models
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. The
other possibility is to use virtual router based approach (virtual
routers (VPN instances) on every node which is the end point of at
least one virtual link) [VR].
7.3.3. Additional Work Area(s)
As described in section 7.3.2, it could be possible to realize this
service model by extending [GVPN] including following aspects, in
addition to aspects mentioned in section 7.1.3.
o 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.
o Topology abstraction
The PE may abstract routing information of the provider network,
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].
o 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.
T.Takeda, et al. Expires January 2005 [Page 11]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
At the same time, when RRO is requested, RRO passed to the CE must
be either edited to match the abstracted topology, or removed.
o Private address
The provider network may support private address for routing
information provided to the customer. This means that the customer
is able to assign private addresses to partitioned portion of TE
links within the provider network.
It would be also possible to realize this type of service models by
using virtual router based approach (i.e., every PE/P (or PE/P that
contains the end point of virtual links in abstracted topology)
containing virtual router (VPN instance) for each VPN).
Details for additional work areas for this type of service model are
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 able to specify the
desired level of recovery in connection setup requests. The provider
network may constitute a recovery domain (PE-PE recovery).
Following aspects must be considered particularly for L1VPNs.
o Shared recovery
When the provider network supports shared recovery (e.g., shared
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 supports functionalities called extra traffic. Extra traffic
is user traffic carried over 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
T.Takeda, et al. Expires January 2005 [Page 12]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
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, share 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 models and per VPN peer service models,
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.
9. Discussion
This section summarizes items that existing solutions may need to be
extended to fulfill full set of functionalities to realize various
L1VPN service models mentioned in sections 5 to 7.
Note that several items that existing solutions are missing are
optional features. For management-based service model, signaling-
based service models and virtual node service models, existing
solutions can be applied with few extensions for optional
requirements.
As described in section 7.2.2 and 7.2.3, there are no existing
solutions to support virtual link service models and per VPN peer
service models. For virtual link service models, 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 development of additional or enhanced
requirements and understanding of the issues.
o MIB module for SPC
- Optional, but highly required for management-based service models
- Impact: MIB module
o Resource management per VPN
- Optional requirement for management-based, signaling-based and
T.Takeda, et al. Expires January 2005 [Page 13]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
virtual node service models
- Mandatory requirement for virtual link and per VPN peer service
models (support of resource management for dedicated Data-Plane)
- Impact: Routing
o Tunnel mechanisms
- Optional requirement for signaling-based service models and
signaling and routing service models.
- Impact: Auto-discovery
o CE-PE TE link information
- Optional requirement for signaling-based service models
- Impact: Routing
o Control plane routing
- Optional requirement for signaling and routing service models
- Impact: Routing
o Signaling and routing for support of per VPN peer service models
- 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
- Impact: mostly on operational tools (impacts on protocols to be
studied)
10. Security Considerations
TBD
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
[RFC2026] Bradner, S., "The Internet Standards Process
-- Revision 3", RFC 2026, October 1996.
[L1VPN-FW] Takeda, T., Editor "Framework for Layer 1 Virtual
Private Networks", draft-takeda-l1vpn-framework,
work in progress.
14. Informative References
T.Takeda, et al. Expires January 2005 [Page 14]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
[Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic
requirements and architecture elements, ITU-T
Recommendation, September 2003.
[Y.1313] Y.l1vpnarch - Layer 1 Virtual Private Network
service and network architectures, ITU-T draft
Recommendation.
[GMPLS-UNI] Swallow, G., et al., "GMPLS UNI: RSVP 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.
[INTER-DOMAIN FW] Farrel, A., et al., "A Framework for Inter-Domain
MPLS Traffic Engineering", draft-farrel-ccamp-
inter-domain-framework, work in progress.
[P&R TERM] Mannie, E., and Papadimitriou, D. (editors),
"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.
T.Takeda, et al. Expires January 2005 [Page 15]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
[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-TE-CAP] Vesseur, J.P., et al., "OSPF MPLS Traffic
Engineering capabilities", draft-vasseur-ccamp-
ospf-te-caps, work in progress.
[PPVPN-TERM] Andersson, L., and Madsen, T., "PPVPN terminology",
draft-andersson-ppvpn-terminology, work in
progress.
[VR] Knight, P., Editor, ügNetwork based IP VPN
Architecture using Virtual Routersüh, draft-ietf-
l3vpn-vpn-vr, work in progress.
15. Authors' Addresses
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,
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
T.Takeda, et al. Expires January 2005 [Page 16]
Internet Draft draft-takeda-l1vpn-applicability-00.txt July 2004
16. 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.
17. 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 January 2005 [Page 17]| PAFTECH AB 2003-2026 | 2026-04-24 01:32:47 |