--- 1/draft-ietf-ccamp-gmpls-mln-eval-04.txt 2007-12-17 23:12:07.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-mln-eval-05.txt 2007-12-17 23:12:07.000000000 +0100 @@ -1,23 +1,21 @@ Network Working Group J.L. Le Roux (Ed.) Internet Draft France Telecom Category: Informational -Expires: May 2008 D. Papadimitriou (Ed.) - Alcatel-Lucent - - November 2007 +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-04.txt + 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 @@ -52,66 +50,67 @@ 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.................................................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..................8 - 3.2.1. Support for Multi-Region Signaling..........................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....................................12 - 6. Acknowledgments............................................13 - 7. References.................................................13 - 7.1. Normative..................................................13 - 7.2. Informative................................................13 - 8. Editors' Addresses:........................................14 - 9. Contributors' Addresses:...................................14 - 10. Intellectual Property Statement............................15 + 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 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. + 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 ([RFC 3945], [RFC4202], [RFC3471, - [RFC3473]]) against the requirements for MLN and MRN, defined in + 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 @@ -128,35 +127,35 @@ 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 robust Virtual Network Topology (VNT) reconfiguration. + This implies the following requirements: - - Support for FA-LSP attributes inheritance (section 5.6 of + - 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]); + (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 @@ -185,31 +184,30 @@ 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). + - 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]). + - 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 @@ -217,21 +215,22 @@ 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. + parameters carried in GMPLS signalling or advertised in GMPLS + routing. 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 @@ -246,41 +245,41 @@ 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; + 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. + - 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 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: @@ -294,21 +293,21 @@ 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 ([RSVP-CALL]). + 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 @@ -536,31 +536,31 @@ 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 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 signaling extension for constrained multi-region signalling + (SC inclusion/exclusion); - - GMPLS routing extension for the advertisement of the - adjustment capacities of hybrid nodes. + - GMPLS routing extension for the advertisement of the adjustment + capacities of hybrid nodes. 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 @@ -570,115 +570,108 @@ 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. Acknowledgments +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. -7. References +8. References -7.1. Normative +8.1. Normative References - [RFC3979] Bradner, S., "Intellectual Property Rights in IETF - Technology", BCP 79, RFC 3979, March 2005. + [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", draft-ietf-ccamp-gmpls-routing, - RFC4202, October 2005. - - [RFC3471] Berger, L., et. al. "Generalized Multi-Protocol Label - Switching (GMPLS) Signaling Functional Description", RFC - 3471, January 2003. - -7.2. Informative + Label Switching", RFC4202, October 2005. - [RSVP-CALL] Papadimitriou, D., Farrel, A., et. al., "Generalized - MPLS (GMPLS) RSVP-TE Signaling Extensions in support of - Calls", draft-ietf-ccamp-gmpls-rsvp-te-call, work in - progress. +8.2. Informative References - [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-mrn-reqs, work in progess. + [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", draft-ietf-mpls-lsp-hierarchy, - RFC4206, October 2005. + generalized MPLS TE", RFC4206, October 2005. - [GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic - Engineering Network", draft-ietf-ccamp-mpls-graceful- - shutdown, work in progress. + [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. - [VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network - Topology Manager (VNTM) for PCE-based Inter-Layer MPLS - and GMPLS Traffic Engineering", draft-oki-pce-vntm-def, - work in progress. - - [IW-MIG-FMWK]Shiomoto, K et al., "Framework for IP/MPLS-GMPLS - interworking in support of IP/MPLS to GMPLS migration", - draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in - progress. - - [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions", - RFC3473, January 2003. + [RFC4974] Papadimitriou, D., Farrel, A., et. al., "Generalized + MPLS (GMPLS) RSVP-TE Signaling Extensions in support of + Calls", RFC 4974, August 2007. - [RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based - Architecture", RFC4655, August 2006. + [GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic + Engineering Network", draft-ietf-ccamp-mpls-graceful- + shutdown, work in progress. - [RFC4802] Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802, - February 2007. + [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. -8. Editors' Addresses: + [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 - Dimitri Papadimitriou Alcatel-Lucent Francis Wellensplein 1, B-2018 Antwerpen, Belgium Email: dimitri.papadimitriou@alcatel-lucent.be -9. Contributors' Addresses: +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 @@ -684,42 +677,43 @@ 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 -10. Intellectual Property Statement +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. 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. + 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