--- 1/draft-ietf-ccamp-gmpls-mln-reqs-04.txt 2007-08-14 22:12:08.000000000 +0200 +++ 2/draft-ietf-ccamp-gmpls-mln-reqs-05.txt 2007-08-14 22:12:08.000000000 +0200 @@ -3,965 +3,1108 @@ Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) Intended Status: Informational Jean-Louis Le Roux (France Telecom) Martin Vigoureux (Alcatel-Lucent) Deborah Brungard (AT&T) Expires: February 2008 August 2007 Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN) - draft-ietf-ccamp-gmpls-mln-reqs-04.txt + draft-ietf-ccamp-gmpls-mln-reqs-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. + 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 groups may also - distribute working documents as Internet-Drafts. + 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." + 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 - This Internet-Draft will expire on Februrary 2008. - - Copyright Notice - - Copyright (C) The IETF Trust (2007). + This Internet-Draft will expire in February 2008. Abstract - Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been - related to environments hosting devices with a single switching capability. The - complexity raised by the control of such data planes is similar to that seen in - classical IP/MPLS networks. + Most of the initial efforts to utilize Generalized MPLS (GMPLS) have + been related to environments hosting devices with a single switching + capability. The complexity raised by the control of such data planes + is similar to that seen in classical IP/MPLS networks. - By extending MPLS to support multiple switching technologies, GMPLS provides a - comprehensive framework for the control of a multi-layered network of either a - single switching technology or multiple switching technologies. + By extending MPLS to support multiple switching technologies, GMPLS + provides a comprehensive framework for the control of a multi-layered + network of either a single switching technology or multiple switching + technologies. - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - In GMPLS, a switching technology domain defines a region, and a network of - multiple switching types is referred to in this document as a Multi-Region - Network (MRN). When referring in general to a layered network, which may consist - of either a single or multiple regions, this document uses the term, Multi-Layer - Network (MLN). This document defines a framework for GMPLS based multi- - region/multi-layer networks and lists a set of functional requirements. + In GMPLS, a switching technology domain defines a region, and a + network of multiple switching types is referred to in this document + as a Multi-Region Network (MRN). When referring in general to a + layered network, which may consist of either a single or multiple + regions, this document uses the term, Multi-Layer Network (MLN). This + document defines a framework for GMPLS based multi-region/multi-layer + networks and lists a set of functional requirements. Table of Contents - 1. Introduction.....................................................2 - 2. Conventions Used in this Document....................................4 - 2.1. List of acronyms................................................4 - 3. Positioning......................................................5 - 3.1. Data Plane Layers and Control Plane Regions..........................5 - 3.2. Service layer networks...........................................6 - 3.3. Vertical and Horizontal interaction and integration...................6 - 4. Key Concepts of GMPLS-Based MLNs and MRNs.............................8 - 4.1. Interface Switching Capability....................................8 - 4.2. Multiple Interface Switching Capabilities...........................8 - 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes..............9 - 4.3. Integrated Traffic Engineering (TE) and Resource Control..............10 - 4.3.1. Triggered Signaling...........................................10 - 4.3.2. FA-LSPs.....................................................11 - 4.3.3. Virtual Network Topology (VNT)..................................11 - 5. Requirements....................................................12 - 5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes.......12 - 5.2. Advertisement of the Available Adaptation Resource...................12 - 5.3. Scalability...................................................13 - 5.4. Stability.....................................................13 - 5.5. Disruption Minimization.........................................14 - 5.6. LSP Attribute Inheritance........................................14 - 5.7. Computing Paths With and Without Nested Signaling....................15 - 5.8. LSP Resource Utilization........................................15 - 5.8.1. FA-LSP Release and Setup.......................................16 - 5.8.2. Virtual TE-Links.............................................16 - 5.9. Verification of the LSPs........................................17 - 6. Security Considerations...........................................18 - 7. IANA Considerations..............................................18 - 8. References......................................................18 - 8.1. Normative Reference.............................................18 - 8.2. Informative References..........................................18 - 9. Authors' Addresses...............................................19 - 10. Contributors' Addresses..........................................20 - 11. Intellectual Property Considerations...............................20 - 12. Full Copyright Statement.........................................20 + 1. Introduction .................................................... + 1.1. Scope ......................................................... + 2. Conventions Used in this Document ............................... + 2.1. List of Acronyms .............................................. + 3. Positioning ..................................................... + 3.1. Data Plane Layers and Control Plane Regions ................... + 3.2. Service Layer Networks .. ..................................... + 3.3. Vertical and Horizontal Interaction and Integration ........... + 3.4. Motivation .................................................... + 4. Key Concepts of GMPLS-Based MLNs and MRNs ....................... + 4.1. Interface Switching Capability ................................ + 4.2. Multiple Interface Switching Capabilities ..................... + 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes ..... + 4.3. Integrated Traffic Engineering (TE) and Resource Control ...... + 4.3.1. Triggered Signaling ......................................... + 4.3.2. FA-LSPs ..................................................... + 4.3.3. Virtual Network Topology (VNT) .............................. + 5. Requirements .................................................... + 5.1. Handling Single-Switching and Multi-Switching-Type-Capable + Nodes ....................................................... + 5.2. Advertisement of the Available Adaptation Resource ............ + 5.3. Scalability ................................................... + 5.4. Stability ..................................................... + 5.5. Disruption Minimization ....................................... + 5.6. LSP Attribute Inheritance ..................................... + 5.7. Computing Paths With and Without Nested Signaling ............. + 5.8. LSP Resource Utilization ...................................... + 5.8.1. FA-LSP Release and Setup .................................... + 5.8.2. Virtual TE-Links ............................................ + 5.9. Verification of the LSPs ...................................... + 6. Security Considerations ......................................... + 7. IANA Considerations ............................................ + 8. Acknowledgements ................................................ + 9. References ...................................................... + 9.1. Normative Reference ........................................... + 9.2. Informative References ........................................ + 10. Authors' Addresses ............................................. + 11. Contributors' Addresses ........................................ + 12. Intellectual Property Considerations ........................... + 13. Full Copyright Statement ....................................... + + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 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) - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + 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). - 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 + layer describes a data plane switching granularity level (e.g., VC4, + VC-12). A data plane layer is associated with a region in the control + plane (e.g., VC4 is associated with TDM, MPLS is associated with + PSC). However, more than one data plane layer can be associated with + the same region (e.g., both VC4 and VC12 are associated with TDM). + Thus, a control plane region, identified by its switching type value + (e.g., TDM), can be sub-divided into smaller granularity component + networks based on "data plane switching layers". The Interface + Switching Capability Descriptor (ISCD) [RFC4202], identifying the + interface switching capability (ISC), the encoding type, and the + switching bandwidth granularity, enables the characterization of the + associated layers. - 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 layer describes a data plane switching - granularity level (e.g., VC4, VC-12). A data plane layer is associated with a - region in the control plane (e.g., VC4 is associated with TDM, MPLS is - associated with PSC). However, more than one data plane layer can be associated - with the same region (e.g., both VC4 and VC12 are associated with TDM). Thus, a - control plane region, identified by its switching type value (e.g., TDM), can be - sub-divided into smaller granularity component networks based on "data plane - switching layers". The Interface Switching Capability Descriptor (ISCD) - [RFC4202], identifying the interface switching capability (ISC), the encoding - type, and the switching bandwidth granularity, enables the characterization of - the associated layers. + In this document, we define 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. We further + define a particular case of MLNs. A Multi Region Network (MRN) is + defined as a TE domain supporting at least two different switching + technologies (e.g., PSC and TDM) hosted on the same devices (referred + to as multi-switching-type-capable LSRs, see below) and under the + control of a single GMPLS control plane instance. - In this document, we define 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. We further define a particular case of MLNs. A Multi - Region Network (MRN) is defined as a TE domain supporting at least two different - switching technologies (e.g. PSC + TDM) hosted on the same device (referred to - as multi-switching-type-capable LSRs, see below) and under the control of a - single GMPLS control plane instance. + MLNs can be further categorized according to the distribution of the + ISCs among the LSRs: - MLNs can be further categorized according to the distribution of the ISCs among - the LSRs: - Each LSR may support just one ISC. - Such LSRs are known as single-switching-type-capable LSRs. - The MLN may comprise a set of single-switching-type-capable LSRs - that support different ISCs. + Such LSRs are known as single-switching-type-capable LSRs. The MLN + may comprise a set of single-switching-type-capable LSRs some of + which support different ISCs. + - Each LSR may support more than one ISC at the same time. - Such LSRs are known as multi-switching-type-capable LSRs, and - can be further classified as either ‘‘simplex’’ or hybrid’’ nodes - as defined in Section 4.2. + Such LSRs are known as multi-switching-type-capable LSRs, and can + be further classified as either "simplex" or "hybrid" nodes as + defined in Section 4.2. - - The MLN may be constructed from any combination of single-switching-type- - capable LSRs and multi-switching-type-capable LSRs. + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - Since GMPLS provides a comprehensive framework for the control of different - switching capabilities, a single GMPLS instance controlling the MLN/MRN enables - rapid service provisioning and efficient traffic engineering across all - switching capabilities. In such networks, TE Links are consolidated into a - single Traffic Engineering Database (TED). Since this TED contains the - information relative to all the different regions and layers existing in the - network, a path across multiple regions or layers can be computed using this TED. - Thus optimization of network resources can be achieved across the whole MLN/MRN. + - The MLN may be constructed from any combination of single- + switching-type-capable LSRs and multi-switching-type-capable LSRs. - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + Since GMPLS provides a comprehensive framework for the control of + different switching capabilities, a single GMPLS instance may be used + to control the MLN/MRN. This enables rapid service provisioning and + efficient traffic engineering across all switching capabilities. In + such networks, TE Links are consolidated into a single Traffic + Engineering Database (TED). Since this TED contains the information + relative to all the different regions and layers existing in the + network, a path across multiple regions or layers can be computed + using this TED. - Consider, for example, a MRN consisting of packet-switch capable routers and TDM - cross-connects. Assume that a packet LSP is routed between source and - destination packet-switch capable routers, and that the LSP can be routed across - the PSC-region (i.e., utilizing only resources of the packet region topology). - If the performance objective for the packet LSP is not satisfied, new TE links - may be created between the packet-switch capable routers across the TDM-region - (for example, VC-12 links) and the LSP can be routed over those TE links. - Further, even if the LSP can be successfully established across the PSC-region, - TDM hierarchical LSPs across the TDM region between the packet-switch capable - routers may be established and used if doing so is necessary to meet the - operator's objectives for network resources availability (e.g., link bandwidth, - or adaptation ports between regions) across the regions. The same considerations - hold when VC4 LSPs are provisioned to provide extra flexibility for the VC12 - and/or VC11 layers in an MLN. + Thus optimization of network resources can be achieved across the + whole MLN/MRN. Consider, for example, a MRN consisting of packet- + switch capable routers and TDM cross-connects. Assume that a packet + LSP is routed between source and destination packet-switch capable + routers, and that the LSP can be routed across the PSC-region (i.e., + utilizing only resources of the packet region topology). If the + performance objective for the packet LSP is not satisfied, new TE + links may be created between the packet-switch capable routers across + the TDM-region (for example, VC-12 links) and the LSP can be routed + over those TE links. - 1.1 Scope + Furthermore, even if the LSP can be successfully established across + the PSC-region, TDM hierarchical LSPs across the TDM region between + the packet-switch capable routers may be established and used if + doing so is necessary to meet the operator's objectives for network + resources availability (e.g., link bandwidth, or adaptation ports + between regions) across the regions. The same considerations hold + when VC4 LSPs are provisioned to provide extra flexibility for the + VC12 and/or VC11 layers in an MLN. - This document describes the requirements to support multi-region/multi-layer - networks. There is no intention to specify solution-specific and/or protocol - elements in this document. The applicability of existing GMPLS protocols and any - protocol extensions to the MRN/MLN is addressed in separate documents [MRN-EVAL]. +1.1. Scope - This document covers the elements of a single GMPLS control plane instance - controlling multiple layers within a given TE domain. A control plane instance - can serve one, two or more layers. Other possible approaches such as having - multiple control plane instances serving disjoint sets of layers are outside the - scope of this document. + This document describes the requirements to support multi-region/ + multi-layer networks. There is no intention to specify solution- + specific and/or protocol elements in this document. The applicability + of existing GMPLS protocols and any protocol extensions to the + MRN/MLN is addressed in separate documents [MRN-EVAL]. - For such TE domain to interoperate with edge nodes/domains supporting interfaces - by other SDOs e.g. ITU-T and OIF, an interworking function may be needed. - Location and specification of this function are outside the scope of this - document (because interworking aspects are strictly under the responsibility of - the interworking function.) + This document covers the elements of a single GMPLS control plane + instance controlling multiple layers within a given TE domain. A + control plane instance can serve one, two or more layers. Other + possible approaches such as having multiple control plane instances + serving disjoint sets of layers are outside the scope of this + document. It is most probable that such a MLN or MRN would be + operated by a single Service Provider, but this document does not + exclude the possibility of two layers (or regions) being under + different administrative control (for example, by different Service + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - This document assumes that the interconnection of adjacent MRN/MLN TE domains - makes use of [RFC4726] when their edges also support inter-domain GMPLS RSVP-TE - extensions. + Providers that share a single control plane instance) where the + administrative domains are prepared to share a limited amount of + information. - 2. Conventions Used in this Document + For such TE domain to interoperate with edge nodes/domains supporting + non-GMPLS interfaces (such as those defined by other SDOs), an + interworking function may be needed. Location and specification of + this function are outside the scope of this document (because + interworking aspects are strictly under the responsibility of the + interworking function). - Although this is not a protocol specification, the key words "MUST", "MUST NOT", - "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are used in this document to highlight requirements, and are to - be interpreted as described in RFC 2119 [RFC2119]. + This document assumes that the interconnection of adjacent MRN/MLN TE + domains makes use of [RFC4726] when their edges also support inter- + domain GMPLS RSVP-TE extensions. - 2.1.List of acronyms +2. Conventions Used in this Document - MLN: Multi-Layer Network - MRN: Multi-Region Network - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + Although this is not a protocol specification, the key words "MUST", + "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", + "RECOMMENDED", "MAY", and "OPTIONAL" are used in this document to + highlight requirements, and are to be interpreted as described in + RFC 2119 [RFC2119]. +2.1. List of Acronyms + + FA: Forwarding Adjacency + FA-LSP: Forwarding Adjacency Label Switched Path + FSC: Fiber Switching Capable ISC: Interface Switching Capability ISCD: Interface Switching Capability Descriptor - PSC: Packet Switching Capable L2SC: Layer-2 Switching Capable - TDM: Time-Division Switch Capable LSC: Lambda Switching Capable - FSC: Fiber Switching Capable + LSP: Label Switched Path + LSR: Label Switching Router + MLN: Multi-Layer Network + MRN: Multi-Region Network + PSC: Packet Switching Capable SRLG: Shared Risk Ling Group - VNT: Virtual Network Topology - FA: Forwarding Adjacency - FA-LSP: Forwarding Adjacency Label Switched Path + TDM: Time-Division Switch Capable TE: Traffic Engineering TED: Traffic Engineering Database - LSP: Label Switched Path - LSR: Label Switching Router + VNT: Virtual Network Topology 3. Positioning - A multi-region network (MRN) is always a multi-layer network (MLN) since the - network devices on region boundaries bring together different ISCs. A MLN, - however, is not necessarily a MRN since multiple layers could be fully contained - within a single region. For example, VC12, VC4, and VC4-4c are different layers - of the TDM region. + A multi-region network (MRN) is always a multi-layer network (MLN) + since the network devices on region boundaries bring together + different ISCs. A MLN, however, is not necessarily a MRN since + multiple layers could be fully contained within a single region. For + example, VC12, VC4, and VC4-4c are different layers of the TDM + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 + + region. 3.1. Data Plane Layers and Control Plane Regions - A data plane layer is a collection of network resources capable of terminating - and/or switching data traffic of a particular format [RFC4397]. These resources - can be used for establishing LSPs for traffic delivery. For example, VC-11 and - VC4-64c represent two different layers. + A data plane layer is a collection of network resources capable of + terminating and/or switching data traffic of a particular format + [RFC4397]. These resources can be used for establishing LSPs for + traffic delivery. For example, VC-11 and VC4-64c represent two + different layers. - From the control plane viewpoint, an LSP region is defined as a set of one or - more data plane layers that share the same type of switching technology, that is, - the same switching type. For example, VC-11, VC-4, and VC-4-7v layers are part - of the same TDM region. The regions that are currently defined are: PSC, L2SC, - TDM, LSC, and FSC. Hence, an LSP region is a technology domain (identified by - the ISC type) for which data plane resources (i.e., data links) are represented - into the control plane as an aggregate of TE information associated with a set - of links (i.e., TE links). For example VC-11 and VC4-64c capable TE links are - part of the same TDM region. Multiple layers can thus exist in a single region - network. + From the control plane viewpoint, an LSP region is defined as a set + of one or more data plane layers that share the same type of + switching technology, that is, the same switching type. For example, + VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. The + regions that are currently defined are: PSC, L2SC, TDM, LSC, and FSC. + Hence, an LSP region is a technology domain (identified by the ISC + type) for which data plane resources (i.e., data links) are + represented into the control plane as an aggregate of TE information + associated with a set of links (i.e., TE links). For example VC-11 + and VC4-64c capable TE links are part of the same TDM region. + Multiple layers can thus exist in a single region network. - Note also that the region may produce a distinction within the control plane. - Layers of the same region share the same switching technology and, therefore, - use the same set of technology-specific signaling objects and technology- - specific value setting of TE link attributes within the control plane, but - layers from different regions may use different technology-specific objects and - TE attribute values. This means that it may not be possible to simply forward - the signaling message between LSR hosting different switching technologies - because change in some of the signaling objects (for example, the traffic - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + Note also that the region may produce a distinction within the + control plane. Layers of the same region share the same switching + technology and, therefore, use the same set of technology-specific + signaling objects and technology-specific value setting of TE link + attributes within the control plane, but layers from different + regions may use different technology-specific objects and TE + attribute values. This means that it may not be possible to simply + forward the signaling message between LSR hosting different switching + technologies because change in some of the signaling objects (for + example, the traffic parameters) when crossing a region boundary even + if a single control plane instance is used to manage the whole MRN. + We may solve this issue by using triggered signaling (see Section + 4.3.1). - parameters) when crossing a region boundary even if a single control plane - instance is used to manage the whole MRN. We may solve the issue by using - triggered signaling (See 4.3.1). +3.2. Service Layer Networks - 3.2. Service layer networks + A service provider's network may be divided into different service + layers. The customer's network is considered from the provider's + perspective as the highest service layer. It interfaces to the + highest service layer of the service provider's network. Connectivity + across the highest service layer of the service provider's network + may be provided with support from successively lower service layers. + Service layers are realized via a hierarchy of network layers located + generally in several regions and commonly arranged according to the + switching capabilities of network devices. - A service provider's network may be divided into different service layers. The - customer's network is considered from the provider's perspective as the highest - service layer. It interfaces to the highest service layer of the service - provider's network. Connectivity across the highest service layer of the service - provider's network may be provided with support from successively lower service - layers. Service layers are realized via a hierarchy of network layers located - generally in several regions and commonly arranged according to the switching - capabilities of network devices. + For instance some customers purchase Layer 1 (i.e., transport) + services from the service provider, some Layer 2 (e.g., ATM), while + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - For instance some customers purchase Layer 1 (i.e., transport) services from the - service provider, some Layer 2 (e.g., ATM), while others purchase Layer 3 - (IP/MPLS) services. The service provider realizes the services by a stack of - network layers located within one or more network regions. The network layers - are commonly arranged according to the switching capabilities of the devices in - the networks. Thus, a customer network may be provided on top of the GMPLS-based - multi-region/multi-layer network. For example, a Layer 1 service (realized via - the network layers of TDM, and/or LSC, and/or FSC regions) may support a Layer 2 - network (realized via ATM VP/VC) which may itself support a Layer 3 network - (IP/MPLS region). The supported data plane relationship is a data plane client- - server relationship where the lower layer provides a service for the higher + others purchase Layer 3 (IP/MPLS) services. The service provider + realizes the services by a stack of network layers located within one + or more network regions. The network layers are commonly arranged + according to the switching capabilities of the devices in the + networks. Thus, a customer network may be provided on top of the + GMPLS-based multi-region/multi-layer network. For example, a Layer 1 + service (realized via the network layers of TDM, and/or LSC, and/or + FSC regions) may support a Layer 2 network (realized via ATM VP/VC) + which may itself support a Layer 3 network (IP/MPLS region). The + supported data plane relationship is a data plane client-server + relationship where the lower layer provides a service for the higher layer using the data links realized in the lower layer. - Services provided by a GMPLS-based multi-region/multi-layer network are referred - to as "Multi-region/Multi-layer network services". For example, legacy IP and - IP/MPLS networks can be supported on top of multi-region/multi-layer networks. - It has to be emphasized that delivery of such diverse services is a strong - motivator for the deployment of multi-region/multi-layer networks. + Services provided by a GMPLS-based multi-region/multi-layer network + are referred to as "Multi-region/Multi-layer network services". For + example, legacy IP and IP/MPLS networks can be supported on top of + multi-region/multi-layer networks. It has to be emphasized that + delivery of such diverse services is a strong motivator for the + deployment of multi-region/multi-layer networks. - A customer network may be provided on top of a server GMPLS-based MRN/MLN which - is operated by a service provider. For example, a pure IP and/or an IP/MPLS - network can be provided on top of GMPLS-based packet over optical networks - [MPLS-GMPLS]. The relationship between the networks is a client/server - relationship and, such services are referred to as "MRN/MLN services". In this - case, the customer network may form part of the MRN/MLN, or may be partially - separated, for example to maintain separate routing information but retain - common signaling. + A customer network may be provided on top of a server GMPLS-based + MRN/MLN which is operated by a service provider. For example, a pure + IP and/or an IP/MPLS network can be provided on top of GMPLS-based + packet over optical networks [MPLS-GMPLS]. The relationship between + the networks is a client/server relationship and, such services are + referred to as "MRN/MLN services". In this case, the customer network + may form part of the MRN/MLN, or may be partially separated, for + example to maintain separate routing information but retain common + signaling. - 3.3. Vertical and Horizontal interaction and integration +3.3. Vertical and Horizontal Interaction and Integration - Vertical interaction is defined as the collaborative mechanisms within a network - element that is capable of supporting more than one layer or region and of - realizing the client/server relationships between the layers or regions. - Protocol exchanges between two network controllers managing different regions or - layers are also a vertical interaction. Integration of these interactions as - part of the control plane is referred to as vertical integration. Thus, this - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + Vertical interaction is defined as the collaborative mechanisms + within a network element that is capable of supporting more than one + layer or region and of realizing the client/server relationships + between the layers or regions. Protocol exchanges between two network + controllers managing different regions or layers are also a vertical + interaction. Integration of these interactions as part of the control + plane is referred to as vertical integration. Thus, this refers to + the collaborative mechanisms within a single control plane instance + driving multiple network layers part of the same region or not. Such + a concept is useful in order to construct a framework that + facilitates efficient network resource usage and rapid service + provisioning in carrier networks that are based on multiple layers, + switching technologies, or ISCs. - refers to the collaborative mechanisms within a single control plane instance - driving multiple network layers part of the same region or not. Such a concept - is useful in order to construct a framework that facilitates efficient network - resource usage and rapid service provisioning in carrier networks that are based - on multiple layers, switching technologies, or ISCs. + Horizontal interaction is defined as the protocol exchange between + network controllers that manage transport nodes within a given layer + or region. For instance, the control plane interaction between two + TDM network elements switching at OC-48 is an example of horizontal + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - Horizontal interaction is defined as the protocol exchange between network - controllers that manage transport nodes within a given layer or region. For - instance, the control plane interaction between two TDM network elements - switching at OC-48 is an example of horizontal interaction. GMPLS protocol - operations handle horizontal interactions within the same routing area. The case - where the interaction takes place across a domain boundary, such as between two - routing areas within the same network layer, is evaluated as part of the inter- - domain work [RFC4726], and is referred to as horizontal integration. Thus, - horizontal integration refers to the collaborative mechanisms between network - partitions and/or administrative divisions such as routing areas or autonomous - systems. + interaction. GMPLS protocol operations handle horizontal interactions + within the same routing area. The case where the interaction takes + place across a domain boundary, such as between two routing areas + within the same network layer, is evaluated as part of the inter- + domain work [RFC4726], and is referred to as horizontal integration. + Thus, horizontal integration refers to the collaborative mechanisms + between network partitions and/or administrative divisions such as + routing areas or autonomous systems. - This distinction needs further clarification when administrative domains match - layer/region boundaries. Horizontal interaction is extended to cover such cases. - For example, the collaborative mechanisms in place between two lambda switching - capable areas relate to horizontal integration. On the other hand, the - collaborative mechanisms in place between a packet switching capable (e.g. - IP/MPLS) domain over a different time division switching capable (eg VC4 SDH) - domain is part of the horizontal integration while it can be seen as a first - step towards vertical integration. + This distinction needs further clarification when administrative + domains match layer/region boundaries. Horizontal interaction is + extended to cover such cases. For example, the collaborative + mechanisms in place between two lambda switching capable areas relate + to horizontal integration. On the other hand, the collaborative + mechanisms in place between a packet switching capable (e.g., + IP/MPLS) domain and a separate time division switching capable + (e.g., VC4 SDH) domain over which it operates are part of the + horizontal integration while it can also be seen as a first step + towards vertical integration. 3.4.Motivation - The applicability of GMPLS to multiple switching technologies provides the - unified control management approach for both LSP provisioning and recovery. - Indeed, one of the main motivations for unifying the capabilities and operations - GMPLS control plane is the desire to support multi LSP-region [RFC4206] routing - and Traffic Engineering (TE) capability. For instance, this enables effective - network resource utilization of both the Packet/Layer2 LSP regions and the Time - Division Multiplexing (TDM) or Lambda LSP regions in high capacity networks. + The applicability of GMPLS to multiple switching technologies + provides a unified control and management approach for both LSP + provisioning and recovery. Indeed, one of the main motivations for + unifying the capabilities and operations of the GMPLS control plane + is the desire to support multi-LSP-region [RFC4206] routing and + Traffic Engineering (TE) capabilities. For instance, this enables + effective network resource utilization of both the Packet/Layer2 LSP + regions and the Time Division Multiplexing (TDM) or Lambda LSP + regions in high capacity networks. + + The rationales for GMPLS controlled multi-layer/multi-region networks + are summarized below: + + - The maintenance of multiple instances of the control plane on + devices hosting more than one switching capability not only + increases the complexity of their interactions but also increases + the total amount of processing individual instances would handle. - The rationales for GMPLS controlled multi-layer/multi-region networks context - are summarized here below: - - The maintenance of multiple instances of the control plane on devices hosting - more than one switching capability not only increases the complexity of their - interactions but also increases the total amount of processing individual - instances would handle. - The unification of the addressing spaces helps in avoiding multiple - identification for the same object (a link for instance or more generally any - network resource), on the other hand such aggregation does not impact the - separation between the control and the data plane. - - By maintaining a single routing protocol instance and a single TE database - per LSR, a unified control plane model prevents from maintaining a dedicated - routing topology per layer and therefore does not mandate a full mesh of - routing adjacencies as it is the case with overlaid control planes. + identifiers for the same object (a link, for instance, or more + generally, any network resource). On the other hand such + aggregation does not impact the separation between the control + plane and the data plane. - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + - By maintaining a single routing protocol instance and a single TE + database per LSR, a unified control plane model removes the + requirement to maintain a dedicated routing topology per layer and + therefore does not mandate a full mesh of routing adjacencies as is + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 + + the case with overlaid control planes. + + - The collaboration between technology layers where the control + channel is associated with the data channel (e.g. packet/framed + data planes) and technology layers where the control channel is not + directly associated with the data channel (SONET/SDH, G.709, etc.) + is facilitated by the capability within GMPLS to associate in-band + control plane signaling to the IP terminating interfaces of the + control plane. - - The collaboration between associated control planes (packet/framed data - planes) and non-associated control planes (SONET/SDH, G.709, etc.) is - facilitated due to the capability of hooking the associated in-band signaling - to the IP terminating interfaces of the control plane. - Resource management and policies to be applied at the edges of such - environment is facilitated (less control to management interactions) and more - scalable (through the use of aggregated information). - - Multi-region/multi-layer traffic engineering is facilitated as TE-links from - distinct regions/layers are stored within the same TE Database. + a MRN/MLN is made more simple (fewer control to management + interactions) and more scalable (through the use of aggregated + information). + + - Multi-region/multi-layer traffic engineering is facilitated as + TE-links from distinct regions/layers are stored within the same TE + Database. 4. Key Concepts of GMPLS-Based MLNs and MRNs - A network comprising transport nodes with multiple data plane layers of either - the same ISC or different ISCs, controlled by a single GMPLS control plane - instance, is called a Multi-Layer Network (MLN). A sub-set of MLNs consists of - networks supporting LSPs of different switching technologies (ISCs). A network - supporting more than one switching technology is called a Multi-Region Network - (MRN). + A network comprising transport nodes with multiple data plane layers + of either the same ISC or different ISCs, controlled by a single + GMPLS control plane instance, is called a Multi-Layer Network (MLN). + A sub-set of MLNs consists of networks supporting LSPs of different + switching technologies (ISCs). A network supporting more than one + switching technology is called a Multi-Region Network (MRN). 4.1. Interface Switching Capability - The Interface Switching Capability (ISC) is introduced in GMPLS to support - various kinds of switching technology in a unified way [RFC4202]. An ISC is - identified via a switching type. + The Interface Switching Capability (ISC) is introduced in GMPLS to + support various kinds of switching technology in a unified way + [RFC4202]. An ISC is identified via a switching type. - A switching type (also referred to as the switching capability type) describes - the ability of a node to forward data of a particular data plane technology, and - uniquely identifies a network region. The following ISC types (and, hence, - regions) are defined: PSC, L2SC, TDM, LSC, and FSC. Each end of a data link - (more precisely, each interface connecting a data link to a node) in a GMPLS - network is associated with an ISC. + A switching type (also referred to as the switching capability type) + describes the ability of a node to forward data of a particular data + plane technology, and uniquely identifies a network region. The + following ISC types (and, hence, regions) are defined: PSC, L2SC, + TDM, LSC, and FSC. Each end of a data link (more precisely, each + interface connecting a data link to a node) in a GMPLS network is + associated with an ISC. - The ISC value is advertised as a part of the Interface Switching Capability - Descriptor (ISCD) attribute (sub-TLV) of a TE link end associated with a - particular link interface [RFC4202]. Apart from the ISC, the ISCD contains - information including the encoding type, the bandwidth granularity, and the - unreserved bandwidth on each of eight priorities at which LSPs can be - established. The ISCD does not "identify" network layers, it uniquely - characterizes information associated to one or more network layers. + The ISC value is advertised as a part of the Interface Switching + Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end + associated with a particular link interface [RFC4202]. Apart from the + ISC, the ISCD contains information including the encoding type, the + bandwidth granularity, and the unreserved bandwidth on each of eight + priorities at which LSPs can be established. The ISCD does not + "identify" network layers, it uniquely characterizes information + associated to one or more network layers. - TE link end advertisements may contain multiple ISCDs. This can be interpreted - as advertising a multi-layer (or multi-switching-capable) TE link end. That is, - the TE link end (and therefore the TE link) is present in multiple layers. + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - 4.2. Multiple Interface Switching Capabilities + TE link end advertisements may contain multiple ISCDs. This can be + interpreted as advertising a multi-layer (or multi-switching-capable) + TE link end. That is, the TE link end (and therefore the TE link) is + present in multiple layers. - In an MLN, network elements may be single-switching-type-capable or multi- - switching-type-capable nodes. Single-switching-type-capable nodes advertise the - same ISC value as part of their ISCD sub-TLV(s) to describe the termination - capabilities of each of their TE Link(s). This case is described in [RFC4202]. +4.2. Multiple Interface Switching Capabilities - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + In an MLN, network elements may be single-switching-type-capable or + multi-switching-type-capable nodes. Single-switching-type-capable + nodes advertise the same ISC value as part of their ISCD sub-TLV(s) + to describe the termination capabilities of each of their TE Link(s). + This case is described in [RFC4202]. - Multi-switching-type-capable LSRs are classified as "simplex" or "hybrid" nodes. - Simplex and hybrid nodes are categorized according to the way they advertise - these multiple ISCs: + Multi-switching-type-capable LSRs are classified as "simplex" or + "hybrid" nodes. Simplex and hybrid nodes are categorized according to + the way they advertise these multiple ISCs: - - A simplex node can terminate data links with different switching capabilities - where each data link is connected to the node by a separate link interface. - So, it advertises several TE Links each with a single ISC value carried in - its ISCD sub-TLV. For example, an LSR with PSC and TDM links each of which is - connected to the LSR via a separate interface. + - A simplex node can terminate data links with different switching + capabilities where each data link is connected to the node by a + separate link interface. So, it advertises several TE Links each + with a single ISC value carried in its ISCD sub-TLV. For example, + an LSR with PSC and TDM links each of which is connected to the LSR + via a separate interface. - - A hybrid node can terminate data links with different switching capabilities - where the data links are connected to the node by the same interface. So, it - advertises a single TE Link containing more than one ISCD each with a - different ISC value. For example, a node may terminate PSC and TDM data links - and interconnect those external data links via internal links. The external - interfaces connected to the node have both PSC and TDM capabilities. + - A hybrid node can terminate data links with different switching + capabilities where the data links are connected to the node by the + same interface. So, it advertises a single TE Link containing more + than one ISCD each with a different ISC value. For example, a node + may terminate PSC and TDM data links and interconnect those + external data links via internal links. The external interfaces + connected to the node have both PSC and TDM capabilities. - Additionally, TE link advertisements issued by a simplex or a hybrid node may - need to provide information about the node's internal adaptation capabilities - between the switching technologies supported. That is, the node's capability to - perform layer border node functions. + Additionally, TE link advertisements issued by a simplex or a hybrid + node may need to provide information about the node's internal + adaptation capabilities between the switching technologies supported. + That is, the node's capability to perform layer border node + functions. This information allows path computation to select an end- + to-end multi-layer or multi-region path that includes links of + different switching capabilities that are joined by LSRs that can + adapt the signal between the links. 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes - This type of network contains at least one hybrid node, zero or more simplex - nodes, and a set of single-switching-type-capable nodes. + This type of network contains at least one hybrid node, zero or more + simplex nodes, and a set of single-switching-type-capable nodes. - Figure 1 shows an example hybrid node. The hybrid node has two switching - elements (matrices), which support, for instance, TDM and PSC switching - respectively. The node terminates a PSC and a TDM link (Link1 and Link2 - respectively). It also has an internal link connecting the two switching - elements. + Figure 1 shows an example hybrid node. The hybrid node has two + switching elements (matrices), which support, for instance, TDM and + PSC switching respectively. The node terminates a PSC and a TDM link + (Link1 and Link2 respectively). It also has an internal link + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - The two switching elements are internally interconnected in such a way that it - is possible to terminate some of the resources of, say, Link2 and provide - adaptation for PSC traffic received/sent over the PSC interface (#b). This - situation is modeled in GMPLS by connecting the local end of Link2 to the TDM - switching element via an additional interface realizing the - termination/adaptation function. There are two possible ways to set up PSC LSPs - through the hybrid node. Available resource advertisement (i.e., Unreserved and - Min/Max LSP Bandwidth) should cover both of these methods. + 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, say, + Link2 and provide adaptation for PSC traffic received/sent over the + PSC interface (#b). This situation is modeled in GMPLS by connecting + the local end of Link2 to the TDM switching element via an additional + interface realizing the termination/adaptation function. There are + two possible ways to set up PSC LSPs through the hybrid node. + Available resource advertisement (i.e., Unreserved and Min/Max LSP + Bandwidth) should cover both of these methods. Network element ............................. : -------- : : | PSC | : Link1 -------------<->--|#a | : + : | | : : +--<->---|#b | : : | -------- : - TDM : | ---------- : - +PSC : +--<->--|#c TDM | : - - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 - + : | ---------- : + TDM : +--<->--|#c TDM | : + +PSC : | | : Link2 ------------<->--|#d | : : ---------- : :............................ Figure 1. Hybrid node. 4.3. Integrated Traffic Engineering (TE) and Resource Control - In GMPLS-based multi-region/multi-layer networks, TE Links may be consolidated - into a single Traffic Engineering Database (TED) for use by the single control - plane instance. Since this TED contains the information relative to all the - layers of all regions in the network, a path across multiple layers (possibly - crossing multiple regions) can be computed using the information in this TED. - Thus, optimization of network resources across the multiple layers of the same - region and across multiple regions can be achieved. + In GMPLS-based multi-region/multi-layer networks, TE Links may be + consolidated into a single Traffic Engineering Database (TED) for use + by the single control plane instance. Since this TED contains the + information relative to all the layers of all regions in the network, + a path across multiple layers (possibly crossing multiple regions) + can be computed using the information in this TED. Thus, optimization + of network resources across the multiple layers of the same region + and across multiple regions can be achieved. - These concepts allow for the operation of one network layer over the topology - (that is, TE links) provided by other network layers (for example, the use of a - lower layer LSC LSP carrying PSC LSPs). In turn, a greater degree of control and - inter-working can be achieved, including (but not limited too): + These concepts allow for the operation of one network layer over the + topology (that is, TE links) provided by other network layers (for + example, the use of a lower layer LSC LSP carrying PSC LSPs). In + turn, a greater degree of control and inter-working can be achieved, + including (but not limited too): - Dynamic establishment of Forwarding Adjacency (FA) LSPs [RFC4206] (see Sections 4.3.2 and 4.3.3). + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 + - Provisioning of end-to-end LSPs with dynamic triggering of FA LSPs. - Note that in a multi-layer/multi-region network that includes multi-switching- - type-capable nodes, an explicit route used to establish an end-to-end LSP can - specify nodes that belong to different layers or regions. In this case, a - mechanism to control the dynamic creation of FA LSPs may be required (see - Sections 4.3.2 and 4.3.3). + Note that in a multi-layer/multi-region network that includes multi- + switching-type-capable nodes, an explicit route used to establish an + end-to-end LSP can specify nodes that belong to different layers or + regions. In this case, a mechanism to control the dynamic creation of + FA-LSPs may be required (see Sections 4.3.2 and 4.3.3). - There is a full spectrum of options to control how FA LSPs are dynamically - established. The process can be subject to the control of a policy, which may be - set by a management component, and which may require that the management plane - is consulted at the time that the FA LSP is established. Alternatively, the FA - LSP can be established at the request of the control plane without any - management control. + There is a full spectrum of options to control how FA-LSPs are + dynamically established. The process can be subject to the control of + a policy, which may be set by a management component, and which may + require that the management plane is consulted at the time that the + FA-LSP is established. Alternatively, the FA-LSP can be established + at the request of the control plane without any management control. 4.3.1. Triggered Signaling - When an LSP crosses the boundary from an upper to a lower layer, it may be - nested into a lower layer FA LSP that crosses the lower layer. From a signaling - perspective, there are two alternatives to establish the lower layer FA LSP: - static (pre-provisioned) and dynamic (triggered). A pre-provisioned FA-LSP may - be initiated either by the operator or automatically using features like TE - auto-mesh [AUTO-MESH]. If such a lower layer LSP does not already exist, the LSP - may be established dynamically. Such a mechanism is referred to as "triggered - signaling". - - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + When an LSP crosses the boundary from an upper to a lower layer, it + may be nested into a lower layer FA-LSP that crosses the lower layer. + From a signaling perspective, there are two alternatives to establish + the lower layer FA-LSP: static (pre-provisioned) and dynamic + (triggered). A pre-provisioned FA-LSP may be initiated either by the + operator or automatically using features like TE auto-mesh + [RFC4972]. If such a lower layer LSP does not already exist, the LSP + may be established dynamically. Such a mechanism is referred to as + "triggered signaling". 4.3.2. FA-LSPs - Once an LSP is created across a layer from one layer border node to another, it - can be used as a data link in an upper layer. + Once an LSP is created across a layer from one layer border node to + another, it can be used as a data link in an upper layer. - Furthermore, it can be advertised as a TE-link, allowing other nodes to consider - the LSP as a TE link for their path computation [RFC4206]. An LSP created either - statically or dynamically by one instance of the control plane and advertised as - a TE link into the same instance of the control plane is called a Forwarding - Adjacency LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE link - is called a Forwarding Adjacency (FA). An FA has the special characteristic of - not requiring a routing adjacency (peering) between its end points yet still - guaranteeing control plane connectivity between the FA-LSP end points based on a - signaling adjacency. An FA is a useful and powerful tool for improving the - scalability of GMPLS Traffic Engineering (TE) capable networks since multiple - higher layer LSPs may be nested (aggregated) over a single FA-LSP. + Furthermore, it can be advertised as a TE-link, allowing other nodes + to consider the LSP as a TE link for their path computation + [RFC4206]. An LSP created either statically or dynamically by one + instance of the control plane and advertised as a TE link into the + same instance of the control plane is called a Forwarding Adjacency + LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE link + is called a Forwarding Adjacency (FA). An FA has the special + characteristic of not requiring a routing adjacency (peering) between + its end points yet still guaranteeing control plane connectivity + between the FA-LSP end points based on a signaling adjacency. An FA + is a useful and powerful tool for improving the scalability of GMPLS + Traffic Engineering (TE) capable networks since multiple higher layer + LSPs may be nested (aggregated) over a single FA-LSP. - The aggregation of LSPs enables the creation of a vertical (nested) LSP - Hierarchy. A set of FA-LSPs across or within a lower layer can be used during - path selection by a higher layer LSP. Likewise, the higher layer LSPs may be - carried over dynamic data links realized via LSPs (just as they are carried over - any "regular" static data links). This process requires the nesting of LSPs - through a hierarchical process [RFC4206]. The TED contains a set of LSP - advertisements from different layers that are identified by the ISCD contained - within the TE link advertisement associated with the LSP [RFC4202]. + The aggregation of LSPs enables the creation of a vertical (nested) + LSP Hierarchy. A set of FA-LSPs across or within a lower layer can be + used during path selection by a higher layer LSP. Likewise, the + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - If a lower layer LSP is not advertised as an FA, it can still be used to carry - higher layer LSPs across the lower layer. For example, if the LSP is set up - using triggered signaling, it will be used to carry the higher layer LSP that - caused the trigger. Further, the lower layer remains available for use by other - higher layer LSPs arriving at the boundary. + higher layer LSPs may be carried over dynamic data links realized via + LSPs (just as they are carried over any "regular" static data links). + This process requires the nesting of LSPs through a hierarchical + process [RFC4206]. The TED contains a set of LSP advertisements from + different layers that are identified by the ISCD contained within the + TE link advertisement associated with the LSP [RFC4202]. - Under some circumstances it may be useful to control the advertisement of LSPs - as FAs during the signaling establishment of the LSPs [DYN-HIER]. + If a lower layer LSP is not advertised as an FA, it can still be used + to carry higher layer LSPs across the lower layer. For example, if + the LSP is set up using triggered signaling, it will be used to carry + the higher layer LSP that caused the trigger. Further, the lower + layer remains available for use by other higher layer LSPs arriving + at the boundary. + + Under some circumstances it may be useful to control the + advertisement of LSPs as FAs during the signaling establishment of + the LSPs [DYN-HIER]. 4.3.3. Virtual Network Topology (VNT) - A set of one or more of lower-layer LSPs provides information for efficient path - handling in upper-layer(s) of the MLN, or, in other words, provides a virtual - network topology (VNT) to the upper-layers. For instance, a set of LSPs, each of - which is supported by an LSC LSP, provides a virtual network topology to the - layers of a PSC region, assuming that the PSC region is connected to the LSC - region. Note that a single lower-layer LSP is a special case of the VNT. The - virtual network topology is configured by setting up or tearing down the lower - layer LSPs. By using GMPLS signaling and routing protocols, the virtual network - topology can be adapted to traffic demands. + A set of one or more of lower-layer LSPs provides information for + efficient path handling in upper-layer(s) of the MLN, or, in other + words, provides a virtual network topology (VNT) to the upper-layers. + For instance, a set of LSPs, each of which is supported by an LSC + LSP, provides a virtual network topology to the layers of a PSC + region, assuming that the PSC region is connected to the LSC region. + Note that a single lower-layer LSP is a special case of the VNT. The + virtual network topology is configured by setting up or tearing down + the lower layer LSPs. By using GMPLS signaling and routing protocols, + the virtual network topology can be adapted to traffic demands. - A lower-layer LSP appears as a TE-link in the VNT. Whether the diversely-routed - lower-layer LSPs are used or not, the routes of lower-layer LSPs are hidden from - the upper layer in the VNT. Thus, the VNT simplifies the upper-layer routing and - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + A lower-layer LSP appears as a TE-link in the VNT. Whether the + diversely-routed lower-layer LSPs are used or not, the routes of + lower-layer LSPs are hidden from the upper layer in the VNT. Thus, + the VNT simplifies the upper-layer routing and traffic engineering + decisions by hiding the routes taken by the lower-layer LSPs. + However, hiding the routes of the lower-layer LSPs may lose important + information that is needed to make the higher-layer LSPs reliable. + For instance, the routing and traffic engineering in the IP/MPLS + layer does not usually consider how the IP/MPLS TE links are formed + from optical paths that are routed in the fiber layer. Two optical + paths may share the same fiber link in the lower-layer and therefore + they may both fail if the fiber link is cut. Thus the shared risk + properties of the TE links in the VNT must be made available to the + higher layer during path computation. Further, the topology of the + VNT should be designed so that any single fiber cut does not bisect + the VNT. These issues are addressed later in this document. - traffic engineering decisions by hiding the routes taken by the lower-layer LSPs. - However hiding the routes of the lower-layer LSPs may lose important information - that is needed to make the higher-layer LSPs reliable. For instance, the routing - and traffic engineering in the IP/MPLS layer does not usually consider how the - IP/MPLS TE links are formed from optical paths that are routed in the fiber - layer. Two optical paths may share the same fiber link in the lower-layer and - therefore they may both fail if the fiber link is cut. Thus the shared risk - properties of the TE links in the VNT must be made available to the higher layer - during path computation. Further, the topology of the VNT should be designed so - that any single fiber cut does not bisect the VNT. These issues are addressed - later in this document. + Reconfiguration of the virtual network topology may be triggered by + traffic demand changes, topology configuration changes, signaling + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - Reconfiguration of the virtual network topology may be triggered by traffic - demand changes, topology configuration changes, signaling requests from the - upper layer, and network failures. For instance, by reconfiguring the virtual - network topology according to the traffic demand between source and destination - node pairs, network performance factors, such as maximum link utilization and - residual capacity of the network, can be optimized. Reconfiguration is performed - by computing the new VNT from the traffic demand matrix and optionally from the - current VNT. Exact details are outside the scope of this document. However, this - method may be tailored according to the service provider's policy regarding - network performance and quality of service (delay, loss/disruption, utilization, - residual capacity, reliability). + requests from the upper layer, and network failures. For instance, by + reconfiguring the virtual network topology according to the traffic + demand between source and destination node pairs, network performance + factors, such as maximum link utilization and residual capacity of + the network, can be optimized. Reconfiguration is performed by + computing the new VNT from the traffic demand matrix and optionally + from the current VNT. Exact details are outside the scope of this + document. However, this method may be tailored according to the + service provider's policy regarding network performance and quality + of service (delay, loss/disruption, utilization, residual capacity, + reliability). 5.Requirements 5.1.Handling Single-Switching and Multi-Switching-Type-Capable Nodes - The MRN/MLN can consist of single-switching-type-capable and multi-switching- - type-capable nodes. The path computation mechanism in the MLN SHOULD be able to - compute paths consisting of any combination of such nodes. + The MRN/MLN can consist of single-switching-type-capable and multi- + switching-type-capable nodes. The path computation mechanism in the + MLN SHOULD be able to compute paths consisting of any combination of + such nodes. - Both single-switching-type-capable and multi-switching-type-capable (simplex or - hybrid) nodes could play the role of layer boundary. MRN/MLN Path computation - SHOULD handle TE topologies built of any combination of nodes + Both single-switching-type-capable and multi-switching-type-capable + (simplex or hybrid) nodes could play the role of layer boundary. + MRN/MLN Path computation SHOULD handle TE topologies built of any + combination of nodes. 5.2. Advertisement of the Available Adaptation Resource - A hybrid node SHOULD maintain resources on its internal links (the links - required for vertical (layer) integration) and SHOULD advertise the resource - information for those links. Likewise, path computation elements SHOULD be - prepared to use the availability of termination/adaptation resources as a - constraint in MRN/MLN path computations to reduce the higher layer LSP setup - blocking probability caused by the lack of necessary termination/ adaptation - resources in the lower layer(s). + A hybrid node SHOULD maintain resources on its internal links (the + links required for vertical (layer) integration) and SHOULD advertise + the resource information for those links. Likewise, path computation + elements SHOULD be prepared to use the availability of termination/ + adaptation resources as a constraint in MRN/MLN path computations to + reduce the higher layer LSP setup blocking probability caused by the + lack of necessary termination/adaptation resources in the lower + layer(s). - The advertisement of the adaptation capability to terminate LSPs of lower-region - and forward traffic in the upper-region is REQUIRED, as it provides critical - information when performing multi-region path computation. + The advertisement of the adaptation capability to terminate LSPs of + lower-region and forward traffic in the upper-region is REQUIRED, as + it provides critical information when performing multi-region path + computation. - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + The mechanism SHOULD cover the case where the upper-layer links which + are directly connected to upper-layer switching element and the ones + which are connected through internal links between upper-layer + element and lower-layer element coexist (see Section 4.2.1). - The mechanism SHOULD cover the case where the upper-layer links which are - directly connected to upper-layer switching element and the ones which are - connected through internal links between upper-layer element and lower-layer - element coexist (See section 4.2.1). + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 5.3. Scalability - The MRN/MLN relies on a unified traffic engineering and routing model. - - Unified routing model: by maintaining a single routing protocol instance and - a single TE database per LSR, a unified control plane model prevents from - maintaining a dedicated routing topology per layer and therefore does not - mandate a full mesh of routing adjacencies per layer. - - Unified TE model: the TED in each LSR is populated with TE-links from all - layers of all regions (TE links interfaces on multiple-switching capability - LSR can be advertised with multiple ISCD). This may lead to a large amount of - information that has to be flooded and stored within the network. + The MRN/MLN relies on unified routing and traffic engineering + models. - Furthermore, path computation times, which may be of great importance during - restoration, will depend on the size of the TED. + - Unified routing model: By maintaining a single routing protocol + instance and a single TE database per LSR, a unified control plane + model removes the requirement to maintain a dedicated routing + topology per layer, and therefore does not mandate a full mesh of + routing adjacencies per layer. + + - Unified TE model: The TED in each LSR is populated with TE-links + from all layers of all regions (TE link interfaces on multiple- + switching-capability LSRs can be advertised with multiple ISCDs). + This may lead to an increase in the amount of information that has + to be flooded and stored within the network. + + Furthermore, path computation times, which may be of great importance + during restoration, will depend on the size of the TED. + + Thus MRN/MLN routing mechanisms MUST be designed to scale well with + an increase of any of the following: - Thus MRN/MLN routing mechanisms MUST be designed to scale well with an increase - of any of the following: - Number of nodes - Number of TE-links (including FA-LSPs) - Number of LSPs - Number of regions and layers - Number of ISCDs per TE-link. - Further, design of the routing protocols MUST NOT prevent TE information - filtering based on ISCDs. The path computation mechanism and the signaling - protocol SHOULD be able to operate on partial TE information. + Further, design of the routing protocols MUST NOT prevent TE + information filtering based on ISCDs. The path computation mechanism + and the signaling protocol SHOULD be able to operate on partial TE + information. - Since TE Links can advertise multiple Interface Switching Capabilities (ISC), - the number of links can be limited (by combination) by using specific - topological maps referred to as VNT (Virtual Network Topologies). The - introduction of virtual topological maps leads us to consider the concept of - emulation of data plane overlays. + Since TE Links can advertise multiple Interface Switching + Capabilities (ISCs), the number of links can be limited (by + combination) by using specific topological maps referred to as VNT + (Virtual Network Topologies). The introduction of virtual topological + maps leads us to consider the concept of emulation of data plane + overlays. 5.4.Stability - Path computation is dependent on the network topology and associated link state. - The path computation stability of an upper layer may be impaired if the VNT - changes frequently and/or if the status and TE parameters (the TE metric, for - instance) of links in the VNT changes frequently. In this context, robustness of - the VNT is defined as the capability to smooth changes that may occur and avoid - their propagation into higher layers. Changes to the VNT may be caused by the - creation, deletion, or modification of LSPs. + Path computation is dependent on the network topology and associated + link state. The path computation stability of an upper layer may be + impaired if the VNT changes frequently and/or if the status and TE + parameters (the TE metric, for instance) of links in the VNT changes + frequently. In this context, robustness of the VNT is defined as the + capability to smooth changes that may occur and avoid their + propagation into higher layers. Changes to the VNT may be caused by + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - Creation, deletion, and modification of LSPs MAY be triggered by adjacent layers - or through operational actions to meet traffic demand changes, topology changes, - signaling requests from the upper layer, and network failures. Routing - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + the creation, deletion, or modification of LSPs. - robustness SHOULD be traded with adaptability with respect to the change of - incoming traffic requests. + Creation, deletion, and modification of LSPs MAY be triggered by + adjacent layers or through operational actions to meet traffic demand + changes, topology changes, signaling requests from the upper layer, + and network failures. Routing robustness SHOULD be traded with + adaptability with respect to the change of incoming traffic requests. 5.5.Disruption Minimization - When reconfiguring the VNT according to a change in traffic demand, the upper- - layer LSP might be disrupted. Such disruption to the upper layers MUST be - minimized. + When reconfiguring the VNT according to a change in traffic demand, + the upper-layer LSP might be disrupted. Such disruption to the upper + layers MUST be minimized. - When residual resource decreases to a certain level, some lower layer LSPs MAY - be released according to local or network policies. There is a trade-off between - minimizing the amount of resource reserved in the lower layer and disrupting - higher layer traffic (i.e. moving the traffic to other TE-LSPs so that some LSPs - can be released). Such traffic disruption MAY be allowed, but MUST be under the - control of policy that can be configured by the operator. Any repositioning of - traffic MUST be as non-disruptive as possible (for example, using make-before- - break). + When residual resource decreases to a certain level, some lower layer + LSPs MAY be released according to local or network policies. There is + a trade-off between minimizing the amount of resource reserved in the + lower layer and disrupting higher layer traffic (i.e. moving the + traffic to other TE-LSPs so that some LSPs can be released). Such + traffic disruption MAY be allowed, but MUST be under the control of + policy that can be configured by the operator. Any repositioning of + traffic MUST be as non-disruptive as possible (for example, using + make-before-break). 5.6.LSP Attribute Inheritance - TE-Link parameters SHOULD be inherited from the parameters of the LSP that - provides the TE-link, and so from the TE-links in the lower layer that are - traversed by the LSP. + TE-Link parameters SHOULD be inherited from the parameters of the LSP + that provides the TE-link, and so from the TE-links in the lower + layer that are traversed by the LSP. These include: - Interface Switching Capability - TE metric - Maximum LSP bandwidth per priority level - Unreserved bandwidth for all priority levels - Maximum Reservable bandwidth - Protection attribute - Minimum LSP bandwidth (depending on the Switching Capability) - SRLG - Inheritance rules MUST be applied based on specific policies. Particular - attention should be given to the inheritance of TE metric (which may be other - than a strict sum of the metrics of the component TE links at the lower layer), - protection attributes, and SRLG. + Inheritance rules MUST be applied based on specific policies. + Particular attention should be given to the inheritance of TE metric + (which may be other than a strict sum of the metrics of the component + TE links at the lower layer), protection attributes, and SRLG. - As described earlier, hiding the routes of the lower-layer LSPs may lose - important information necessary to make LSPs in the higher layer network - reliable. SRLGs may be used to identify which lower-layer LSPs share the same - failure risk so that the potential risk of the VNT becoming disjoint can be - minimized, and so that resource disjoint protection paths can be set up in the - higher layer. How to inherit the SRLG information from the lower layer to the - upper layer needs more discussion and is out of scope of this document. + As described earlier, hiding the routes of the lower-layer LSPs may + lose important information necessary to make LSPs in the higher layer + network reliable. SRLGs may be used to identify which lower-layer + LSPs share the same failure risk so that the potential risk of the + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + VNT becoming disjoint can be minimized, and so that resource disjoint + protection paths can be set up in the higher layer. How to inherit + the SRLG information from the lower layer to the upper layer needs + more discussion and is out of scope of this document. 5.7.Computing Paths With and Without Nested Signaling - Path computation MAY take into account LSP region and layer boundaries when - computing a path for an LSP. For example, path computation MAY restrict the path - taken by an LSP to only the links whose interface switching capability is PSC. + Path computation MAY take into account LSP region and layer + boundaries when computing a path for an LSP. For example, path + computation MAY restrict the path taken by an LSP to only the links + whose interface switching capability is PSC. - Interface switching capability is used as a constraint in path computation. For - example, a TDM-LSP is routed over the topology composed of TE links of the same - TDM layer. In calculating the path for the LSP, the TED MAY be filtered to - include only links where both end include requested LSP switching type. In this - way hierarchical routing is done by using a TED filtered with respect to - switching capability (that is, with respect to particular layer). + Interface switching capability is used as a constraint in path + computation. For example, a TDM-LSP is routed over the topology + composed of TE links of the same TDM layer. In calculating the path + for the LSP, the TED MAY be filtered to include only links where both + end include requested LSP switching type. In this way hierarchical + routing is done by using a TED filtered with respect to switching + capability (that is, with respect to particular layer). - If triggered signaling is allowed, the path computation mechanism MAY produce a - route containing multiple layers/regions. The path is computed over the multiple - layers/regions even if the path is not "connected" in the same layer as the - endpoints of the path exist. Note that here we assume that triggered signaling - will be invoked to make the path "connected", when the upper-layer signaling - request arrives at the boundary node. + If triggered signaling is allowed, the path computation mechanism MAY + produce a route containing multiple layers/regions. The path is + computed over the multiple layers/regions even if the path is not + "connected" in the same layer as the endpoints of the path exist. + Note that here we assume that triggered signaling will be invoked to + make the path "connected", when the upper-layer signaling request + arrives at the boundary node. - The upper-layer signaling request may contain an ERO that includes only hops in - the upper layer, in which case the boundary node is responsible for triggered - creation of the lower-layer FA-LSP using a path of its choice, or for the - selection of any available lower layer LSP as a data link for the higher layer. - This mechanism is appropriate for environments where the TED is filtered in the - higher layer, where separate routing instances are used per layer, or where - administrative policies prevent the higher layer from specifying paths through - the lower layer. + The upper-layer signaling request may contain an ERO that includes + only hops in the upper layer, in which case the boundary node is + responsible for triggered creation of the lower-layer FA-LSP using a + path of its choice, or for the selection of any available lower layer + LSP as a data link for the higher layer. This mechanism is + appropriate for environments where the TED is filtered in the higher + layer, where separate routing instances are used per layer, or where + administrative policies prevent the higher layer from specifying + paths through the lower layer. - Obviously, if the lower layer LSP has been advertised as a TE link (virtual or - real) into the higher layer, then the higher layer signaling request may contain - the TE link identifier and so indicate the lower layer resources to be used. But - in this case, the path of the lower layer LSP can be dynamically changed by the - lower layer at any time. + Obviously, if the lower layer LSP has been advertised as a TE link + (virtual or real) into the higher layer, then the higher layer + signaling request may contain the TE link identifier and so indicate + the lower layer resources to be used. But in this case, the path of + the lower layer LSP can be dynamically changed by the lower layer at + any time. - Alternatively, the upper-layer signaling request may contain an ERO specifying - the lower layer FA-LSP route. In this case, the boundary node is responsible for - decision as to which it should use the path contained in the strict ERO or it - should re-compute the path within in the lower-layer. + Alternatively, the upper-layer signaling request may contain an ERO + specifying the lower layer FA-LSP route. In this case, the boundary + node is responsible for decision as to which it should use the path + contained in the strict ERO or it should re-compute the path within + in the lower-layer. - Even in case the lower-layer FA-LSPs are already established, a signaling - request may also be encoded as loose ERO. In this situation, it is up to the - boundary node to decide whether it should a new lower-layer FA-LSP or it should - use the existing lower-layer FA-LSPs. + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - The lower-layer FA-LSP can be advertised just as an FA-LSP in the upper-layer or - an IGP adjacency can be brought up on the lower-layer FA-LSP. + Even in case the lower-layer FA-LSPs are already established, a + signaling request may also be encoded as loose ERO. In this + situation, it is up to the boundary node to decide whether it should + a new lower-layer FA-LSP or it should use the existing lower-layer + FA-LSPs. + + The lower-layer FA-LSP can be advertised just as an FA-LSP in the + upper-layer or an IGP adjacency can be brought up on the lower-layer + FA-LSP. 5.8. LSP Resource Utilization - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 - It MUST be possible to utilize network resources efficiently. Particularly, - resource usage in all layers SHOULD be optimized as a whole (i.e., across all - layers), in a coordinated manner, (i.e., taking all layers into account). The - number of lower-layer LSPs carrying upper-layer LSPs SHOULD be minimized (note - that multiple LSPs MAY be used for load balancing). Lower-layer LSPs that could - have their traffic re-routed onto other LSPs are unnecessary and SHOULD be - avoided. + It MUST be possible to utilize network resources efficiently. + Particularly, resource usage in all layers SHOULD be optimized as a + whole (i.e., across all layers), in a coordinated manner, (i.e., + taking all layers into account). The number of lower-layer LSPs + carrying upper-layer LSPs SHOULD be minimized (note that multiple + LSPs MAY be used for load balancing). Lower-layer LSPs that could + have their traffic re-routed onto other LSPs are unnecessary and + SHOULD be avoided. 5.8.1. FA-LSP Release and Setup - Statistical multiplexing can only be employed in PSC and L2SC regions. A PSC or - L2SC LSP may or may not consume the maximum reservable bandwidth of the TE link - (FA LSP) that carries it. On the other hand, a TDM, or LSC LSP always consumes a - fixed amount of bandwidth as long as it exists (and is fully instantiated) - because statistical multiplexing is not available. + Statistical multiplexing can only be employed in PSC and L2SC + regions. A PSC or L2SC LSP may or may not consume the maximum + reservable bandwidth of the TE link (FA-LSP) that carries it. On the + other hand, a TDM, or LSC LSP always consumes a fixed amount of + bandwidth as long as it exists (and is fully instantiated) because + statistical multiplexing is not available. - If there is low traffic demand, some FA LSPs that do not carry any higher-layer - LSP MAY be released so that lower-layer resources are released and can be - assigned to other uses. Note that if a small fraction of the available bandwidth - of an FA-LSP is still in use, the nested LSPs can also be re-routed to other FA- - LSPs (optionally using the make-before-break technique) to completely free up - the FA-LSP. Alternatively, unused FA LSPs MAY be retained for future use. - Release or retention of underutilized FA LSPs is a policy decision. + If there is low traffic demand, some FA-LSPs that do not carry any + higher-layer LSP MAY be released so that lower-layer resources are + released and can be assigned to other uses. Note that if a small + fraction of the available bandwidth of an FA-LSP is still in use, the + nested LSPs can also be re-routed to other FA-LSPs (optionally using + the make-before-break technique) to completely free up the FA-LSP. + Alternatively, unused FA-LSPs MAY be retained for future use. Release + or retention of underutilized FA-LSPs is a policy decision. - As part of the re-optimization process, the solution MUST allow rerouting of an - FA LSP while keeping interface identifiers of corresponding TE links unchanged. - Further, this process MUST be possible while the FA LSP is carrying traffic - (higher layer LSPs) with minimal disruption to the traffic. + As part of the re-optimization process, the solution MUST allow + rerouting of an FA-LSP while keeping interface identifiers of + corresponding TE links unchanged. Further, this process MUST be + possible while the FA-LSP is carrying traffic (higher layer LSPs) + with minimal disruption to the traffic. - Additional FA LSPs MAY also be created based on policy, which might consider - residual resources and the change of traffic demand across the region. By - creating the new FA LSPs, the network performance such as maximum residual - capacity may increase. + Additional FA-LSPs MAY also be created based on policy, which might + consider residual resources and the change of traffic demand across + the region. By creating the new FA-LSPs, the network performance such + as maximum residual capacity may increase. - As the number of FA LSPs grows, the residual resource may decrease. In this case, - re-optimization of FA LSPs MAY be invoked according to policy. + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - Any solution MUST include measures to protect against network destabilization - caused by the rapid setup and teardown of LSPs as traffic demand varies near a - threshold. + As the number of FA-LSPs grows, the residual resource may decrease. + In this case, re-optimization of FA-LSPs MAY be invoked according to + policy. - Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly advertise - the LSP as a TE link and to coordinate into which routing instances the TE link - should be advertised. + Any solution MUST include measures to protect against network + destabilization caused by the rapid setup and teardown of LSPs as + traffic demand varies near a threshold. + + Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly + advertise the LSP as a TE link and to coordinate into which routing + instances the TE link should be advertised. 5.8.2. Virtual TE-Links - It may be considered disadvantageous to fully instantiate (i.e. pre-provision) - the set of lower layer LSPs that provide the VNT since this might reserve - bandwidth that could be used for other LSPs in the absence of upper-layer - traffic. + It may be considered disadvantageous to fully instantiate (i.e. pre- + provision) the set of lower layer LSPs that provide the VNT since + this might reserve bandwidth that could be used for other LSPs in the + absence of upper-layer traffic. - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + However, in order to allow path computation of upper-layer LSPs + across the lower-layer, the lower-layer LSPs MAY be advertised into + the upper-layer as though they had been fully established, but + without actually establishing them. Such TE links that represent the + possibility of an underlying LSP are termed "virtual TE-links." It is + an implementation choice at a layer boundary node whether to create + real or virtual TE-links, and the choice if available in an + implementation MUST be under the control of operator policy. Note + that there is no requirement to support the creation of virtual TE- + links, since real TE-links (with established LSPs) may be used, and + even if there are no TE-links (virtual or real) advertised to the + higher layer, it is possible to route a higher layer LSP into a lower + layer on the assumptions that proper hierarchical LSPs in the lower + layer will be dynamically created (triggered) as needed. - However, in order to allow path computation of upper-layer LSPs across the - lower-layer, the lower-layer LSPs MAY be advertised into the upper-layer as - though they had been fully established, but without actually establishing them. - Such TE links that represent the possibility of an underlying LSP are termed - "virtual TE-links." It is an implementation choice at a layer boundary node - whether to create real or virtual TE-links, and the choice if available in an - implementation MUST be under the control of operator policy. Note that there is - no requirement to support the creation of virtual TE-links, since real TE-links - (with established LSPs) may be used, and even if there are no TE-links (virtual - or real) advertised to the higher layer, it is possible to route a higher layer - LSP into a lower layer on the assumptions that proper hierarchical LSPs in the - lower layer will be dynamically created (triggered) as needed. + If an upper-layer LSP that makes use of a virtual TE-Link is set up, + the underlying LSP MUST be immediately signaled in the lower layer. - If an upper-layer LSP that makes use of a virtual TE-Link is set up, the - underlying LSP MUST be immediately signaled in the lower layer. + If virtual TE-Links are used in place of pre-established LSPs, the + TE-links across the upper-layer can remain stable using pre-computed + paths while wastage of bandwidth within the lower-layer and + unnecessary reservation of adaptation ports at the border nodes can + be avoided. - If virtual TE-Links are used in place of pre-established LSPs, the TE-links - across the upper-layer can remain stable using pre-computed paths while wastage - of bandwidth within the lower-layer and unnecessary reservation of adaptation - ports at the border nodes can be avoided. + The solution SHOULD provide operations to facilitate the build-up of + such virtual TE-links, taking into account the (forecast) traffic + demand and available resource in the lower-layer. - The solution SHOULD provide operations to facilitate the build-up of such - virtual TE-links, taking into account the (forecast) traffic demand and - available resource in the lower-layer. + Virtual TE-links MAY be added, removed or modified dynamically (by + changing their capacity) according to the change of the (forecast) + traffic demand and the available resource in the lower-layer. The + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 - Virtual TE-links MAY be added, removed or modified dynamically (by changing - their capacity) according to the change of the (forecast) traffic demand and the - available resource in the lower-layer. The maximum number of virtual TE links - that can be defined SHOULD be configurable. + maximum number of virtual TE links that can be defined SHOULD be + configurable. - Any solution MUST include measures to protect against network destabilization - caused by the rapid changes in the virtual network topology as traffic demand - varies near a threshold. + Any solution MUST include measures to protect against network + destabilization caused by the rapid changes in the virtual network + topology as traffic demand varies near a threshold. - The concept of the VNT can be extended to allow the virtual TE-links to form - part of the VNT. The combination of the fully provisioned TE-links and the - virtual TE-links defines the VNT provided by the lower layer. The VNT can be - changed by setting up and/or tearing down virtual TE links as well as by - modifying real links (i.e. the fully provisioned LSPs). How to design the VNT - and how to manage it are out of scope of this document. + The concept of the VNT can be extended to allow the virtual TE-links + to form part of the VNT. The combination of the fully provisioned TE- + links and the virtual TE-links defines the VNT provided by the lower + layer. The VNT can be changed by setting up and/or tearing down + virtual TE links as well as by modifying real links (i.e., the fully + provisioned LSPs). How to design the VNT and how to manage it are out + of scope of this document. 5.9. Verification of the LSPs - When a lower layer LSP is established for use as a data link by a higher layer, - the LSP MAY be verified for correct connectivity and data integrity. Such - mechanisms are data technology-specific and are beyond the scope of this - document, but may be coordinated through the GMPLS control plane. - - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 + When a lower layer LSP is established for use as a data link by a + higher layer, the LSP MAY be verified for correct connectivity and + data integrity. Such mechanisms are data technology-specific and are + beyond the scope of this document, but may be coordinated through the + GMPLS control plane. 6. Security Considerations - The current version of this document does not introduce any new security - considerations as it only lists a set of requirements. + The MLN/MRN architecture does not introduce any new security + requirements over the general GMPLS architecture described in + [RFC3945]. Additional security considerations form MPLS and GMPLS + networks are described in [MPLS-SEC]. - It is expected that solution documents will include a full analysis of the - security issues that any protocol extensions introduce. + However, 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, for triggering lower-layer LSPs, or for VNT + management. Similarly, consideration may be given to the amount of + information shared between administrative domains, and the trade-off + between multi-layer TE and confidentiality of information belonging + to each administrative domain. + + It is expected that solution documents will include a full analysis + of the security issues that any protocol extensions introduce. 7. IANA Considerations This informational document makes no requests to IANA for action. - 8. References +8. Acknowledgements - 8.1. Normative Reference + The authors would like to thank Adrian Farrel and the participants of + ITU-T Study Group 15 Question 14 for their careful review. + + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 + +9. References + +9.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC4202] K.Kompella and Y.Rekhter, "Routing Extensions in Support of - Generalized Multi-Protocol Label Switching (GMPLS)," RFC4202, - October 2005. - - [RFC4726] A.Farrel, J-P. Vasseur, and A.Ayyangar, "A Framework for Inter- - Domain Multiprotocol Label Switching Traffic Engineering", RFC - 4726, November 2006. + [RFC4202] Kompella, K., and Rekhter, Y., "Routing Extensions in + Support of Generalized Multi-Protocol Label Switching + (GMPLS)," RFC4202, October 2005. - [RFC4206] K.Kompella and Y.Rekhter, "Label Switched Paths (LSP) Hierarchy - with Generalized Multi-Protocol Label Switching (GMPLS) Traffic - Engineering (TE)," RFC4206, Oct. 2005. + [RFC4726] Farrel, A., Vasseur, JP., and Ayyangar, A., "A Framework + for Inter-Domain Multiprotocol Label Switching Traffic + Engineering", RFC 4726, November 2006. - [RFC3945] E.Mannie (Ed.), "Generalized Multi-Protocol Label Switching - (GMPLS) Architecture", RFC 3945, October 2004. - [RFC4397] I.Bryskin and A. Farrel, "A Lexicography for the Interpretation of - Generalized Multiprotocol Label Switching (GMPLS) - Terminology within the Context of the ITU-T's Automatically - Switched Optical Network (ASON) Architecture", RFC 4397, - February 2006. + [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) + Hierarchy with Generalized Multi-Protocol Label Switching + (GMPLS) Traffic Engineering (TE)," RFC4206, Oct. 2005. - 8.2. Informative References + [RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture", RFC 3945, October 2004. - [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., Shiomoto, - K., Vigoureux, M.,"Evaluation of existing GMPLS Protocols - against Multi Layer and Multi Region Networks (MLN/MRN)", - draft-ietf-ccamp-gmpls-mrn-eval, work in progress. + [RFC4397] Bryskin, I., and Farrel, A., "A Lexicography for the + Interpretation of Generalized Multiprotocol Label Switching + (GMPLS) Terminology within the Context of the ITU-T's + Automatically Switched Optical Network (ASON) + Architecture", RFC 4397, February 2006. - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 +9.2. Informative References - [MPLS-GMPLS] K. Kumaki (Editor), "Interworking Requirements to Support - operation of MPLS-TE over GMPLS networks", draft- - ietf-ccamp-mpls-gmpls-interwork-reqts, work in progress. + [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., + Shiomoto, K., Vigoureux, M., "Evaluation of Existing + GMPLS Protocols Against Multi-Layer and Multi-Region + Network (MLN/MRN) Requirements", draft-ietf-ccamp-gmpls- + mln-eval, work in progress. - [DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and Ali, Z., - "Procedures for Dynamically Signaled Hierarchical Label - Switched Paths", draft-ietf-ccamp-lsp-hierarchy-bis, work in + [MPLS-GMPLS] K. Kumaki (Editor), "Interworking Requirements to + Support Operation of MPLS-TE over GMPLS Networks", + draft-ietf-ccamp-mpls-gmpls-interwork-reqts, work in progress. - [AUTO-MESH] Vasseur, JP., Le Roux, JL., et al., "Routing extensions for - discovery of Multiprotocol (MPLS) Label Switch Router (LSR) - Traffic Engineering (TE) mesh membership", draft-ietf-ccamp- - automesh, work in progress. + [DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and + Ali, Z., "Procedures for Dynamically Signaled + Hierarchical Label Switched Paths", draft-ietf-ccamp- + lsp-hierarchy-bis, work in progress. - 9. Authors' Addresses + [MPLS-SEC] Fang, L., et al., " Security Framework for MPLS and + GMPLS Networks", draft-fang-mpls-gmpls-security- + framework, work in progress. + + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 + + [RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing Extensions + for Discovery of Multiprotocol (MPLS) Label Switch + Router (LSR) Traffic Engineering (TE) Mesh Membership", + RFC 4972, July 2007. + +10. Authors' Addresses Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan 50, @@ -980,75 +1123,82 @@ Route de Nozay, 91461 Marcoussis cedex, France Phone: +33 (0)1 69 63 18 52 Email: martin.vigoureux@alcatel-lucent.fr Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave., Middletown, NJ 07748, USA Phone: +1 732 420 1573 Email: dbrungard@att.com - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 - 10.Contributors' Addresses +11. Contributors' Addresses Eiji Oki NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Phone: +81 422 59 3441 Email: oki.eiji@lab.ntt.co.jp + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 Ichiro Inoue NTT Network Service Systems Laboratories 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Phone: +81 422 59 3441 Email: ichiro.inoue@lab.ntt.co.jp Emmanuel Dotaro Alcatel-Lucent Route de Nozay, 91461 Marcoussis cedex, France Phone : +33 1 6963 4723 Email: emmanuel.dotaro@alcatel-lucent.fr - 11. Intellectual Property Considerations +12. Intellectual Property Considerations - 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 + 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. + 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. + 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. - 12. Full Copyright Statement - draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 +13. Full Copyright Statement - Copyright (C) The IETF Trust (2007). 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. + Copyright (C) The IETF Trust (2007). - 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 FOR A - PARTICULAR PURPOSE. + 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. + + draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 + + 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 FOR A PARTICULAR + PURPOSE.