Network Working Group J.L. Le Roux (France Telecom)
Internet Draft D. Brungard (AT&T)
Category: Informational E. Oki (NTT)
Expires: January 2006 D. Papadimitriou (Alcatel)
K. Shiomoto (NTT)
M. Vigoureux (Alcatel)
July 2005
Evaluation of existing GMPLS Protocols against Multi Layer
and Multi Region Networks (MLN/MRN)
draft-leroux-ccamp-gmpls-mrn-eval-01.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.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document provides 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-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
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 aspects.........................................4
3.1.1. Support for Virtual Network Topology Reconfiguration........4
3.1.1.1. Control of Forwarding Adjacencies (FA) setup/release......4
3.1.1.2. Virtual TE-link...........................................6
3.1.1.3. Traffic Disruption minimization during FA release.........7
3.1.1.4. Stability.................................................7
3.1.2. Support for FA LSP attributes inheritance...................7
3.1.3. Support for Triggered signaling.............................7
3.1.4. FA connectivity verification................................8
3.2. Multi-Region specific aspects...............................8
3.2.1. Support for Multi-region signaling..........................8
3.2.2. Advertisement of Internal Adaptation Capabilities...........9
4. Evaluation Conclusion......................................10
5. Security considerations....................................10
6. Acknowledgments............................................10
7. References.................................................10
8. Authors' Addresses:........................................11
9. Intellectual Property Statement............................12
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 2]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to
handle multiple switching technologies: packet switching, layer-two
switching, TDM switching, wavelength switching and fiber switching
(see [RFC 3945]).
A data plane layer is a collection of network resources capable of
terminating and/or switching data traffic of a particular format. For
example, LSC, TDM VC-11 and TDM VC-4-64c represent three different
layers. A network comprising transport nodes with different data
plane switching layers controlled by a single GMPLS control plane
instance is called a Multi-Layer Network (MLN).
A GMPLS switching type (PSC, TDM, etc.) describes the ability of a
node to forward data of a particular data plane technology, and
uniquely identifies a control plane region. The notion of LSP Region
is defined in [HIER]. A MLN comprising of multiple switching types
(e.g. PSC and TDM) is called a Multi-Region Network (MRN).
Note that the region is a control plane only concept. That is, layers
of the same region share the same switching technology and,
therefore, need the same set of technology specific signaling
objects.
Note that a MRN is necessarily a MLN, but not vice versa, as a MLN
may consist of a single region (control of multiple data plane layers
within a region). Hence, in the following, we use the term layer if
the mechanism discussed applies equally to layers and regions (e.g.
VNT, virtual TE-link, etc.), and we specifically use the term region
if the mechanism applies only for supporting a MRN.
The objectives of this document are to evaluate existing GMPLS
mechanisms and protocols ([RFC 3945], [GMPLS-RTG], [GMPLS-SIG])
against the requirements for MLN and MRN, defined in [MRN-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.
Section 2 provides an overview of MLN/MRN requirements.
Section 3 evaluates for each of these requirements, whether current
GMPLS protocols and mechanisms allow addressing the requirements.
When the requirements are not met, the document identifies whether
the required mechanisms could rely on GMPLS protocols and procedure
extensions or if 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.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 3]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
2. MLN/MRN Requirements overview
[MRN-REQ] lists a set of functional requirements for Multi
Layer/Region Networks (MLN/MRN). These requirements are summarized
below:
-Support of robust Virtual Network Topology reconfiguration.
This implies the following requirements:
-Optimal control of Forwarding Adjacencies (FA) setup
and release;
-Support for virtual TE-links;
-Traffic Disruption minimization during FA release (e.g.
network reconfiguration events);
-Stability
-Support for FA LSP attributes inheritance;
-Support for Triggered Signaling;
-Support for FA data plane connectivity verification;
-Support for Multi-region signaling;
-Advertisement of the adaptation capabilities and resources;
3. Analysis
3.1. Multi-layer aspects
3.1.1. Support for Virtual Network Topology Reconfiguration
A set of lower-layer FAs provides a Virtual Network Topology (VNT) to
the upper-layer. By reconfiguring the VNT (FA-LSP setup/release)
according to traffic demands between source and destination node
pairs of 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 approach among others, to
perform inter-layer Traffic Engineering.
3.1.1.1. Control of Forwarding Adjacencies (FA) setup/release
In a multi-layer network, FAs 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 a new VNT.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 4]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
Several building blocks are required to support such TE mechanism:
- Discovery of TE topology and available resources;
- Collection of traffic demands of the upper layer;
- VNT engine, ensuring VNT computation and reconfiguration
according to upper layer traffic demands and TE topology
(and potentially old VNT);
- FA setup/release;
GMPLS routing protocols support TE topology discovery and
GMPLS signaling protocols allow setting up/releasing FAs.
VNT computation and reconfiguration is out of the scope of GMPLS
protocols. Such functionality can be achieved directly on layer
border LSRs, or one or more external tools, as for instance Path
Computation Elements (PCE) (see [PCE-ARCH]).
The set of traffic demands of the upper layer is required to
recompute and re-optimize the VNT. This functionality must have
knowledge of the aggregated bandwidth reserved by upper layer LSPs
established between any pair of border LSRs.
Existing GMPLS routing allows for the collection of traffic demands
of the upper region. It can be deduced from FA TE-link
advertisements.
The set of traffic demands can be inferred:
- either directly, based on upper-layer FA TE-link
advertisements. The traffic demands between two points
correspond to the cumulated bandwidth reserved by upper-layer
LSPs between these two points;
- or indirectly, based on lower-layer FA TE-link
advertisements. In this case a mechanism to infer the upper-
layer traffic demand from the aggregated bandwidth reserved
in lower-layer LSPs might be required, as all pairs of border
nodes may not be directly connected by a lower layer LSP.
Collection of traffic demands of an upper region may actually be
achieved in several ways depending on the location of VNT engines:
- If a VNT engine is distributed on border region LSRs, then the
collection of traffic demands would rely on existing GMPLS
routing, as per described above;
- If a VNT engine is located on an external tool (e.g. a PCE)
then the collection of traffic demands may be achieved using
existing GMPLS routing, provided that the tool relies on GMPLS
routing to discover TE link information, or it may rely on
another mechanism out of the scope of GMPLS protocols (e.g.
SNMP, PCC-PCE communication protocolà).
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 5]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
3.1.1.2. Virtual TE-link
A virtual TE-link is a TE-link between two nodes, not actually
associated to a fully provisioned FA-LSP. A virtual TE-link
represents the potentiality to setup a FA-LSP. There is no IGP
adjacency associated to a virtual TE-link. A virtual TE-link is
advertised as any classical TE-link, i.e. following the rules in
[HIER] defined for fully provisioned TE-links. Particularly, the
flooding scope of a virtual TE link is within an IGP area, as any TE-
link.
During its signalling, if an upper-layer LSP makes use of a virtual
TE-link, the underlying FA-LSP is immediately signalled and
provisioned.
The use of virtual TE-links has two main advantages:
- flexibility: allows to compute a LSP path using TE links and this
without taking into account the actual status of the
corresponding FA-LSP in the lower layer in terms of provisioning;
- stability: allows stability of TE-links, while
avoiding wastage of bandwidth in the lower layer, as data
plane connections are not established.
Note also that it avoids state maintenance but is susceptible to
create contention if no adequate/consistent admission control is put
in place.
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 signalling 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
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. The association between virtual TE-link end-points
may rely on extensions to the RSVP-TE ASON Call procedure ([GMPLS-
ASON]).
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 6]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
Note that the support of virtual TE-link 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 where using the TE-link.
GMPLS protocols do not provide for explicit indication to trigger
such operation.
Hence, GMPLS routing and/or signaling extensions are required
to support graceful deletion of TE-links. This may rely, for
instance, on new signaling Error code to notify head-end LSRs that a
TE-link along the path of a LSP is going to disappear, and also on
new routing attributes (if limited to a single IGP area), such as
defined in [GR-SHUT].
3.1.1.4. Stability
The upper-layer LSP stability may be impaired if the VNT undergoes
frequent changes. In this context robustness of the VNT is defined as
the capability to smooth 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 TE algorithms to minimize
routing perturbations. This requires that the TE algorithm takes into
account the old VNT when computing a new VNT, and tries to minimize
the perturbation.
3.1.2. Support for FA LSP attributes inheritance
When FA TE-link parameters are inherited from FA-LSP parameters,
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 and tail-ends of the FA-LSP
are driven by same policies.
3.1.3. Support for Triggered signaling.
When a LSP crosses the boundary from an upper to a lower layer, it
may be nested in or stitched to a lower-layer LSP. If such an LSP
does not exist the LSP may be established dynamically. Such a
mechanism is referred to as "Triggered signaling".
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 7]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
Triggered signaling requires the following building blocks:
-The identification of layer boundaries.
-A path computation engine capable of computing a path
containing multiple layers.
-A mechanism for nested signaling.
The identification of layer boundaries is supported by GMPLS routing
protocols. The identification of layer boundaries is performed using
the interface switching capability descriptor associated to the TE-
link (see [HIER] and [GMPLS-RTG]).
The capability to compute a path containing multiple layers is a
local implementation issue and is out of the scope of GMPLS protocols.
A mechanism for nested signaling is defined in [HIER].
Hence, GMPLS protocols already meet this requirement.
3.1.4. FA connectivity verification
Once fully provisioned, FA liveliness may be achieved by verifying
its data plane connectivity.
FA connectivity verification relies on technology specific mechanisms
(e.g. for SDH, G.707, G.783, for MPLS, BFD, etc.) as for any other
LSP. Hence this requirement is out of the scope of GMPLS protocols.
Note that the time to establish the FA-LSP must be minimized.
3.2. Multi-Region specific aspects
3.2.1. Support for Multi-region signaling
Applying the triggered signaling procedure discussed above, in a MRN
environment may lead to setup of one-hop FA-LSPs between each node.
Therefore, considering that the path computation is able to take into
account richness of information with regard to the Switching
Capability (SC) available on given nodes belonging to the path, it is
consistent to provide enough signaling information to indicate the SC
to be used and on over which link.
Limited extension to existing GMPLS signaling procedures is required
for this purpose as it only mandates indication of the SCs to be
included or excluded before initiating the LSP provisioning procedure.
This enhancement would solve the ambiguous choice of SC that are
potentially used along a given path, particularly in case of ERO
expansion, or when an ERO sub-object identifies a multi-SC TE link.
This would give the possibility to optimize resource usage on a
multi-region basis.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 8]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
3.2.2. Advertisement of Internal Adaptation Capabilities
In the MRN context, nodes supporting more than one switching
capability on at least one interface are called Hybrid nodes. Hybrid
nodes contain at least two distinct switching elements that are
interconnected by internal links, to provide adaptation 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 internal adaptation capability is required
as it provides critical information when performing multi-region path
computation.
The advertisement of the internal adaptation capability, using
existing GMPLS routing, would require dividing a hybrid node, in the
routing plane, in several logical nodes, and advertising internal
adaptation capabilities as TE-links between logical nodes. Of course
such approach must be avoided as it leads to the introduction of
internal node states.
Hence, GMPLS routing must be extended to meet this requirement. This
could rely on the advertisement of the internal adaptation
capabilities as a new TE link attribute (that would complement the
Interface Switching Capability Descriptor TE link attribute).
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 9]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
4. Evaluation Conclusion
Most of MLN/MRN requirements 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 that could, for instance,
rely on PCE based mechanisms and protocols 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 (as well as exact trigger for its actual
provisioning);
- GMPLS routing and signaling extension for graceful TE link
deletion;
- GMPLS signalling extension for constrained multi-region
signalling (SC inclusion/exclusion);
- GMPLS routing extension for the advertisement of the
internal adaptation capability of hybrid nodes.
5. Security considerations
This document specifically addresses GMPLS control plane
functionality for MLN/MRN in the context of a single administrative
control plane partition and hence does not introduce additional
security threats beyond those described in [RFC3945].
6. Acknowledgments
We would like to thank Julien Meuric and Igor Bryskin for their
useful comments.
7. References
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label
Switching Architecture", RFC 3945, October 2004
[GMPLS-RTG] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-gmpls-routing, work in Progress.
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 10]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
[GMPLS-SIG] Berger, L., et. al. "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[GMPLS-ASON] Papadimitriou, D., et. al., " Generalized MPLS (GMPLS)
RSVP-TE Signalling in support of Automatically Switched Optical
Network (ASON)", draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progess.
[MRN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux,
M., Brungard, D., "Requirements for GMPLS-based multi-region and
multi-layer networks", draft-shiomoto-ccamp-gmpls-mrn-reqs, work in
progess.
[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE) Architecture", draft-ietf-pce-architecture, work in
progress.
[GTEP] Oki, E., et. al., "Generalized Traffic Engineering Protocol",
draft-oki-pce-gtep, work in progress.
[HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08, work in progress.
[GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic
Engineering Network", draft-ali-ccamp-mpls-graceful-shutdown, work in
progress.
8. Authors' Addresses:
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
Email: jeanlouis.leroux@francetelecom.com
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
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 11]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
Email: dimitri.papdimitriou@alcatel.be
Kohei Shiomoto
NTT
3-9-11 Midori-Cho
Musashino, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp
Martin Vigoureux
Alcatel
Route de Nozay,
91461 Marcoussis Cedex, France
Email: martin.vigoureux@alcatel.fr
9. 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.
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 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 Internet Society (2005). This document is subject
Le Roux, et al. Evaluation of GMPLS against MLN/MRN Reqs [Page 12]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-01.txt July 2005
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 13]