CCAMP Working Group J.L. Le Roux
France Telecom
Internet Draft D. Brungard
AT&T
E. Oki
NTT
D. Papadimitriou
Alcatel
K. Shiomoto
NTT
M. Vigoureux
Alcatel
Category: Informational
Expires: July 2005 February 2005
Evaluation of existing GMPLS Protocols against Multi Region Networks
draft-leroux-ccamp-gmpls-mrn-eval-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,
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 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.
Le Roux et al. [Page 1]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 2005
Abstract
This document provides an evaluation of Generalized Multi-Protocol
Label Switching (GMPLS) protocols and mechanisms against the
requirements for Multi Region Networks (MRN).
In addition, this document identifies areas where additional
protocol extensions or procedures are needed to satisfy the
requirements of Multi Region Networks, and provides guidelines for
potential extensions.
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. MRN Requirements overview...................................3
3. Analysis....................................................4
3.1. Support for Virtual Network Topology Reconfiguration........4
3.1.1. Control of Forwarding Adjacencies (FA) setup/release........4
3.1.2. Virtual FAs.................................................5
3.1.3. Traffic Disruption minimization during FA release...........6
3.1.4. Path computation stability..................................6
3.2. Support for FA LSP attributes inheritance...................7
3.3. Support for Triggered signaling.............................7
3.4. Support for Multi-region signaling..........................7
3.5. FA connectivity verification................................8
3.6. Advertisement of Internal Adaptation Capabilities...........8
4. Evaluation Conclusion.......................................9
5. Intellectual Property Statement.............................9
5.1. IPR Disclosure Acknowledgement.............................10
6. Acknowledgment.............................................10
7. References.................................................10
8. Authors' Addresses:........................................11
Le Roux, et al. [Page 2]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 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 [GMPLS-ARCH]).
A Multi Region Network (MRN) is defined as a network consisting of
elements based on different switching technologies controlled by a
unified GMPLS control plane (see [MRN-REQ]).
[MRN-REQ] defines a framework for GMPLS-based multi region networks
and lists a set of functional requirements.
The objectives of this document are to evaluate existing GMPLS
protocols ([GMPLS-RTG], [GMPLS-SIG]) and mechanisms against the
requirements for MRN [MRN-REQ], and to identify several areas where
additional protocol extensions and modifications are required to meet
these requirements.
Section 2 provides an overview of MRN requirements.
Section 3 evaluates for each of these requirements, if current GMPLS
protocols and mechanisms allow addressing the requirements. When the
requirements are not met, the document identifies if the required
mechanisms could rely on GMPLS protocols and procedure extensions or
rather rely on other means.
2. MRN Requirements overview
[MRN-REQ] lists a set of functional requirements for Multi Region
Networks (MRN). These requirements are summarized below:
-Support of robust Virtual Network Topology reconfiguration.
This implies:
-Optimal control of Forwarding Adjacencies (FA) setup
and release;
-Support for virtual FAs;
-Traffic Disruption minimization during FA release (e.g.
network reconfiguration events);
-Path computation stability
-Support for FA LSP attributes inheritance;
-Support for Triggered Signaling;
-Support for Multi-region signaling;
-FA data plane connectivity verification;
-Advertisement of the adaptation capabilities and resources;
Le Roux, et al. [Page 3]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 2005
3. Analysis
3.1. Support for Virtual Network Topology Reconfiguration
A set of lower-region FAs provides a Virtual Network Topology (VNT)
to the upper-region.
By reconfiguring the virtual network topology (FA-LSP setup/release)
according to traffic demands between source and destination node
pairs of a region, 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.
3.1.1. Control of Forwarding Adjacencies (FA) setup/release
In a multi-region network, FAs in a region are created, modified,
released periodically according to the change of traffic demands of
the upper region.
This implies a TE mechanism that takes into account the demands
matrix, and potentially the current VNT in order to compute a new
VNT.
Several building blocks are required to support such TE mechanism:
-Discovery of TE topology and available resources;
-Collection of traffic demands of the upper region;
-VNT engine, ensuring VNT computation and reconfiguration
according to upper region 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.
The VNT engine responsible for VNT computation and reconfiguration is
out of the scope of GMPLS protocols. It may be achieved directly on
region border LSRs, or by use of one or more Path Computation
Elements (PCE) (see [PCE-ARCH]).
The set of traffic demands from the upper region is required to
recompute and re-optimize the VNT. Actually the VNT engine must have
knowledge of the aggregated bandwidth reserved by lower region LSPs
between all border region LSRs, that is, the reserved bandwidth
within FAs.
Existing GMPLS routing allows for the collection of traffic demands
from the upper region.
Le Roux, et al. [Page 4]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 2005
It can be deduced from FA TE-link advertisements. Indeed the
bandwidth reserved by lower region LSPs within an FA is equal to
maximum reservable bandwidth minus unreserved bandwidth.
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 relies on existing GMPLS routing. Each
LSR has knowledge of all FA-LSPs within the region.
-If a VNT engine is located on an external PCE, then the
collection of traffic demands may be achieved using existing GMPLS
routing, if the PCE relies on GMPLS routing to discover TE link
information, or another mechanism out of the scope of GMPLS protocols
may be used (e.g. SNMP or PCC-PCE communication protocol).
3.1.2. Virtual FAs
A virtual FA is an FA which has not been provisioned (data plane
resources have not yet been committed but only pre-allocated at the
control plane level). The corresponding FA-LSP is setup at the
control plane level, but cross connections are not activated at the
data plane level.
If an upper-region LSP that makes use of a virtual FA is setup, the
underlying FA-LSP is immediately signaled and fully provisioned.
This has two main advantages:
- flexibility: allows a region to route an LSP using TE link
without taking into account the actual corresponding FA-LSP
status in the lower region in terms of provisioning.
- stability: allows stability of TE-links in a region, while
avoiding wastage of bandwidth in the lower region, as data
plane connections are not established.
Virtual FAs 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
region.
Virtual FAs require two building blocks:
-A TE mechanism for dynamic modification of virtual FA topology
-A signaling mechanism for the dynamic setup and deletion of
virtual FAs
The TE mechanism responsible for dynamic modification of virtual FAs
is out of the scope of GMPLS protocols.
Le Roux, et al. [Page 5]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 2005
Current GMPLS signaling protocol does not support the setup and
deletion of virtual FAs. The major issue relates to the specification
of a mechanism allowing for allocating the resources at the control
plane level without performing any resource allocation at the data
plane level. So GMPLS signaling procedures must be adapted to allow
for the provisioning and related operations on virtual FAs.
Advertisement of virtual FA is identical to the rules currently
defined for fully provisioned FAs.
3.1.3. Traffic Disruption minimization during FA release
When reconfiguring the virtual network topology according to the
traffic demand change or maintenance actions, the disruption of an
upper-region LSP must be minimized.
This requires local procedures on border region LSRs that are out of
the scope of GMPLS protocols.
Before deleting a given FA-LSP, all nested LSPs have to be rerouted
and removed from the FA-LSP. This is 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 TE-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.4. Path computation stability
The path computation stability of an upper-region may be impaired if
the Virtual Network Topology frequently changes. In this context
robustness of the Virtual Network topology is defined as the
capability to smooth changes that may occur 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.
Le Roux, et al. [Page 6]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 2005
3.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.
This requires that both head and tail-ends of the FA-LSP are driven
by same policies.
3.3. Support for Triggered signaling.
When a LSP crosses the boundary from an upper to a lower region, it
may be nested in or stitched to a lower-region LSP. If such an LSP
does not exist the LSP may be established dynamically. Such a
mechanism is referred to as "Triggered signaling".
Triggered signaling requires the following building blocks:
-The identification of region boundaries.
-A path computation engine capable of computing a path
containing multiple regions.
-A mechanism for nested signaling.
The identification of region boundaries is supported by GMPLS routing
protocols. Region boundaries are identified by the interface
switching capability descriptor attached to the TE-link (see [HIER]
and [GMPLS-RTG]).
The capability to compute a path containing multiple regions 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.4. Support for Multi-region signaling
Applying the triggered signaling procedure discussed above, in a MRN
environment may lead to setup 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 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
Le Roux, et al. [Page 7]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 2005
potentially used along a given path (particularly in case of ERO
expansion) and would give the possibility to optimize resource usage
on a multi-region basis.
3.5. 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.
3.6. Advertisement of Internal Adaptation Capabilities
In the MRN context, nodes supporting more than one switching
capability per interface are called Hybrid nodes. Hybrid nodes
contain at least two distinct switching elements that are
interconnected by internal links, used to facilitate adaptation
between distinct 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 adapatation capability to terminate
LSPs 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 attribute).
Le Roux, et al. [Page 8]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 2005
4. Evaluation Conclusion
Most of 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 have to be defined, but
these mechanisms are out of the scope of GMPLS protocols
Four needs for extensions of GMPLS protocols and procedures have been
identified:
- GMPLS signaling extension for the setup/deletion of
the virtual FAs (as well as exact trigger for its actual
provisioning);
- GMPLS signaling extension for constraint multi-region
signaling;
- GMPLS routing and signaling extension for graceful TE link
deletion;
- GMPLS routing extension for the advertisement of the
internal adaptation capability of hybrid nodes.
5. 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..
Le Roux, et al. [Page 9]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 2005
5.1. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
6. Acknowledgment
We would like to thank Julien Meuric for its useful comments.
7. References
Informative References
[GMPLS-ARCH] 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-09.txt, work in Progress.
[GMPLS-SIG] Berger, L., et. al. "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[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-00.txtwork
in progess.
[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE) Architecture", draft-ash-pce-architecture-00.txt, work
in progress.
[GTEP] Oki, E., et. al., "Generalized Traffic Engineering Protocol",
draft-oki-pce-gtep-01.txt, work in progress
[HIER] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized
MPLS TE," <draft-ietf-mpls-lsp-hierarchy-08.txt> Sept. 2002.
[GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic
Engineering Network", draft-ali-ccamp-mpls-graceful-shutdown-00.txt,
work in progress.
Le Roux, et al. [Page 10]
Internet Draft draft-leroux-ccamp-gmpls-mrn-eval-00.txt February 2005
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
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
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.
Le Roux, et al. [Page 11]