[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 RFC 5339
Network Working Group J.L. Le Roux (Ed.)
Internet Draft France Telecom
Category: Informational
Created: December 17, 2007 D. Papadimitriou (Ed.)
Expires: June 17, 2008 Alcatel-Lucent
Evaluation of existing GMPLS Protocols against Multi Layer
and Multi Region Networks (MLN/MRN)
draft-ietf-ccamp-gmpls-mln-eval-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 an evaluation of Generalized Multi-Protocol
Label Switching (GMPLS) protocols and mechanisms against the
requirements for Multi-Layer Networks (MLN) and Multi-Region Networks
(MRN). In addition, this document identifies areas where additional
protocol extensions or procedures are needed to satisfy these
requirements, and provides guidelines for potential extensions.
Le Roux et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 1]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction................................................3
2. MLN/MRN Requirements Overview...............................4
3. Analysis....................................................4
3.1. Multi Layer Network Aspects.................................4
3.1.1. Support for Virtual Network Topology Reconfiguration........4
3.1.1.1. Control of FA-LSPs Setup/Release..........................5
3.1.1.2. Virtual TE-Links..........................................6
3.1.1.3. Traffic Disruption Minimization During FA Release.........7
3.1.1.4. Stability.................................................8
3.1.2. Support for FA-LSP Attributes Inheritance...................8
3.1.3. FA-LSP Connectivity Verification............................8
3.2. Specific Aspects for Multi-Region Networks..................9
3.2.1. Support for Multi-Region Signaling..........................9
3.2.2. Advertisement of Adjustment Capacities......................9
4. Evaluation Conclusion......................................12
5. Security Considerations....................................13
6. IANA Considerations........................................13
7. Acknowledgments............................................13
8. References.................................................13
8.1. Normative References.......................................13
8.2. Informative References.....................................14
9. Editors' Addresses:........................................14
10. Contributors' Addresses:...................................15
11. Intellectual Property Statement............................15
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 2]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
1. Introduction
Generalized MPLS (GMPLS) extends MPLS to handle multiple switching
technologies: packet switching, layer-2 switching, TDM switching,
wavelength switching, and fiber switching (see [RFC3945]). The
Interface Switching Capability (ISC) concept is introduced for
these switching technologies and is designated as follows: PSC
(Packet Switch Capable), L2SC (Layer-2 Switch Capable), TDM (Time
Division Multiplex capable), LSC (Lambda Switch Capable), and FSC
(Fiber Switch Capable). The representation, in a GMPLS control
plane, of a switching technology domain is referred to as a region
[RFC4206]. A switching type describes the ability of a node to
forward data of a particular data plane technology, and uniquely
identifies a network region.
A data plane switching layer describes a data plane switching
granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are
three different layers. [MLN-REQ] defines a Multi Layer Network
(MLN) to be a TE domain comprising multiple data plane switching
layers either of the same ISC (e.g. TDM) or different ISC (e.g. TDM
and PSC) and controlled by a single GMPLS control plane instance.
[MLN-REQ] further define a particular case of MLNs. A Multi Region
Network (MRN) is defined as a TE domain supporting at least two
different switching types (e.g., PSC and TDM), either hosted on the
same device or on different ones, and under the control of a single
GMPLS control plane instance.
The objectives of this document are to evaluate existing GMPLS
mechanisms and protocols ([RFC3945], [RFC4202], [RFC3471],
[RFC3473]) against the requirements for MLN and MRN, defined in
[MLN-REQ]. From this evaluation, we identify several areas where
additional protocol extensions and modifications are required to meet
these requirements, and provide guidelines for potential extensions.
A summary of MLN/MRN requirements is provided in section 2. Then
section 3 evaluates for each of these requirements, whether current
GMPLS protocols and mechanisms meet the requirements. When the
requirements are not met by existing protocols, the document
identifies whether the required mechanisms could rely on GMPLS
protocols and procedure extensions or whether it is entirely out of
the scope of GMPLS protocols.
Note that this document specifically addresses GMPLS control plane
functionality for MLN/MRN in the context of a single administrative
control plane partition. Partitions of the control plane where
separate layers are under distinct administrative control are for
future study.
This document uses terminologies defined in [RFC3945], [RFC4206], and
[MLN-REQ].
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 3]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
2. MLN/MRN Requirements Overview
Section 5 of [MLN-REQ] lists a set of functional requirements for
Multi Layer/Region Networks (MLN/MRN). These requirements are
summarized below, and a mapping with sub-sections of [MLN-REQ] is
provided.
Here is the list of requirements that apply to MLN (and thus to MRN):
- Support for robust Virtual Network Topology (VNT) reconfiguration.
This implies the following requirements:
- Optimal control of Forwarding Adjacency LSP (FA-LSP) setup and
release (Section 5.8.1 of [MLN-REQ]);
- Support for virtual TE-links (Section 5.8.2 of [MLN-REQ]);
- Traffic Disruption minimization during FA-LSP release (Section
5.5 of [MLN-REQ]);
- Stability (Section 5.4 of [MLN-REQ]);
- Support for FA-LSP attributes inheritance (Section 5.6 of
[MLN-REQ]);
- Support for FA-LSP data plane connectivity verification
(Section 5.9 of [MLN-REQ]);
Here is the list of requirements that apply to MRN only:
- Support for Multi-Region signaling (section 5.7 of [MLN-REQ]);
- Advertisement of the adjustment capacity (section 5.2 of
[MLN-REQ]);
3. Analysis
3.1. Multi Layer Network Aspects
3.1.1. Support for Virtual Network Topology Reconfiguration
A set of lower-layer FA-LSPs provides a Virtual Network Topology
(VNT) to the upper-layer [MLN-REQ]. By reconfiguring the VNT (FA-LSP
setup/release) according to traffic demands between source and
destination node pairs within a layer, network performance factors
such as maximum link utilization and residual capacity of the network
can be optimized. Such optimal VNT reconfiguration implies several
mechanisms that are analyzed in the following sections.
Note that the VNT approach is just one possible approach to perform
inter-layer Traffic Engineering.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 4]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
3.1.1.1. Control of FA-LSPs Setup/Release
In a Multi-Layer Network, FA-LSPs are created, modified, released
periodically according to the change of incoming traffic demands from
the upper layer.
This implies a TE mechanism that takes into account the demands
matrix, the TE topology and potentially the current VNT, in order to
compute and setup a new VNT.
Several functional building blocks are required to support such TE
mechanism:
- Discovery of TE topology and available resources.
- Collection of upper layer traffic demands.
- Policing and scheduling of VNT resources with regard to traffic
demands and usage (that is, decision to setup/release FA-LSPs). The
functional component in charge of this function is called a VNT
Manager (VNTM) [PCE-INTER].
- VNT Paths Computation according to TE topology, and potentially
taking into account the old (existing) VNT to minimize changes. The
Functional component in charge of VNT computation may be
distributed on network elements or may be performed on an external
tool (such as a Path Computation Element (PCE), [RFC4655]).
- FA-LSP setup/release.
GMPLS routing protocols provide TE topology discovery.
GMPLS signaling protocols allow setting up/releasing FA-LSPs.
VNTM functions (resources policing/scheduling, decision to
setup/release FA-LSPs, FA-LSP configuration) are out of the scope of
GMPLS protocols. Such functionalities can be achieved directly on
layer border LSRs, or through one or more external tools. When an
external tool is used, an interface is required between the VNTM and
the network elements so as to setup/release FA-LSPs. This could use
standard management interfaces such as [RFC4802].
The set of traffic demands of the upper layer is required for the
VNT Manager to take decisions to setup/release FA-LSPs. Such
traffic demands include satisfied demands, for which one or more
upper layer LSP have been successfully setup, as well as unsatisfied
demands and future demands, for which no upper layer LSP has been
setup yet. The collection of such information is beyond the scope of
GMPLS protocols. Note that it may be partially inferred from
parameters carried in GMPLS signalling or advertised in GMPLS
routing.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 5]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
Finally, the computation of FA-LSPs that form the VNT can be
performed directly on layer border LSRs or on an external tool (such
as a Path Computation Element (PCE), [RFC4655]), and this is
independent of the location of the VNTM.
Hence, to summarize, no GMPLS protocol extensions are required to
control FA-LSP setup/release.
3.1.1.2. Virtual TE-Links
A Virtual TE-link is a TE-link between two upper layer nodes that is
not actually associated with a fully provisioned FA-LSP in a lower
layer. A Virtual TE-link represents the potentiality to setup an FA-
LSP in the lower layer to support the TE-link that has been
advertised. A Virtual TE-link is advertised as any TE-link, following
the rules in [RFC4206] defined for fully provisioned TE-links. In
particular, the flooding scope of a Virtual TE-link is within an IGP
area, as is the case for any TE-link.
If an upper-layer LSP attempts (through a signalling message) to make
use of a Virtual TE-link, the underlying FA-LSP is immediately
signalled and provisioned (provided there are available resources in
the lower layer) in the process known as triggered signaling.
The use of Virtual TE-links has two main advantages:
- Flexibility: allows the computation of an LSP path using TE-links
without needing to take into account the actual provisioning status
of the corresponding FA-LSP in the lower layer;
- Stability: allows stability of TE-links in the upper layer, while
avoiding wastage of bandwidth in the lower layer, as data plane
connections are not established until they are actually needed.
Virtual TE-links are setup/deleted/modified dynamically, according to
the change of the (forecast) traffic demand, operator's policies for
capacity utilization, and the available resources in the lower layer.
The support of Virtual TE-links requires two main building blocks:
- A TE mechanism for dynamic modification of Virtual TE-link
Topology;
- A signaling mechanism for the dynamic setup and deletion of virtual
TE-links. Setting up a virtual TE-link requires a signaling
mechanism allowing an end-to-end association between Virtual
TE-link end points so as to exchange link identifiers as well as
some TE parameters.
The TE mechanism responsible for triggering/policing dynamic
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 6]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
modification of Virtual TE-links is out of the scope of GMPLS
protocols.
Current GMPLS signalling does not allow setting up and releasing
Virtual TE-links. Hence GMPLS signalling must be extended to support
Virtual TE-links.
We can distinguish two options for setting up Virtual TE-links:
- The Soft FA approach that consists of setting up the FA-LSP in the
control plane without actually activating cross connections in the
data plane. On the one hand, this requires state maintenance on all
transit LSRs (N square issue), but on the other hand this may allow
for some admission control. Indeed, when a soft-FA is activated,
the resources may be no longer available for use by other soft-FAs
that have common links. These soft-FA will be dynamically released
and corresponding virtual TE-links are deleted. The soft-FA LSPs
may be setup using procedures similar to those described in
[RFC4872] for setting up secondary LSPs.
- The remote association approach that simply consists of exchanging
virtual TE-links IDs and parameters directly between TE-link end
points. This does not require state maintenance on transit LSRs,
but reduces admission control capabilities. Such an association
between Virtual TE-link end-points may rely on extensions to the
RSVP-TE ASON Call procedure ([RFC4974]).
Note that the support of Virtual TE-links does not require any GMPLS
routing extension.
3.1.1.3. Traffic Disruption Minimization During FA Release
Before deleting a given FA-LSP, all nested LSPs have to be rerouted
and removed from the FA-LSP to avoid traffic disruption.
The mechanisms required here are similar to those required for
graceful deletion of a TE-Link. A Graceful TE-link deletion mechanism
allows for the deletion of a TE-link without disrupting traffic of
TE-LSPs that were using the TE-link.
Hence, GMPLS routing and/or signaling extensions are required
to support graceful deletion of TE-links. This may utilize the
procedures described in [GR-SHUT]: A transit LSR notifies a head-end
LSR that a TE-link along the path of a LSP is going to be torn down,
and also withdraws the bandwidth on the TE-link so that it is not
used for new LSPs.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 7]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
3.1.1.4. Stability
The stability of upper-layer LSP may be impaired if the VNT undergoes
frequent changes. In this context robustness of the VNT is defined as
the capability to smooth the impact of these changes and avoid their
subsequent propagation.
Guaranteeing VNT stability is out of the scope of GMPLS protocols and
relies entirely on the capability of the TE and VNT management
algorithms to minimize routing perturbations. This requires that the
algorithms takes into account the old VNT when computing a new VNT,
and try to minimize the perturbation.
Note that a full mesh of lower-layer LSPs may be created between
every pair of border nodes between the upper and lower layers. The
merit of a full mesh of lower-layer LSPs is that it provides
stability to the upper layer routing. That is, forwarding table used
in the upper layer is not impacted if the VNT undergoes changes.
Further, there is always full reachability and immediate access to
bandwidth to support LSPs in the upper layer. But it also has
significant drawbacks, since it requires the maintenance of n^2 RSVP-
TE sessions, which may be quite CPU and memory consuming (scalability
impact). Also this may lead to significant bandwidth wastage. Note
that the use of virtual TE-links solves the bandwidth wastage issue,
and may reduce the control plane overload.
3.1.2. Support for FA-LSP Attributes Inheritance
When a FA TE Link is advertised, its parameters are inherited from
the parameters of the FA-LSP, and specific inheritance rules are
applied.
This relies on local procedures and policies and is out of the scope
of GMPLS protocols. Note that this requires that both head-end and
tail-end of the FA-LSP are driven by same policies.
3.1.3. FA-LSP Connectivity Verification
Once fully provisioned, FA-LSP liveliness may be achieved by
verifying its data plane connectivity.
FA-LSP connectivity verification relies on technology specific
mechanisms (e.g., for SDH using G.707 and G.783; for MPLS using BFD;
etc.) as for any other LSP. Hence this requirement is out of the
scope of GMPLS protocols.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 8]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
3.2. Specific Aspects for Multi-Region Networks
3.2.1. Support for Multi-Region Signaling
There are actually several cases where a transit node could choose
between multiple SCs to be used for a lower region FA-LSP:
- ERO expansion with loose hops: The transit node has to expand the
path, and may have to select among a set of lower region SCs.
- Multi-SC TE link: When the ERO of a FA LSP, included in the ERO of
an upper region LSP, comprises a multi-SC TE-link, the region
border node has to select among these SCs.
Existing GMPLS signalling procedures do not allow solving this
ambiguous choice of SC that may be used along a given path.
Hence an extension to GMPLS signalling has to be defined to indicate
the SC(s) that can be used and the SC(s) that cannot be used along
the path.
3.2.2. Advertisement of Adjustment Capacities
In the MRN context, nodes supporting more than one switching
capability on at least one interface are called Hybrid nodes ([MLN-
REQ]). Conceptually, hybrid nodes can be viewed as containing at
least two distinct switching elements interconnected by internal
links which provide adjustment between the supported switching
capabilities. These internal links have finite capacities and must be
taken into account when computing the path of a multi-region TE-LSP.
The advertisement of the adjustment capacities is required as it
provides critical information when performing multi-region path
computation.
The term adjustment capacity refers to the property of a hybrid node
to interconnect different switching capabilities it provides though
its external interfaces [MLN-REQ]. This information allows path
computation to select an end-to-end multi-region path that includes
links of different switching capabilities that are joined by LSRs
that can adapt the signal between the links.
Figure 1a below shows an example of hybrid node. The hybrid node has
two switching elements (matrices), which support here TDM and PSC
switching respectively. The node has two PSC and TDM ports (port1 and
port2 respectively). It also has internal link connecting the two
switching elements.
The two switching elements are internally interconnected in such a
way that it is possible to terminate some of the resources of the TDM
port 2 and provide through them adjustment for PSC traffic,
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 9]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
received/sent over the internal PSC interface (#b). Two ways are
possible to set up PSC LSPs (port 1 or port 2). Available resources
advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover
both ways.
Network element
.............................
: -------- :
PSC : | PSC | :
Port1-------------<->---|#a | :
: +--<->---|#b | :
: | -------- :
: | ---------- :
TDM : +--<->--|#c TDM | :
Port2 ------------<->--|#d | :
: ---------- :
:............................
Figure 1a. Hybrid node.
Port 1 and Port 2 can be grouped together thanks to internal DWDM, to
result in a single interface: Link 1. This is illustrated in figure
1b below.
Network element
.............................
: -------- :
: | PSC | :
: | | :
: --|#a | :
: | | #b | :
: | -------- :
: | | :
: | ---------- :
: /| | | #c | :
: | |-- | | :
Link1 ========| | | TDM | :
: | |----|#d | :
: \| ---------- :
:............................
Figure 1b. Hybrid node.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 10]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
Let's assume that all interfaces are STM16 (with VC4-16c capable
as Max LSP bandwidth). After, setting up several PSC LSPs via port #a
and setting up and terminating several TDM LSPs via port #d and port
#b, there is only 155 Mb capacities still available on port #b.
However a 622 Mb capacity remains on port #a and VC4-5c capacity on
port #d.
When computing the path for a new VC4-4c TDM LSP, one must know, that
this node cannot terminate this LSP, as there is only 155Mb still
available for TDM-PSC adjustment. Hence the TDM-PSC adjustment
capacity must be advertised.
With current GMPLS routing [RFC4202] this advertisement is possible
if link bundling is not used and if two TE-links are advertised for
link1:
We would have the following TE-link advertisements:
TE-link 1 (port 1):
- ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb
- Unreserved bandwidth = 622Mb.
TE-Link 2 (port 2):
- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb,
- Unreserved bandwidth (equivalent): 777 Mb.
The ISCD 2 in TE-link 2 represents actually the TDM-PSC adjustment
capacity.
However if for obvious scalability reasons link bundling is done then
the adjustment capacity information is lost with current GMPLS
routing, as we have the following TE-link advertisement:
TE-link 1 (port 1 + port 2):
- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,
- Unreserved bandwidth (equivalent): 1399 Mb.
With such TE-link advertisement an element computing the path of a
VC4-4c LSP cannot know that this LSP cannot be terminated on the
node.
Thus current GMPLS routing can support the advertisement of the
adjustment capacities but this precludes performing link bundling and
thus faces significant scalability limitations.
Hence, GMPLS routing must be extended to meet this requirement. This
could rely on the advertisement of the adjustment capacities as a new
TE link attribute (that would complement the Interface Switching
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 11]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
Capability Descriptor TE-link attribute).
Note: Multiple ISCDs MAY be associated to a single switching
capability. This can be performed to provide e.g. for TDM interfaces
the Min/Max LSP Bandwidth associated to each (set of) layer for that
switching capability. As an example, an interface associated to TDM
switching capability and supporting VC-12 and VC-4 switching, can be
associated one ISCD sub-TLV or two ISCD sub-TLVs. In the first case,
the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to
VC-4. In the second case, the Min LSP Bandwidth is set to VC-12 and
the Max LSP Bandwidth to VC-12, in the first ISCD sub-TLV; and the
Min LSP Bandwidth is set to VC-4 and the Max LSP Bandwidth to VC-4,
in the second ISCD sub-TLV. Hence, in the first case, as long as the
Min LSP Bandwidth is set to VC-12 (and not VC-4) and in the second
case, as long as the first ISCD sub-TLV is advertised there is
sufficient capacity across that interface to setup a VC-12 LSP.
4. Evaluation Conclusion
Most of the required MLN/MRN functions will rely on mechanisms and
procedures that are out of the scope of the GMPLS protocols, and thus
do not require any GMPLS protocol extensions. They will rely on local
procedures and policies, and on specific TE mechanisms and
algorithms.
As regards Virtual Network Topology (VNT) computation and
reconfiguration, specific TE mechanisms need to be defined, but these
mechanisms are out of the scope of GMPLS protocols.
Four areas for extensions of GMPLS protocols and procedures have been
identified:
- GMPLS signaling extension for the setup/deletion of the virtual
TE-links;
- GMPLS routing and signaling extension for graceful TE-link
deletion;
- GMPLS signaling extension for constrained multi-region signalling
(SC inclusion/exclusion);
- GMPLS routing extension for the advertisement of the adjustment
capacities of hybrid nodes.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 12]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
5. Security Considerations
[MLN-REQ] sets out the security requirements for operating a MLN or
MRN. These requirements are, in general, no different from the
security requirements for operating any GMPLS network. As such, the
GMPLS protocols already provide adequate security features. An
evaluation of the security features for GMPLS networks may be found
in [MPLS-SEC], and where issues or further work is identified by that
document, new security features or procedures for the GMPLS protocols
will need to be developed.
[MLN-REQ] also identifies that where the separate layers of a MLN/MRN
network are operated as different administrative domains, additional
security considerations may be given to the mechanisms for allowing
inter-layer LSP setup. However, this document is explicitly limited
to the case where all layers under GMPLS control are part of the same
administrative domain.
Lastly, as noted in [MLN-REQ], it is expected that solution documents
will include a full analysis of the security issues that any protocol
extensions introduce.
6. IANA Considerations
This informational document makes no requests for IANA action.
7. Acknowledgments
We would like to thank Julien Meuric, Igor Bryskin and Adrian Farrel
for their useful comments.
Thanks also to Question 14 of Study Group 15 of the ITU-T for their
thoughtful review.
8. References
8.1. Normative References
[RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label
Switching Architecture", RFC 3945, October 2004
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol
Label Switching", RFC4202, October 2005.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 13]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
8.2. Informative References
[RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE
extensions", RFC3473, January 2003.
[RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with
generalized MPLS TE", RFC4206, October 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based
Architecture", RFC4655, August 2006.
[RFC4802] Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802,
February 2007.
[RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in
support of End-to-End Generalized Multi-Protocol Label
Switching (GMPLS)-based Recovery", RFC4872, May 2007.
[RFC4974] Papadimitriou, D., Farrel, A., et. al., "Generalized
MPLS (GMPLS) RSVP-TE Signaling Extensions in support of
Calls", RFC 4974, August 2007.
[GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic
Engineering Network", draft-ietf-ccamp-mpls-graceful-
shutdown, work in progress.
[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L.,
Vigoureux, M., Brungard, D., "Requirements for GMPLS-
based multi-region and multi-layer networks", draft-
ietf-ccamp-gmpls-mln-reqs, work in progess.
[MPLS-SEC] Fang, et al. "Security Framework for MPLS and GMPLS
Networks draft-fang-mpls-gmpls-security-framework, work
in progress.
[PCE-INTER] Oki, E., Le Roux , J-L., and Farrel, A., "Framework for
PCE-Based Inter-Layer MPLS and GMPLS Traffic
Engineering", draft-ietf-pce-inter-layer-frwk, work in
progress.
9. Editors' Addresses:
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
Email: jeanlouis.leroux@orange-ftgroup.com
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 14]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
Dimitri Papadimitriou
Alcatel-Lucent
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Email: dimitri.papadimitriou@alcatel-lucent.be
10. Contributors' Addresses:
Deborah Brungard
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ, 07748 USA
E-mail: dbrungard@att.com
Eiji Oki
NTT
3-9-11 Midori-Cho
Musashino, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp
Kohei Shiomoto
NTT
3-9-11 Midori-Cho
Musashino, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp
M. Vigoureux
Alcatel-Lucent France
Route de Villejust
91620 Nozay
FRANCE
Email: martin.vigoureux@alcatel-lucent.fr
11. Intellectual Property Statement
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.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 15]
Internet Draft draft-ietf-ccamp-gmpls-mln-eval-05.txt December 2007
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.
Disclaimer of Validity
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, THE
IETF TRUST 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.
Copyright Statement
Copyright (C) The IETF Trust (2007). 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.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 16]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/