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," 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]