idnits 2.17.1 draft-ietf-ccamp-gmpls-architecture-07.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 57 longer pages, the longest (page 2) being 59 lines 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (May 2003) is 7651 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: 'ITU-T G.709' is mentioned on line 1523, but not defined == Missing Reference: 'RFC2205' is mentioned on line 1795, but not defined == Unused Reference: 'ITUT-G.707' is defined on line 2839, but no explicit reference was found in the text == Unused Reference: 'ITUT-G.709' is defined on line 2843, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-gmpls-recovery-functional-01 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-g709-03 == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-gmpls-overlay-01 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G.707' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G.709' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G.841' == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-09 == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-lmp-wdm-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-TE-GMPLS' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-09 ** Obsolete normative reference: RFC 1393 (Obsoleted by RFC 6814) ** Downref: Normative reference to an Informational RFC: RFC 2151 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2753 ** Obsolete normative reference: RFC 2925 (Obsoleted by RFC 4560) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 Summary: 12 errors (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric Mannie - Editor 3 Internet Draft 4 Category: Standard Track 6 Expiration date: November 2003 May 2003 8 Generalized Multi-Protocol Label Switching Architecture 10 draft-ietf-ccamp-gmpls-architecture-07.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Future data and transmission networks will consist of elements such 36 as routers, switches, Dense Wavelength Division Multiplexing (DWDM) 37 systems, Add-Drop Multiplexors (ADMs), photonic cross-connects 38 (PXCs), optical cross-connects (OXCs), etc. that will use 39 Generalized Multi-Protocol Label Switching (GMPLS) to dynamically 40 provision resources and to provide network survivability using 41 protection and restoration techniques. 43 This document describes the architecture of GMPLS. GMPLS extends 44 MPLS to encompass time-division (e.g. SONET/SDH, PDH, G.709), 45 wavelength (lambdas), and spatial switching (e.g. incoming port or 46 fiber to outgoing port or fiber). The focus of GMPLS is on the 47 control plane of these various layers since each of them can use 48 physically diverse data or forwarding planes. The intention is to 49 cover both the signaling and the routing part of that control plane. 51 E. Mannie (Editor) et al. Standard Track 1 52 1. Table of Contents 54 Status of this Memo .............................................. 1 55 Abstract ......................................................... 1 56 1. Table of Contents ............................................. 2 57 2. Conventions used in this document ............................. 3 58 3. Introduction .................................................. 3 59 3.1. Acronyms & Abbreviations .................................... 4 60 3.2. Multiple Types of Switching and Forwarding Hierarchies ...... 4 61 3.3. Extension of the MPLS Control Plane ......................... 6 62 3.4. GMPLS Key Extensions to MPLS-TE ............................. 9 63 4. Routing and Addressing Mode .................................. 10 64 4.1. Addressing of PSC and non-PSC layers ....................... 11 65 4.2. GMPLS Scalability Enhancements ............................. 11 66 4.3. TE Extensions to IP Routing Protocols ...................... 12 67 5. Unnumbered Links ............................................. 13 68 5.1. Unnumbered Forwarding Adjacencies .......................... 14 69 6. Link Bundling ................................................ 14 70 6.1. Restrictions on Bundling ................................... 15 71 6.2. Routing Considerations for Bundling ........................ 15 72 6.3. Signaling Considerations ................................... 16 73 6.3.1 Mechanism 1: Implicit Indication .......................... 16 74 6.3.2 Mechanism 2: Explicit Indication by Numbered Interface ID . 16 75 6.3.3 Mechanism 3: Explicit Indication by Unnumbered Interface ID 16 76 6.4. Unnumbered Bundled Link .................................... 17 77 6.5. Forming Bundled Links ...................................... 17 78 7. Relationship with the UNI .................................... 18 79 7.1. Relationship with the OIF UNI .............................. 18 80 7.2. Reachability across the UNI ................................ 19 81 8. Link Management .............................................. 19 82 8.1. Control Channel and Control Channel Management ............. 20 83 8.2. Link Property Correlation .................................. 21 84 8.3. Link Connectivity Verification ............................. 21 85 8.4. Fault Management ........................................... 22 86 8.5. LMP for DWDM Optical Line Systems (OLSs) ................... 23 87 9. Generalized Signaling ........................................ 24 88 9.1. Overview: How to Request an LSP ............................ 25 89 9.2. Generalized Label Request .................................. 26 90 9.3. SONET/SDH Traffic Parameters ............................... 27 91 9.4. G.709 Traffic Parameters ................................... 28 92 9.5. Bandwidth Encoding ......................................... 29 93 9.6. Generalized Label .......................................... 29 94 9.7. Waveband Switching ......................................... 30 95 9.8. Label Suggestion by the Upstream ........................... 30 96 9.9. Label Restriction by the Upstream .......................... 31 97 9.10. Bi-directional LSP ........................................ 31 98 9.11. Bi-directional LSP Contention Resolution .................. 32 99 9.12. Rapid Notification of Failure ............................. 33 100 9.13. Link Protection ........................................... 33 101 9.14. Explicit Routing and Explicit Label Control ............... 34 102 9.15. Route Recording ........................................... 35 103 9.16. LSP Modification and LSP Re-routing ....................... 35 104 9.17. LSP Administrative Status Handling ........................ 36 105 9.18. Control Channel Separation ................................ 36 107 E. Mannie (Editor) et al. Standard Track 2 108 10. Forwarding Adjacencies (FA) ................................. 37 109 10.1. Routing and Forwarding Adjacencies ........................ 38 110 10.2. Signaling Aspects ......................................... 39 111 10.3. Cascading of Forwarding Adjacencies ....................... 39 112 11. Routing and Signaling Adjacencies ........................... 39 113 12. Control Plane Fault Handling ................................ 40 114 13. LSP Protection and Restoration .............................. 41 115 13.1. Protection Escalation across Domains and Layers ........... 42 116 13.2. Mapping of Services to P&R Resources ...................... 43 117 13.3. Classification of P&R Mechanism Characteristics ........... 43 118 13.4. Different Stages in P&R ................................... 44 119 13.5. Recovery Strategies ....................................... 44 120 13.6. Recovery mechanisms: Protection schemes ................... 45 121 13.7. Recovery mechanisms: Restoration schemes .................. 45 122 13.8. Schema Selection Criteria ................................. 46 123 14. Network Management .......................................... 48 124 14.1. Network Management Systems (NMS) .......................... 48 125 14.2. Management Information Base (MIB) ......................... 48 126 14.3. Tools ..................................................... 49 127 14.4. Fault Correlation Between Multiple Layers ................. 49 128 15. Security Considerations ..................................... 50 129 16. Acknowledgements ............................................ 51 130 17. Intellectual Property Considerations ........................ 51 131 18. References .................................................. 51 132 18.1 Normative References ....................................... 51 133 18.2 Information References ..................................... 54 134 19. Author's Address ............................................ 55 135 20. Contributors ................................................ 55 136 Full Copyright Statement ........................................ 58 138 2. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 142 this document are to be interpreted as described in [RFC2119]. 144 3. Introduction 146 The architecture described in this document covers the main building 147 blocks needed to build a consistent control plane for multiple 148 switching layers. It does not restrict the way that these layers 149 work together. Different models can be applied: e.g. overlay, 150 augmented or integrated. Moreover, each pair of contiguous layers 151 may collaborate in different ways, resulting in a number of possible 152 combinations, at the discretion of manufacturers and operators. 154 This architecture clearly separates the control plane and the 155 forwarding plane. In addition, it also clearly separates the control 156 plane in two parts, the signaling plane containing the signaling 157 protocols and the routing plane containing the routing protocols. 159 This document is a generalization of the Multi-Protocol Label 160 Switching (MPLS) architecture [RFC3031], and in some cases may 161 differ slightly from that architecture since non packet-based 163 E. Mannie (Editor) et al. Standard Track 3 164 forwarding planes are now considered. It is not the intention of 165 this document to describe concepts already described in the current 166 MPLS architecture. The goal is to describe specific concepts of 167 Generalized MPLS (GMPLS). 169 However, some of the concepts explained hereafter are not part of 170 the current MPLS architecture and are applicable to both MPLS and 171 GMPLS (i.e. link bundling, unnumbered links, and LSP hierarchy). 172 Since these concepts were introduced together with GMPLS and since 173 they are of paramount importance for an operational GMPLS network, 174 they will be discussed here. 176 The organization of the remainder of this document is as follows. We 177 begin with an introduction of GMPLS. We then present the specific 178 GMPLS building blocks and explain how they can be combined together 179 to build an operational GMPLS network. Specific details of the 180 separate building blocks can be found in the corresponding 181 documents. 183 3.1. Acronyms & Abbreviations 185 AS Autonomous System 186 BGP Border Gateway Protocol 187 CR-LDP Constraint-based Routing LDP 188 CSPF Constraint-based Shortest Path First 189 DWDM Dense Wavelength Division Multiplexing 190 FA Forwarding Adjacency 191 GMPLS Generalized Multi-Protocol Label Switching 192 IGP Interior Gateway Protocol 193 LDP Label Distribution Protocol 194 LMP Link Management Protocol 195 LSA Link State Advertisement 196 LSR Label Switching Router 197 LSP Label Switched Path 198 MIB Management Information Base 199 MPLS Multi-Protocol Label Switching 200 NMS Network Management System 201 OXC Optical Cross-Connect 202 PXC Photonic Cross-Connect 203 RSVP ReSource reserVation Protocol 204 SDH Synchronous Digital Hierarchy 205 SONET Synchronous Optical Networks 206 STM(-N) Synchronous Transport Module (-N) 207 STS(-N) Synchronous Transport Signal-Level N (SONET) 208 TDM Time Division Multiplexing 209 TE Traffic Engineering 211 3.2. Multiple Types of Switching and Forwarding Hierarchies 213 Generalized MPLS (GMPLS) differs from traditional MPLS in that it 214 supports multiple types of switching, i.e. the addition of support 215 for TDM, lambda, and fiber (port) switching. The support for the 216 additional types of switching has driven GMPLS to extend certain 217 base functions of traditional MPLS and, in some cases, to add 219 E. Mannie (Editor) et al. Standard Track 4 220 functionality. These changes and additions impact basic LSP 221 properties: how labels are requested and communicated, the 222 unidirectional nature of LSPs, how errors are propagated, and 223 information provided for synchronizing the ingress and egress LSRs. 225 The MPLS architecture [RFC3031] was defined to support the 226 forwarding of data based on a label. In this architecture, Label 227 Switching Routers (LSRs) were assumed to have a forwarding plane 228 that is capable of (a) recognizing either packet or cell boundaries, 229 and (b) being able to process either packet headers (for LSRs 230 capable of recognizing packet boundaries) or cell headers (for LSRs 231 capable of recognizing cell boundaries). 233 The original MPLS architecture is here being extended to include 234 LSRs whose forwarding plane recognizes neither packet, nor cell 235 boundaries, and therefore, can't forward data based on the 236 information carried in either packet or cell headers. Specifically, 237 such LSRs include devices where the switching decision is based on 238 time slots, wavelengths, or physical ports. So, the new set of LSRs, 239 or more precisely interfaces on these LSRs, can be subdivided into 240 the following classes: 242 1. Packet Switch Capable (PSC) interfaces: 244 Interfaces that recognize packet boundaries and can forward data 245 based on the content of the packet header. Examples include 246 interfaces on routers that forward data based on the content of the 247 IP header and interfaces on routers that switch data based on the 248 content of the MPLS "shim" header. 250 2. Layer-2 Switch Capable (L2SC) interfaces: 252 Interfaces that recognize frame/cell boundaries and can switch data 253 based on the content of the frame/cell header. Examples include 254 interfaces on Ethernet bridges that switch data based on the content 255 of the MAC header and interfaces on ATM-LSRs that forward data based 256 on the ATM VPI/VCI. 258 3. Time-Division Multiplex Capable (TDM) interfaces: 260 Interfaces that switch data based on the data's time slot in a 261 repeating cycle. An example of such an interface is that of a 262 SONET/SDH Cross-Connect (XC), Terminal Multiplexer (TM), or Add-Drop 263 Multiplexer (ADM). Other examples include interfaces providing G.709 264 TDM capabilities (the "digital wrapper") and PDH interfaces. 266 4. Lambda Switch Capable (LSC) interfaces: 268 Interfaces that switch data based on the wavelength on which the 269 data is received. An example of such an interface is that of a 270 Photonic Cross-Connect (PXC) or Optical Cross-Connect (OXC) that can 271 operate at the level of an individual wavelength. Additional 272 examples include PXC interfaces that can operate at the level of a 274 E. Mannie (Editor) et al. Standard Track 5 275 group of wavelengths, i.e. a waveband and G.709 interfaces providing 276 optical capabilities. 278 5. Fiber-Switch Capable (FSC) interfaces: 280 Interfaces that switch data based on a position of the data in the 281 (real world) physical spaces. An example of such an interface is 282 that of a PXC or OXC that can operate at the level of a single or 283 multiple fibers. 285 A circuit can be established only between, or through, interfaces of 286 the same type. Depending on the particular technology being used for 287 each interface, different circuit names can be used, e.g. SDH 288 circuit, optical trail, light-path, etc. In the context of GMPLS, 289 all these circuits are referenced by a common name: Label Switched 290 Path (LSP). 292 The concept of nested LSP (LSP within LSP), already available in the 293 traditional MPLS, facilitates building a forwarding hierarchy, i.e. 294 a hierarchy of LSPs. This hierarchy of LSPs can occur on the same 295 interface, or between different interfaces. 297 For example, a hierarchy can be built if an interface is capable of 298 multiplexing several LSPs from the same technology (layer), e.g. a 299 lower order SONET/SDH LSP (e.g. VT2/VC-12) nested in a higher order 300 SONET/SDH LSP (e.g. STS-3c/VC-4). Several levels of signal (LSP) 301 nesting are defined in the SONET/SDH multiplexing hierarchy. 303 The nesting can also occur between interface types. At the top of 304 the hierarchy are FSC interfaces, followed by LSC interfaces, 305 followed by TDM interfaces, followed by L2SC, and followed by PSC 306 interfaces. This way, an LSP that starts and ends on a PSC interface 307 can be nested (together with other LSPs) into an LSP that starts and 308 ends on a L2SC interface. This LSP, in turn, can be nested (together 309 with other LSPs) into an LSP that starts and ends on a TDM 310 interface. In turn, this LSP can be nested (together with other 311 LSPs) into an LSP that starts and ends on a LSC interface, which in 312 turn can be nested (together with other LSPs) into an LSP that 313 starts and ends on a FSC interface. 315 3.3. Extension of the MPLS Control Plane 317 The establishment of LSPs that span only Packet Switch Capable (PSC) 318 or Layer-2 Switch Capable (L2SC) interfaces is defined for the 319 original MPLS and/or MPLS-TE control planes. GMPLS extends these 320 control planes to support each of the five classes of interfaces 321 (i.e. layers) defined in the previous section. 323 Note that the GMPLS control plane supports an overlay model, an 324 augmented model, and a peer (integrated) model. In the near term, 325 GMPLS appears to be very suitable for controlling each layer 326 independently. This elegant approach will facilitate the future 327 deployment of other models. 329 E. Mannie (Editor) et al. Standard Track 6 330 The GMPLS control plane is made of several building blocks are 331 described in more detail in the following sections. These building 332 blocks are based on well-known signaling and routing protocols that 333 have been extended and/or modified to support GMPLS. They use IPv4 334 and/or IPv6 addresses. Only one new specialized protocol is required 335 to support the operations of GMPLS, a signaling protocol for link 336 management [LMP]. 338 GMPLS is indeed based on the Traffic Engineering (TE) extensions to 339 MPLS, a.k.a. MPLS-TE [RFC2702]. This, because most of the 340 technologies that can be used below the PSC level requires some 341 traffic engineering. The placement of LSPs at these levels needs in 342 general to consider several constraints (such as framing, bandwidth, 343 protection capability, etc) and to bypass the legacy Shortest-Path 344 First (SPF) algorithm. Note, however, that this is not mandatory and 345 that in some cases SPF routing can be applied. 347 In order to facilitate constrained-based SPF routing of LSPs, nodes 348 that perform LSP establishment need more information about the links 349 in the network than standard intra-domain routing protocols provide. 350 These TE attributes are distributed using the transport mechanisms 351 already available in IGPs (e.g. flooding) and taken into 352 consideration by the LSP routing algorithm. Optimization of the LSP 353 routes may also require some external simulations using heuristics 354 that serve as input for the actual path calculation and LSP 355 establishment process. 357 By definition, a TE link is a representation in the IS-IS/OSPF Link 358 State advertisements and in the link state database of certain 359 physical resources, and their properties, between two GMPLS nodes. 360 TE Links are used by the GMPLS control plane (routing and signaling) 361 for establishing LSPs. 363 Extensions to traditional routing protocols and algorithms are 364 needed to uniformly encode and carry TE link information, and 365 explicit routes (e.g. source routes) are required in the signaling. 366 In addition, the signaling must now be capable of transporting the 367 required circuit (LSP) parameters such as the bandwidth, the type of 368 signal, the desired protection and/or restoration, the position in a 369 particular multiplex, etc. Most of these extensions have already 370 been defined for PSC and L2SC traffic engineering with MPLS. GMPLS 371 primarily defines additional extensions for TDM, LSC, and FSC 372 traffic engineering. A very few elements are technology specific. 374 Thus, GMPLS extends the two signaling protocols defined for MPLS-TE 375 signaling, i.e. RSVP-TE [RFC3209] and CR-LDP [RFC3212]. However, 376 GMPLS does not specify which one of these two signaling protocols 377 must be used. It is the role of manufacturers and operators to 378 evaluate the two possible solutions for their own interest. 380 Since GMPLS signalling is based on RSVP-TE and CR-LDP, it mandates a 381 downstream-on-demand label allocation and distribution, with ingress 382 initiated ordered control. Liberal label retention is normally used, 383 but conservative label retention mode could also be used. 385 E. Mannie (Editor) et al. Standard Track 7 386 Furthermore, there is no restriction on the label allocation 387 strategy, it can be request/signaling driven (obvious for circuit 388 switching technologies), traffic/data driven, or even topology 389 driven. There is also no restriction on the route selection; 390 explicit routing is normally used (strict or loose) but hop-by-hop 391 routing could be used as well. 393 GMPLS also extends two traditional intra-domain link-state routing 394 protocols already extended for TE purposes, i.e. OSPF-TE [OSPF-TE] 395 and IS-IS-TE [ISIS-TE]. However, if explicit (source) routing is 396 used, the routing algorithms used by these protocols no longer need 397 to be standardized. Extensions for inter-domain routing (e.g. BGP) 398 are for further study. 400 The use of technologies like DWDM (Dense Wavelength Division 401 Multiplexing) implies that we can now have a very large number of 402 parallel links between two directly adjacent nodes (hundreds of 403 wavelengths, or even thousands of wavelengths if multiple fibers are 404 used). Such a large number of links was not originally considered 405 for an IP or MPLS control plane, although it could be done. Some 406 slight adaptations of that control plane are thus required if we 407 want to better reuse it in the GMPLS context. 409 For instance, the traditional IP routing model assumes the 410 establishment of a routing adjacency over each link connecting two 411 adjacent nodes. Having such a large number of adjacencies does not 412 scale well. Each node needs to maintain each of its adjacencies one 413 by one, and link state routing information must be flooded 414 throughout the network. 416 To solve this issue the concept of link bundling was introduced. 417 Moreover, the manual configuration and control of these links, even 418 if they are unnumbered, becomes impractical. The Link Management 419 Protocol (LMP) was specified to solve these issues. 421 LMP runs between data plane adjacent nodes and is used to manage TE 422 links. Specifically, LMP provides mechanisms to maintain control 423 channel connectivity (IP Control Channel Maintenance), verify the 424 physical connectivity of the data-bearing links (Link Verification), 425 correlate the link property information (Link Property Correlation), 426 and manage link failures (Fault Localization and Fault 427 Notification). A unique feature of LMP is that it is able to 428 localize faults in both opaque and transparent networks (i.e. 429 independent of the encoding scheme and bit rate used for the data). 431 LMP is defined in the context of GMPLS, but is specified 432 independently of the GMPLS signaling specification since it is a 433 local protocol running between data-plane adjacent nodes. 434 Consequently, LMP can be used in other contexts with non-GMPLS 435 signaling protocols. 437 MPLS signaling and routing protocols require at least one bi- 438 directional control channel to communicate even if two adjacent 439 nodes are connected by unidirectional links. Several control 441 E. Mannie (Editor) et al. Standard Track 8 442 channels can be used. LMP can be used to establish, maintain and 443 manage these control channels. 445 GMPLS does not specify how these control channels must be 446 implemented, but GMPLS requires IP to transport the signaling and 447 routing protocols over them. Control channels can be either in-band 448 or out-of-band, and several solutions can be used to carry IP. Note 449 also that one type of LMP message (the Test message) is used in-band 450 in the data plane and may not be transported over IP, but this is a 451 particular case, needed to verify connectivity in the data plane. 453 3.4. GMPLS Key Extensions to MPLS-TE 455 Some key extensions brought by GMPLS to MPLS-TE are highlighted in 456 the following. Some of them are key advantages of GMPLS to control 457 TDM, LSC and FSC layers. 459 - In MPLS-TE, links traversed by an LSP can include an intermix of 460 links with heterogeneous label encoding (e.g. links between routers, 461 links between routers and ATM-LSRs, and links between ATM-LSRs. 462 GMPLS extends this by including links where the label is encoded as 463 a time slot, or a wavelength, or a position in the (real world) 464 physical space. 466 - In MPLS-TE, an LSP that carries IP has to start and end on a 467 router. GMPLS extends this by requiring an LSP to start and end on 468 similar type of interfaces. 470 - The type of a payload that can be carried in GMPLS by an LSP is 471 extended to allow such payloads as SONET/SDH, G.709, 1Gb or 10Gb 472 Ethernet, etc. 474 - The use of Forwarding Adjacencies (FA) provides a mechanism that 475 can improve bandwidth utilization, when bandwidth allocation can be 476 performed only in discrete units. It offers also a mechanism to 477 aggregate forwarding state, thus allowing the number of required 478 labels to be reduced. 480 - GMPLS allows suggesting a label by an upstream node to reduce the 481 setup latency. This suggestion may be overridden by a downstream 482 node but in some cases, at the cost of higher LSP setup time. 484 - GMPLS extends on the notion of restricting the range of labels 485 that may be selected by a downstream node. In GMPLS, an upstream 486 node may restrict the labels for an LSP along either a single hop or 487 the entire LSP path. This feature is useful in photonic networks 488 where wavelength conversion may not be available. 490 - While traditional TE-based (and even LDP-based) LSPs are 491 unidirectional, GMPLS supports the establishment of bi-directional 492 LSPs. 494 - GMPLS supports the termination of an LSP on a specific egress 495 port, i.e. the port selection at the destination side. 497 E. Mannie (Editor) et al. Standard Track 9 498 - GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid 499 failure notification. 501 Note also some other key differences between MPLS-TE and GMPLS: 503 - For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP 504 can be performed only in discrete units. 506 - It is expected to have (much) fewer labels on TDM, LSC or FSC 507 links than on PSC or L2SC links, because the former are physical 508 labels instead of logical labels. 510 4. Routing and Addressing Model 512 GMPLS is based on the IP routing and addressing models. This assumes 513 that IPv4 and/or IPv6 addresses are used to identify interfaces but 514 also that traditional (distributed) IP routing protocols are reused. 515 Indeed, the discovery of the topology and the resource state of all 516 links in a routing domain is achieved via these routing protocols. 518 Since control and data planes are de-coupled in GMPLS, control-plane 519 neighbors (i.e. IGP-learnt neighbors) may not be data-plane 520 neighbors. Hence, mechanisms like LMP are needed to associate TE 521 links with neighboring nodes. 523 IP addresses are not used only to identify interfaces of IP hosts 524 and routers, but more generally to identify any PSC and non-PSC 525 interfaces. Similarly, IP routing protocols are used to find routes 526 for IP datagrams with a SPF algorithm; they are also used to find 527 routes for non-PSC circuits by using a CSPF algorithm. 529 However, some additional mechanisms are needed to increase the 530 scalability of these models and to deal with specific traffic 531 engineering requirements of non-PSC layers. These mechanisms will be 532 introduced in the following. 534 Re-using existing IP routing protocols allows for non-PSC layers 535 taking advantage of all the valuable developments that took place 536 since years for IP routing, in particular, in the context of intra- 537 domain routing (link-state routing) and inter-domain routing (policy 538 routing). 540 In an overlay model, each particular non-PSC layer can be seen as a 541 set of Autonomous Systems (ASs) interconnected in an arbitrary way. 542 Similarly to the traditional IP routing, each AS is managed by a 543 single administrative authority. For instance, an AS can be an 544 SONET/SDH network operated by a given carrier. The set of 545 interconnected ASs can be viewed as SONET/SDH internetworks. 547 Exchange of routing information between ASs can be done via an 548 inter-domain routing protocol like BGP-4. There is obviously a huge 549 value of re-using well-known policy routing facilities provided by 550 BGP in a non-PSC context. Extensions for BGP traffic engineering 552 E. Mannie (Editor) et al. Standard Track 10 553 (BGP-TE) in the context of non-PSC layers are left for further 554 study. 556 Each AS can be sub-divided in different routing domains, and each 557 can run a different intra-domain routing protocol. In turn, each 558 routing-domain can be divided in areas. 560 A routing domain is made of GMPLS enabled nodes (i.e. a network 561 device including a GMPLS entity). These nodes can be either edge 562 nodes (i.e. hosts, ingress LSRs or egress LSRs), or internal LSRs. 563 An example of non-PSC host is an SONET/SDH Terminal Multiplexer 564 (TM). Another example is an SONET/SDH interface card within an IP 565 router or ATM switch. 567 Note that traffic engineering in the intra-domain requires the use 568 of link-state routing protocols like OSPF or IS-IS. 570 GMPLS defines extensions to these protocols. These extensions are 571 needed to disseminate specific TDM, LSC and FSC static and dynamic 572 characteristics related to nodes and links. The current focus is on 573 intra-area traffic engineering. However, inter-area traffic 574 engineering is also under investigation. 576 4.1. Addressing of PSC and non-PSC Layers 578 The fact that IPv4 and/or IPv6 addresses are used doesn't imply at 579 all that they should be allocated in the same addressing space than 580 public IPv4 and/or IPv6 addresses used for the Internet. Private IP 581 addresses can be used if they don't require to be exchanged with any 582 other operator; public IP addresses are otherwise required. Of 583 course, if an integrated model is used, two layers could share the 584 same addressing space. Finally, TE links may be "unnumbered" i.e. 585 not have any IP addresses, in case IP addresses are not available, 586 or the overhead of managing them is considered too high. 588 Note that there is a benefit of using public IPv4 and/or IPv6 589 Internet addresses for non-PSC layers if an integrated model with 590 the IP layer is foreseen. 592 If we consider the scalability enhancements proposed in the next 593 section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing 594 spaces are both more than sufficient to accommodate any non-PSC 595 layer. We can reasonably expect to have much less non-PSC devices 596 (e.g. SONET/SDH nodes) than we have today IP hosts and routers. 598 4.2. GMPLS Scalability Enhancements 600 TDM, LSC and FSC layers introduce new constraints on the IP 601 addressing and routing models since several hundreds of parallel 602 physical links (e.g. wavelengths) can now connect two nodes. Most of 603 the carriers already have today several tens of wavelengths per 604 fiber between two nodes. New generation of DWDM systems will allow 605 several hundreds of wavelengths per fiber. 607 E. Mannie (Editor) et al. Standard Track 11 608 It becomes rather impractical to associate an IP address with each 609 end of each physical link, to represent each link as a separate 610 routing adjacency, and to advertise and to maintain link states for 611 each of these links. For that purpose, GMPLS enhances the MPLS 612 routing and addressing models to increase their scalability. 614 Two optional mechanisms can be used to increase the scalability of 615 the addressing and the routing: unnumbered links and link bundling. 616 These two mechanisms can also be combined. They require extensions 617 to signaling (RSVP-TE and CR-LDP) and routing (OSPF-TE and IS-IS-TE) 618 protocols. 620 4.3. TE Extensions to IP Routing Protocols 622 Traditionally, a TE link is advertised as an adjunct to a "regular" 623 OSPF or IS-IS link, i.e., an adjacency is brought up on the link. 624 When the link is up, both the regular IGP properties of the link 625 (basically, the SPF metric) and the TE properties of the link are 626 then advertised. 628 However, GMPLS challenges this notion in three ways: 630 - First, links that are non-PSC may yet have TE properties; however, 631 an OSPF adjacency could not be brought up directly on such links. 633 - Second, an LSP can be advertised as a point-to-point TE link in 634 the routing protocol, i.e. as a Forwarding Adjacency (FA); thus, an 635 advertised TE link need no longer be between two OSPF direct 636 neighbors. Forwarding Adjacencies (FA) are further described in 637 Section 10. 639 - Third, a number of links may be advertised as a single TE link 640 (e.g. for improved scalability), so again, there is no longer a one- 641 to-one association of a regular adjacency and a TE link. 643 Thus, we have a more general notion of a TE link. A TE link is a 644 logical link that has TE properties. Some of these properties may be 645 configured on the advertising LSR, others may be obtained from other 646 LSRs by means of some protocol, and yet others may be deduced from 647 the component(s) of the TE link. 649 An important TE property of a TE link is related to the bandwidth 650 accounting for that link. GMPLS will define different accounting 651 rules for different non-PSC layers. Generic bandwidth attributes are 652 however defined by the TE routing extensions and by GMPLS, such as 653 the unreserved bandwidth, the maximum reservable bandwidth and the 654 maximum LSP bandwidth. 656 It is expected in a dynamic environment to have frequent changes of 657 bandwidth accounting information. A flexible policy for triggering 658 link state updates based on bandwidth thresholds and link-dampening 659 mechanism can be implemented. 661 E. Mannie (Editor) et al. Standard Track 12 662 TE properties associated with a link should also capture protection 663 and restoration related characteristics. For instance, shared 664 protection can be elegantly combined with bundling. Protection and 665 restoration are mainly generic mechanisms also applicable to MPLS. 666 It is expected that they will first be developed for MPLS and later 667 on generalized to GMPLS. 669 A TE link between a pair of LSRs doesn't imply the existence of an 670 IGP adjacency between these LSRs. A TE link must also have some 671 means by which the advertising LSR can know of its liveness (e.g. by 672 using LMP hellos). When an LSR knows that a TE link is up, and can 673 determine the TE link's TE properties, the LSR may then advertise 674 that link to its GMPLS enhanced OSPF or IS-IS neighbors using the TE 675 objects/TLVs. We call the interfaces over which GMPLS enhanced OSPF 676 or IS-IS adjacencies are established "control channels". 678 5. Unnumbered Links 680 Unnumbered links (or interfaces) are links (or interfaces) that do 681 not have IP addresses. Using such links involves two capabilities: 682 the ability to specify unnumbered links in MPLS TE signaling, and 683 the ability to carry (TE) information about unnumbered links in IGP 684 TE extensions of IS-IS-TE and OSPF-TE. 686 A. The ability to specify unnumbered links in MPLS TE signaling 687 requires extensions to RSVP-TE [RFC3477] and CR-LDP [RFC3480]. The 688 MPLS-TE signaling doesn't provide support for unnumbered links, 689 because it doesn't provide a way to indicate an unnumbered link in 690 its Explicit Route Object/TLV and in its Record Route Object 691 (there is no such TLV for CR-LDP). GMPLS defines simple extensions 692 to indicate an unnumbered link in these two Objects/TLVs, using a 693 new Unnumbered Interface ID sub-object/sub-TLV. 695 Since unnumbered links are not identified by an IP address, then 696 for the purpose of MPLS TE each end need some other identifier, 697 local to the LSR to which the link belongs. LSRs at the two end- 698 points of an unnumbered link exchange with each other the 699 identifiers they assign to the link. Exchanging the identifiers 700 may be accomplished by configuration, by means of a protocol such 701 as LMP ([LMP]), by means of RSVP-TE/CR-LDP (especially in the case 702 where a link is a Forwarding Adjacency, see below), or by means of 703 IS-IS or OSPF extensions ([ISIS-TE-GMPLS], [OSPF-TE-GMPLS]). 705 Consider an (unnumbered) link between LSRs A and B. LSR A chooses 706 an identifier for that link. So does LSR B. From A's perspective 707 we refer to the identifier that A assigned to the link as the 708 "link local identifier" (or just "local identifier"), and to the 709 identifier that B assigned to the link as the "link remote 710 identifier" (or just "remote identifier"). Likewise, from B's 711 perspective the identifier that B assigned to the link is the 712 local identifier, and the identifier that A assigned to the link 713 is the remote identifier. 715 E. Mannie (Editor) et al. Standard Track 13 716 The new Unnumbered Interface ID sub-object/sub-TLV for the ER 717 Object/TLV contains the Router ID of the LSR at the upstream end 718 of the unnumbered link and the link local identifier with respect 719 to that upstream LSR. 721 The new Unnumbered Interface ID sub-object for the RR Object 722 contains the link local identifier with respect to the LSR that 723 adds it in the RR Object. 725 B. The ability to carry (TE) information about unnumbered links in 726 IGP TE extensions requires new sub-TLVs for the extended IS 727 reachability TLV defined in IS-IS-TE and for the TE LSA (which is 728 an opaque LSA) defined in OSPF-TE. A Link Local Identifier sub-TLV 729 and a Link Remote Identifier sub-TLV are defined. 731 5.1. Unnumbered Forwarding Adjacencies 733 If an LSR that originates an LSP advertises this LSP as an 734 unnumbered FA in IS-IS or OSPF, or the LSR uses this FA as an 735 unnumbered component link of a bundled link, the LSR must allocate 736 an Interface ID to that FA. If the LSP is bi-directional, the tail 737 end does the same and allocates an Interface ID to the reverse FA. 739 Signaling has been enhanced to carry the Interface ID of a FA in the 740 new LSP Tunnel Interface ID object/TLV. This object/TLV contains the 741 Router ID (of the LSR that generates it) and the Interface ID. It is 742 called the Forward Interface ID when it appears in a Path/REQUEST 743 message, and it is called the Reverse Interface ID when it appears 744 in the Resv/MAPPING message. 746 6. Link Bundling 748 The concept of link bundling is essential in certain networks 749 employing the GMPLS control plane as is defined in [BUNDLE]. A 750 typical example is an optical meshed network where adjacent optical 751 cross-connects (LSRs) are connected by several hundreds of parallel 752 wavelengths. In this network, consider the application of link state 753 routing protocols, like OSPF or IS-IS, with suitable extensions for 754 resource discovery and dynamic route computation. Each wavelength 755 must be advertised separately to be used, except if link bundling is 756 used. 758 When a pair of LSRs is connected by multiple links, it is possible 759 to advertise several (or all) of these links as a single link into 760 OSPF and/or IS-IS. This process is called link bundling, or just 761 bundling. The resulting logical link is called a bundled link as its 762 physical links are called component links (and are identified by 763 interface indexes). 765 The result is that a combination of three identifiers ((bundled) 766 link identifier, component link identifier, label) is sufficient to 767 unambiguously identify the appropriate resources used by an LSP. 769 E. Mannie (Editor) et al. Standard Track 14 770 The purpose of link bundling is to improve routing scalability by 771 reducing the amount of information that has to be handled by OSPF 772 and/or IS-IS. This reduction is accomplished by performing 773 information aggregation/abstraction. As with any other information 774 aggregation/abstraction, this results in losing some of the 775 information. To limit the amount of losses one need to restrict the 776 type of the information that can be aggregated/abstracted. 778 6.1. Restrictions on Bundling 780 The following restrictions are required for bundling links. All 781 component links in a bundle must begin and end on the same pair of 782 LSRs; and share some common characteristics or properties defined in 783 [OSPF-TE] and [ISIS-TE], i.e. they must have the same: 785 - Link Type (i.e. point-to-point or multi-access), 786 - TE Metric (i.e. an administrative cost), 787 - Set of Resource Classes at each end of the links (i.e. colors). 789 Note that a FA may also be a component link. In fact, a bundle can 790 consist of a mix of point-to-point links and FAs, but all sharing 791 some common properties. 793 6.2. Routing Considerations for Bundling 795 A bundled link is just another kind of TE link such as those defined 796 by [GMPLS-ROUTING]. The liveness of the bundled link is determined 797 by the liveness of each its component links. A bundled link is alive 798 when at least one of its component links is alive. The liveness of a 799 component link can be determined by any of several means: IS-IS or 800 OSPF hellos over the component link, or RSVP Hello (hop local), or 801 LMP hellos (link local), or from layer 1 or layer 2 indications. 803 Note that (according to the RSVP-TE specification [RFC3209]) the 804 RSVP Hello mechanism is intended to be used when notification of 805 link layer failures is not available and unnumbered links are not 806 used, or when the failure detection mechanisms provided by the link 807 layer are not sufficient for timely node failure detection. 809 Once a bundled link is determined to be alive, it can be advertised 810 as a TE link and the TE information can be flooded. If IS-IS/OSPF 811 hellos are run over the component links, IS-IS/OSPF flooding can be 812 restricted to just one of the component links. 814 Note that advertising a (bundled) TE link between a pair of LSRs 815 doesn't imply that there is an IGP adjacency between these LSRs that 816 is associated with just that link. In fact, in certain cases a TE 817 link between a pair of LSRs could be advertised even if there is no 818 IGP adjacency at all between the LSR (e.g. when the TE link is an 819 FA). 821 Forming a bundled link consist in aggregating the identical TE 822 parameters of each individual component link to produce aggregated 824 E. Mannie (Editor) et al. Standard Track 15 825 TE parameters. A TE link as defined by [GMPLS-ROUTING] has many 826 parameters; adequate aggregation rules must be defined for each one. 828 Some parameters can be sums of component characteristics such as the 829 unreserved bandwidth and the maximum reservable bandwidth. Bandwidth 830 information is an important part of a bundle advertisement and it 831 must be clearly defined since an abstraction is done. 833 A GMPLS node with bundled links must apply admission control on a 834 per-component link basis. 836 6.3. Signaling Considerations 838 Typically, an LSP's explicit route (e.g. contained in an explicit 839 route Object/TLV) will choose the bundled link to be used for the 840 LSP, but not the component link(s). This because information about 841 the bundled link is flooded but information about the component 842 links is not. 844 The choice of the component link to use is always made by an 845 upstream node. If the LSP is bi-directional, the upstream node 846 chooses a component link in each direction. 848 Three mechanisms for indicating this choice to the downstream node 849 are possible. 851 6.3.1. Mechanism 1: Implicit Indication 853 This mechanism requires that each component link has a dedicated 854 signaling channel (e.g., the link is a Sonet/SDH link using the DCC 855 for in-band signaling). The upstream node tells the receiver which 856 component link to use by sending the message over the chosen 857 component link's dedicated signaling channel. Note that this 858 signaling channel can be in-band or out-of-band. In this last case, 859 the association between the signaling channel and that component 860 link need to be explicitly configured. 862 6.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID 864 This mechanism requires that the component link has a unique remote 865 IP address. The upstream node indicates the choice of the component 866 link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying 867 either an IPv4 or an IPv6 address in the Path/Label Request message 868 (see [RFC3473]/[RFC3472], respectively). For a bi-directional LSP, a 869 component link is provided for each direction by the upstream node. 871 This mechanism does not require each component link to have its own 872 control channel. In fact, it doesn't even require the whole 873 (bundled) link to have its own control channel. 875 6.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID 877 With this mechanism, each component link that is unnumbered is 878 assigned a unique Interface Identifier (32 bits value). The upstream 880 E. Mannie (Editor) et al. Standard Track 16 881 node indicates the choice of the component link by including a new 882 IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message 883 (see [RFC3473]/[RFC3472], respectively). 885 This object/TLV carries the component interface ID in the downstream 886 direction for a unidirectional LSP, and in addition, the component 887 interface ID in the upstream direction for a bi-directional LSP. 889 The two LSRs at each end of the bundled link exchange these 890 identifiers. Exchanging the identifiers may be accomplished by 891 configuration, by means of a protocol such as LMP (preferred 892 solution), by means of RSVP-TE/CR-LDP (especially in the case where 893 a component link is a Forwarding Adjacency), or by means of IS-IS or 894 OSPF extensions. 896 This mechanism does not require each component link to have its own 897 control channel. In fact, it doesn't even require the whole 898 (bundled) link to have its own control channel. 900 6.4. Unnumbered Bundled Link 902 A bundled link may itself be numbered or unnumbered independent of 903 whether the component links are numbered or not. This affects how 904 the bundled link is advertised in IS-IS/OSPF and the format of LSP 905 EROs that traverse the bundled link. Furthermore, unnumbered 906 Interface Identifiers for all unnumbered outgoing links of a given 907 LSR (whether component links, Forwarding Adjacencies or bundled 908 links) must be unique in the context of that LSR. 910 6.5. Forming Bundled Links 912 The generic rule for bundling component links is to place those 913 links that are correlated in some manner in the same bundle. If 914 links may be correlated based on multiple properties then the 915 bundling may be applied sequentially based on these properties. For 916 instance, links may be first grouped based on the first property. 917 Each of these groups may be then divided into smaller groups based 918 on the second property and so on. The main principle followed in 919 this process is that the properties of the resulting bundles should 920 be concisely summarizable. Link bundling may be done automatically 921 or by configuration. Automatic link bundling can apply bundling 922 rules sequentially to produce bundles. 924 For instance, the first property on which component links may be 925 correlated could be the Interface Switching Capability [GMPLS- 926 ROUTING], the second property could be the Encoding [GMPLS-ROUTING], 927 the third property could be the Administrative Weight (cost), the 928 fourth property could be the Resource Classes and finally links may 929 be correlated based on other metrics such as SRLG (Shared Risk Link 930 Groups). 932 When routing an alternate path for protection purposes, the general 933 principle followed is that the alternate path is not routed over any 934 link belonging to an SRLG that belongs to some link of the primary 936 E. Mannie (Editor) et al. Standard Track 17 937 path. Thus, the rule to be followed is to group links belonging to 938 exactly the same set of SRLGs. 940 This type of sequential sub-division may result in a number of 941 bundles between two adjacent nodes. In practice, however, the link 942 properties may not be very heterogeneous among component links 943 between two adjacent nodes. Thus, the number of bundles in practice 944 may not be large. 946 7. Relationship with the UNI 948 The interface between an edge GMPLS node and a GMPLS LSR on the 949 network side may be referred to as a User to Network Interface 950 (UNI), while the interface between two-network side LSRs may be 951 referred to as a Network to Network Interface (NNI). 953 GMPLS does not specify separately a UNI and an NNI. Edge nodes are 954 connected to LSRs on the network side, and these LSRs are in turn 955 connected between them. Of course, the behavior of an edge node is 956 not exactly the same as the behavior of an LSR on the network side. 957 Note also, that an edge node may run a routing protocol, however it 958 is expected that in most of the cases it will not (see also section 959 7.2 and the section about signaling with an explicit route). 961 Conceptually, a difference between UNI and NNI make sense either if 962 both interface uses completely different protocols, or if they use 963 the same protocols but with some outstanding differences. In the 964 first case, separate protocols are often defined successively, with 965 more or less success. 967 The GMPLS approach consisted in building a consistent model from day 968 one, considering both the UNI and NNI interfaces at the same time 969 [GMPLS-OVERLAY]. For that purpose, a very few specific UNI 970 particularities have been ignored in a first time. GMPLS has been 971 enhanced to support such particularities at the UNI by some other 972 standardization bodies (see hereafter). 974 7.1. Relationship with the OIF UNI 976 This section is only given for reference to the OIF work related to 977 GMPLS. The current OIF UNI specification [OIF-UNI] defines an 978 interface between a client SONET/SDH equipment and an SONET/SDH 979 network, each belonging to a distinct administrative authority. It 980 is designed for an overlay model. The OIF UNI defines additional 981 mechanisms on the top of GMPLS for the UNI. 983 For instance, the OIF service discovery procedure is a precursor to 984 obtaining UNI services. Service discovery allows a client to 985 determine the static parameters of the interconnection with the 986 network, including the UNI signaling protocol, the type of 987 concatenation, the transparency level as well as the type of 988 diversity (node, link, SRLG) supported by the network. 990 E. Mannie (Editor) et al. Standard Track 18 991 Since the current OIF UNI interface does not cover photonic 992 networks, G.709 Digital Wrapper, etc, it is from that perspective a 993 subset of the GMPLS Architecture at the UNI. 995 7.2. Reachability across the UNI 997 This section discusses the selection of an explicit route by an edge 998 node. The selection of the first LSR by an edge node connected to 999 multiple LSRs is part of that problem. 1001 An edge node (host or LSR) can participate more or less deeply in 1002 the GMPLS routing. Four different routing models can be supported at 1003 the UNI: configuration based, partial peering, silent listening and 1004 full peering. 1006 - Configuration based: this routing model requires the manual or 1007 automatic configuration of an edge node with a list of neighbor LSRs 1008 sorted by preference order. Automatic configuration can be achieved 1009 using DHCP for instance. No routing information is exchanged at the 1010 UNI, except maybe the ordered list of LSRs. The only routing 1011 information used by the edge node is that list. The edge node sends 1012 by default an LSP request to the preferred LSR. ICMP redirects could 1013 be send by this LSR to redirect some LSP requests to another LSR 1014 connected to the edge node. GMPLS does not preclude that model. 1016 - Partial peering: limited routing information (mainly reachability) 1017 can be exchanged across the UNI using some extensions in the 1018 signaling plane. The reachability information exchanged at the UNI 1019 may be used to initiate edge node specific routing decision over the 1020 network. GMPLS does not have any capability to support this model 1021 today. 1023 - Silent listening: the edge node can silently listen to routing 1024 protocols and take routing decisions based on the information 1025 obtained. An edge node receives the full routing information, 1026 including traffic engineering extensions. One LSR should forward 1027 transparently all routing PDUs to the edge node. An edge node can 1028 now compute a complete explicit route taking into consideration all 1029 the end-to-end routing information. GMPLS does not preclude this 1030 model. 1032 - Full peering: in addition to silent listening, the edge node 1033 participates within the routing, establish adjacencies with its 1034 neighbors and advertises LSAs. This is useful only if there are 1035 benefits for edge nodes to advertise themselves traffic engineering 1036 information. GMPLS does not preclude this model. 1038 8. Link Management 1040 In the context of GMPLS, a pair of nodes (e.g., a photonic switch) 1041 may be connected by tens of fibers, and each fiber may be used to 1042 transmit hundreds of wavelengths if DWDM is used. Multiple fibers 1043 and/or multiple wavelengths may also be combined into one or more 1044 bundled links for routing purposes. Furthermore, to enable 1046 E. Mannie (Editor) et al. Standard Track 19 1047 communication between nodes for routing, signaling, and link 1048 management, control channels must be established between a node 1049 pair. 1051 Link management is a collection of useful procedures between 1052 adjacent nodes that provide local services such as control channel 1053 management, link connectivity verification, link property 1054 correlation, and fault management. The Link Management Protocol 1055 (LMP) [LMP] has been defined to fulfill these operations. LMP has 1056 been initiated in the context of GMPLS but is a generic toolbox that 1057 can be also used in other contexts. 1059 In GMPLS, the control channels between two adjacent nodes are no 1060 longer required to use the same physical medium as the data links 1061 between those nodes. Moreover, the control channels that are used to 1062 exchange the GMPLS control-plane information exist independently of 1063 the links they manage. Hence, LMP was designed to manage the data 1064 links, independently of the termination capabilities of those data 1065 links. 1067 Control channel management and link property correlation procedures 1068 are mandatory per LMP. Link connectivity verification and fault 1069 management procedures are optional. 1071 8.1. Control Channel and Control Channel Management 1073 LMP control channel management is used to establish and maintain 1074 control channels between nodes. Control channels exist independently 1075 of TE links, and can be used to exchange MPLS control-plane 1076 information such as signaling, routing, and link management 1077 information. 1079 An "LMP adjacency" is formed between two nodes that support the same 1080 LMP capabilities. Multiple control channels may be active 1081 simultaneously for each adjacency. A control channel can be either 1082 explicitly configured or automatically selected, however, LMP 1083 currently assume that control channels are explicitly configured 1084 while the configuration of the control channel capabilities can be 1085 dynamically negotiated. 1087 For the purposes of LMP, the exact implementation of the control 1088 channel is left unspecified. The control channel(s) between two 1089 adjacent nodes is no longer required to use the same physical medium 1090 as the data-bearing links between those nodes. For example, a 1091 control channel could use a separate wavelength or fiber, an 1092 Ethernet link, or an IP tunnel through a separate management 1093 network. 1095 A consequence of allowing the control channel(s) between two nodes 1096 to be physically diverse from the associated data-bearing links is 1097 that the health of a control channel does not necessarily correlate 1098 to the health of the data-bearing links, and vice-versa. Therefore, 1099 new mechanisms have been developed in LMP to manage links, both in 1100 terms of link provisioning and fault isolation. 1102 E. Mannie (Editor) et al. Standard Track 20 1103 LMP does not specify the signaling transport mechanism used in the 1104 control channel, however it states that messages transported over a 1105 control channel must be IP encoded. Furthermore, since the messages 1106 are IP encoded, the link level encoding is not part of LMP. A 32-bit 1107 non-zero integer Control Channel Identifier (CCId) is assigned to 1108 each direction of a control channel. 1110 Each control channel individually negotiates its control channel 1111 parameters and maintains connectivity using a fast Hello protocol. 1112 The latter is required if lower-level mechanisms are not available 1113 to detect link failures. 1115 The Hello protocol of LMP is intended to be a lightweight keep-alive 1116 mechanism that will react to control channel failures rapidly so 1117 that IGP Hellos are not lost and the associated link-state 1118 adjacencies are not removed uselessly. 1120 The Hello protocol consists of two phases: a negotiation phase and a 1121 keep-alive phase. The negotiation phase allows negotiation of some 1122 basic Hello protocol parameters, like the Hello frequency. The keep- 1123 alive phase consists of a fast lightweight bi-directional Hello 1124 message exchange. 1126 If a group of control channels share a common node pair and support 1127 the same LMP capabilities, then LMP control channel messages (except 1128 Configuration messages, and Hello's) may be transmitted over any of 1129 the active control channels without coordination between the local 1130 and remote nodes. 1132 For LMP, it is essential that at least one control channel is always 1133 available. In case of control channel failure, it may be possible to 1134 use an alternate active control channel without coordination. 1136 8.2. Link Property Correlation 1138 As part of LMP, a link property correlation exchange is defined. 1139 The exchange is used to aggregate multiple data-bearing links (i.e. 1140 component links) into a bundled link and exchange, correlate, or 1141 change TE link parameters. The link property correlation exchange 1142 may be done at any time a link is up and not in the Verification 1143 process (see next section). 1145 It allows for instance to add component links to a link bundle, 1146 change link's minimum/maximum reservable bandwidth, change port 1147 identifiers, or change component identifiers in a bundle. This 1148 mechanism is supported by an exchange of link summary messages. 1150 8.3. Link Connectivity Verification 1152 Link connectivity verification is an optional procedure that may be 1153 used to verify the physical connectivity of data-bearing links as 1154 well as to exchange the link identifiers that are used in the GMPLS 1155 signaling. 1157 E. Mannie (Editor) et al. Standard Track 21 1158 This procedure should be performed initially when a data-bearing 1159 link is first established, and subsequently, on a periodic basis for 1160 all unallocated (free) data-bearing links. 1162 The verification procedure consists of sending Test messages in-band 1163 over the data-bearing links. This requires that the unallocated 1164 links must be opaque; however, multiple degrees of opaqueness (e.g., 1165 examining overhead bytes, terminating the payload, etc.), and hence 1166 different mechanisms to transport the Test messages, are specified. 1167 Note that the Test message is the only LMP message that is 1168 transmitted over the data-bearing link, and that Hello messages 1169 continue to be exchanged over the control channel during the link 1170 verification process. Data-bearing links are tested in the transmit 1171 direction as they are unidirectional. As such, it is possible for 1172 LMP neighboring nodes to exchange the Test messages simultaneously 1173 in both directions. 1175 To initiate the link verification procedure, a node must first 1176 notify the adjacent node that it will begin sending Test messages 1177 over a particular data-bearing link, or over the component links of 1178 a particular bundled link. The node must also indicate the number of 1179 data-bearing links that are to be verified; the interval at which 1180 the test messages will be sent; the encoding scheme, the transport 1181 mechanisms that are supported, the data rate for Test messages; and, 1182 in the case where the data-bearing links correspond to fibers, the 1183 wavelength over which the Test messages will be transmitted. 1184 Furthermore, the local and remote bundled link identifiers are 1185 transmitted at this time to perform the component link association 1186 with the bundled link identifiers. 1188 8.4. Fault Management 1190 Fault management is an important requirement from the operational 1191 point of view. Fault management includes usually: fault detection, 1192 fault localization and fault notification. When a failure occurs and 1193 is detected (fault detection), an operator needs to know exactly 1194 where it happened (fault localization) and a source node may need to 1195 be notified in order to take some actions (fault notification). 1197 Note that fault localization can also be used to support some 1198 specific (local) protection/restoration mechanisms. 1200 In new technologies such as transparent photonic switching currently 1201 no method is defined to locate a fault, and the mechanism by which 1202 the fault information is propagated must be sent "out of band" (via 1203 the control plane). 1205 LMP provides a fault localization procedure that can be used to 1206 rapidly localize link failures, by notifying a fault up to the node 1207 upstream of that fault (i.e. through a fault notification 1208 procedure). 1210 E. Mannie (Editor) et al. Standard Track 22 1211 A downstream LMP neighbor that detects data link failures will send 1212 an LMP message to its upstream neighbor notifying it of the failure. 1213 When an upstream node receives a failure notification, it can 1214 correlate the failure with the corresponding input ports to 1215 determine if the failure is between the two nodes. Once the failure 1216 has been localized, the signaling protocols can be used to initiate 1217 link or path protection/restoration procedures. 1219 8.5 LMP for DWDM Optical Line Systems (OLSs) 1221 In an all-optical environment, LMP focuses on peer communications 1222 (e.g. OXC-to-OXC). A great deal of information about a link between 1223 two OXCs is known by the OLS (Optical Line System or WDM Terminal 1224 multiplexer). Exposing this information to the control plane can 1225 improve network usability by further reducing required manual 1226 configuration, and by greatly enhancing fault detection and 1227 recovery. 1229 LMP-WDM [LMP-WDM] defines extensions to LMP for use between an OXC 1230 and an OLS. These extensions are intended to satisfy the Optical 1231 Link Interface Requirements described in [OLI-REQ]. 1233 Fault detection is particularly an issue when the network is using 1234 all-optical photonic switches (PXC). Once a connection is 1235 established, PXCs have only limited visibility into the health of 1236 the connection. Although the PXC is all-optical, long-haul OLSs 1237 typically terminate channels electrically and regenerate them 1238 optically. This provides an opportunity to monitor the health of a 1239 channel between PXCs. LMP-WDM can then be used by the OLS to provide 1240 this information to the PXC. 1242 In addition to the link information known to the OLS that is 1243 exchanged through LMP-WDM, some information known to the OXC may 1244 also be exchanged with the OLS through LMP-WDM. This information is 1245 useful for alarm management and link monitoring (e.g. trace 1246 monitoring). Alarm management is important because the 1247 administrative state of a connection, known to the OXC (e.g. this 1248 information may be learned through the Admin Status object of GMPLS 1249 signaling [RFC3471]), can be used to suppress spurious alarms. For 1250 example, the OXC may know that a connection is "up", "down", in a 1251 "testing" mode, or being deleted ("deletion-in-progress"). The OXC 1252 can use this information to inhibit alarm reporting from the OLS 1253 when a connection is "down", "testing", or being deleted. 1255 It is important to note that an OXC may peer with one or more OLSs 1256 and an OLS may peer with one or more OXCs. Although there are many 1257 similarities between an OXC-OXC LMP session and an OXC-OLS LMP 1258 session, particularly for control management and link verification, 1259 there are some differences as well. These differences can primarily 1260 be attributed to the nature of an OXC-OLS link, and the purpose of 1261 OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the 1262 basis for GMPLS signaling and routing at the optical layer. The 1263 information exchanged over LMP-WDM sessions is used to augment 1264 knowledge about the links between OXCs. 1266 E. Mannie (Editor) et al. Standard Track 23 1267 In order for the information exchanged over the OXC-OLS LMP sessions 1268 to be used by the OXC-OXC session, the information must be 1269 coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP 1270 sessions are run independently and must be maintained separately. 1271 One critical requirement when running an OXC-OLS LMP session is the 1272 ability of the OLS to make a data link transparent when not doing 1273 the verification procedure. This is because the same data link may 1274 be verified between OXC-OLS and between OXC-OXC. The verification 1275 procedure of LMP is used to coordinate the Test procedure (and hence 1276 the transparency/opaqueness of the data links). To maintain 1277 independence between the sessions, it must be possible for the LMP 1278 sessions to come up in any order. In particular, it must be possible 1279 for an OXC-OXC LMP session to come up without an OXC-OLS LMP session 1280 being brought up, and vice-versa. 1282 9. Generalized Signaling 1284 The GMPLS signaling extends certain base functions of the RSVP-TE 1285 and CR-LDP signaling and, in some cases, adds functionality. These 1286 changes and additions impact basic LSP properties: how labels are 1287 requested and communicated, the unidirectional nature of LSPs, how 1288 errors are propagated, and information provided for synchronizing 1289 the ingress and egress. 1291 The core GMPLS signaling specification is available in three parts: 1293 1. A signaling functional description [RFC3471]. 1294 2. RSVP-TE extensions [RFC3473]. 1295 3. CR-LDP extensions [RFC3472]. 1297 In addition, independent parts are available per technology: 1299 1. GMPLS extensions for SONET and SDH control [GMPLS-SONET-SDH]. 1300 2. GMPLS extensions for G.709 control [GMPLS-G709]. 1302 The following MPLS profile expressed in terms of MPLS features 1303 [RFC3031] applies to GMPLS: 1305 - Downstream-on-demand label allocation and distribution. 1306 - Ingress initiated ordered control. 1307 - Liberal (typical), or conservative (could) label retention 1308 mode. 1309 - Request, traffic/data, or topology driven label allocation 1310 strategy. 1311 - Explicit routing (typical), or hop-by-hop routing. 1313 The GMPLS signaling defines the following new building blocks on the 1314 top of MPLS-TE: 1316 1. A new generic label request format. 1317 2. Labels for TDM, LSC and FSC interfaces, generically known as 1318 Generalized Label. 1319 3. Waveband switching support. 1321 E. Mannie (Editor) et al. Standard Track 24 1322 4. Label suggestion by the upstream for optimization purposes 1323 (e.g. latency). 1324 5. Label restriction by the upstream to support some optical 1325 constraints. 1326 6. Bi-directional LSP establishment with contention resolution. 1327 7. Rapid failure notification extensions. 1328 8. Protection information currently focusing on link protection, 1329 plus primary and secondary LSP indication. 1330 9. Explicit routing with explicit label control for a fine 1331 degree of control. 1332 10. Specific traffic parameters per technology. 1333 11. LSP administrative status handling. 1334 12. Control channel separation. 1336 These building blocks will be described in more details in the 1337 following. A complete specification can be found in the 1338 corresponding documents. 1340 Note that GMPLS is highly generic and has many options. Only 1341 building blocks 1, 2 and 10 are mandatory, and only within the 1342 specific format that is needed. Typically, building blocks 6 and 9 1343 should be implemented. Building blocks 3, 4, 5, 7, 8, 11 and 12 are 1344 optional. 1346 A typical SONET/SDH switching network would implement building 1347 blocks: 1, 2 (the SONET/SDH label), 6, 9, 10 and 11. Building blocks 1348 7 and 8 are optional since protection can be achieved using SONET/ 1349 SDH overhead bytes. 1351 A typical wavelength switching network would implement building 1352 blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11. Building 1353 block 3 is only needed in the particular case of waveband switching. 1355 A typical fiber switching network would implement building blocks: 1356 1, 2 (the generic format), 6, 7, 8, 9 and 11. 1358 A typical MPLS-IP network would not implement any of these building 1359 blocks, since the absence of building block 1 would indicate regular 1360 MPLS-IP. Note however that building block 1 and 8 can be used to 1361 signal MPLS-IP as well. In that case, the MPLS-IP network can 1362 benefit from the link protection type (not available in CR-LDP, some 1363 very basic form being available in RSVP-TE). Building block 2 is 1364 here a regular MPLS label and no new label format is required. 1366 GMPLS does not specify any profile for RSVP-TE and CR-LDP 1367 implementations that have to support GMPLS - except for what is 1368 directly related to GMPLS procedures. It is to the manufacturer to 1369 decide which are the optional elements and procedures of RSVP-TE and 1370 CR-LDP that need to be implemented. Some optional MPLS-TE elements 1371 can be useful for TDM, LSC and FSC layers, for instance the setup 1372 and holding priorities that are inherited from MPLS-TE. 1374 9.1. Overview: How to Request an LSP 1376 E. Mannie (Editor) et al. Standard Track 25 1377 A TDM, LSC or FSC LSP is established by sending a PATH/Label Request 1378 message downstream to the destination. This message contains a 1379 Generalized Label Request with the type of LSP (i.e. the layer 1380 concerned), and its payload type. An Explicit Route Object (ERO) is 1381 also normally added to the message, but this can be added and/or 1382 completed by the first/default LSR. 1384 The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC 1385 object, or in the CR-LDP Traffic Parameters TLV. Specific parameters 1386 for a given technology are given in these traffic parameters, such 1387 as the type of signal, concatenation and/or transparency for a 1388 SONET/SDH LSP. For some other technology there be could just one 1389 bandwidth parameter indicating the bandwidth as a floating-point 1390 value. 1392 The requested local protection per link may be requested using the 1393 Protection Information Object/TLV. The end-to-end LSP protection is 1394 for further study and is introduced LSP protection/restoration 1395 section (see after). 1397 If the LSP is a bi-directional LSP, an Upstream Label is also 1398 specified in the Path/Label Request message. This label will be the 1399 one to use in the upstream direction. 1401 Additionally, a Suggested Label, a Label Set and a Waveband Label 1402 can also be included in the message. Other operations are defined in 1403 MPLS-TE. 1405 The downstream node will send back a Resv/Label Mapping message 1406 including one Generalized Label object/TLV that can contain several 1407 Generalized Labels. For instance, if a concatenated SONET/SDH signal 1408 is requested, several labels can be returned. 1410 In case of SONET/SDH virtual concatenation, a list of labels is 1411 returned. Each label identifying one element of the virtual 1412 concatenated signal. This limits virtual concatenation to remain 1413 within a single (component) link. 1415 In case of any type of SONET/SDH contiguous concatenation, only one 1416 label is returned. That label is the lowest signal of the contiguous 1417 concatenated signal (given an order specified in [GMPLS-SONET-SDH]). 1419 In case of SONET/SDH "multiplication", i.e. co-routing of circuits 1420 of the same type but without concatenation but all belonging to the 1421 same LSP, the explicit ordered list of all signals that take part in 1422 the LSP is returned. 1424 9.2. Generalized Label Request 1426 The Generalized Label Request is a new object/TLV to be added in an 1427 RSVP-TE Path message instead of the regular Label Request, or in a 1428 CR-LDP Request message in addition to the already existing TLVs. 1429 Only one label request can be used per message, so a single LSP can 1430 be requested at a time per signaling message. 1432 E. Mannie (Editor) et al. Standard Track 26 1433 The Generalized Label Request gives three major characteristics 1434 (parameters) required to support the LSP being requested: the LSP 1435 Encoding Type, the Switching Type that must be used and the LSP 1436 payload type called Generalized PID (G-PID). 1438 The LSP Encoding Type indicates the encoding type that will be used 1439 with the data associated with the LSP, i.e. the type of technology 1440 being considered. For instance, it can be SDH, SONET, Ethernet, ANSI 1441 PDH, etc. It represents the nature of the LSP, and not the nature of 1442 the links that the LSP traverses. This is used hop-by-hop by each 1443 node. 1445 A link may support a set of encoding formats, where support means 1446 that a link is able to carry and switch a signal of one or more of 1447 these encoding formats. The Switching Type indicates then the type 1448 of switching that should be performed on a particular link for that 1449 LSP. This information is needed for links that advertise more than 1450 one type of switching capability. 1452 Nodes must verify that the type indicated in the Switching Type is 1453 supported on the corresponding incoming interface; otherwise, the 1454 node must generate a notification message with a "Routing 1455 problem/Switching Type" indication. 1457 The LSP payload type (G-PID) identifies the payload carried by the 1458 LSP, i.e. an identifier of the client layer of that LSP. For some 1459 technologies, it also indicates the mapping used by the client 1460 layer, e.g. byte synchronous mapping of E1. This must be interpreted 1461 according to the LSP encoding type and is used by the nodes at the 1462 endpoints of the LSP to know to which client layer a request is 1463 destined, and in some cases by the penultimate hop. 1465 Other technology specific parameters are not transported in the 1466 Generalized Label Request but in technology specific traffic 1467 parameters as explained hereafter. Currently, two set of traffic 1468 parameters are defined, one for SONET/SDH and one for G.709. 1470 Note that it is expected than specific traffic parameters will be 1471 defined in the future for photonic (all optical) switching. 1473 9.3. SONET/SDH Traffic Parameters 1475 The GMPLS SONET/SDH traffic parameters [GMPLS-SONET-SDH] specify a 1476 powerful set of capabilities for SONET [ANSI T1.105] and SDH [ITU-T 1477 G.707]. 1479 The first traffic parameter specifies the type of the elementary 1480 SONET/SDH signal that comprises the requested LSP, e.g. VC-11, VT6, 1481 VC-4, STS-3c, etc. Several transforms can then be applied 1482 successively on the elementary Signal to build the final signal 1483 being actually requested for the LSP. 1485 E. Mannie (Editor) et al. Standard Track 27 1486 These transforms are the contiguous concatenation, the virtual 1487 concatenation, the transparency and the multiplication. Each one is 1488 optional. They must be applied strictly in the following order: 1490 - First, contiguous concatenation can be optionally applied on the 1491 Elementary Signal, resulting in a contiguously concatenated 1492 signal. 1493 - Second, virtual concatenation can be optionally applied either 1494 directly on the elementary Signal, or on the contiguously 1495 concatenated signal obtained from the previous phase. 1496 - Third, some transparency can be optionally specified when 1497 requesting a frame as signal rather than a container. Several 1498 transparency packages are defined. 1499 - Fourth, a multiplication can be optionally applied either directly 1500 on the elementary Signal, or on the contiguously concatenated 1501 signal obtained from the first phase, or on the virtually 1502 concatenated signal obtained from the second phase, or on these 1503 signals combined with some transparency. 1505 For RSVP-TE, the SONET/SDH traffic parameters are carried in a new 1506 SENDER_TSPEC and FLOWSPEC. The same format is used for both. There 1507 is no Adspec associated with the SENDER_TSPEC, it is omitted or a 1508 default value is used. The content of the FLOWSPEC object received 1509 in a Resv message should be identical to the content of the 1510 SENDER_TSPEC of the corresponding Path message. In other words, the 1511 receiver is normally not allowed to change the values of the traffic 1512 parameters. However, some level of negotiation may be achieved as 1513 explained in [GMPLS-SONET-SDH]. 1515 For CR-LDP, the SONET/SDH traffic parameters are simply carried in a 1516 new TLV. 1518 Note that a general discussion on SONET/SDH and GMPLS can be found 1519 in [SONET-SDH-GMPLS-FRM]. 1521 9.4. G.709 Traffic Parameters 1523 Simply said, an [ITU-T G.709] based network is decomposed in two 1524 major layers: an optical layer (i.e. made of wavelengths) and a 1525 digital layer. These two layers are divided into sub-layers and 1526 switching occurs at two specific sub-layers: at the OCh (Optical 1527 Channel) optical layer and at the ODU (Optical channel Data Unit) 1528 electrical layer. The ODUk notation is used to denote ODUs at 1529 different bandwidths. 1531 The GMPLS G.709 traffic parameters [GMPLS-G709] specify a powerful 1532 set of capabilities for ITU-T G.709 networks. 1534 The first traffic parameter specifies the type of the elementary 1535 G.709 signal that comprises the requested LSP, e.g. ODU1, OCh at 40 1536 Gbps, etc. Several transforms can then be applied successively on 1537 the elementary Signal to build the final signal being actually 1538 requested for the LSP. 1540 E. Mannie (Editor) et al. Standard Track 28 1541 These transforms are the virtual concatenation and the 1542 multiplication. Each one of these transforms is optional. They must 1543 be applied strictly in the following order: 1545 - First, virtual concatenation can be optionally applied directly on 1546 the elementary Signal, 1547 - Second, a multiplication can be optionally applied, either 1548 directly on the elementary Signal, or on the virtually 1549 concatenated signal obtained from the first phase. 1551 Additional ODUk Multiplexing traffic parameters allow indicating an 1552 ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request. 1553 G.709 supports the following multiplexing capabilities: ODUj into 1554 ODUk (k > j) and ODU1 with ODU2 multiplexing into ODU3. 1556 For RSVP-TE, the G.709 traffic parameters are carried in a new 1557 SENDER-TSPEC and FLOWSPEC. The same format is used for both. There 1558 is no Adspec associated with the SENDER_TSPEC, it is omitted or a 1559 default value is used. The content of the FLOWSPEC object received 1560 in a Resv message should be identical to the content of the 1561 SENDER_TSPEC of the corresponding Path message. 1563 For CR-LDP, the G.709 traffic parameters are simply carried in a new 1564 TLV. 1566 9.5. Bandwidth Encoding 1568 Some technologies that do not have (yet) specific traffic parameters 1569 just require a bandwidth encoding transported in a generic form. 1570 Bandwidth is carried in 32-bit number in IEEE floating-point format 1571 (the unit is bytes per second). Values are carried in a per protocol 1572 specific manner. For non-packet LSPs, it is useful to define 1573 discrete values to identify the bandwidth of the LSP. 1575 It should be noted that this bandwidth encoding do not apply to 1576 SONET/SDH and G.709, for which the traffic parameters fully define 1577 the requested SONET/SDH or G.709 signal. 1579 The bandwidth is coded in the Peak Data Rate field of Int-Serv 1580 objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects and in 1581 the Peak and Committed Data Rate fields of the CR-LDP Traffic 1582 Parameters TLV. 1584 9.6. Generalized Label 1586 The Generalized Label extends the traditional MPLS label by allowing 1587 the representation of not only labels that travel in-band with 1588 associated data packets, but also (virtual) labels that identify 1589 time-slots, wavelengths, or space division multiplexed positions. 1591 For example, the Generalized Label may identify (a) a single fiber 1592 in a bundle, (b) a single waveband within fiber, (c) a single 1593 wavelength within a waveband (or fiber), or (d) a set of time-slots 1594 within a wavelength (or fiber). It may also be a generic MPLS label, 1596 E. Mannie (Editor) et al. Standard Track 29 1597 a Frame Relay label, or an ATM label (VCI/VPI). The format of a 1598 label can be as simple as an integer value such as a wavelength 1599 label or can be more elaborated such as an SONET/SDH or a G.709 1600 label. 1602 SDH and SONET define each a multiplexing structure. These 1603 multiplexing structures will be used as naming trees to create 1604 unique labels. Such a label will identify the exact position (times- 1605 lot(s)) of a signal in a multiplexing structure. Since the SONET 1606 multiplexing structure may be seen as a subset of the SDH 1607 multiplexing structure, the same format of label is used for SDH and 1608 SONET. A similar concept is applied to build a label at the G.709 1609 ODU layer. 1611 Since the nodes sending and receiving the Generalized Label know 1612 what kinds of link they are using, the Generalized Label does not 1613 identify its type. Instead, the nodes are expected to know from the 1614 context what type of label to expect. 1616 A Generalized Label only carries a single level of label i.e. it is 1617 non-hierarchical. When multiple levels of labels (LSPs within LSPs) 1618 are required, each LSP must be established separately. 1620 9.7. Waveband Switching 1622 A special case of wavelength switching is waveband switching. A 1623 waveband represents a set of contiguous wavelengths, which can be 1624 switched together to a new waveband. For optimization reasons, it 1625 may be desirable for a photonic cross-connect to optically switch 1626 multiple wavelengths as a unit. This may reduce the distortion on 1627 the individual wavelengths and may allow tighter separation of the 1628 individual wavelengths. A Waveband label is defined to support this 1629 special case. 1631 Waveband switching naturally introduces another level of label 1632 hierarchy and as such the waveband is treated the same way, all 1633 other upper layer labels are treated. As far as the MPLS protocols 1634 are concerned, there is little difference between a waveband label 1635 and a wavelength label. Exception is that semantically the waveband 1636 can be subdivided into wavelengths whereas the wavelength can only 1637 be subdivided into time or statistically multiplexed labels. 1639 In the context of waveband switching, the generalized label used to 1640 indicate a waveband contains three fields, a waveband ID, a Start 1641 Label and an End Label. The Start and End Labels are channel 1642 identifiers from the sender perspective that identify respectively, 1643 the lowest value wavelength and the highest value wavelength making 1644 up the waveband. 1646 9.8. Label Suggestion by the Upstream 1648 GMPLS allows for a label to be optionally suggested by an upstream 1649 node. This suggestion may be overridden by a downstream node but in 1650 some cases, at the cost of higher LSP setup time. The suggested 1652 E. Mannie (Editor) et al. Standard Track 30 1653 label is valuable when establishing LSPs through certain kinds of 1654 optical equipment where there may be a lengthy (in electrical terms) 1655 delay in configuring the switching fabric. For example, micro 1656 mirrors may have to be elevated or moved, and this physical motion 1657 and subsequent damping takes time. If the labels and hence switching 1658 fabric are configured in the reverse direction (the norm), the Resv/ 1659 MAPPING message may need to be delayed by 10's of milliseconds per 1660 hop in order to establish a usable forwarding path. It can be 1661 important for restoration purposes where alternate LSPs may need to 1662 be rapidly established as a result of network failures. 1664 9.9. Label Restriction by the Upstream 1666 An upstream node can optionally restrict (limit) the choice of label 1667 of a downstream node to a set of acceptable labels. Giving lists 1668 and/or ranges of inclusive (acceptable) or exclusive (unacceptable) 1669 labels in a Label Set provides this restriction. If not applied, all 1670 labels from the valid label range may be used. There are at least 1671 four cases where a label restriction is useful in the "optical" 1672 domain. 1674 Case 1: the end equipment is only capable of transmitting and 1675 receiving on a small specific set of wavelengths/wavebands. 1677 Case 2: there is a sequence of interfaces, which cannot support 1678 wavelength conversion and require the same wavelength be used end- 1679 to-end over a sequence of hops, or even an entire path. 1681 Case 3: it is desirable to limit the amount of wavelength conversion 1682 being performed to reduce the distortion on the optical signals. 1684 Case 4: two ends of a link support different sets of wavelengths. 1686 The receiver of a Label Set must restrict its choice of labels to 1687 one that is in the Label Set. A Label Set may be present across 1688 multiple hops. In this case, each node generates its own outgoing 1689 Label Set, possibly based on the incoming Label Set and the node's 1690 hardware capabilities. This case is expected to be the norm for 1691 nodes with conversion incapable interfaces. 1693 9.10. Bi-directional LSP 1695 GMPLS allows establishment of bi-directional symmetric LSPs (not of 1696 asymmetric LSPs). A symmetric bi-directional LSP has the same 1697 traffic engineering requirements including fate sharing, protection 1698 and restoration, LSRs, and resource requirements (e.g. latency and 1699 jitter) in each direction. 1701 In the remainder of this section, the term "initiator" is used to 1702 refer to a node that starts the establishment of an LSP; the term 1703 "terminator" is used to refer to the node that is the target of the 1704 LSP. For a bi-directional LSPs, there is only one initiator and one 1705 terminator. 1707 E. Mannie (Editor) et al. Standard Track 31 1708 Normally to establish a bi-directional LSP when using RSVP-TE 1709 [RFC3209] or CR-LDP [RFC3212] two unidirectional paths must be 1710 independently established. This approach has the following 1711 disadvantages: 1713 1. The latency to establish the bi-directional LSP is equal to one 1714 round trip signaling time plus one initiator-terminator signaling 1715 transit delay. This not only extends the setup latency for 1716 successful LSP establishment, but it extends the worst-case latency 1717 for discovering an unsuccessful LSP to as much as two times the 1718 initiator-terminator transit delay. These delays are particularly 1719 significant for LSPs that are established for restoration purposes. 1721 2. The control overhead is twice that of a unidirectional LSP. This 1722 is because separate control messages (e.g. Path and Resv) must be 1723 generated for both segments of the bi-directional LSP. 1725 3. Because the resources are established in separate segments, route 1726 selection is complicated. There is also additional potential race 1727 for conditions in assignment of resources, which decreases the 1728 overall probability of successfully establishing the bi-directional 1729 connection. 1731 4. It is more difficult to provide a clean interface for SONET/SDH 1732 equipment that may rely on bi-directional hop-by-hop paths for 1733 protection switching. Note that existing SONET/SDH equipment 1734 transmits the control information in-band with the data. 1736 5. Bi-directional optical LSPs (or lightpaths) are seen as a 1737 requirement for many optical networking service providers. 1739 With bi-directional LSPs both the downstream and upstream data 1740 paths, i.e. from initiator to terminator and terminator to 1741 initiator, are established using a single set of signaling messages. 1742 This reduces the setup latency to essentially one initiator- 1743 terminator round trip time plus processing time, and limits the 1744 control overhead to the same number of messages as a unidirectional 1745 LSP. 1747 For bi-directional LSPs, two labels must be allocated. Bi- 1748 directional LSP setup is indicated by the presence of an Upstream 1749 Label in the appropriate signaling message. 1751 9.11. Bi-directional LSP Contention Resolution 1753 Contention for labels may occur between two bi-directional LSP setup 1754 requests traveling in opposite directions. This contention occurs 1755 when both sides allocate the same resources (ports) at effectively 1756 the same time. GMPLS signaling defines a procedure to resolve that 1757 contention: the node with the higher node ID will win the 1758 contention. To reduce the probability of contention, some mechanisms 1759 are also suggested. 1761 E. Mannie (Editor) et al. Standard Track 32 1762 9.12. Rapid Notification of Failure 1764 GMPLS defines several signaling extensions that enable expedited 1765 notification of failures and other events to nodes responsible for 1766 restoring failed LSPs, and error handling. 1768 1. Acceptable Label Set for notification on Label Error: 1770 There are cases in traditional MPLS and in GMPLS that result in an 1771 error message containing an "Unacceptable label value" indication. 1772 When these cases occur, it can useful for the node generating the 1773 error message to indicate which labels would be acceptable. To cover 1774 this case, GMPLS introduces the ability to convey such information 1775 via the "Acceptable Label Set". An Acceptable Label Set is carried 1776 in appropriate protocol specific error messages. The format of an 1777 Acceptable Label Set is identical to a Label Set. 1779 2. Expedited notification: 1781 Extensions to RSVP-TE enable expedited notification of failures and 1782 other events to determined nodes. For CR-LDP, there is not currently 1783 a similar mechanism. The first extension identifies where event 1784 notifications are to be sent. The second provides for general 1785 expedited event notification with a Notify message. Such extensions 1786 can be used by fast restoration mechanisms. Notifications may be 1787 requested in both the upstream and downstream directions. 1789 The Notify message is a generalized notification mechanism that 1790 differs from the currently defined error messages in that it can be 1791 "targeted" to a node other than the immediate upstream or downstream 1792 neighbor. The Notify message does not replace existing error 1793 messages. The Notify message may be sent either (a) normally, where 1794 non-target nodes just forward the Notify message to the target node, 1795 similar to ResvConf processing in [RFC2205]; or (b) encapsulated in 1796 a new IP header whose destination is equal to the target IP address. 1798 3. Faster removal of intermediate states: 1800 A specific RSVP optimization allowing in some cases the faster 1801 removal of intermediate states. This extension is used to deal with 1802 specific RSVP mechanisms. 1804 9.13. Link Protection 1806 Protection information is carried in the new optional Protection 1807 Information Object/TLV. It currently indicates the desired link 1808 protection for each link of an LSP. If a particular protection type, 1809 i.e. 1+1, or 1:N, is requested, then a connection request is 1810 processed only if the desired protection type can be honored. Note 1811 that GMPLS advertises the protection capabilities of a link in the 1812 routing protocols. Path computation algorithms may consider this 1813 information when computing paths for setting up LSPs. 1815 E. Mannie (Editor) et al. Standard Track 33 1816 Protection information also indicates if the LSP is a primary or 1817 secondary LSP. A secondary LSP is a backup to a primary LSP. The 1818 resources of a secondary LSP are normally not used until the primary 1819 LSP fails, but they may be used by other LSPs until the primary LSP 1820 fails over the secondary LSP. At that point, any LSP that is using 1821 the resources for the secondary LSP must be preempted. 1823 Six link protection types are currently defined as individual flags 1824 and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared, 1825 unprotected, extra traffic. See [RFC3471] section 7.1 for a precise 1826 definition of each. 1828 9.14. Explicit Routing and Explicit Label Control 1830 By using an explicit route, the path taken by an LSP can be 1831 controlled more or less precisely. Typically, the node at the head- 1832 end of an LSP finds an explicit route and builds an Explicit Route 1833 Object (ERO)/ Explicit Route (ER) TLV that contains that route. 1834 Possibly, the edge node does not build any explicit route, and just 1835 transmit a signaling request to a default neighbor LSR (as IP/MPLS 1836 hosts would). For instance, an explicit route could be added to a 1837 signaling message by the first switching node, on behalf of the edge 1838 node. Note also that an explicit route is altered by intermediate 1839 LSRs during its progression towards the destination. 1841 The explicit route is originally defined by MPLS-TE as a list of 1842 abstract nodes (i.e. groups of nodes) along the explicit route. Each 1843 abstract node can be an IPv4 address prefix, an IPv6 address prefix, 1844 or an AS number. This capability allows the generator of the 1845 explicit route to have incomplete information about the details of 1846 the path. In the simplest case, an abstract node can be a full IP 1847 address (32 bits) that identifies a specific node (called a simple 1848 abstract node). 1850 MPLS-TE allows strict and loose abstract nodes. The path between a 1851 strict node and its preceding node must include only network nodes 1852 from the strict node and its preceding abstract node. The path 1853 between a loose node and its preceding abstract node may include 1854 other network nodes that are not part of the loose node or its 1855 preceding abstract node. 1857 This explicit route was extended to include interface numbers as 1858 abstract nodes to support unnumbered interfaces; and further 1859 extended by GMPLS to include labels as abstract nodes. Having labels 1860 in an explicit route is an important feature that allows controlling 1861 the placement of an LSP with a very fine granularity. This is more 1862 likely to be used for TDM, LSC and FSC links. 1864 In particular, the explicit label control in the explicit route 1865 allows terminating an LSP on a particular outgoing port of an egress 1866 node. Indeed, a label sub-object/TLV must follow a sub-object/TLV 1867 containing the IP address, or the interface identifier (in case of 1868 unnumbered interface), associated with the link on which it is to be 1869 used. 1871 E. Mannie (Editor) et al. Standard Track 34 1872 This can also be used when it is desirable to "splice" two LSPs 1873 together, i.e. where the tail of the first LSP would be "spliced" 1874 into the head of the second LSP. 1876 When used together with an optimization algorithm, it can provide 1877 very detailed explicit routes, including the label (timeslot) to use 1878 on a link, in order to minimize the fragmentation of the SONET/SDH 1879 multiplex on the corresponding interface. 1881 9.15. Route Recording 1883 In order to improve the reliability and the manageability of the LSP 1884 being established, the concept of the route recording was introduced 1885 in RSVP-TE to function as: 1887 - First, a loop detection mechanism to discover L3 routing loops, or 1888 loops inherent in the explicit route (this mechanism is strictly 1889 exclusive with the use of explicit routing objects). 1891 - Second, a route recording mechanism collects up-to-date detailed 1892 path information on a hop-by-hop basis during the LSP setup process. 1893 This mechanism provides valuable information to the source and 1894 destination nodes. Any intermediate routing change at setup time, in 1895 case of loose explicit routing, will be reported. 1897 - Third, a recorded route can be used as input for an explicit 1898 route. This is useful if a source node receives the recorded route 1899 from a destination node and applies it as an explicit route in order 1900 to "pin down the path". 1902 Within the GMPLS architecture, only the second and third functions 1903 are mainly applicable for TDM, LSC and FSC layers. 1905 9.16. LSP Modification and LSP Re-routing 1907 LSP modification and re-routing are two features already available 1908 in MPLS-TE. GMPLS does not add anything new. Elegant re-routing is 1909 possible with the concept of "make-before-break" whereby an old path 1910 is still used while a new path is set up by avoiding double 1911 reservation of resources. Then, the node performing the re-routing 1912 can swap on the new path and close the old path. This feature is 1913 supported with RSVP-TE (using shared explicit filters) and CR-LDP 1914 (using the action indicator flag). 1916 LSP modification consists in changing some LSP parameters, but 1917 normally without changing the route. It is supported using the same 1918 mechanism as re-routing. However, the semantic of LSP modification 1919 will differ from one technology to the other. For instance, further 1920 studies are required to understand the impact of dynamically 1921 changing some SONET/SDH circuit characteristics such as the 1922 bandwidth, the protection type, the transparency, the concatenation, 1923 etc. 1925 E. Mannie (Editor) et al. Standard Track 35 1926 9.17. LSP Administrative Status Handling 1928 GMPLS provides the optional capability to indicate the 1929 administrative status of an LSP by using a new Admin Status 1930 object/TLV. Administrative Status information is currently used in 1931 two ways. 1933 In the first usage, the Admin Status object/TLV is carried in a 1934 Path/Label Request or Resv/Label Mapping message to indicate the 1935 administrative state of an LSP. In this usage, Administrative Status 1936 information indicates the state of the LSP, which include "up" or 1937 "down", if it in a "testing" mode, and if deletion is in progress. 1939 Based on that administrative status, a node can take local 1940 decisions, like inhibit alarm reporting when an LSP is in "down" or 1941 "testing" states, or report alarms associated with the connection at 1942 a priority equal to or less than "Non service affecting". 1944 It is possible that some nodes along an LSP will not support the 1945 Admin Status Object/TLV. In the case of a non-supporting transit 1946 node, the object will pass through the node unmodified and normal 1947 processing can continue. 1949 In some circumstances, particularly optical networks, it is useful 1950 to set the administrative status of an LSP to "being deleted" before 1951 tearing it down in order to avoid non-useful generation of alarms. 1952 The ingress LSR precedes an LSP deletion by inserting an appropriate 1953 Admin Status Object/TLV in a Path/Label Request (with the 1954 modification action indicator flag set to modify) message. Transit 1955 LSRs process the Admin Status Object/TLV and forward it. The egress 1956 LSR answers in a Resv/Label Mapping (with the modification action 1957 indicator flag set to modify) message with the Admin Status object. 1958 Upon receiving this message and object, the ingress node sends a 1959 PathTear/Release message downstream to remove the LSP and normal 1960 RSVP-TE/CR-LDP processing takes place. 1962 In the second usage, the Admin Status object/TLV is carried in a 1963 Notification/Label Mapping (with the modification action indicator 1964 flag set to modify) message to request that the ingress node change 1965 the administrative state of an LSP. This allows intermediate and 1966 egress nodes triggering the setting of administrative status. In 1967 particular, this allows intermediate or egress LSRs requesting a 1968 release of an LSP initiated by the ingress node. 1970 9.18. Control Channel Separation 1972 In GMPLS, a control channel can be separated from the data channel. 1973 Indeed, the control channel can be implemented completely out-of- 1974 band for various reason, e.g. when the data channel cannot carry in- 1975 band control information. This issue was even originally introduced 1976 to MPLS in the context of link bundling. 1978 In traditional MPLS, there is an implicit one-to-one association of 1979 a control channel to a data channel. When such an association is 1981 E. Mannie (Editor) et al. Standard Track 36 1982 present, no additional or special information is required to 1983 associate a particular LSP setup transaction with a particular data 1984 channel. 1986 Otherwise, it is necessary to convey additional information in 1987 signaling to identify the particular data channel being controlled. 1988 GMPLS supports explicit data channel identification by providing 1989 interface identification information. GMPLS allows the use of a 1990 number of interface identification schemes including IPv4 or IPv6 1991 addresses, interface indexes (for unnumbered interfaces) and 1992 component interfaces (for bundled interfaces), unnumbered bundled 1993 interfaces are also supported. 1995 The choice of the data interface to use is always made by the sender 1996 of the Path/Label Request message, and indicated by including the 1997 data channel's interface identifier in the message using a new IF_ID 1998 RSVP_HOP object sub-type/Interface TLV. 2000 For bi-directional LSPs, the sender chooses the data interface in 2001 each direction. In all cases but bundling, the upstream interface is 2002 implied by the downstream interface. For bundling, the Path/Label 2003 Request sender explicitly identifies the component interface used in 2004 each direction. The new object/TLV is used in Resv/Label Mapping 2005 message to indicate the downstream node's usage of the indicated 2006 interface(s). 2008 The new object/TLV can contain a list of embedded TLVs, each 2009 embedded TLV can be an IPv4 address, and IPv6 address, an interface 2010 index, a downstream component interface ID or an upstream component 2011 interface ID. In the last three cases, the embedded TLV contains 2012 itself an IP address plus an Interface ID, the IP address being used 2013 to identify the interface ID (it can be the router ID for instance). 2015 There are cases where it is useful to indicate a specific interface 2016 associated with an error. To support these cases the IF_ID 2017 ERROR_SPEC RSVP Objects are defined. 2019 10. Forwarding Adjacencies (FA) 2021 To improve scalability of MPLS TE (and thus GMPLS) it may be useful 2022 to aggregate multiple TE LSPs inside a bigger TE LSP. Intermediate 2023 nodes see the external LSP only. They don't have to maintain 2024 forwarding states for each internal LSP, less signaling messages 2025 need to be exchanged and the external LSP can be somehow protected 2026 instead (or in addition) to the internal LSPs. This can considerably 2027 increase the scalability of the signaling. 2029 The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) 2030 the LSR forming a forwarding adjacency out of that LSP (advertising 2031 this LSP as a Traffic Engineering (TE) link into IS-IS/OSPF), (c) 2032 allowing other LSRs to use forwarding adjacencies for their path 2033 computation, and (d) nesting of LSPs originated by other LSRs into 2034 that LSP (e.g. by using the label stack construct in the case of 2035 IP). 2037 E. Mannie (Editor) et al. Standard Track 37 2038 IS-IS/OSPF floods the information about "Forwarding Adjacencies" FAs 2039 just as it floods the information about any other links. 2040 Consequently to this flooding, an LSR has in its TE link state 2041 database the information about not just conventional links, but FAs 2042 as well. 2044 An LSR, when performing path computation, uses not just conventional 2045 links, but FAs as well. Once a path is computed, the LSR uses RSVP- 2046 TE/CR-LDP for establishing label binding along the path. FAs need 2047 simple extensions to signaling and routing protocols. 2049 10.1. Routing and Forwarding Adjacencies 2051 Forwarding adjacencies may be represented as either unnumbered or 2052 numbered links. A FA can also be a bundle of LSPs between two nodes. 2054 FAs are advertised as GMPLS TE links such as defined in [HIERARCHY]. 2055 GMPLS TE links are advertised in OSPF and IS-IS such as defined in 2056 [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications 2057 enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link. 2059 When a FA is created dynamically, its TE attributes are inherited 2060 from the FA-LSP that induced its creation. [HIERARCHY] specifies how 2061 each TE parameter of the FA is inherited from the FA-LSP. Note that 2062 the bandwidth of the FA must be at least as big as the FA-LSP that 2063 induced it, but may be bigger if only discrete bandwidths are 2064 available for the FA-LSP. In general, for dynamically provisioned 2065 forwarding adjacencies, a policy-based mechanism may be needed to 2066 associate attributes to forwarding adjacencies. 2068 A FA advertisement could contain the information about the path 2069 taken by the FA-LSP associated with that FA. Other LSRs may use this 2070 information for path computation. This information is carried in a 2071 new OSPF and IS-IS TLV called the Path TLV. 2073 It is possible that the underlying path information might change 2074 over time, via configuration updates, or dynamic route 2075 modifications, resulting in the change of that TLV. 2077 If forwarding adjacencies are bundled (via link bundling), and if 2078 the resulting bundled link carries a Path TLV, the underlying path 2079 followed by each of the FA-LSPs that form the component links must 2080 be the same. 2082 It is expected that forwarding adjacencies will not be used for 2083 establishing IS-IS/OSPF peering relation between the routers at the 2084 ends of the adjacency. 2086 LSP hierarchy could exist both with the peer and with the overlay 2087 models. With the peer model, the LSP hierarchy is realized via FAs 2088 and an LSP is both created and used as a TE link by exactly the same 2089 instance of the control plane. Creating LSP hierarchies with 2090 overlays doesn't involve the concept of FA. With the overlay model 2092 E. Mannie (Editor) et al. Standard Track 38 2093 an LSP created (and maintained) by one instance of the GMPLS control 2094 plane is used as a TE link by another instance of the GMPLS control 2095 plane. Moreover, the nodes using a TE link are expected to have a 2096 routing and signaling adjacency. 2098 10.2. Signaling Aspects 2100 For the purpose of processing the explicit route in a Path/Request 2101 message of an LSP that is to be tunneled over a forwarding 2102 adjacency, an LSR at the head-end of the FA-LSP views the LSR at the 2103 tail of that FA-LSP as adjacent (one IP hop away). 2105 10.3. Cascading of Forwarding Adjacencies 2107 With an integrated model, several layers are controlled using the 2108 same routing and signaling protocols. A network may then have links 2109 with different multiplexing/demultiplexing capabilities. For 2110 example, a node may be able to multiplex/demultiplex individual 2111 packets on a given link, and may be able to multiplex/demultiplex 2112 channels within a SONET payload on other links. 2114 A new OSPF and IS-IS sub-TLV has been defined to advertise the 2115 multiplexing capability of each interface: PSC, L2SC, TDM, LSC or 2116 FSC. This sub-TLV is called the Interface Switching Capability 2117 Descriptor sub-TLV, which complements the sub-TLVs defined in [OSPF- 2118 TE-GMPLS] and [ISIS-TE-GMPLS]. The information carried in this sub- 2119 TLV is used to construct LSP regions, and determine region's 2120 boundaries. 2122 Path computation may take into account region boundaries when 2123 computing a path for an LSP. For example, path computation may 2124 restrict the path taken by an LSP to only the links whose 2125 multiplexing/demultiplexing capability is PSC. When an LSP need to 2126 cross a region boundary, it can trigger the establishment of an FA 2127 at the underlying layer (i.e. the L2SC layer). This can trigger a 2128 cascading of FAs between layers with the following obvious order: 2129 L2SC, then TDM, then LSC, and then finally FSC. 2131 11. Routing and Signaling Adjacencies 2133 By definition, two nodes have a routing (IS-IS/OSPF) adjacency if 2134 they are neighbors in the IS-IS/OSPF sense. 2136 By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency 2137 if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are 2138 RSVP-TE neighbors if they directly exchange RSVP-TE messages 2139 (Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of 2140 [HIERARCHY]). The neighbor relationship includes exchanging RSVP-TE 2141 Hellos. 2143 By definition, a Forwarding Adjacency (FA) is a TE Link between two 2144 GMPLS nodes whose path transits one or more other (G)MPLS nodes in 2145 the same instance of the (G)MPLS control plane. If two nodes have 2146 one or more non-FA TE Links between them, these two nodes are 2148 E. Mannie (Editor) et al. Standard Track 39 2149 expected (although not required) to have a routing adjacency. If two 2150 nodes do not have any non-FA TE Links between them, it is expected 2151 (although not required) that these two nodes would not have a 2152 routing adjacency. To state the obvious, if the TE links between two 2153 nodes are to be used for establishing LSPs, the two nodes must have 2154 a signaling adjacency. 2156 If one wants to establish routing and/or signaling adjacency between 2157 two nodes, there must be an IP path between them. This IP path can 2158 be, for example, a TE Link with an interface switching capability of 2159 PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a 2160 (bi-directional) LSP that with an interface switching capability of 2161 PSC). 2163 A TE link may not be capable of being used directly for maintaining 2164 routing and/or signaling adjacencies. This is because GMPLS routing 2165 and signaling adjacencies requires exchanging data on a per frame/ 2166 packet basis, and a TE link (e.g. a link between OXCs) may not be 2167 capable of exchanging data on a per packet basis. In this case, the 2168 routing and signaling adjacencies are maintained via a set of one or 2169 more control channels (see [LMP]). 2171 Two nodes may have a TE link between them even if they don't have a 2172 routing adjacency. Naturally, each node must run OSPF/IS-IS with 2173 GMPLS extensions in order for that TE link to be advertised. More 2174 precisely, the node needs to run GMPLS extensions for TE Links with 2175 an interface switching capability (see [GMPLS-ROUTING]) other than 2176 PSC. Moreover, this node needs to run either GMPLS or MPLS 2177 extensions for TE links with an interface switching capability of 2178 PSC. 2180 The mechanisms for Control Channel Separation [RFC3471] should be 2181 used (even if the IP path between two nodes is a TE link). I.e., 2182 RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object 2183 to specify a particular TE link when establishing an LSP. 2185 The IP path could consist of multiple IP hops. In this case, the 2186 mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used 2187 (in addition to Control Channel Separation). 2189 12. Control Plane Fault Handling 2191 Two major types of faults can impact a control plane. The first, 2192 referred to as control channel fault, relates to the case where 2193 control communication is lost between two neighboring nodes. If the 2194 control channel is embedded with the data channel, data channel 2195 recovery procedure should solve the problem. If the control channel 2196 is independent of the data channel, additional procedures are 2197 required to recover from that problem. 2199 The second, referred to as nodal faults, relates to the case where 2200 node loses its control state (e.g., after a restart) but does not 2201 loose its data forwarding state. 2203 E. Mannie (Editor) et al. Standard Track 40 2204 In transport networks, such types of control plane faults should not 2205 have service impact on the existing connections. Under such 2206 circumstances, a mechanism must exist to detect a control 2207 communication failure and a recovery procedure must guarantee 2208 connection integrity at both ends of the control channel. 2210 For a control channel fault, once communication is restored routing 2211 protocols are naturally able to recover but the underlying signaling 2212 protocols must indicate that the nodes have maintained their state 2213 through the failure. The signaling protocol must also ensure that 2214 any state changes that were instantiated during the failure are 2215 synchronized between the nodes. 2217 For a nodal fault, a node's control plane restarts and loses most of 2218 its state information. In this case, both upstream and downstream 2219 nodes must synchronize their state information with the restarted 2220 node. In order for any resynchronization to occur the node 2221 undergoing the restart will need to preserve some information, such 2222 as it's mappings of incoming to outgoing labels. 2224 These issues are addressed in protocol specific fashions, see 2225 [RFC3473], [RFC3472], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. Note that 2226 these cases only apply when there are mechanisms to detect data 2227 channel failures independent of control channel failures. 2229 The LDP Fault tolerance (see [RFC3479]) specifies the procedures to 2230 recover from a control channel failure. [RFC3473] specifies how to 2231 recover from both a control channel failure and a node failure. 2233 13. LSP Protection and Restoration 2235 This section discusses Protection and Restoration (P&R) issues for 2236 GMPLS LSPs. It is driven by the requirements outlined in [RFC3386] 2237 and some of the principles outlined in [RFC3469]. It will be 2238 enhanced, as more GMPLS P&R mechanisms are defined. The scope of 2239 this section is clarified hereafter: 2241 - This section is only applicable when a fault impacting LSP(s) 2242 happens in the data/transport plane. Section 11 deals with control 2243 plane fault handling for nodal and control channel faults. 2245 - This section focuses on P&R at the TDM, LSC and FSC layers. There 2246 are specific P&R requirements at these layers not present at the 2247 PSC layer. 2249 - This section focuses on intra-area P&R as opposed to inter-area 2250 P&R and even inter-domain P&R. Note that P&R can even be more 2251 restricted, e.g. to a collection of like customer equipment, or a 2252 collection of equipment of like capabilities, in one single 2253 routing area. 2255 - This section focuses on intra-layer P&R (horizontal hierarchy as 2256 defined in [RFC3386]) as opposed to the inter-layer P&R (vertical 2257 hierarchy). 2259 E. Mannie (Editor) et al. Standard Track 41 2260 - P&R mechanisms are in general designed to handle single failures, 2261 which makes SRLG diversity a necessity. Recovery from multiple 2262 failures requires further study. 2264 - Both mesh and ring-like topologies are supported. 2266 In the following, we assume that: 2268 - TDM, LSC and FSC devices are more generally committing recovery 2269 resources in a non-best effort way. Recovery resources are either 2270 allocated (thus used) or at least logically reserved (whether used 2271 or not by preemptable extra traffic but unavailable anyway for 2272 regular working traffic). 2274 - Shared P&R mechanisms are valuable to operators in order to 2275 maximize their network utilization. 2277 - Sending preemptable excess traffic on recovery resources is a 2278 valuable feature for operators. 2280 13.1. Protection Escalation across Domains and Layers 2282 To describe the P&R architecture, one must consider two dimensions 2283 of hierarchy [RFC3386]: 2285 - A horizontal hierarchy consisting of multiple P&R domains, which 2286 is important in an LSP based protection scheme. The scope of P&R 2287 may extend over a link (or span), an administrative domain or sub- 2288 network, an entire LSP. 2290 An administrative domain may consist of a single P&R domain or as 2291 a concatenation of several smaller P&R domains. The operator can 2292 configure P&R domains, based on customers' requirements, and on 2293 network topology and traffic engineering constraints. 2295 - A vertical hierarchy consisting of multiple layers of P&R with 2296 varying granularities (packet flows, STS trails, lightpaths, 2297 fibers, etc). 2299 In the absence of adequate P&R coordination, a fault may propagate 2300 from one level to the next within a P&R hierarchy. It can lead to 2301 "collisions" and simultaneous recovery actions may lead to race 2302 conditions, reduced resource utilization, or instabilities 2303 [MANCHESTER]. Thus, a consistent escalation strategy is needed to 2304 coordinate recovery across domains and layers. The fact that GMPLS 2305 can be used at different layers could simplify this coordination. 2307 There are two types of escalation strategies: bottom-up and top- 2308 down. The bottom-up approach assumes that "lower-level" recovery 2309 schemes are more expedient. Therefore we can inhibit or hold off 2310 higher-level P&R. The Top-down approach attempts service P&R at 2311 the higher levels before invoking "lower level" P&R. Higher-layer 2313 E. Mannie (Editor) et al. Standard Track 42 2314 P&R is service selective, and permits "per-CoS" or "per-LSP" re- 2315 routing. 2317 Service Level Agreements (SLAs) between network operators and their 2318 clients are needed to determine the necessary time scales for P&R at 2319 each layer and at each domain. 2321 13.2. Mapping of Services to P&R Resources 2323 The choice of a P&R scheme is a tradeoff between network utilization 2324 (cost) and service interruption time. In light of this tradeoff, 2325 network service providers are expected to support a range of 2326 different service offerings or service levels. 2328 One can classify LSPs into one of a small set of service levels. 2329 Among other things, these service levels define the reliability 2330 characteristics of the LSP. The service level associated with a 2331 given LSP is mapped to one or more P&R schemes during LSP 2332 establishment. An advantage that mapping is that an LSP may use 2333 different P&E schemes in different segments of a network (e.g. some 2334 links may be span protected, whilst other segments of the LSP may 2335 utilize ring protection). These details are likely to be service 2336 provider specific. 2338 An alternative to using service levels is for an application to 2339 specify the set of specific P&R mechanisms to be used when 2340 establishing the LSP. This allows greater flexibility in using 2341 different mechanisms to meet the application requirements. 2343 A differentiator between these service levels is service 2344 interruption time in case of network failures, which is defined as 2345 the length of time between when a failure occurs and when 2346 connectivity is re-established. The choice of service level (or P&R 2347 scheme) should be dictated by the service requirements of different 2348 applications. 2350 13.3. Classification of P&R Mechanism Characteristics 2352 The following figure provides a classification of the possible 2353 provisioning types of recovery LSPs, and of the levels of 2354 overbooking that is possible for them. 2356 +-Computed on +-Established +-Resources pre- 2357 | demand | on demand | allocated 2358 | | | 2359 Recovery LSP | | | 2360 Provisioning -+-Pre computed +-Pre established +-Resources allocated 2361 on demand 2363 +--- Dedicated (1:1, 1+1) 2364 | 2365 | 2366 +--- Shared (1:N, Ring, Shared mesh) 2368 E. Mannie (Editor) et al. Standard Track 43 2369 | 2370 Level of | 2371 Overbooking ---+--- Best effort 2373 13.4. Different Stages in P&R 2375 Recovery from a network fault or impairment takes place in several 2376 stages as discussed in [RFC3469], including fault detection, fault 2377 localization, notification, recovery (i.e. the P&R itself) and 2378 reversion of traffic (i.e. returning the traffic to the original 2379 working LSP or to a new one). 2381 - Fault detection is technology and implementation dependent. In 2382 general, failures are detected by lower layer mechanisms (e.g. 2383 SONET/SDH, Loss-of-Light (LOL)). When a node detects a failure, an 2384 alarm may be passed up to a GMPLS entity, which will take 2385 appropriate actions, or the alarm may be propagated at the lower 2386 layer (e.g. SONET/SDH AIS). 2388 - Fault localization can be done with the help of GMPLS, e.g. using 2389 LMP for fault localization (see section 8.4). 2391 - Fault notification can also be achieved through GMPLS, e.g. using 2392 GMPLS RSVP-TE/CR-LDP notification (see section 9.12). 2394 - This section focuses on the different mechanisms available for 2395 recovery and reversion of traffic once fault detection, 2396 localization and notification have taken place. 2398 13.5. Recovery Strategies 2400 Network P&R techniques can be divided into Protection and 2401 Restoration. In protection, resources between the protection 2402 endpoints are established before failure, and connectivity after 2403 failure is achieved simply by switching performed at the protection 2404 end-points. In contrast, restoration uses signaling after failure to 2405 allocate resources along the recovery path. 2407 - Protection aims at extremely fast reaction times and may rely on 2408 the use of overhead control fields for achieving end-point 2409 coordination. Protection for SONET/SDH networks is described in 2410 [ITUT-G.841] and [ANSI-T1.105]. Protection mechanisms can be 2411 further classified by the level of redundancy and sharing. 2413 - Restoration mechanisms rely on signaling protocols to coordinate 2414 switching actions during recovery, and may involve simple re- 2415 provisioning, i.e. signaling only at the time of recovery; or pre- 2416 signaling, i.e., signaling prior to recovery. 2418 In addition, P&R can be applied on a local or end-to-end basis. In 2419 the local approach, P&R is focused on the local proximity of the 2420 fault in order to reduce delay in restoring service. In the end-to- 2422 E. Mannie (Editor) et al. Standard Track 44 2423 end approach, the LSP originating and terminating nodes control 2424 recovery. 2426 Using these strategies, the following recovery mechanisms can be 2427 defined. 2429 13.6. Recovery mechanisms: Protection schemes 2431 Note that protection schemes are usually defined in technology 2432 specific ways, but this does not preclude other solutions. 2434 - 1+1 Link Protection: Two pre-provisioned resources are used in 2435 parallel. For example, data is transmitted simultaneously on two 2436 parallel links and a selector is used at the receiving node to 2437 choose the best source (see also [GMPLS-FUNCT]). 2439 - 1:N Link Protection: Working and protecting resources (N working, 2440 1 backup) are pre-provisioned. If a working resource fails, the 2441 data is switched to the protecting resource, using a coordination 2442 mechanism (e.g. in overhead bytes). More generally, N working and 2443 M protecting resources can be assigned for M:N link protection 2444 (see also [GMPLS-FUNCT]). 2446 - Enhanced Protection: Various mechanisms such as protection rings 2447 can be used to enhance the level of protection beyond single link 2448 failures to include the ability to switch around a node failure or 2449 multiple link failures within a span, based on a pre-established 2450 topology of protection resources (note: no reference available at 2451 publication time). 2453 - 1+1 LSP Protection: Simultaneous data transmission on working and 2454 protecting LSPs and tail-end selection can be applied (see also 2455 [GMPLS-FUNCT]). 2457 13.7. Recovery mechanisms: Restoration schemes 2459 Thanks to the use of a distributed control plane like GMPLS, 2460 restoration is possible in multiple of tenths of milliseconds. It is 2461 much harder to achieve when only an NMS is used and can only be done 2462 in that case in a multiple of seconds. 2464 - End-to-end LSP restoration with re-provisioning: an end-to-end 2465 restoration path is established after failure. The restoration 2466 path may be dynamically calculated after failure, or pre- 2467 calculated before failure (often during LSP establishment). 2468 Importantly, no signaling is used along the restoration path 2469 before failure, and no restoration bandwidth is reserved. 2470 Consequently, there is no guarantee that a given restoration path 2471 is available when a failure occurs. Thus, one may have to 2472 crankback to search for an available path. 2474 - End-to-end LSP restoration with pre-signaled recovery bandwidth 2475 reservation and no label pre-selection: an end-to-end restoration 2476 path is pre-calculated before failure and a signaling message is 2478 E. Mannie (Editor) et al. Standard Track 45 2479 sent along this pre-selected path to reserve bandwidth, but labels 2480 are not selected (see also [GMPLS-FUNCT]). 2482 The resources reserved on each link of a restoration path may be 2483 shared across different working LSPs that are not expected to fail 2484 simultaneously. Local node policies can be applied to define the 2485 degree to which capacity is shared across independent failures. 2486 Upon failure detection, LSP signaling is initiated along the 2487 restoration path to select labels, and to initiate the appropriate 2488 cross-connections. 2490 - End-to-end LSP restoration with pre-signaled recovery bandwidth 2491 reservation and label pre-selection: An end-to-end restoration 2492 path is pre-calculated before failure and a signaling procedure is 2493 initiated along this pre-selected path on which bandwidth is 2494 reserved and labels are selected (see also [GMPLS-FUNCT]). 2496 The resources reserved on each link may be shared across different 2497 working LSPs that are not expected to fail simultaneously. In 2498 networks based on TDM, LSC and FSC technology, LSP signaling is 2499 used after failure detection to establish cross-connections at the 2500 intermediate switches on the restoration path using the pre- 2501 selected labels. 2503 - Local LSP restoration: the above approaches can be applied on a 2504 local basis rather than end-to-end, in order to reduce recovery 2505 time (note: no reference available at publication time). 2507 13.8. Schema Selection Criteria 2509 This section discusses criteria that could be used by the operator 2510 in order to make a choice among the various P&R mechanisms. 2512 - Robustness: In general, the less pre-planning of the restoration 2513 path, the more robust the restoration scheme is to a variety of 2514 failures, provided that adequate resources are available. 2515 Restoration schemes with pre-planned paths will not be able to 2516 recover from network failures that simultaneously affect both the 2517 working and restoration paths. Thus, these paths should ideally be 2518 chosen to be as disjoint as possible (i.e. SRLG and node 2519 disjoint), so that any single failure event will not affect both 2520 paths. The risk of simultaneous failure of the two paths can be 2521 reduced by recalculating the restoration path whenever a failure 2522 occurs along it. 2524 The pre-selection of a label gives less flexibility for multiple 2525 failure scenarios than no label pre-selection. If failures occur 2526 that affect two LSPs that are sharing a label at a common node 2527 along their restoration routes, then only one of these LSPs can be 2528 recovered, unless the label assignment is changed. 2530 The robustness of a restoration scheme is also determined by the 2531 amount of reserved restoration bandwidth - as the amount of 2532 restoration bandwidth sharing increases (reserved bandwidth 2534 E. Mannie (Editor) et al. Standard Track 46 2535 decreases), the restoration scheme becomes less robust to 2536 failures. Restoration schemes with pre-signaled bandwidth 2537 reservation (with or without label pre-selection) can reserve 2538 adequate bandwidth to ensure recovery from any specific set of 2539 failure events, such as any single SRLG failure, any two SRLG 2540 failures etc. Clearly, more restoration capacity is allocated if a 2541 greater degree of failure recovery is required. Thus, the degree 2542 to which the network is protected is determined by the policy that 2543 defines the amount of reserved restoration bandwidth. 2545 - Recovery time: In general, the more pre-planning of the 2546 restoration route, the more rapid the P&R scheme. Protection 2547 schemes generally recover faster than restoration schemes. 2548 Restoration with pre-signaled bandwidth reservation are likely to 2549 be (significantly) faster than path restoration with re- 2550 provisioning, especially because of the elimination of any 2551 crankback. Local restoration will generally be faster than end-to- 2552 end schemes. 2554 Recovery time objectives for SONET/SDH protection switching (not 2555 including time to detect failure) are specified in [ITUT-G.841] at 2556 50 ms, taking into account constraints on distance, number of 2557 connections involved, and in the case of ring enhanced protection, 2558 number of nodes in the ring. 2560 Recovery time objectives for restoration mechanisms are being 2561 defined through a separate effort [RFC3386]. 2563 - Resource Sharing: 1+1 and 1:N link and LSP protection require 2564 dedicated recovery paths with limited ability to share resources: 2565 1+1 allows no sharing, 1:N allows some sharing of protection 2566 resources and support of extra (preemptable) traffic. Flexibility 2567 is limited because of topology restrictions, e.g. fixed ring 2568 topology for traditional enhanced protection schemes. 2570 The degree to which restoration schemes allow sharing amongst 2571 multiple independent failures is directly dictated by the size of 2572 the restoration pool. In restoration schemes with re-provisioning, 2573 a pool of restoration capacity can be defined from which all 2574 restoration routes are selected after failure. Thus, the degree of 2575 sharing is defined by the amount of available restoration 2576 capacity. In restoration with pre-signaled bandwidth reservation, 2577 the amount of reserved restoration capacity is determined by the 2578 local bandwidth reservation policies. In all restoration schemes, 2579 pre-emptable resources can use spare restoration capacity when 2580 that capacity is not being used for failure recovery. 2582 E. Mannie (Editor) et al. Standard Track 47 2583 14. Network Management 2585 Service Providers (SPs) use network management extensively to 2586 configure, monitor or provision various devices in their network. It 2587 is important to note that a SP's equipment may be distributed across 2588 geographically separate sites thus making distributed management 2589 even more important. The service provider should utilize an NMS 2590 system and standard management protocols such as SNMP (see 2591 [RFC3410], [RFC3411] and [RFC3416]) and the relevant MIB modules as 2592 standard interfaces to configure, monitor and provision devices at 2593 various locations. The service provider may also wish to use the 2594 command line interface (CLI) provided by vendors with their devices. 2595 However, this is not a standard or recommended solution because 2596 there is no standard CLI language or interface, which results in N 2597 different CLIs in a network with devices from N different vendors. 2598 In the context of GMPLS, it is extremely important for standard 2599 interfaces to the SP's devices (e.g. SNMP) to exist due to the 2600 nature of the technology itself. Since GMPLS comprises many 2601 different layers of control-plane and data-plane technology, it is 2602 important for management interfaces in this area to be flexible 2603 enough to allow the manager to manage GMPLS easily, and in a 2604 standard way. 2606 14.1. Network Management Systems (NMS) 2608 The NMS system should maintain the collective information about each 2609 device within the system. Note that the NMS system may actually be 2610 comprised of several distributed applications (i.e. alarm 2611 aggregators, configuration consoles, polling applications, etc.) 2612 that collectively comprises the SP's NMS. In this way, it can make 2613 provisioning and maintenance decisions with the full knowledge of 2614 the entire SP's network. Configuration or provisioning information 2615 (i.e. requests for new services) could be entered into the NMS and 2616 subsequently distributed via SNMP to the remote devices. Thus, 2617 making the SP's task of managing the network much more compact and 2618 effortless rather than having to manage each device individually 2619 (i.e. via CLI). 2621 Security and access control can be achieved using the SNMPv3 User- 2622 based Security Model (USM) [RFC3414] and the View-based Access 2623 Control Model (VACM) [RFC3415]. This approach can be very 2624 effectively used within a SP's network, since the SP has access to 2625 and control over all devices within its domain. Standardized MIBs 2626 will need to be developed before this approach can be used 2627 ubiquitously to provision, configure and monitor devices in non- 2628 heterogeneous networks or across SP's network boundaries. 2630 14.2. Management Information Base (MIB) 2632 In the context of GMPLS, it is extremely important for standard 2633 interfaces to devices to exist due to the nature of the technology 2634 itself. Since GMPLS comprises many different layers of control-plane 2635 technology, it is important for SNMP MIB modules in this area to be 2636 flexible enough to allow the manager to manage the entire control 2638 E. Mannie (Editor) et al. Standard Track 48 2639 plane. This should be done using MIB modules that may cooperate 2640 (i.e. coordinated row-creation on the agent) or through more 2641 generalized MIB modules that aggregate some of the desired actions 2642 to be taken and push those details down to the devices. It is 2643 important to note that in certain circumstances, it may be necessary 2644 to duplicate some small subset of manageable objects in new MIB 2645 modules for management convenience. Control of some parts of GMPLS 2646 may also be achieved using existing MIB interfaces (i.e. existing 2647 SONET MIB) or using separate ones, which are yet to be defined. MIB 2648 modules may have been previously defined in the IETF or ITU. Current 2649 MIB modules may need to be extended to facilitate some of the new 2650 functionality desired by GMPLS. In these cases, the working group 2651 should work on new versions of these MIB modules so that these 2652 extensions can be added. 2654 14.3. Tools 2656 As in traditional networks, standard tools such as traceroute 2657 [RFC1393] and ping [RFC2151] are needed for debugging and 2658 performance monitoring of GMPLS networks, and mainly for the control 2659 plane topology, that will mimic the data plane topology. 2660 Furthermore, such tools provide network reachability information. 2661 The GMPLS control protocols will need to expose certain pieces of 2662 information in order for these tools to function properly and to 2663 provide information germane to GMPLS. These tools should be made 2664 available via the CLI. These tools should also be made available for 2665 remote invocation via the SNMP interface [RFC2925]. 2667 14.4. Fault Correlation between Multiple Layers 2669 Due to the nature of GMPLS, and that potential layers may be 2670 involved in the control and transmission of GMPLS data and control 2671 information, it is required that a fault in one layer be passed to 2672 the adjacent higher and lower layers to notify them of the fault. 2673 However, due to nature of these many layers, it is possible and even 2674 probable, that hundreds or even thousands of notifications may need 2675 to transpire between layers. This is undesirable for several 2676 reasons. First, these notifications will overwhelm the device. 2677 Second, if the device(s) are programmed to emit SNMP Notifications 2678 [RFC3417] then the large number of notifications the device may 2679 attempt to emit may overwhelm the network with a storm of 2680 notifications. Furthermore, even if the device emits the 2681 notifications, the NMS that must process these notifications either 2682 will be overwhelmed or will be processing redundant information. 2683 That is, if 1000 interfaces at layer B are stacked above a single 2684 interface below it at layer A, and the interface at A goes down, the 2685 interfaces at layer B should not emit notifications. Instead, the 2686 interface at layer A should emit a single notification. The NMS 2687 receiving this notification should be able to correlate the fact 2688 that this interface has many others stacked above it and take 2689 appropriate action, if necessary. 2691 Devices that support GMPLS should provide mechanisms for 2692 aggregating, summarizing, enabling and disabling of inter-layer 2694 E. Mannie (Editor) et al. Standard Track 49 2695 notifications for the reasons described above. In the context of 2696 SNMP MIB modules, all MIB modules that are used by GMPLS must 2697 provide enable/disable objects for all notification objects. 2698 Furthermore, these MIBs must also provide notification summarization 2699 objects or functionality (as described above) as well. NMS systems 2700 and standard tools which process notifications or keep track of the 2701 many layers on any given devices must be capable of processing the 2702 vast amount of information which may potentially be emitted by 2703 network devices running GMPLS at any point in time. 2705 15. Security Considerations 2707 GMPLS defines a control plane architecture for multiple technologies 2708 and types of network elements. In general, since LSPs established 2709 using GMPLS may carry high volumes of data and consume significant 2710 network resources, security mechanisms are required to safeguard the 2711 underlying network against attacks on the control plane and/or 2712 unauthorized usage of data transport resources. The GMPLS control 2713 plane should therefore include mechanisms that prevent or minimize 2714 the risk of attackers being able to inject and/or snoop on control 2715 traffic. These risks depend on the level of trust between nodes that 2716 exchange GMPLS control messages, as well as the realization and 2717 physical characteristics of the control channel. For example, an in- 2718 band, in-fiber control channel over SONET/SDH overhead bytes is, in 2719 general, considered less vulnerable than a control channel realized 2720 over an out-of-band IP network. 2722 Security mechanisms can provide authentication and confidentiality. 2723 Authentication can provide origin verification, message integrity 2724 and replay protection, while confidentiality ensures that a third 2725 party cannot decipher the contents of a message. In situations where 2726 GMPLS deployment requires primarily authentication, the respective 2727 authentication mechanisms of the GMPLS component protocols may be 2728 used (see [RFC2747], [RFC3036], [RFC2385] and [LMP]). Additionally, 2729 the IPsec suite of protocols (see [RFC2402], [RFC2406] and 2730 [RFC2409]) may be used to provide authentication, confidentiality or 2731 both, for a GMPLS control channel. IPsec thus offers the benefits of 2732 combined protection for all GMPLS component protocols as well as key 2733 management. 2735 A related issue is that of the authorization of requests for 2736 resources by GMPLS-capable nodes. Authorization determines whether a 2737 given party, presumable already authenticated, has a right to access 2738 the requested resources. This determination is typically a matter of 2739 local policy control [RFC2753], for example by setting limits on the 2740 total bandwidth available to some party in the presence of resource 2741 contention. Such policies may become quite complex as the number of 2742 users, types of resources and sophistication of authorization rules 2743 increases. 2745 After authenticating requests, control elements should match them 2746 against the local authorization policy. These control elements must 2747 be capable of making decisions based on the identity of the 2748 requester, as verified cryptographically and/or topologically. For 2750 E. Mannie (Editor) et al. Standard Track 50 2751 example, decisions may depend on whether the interface through which 2752 the request is made is an inter- or intra-domain one. The use of 2753 appropriate local authorization policies may help in limiting the 2754 impact of security breaches in remote parts of a network. 2756 Finally, it should be noted that GMPLS itself introduces no new 2757 security considerations to the current MPLS-TE signaling (RSVP-TE, 2758 CR-LDP), routing protocols (OSPF-TE, IS-IS-TE) or network management 2759 protocols (SNMP). 2761 16. Acknowledgements 2763 This document is the work of numerous authors and consists of a 2764 composition of a number of previous drafts in this area. 2766 Many thanks to Ben Mack-Crane (Tellabs) for all the useful SONET/SDH 2767 discussions we had together. Thanks also to Pedro Falcao, Alexandre 2768 Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from 2769 Ebone for their SONET/SDH and optical technical advice and support. 2770 Finally, many thanks also to Krishna Mitra (Consultant), Curtis 2771 Villamizar (Avici), Ron Bonica (WorldCom) and Bert Wijnen (Lucent) 2772 for its revision effort of Section 14. 2774 17. Intellectual Property Considerations 2776 This section is taken from Section 10.4 of [RFC2026]. 2778 The IETF takes no position regarding the validity or scope of any 2779 intellectual property or other rights that might be claimed to 2780 pertain to the implementation or use of the technology described in 2781 this document or the extent to which any license under such rights 2782 might or might not be available; neither does it represent that it 2783 has made any effort to identify any such rights. Information on the 2784 IETF's procedures with respect to rights in standards-track and 2785 standards-related documentation can be found in BCP-11. Copies of 2786 claims of rights made available for publication and any assurances 2787 of licenses to be made available, or the result of an attempt made 2788 to obtain a general license or permission for the use of such 2789 proprietary rights by implementors or users of this specification 2790 can be obtained from the IETF Secretariat. 2792 The IETF invites any interested party to bring to its attention any 2793 copyrights, patents or patent applications, or other proprietary 2794 rights which may cover technology that may be required to practice 2795 this standard. Please address the information to the IETF Executive 2796 Director. 2798 18. References 2800 18.1 Normative References 2802 [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic 2803 Description Including Multiplex Structure, Rates, 2804 And Formats," ANSI T1.105, 2000. 2806 E. Mannie (Editor) et al. Standard Track 51 2808 [BUNDLE] K.Kompella, Y.Rekhter and L.Berger, "Link Bundling 2809 in MPLS Traffic Engineering," Work in Progress, 2810 draft-ietf-mpls-bundle-04.txt. 2812 [GMPLS-FUNCT] J.P.Lang and B.Rajagopalan (Editors) et al., 2813 "Generalized MPLS Recovery Functional 2814 Specification," Work in Progress, draft-ietf-ccamp- 2815 gmpls-recovery-functional-01.txt. 2817 [GMPLS-G709] D.Papadimitriou (Editor) et al., "GMPLS Signaling 2818 Extensions for G.709 Optical Transport Networks 2819 Control," Work in progress, draft-ietf-ccamp-gmpls- 2820 g709-03.txt. 2822 [GMPLS-OVERLAY] G.Swallow et al., "GMPLS RSVP Support for the 2823 Overlay Model," Work in Progress, draft-ietf-ccamp- 2824 gmpls-overlay-01.txt. 2826 [GMPLS-ROUTING] K.Kompella and Y.Rekhter (Editors) et al., "Routing 2827 Extensions in Support of Generalized MPLS," Work in 2828 Progress, draft-ietf-ccamp-gmpls-routing-05.txt. 2830 [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., 2831 "Generalized MPLS Extensions for SONET and SDH 2832 Control," Work in progress, draft-ietf-ccamp-gmpls- 2833 sonet-sdh-08.txt. 2835 [HIERARCHY] K.Kompella and Y.Rekhter, "LSP Hierarchy with 2836 Generalized MPLS TE," Work in Progress, draft-ietf- 2837 mpls-lsp-hierarchy-08.txt. 2839 [ITUT-G.707] ITU-T, "Network Node Interface for the Synchronous 2840 Digital Hierarchy", Recommendation G.707, October 2841 2000. 2843 [ITUT-G.709] ITU-T, "Interface for the Optical Transport Network 2844 (OTN)," Recommendation G.709 version 1.0 (and 2845 Amendment 1), February 2001 (and October 2001). 2847 [ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network 2848 Protection Architectures," Recommendation G.841, 2849 October 1998. 2851 [LMP] J.P.Lang (Editor) et al., "Link Management Protocol 2852 (LMP)," Work in progress, draft-ietf-ccamp-lmp- 2853 09.txt. 2855 [LMP-WDM] A.Fredette and J.P.Lang (Editors) et al., "LMP for 2856 WDM Optical Line Systems (LMP-WDM)," Work in 2857 progress, draft-ietf-ccamp-lmp-wdm-02.txt. 2859 [OSPF-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "OSPF Extensions 2860 in Support of Generalized MPLS," Work in Progress, 2862 E. Mannie (Editor) et al. Standard Track 52 2864 [OSPF-TE] D.Katz, D.Yeung, and K.Kompella, "Traffic 2865 Engineering Extensions to OSPF", Work in Progress, 2866 draft-katz-yeung-ospf-traffic-09.txt. 2868 [RFC1393] G.Malkin, "Traceroute Using an IP Option", IETF RFC 2869 1393, January 1993. 2871 [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 2872 3," BCP 9, IETF RFC 2026, October 1996. 2874 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 2875 Requirement Levels", BCP 14, IETF RFC 2119, March 1997. 2877 [RFC2151] G.Kessler and S.Shepard, "A Primer On Internet and 2878 TCP/IP Tools and Utilities", IETF RFC 2151, June 1997. 2880 [RFC2385] A.Heffernan, "Protection of BGP Sessions via the TCP 2881 MD5 Signature Option," IETF RFC 2385, August 1998. 2883 [RFC2402] S.Kent and R.Atkinson, "IP Authentication Header," IETF 2884 RFC 2402, November 1998. 2886 [RFC2406] S.Kent and R. Atkinson, "IP Encapsulating Security 2887 Payload (ESP)," IETF RFC 2406, November 1998. 2889 [RFC2409] D.Harkins and D.Carrel, "The Internet Key Exchange 2890 (IKE)," IETF RFC 2409, November 1998. 2892 [RFC2747] F.Baker et al., "RSVP Cryptographic Authentication," 2893 IETF RFC 2747, January 2000. 2895 [RFC2753] R.Yavatkar, D.Pendarakis and R.Guerin, "A Framework for 2896 Policy-based Admission Control," IETF RFC 2753, January 2897 2000. 2899 [RFC2925] K.White, "Definitions of Managed Objects for Remote 2900 Ping, Traceroute, and Lookup Operations," IETF RFC 2901 2925, September 2000. 2903 [RFC3031] E.Rosen, A.Viswanathan, and R.Callon, "Multiprotocol 2904 Label Switching Architecture," IETF RFC 3031, January 2905 2001. 2907 [RFC3036] L.Andersson, P.Doolan, N.Feldman, A.Fredette, and 2908 B.Thomas, "LDP Specification," IETF RFC 3036, January 2909 2001. 2911 [RFC3209] D.Awduche, et al., "RSVP-TE: Extensions to RSVP for 2912 LSP Tunnels," IETF RFC 3209, December 2001. 2914 [RFC3212] B.Jamoussi (Editor) et al., "Constraint-Based LSP Setup 2915 using LDP," IETF RFC 3212, January 2002. 2917 E. Mannie (Editor) et al. Standard Track 53 2919 [RFC3411] D.Harrington, R.Presuhn and B.Wijnen, "An Architecture 2920 for Describing Simple Network Management Protocol 2921 (SNMP) Management Frameworks," IETF RFC 3411, December 2922 2002. 2924 [RFC3414] U.Blumenthal and B.Wijnen, "User-based Security Model 2925 (USM) for version 3 of the Simple Network Management 2926 Protocol (SNMPv3)," IETF RFC 3414, December 2002. 2928 [RFC3415] B.Wijnen, R.Presuhn, and K.McCloghrie, "View-based 2929 Access Control Model (VACM) for the Simple Network 2930 Management Protocol (SNMP)," IETF RFC 3415, December 2931 2002. 2933 [RFC3416] R.Presuhn (Editor), "Version 2 of the Protocol 2934 Operations for the Simple Network Management Protocol 2935 (SNMP)," IETF RFC 3416, December 2002. 2937 [RFC3417] R.Presuhn (Editor), "Transport Mappings for the Simple 2938 Network Management Protocol (SNMP)," IETF RFC 3417, 2939 December 2002. 2941 [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered 2942 Links in Resource ReSerVation Protocol - Traffic 2943 Engineering (RSVP-TE)," IETF RFC 3477, January 2003. 2945 [RFC3471] L.Berger (Editor) et al., "Generalized MPLS - 2946 Signaling Functional Description," IETF RFC 3471, 2947 January 2003. 2949 [RFC3472] P.Ashwood-Smith and L.Berger (Editors) et al., 2950 "Generalized MPLS Signaling - CR-LDP Extensions," IETF 2951 RFC 3472, January 2003. 2953 [RFC3473] L.Berger (Editor) et al., "Generalized MPLS 2954 Signaling - RSVP-TE Extensions," IETF RFC 3473, January 2955 2003. 2957 [RFC3479] A.Farrel (Editor) et al., "Fault Tolerance for the 2958 Label Distribution Protocol (LDP)," IETF RFC 3479, 2959 February 2003. 2961 [RFC3480] K.Kompella, Y.Rekhter and A.Kullberg, "Signalling 2962 Unnumbered Links in CR-LDP," IETF RFC 3480, February 2963 2003. 2965 18.2 Informative References 2967 [ISIS-TE] H.Smit and T.Li, "IS-IS extensions for Traffic 2968 Engineering," Work in Progress, draft-ietf-isis- 2969 traffic-04.txt. 2971 [ISIS-TE-GMPLS] K.Kompella and Y.Rekhter (Editors), "IS-IS 2973 E. Mannie (Editor) et al. Standard Track 54 2974 Extensions in Support of Generalized MPLS," Work in 2975 Progress, draft-ietf-isis-gmpls-extensions-16.txt. 2977 [MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution 2978 of Transport Network Survivability," IEEE 2979 Communications Magazine, August 1999. 2981 [OIF-UNI] The Optical Internetworking Forum, "User Network 2982 Interface (UNI) 1.0 Signaling Specification - 2983 Implementation Agreement OIF-UNI-01.0," October 2001. 2985 [OLI-REQ] A.Fredette (Editor), "Optical Link Interface 2986 Requirements," Work in Progress. 2988 [RFC2702] D.Awduche, et al., "Requirements for Traffic 2989 Engineering Over MPLS," IETF RFC 2702, September 1999. 2991 [RFC3386] W.Lai, D.McDysan, et al., "Network Hierarchy and Multi- 2992 layer Survivability," IETF RFC 3386, November 2002. 2994 [RFC3410] J.Case, R.Mundy, D.Partain, and B. Stewart, 2995 "Introduction and Applicability Statements for 2996 Internet-Standard Management Framework," IETF RFC 3410, 2997 December 2002. 2999 [RFC3469] V.Sharma and F.Hellstrand (Editors), "Framework for 3000 Multi-Protocol Label Switching (MPLS)-based Recovery," 3001 IETF RFC 3469, February 2003. 3003 [SONET-SDH-GMPLS-FRM] G.Bernstein, E.Mannie and V.Sharma, 3004 "Framework for GMPLS-based Control of SDH/SONET 3005 Networks," Work in Progress. 3007 19. Author's Address 3009 Eric Mannie (Consult) 3010 Phone: +32 2 658-5023 3011 Mobile: +32 (0)495-221775 3012 Email: eric_mannie@hotmail.com 3014 20. Contributors 3016 Peter Ashwood-Smith (Nortel) Eric Mannie (Consult) 3017 P.O. Box 3511 Station C, Phone: +32 2 648-5023 3018 Ottawa, ON K1Y 4H7, Canada Mobile: +32 (0)495-221775 3019 Email: petera@nortelnetworks.com Email: eric_mannie@hotmail.com 3021 Daniel O. Awduche (Consult) Thomas D. Nadeau (Cisco) 3022 Email: awduche@awduche.com 250 Apollo Drive 3023 Chelmsford, MA 01824, USA 3024 Email: tnadeau@cisco.com 3026 E. Mannie (Editor) et al. Standard Track 55 3027 Ayan Banerjee (Calient) Lyndon Ong (Ciena) 3028 5853 Rue Ferrari 10480 Ridgeview Ct 3029 San Jose, CA 95138, USA Cupertino, CA 95014, USA 3030 Email: abanerjee@calient.net Email: lyong@ciena.com 3032 Debashis Basak (Accelight) Dimitri Papadimitriou (Alcatel) 3033 70 Abele Road, Bldg.1200 Francis Wellesplein, 1 3034 Bridgeville, PA 15017, USA B-2018 Antwerpen, Belgium 3035 Email: dbasak@accelight.com Email: 3036 dimitri.papadimitriou@alcatel.be 3038 Lou Berger (Movaz) Dimitrios Pendarakis (Tellium) 3039 7926 Jones Branch Drive 2 Crescent Place, P.O. Box 901 3040 MCLean VA, 22102, USA Oceanport, NJ 07757-0901, USA 3041 Email: lberger@movaz.com Email: dpendarakis@tellium.com 3043 Greg Bernstein (Grotto) Bala Rajagopalan (Tellium) 3044 Email: 2 Crescent Place, P.O. Box 901 3045 gregb@grotto-networking.com Oceanport, NJ 07757-0901, USA 3046 Email: braja@tellium.com 3048 Sudheer Dharanikota (Consult) Yakov Rekhter (Juniper) 3049 Email: sudheer@ieee.org 1194 N. Mathilda Ave. 3050 Sunnyvale, CA 94089, USA 3051 Email: yakov@juniper.net 3053 John Drake (Calient) Debanjan Saha 3054 5853 Rue Ferrari (IBM Watson Research Center) 3055 San Jose, CA 95138, USA Email: dsaha@us.ibm.com 3056 Email: jdrake@calient.net 3058 Yanhe Fan (Axiowave) Hal Sandick 3059 200 Nickerson Road Shepard M.S. 3060 Marlborough, MA 01752, USA 2401 Dakota Street 3061 Email: yfan@axiowave.com Durham, NC 27705, USA 3062 Email: sandick@nc.rr.com 3064 Don Fedyk (Nortel) Vishal Sharma (Metanoia) 3065 600 Technology Park Drive 1600 Villa Street, Unit 352 3066 Billerica, MA 01821, USA Mountain View, CA 94041, USA 3067 Email: Email: v.sharma@ieee.org 3068 dwfedyk@nortelnetworks.com 3070 Gert Grammel (Alcatel) George Swallow (Cisco) 3071 Lorenzstrasse, 10 250 Apollo Drive 3072 70435 Stuttgart, Germany Chelmsford, MA 01824, USA 3073 Email: gert.grammel@alcatel.de Email: swallow@cisco.com 3075 Dan Guo (Turin) Z. Bo Tang (Tellium) 3076 1415 N. McDowell Blvd, Petaluma, 2 Crescent Place, P.O. Box 901 3077 CA 95454, USA Oceanport, NJ 07757-0901, USA 3078 Email: dguo@turinnetworks.com Email: btang@tellium.com 3080 E. Mannie (Editor) et al. Standard Track 56 3081 Kireeti Kompella (Juniper) Jennifer Yates (AT&T) 3082 1194 N. Mathilda Ave. 180 Park Avenue 3083 Sunnyvale, CA 94089, USA Florham Park, NJ 07932, USA 3084 Email: kireeti@juniper.net Email: jyates@research.att.com 3086 Alan Kullberg (NetPlane) George R. Young (Edgeflow) 3087 888 Washington 329 March Road 3088 St.Dedham, MA 02026, USA Ottawa, Ontario, K2K 2E1, Canada 3089 Email: akullber@netplane.com Email: george.young@edgeflow.com 3091 Jonathan P. Lang John Yu (Hammerhead Systems) 3092 (Rincon Networks) 640 Clyde Court 3093 Email: jplang@ieee.org Mountain View, CA 94043, USA 3094 Email: john@hammerheadsystems.com 3096 Fong Liaw (Solas Research) Alex Zinin (Alcatel) 3097 Solas Research, LLC 1420 North McDowell Ave 3098 Email: fongliaw@yahoo.com Petaluma, CA 94954, USA 3099 Email: alex.zinin@alcatel.com 3101 E. Mannie (Editor) et al. Standard Track 57 3102 Full Copyright Statement 3104 "Copyright (C) The Internet Society (date). All Rights Reserved. 3105 This document and translations of it may be copied and furnished to 3106 others, and derivative works that comment on or otherwise explain it 3107 or assist in its implementation may be prepared, copied, published 3108 and distributed, in whole or in part, without restriction of any 3109 kind, provided that the above copyright notice and this paragraph 3110 are included on all such copies and derivative works. However, this 3111 document itself may not be modified in any way, such as by removing 3112 the copyright notice or references to the Internet Society or other 3113 Internet organizations, except as needed for the purpose of 3114 developing Internet standards in which case the procedures for 3115 copyrights defined in the Internet Standards process must be 3116 followed, or as required to translate it into languages other than 3117 English. 3119 The limited permissions granted above are perpetual and will not be 3120 revoked by the Internet Society or its successors or assigns. 3122 This document and the information contained herein is provided on an 3123 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3124 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3125 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3126 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3127 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 3129 E. Mannie (Editor) et al. Standard Track 58