--- 1/draft-ietf-ccamp-gmpls-mln-eval-03.txt 2007-11-19 21:13:57.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-mln-eval-04.txt 2007-11-19 21:13:57.000000000 +0100 @@ -1,20 +1,23 @@ Network Working Group J.L. Le Roux (Ed.) Internet Draft France Telecom Category: Informational -Expires: January 2008 D. Papadimitriou (Ed.) +Expires: May 2008 D. Papadimitriou (Ed.) Alcatel-Lucent + + November 2007 + Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN) - draft-ietf-ccamp-gmpls-mln-eval-03.txt + draft-ietf-ccamp-gmpls-mln-eval-04.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 @@ -49,69 +52,62 @@ 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.1.4. Stability.................................................7 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 Internal Adaptation Capabilities...........9 + 3.2. Specific Aspects for Multi-Region Networks..................8 + 3.2.1. Support for Multi-Region Signaling..........................8 + 3.2.2. Advertisement of Adjustment Capacities......................9 4. Evaluation Conclusion......................................12 5. Security Considerations....................................12 - 6. Acknowledgments............................................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 1. Introduction - Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to - handle multiple switching technologies: packet switching (PSC), - layer-two switching (L2SC), TDM switching (TDM), wavelength switching - (LSC) and fiber switching (FSC) (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 are 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 Label - Switched Path (LSP) Region is defined in [RFC4206]. A network - comprised of multiple switching types (for example PSC and TDM) - controlled by a single GMPLS control plane instance 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. + 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. - Note that a MRN is necessarily a MLN, but not vice versa, as a MLN - may consist of multiple data plane layers of the same switching - technology. Hence, in the following, we use the term "layer" if the - mechanism discussed applies equally to layers and regions (for - example VNT, virtual TE-link, etc.), and we specifically use the term - "region" if the mechanism applies only to the support of a MRN. + 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 ([RFC 3945], [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 @@ -130,21 +126,21 @@ This document uses terminologies defined in [RFC3945], [RFC4206], and [MLN-REQ]. 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: + 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]); @@ -152,22 +148,22 @@ - 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 adaptation capabilities and resources - (section 5.2 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 @@ -198,70 +194,68 @@ - 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). - 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 - centralized on an external tool (such as a Path Computation + 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. - VNT Management functions (resources policing/scheduling, decision to + 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/releases FA-LSPs. This could use + 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 satisfied, 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, but may be partially inferred from - parameters carried in GMPLS signaling or advertised in GMPLS routing. + 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. 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. VNT computation is triggered - by the VNTM (for example, when the path computation is externalized - on a PCE, the VNTM acts as Path Computation Client (PCC)). + 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 in the process known as triggered - signaling. + 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. @@ -334,32 +328,32 @@ 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. - A full mesh of upper-layer LSPs MAY be created between every pair of - border nodes between the upper and lower layers. The merit of a full - mesh of upper-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. + 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. @@ -381,62 +375,70 @@ 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 does not allow solving this + 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 Internal Adaptation Capabilities +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]). 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. + 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 terminates two PSC and TDM ports - (port1 and port2 respectively). It also has internal link connecting - the two switching elements. + 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 adaptation for PSC traffic, + port 2 and provide through them adjustment for PSC traffic, 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 : | ---------- : - +PSC : +--<->--|#c TDM | : + : | ---------- : + 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. @@ -461,77 +463,77 @@ 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 adaptation. Hence the internal TDM-PSC - adaptation capability must be advertised. + 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 internal TDM-PSC - adaptation capability. + 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 adaptation capability information is lost with current GMPLS + 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 - internal adaptation capability but this precludes performing link - bundling and thus faces significant scalability limitations. + 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 internal adaptation capability - as a new TE link attribute (that would complement the Interface - Switching Capability Descriptor TE-link attribute). + could rely on the advertisement of the adjustment capacities as a new + TE link attribute (that would complement the Interface Switching + 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." + 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 @@ -544,34 +546,52 @@ - 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 - internal adaptation capability of hybrid nodes. + adjustment capacities 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]. + [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. 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 7.1. Normative [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 @@ -599,63 +619,66 @@ [RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, 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. [RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label - Switching (GMPLS)-based Recovery", RFC4872, July 2007. + 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. [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. -8. Editors' Addresses + [MPLS-SEC] Fang, et al. "Security Framework for MPLS and GMPLS + Networks draft-fang-mpls-gmpls-security-framework, work + in progress. + +8. 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 +9. 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