idnits 2.17.1 draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 162 has weird spacing: '...der its local...' == Line 448 has weird spacing: '...te LSPs provi...' == Line 551 has weird spacing: '...sidered regar...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The best example is a packet LSP (PSC-1) to be multiplexed into PSC-2 region that lies over an LSC region. The metric MUST not take only into account packet boundaries interface features, properties and traffic engineering attributes such as delay or bit-rate but also for instance the distance over the LSP region that this LSP will have to travel. As such, the TE Metric for the Lambda LSP (in this example, FA-LSP(i+1)) must be at least defined as a combination of the bit-rate and the distance, classically the bit-rate times the distance with some weighting factors. The main issue from this perspective is that joined Path TE Metric wouldn't in such a case tackle simultaneously both packet and optical specifics. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7375 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GMPLS-ARCH' is mentioned on line 971, but not defined == Missing Reference: 'MPLS-HIER' is mentioned on line 706, but not defined == Missing Reference: 'TE-WG' is mentioned on line 118, but not defined == Missing Reference: 'TERM' is mentioned on line 406, but not defined == Missing Reference: 'E2E-RECOVERY' is mentioned on line 406, but not defined == Missing Reference: 'LSC' is mentioned on line 487, but not defined == Missing Reference: 'PSC' is mentioned on line 482, but not defined == Missing Reference: 'TDM' is mentioned on line 487, but not defined == Missing Reference: 'GMPLS-SONET-SDH' is mentioned on line 832, but not defined == Missing Reference: 'A-B-C-D-J-I-F-E-H-G' is mentioned on line 905, but not defined == Missing Reference: 'A-B-C-D-J' is mentioned on line 911, but not defined == Missing Reference: 'A-B-D-J-I-G' is mentioned on line 919, but not defined == Missing Reference: 'J-I-F-E' is mentioned on line 919, but not defined == Missing Reference: 'A-B-C-D' is mentioned on line 919, but not defined == Unused Reference: 'SURVEY' is defined on line 1065, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.709' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.805' == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-g709-06 == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-gmpls-recovery-analysis-02 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-recovery-analysis (ref. 'RECOVERY') -- No information found for draft-vasseur-ayyangar-ccamp-inter-area-AS-TE - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'INTER-AREA-AS' == Outdated reference: A later version (-03) exists of draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01 -- Possible downref: Normative reference to a draft: ref. 'L2SC-LSP' -- No information found for draft-shiomoto-multiarea-te - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MAMLTE' -- Possible downref: Normative reference to a draft: ref. 'MLRT' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'SRLG' -- Possible downref: Normative reference to a draft: ref. 'SURVEY' == Outdated reference: A later version (-05) exists of draft-douville-ccamp-gmpls-waveband-extensions-03 -- Possible downref: Normative reference to a draft: ref. 'WBEXT' Summary: 8 errors (**), 0 flaws (~~), 26 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Papadimitriou 3 M. Vigoureux 4 Internet Draft (Alcatel) 5 draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt 6 K. Shiomoto 7 Expiration Date: August 2004 (NTT) 9 D. Brungard 10 (ATT) 12 J.L. Le Roux 13 (FT) 15 February 2004 17 Generalized MPLS Architecture for Multi-Region Networks 19 draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet- Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference 32 material or to cite them other than as "work in progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 Most of the initial efforts on Generalized MPLS (GMPLS) have been 43 related to environments of single switching capability devices e.g. 44 one data plane layer, as such, the complexity raised by the control 45 of such data planes is similar to the one expected in classical 46 IP/MPLS networks. The fundamental reason being that an IP-based 47 control plane protocol suite for Label Switch Routers (LSR) or 48 Optical Cross-Connects (OXC) has exactly the same Level (i.e. single 49 data plane layer) complexity. 51 The present document analyses the various GMPLS signaling and routing 52 aspects when considering network environments consisting of multiple 53 switching data layers e.g. supporting combined Packet/Layer-2 54 Switching - OXC devices. The examples provide an overview of the 55 tradeoffs in using a GMPLS control plane for combined Ethernet MAC - 56 opaque, service transparent, and/or fully transparent data planes. 57 The intent of this memo is also to demonstrate that these aspects may 58 not be as straightforward as they may first appear. 60 Table of Contents 62 Conventions used in this document.................................2 63 1. Introduction...................................................3 64 1.1 Context and Motivations....................................3 65 1.2 Rationales for Multi-Region Networks:......................4 66 1.3 Problem statement..........................................5 67 2. Routing over Forwarding Adjacencies............................5 68 2.1 Scalability of Single Region Networks......................6 69 2.2 Scalability of Multi-Region Networks.......................7 70 2.3 Emulating Data Plane Overlays using FAs....................7 71 2.4 FA Attributes Inheritance..................................8 72 2.5 FA Abstraction for Recovery................................9 73 3. Cross Region Considerations....................................9 74 3.1 Interface adaptation capability descriptor................10 75 3.2 Regeneration capability...................................15 76 3.3 Dedicated Traffic Parameters..............................16 77 3.4 Applications..............................................16 78 4. Extended Scope of Switching Capabilities......................17 79 4.1 L2SC Switching............................................17 80 4.2 Example...................................................19 81 4.3 Waveband switching........................................20 82 5. Conclusion....................................................20 83 Security Considerations..........................................21 84 References.......................................................21 85 Acknowledgments..................................................23 86 Author�s Addresses...............................................23 87 Contributors.....................................................24 89 Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC-2119. 95 In addition the reader is assumed to be familiar with the concepts 96 developed in [GMPLS-ARCH], [RFC-3471], and [GMPLS-RTG] as well as 97 [MPLS-HIER] and [MPLS-BDL]. 99 1. Introduction 101 Generalized Multi-Protocol Label Switching (GMPLS) facilitates the 102 realization of seamless control integration of IP/MPLS networks with 103 SONET/SDH (see [T1.105]/[G.707]) or G.709 (see [G.709]) optical 104 transport networks. In particular, the applicability of GMPLS to both 105 packet/frame and circuit switching technologies (i.e. unified control 106 plane architecture) provides a unified control management approach 107 for both provisioning resources and restoration techniques. 109 One of the additional advantages driving the construction of a 110 unified GMPLS control plane is the desire to support multi LSP- 111 region [MPLS-HIER] routing and traffic engineering capability. This 112 would enable effective network resource utilization of both the 113 Packet/Layer2 LSP regions and the Time Division Multiplexing (TDM) or 114 Lambda (Optical Channels) LSP regions in high capacity networks. 116 1.1 Context and Motivations 118 Vertical integration refers (see [TE-WG]) to the definition of 119 collaborative mechanisms within a single control plane instance 120 driving multiple (but at least two) data planes (also referred in the 121 scope of GMPLS as switching layers). Horizontal integration is 122 defined when each entity constituting the network environment 123 includes at least one common (data plane) switching capability and 124 the control plane topology extends over several partitions being 125 either areas or autonomous systems (see [INTER-AREA-AS]). In this 126 latter case, the integration is thus defined between nodes hosting 127 the same switching capability. For instance, the control plane 128 interconnection between lambda switching capable routing areas 129 defines an horizontal integration. On the other hand, an environment 130 in which at least two different switching capabilities are present 131 and where these capabilities are both hosted by the same device 132 and/or hosted by different devices involves a vertical integration 133 within the GMPLS control plane. Such multi-switching layer capable 134 networks are referred to as Multi LSP-Region Networks or simply 135 Multi-Region Networks (MRN). 137 Note here that, the CCAMP Working Group is currently actively working 138 on extensions to this horizontal integration (the initial iteration 139 being the single area context worked out over the past few years) by 140 considering common multi-area and multi-AS traffic engineering 141 techniques and protocol extensions [INTER-AREA-AS]. As a first phase 142 vertical integration, as proposed in this document, we focus on 143 single area only environments. 145 From the control plane viewpoint (as defined in [MPLS-HIER]) a data 146 plane layer is mapped to an LSP region. Following this approach, a 147 Traffic Engineering link or simply TE Link (at the control plane 148 level) maps exactly the definition proposed in the canonical layered 149 model (see [G.805]) where a link is defined as a link bundle (using 150 the IETF terminology). More generically, the TE link notion is now 151 recursively defined and accepted implying that the link bundle term 152 will be used only when referring to a set of component links or 153 ports. Therefore, the TE Link concept opens the door for a clear 154 separation between the routing adjacencies and the data plane bearer 155 links (or channels). Furthermore, TE Links have been extended to non 156 adjacent devices by introducing the Forwarding Adjacency (FA) concept 157 enabling in turn to decrease the number of control plane instances to 158 control N transport layers. Last, the bundling of FA is also defined 159 in [MPLS-BDL] allowing for additional flexibility in controlling 160 large scale backbone networks. 162 Using the Forwarding Adjacency, a node may (under its local control 163 policy configuration) advertise an LSP as a TE link into the same 164 OSPF/ISIS instance as the one that induces this LSP. Such a link is 165 referred to as a "Forwarding Adjacency" (FA) and the corresponding 166 LSP to as a "Forwarding Adjacency LSP", or simply FA-LSP. Since the 167 advertised entity appears as a TE link in OSPF/ISIS, both end-point 168 nodes of the FA-LSP must belong to the same OSPF area/ISIS level 169 (intra-area improvement of scalability). Afterwards, OSPF/ISIS floods 170 the link-state information about FAs just as it floods the 171 information about any other TE Link. This allows other nodes to use 172 FAs as any other TE Links for path computation purposes. 174 1.2 Rationales for Multi-Region Networks: 176 The rationales for investigating vertical integration (and thus 177 multi-region networks) in the GMPLS distributed control plane context 178 can be summarized as follows: 180 - The maintenance of multiple instances of the control plane on 181 devices hosting more than one switching capability not only (and 182 obviously) increases the complexity of their interactions but also 183 increases the total amount of processing individual instances would 184 handle. 186 - The merge of both data and control plane addressing spaces helps in 187 avoiding multiple identification for the same object (a link for 188 instance or more generally any network resource), on the other hand 189 such aggregation does not impact the separation between the control 190 and the data plane. 192 - The collaboration between associated control planes (packet/framed 193 data planes) and non-associated control planes (SONET/SDH, G.709, 194 etc.) is facilitated due to the capability of hooking the associated 195 in-band signaling to the IP terminating interfaces of the control 196 plane. 198 - Resource management and policies to be applied at the edges of such 199 environment would be facilitated (less control to management 200 interactions) and more scalable (through the use of aggregated 201 information). 203 In this context, Hybrid Photonic Networks (HPN) can be differentiated 204 from Multi-Region Networks (MRN). The main difference between nodes 205 included in an HPN environment and nodes included in an MRN 206 environment can be expressed as follows: some of the former MUST 207 include at least for some (but at least two) of their interfaces an 208 LSC switching capability with "lambda" (photonic) encoding. 210 1.3 Problem statement 212 The control by a single GMPLS instance of at least two different 213 switching capabilities rises some issues with regards to the control 214 plane scalability as well as inter-working issues between these 215 switching capabilities. Typically, devices present in an MRN will 216 have the information about all the TE-Links corresponding to the 217 different switching capabilities present in the environment. This 218 will lead, in turn, to the maintenance of large LSDB resulting in 219 CSPF computation time possibly exceeding reasonable value. 220 Scalability also concerns the maintenance of a very large number of 221 signaling sessions. Section 4 addresses these types of issues while 222 section 5 covers issues resulting from devices hosting at least two 223 different switching capabilities, or, more broadly, cross layer 224 considerations. 226 2. Routing over Forwarding Adjacencies 228 In order to extend MPLS to support non-packet TE attributes within 229 the scope of an integrated (routing) model encompassing several data 230 planes, GMPLS needs to support control of several data plane layers 231 (or switching layers) using the same protocol instance. 233 Forwarding Adjacencies (FAs) as described in [MPLS-HIER] are a useful 234 and powerful tool for improving the scalability of Generalized MPLS 235 (GMPLS) Traffic Engineering (TE) capable networks. 236 Through the aggregation of TE Label Switched Paths (LSPs) this 237 concept enables the creation of a vertical (nested) TE-LSP Hierarchy. 238 Forwarding Adjacency LSPs (FA-LSP) may be advertised as TE link (or 239 simply FA) into the same instance of OSPF/ISIS as the one that was 240 used to create, initiate or trigger this LSP, allowing other LSRs to 241 use FAs as TE links for their path computation. As such, forwarding 242 adjacency LSPs have characteristics of both TE links and LSPs. 244 While this definition is in perfect alignment for non-packet LSP 245 regions and boundaries, the same concept(s) can also be re-used in 246 the MPLS LSP context but with a major difference. The mapping goes in 247 the opposite direction i.e. from the control to the IP/MPLS 248 forwarding plane, since in the packet domain FA-LSPs are purely 249 abstract objects that would, if well tailored, provide additional 250 scalability within a routing plane instance (i.e. define virtual TE 251 links without increasing the number of routing adjacencies). Indeed, 252 the use of FAs provides a mechanism for improving bandwidth (or more 253 generally any resource) utilization when its dynamic allocation can 254 be performed in discrete units; it also enables aggregating 255 forwarding state, and in turn, reducing significantly the number of 256 required labels as well as the number of signaling sessions. 257 Therefore, FAs may significantly improve the scalability of GMPLS TE- 258 capable control planes, and allow the creation of a TE-LSP hierarchy. 260 From this, and when combining multi-region environments, the 261 challenges that arise are related to the combination of both types of 262 mappings (and in particular their control) for both super-classes of 263 LSPs i.e. packet LSPs and circuit-oriented LSPs (a.k.a. non-packet 264 LSPs) from or to the same control plane instance. 266 2.1 Scalability of Single Region Networks 268 The main issue arising with FAs is related to the mapping 269 directionality (from the data to the control plane). FAs allow 270 avoiding the well-known O(N^2) at the control plane level by using 271 the mechanisms defined in [MPLS-HIER] but requires a specific 272 policing at the LSP region edges (or boundaries) in order to avoid 273 full meshes both at the data plane level and control plane level. 275 Currently, and as specified in [MPLS-HIER], it is expected that FAs 276 will not be used for establishing OSPF/ISIS peering relation between 277 the routers at the ends of the adjacency thus clearly avoiding N 278 square problem at the control plane level. On the other hand, 279 specific policies would be required to avoid a full mesh of FAs. A 280 full mesh of FAs would lead, at the control plane level, to a full 281 mesh of signaling sessions while, at the data plane, it would lead to 282 poor resource utilization. Avoiding full meshes can be accomplished 283 by setting the default metric of the FA to max[1, (the TE metric of 284 the FA-LSP path - 1)] so that it attracts traffic in preference to 285 setting up a new LSP. Such policing clearly states that FA-LSPs are 286 driven by a most fit approach: do not create new FA-LSPs as long as 287 existing ones are not filled up. The main issue with this approach is 288 definitely related to "what to advertise and originate at LSP region 289 boundaries". For instance, fully filled FA-LSPs should not be 290 advertised (if preemption is not allowed), while, attracting traffic 291 should be provided in some coordinated manner in order to avoid sub- 292 optimal FA-LSP setup. Moreover, nothing precludes the maintenance of 293 several partially filled FA-LSPs that are kept unused indefinitely 294 (even if their metric is set optimally) in particular when the 295 bandwidth of the FA-LSP can not (due to its discrete bandwidths 296 units) be exactly set to the incoming LSP request. 298 Note: the latter suggests filtering of the corresponding LSAs at the 299 regions' boundaries. In OSPF this can be accomplished by not 300 advertising the link as a regular LSA, but only as a TE opaque LSA 301 (see [RFC-2370]). 303 2.2 Scalability of Multi-Region Networks 305 The Shortest Path First (SPF) computation complexity is, in classical 306 cases, proportional to L Log(N) where L is the number of links (here, 307 more precisely TE links) and N the number of address prefixes. As 308 such, the full mesh scalability issues can be solved in two ways 309 either by improving the computational capabilities of the (C-)SPF 310 algorithms or simply by keeping existing Log(N) complexity but then 311 by improving collaboration between data planes. 312 The former can be achieved for instance by using Fibonacci heaps with 313 Log(Log(N)) complexity for instance, which in turn, allows for a 314 number of TE links greater than 1E6 (versus 1E3 with classical 315 implementations). The latter can be achieved by considering M 316 regions, over the same control plane topology and without using any 317 heuristics, one increases this complexity to M x L (Log (M x N)). 319 However, since TE Links can advertise multiple Interface Switching 320 Capabilities (ISC), the number of links can be limited (by 321 combination) by using specific topological maps referred to as 322 Virtual Network Topologies (VNT). The introduction of virtual 323 topological maps leads us to consider the concept of emulation of 324 data plane overlays [MAMLTE]. Therefore, the expectation here is to 325 reduce the overall computational complexity to L Log(M+1) x Log 326 (Log(M+1) x N) (note: with M = 1 it brings L Log(N)). 328 2.3 Emulating Data Plane Overlays using FAs 330 According to [MPLS-HIER] ISC ordering, we can use the following 331 terminology: FA-LSP(1) corresponds to TE Links for which the ISC is 332 equal to PSC-1, FA-LSP(2) to PSC-2, FA-LSP(3) to PSC-3, FA-LSP(4) = 333 PSC-4, FA-LSP(5) to LS2SC, FA-LSP(6) to TDM, FA-LSP(7) to LSC and FA- 334 LSP(8) to FSC. 336 FA-LSP(i) is routed over the FA-LSP(i+j) with j >= 1. In other words 337 a set of FA-LSPs(i+j) with j fixed provides a Virtual Network 338 Topology (VNT) for routing FA-LSPs(i). The virtual network topology 339 offered by a set of FA-LSPs(i) is denoted by VNT(i) in this document. 340 The virtual network topology is changed by setting up and/or tearing 341 down one (or more) FA-LSP(i). The change of the VNT(i) affects the 342 routing of FA-LSPs(i-j). It is expected that boundary LSRs of VNT(i) 343 will behave consistently with respect to any internal (LSP/link 344 recovery) or external (LSP/link provisioning) triggering event. 346 Routing is dependent on the network topology and associated link 347 state. Routing stability may be impaired if the Virtual Network 348 Topology frequently changes and/or if the status of links in the 349 Virtual Network Topology frequently changes. In this context, 350 robustness of the Virtual Network Topology is defined as the 351 capability to smooth changes that may occur and avoid their 352 subsequent propagation. Changes of the Virtual Network Topology may 353 be caused by the creation and/or deletion of several LSPs. Creation 354 and deletion of LSPs may be triggered by adjacent regions or through 355 operational actions to meet change of traffic demand. Routing 356 robustness should be traded with adaptability with respect to the 357 change of incoming traffic requests. 359 2.4 FA Attributes Inheritance 361 Several FA-LSPs(i) between LSRs over LSP region(i+1) are already 362 established, and several FA-LSPs(i-1) have been setup over this 363 topology and are partially filled up. One of the latter LSR regions 364 sees an incoming LSP request. It can be demonstrated that the TE 365 metric (in addition to the Maximum LSP Bandwidth and Unreserved 366 Bandwidth see [GMPLS-RTG]) alone is not a sufficient metric to 367 compute the best path between these regions. This suggests that the 368 inheritance process over which the TE-Metric of the FA is not as 369 straightforward as proposed in [MPLS-HIER]. 371 The best example is a packet LSP (PSC-1) to be multiplexed into PSC- 372 2 region that lies over an LSC region. The metric MUST not take only 373 into account packet boundaries interface features, properties and 374 traffic engineering attributes such as delay or bit-rate but also for 375 instance the distance over the LSP region that this LSP will have to 376 travel. As such, the TE Metric for the Lambda LSP (in this example, 377 FA-LSP(i+1)) must be at least defined as a combination of the bit- 378 rate and the distance, classically the bit-rate times the distance 379 with some weighting factors. The main issue from this perspective is 380 that joined Path TE Metric wouldn't in such a case tackle 381 simultaneously both packet and optical specifics. 383 This suggests the definition of more flexible TE Metric, at least the 384 definition of a TE Metric per ISC. Simply adjust the TE Metric to the 385 (TE Metric of the FA-LSP path - 1) is a valid approach between LSP 386 over the same region class (PSC-1, PSC-2, ... , PSC-N, for instance) 387 but not necessarily between PSC and LSC region. 389 Other TE attributes that need a specific processing during 390 inheritance are the Shared Risk Link Groups (SRLG) (see for instance 391 [SRLG]) Resource Class/Color (i.e. Administrative Groups) and 392 Protection (see Section 2.5). 394 The next section will describe the specific TE attributes to be 395 considered for devices hosting at least two switching capabilities, 396 in particular the interface switching adaptation capabilities. 398 2.5 FA Abstraction for Recovery 400 In multi switching environments the inheritance of protection and 401 restoration related TE link attributes must also be considered. 403 1) Considering a 1:1 end-to-end LSP recovery scheme, two FA-LSPs may 404 be set up to form a single FA. To enhance the availability of the FA, 405 the primary and the secondary LSPs are set up. The primary LSP is 406 used to carry the normal traffic (see [TERM] and [E2E-RECOVERY]). 407 Once the failure occurs affecting the primary LSP, the normal traffic 408 is carried over the secondary LSP. From the routing perspective, 409 there is no topological change to carry the traffic. These two LSPs 410 should, therefore, be advertised within the scope of a single FA TE 411 link advertisement with link protection type of 1:1. This FA will be 412 processed by an upper layer as a span protected link. 414 2) Considering now a single FA-LSP, span protected over each link 415 (i.e. at the underlying layer). 416 The question that arises is how should this span protected FA-LSP be 417 advertised in the IGP. A link protection type of 1:1 could also be 418 used for this advertisement but then, an upper layer would have no 419 means to differentiate the two cases. However, these two recovery 420 schemes (end-to-end and span) have major differences in terms of 421 recovery delay and robustness [RECOVERY]. 423 Therefore, abstraction and summarization must be performed when 424 advertising FA-LSPs as TE links (to an upper layer) but using the 425 Link Protection Type flags and applying simple attribute inheritance 426 might not be sufficient to distinguish different recovery schemes. 428 3. Cross Region Considerations 430 In an MRN, as described here above, some LSR could contain, under the 431 control of a single GMPLS instance, multiple interface switching 432 capabilities such as PSC and Time-Division-Multiplexing (TDM) or PSC 433 and Lambda Switching Capability (LSC) or LSC and Waveband Switching 434 Capability WBSC). 436 These LSRs, hosting multiple Interface Switching Capabilities (ISC), 437 are required to hold and advertise resource information on link 438 states and topology. They also may have to consider certain portions 439 of internal LSR resources to terminate hierarchical label switched 440 paths (LSPs), since circuit switch capable units such as TDMs, LSCs, 441 and FSCs require rigid resources. 443 For example, an LSR with PSC+LSC switching capability can switch a 444 Lambda LSP but can never terminate the Lambda LSP if there is no 445 unused adaptation capability between the LSC and the PSC layers. 447 Therefore, within multi-region LSR networks, the advertisement the 448 so-called adaptation capability to terminate LSPs provides critical 449 information to take into account when performing multi-region path 450 computation. This concept enables a local LSR to discriminate remote 451 LSRs (and thus allows their selection during path computation) with 452 respect to their adaptation capability e.g. to terminate Lambda LSPs 453 at the PSC level. 455 Hence, here we introduce the idea of discriminating the (internal) 456 adaptation capability from the (interface) switching capability by 457 considering an interface adaptation capability descriptor. 459 3.1 Interface adaptation capability descriptor 461 The interface adaptation capability descriptor can be interpreted 462 either as the adaptation capability information from an incoming 463 interface or as the adaptation capability to an outgoing interface 464 for a given interface switching capability. By introducing such an 465 additional descriptor (as a sub-object of the ISC sub-TLV, for 466 instance), the local GMPLS control plane can swiftly search which 467 LSRs can terminate a certain encoding type of LSP and successfully 468 establish an LSP tunnel between two PSCs. 470 As an example, consider for instance a multiple LSP-region domain 471 comprising simultaneously PSC LSRs, LSC LSRs, PSC+LSC LSRs and 472 PSC+TDM+LSC LSRs. The LSRs discriminate the type of the links 473 connecting these LSRs by interpreting the interface switching 474 capability descriptor included in the TE Link TLV of the TE opaque 475 LSAs [LSP-HIER]. 477 The interface switching capability at both ends of a TE link between 478 LSRs for which individual resources (lambdas) are represented by 479 wavelength labels shall be [LSC, LSC], [{TDM|PSC}, LSC], or [LSC, 480 {TDM|PSC}]. On the other hand, the interface switching capability at 481 both ends of a TE link shall be [PSC,PSC] for LSPs "carrying" a shim 482 header label, or shall be [TDM, TDM], [TDM,PSC] or [PSC,TDM] for TE 483 links whose individual resources (timeslots) are represented by TDM 484 labels. Thus, based on the interface switching capability descriptor, 485 the LSRs can impose proper constraints in order to compute the paths 486 of the LSPs. For example, LSRs can understand that a remote TDM LSR 487 with [LSC,TDM] link cannot be a lambda LSP intermediate link with the 488 exception that it can initiate or terminate lambda LSPs and switch 489 "TDM timeslots". 491 However, LSRs cannot infer the internal LSP switching capability of 492 remote LSRs, especially if the LSRs have a multi-switching capability 493 architecture such as a PSC+TDM+LSC as shown below or more generally, 494 more than two ISC capabilities. In the LSR, LSC may have a direct 495 inner interface not only to TDM but also to PSC. The LSP can be 496 interfaced at both TDM or PSC. This kind of multi-switching 497 architecture may become very common in optical networks. 499 .......................... 500 . . 501 . -------- . 502 . | | . 503 . | ISC2 | . 504 . -<->--| | . 505 . | | | . 506 . | -------- . 507 . | . 508 . | -------- . 509 . | | | . 510 . -<->--| ISC1 | . 511 . | | . 512 -----<---------| | . 513 ----->---------| | . 514 . -------- . 515 .......................... 517 In the above figure, the switching capabilities ISC1 and ISC2 can be 518 grouped in a single TE link, and the bandwidth information defined as 519 follows: 520 Let X be the initial Unreserved Bandwidth of the TE link then the Max 521 LSP bandwidth can be equal to X for the ISC1 (as advertised in the 522 ISC1 sub-TLV) and equal to Y12 for the ISC2 (as advertised in the 523 ISC2 sub-TLV). Y12 represents the link bandwidth between the two 524 ISCs. The bandwidth accounting/updating is then dependent of the 525 inner architecture. In this case no specific adaptation capability 526 descriptor is required. 528 The following cases, however, highlight the limitations of such 529 procedure and the need for an enhanced switching adaptation 530 description. 532 .......................... 534 . . 535 TE2 . -------- . 536 ----->---------| | . 537 -----<---------| ISC2 | . 538 . --->--| | . 539 . | --<--| | . 540 . || -------- . 541 . || . 542 . || -------- . 543 . | -->--| | . 544 . ---<--| ISC1 | . 545 TE1 . | | . 546 ----->---------| | . 547 -----<---------| | . 548 . -------- . 549 .......................... 551 For the above picture, two cases can be considered regarding the 552 switching capability configuration. Note that both TE1 and TE2 belong 553 to the same physical link. 555 Let the triplet represent respectively the 556 Unreserved Bandwidth of the TE link, the Maximum LSP Bandwidth of 557 ISC1 and the Maximum LSP Bandwidth of ISC2. 559 In a first scheme the switching capabilities can be declared as two 560 separate TE links: for TE link 1 (TE_1) and TE link 2 (TE_2): and 563 In a second scheme, the capabilities are described as part of a 564 single TE Link: . 566 While the first case rises some issues concerning bandwidth 567 accounting coordination between the two TE Links, the later is 568 confronted to an over-provisioning issue being, in addition, highly 569 dependent on the Minimum LSP bandwidth value. Also, these approaches 570 are limited 1) by the number of switching capabilities hosted by a 571 single system and 2) by the number of ways these switching 572 capabilities interacts (i.e. the number of ways data can be 573 encapsulated/decapsulated when passing from one switching capability 574 to another). 576 1) Number of Switching Capabilities: 578 ------- 579 ------| |------ 580 | | PSC | | 581 | --| |-- | 582 | | ------- | | 583 | \|/ /|\ | 584 | | ------- | | 585 | --| |-- | 586 \|/ | TDM | /|\ 587 | --| |-- | 588 | | ------- | | 589 | \|/ /|\ | 590 | | ------- | | 591 | --| |--_ | 592 ------| |------ 593 | | 594 /|---| |---|\ Fiber #1 595 ========| |---| LSC |---| |======== 596 ========| |---| |---| |======== 597 \|---| |---|/ Fiber #N 598 ------- 600 Referring to this figure, the problem with the use of the interface 601 switching capability descriptor at the PSC+TDM+LSC LSR, is the 602 shortage of LSP termination capability information. The PSC+TDM+LSC 603 LSR provides only switching capability information by abstracting the 604 internal node capabilities. Therefore, remote LSRs cannot accurately 605 determine which switching capability can be switched and/or 606 terminated at the PSC+TDM+LSC LSR. For such a node supporting LSC, 607 TDM and PSC switching capability, the determination of the resource 608 made available to cross for instance the LSC to PSC region boundary 609 (LSC -> PSC) may involve one of the following region cross- over: LSC 610 -> PSC and LSC -> TDM -> PSC. This can be represented as follows: 612 ------- 613 | | 614 ----| PSC |---- 615 | | | | 616 ----- ------- ----- 617 | | | | 618 ----- ------- ----- 619 | | | | | | 620 | ---| TDM |--- | 621 | ---| |--- | 622 | | | | | | 623 ----- ------- ----- 624 | | | | 625 ----- ------- ----- 626 | | | | _| | 627 | ---| LSC |--- | 628 -----| |----- 630 2) Number of adaptation capabilities: 632 In addition, the LSP Encoding Type (representing the nature of the 633 link that the LSP traverses) is "lambda". Therefore, as depicted in 634 the following figure, this issue become more complex once each 635 switching capability supports multiple framing, for instance, at PSC, 636 Ethernet-MAC framing and PPP framing. 638 ------- 639 | | 640 ------------| PSC |------------ 641 | ----| |---- | 642 | | | | | | 643 ----- ----- ------- ----- ----- 644 | ETH | | PPP | | PPP | | ETH | 645 ----- ----- ------- ----- ----- 646 | | | | | | | | | | 647 | | | ---| TDM |--- | | | 648 | -----------| |----------- | 649 | | | | | | 651 Another example occurs when L2SC (Ethernet) switching can be adapted 652 in LAPS X.86 and GFP for instance before reaching the TDM switching 653 matrix: 655 ------- 656 | | 657 ------------| L2SC |------------ 658 | ----| |---- | 659 | | | | | | 660 ----- ----- ------- ----- ----- 661 | X86 | | GFP | | GFP | | X86 | 662 ----- ----- ------- ----- ----- 663 | | | | | | | | | | 664 | | | ---| TDM |--- | | | 665 | -----------| |----------- | 666 | | | | | | 668 Similar circumstances can occur, if a switching fabric that supports 669 both PSC and L2SC functionalities is assembled with LSC interfaces 670 enabling "lambda" (photonic) encoding. In the switching fabric, some 671 interfaces can terminate Lambda LSPs and perform frame (or cell) 672 switching whilst other interfaces can terminate Lambda LSPs and 673 perform packet switching. 675 Thus, the interface switching capability descriptor provides the 676 information for the forwarding (or switching) capability only. In 677 order for remote LSRs to understand properly the termination 678 capability of the other LSRs, additional information to the existing 679 interface switching capability descriptor is essential in achieving 680 seamless multi-region routing. In turn, adequate processing of this 681 additional information will allow the signaling of packet LSP set- up 682 combined with an automated triggering of new Lambda LSPs between LSRs 683 that do not yet have a preferred Lambda LSP to carry the Packet LSP. 684 (see [MLRT]). 685 Note that in the context of Hybrid Photonic Networks, additional 686 constraints such as the regeneration capability drive even more the 687 need for an adaptation switching capability descriptor. 689 3.2 Regeneration capability 691 In an HPN context, the lower LSP region provides to the upper LSP 692 region a regeneration/conversion function (using for instance opto- 693 electronic interfaces). More precisely a regeneration function can 694 deliver conversion (within a given pre- determined range or not) 695 while conversion may be delivered independently of the existence of 696 any regeneration capability. 698 The following classification applies from the definition of the 699 regeneration function: 701 1. If the regeneration function is defined as an Interface Switching 702 Capability (or simply ISC see [GMPLS-RTG] and [MPLS-HIER]), then if 703 this ISC value is lower or equal to the incoming LSP switching type, 704 the request may be processed by the network. Otherwise if the LSP 705 Switching Type > ISC value of the region, the LSP request can not be 706 processed and is simply rejected (see [MPLS-HIER] for a definition of 707 the relationship between ISC values). 709 2. If the regeneration function is not defined as an interface 710 switching capability (pure regeneration without any connection 711 function defined) then the following alternative applies depending on 712 the encoding type defined at its entry points. If the regeneration 713 depends on the encoding type of the incoming LSP request the latter 714 must be the same as the one provided by the regeneration function. 715 Otherwise the LSP request is simply rejected or tunneled toward the 716 next hop (if feasible). Notice here that forwarding an LSP request to 717 the next hop and expecting the latter would provide enough 718 regeneration capacity for this incoming LSP is a complex problem, 719 since one can not, with the currently available GMPLS tools, 720 guarantee that this request will not itself be forwarded to the next 721 hop, and so on. 723 Moreover, by extending the knowledge of the interface capability to 724 terminate (adapt) a given signal, it would be possible for instance 725 to characterize more precisely the interfaces (physical) distance 726 coverage. This may be achieved by considering information such as the 727 transmission distance range (Short Haul, Long Haul, Ultra Long Haul, 728 etc.) or even the signal modulation format. This would provide 729 dynamic interface resource management (versus the current Network 730 Management techniques). In turn, this would decrease the time needed 731 for selecting resources during path computation. 733 3.3 Dedicated Traffic Parameters 735 This point is related to whether or not dedicated traffic parameters 736 should be defined for LSPs established in MRN environments such as 737 the ones defined for Sonet/SDH (see [SONET-SDH] and G.709 (see 738 [GMPLS-G709]). 740 With respect to spatial routing the LSP Encoding Type, Switching Type 741 and G-PID (see [RFC-3471] for the corresponding definitions) provides 742 the required information to pertinently setup such LSPs. It is 743 nevertheless expected here to see some additional capability allowing 744 for intermediate states, in particular when the regeneration function 745 is defined as a switching layer (see also Section 6.2). 747 With respect to spectral routing the main issue raises from the 748 passing of external physical constraints between conversion points. 749 In addition to the Multiplier usage that may help in establishing/ 750 deleting parallel LSPs, additional information concerning the 751 physical constraint each sub-path MUST fulfill should be considered 752 e.g. maximum distance and BER per (sub-path). A parameter equivalent 753 to the Transparency level may also help in providing a hop-by-hop 754 negotiation of the regeneration capability to be used. 756 3.4 Applications 758 In multi-region environments, crossing LSP regions during 759 provisioning can occur for two main reasons: grooming or regeneration 760 (when delivered by a switching capable layer). 762 1. Grooming 764 LSP grooming deals with the optimization of network resource 765 utilization. Multi-region environments are particularly well adapted 766 for this feature as they may provide different switching 767 granularities allowing for the tunnelling of several finer grained 768 LSPs into a coarser grained LSP. In this context, it can be useful 769 from the control plane viewpoint not to terminate the multiplexed LSP 770 and simply tunnel this LSP into a lower-region LSP viewed as a common 771 segment for each incoming LSPs. 773 However, this raises the problem of the representation of the newly 774 established LSP at the control plane level. In particular, concerning 775 the maintenance of the two LSPs (head-end and tail-end LSPs) that 776 forms the newly spliced LSPs. Further consideration on grooming are 777 left for further study as it includes aspects leading to the 778 definition of multipoint-to-point LSPs (beyond the scope of this 779 document). 781 2. Regeneration 783 Due to the constraints of optical transmission, the optical signal 784 may have to be regenerated along the LSP path. Some multi-region 785 network may require to cross a region boundary to access the 786 regeneration function. This rises the question of the so-called LSP 787 integrity when crossing region boundaries. 789 Consider for instance a Lambda LSP in a LSC+PSC multi-region network. 790 For a given reason the LSP needs to be regenerated at an intermediate 791 node. It will thus use the O/E/O interfaces present in the PSC 792 region. From the control plane viewpoint either two Lambda LSPs are 793 seen (ingress to intermediate and intermediate to egress) or a single 794 one (ingress to egress). 796 Keeping a single Lambda LSP would prevent from maintaining, at the 797 control plane level, several entities for a single connection. It 798 should be also noted here that one assumes that regeneration is 799 delivered between LSPs (from ingress to intermediate and intermediate 800 to egress) defined within regions of the same switching capability 801 (i.e. LSC-PSC-LSC). This would in turn facilitate the processing of 802 both the regenerated entities and the (pool of) regeneration 803 resources that would need to be marked. 805 4. Extended Scope of Switching Capabilities 807 When considering multi-region environments, two common examples of 808 multi-switching combinations are: 809 - Packet(LSR)/Layer-2(Switch) with TDM (SONET/SDH) or LSC (OXC) 810 - Multi-Granularity OXC (including opaque and transparent switching 811 capabilities at different granularity levels) 813 The first implies some considerations with respect to Layer-2 814 Switching Capable interfaces and L2SC environments. The latter 815 implies further considerations on Waveband Switching aspects. 817 4.1 L2SC Switching 819 Layer 2 Switching capable interfaces and Layer 2 LSPs are in the 820 scope of GMPLS (see [GMPLS-ARCH], [GMPLS-RTG] and [RFC-3471]). Such 821 interfaces are defined as capable to recognize frame/cell boundaries 822 and can forward data based on the content of the frame/cell header. 823 They include mainly interfaces on Ethernet bridges that forward data 824 based on the content of the MAC header. This section provides an 825 overview of the issues to be considered when introducing GMPLS in 826 Ethernet MAC-based networks. 828 In this context, the possible development of a GMPLS signaling 829 profile for Ethernet networks, involves the definition of a label 830 space. From this perspective, two questions arise: 1) what the label 831 value space represents and is the corresponding label value space 832 semantic-full (see [GMPLS-SONET-SDH]) or semantic-less (see [RFC- 833 3471]) and 2) how is the label value space implemented (i.e. 834 associated with data plane or non-associated and therefore exchanged 835 over dedicated signaling channels or even a combination of both). A 836 contiguous problem arises that the set of potential solutions must be 837 backward compatible meaning that non-GMPLS controlled Ethernet 838 interfaces should be capable to inter-work with GMPLS controlled 839 Ethernet interfaces. 840 In addition to the label considerations, an additional problem 841 appears due to the type of environment in which these Ethernet 842 interfaces are considered. These interfaces may be either so-called 843 LAN PHY's (thus implying a broadcast capable environment) or WAN 844 PHY's (thus implying point-to-point links). On the other side, one 845 has to consider MAC-based capable interfaces over Non-Broadcast 846 Multiple Access (NBMA) technologies such as MPLS (Ethernet-over- 847 MPLS) and over circuit-oriented technologies such as SDH and OTN 848 (through different adaptation technologies such as LAPS X.86 and 849 GFP). This by taking into account that the MAC Address space is by 850 definition non-hierarchical. The latter implies the definition of an 851 identification space translating the topological location of the 852 Ethernet end-points from an IP-based perspective and this optimally 853 independently of the underlying bearer technology of the Ethernet 854 frames. 856 The ideal situation would be to define a "one size fits all" 857 solution. However, it is clear that inferring label value space from 858 the bearer technology implies the development of so-called snooping 859 approaches, while on the other side LAN PHY's would not scale such a 860 solution implying the transformation of Broadcast Access (BA) 861 environment into a NBMA one (using star, hub-and-spoke, or multi- 862 tree approaches). Therefore, a heuristic has to be provided to solve 863 these problems while avoiding introduction of complex address 864 resolution mechanisms for such environments. Broadcasts are mainly 865 used in LAN environments for address resolution (ARP) and 866 bootstrapping (DHCP) reasons. Thus a potential solution would be to 867 let the network operate in a BA mode for such operations and bring 868 its operational mode back to an NBMA mode for unicast/multicast frame 869 processing. The same would apply for unknown unicast frames. 871 Therefore, a first step towards a solution would be reached, if one 872 can guarantee a dual operational mode for these environments: 1) 873 first mode being backward compatible with the broadcast exchanges as 874 defined by the IEEE (using IEEE 802.1d and related, thus using an 875 associated control plane) and 2) the second mode being GMPLS 876 compatible (thus using a non-associated IP-based distributed control 877 plane) for the unicast operations 879 The next issue relates to the realization of resource reservation 880 over Ethernet interfaces using GMPLS signaling techniques and its 881 applicability. For more detailed considerations see [L2SC-LSP]. 883 4.2 Example 885 The following example details the usage of the concepts presented in 886 the previous sections of this document in delivering a virtual 887 topology for L2SC-over-LSC nodes. 889 Consider the following network topology: 891 1 2 892 | | 893 3---A---B---C---D---5 894 | | | | 895 | E---F | 896 | | | | 897 4---G---H---I---J---6 898 | | 899 7 8 901 In this topology each node identified with a letter is a dual 902 switching capable node (L2SC/LSC or L2SC/WBSC) and nodes identified 903 with a number refers to L2SC capable devices. 905 An Lambda LSP is established covering all dual-switching nodes [A-B- 906 C-D-J-I-F-E-H-G]. 907 This FA-LSP constitutes the virtual topology for the dual switching 908 nodes. This is viewed from the L2SC level as a L2SC capable multi- 909 access link that may be accessed (upon local policy basis) from each 910 node constituting the topology. Another example, would be, for 911 instance, a Lambda LSP routed over [A-B-C-D-J] but precluding access 912 to node C. 914 Afterwards, each node (more precisely the L2SC region) may trigger 915 the establishment of L2SC LSPs on top of this multi-access FA-LSP 916 that would allow setting up multi-partitioning of the bandwidth 917 capacity made available by the "fat pipe" having a higher ISC value. 919 These L2SC LSP's may be for instance, using the above example, [A-B- 920 C-D], [A-B-D-J-I-G] or [J-I-F-E], even if the latter wouldn't be 921 usable by any incoming LSP. Each of these L2SC LSP's are simply L2SC 922 FA-LSP's forming a L2SC-capable virtual topology. This topology can 923 be subsequently used by external devices to establish L2SC LSP's 924 using these FA's as links. 926 Bandwidth accounting is performed on a per FA basis, translating into 927 intermediate node bandwidth aggregation accounted on a per priority 928 basis. In turn, this accounting translates into restriction over the 929 accessibility of each of the links constituting the Lambda LSP. 931 The above example implies that currently defined ISCs (see [GMPLS- 932 RTG]) such as L2SC might be extended to more than one value with the 933 following relationship L2SC (=L2SC-1) < L2SC-2 < L2SC-3 < L2SC-4 < 934 TDM. The (data plane) flow aggregation mechanisms for L2SC LSPs being 935 out of scope of the present document. 937 4.3 Waveband switching 939 The GMPLS protocol suite, as currently defined, supports waveband 940 switching through inverse multiplexing or switching of individual 941 (contiguous) wavelength components. It may be thus appropriate to 942 integrate wavebands in the switching hierarchy in order to reflect, 943 at the control plane level, waveband physical components 944 (multiplexer/demultiplexer) availability at the data plane [WBEXT]. 945 Also, depending on the (passive/active) components used in an optical 946 network, wavelength spacing in the optical multiplex can vary. Some 947 components like multiplexer/demultiplexer impose or depend on that 948 spacing. Therefore, it may be appropriate to detail the component 949 capability with respect to spacing, and/or to indicate the number of 950 supported wavelengths per waveband. Moreover, one may also expect in 951 case of (standardized) waveband nominal frequency values some 952 simplification during the corresponding wavelength assignment. 954 In the MRN context, the main issue with Waveband Switching can be 955 viewed as follows. If the LSRs support in addition to waveband 956 switching an ISC in the set {PSC, L2SC, TDM, FSC} then waveband 957 switching can be assumed (from the control plane processing 958 viewpoint) as being equivalent to Lambda Switching, if one considers 959 labels as described here above. However if the additional switching 960 capability within a single device, or even network, includes 961 interfaces with LSC capability then either links should have a 962 specific resource class assigned or dedicated values should be 963 considered for the LSP Encoding Type, Switching Type and G-PID (when 964 bands are carried over fibers). 966 5. Conclusion 967 In this draft, we address the issues when using the GMPLS protocol 968 suite as a unified control plane for MRN environments. Several 969 proposals for enhancing the current GMPLS mechanisms are presented. 970 The proposals are based on current GMPLS mechanisms and in alignment 971 with GMPLS architecture (see [GMPLS-ARCH]). This memo analyzes the 972 suitability of the GMPLS protocol suite for the MRN environment, 973 keeping a strict and full alignment with the current and preferred 974 suite of signaling and routing protocols (in particular, OSPF, IS-IS, 975 RSVP-TE and LMP). 976 By starting from a single area context, the expectations coming out 977 from the first release of this memo, are clearly intended to open the 978 field to a more detailed description of the collaborative processes 979 within the GMPLS protocol suite. 981 The main guideline of this work is backward compatibility with the 982 current GMPLS protocols suite. The second guideline is limiting and 983 efficiently handling the complexity introduced. This memo provides an 984 introduction to MRNs and aspects to be considered. We invite the 985 CCAMP community to collaborate on progressing this critical GMPLS 986 topic: an integrated control plane supporting multiple data layers. 988 Security Considerations 990 In its current version, this memo does not introduce new security 991 consideration from the ones already detailed in the GMPLS protocol 992 suite. 994 References 996 [G.707] ITU-T, "Network node interface for the Synchronous 997 Digital Hierarchy", Recommendation G.707 999 [G.709] ITU-T, "Interfaces for the Optical Transport Network" 1000 Recommendation G.709 1002 [G.805] ITU-T, "Generic functional architecture of transport 1003 networks", Recommendation G.805 1005 [GMPLS-RTG] K. Kompella (Editor), Y. Rekhter (Editor) et al. 1006 "Routing Extensions in Support of Generalized MPLS", 1007 Internet Draft, Work in Progress, 1008 draft-ietf-ccamp-gmpls-routing-09.txt 1010 [GMPLS-G709] D. Papadimitriou (Editor) et al. "Generalized MPLS 1011 Signaling Extensions for G.709 Optical Transport 1012 Networks Control", Internet Draft, Work in Progress, 1013 draft-ietf-ccamp-gmpls-g709-06.txt 1015 [LSP-HIER] K. Kompella and Y. Rekhter, "LSP Hierarchy with 1016 Generalized MPLS TE", Internet Draft, Work in Progress, 1017 draft-ietf-mpls-lsp-hierarchy-08.txt 1019 [RECOVERY] CCAMP P&R Design Team, Analysis of Generalized Multi- 1020 Protocol Label Switching (GMPLS)-based Recovery 1021 Mechanisms (including Protection and Restoration), 1022 Work in Progress, 1023 draft-ietf-ccamp-gmpls-recovery-analysis-02.txt 1025 [INTER-AREA-AS] A. Ayyangar, J. Vasseur, " Inter-area and Inter-AS 1026 MPLS Traffic Engineering", Internet Draft, Work in 1027 Progress, 1028 draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt 1030 [L2SC-LSP] D. Papadimitriou, et. Al., "Generalized MPLS Signaling 1031 for Layer-2 Label Switched Paths (LSP)", Internet Draft, 1032 Work in Progress, 1033 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt 1035 [MAMLTE] K. Shiomoto et al., "Multi-area multi-layer traffic 1036 engineering using hierarchical LSPs in GMPLS networks", 1037 Internet Draft, Work in Progress 1038 draft-shiomoto-multiarea-te-01.txt. 1040 [MLRT] W. Imajuku et al., "Multilayer routing using multilayer 1041 switch capable LSRs, Internet Draft, Work in Progress, 1042 draft-imajuku-ml-routing-02.txt. 1044 [MPLS-BDL] K. Kompella, Y. Rekhter and Lou Berger, "Link Bundling 1045 in MPLS Traffic Engineering", Internet Draft, Work in 1046 Progress 1047 draft-ietf-mpls-bundle-04.txt 1049 [RFC-2370] R. Coltun, "The OSPF Opaque LSA Option", 1050 IETF RFC 2370 1052 [RFC-3471] L. Berger et al., "Generalized Multi-Protocol Label 1053 Switching (GMPLS) Signaling Functional Description", 1054 IETF RFC 3471 1056 [SONET-SDH] E. Mannie and D. Papadimitriou et al., "Generalized 1057 Multi-Protocol Label Switching Extensions for SONET and 1058 SDH Control", Internet Draft, Work in Progress, 1059 draft-ietf-ccamp-gmpls-sonet-sdh-08.txt 1061 [SRLG] D. Papadimitriou et al. "Shared Risk Link Groups 1062 Inference and Processing", Internet Draft, Work in 1063 Progress, 1065 [SURVEY] L. Berger, Y. Rekhter et al., "Generalized MPLS 1066 Signaling - Implementation Survey", 1067 Internet Draft, Work in Progress, 1068 draft-ietf-ccamp-gmpls-signaling-survey-03.txt 1070 [WBEXT] R. Douville et al., "Extensions to Generalized MPLS for 1071 Waveband Switching", Internet Draft, Work in Progress 1072 draft-douville-ccamp-gmpls-waveband-extensions-03.txt 1074 Acknowledgments 1076 We would like to thank here, Sven Van Den Bosch, Richard Douville, 1077 Olivier Audouin, Amaury Jourdan, Emmanuel Desmet and Bernard sales. 1079 The authors would like to thank Mr. Wataru Imajuku for the 1080 discussions on adaptation between regions [MLRT]. 1082 Author�s Addresses 1084 Dimitri Papadimitriou (Alcatel) 1085 Francis Wellensplein 1, 1086 B-2018 Antwerpen, Belgium 1087 Phone : +32 3 240 8491 1088 E-mail: dimitri.papadimitriou@alcatel.be 1090 Martin Vigoureux (Alcatel) 1091 Route de Nozay, 1092 91461 Marcoussis cedex, France 1093 Phone: +33 (0)1 69 63 18 52 1094 E-mail: martin.vigoureux@alcatel.fr 1096 Kohei Shiomoto (NTT Network Innovation Laboratories) 1097 3-9-11 Midori-cho 1098 Musashino-shi, Tokyo 180-8585, Japan 1099 Phone: +81 422 59 4402 1100 E-mail: shiomoto.kohei@lab.ntt.co.jp 1102 Deborah Brungard (AT&T) 1103 Rm. D1-3C22 - 200 S. Laurel Ave. 1104 Middletown, NJ 07748, USA 1105 Phone: +1 732 420 1573 1106 E-mail: dbrungard@att.com 1108 Jean-Louis Le Roux (FTRD/DAC/LAN) 1109 Avenue Pierre Marzin 1110 22300 Lannion, France 1111 Phone: +33 (0)2 96 05 30 20 1112 E-mail:jean-louis.leroux@rd.francetelecom.com 1114 Contributors 1116 Eiji Oki (NTT Network Innovation Laboratories) 1117 3-9-11 Midori-cho 1118 Musashino-shi, Tokyo 180-8585, Japan 1119 Phone : +81 422 59 3441 1120 E-mail: oki.eiji@lab.ntt.co.jp 1122 Nobuaki Matsuura (NTT Network Service Systems Laboratories) 1123 3-9-11 Midori-cho 1124 Musashino-shi, Tokyo 180-8585, Japan 1125 Phone : +81 422 59 3758 1126 E-mail: matsuura.nobuaki@lab.ntt.co.jp 1128 Emmanuel Dotaro (Alcatel) 1129 Route de Nozay, 1130 91461 Marcoussis cedex, France 1131 Phone : +33 1 6963 4723 1132 E-mail: emmanuel.dotaro@alcatel.fr