idnits 2.17.1 draft-ietf-mpls-generalized-signaling-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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 100 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([GMPLS-LDP], [GMPLS-SONET], [GMPLS-RSVP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 677: '... is reserved. It MUST be set to zero o...' RFC 2119 keyword, line 678: '... and MUST be ignored on receip...' RFC 2119 keyword, line 763: '...ontention and it MUST issue a PathErr/...' RFC 2119 keyword, line 765: '... error, the node SHOULD try to allocat...' RFC 2119 keyword, line 930: '...ted for a secondary LSP MAY be used by...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2001) is 8197 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: 'MPLS-BUNDLING' is mentioned on line 1066, but not defined == Unused Reference: 'RECOVERY' is defined on line 1265, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-05 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-06 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-00 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-00 ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- Possible downref: Normative reference to a draft: ref. 'LMP' -- Possible downref: Normative reference to a draft: ref. 'MPLS-BUNDLE' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 -- No information found for draft-ieft-mpls-recovery-frmwrk - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RECOVERY' Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Peter Ashwood-Smith (Nortel Networks Corp.) 2 Internet Draft Ayan Banerjee (Calient Networks) 3 Expiration Date: May 2002 Lou Berger (Movaz Networks) 4 Greg Bernstein (Ciena Corporation) 5 John Drake (Calient Networks) 6 Yanhe Fan (Axiowave Networks) 7 Kireeti Kompella (Juniper Networks, Inc.) 8 Eric Mannie (EBONE) 9 Jonathan P. Lang (Calient Networks) 10 Bala Rajagopalan (Tellium, Inc.) 11 Yakov Rekhter (Juniper Networks, Inc.) 12 Debanjan Saha (Tellium, Inc.) 13 Vishal Sharma (Metanoia, Inc.) 14 George Swallow (Cisco Systems) 15 Z. Bo Tang (Tellium, Inc.) 17 November 2001 19 Generalized MPLS - Signaling Functional Description 21 draft-ietf-mpls-generalized-signaling-07.txt 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its areas, 28 and its working groups. Note that other groups may also distribute 29 working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 To view the current status of any Internet-Draft, please check the 37 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 38 Directory, see http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes extensions to MPLS signaling required to 43 support Generalized MPLS. Generalized MPLS extends the MPLS control 44 plane to encompass time-division (e.g. SONET ADMs), wavelength 45 (optical lambdas) and spatial switching (e.g. incoming port or fiber 46 to outgoing port or fiber). This document presents a functional 47 description of the extensions. Protocol specific formats and 48 mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP]. Technology 49 specific details are expected to be specified in independent 50 technology specific documents, e.g., [GMPLS-SONET]. 52 Contents 54 1 Introduction .............................................. 3 55 2 Overview ................................................. 4 56 3 Label Related Formats .................................... 6 57 3.1 Generalized Label Request ................................. 7 58 3.1.1 Required Information ...................................... 7 59 3.1.2 Bandwidth Encoding ........................................ 9 60 3.2 Generalized Label ......................................... 10 61 3.2.1 Required Information ...................................... 11 62 3.3 Waveband Switching ........................................ 12 63 3.3.1 Required information ...................................... 12 64 3.4 Suggested Label ........................................... 13 65 3.5 Label Set ................................................. 14 66 3.5.1 Required Information ...................................... 15 67 4 Bidirectional LSPs ........................................ 16 68 4.1 Required Information ...................................... 17 69 4.2 Contention Resolution ..................................... 17 70 5 Notification on Label Error ............................... 20 71 6 Explicit Label Control .................................... 20 72 6.1 Required Information ...................................... 21 73 7 Protection Information .................................... 21 74 7.1 Required Information ...................................... 22 75 8 Administrative Status Information ......................... 23 76 8.1 Required Information ...................................... 24 77 9 Control Channel Separation ................................ 25 78 9.1 Interface Identification .................................. 25 79 9.1.1 Required Information ...................................... 25 80 9.2 Fault Handling ............................................ 27 81 10 Acknowledgments ........................................... 28 82 11 Security Considerations ................................... 28 83 12 IANA Considerations ....................................... 28 84 13 References ................................................ 28 85 14 Authors' Addresses ........................................ 29 87 [Editor's note: changes to be removed prior to publication as an RFC.] 88 Changes from previous version: 90 o Removed various parameter values based on comments 91 o Minor editorial changes and clarifications 93 1. Introduction 95 The Multiprotocol Label Switching (MPLS) architecture [MPLS-ARCH] has 96 been defined to support the forwarding of data based on a label. In 97 this architecture, Label Switching Routers (LSRs) were assumed to 98 have a forwarding plane that is capable of (a) recognizing either 99 packet or cell boundaries, and (b) being able to process either 100 packet headers (for LSRs capable of recognizing packet boundaries) or 101 cell headers (for LSRs capable of recognizing cell boundaries). 103 The original architecture has recently been extended to include LSRs 104 whose forwarding plane recognizes neither packet, nor cell 105 boundaries, and therefore, can't forward data based on the 106 information carried in either packet or cell headers. Specifically, 107 such LSRs include devices where the forwarding decision is based on 108 time slots, wavelengths, or physical ports. 110 Given the above, LSRs, or more precisely interfaces on LSRs, can be 111 subdivided into the following classes: 113 1. Interfaces that recognize packet/cell boundaries and can forward 114 data based on the content of the packet/cell header. Examples 115 include interfaces on routers that forward data based on the 116 content of the "shim" header, interfaces on ATM-LSRs that forward 117 data based on the ATM VPI/VCI. Such interfaces are referred to as 118 Packet-Switch Capable (PSC). 120 2. Interfaces that forward data based on the data's time slot in a 121 repeating cycle. An example of such an interface is an interface 122 on a SONET Cross-Connect. Such interfaces are referred to as 123 Time-Division Multiplex Capable (TDM). 125 3. Interfaces that forward data based on the wavelength on which the 126 data is received. An example of such an interface is an interface 127 on an Optical Cross-Connect that can operate at the level of an 128 individual wavelength. Such interfaces are referred to as Lambda 129 Switch Capable (LSC). 131 4. Interfaces that forward data based on a position of the data in 132 the real world physical spaces. An example of such an interface 133 is an interface on an Optical Cross-Connect that can operate at 134 the level of a single (or multiple) fibers. Such interfaces are 135 referred to as Fiber-Switch Capable (FSC). 137 Using the concept of nested LSPs allows the system to scale by 138 building a forwarding hierarchy. At the top of this hierarchy are 139 FSC interfaces, followed by LSC interfaces, followed by TDM 140 interfaces, followed by PSC interfaces. This way, an LSP that starts 141 and ends on a PSC interface can be nested (together with other LSPs) 142 into an LSP that starts and ends on a TDM interface. This LSP, in 143 turn, can be nested (together with other LSPs) into an LSP that 144 starts and ends on an LSC interface, which in turn can be nested 145 (together with other LSPs) into an LSP that starts and ends on a FSC 146 interface. See [MPLS-HIERARCHY] for more information on LSP 147 hierarchies. 149 The establishment of LSPs that span only the first class of 150 interfaces is defined in [LDP, CR-LDP, RSVP-TE]. This document 151 presents a functional description of the extensions needed to 152 generalize the MPLS control plane to support each of the four classes 153 of interfaces. Only signaling protocol independent formats and 154 definitions are provided in this document. Protocol specific formats 155 are defined in [GMPLS-RSVP] and [GMPLS-LDP]. Technology specific 156 details are outside the scope of this document and will be specified 157 in technology specific documents, such as [GMPLS-SONET]. 159 2. Overview 161 Generalized MPLS differs from traditional MPLS in that it supports 162 multiple types of switching, i.e., the addition of support for TDM, 163 lambda, and fiber (port) switching. The support for the additional 164 types of switching has driven generalized MPLS to extend certain base 165 functions of traditional MPLS and, in some cases, to add 166 functionality. These changes and additions impact basic LSP 167 properties, how labels are requested and communicated, the 168 unidirectional nature of LSPs, how errors are propagated, and 169 information provided for synchronizing the ingress and egress. 171 In traditional MPLS Traffic Engineering, links traversed by an LSP 172 can include an intermix of links with heterogeneous label encodings. 173 For example, an LSP may span links between routers, links between 174 routers and ATM-LSRs, and links between ATM-LSRs. Generalized MPLS 175 extends this by including links where the label is encoded as a time 176 slot, or a wavelength, or a position in the real world physical 177 space. Just like with traditional MPLS TE, where not all LSRs are 178 capable of recognizing (IP) packet boundaries (e.g., an ATM-LSR) in 179 their forwarding plane, generalized MPLS includes support for LSRs 180 that can't recognize (IP) packet boundaries in their forwarding 181 plane. In traditional MPLS TE an LSP that carries IP has to start 182 and end on a router. Generalized MPLS extends this by requiring an 183 LSP to start and end on similar type of LSRs. Also, in generalized 184 MPLS the type of a payload that can be carried by an LSP is extended 185 to allow such payloads as SONET/SDH, or 1 or 10Gb Ethernet. These 186 changes from traditional MPLS are reflected in how labels are 187 requested and communicated in generalized MPLS, see Sections 3.1 and 188 3.2. A special case of Lambda switching, called Waveband switching 189 is also described in Section 3.3. 191 Another basic difference between traditional and non-PSC types of 192 generalized MPLS LSPs, is that bandwidth allocation for an LSP can be 193 performed only in discrete units, see Section 3.1.3. There are also 194 likely to be (much) fewer labels on non-PSC links than on PSC links. 195 Note that the use of Forwarding Adjacencies (FA), see [MPLS- 196 HIERARCHY], provides a mechanism that may improve bandwidth 197 utilization, when bandwidth allocation can be performed only in 198 discrete units, as well as a mechanism to aggregate forwarding state, 199 thus allowing the number of required labels to be reduced. 201 Generalized MPLS allows for a label to be suggested by an upstream 202 node, see Section 3.4. This suggestion may be overridden by a 203 downstream node but, in some cases, at the cost of higher LSP setup 204 time. The suggested label is valuable when establishing LSPs through 205 certain kinds of optical equipment where there may be a lengthy (in 206 electrical terms) delay in configuring the switching fabric. For 207 example micro mirrors may have to be elevated or moved, and this 208 physical motion and subsequent damping takes time. If the labels and 209 hence switching fabric are configured in the reverse direction (the 210 norm) the MAPPING/Resv message may need to be delayed by 10's of 211 milliseconds per hop in order to establish a usable forwarding path. 212 The suggested label is also valuable when recovering from nodal 213 faults. 215 Generalized MPLS extends on the notion of restricting the range of 216 labels that may be selected by a downstream node, see Section 3.5. 217 In generalized MPLS, an ingress or other upstream node may restrict 218 the labels that may be used by an LSP along either a single hop or 219 along the whole LSP path. This feature is driven from the optical 220 domain where there are cases where wavelengths used by the path must 221 be restricted either to a small subset of possible wavelengths, or to 222 one specific wavelength. This requirement occurs because some 223 equipment may only be able to generate a small set of the wavelengths 224 that intermediate equipment may be able to switch, or because 225 intermediate equipment may not be able to switch a wavelength at all, 226 being only able to redirect it to a different fiber. 228 While traditional traffic engineered MPLS (and even LDP) are 229 unidirectional, generalized MPLS supports the establishment of 230 bidirectional LSPs, see Section 4. The need for bidirectional LSPs 231 comes from non-PSC applications. There are multiple reasons why such 232 LSPs are needed, particularly possible resource contention when 233 allocating reciprocal LSPs via separate signaling sessions, and 234 simplifying failure restoration procedures in the non-PSC case. 235 Bidirectional LSPs also have the benefit of lower setup latency and 236 lower number of messages required during setup. 238 Generalized MPLS supports the communication of a specific label to 239 use on a specific interface, see Section 6. [GMPLS-RSVP] also 240 supports an RSVP specific mechanism for rapid failure notification. 242 Generalized MPLS formalizes possible separation of control and data 243 channels, see Section 9. Such support is particularly important to 244 support technologies where control traffic cannot be sent in-band 245 with the data traffic. 247 Generalized MPLS also allows for the inclusion of technology specific 248 parameters in signaling. The intent is for all technology specific 249 parameters to be carried, when using RSVP, in the SENDER_TSPEC and 250 other related objects, and when using CR-LDP, in the Traffic 251 Parameters TLV. Technology specific formats will be defined on an as 252 needed basis. For an example definition, see [GMPLS-SONET]. 254 3. Label Related Formats 256 To deal with the widening scope of MPLS into the optical and time 257 domain, several new forms of "label" are required. These new forms 258 of label are collectively referred to as a "generalized label". A 259 generalized label contains enough information to allow the receiving 260 node to program its cross connect, regardless of the type of this 261 cross connect, such that the ingress segments of the path are 262 properly joined. This section defines a generalized label request, a 263 generalized label, support for waveband switching, suggested label 264 and label sets. 266 Note that since the nodes sending and receiving the new form of label 267 know what kinds of link they are using, the generalized label does 268 not contain a type field, instead the nodes are expected to know from 269 context what type of label to expect. 271 3.1. Generalized Label Request 273 The Generalized Label Request supports communication of 274 characteristics required to support the LSP being requested. These 275 characteristics include LSP encoding and LSP payload. Note that 276 these characteristics may be used by transit nodes, e.g., to support 277 penultimate hop popping. 279 The Generalized Label Request carries an LSP encoding parameter, 280 called LSP Encoding Type. This parameter indicates the encoding 281 type, e.g., SONET/SDH/GigE etc., that will be used with the data 282 associated with the LSP. The LSP Encoding Type represents the nature 283 of the LSP, and not the nature of the links that the LSP traverses. 284 A link may support a set of encoding formats, where support means 285 that a link is able to carry and switch a signal of one or more of 286 these encoding formats depending on the resource availability and 287 capacity of the link. For example, consider an LSP signaled with 288 "lambda" encoding. It is expected that such an LSP would be 289 supported with no electrical conversion and no knowledge of the 290 modulation and speed by the transit nodes. Other formats normally 291 require framing knowledge, and field parameters are broken into the 292 framing type and speed as shown below. 294 The Generalized Label Request also indicates the type of switching 295 that is being requested on a link. This field normally is consistent 296 across all links of an LSP. 298 3.1.1. Required Information 300 The information carried in a Generalized Label Request is: 302 0 1 2 3 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | LSP Enc. Type |Switching Type | G-PID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 LSP Encoding Type: 8 bits 310 Indicates the encoding of the LSP being requested. The 311 following shows permitted values and their meaning: 313 Value Type 314 ----- ---- 315 1 Packet 316 2 Ethernet V2/DIX 317 3 ANSI PDH 318 4 ETSI PDH 319 5 SDH ITU-T G.707 320 6 SONET ANSI T1.105 321 7 Digital Wrapper 322 8 Lambda (photonic) 323 9 Fiber 324 10 Ethernet 802.3 325 11 FiberChannel 327 The ANSI PDH and ETSI PDH types designate these respective 328 networking technologies. DS1 and DS3 are examples of ANSI PDH 329 LSPs. An E1 LSP would be ETSI PDH. The Lambda encoding type 330 refers to an LSP that encompasses a whole wavelengths. The 331 Fiber encoding type refers to an LSP that encompasses a whole 332 fiber port. 334 Switching Type: 8 bits 336 Indicates the type of switching that should be performed on a 337 particular link. This field is needed for links that advertise 338 more than one type of switching capability. Values of this 339 field are as the Switching Capability field defined in [GMPLS- 340 RTG] 342 Generalized PID (G-PID): 16 bits 344 An identifier of the payload carried by an LSP, i.e. an 345 identifier of the client layer of that LSP. This is used by 346 the nodes at the endpoints of the LSP, and in some cases by the 347 penultimate hop. Standard Ethertype values are used for packet 348 and Ethernet LSPs; other values are: 350 Value Type Technology 351 ----- ---- ---------- 352 0 Unknown All 353 1 Reserved 354 2 Reserved 355 3 Reserved 356 4 Reserved 357 5 Asynchronous mapping of E4 SONET, SDH 358 6 Asynchronous mapping of DS3/T3 SONET, SDH 359 7 Asynchronous mapping of E3 SONET, SDH 360 8 Bit synchronous mapping of E3 SDH 361 9 Byte synchronous mapping of E3 SDH 362 10 Asynchronous mapping of DS2/T2 SONET, SDH 363 11 Bit synchronous mapping of DS2/T2 SONET, SDH 364 12 Reserved 365 13 Asynchronous mapping of E1 SONET, SDH 366 14 Byte synchronous mapping of E1 SONET, SDH 367 15 Byte synchronous mapping of 31 * DS0 SONET, SDH 368 16 Asynchronous mapping of DS1/T1 SONET, SDH 369 17 Bit synchronous mapping of DS1/T1 SONET, SDH 370 18 Byte synchronous mapping of DS1/T1 SONET, SDH 371 19 VC-11 in VC-12 SDH 372 20 Reserved 373 21 Reserved 374 22 DS1 SF Asynchronous SONET 375 23 DS1 ESF Asynchronous SONET 376 24 DS3 M23 Asynchronous SONET 377 25 DS3 C-Bit Parity Asynchronous SONET 378 26 VT/LOVC SONET, SDH 379 27 STS SPE/HOVC SONET, SDH 380 28 POS - No Scrambling, 16 bit CRC SONET, SDH 381 29 POS - No Scrambling, 32 bit CRC SONET, SDH 382 30 POS - Scrambling, 16 bit CRC SONET, SDH 383 31 POS - Scrambling, 32 bit CRC SONET, SDH 384 32 ATM mapping SONET, SDH 385 33 Ethernet SDH, Lambda, Fiber 386 34 SDH Lambda, Fiber 387 35 SONET Lambda, Fiber 388 36 Digital Wrapper Lambda, Fiber 389 37 Lambda Fiber 390 38 ETSI PDH SDH 391 39 ANSI PDH SONET, SDH 392 40 Link Access Protocol SDH SONET, SDH 393 (LAPS - X.85 and X.86) 394 41 FDDI SONET, SDH, Lambda, Fiber 395 42 DQDB (ETSI ETS 300 216) SONET, SDH 396 43 FiberChannel-3 (Services) FiberChannel 398 3.1.2. Bandwidth Encoding 400 Bandwidth encodings are carried in in 32 bit number in IEEE floating 401 point format (the unit is bytes per second). For non-packet LSPs, it 402 is useful to define discrete values to identify the bandwidth of the 403 LSP. Some typical values for the requested bandwidth are enumerated 404 below. (These values are guidelines.) Additional values will be 405 defined as needed. Bandwidth encoding values are carried in a per 406 protocol specific manner, see [GMPLS-RSVP] and [GMPLS-LDP]. 408 Signal Type (Bit-rate) Value (Bytes/Sec) 409 (IEEE Floating point) 410 -------------- --------------- --------------------- 411 DS0 (0.064 Mbps) 0x45FA0000 412 DS1 (1.544 Mbps) 0x483C7A00 413 E1 (2.048 Mbps) 0x487A0000 414 DS2 (6.312 Mbps) 0x4940A080 415 E2 (8.448 Mbps) 0x4980E800 416 Ethernet (10.00 Mbps) 0x49989680 417 E3 (34.368 Mbps) 0x4A831A80 418 DS3 (44.736 Mbps) 0x4AAAA780 419 STS-1 (51.84 Mbps) 0x4AC5C100 420 Fast Ethernet (100.00 Mbps) 0x4B3EBC20 421 E4 (139.264 Mbps) 0x4B84D000 422 FC-0 133M 0x4B7DAD68 423 OC-3/STM-1 (155.52 Mbps) 0x4B9450C0 424 FC-0 266M 0x4BFDAD68 425 FC-0 531M 0x4C7D3356 426 OC-12/STM-4 (622.08 Mbps) 0x4C9450C0 427 GigE (1000.00 Mbps) 0x4CEE6B28 428 FC-0 1062M 0x4CFD3356 429 OC-48/STM-16 (2488.32 Mbps) 0x4D9450C0 430 OC-192/STM-64 (9953.28 Mbps) 0x4E9450C0 431 10GigE-LAN (10000.00 Mbps) 0x4E9502F9 432 OC-768/STM-256 (39813.12 Mbps) 0x4F9450C0 434 3.2. Generalized Label 436 The Generalized Label extends the traditional label by allowing the 437 representation of not only labels which travel in-band with 438 associated data packets, but also labels which identify time-slots, 439 wavelengths, or space division multiplexed positions. For example, 440 the Generalized Label may carry a label that represents (a) a single 441 fiber in a bundle, (b) a single waveband within fiber, (c) a single 442 wavelength within a waveband (or fiber), or (d) a set of time-slots 443 within a wavelength (or fiber). It may also carry a label that 444 represents a generic MPLS label, a Frame Relay label, or an ATM label 445 (VCI/VPI). 447 A Generalized Label does not identify the "class" to which the label 448 belongs. This is implicit in the multiplexing capabilities of the 449 link on which the label is used. 451 A Generalized Label only carries a single level of label, i.e., it is 452 non-hierarchical. When multiple levels of label (LSPs within LSPs) 453 are required, each LSP must be established separately, see [MPLS- 454 HIERARCHY]. 456 Each Generalized Label object carries a variable length label 457 parameter. 459 3.2.1. Required Information 461 The information carried in a Generalized Label is: 463 0 1 2 3 464 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Label | 467 | ... | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Label: Variable 472 Carries label information. The interpretation of this field 473 depends on the type of the link over which the label is used. 475 3.2.1.1. Port and Wavelength Labels 477 Some configurations of fiber switching (FSC) and lambda switching 478 (LSC) use multiple data channels/links controlled by a single control 479 channel. In such cases the label indicates the data channel/link to 480 be used for the LSP. Note that this case is not the same as when 481 [MPLS-BUNDLING] is being used. 483 The information carried in a Port and Wavelength label is: 485 0 1 2 3 486 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Label | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Label: 32 bits 492 Indicates port/fiber or lambda to be used, from the sender's 493 perspective. Values used in this field only have significance 494 between two neighbors, and the receiver may need to convert the 495 received value into a value that has local significance. 496 Values may be configured or dynamically determined using a 497 protocol such as [LMP]. 499 3.2.1.2. Other Labels 501 Generic MPLS labels and Frame Relay labels are encoded right 502 justified aligned in 32 bits (4 octets). ATM labels are encoded with 503 the VPI right justified in bits 0-15 and the VCI right justified in 504 bits 16-31. 506 3.3. Waveband Switching 508 A special case of lambda switching is waveband switching. A waveband 509 represents a set of contiguous wavelengths which can be switched 510 together to a new waveband. For optimization reasons it may be 511 desirable for an optical cross connect to optically switch multiple 512 wavelengths as a unit. This may reduce the distortion on the 513 individual wavelengths and may allow tighter separation of the 514 individual wavelengths. The Waveband Label is defined to support 515 this special case. 517 Waveband switching naturally introduces another level of label 518 hierarchy and as such the waveband is treated the same way all other 519 upper layer labels are treated. 521 As far as the MPLS protocols are concerned there is little difference 522 between a waveband label and a wavelength label except that 523 semantically the waveband can be subdivided into wavelengths whereas 524 the wavelength can only be subdivided into time or statistically 525 multiplexed labels. 527 3.3.1. Required information 529 Waveband switching uses the same format as the generalized label, see 530 section 3.2.1. 532 In the context of waveband switching, the generalized label has the 533 following format: 534 0 1 2 3 535 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Waveband Id | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Start Label | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | End Label | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Waveband Id: 32 bits 546 A waveband identifier. The value is selected by the sender and 547 reused in all subsequent related messages. 549 Start Label: 32 bits 551 Indicates the channel identifier, from the sender's 552 perspective, of the lowest value wavelength making up the 553 waveband. 555 End Label: 32 bits 557 Indicates the channel identifier, from the sender's 558 perspective, of the highest value wavelength making up the 559 waveband. 561 Channel identifiers are established either by configuration or by 562 means of a protocol such as LMP [LMP]. They are normally used in the 563 label parameter of the Generalized Label one PSC and LSC. 565 3.4. Suggested Label 567 The Suggested Label is used to provide a downstream node with the 568 upstream node's label preference. This permits the upstream node to 569 start configuring it's hardware with the proposed label before the 570 label is communicated by the downstream node. Such early 571 configuration is valuable to systems that take non-trivial time to 572 establish a label in hardware. Such early configuration can reduce 573 setup latency, and may be important for restoration purposes where 574 alternate LSPs may need to be rapidly established as a result of 575 network failures. 577 The use of Suggested Label is only an optimization. If a downstream 578 node passes a different label upstream, an upstream LSR reconfigures 579 itself so that it uses the label specified by the downstream node, 580 thereby maintaining the downstream control of a label. Note, the 581 transmission of a suggested label does not imply that the suggested 582 label is available for use. In particular, an ingress node should 583 not transmit data traffic on a suggested label until the downstream 584 node passes a label upstream. 586 The information carried in a suggested label is identical to a 587 generalized label. 589 3.5. Label Set 591 The Label Set is used to limit the label choices of a downstream node 592 to a set of acceptable labels. This limitation applies on a per hop 593 basis. 595 We describe four cases where a Label Set is useful in the optical 596 domain. The first case is where the end equipment is only capable of 597 transmitting on a small specific set of wavelengths/bands. The 598 second case is where there is a sequence of interfaces which cannot 599 support wavelength conversion (CI-incapable) and require the same 600 wavelength be used end-to-end over a sequence of hops, or even an 601 entire path. The third case is where it is desirable to limit the 602 amount of wavelength conversion being performed to reduce the 603 distortion on the optical signals. The last case is where two ends 604 of a link support different sets of wavelengths. 606 Label Set is used to restrict label ranges that may be used for a 607 particular LSP between two peers. The receiver of a Label Set must 608 restrict its choice of labels to one which is in the Label Set. Much 609 like a label, a Label Set may be present across multiple hops. In 610 this case each node generates it's own outgoing Label Set, possibly 611 based on the incoming Label Set and the node's hardware capabilities. 612 This case is expected to be the norm for nodes with conversion 613 incapable (CI-incapable) interfaces. 615 The use of Label Set is optional, if not present, all labels from the 616 valid label range may be used. Conceptually the absence of a Label 617 Set implies a Label Set whose value is {U}, the set of all valid 618 labels. 620 3.5.1. Required Information 622 A label set is composed of one or more Label_Set objects/TLVs. Each 623 object/TLV contains one or more elements of the Label Set. Each 624 element is referred to as a subchannel identifier and has the same 625 format as a generalized label. 627 The information carried in a Label_Set is: 629 0 1 2 3 630 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Action | Reserved | Label Type | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Subchannel 1 | 635 | ... | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 : : : 638 : : : 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Subchannel N | 641 | ... | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Action: 8 bits 646 0 - Inclusive List 648 Indicates that the object/TLV contains one or more 649 subchannel elements that are included in the Label Set. 651 1 - Exclusive List 653 Indicates that the object/TLV contains one or more 654 subchannel elements that are excluded from the Label Set. 656 2 - Inclusive Range 658 Indicates that the object/TLV contains a range of labels. 659 The object/TLV contains two subchannel elements. The first 660 element indicates the start of the range. The second 661 element indicates the end of the range. A value of zero 662 indicates that there is no bound on the corresponding 663 portion of the range. 665 3 - Exclusive Range 667 Indicates that the object/TLV contains a range of labels 668 that are excluded from the Label Set. The object/TLV 669 contains two subchannel elements. The first element 670 indicates the start of the range. The second element 671 indicates the end of the range. A value of zero indicates 672 that there is no bound on the corresponding portion of the 673 range. 675 Reserved: 10 bits 677 This field is reserved. It MUST be set to zero on transmission 678 and MUST be ignored on receipt. 680 Label Type: 14 bits 682 Indicates the type and format of the labels carried in the 683 object/TLV. Values are signaling protocol specific. 685 Subchannel: 687 The subchannel represents the label (wavelength, fiber ... ) 688 which is eligible for allocation. This field has the same 689 format as described for labels under section 3.2. 691 Note that subchannel to local channel identifiers (e.g., 692 wavelength) mappings are a local matter. 694 4. Bidirectional LSPs 696 This section defines direct support of bidirectional LSPs. Support 697 is defined for LSPs that have the same traffic engineering 698 requirements including fate sharing, protection and restoration, 699 LSRs, and resource requirements (e.g., latency and jitter) in each 700 direction. In the remainder of this section, the term "initiator" is 701 used to refer to a node that starts the establishment of an LSP and 702 the term "terminator" is used to refer to the node that is the target 703 of the LSP. Note that for bidirectional LSPs, there is only one 704 "initiator" and one "terminator". 706 Normally to establish a bidirectional LSP when using [RSVP-TE] or 707 [CR-LDP] two unidirectional paths must be independently established. 708 This approach has the following disadvantages: 710 * The latency to establish the bidirectional LSP is equal to one 711 round trip signaling time plus one initiator-terminator signaling 712 transit delay. This not only extends the setup latency for 713 successful LSP establishment, but it extends the worst-case 714 latency for discovering an unsuccessful LSP to as much as two 715 times the initiator-terminator transit delay. These delays are 716 particularly significant for LSPs that are established for 717 restoration purposes. 719 * The control overhead is twice that of a unidirectional LSP. 720 This is because separate control messages (e.g. Path and Resv) 721 must be generated for both segments of the bidirectional LSP. 723 * Because the resources are established in separate segments, 724 route selection is complicated. There is also additional 725 potential race for conditions in assignment of resources, which 726 decreases the overall probability of successfully establishing 727 the bidirectional connection. 729 * It is more difficult to provide a clean interface for SONET 730 equipment that may rely on bidirectional hop-by-hop paths for 731 protection switching. 733 * Bidirectional optical LSPs (or lightpaths) are seen as a 734 requirement for many optical networking service providers. 736 With bidirectional LSPs both the downstream and upstream data paths, 737 i.e., from initiator to terminator and terminator to initiator, are 738 established using a single set of signaling messages. This reduces 739 the setup latency to essentially one initiator-terminator round trip 740 time plus processing time, and limits the control overhead to the 741 same number of messages as a unidirectional LSP. 743 4.1. Required Information 745 For bidirectional LSPs, two labels must be allocated. Bidirectional 746 LSP setup is indicated by the presence of an Upstream Label 747 object/TLV in the appropriate signaling message. An Upstream Label 748 has the same format as the generalized label, see Section 3.2. 750 4.2. Contention Resolution 752 Contention for labels may occur between two bidirectional LSP setup 753 requests traveling in opposite directions. This contention occurs 754 when both sides allocate the same resources (labels) at effectively 755 the same time. If there is no restriction on the labels that can be 756 used for bidirectional LSPs and if there are alternate resources, 757 then both nodes will pass different labels upstream and there is no 758 contention. However, if there is a restriction on the labels that 759 can be used for the bidirectional LSPs (for example, if they must be 760 physically coupled on a single I/O card), or if there are no more 761 resources available, then the contention must be resolved by other 762 means. To resolve contention, the node with the higher node ID will 763 win the contention and it MUST issue a PathErr/NOTIFICATION message 764 with a "Routing problem/Label allocation failure" indication. Upon 765 receipt of such an error, the node SHOULD try to allocate a different 766 Upstream label (and a different Suggested Label if used) to the 767 bidirectional path. However, if no other resources are available, 768 the node must proceed with standard error handling. 770 To reduce the probability of contention, one may impose a policy that 771 the node with the lower ID never suggests a label in the downstream 772 direction and always accepts a Suggested Label from an upstream node 773 with a higher ID. Furthermore, since the labels may be exchanged 774 using LMP, an alternative local policy could further be imposed such 775 that (with respect to the higher numbered node's label set) the 776 higher numbered node could allocate labels from the high end of the 777 label range while the lower numbered node allocates labels from the 778 low end of the label range. This mechanism would augment any close 779 packing algorithms that may be used for bandwidth (or wavelength) 780 optimization. One special case that should be noted when using RSVP 781 and supporting this approach is that the neighbor's node ID might not 782 be known when sending an initial Path message. When this case 783 occurs, a node should suggest a label chosen at random from the 784 available label space. 786 An example of contention between two nodes (PXC 1 and PXC 2) is shown 787 in Figure 1. In this example PXC 1 assigns an Upstream Label for the 788 channel corresponding to local BCId=2 (local BCId=7 on PXC 2) and 789 sends a Suggested Label for the channel corresponding to local BCId=1 790 (local BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream 791 Label for the channel corresponding to its local BCId=6 (local BCId=1 792 on PXC 1) and sends a Suggested Label for the channel corresponding 793 to its local BCId=7 (local BCId=2 on PXC 1). If there is no 794 restriction on the labels that can be used for bidirectional LSPs and 795 if there are alternate resources available, then both PXC 1 and PXC 2 796 will pass different labels upstream and the contention is resolved 797 naturally (see Fig. 2). However, if there is a restriction on the 798 labels that can be used for bidirectional LSPs (for example, if they 799 must be physically coupled on a single I/O card), then the contention 800 must be resolved using the node ID (see Fig. 3). 802 +------------+ +------------+ 803 + PXC 1 + + PXC 2 + 804 + + SL1,UL2 + + 805 + 1 +------------------------>+ 6 + 806 + + UL1, SL2 + + 807 + 2 +<------------------------+ 7 + 808 + + + + 809 + + + + 810 + 3 +------------------------>+ 8 + 811 + + + + 812 + 4 +<------------------------+ 9 + 813 +------------+ +------------+ 814 Figure 1. Label Contention 816 In this example, PXC 1 assigns an Upstream Label using BCId=2 (BCId=7 817 on PXC 2) and a Suggested Label using BCId=1 (BCId=6 on PXC 2). 818 Simultaneously, PXC 2 assigns an Upstream Label using BCId=6 (BCId=1 819 on PXC 1) and a Suggested Label using BCId=7 (BCId=2 on PXC 1). 821 +------------+ +------------+ 822 + PXC 1 + + PXC 2 + 823 + + UL2 + + 824 + 1 +------------------------>+ 6 + 825 + + UL1 + + 826 + 2 +<------------------------+ 7 + 827 + + + + 828 + + L1 + + 829 + 3 +------------------------>+ 8 + 830 + + L2 + + 831 + 4 +<------------------------+ 9 + 832 +------------+ +------------+ 833 Figure 2. Label Contention Resolution without resource restrictions 835 In this example, there is no restriction on the labels that can be 836 used by the bidirectional connection and there is no contention. 838 +------------+ +------------+ 839 + PXC 1 + + PXC 2 + 840 + + UL2 + + 841 + 1 +------------------------>+ 6 + 842 + + L2 + + 843 + 2 +<------------------------+ 7 + 844 + + + + 845 + + L1 + + 846 + 3 +------------------------>+ 8 + 847 + + UL1 + + 848 + 4 +<------------------------+ 9 + 849 +------------+ +------------+ 850 Figure 3. Label Contention Resolution with resource restrictions 852 In this example, labels 1,2 and 3,4 on PXC 1 (labels 6,7 and 8,9 on 853 PXC 2, respectively) must be used by the same bidirectional 854 connection. Since PXC 2 has a higher node ID, it wins the contention 855 and PXC 1 must use a different set of labels. 857 5. Notification on Label Error 859 There are cases in traditional MPLS and in GMPLS that result in an 860 error message containing an "Unacceptable label value" indication, 861 see [RSVP-TE], [GMPLS-LDP] and [GMPLS-RSVP]. When these cases occur, 862 it can useful for the node generating the error message to indicate 863 which labels would be acceptable. To cover this case, GMPLS 864 introduces the ability to convey such information via the "Acceptable 865 Label Set". An Acceptable Label Set is carried in appropriate 866 protocol specific error messages, see [GMPLS-LDP] and [GMPLS-RSVP]. 868 The format of an Acceptable Label Set is identical to a Label Set, 869 see section 3.5.1. 871 6. Explicit Label Control 873 In traditional MPLS, the interfaces used by an LSP may be controlled 874 via an explicit route, i.e., ERO or ER-Hop. This enables the 875 inclusion of a particular node/interface, and the termination of an 876 LSP on a particular outgoing interface of the egress LSR. Where the 877 interface may be numbered or unnumbered, see [MPLS-UNNUM]. 879 There are cases where the existing explicit route semantics do not 880 provide enough information to control the LSP to the degree desired. 881 This occurs in the case when the LSP initiator wishes to select a 882 label used on a link. Specifically, the problem is that ERO and ER- 883 Hop do not support explicit label sub-objects. An example case where 884 such a mechanism is desirable is where there are two LSPs to be 885 "spliced" together, i.e., where the tail of the first LSP would be 886 "spliced" into the head of the second LSP. This last case is more 887 likely to be used in the non-PSC classes of links. 889 To cover this case, the Label ERO subobject / ER Hop is introduced. 891 6.1. Required Information 893 The Label Explicit and Record Routes contains: 895 L: 1 bit 897 This bit must be set to 0. 899 U: 1 bit 901 This bit indicates the direction of the label. It is 0 for the 902 downstream label. It is set to 1 for the upstream label and is 903 only used on bidirectional LSPs. 905 Label: Variable 907 This field identifies the label to be used. The format of this 908 field is identical to the one used by the Label field in 909 Generalized Label, see Section 3.2.1. 911 Placement and ordering of these parameters are signaling protocol 912 specific. 914 7. Protection Information 916 Protection Information is carried in a new object/TLV. It is used to 917 indicate link related protection attributes of a requested LSP. The 918 use of Protection Information for a particular LSP is optional. 919 Protection Information currently indicates the link protection type 920 desired for the LSP. If a particular protection type, i.e., 1+1, or 921 1:N, is requested, then a connection request is processed only if the 922 desired protection type can be honored. Note that the protection 923 capabilities of a link may be advertised in routing, see [GMPLS-RTG]. 924 Path computation algorithms may take this information into account 925 when computing paths for setting up LSPs. 927 Protection Information also indicates if the LSP is a primary or 928 secondary LSP. A secondary LSP is a backup to a primary LSP. The 929 resources of a secondary LSP are not used until the primary LSP 930 fails. The resources allocated for a secondary LSP MAY be used by 931 other LSPs until the primary LSP fails over to the secondary LSP. At 932 that point, any LSP that is using the resources for the secondary LSP 933 MUST be preempted. 935 7.1. Required Information 937 The following information is carried in Protection Information: 939 0 1 2 3 940 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 |S| Reserved | Link Flags| 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 Secondary (S): 1 bit 947 When set, indicates that the requested LSP is a secondary LSP. 949 Reserved: 25 bits 951 This field is reserved. It MUST be set to zero on transmission 952 and MUST be ignored on receipt. 954 Link Flags: 6 bits 956 Indicates desired link protection type. As previously 957 mentioned, protection capabilities of a link may be advertised 958 in routing. A value of 0 implies that any, including no, link 959 protection may be used. More than one bit may be set to 960 indicate when multiple protection types are acceptable. When 961 multiple bits are set and multiple protection types are 962 available, the choice of protection type is a local (policy) 963 decision. 965 The following flags are defined: 967 0x20 Enhanced 969 Indicates that a protection scheme that is more reliable 970 than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS- 971 SPRING. 973 0x10 Dedicated 1+1 975 Indicates that a dedicated link layer protection scheme, 976 i.e., 1+1 protection, should be used to support the LSP. 978 0x08 Dedicated 1:1 980 Indicates that a dedicated link layer protection scheme, 981 i.e., 1:1 protection, should be used to support the LSP. 983 0x04 Shared 985 Indicates that a shared link layer protection scheme, 986 such as 1:N protection, should be used to support the 987 LSP. 989 0x02 Unprotected 991 Indicates that the LSP should not use any link layer 992 protection. 994 0x01 Extra Traffic 996 Indicates that the LSP should use links that are 997 protecting other (primary) traffic. Such LSPs may be 998 preempted when the links carrying the (primary) traffic 999 being protected fail. 1001 8. Administrative Status Information 1003 Administrative Status Information is carried in a new object/TLV. 1004 Administrative Status Information is currently used in two ways. In 1005 the first, the information indicates administrative state with 1006 respect to a particular LSP. In this usage, Administrative Status 1007 Information indicates the state of the LSP. State indications 1008 include "up" or "down", if it in a "testing" mode, and if deletion is 1009 in progress. The actions taken by a node based on a state local 1010 decision. An example action that may be taken is to inhibit alarm 1011 reporting when an LSP is in "down" or "testing" states, or to report 1012 alarms associated with the connection at a priority equal to or less 1013 than "Non service affecting". 1015 In the second usage of Administrative Status Information, the 1016 information indicates a request to set an LSP's administrative state. 1017 This information is always relayed to the ingress node which acts on 1018 the request. 1020 The different usages are distinguished in a protocol specific 1021 fashion. See [GMPLS-RSVP] and [GMPLS-LDP] for details. The use of 1022 Administrative Status Information for a particular LSP is optional. 1024 8.1. Required Information 1026 The following information is carried in Administrative Status 1027 Information: 1029 0 1 2 3 1030 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 |R| Reserved |T|A|D| 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 Reflect (R): 1 bit 1037 When set, indicates that the edge node SHOULD reflect the 1038 object back in the appropriate message. This bit MUST NOT be 1039 set in state change request, i.e. Notify, messages. 1041 Reserved: 28 bits 1043 This field is reserved. It MUST be set to zero on transmission 1044 and MUST be ignored on receipt. 1046 Testing (T): 1 bit 1048 When set, indicates that the local actions related to the 1049 "testing" mode should be taken. 1051 Administratively down (A): 1 bit 1053 When set, indicates that the local actions related to the 1054 "administratively down" state should be taken. 1056 Deletion in progress (D): 1 bit 1058 When set, indicates that that the local actions related to LSP 1059 teardown should be taken. Edge nodes may use this flag to 1060 control connection teardown. 1062 9. Control Channel Separation 1064 The concept of a control channel being different than a data channel 1065 being signaled was introduced to MPLS in connection with link 1066 bundling, see [MPLS-BUNDLING]. In GMPLS, the separation of control 1067 and data channel may be due to any number of factors. (Including 1068 bundling and other cases such as data channels that cannot carry in- 1069 band control information.) This section will cover the two critical 1070 related issues: the identification of data channels in signaling and 1071 handling of control channel failures that don't impact data channels. 1073 9.1. Interface Identification 1075 In traditional MPLS there as an implicit one-to-one association of a 1076 control channel to a data channel. When such an association is 1077 present, no additional or special information is required to 1078 associate a particular LSP setup transaction with a particular data 1079 channel. (It's implicit in the control channel over which the 1080 signaling messages are sent.) 1082 In cases where there is not an explicit one-to-one association of 1083 control channels to data channels it is necessary to convey 1084 additional information in signaling to identify the particular data 1085 channel being controlled. GMPLS supports explicit data channel 1086 identification by providing interface identification information. 1087 GMPLS allows the use of a number of interface identification schemes 1088 including IPv4 or IPv6 addresses, interface indexes (see [MPLS- 1089 UNNUM]) and component interfaces (established via configuration or a 1090 protocol such as [LMP]). In all cases the choice of the data 1091 interface is indicated by the upstream node using addresses and 1092 identifiers used by the upstream node. 1094 9.1.1. Required Information 1096 The following information is carried in Interface_ID: 1098 0 1 2 3 1099 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | | 1102 ~ TLVs ~ 1103 | | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Where each TLV has the following format: 1108 0 1 2 3 1109 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Type | Length | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | | 1114 ~ Value ~ 1115 | | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 Length: 16 bits 1120 Indicates the total length of the TLV, i.e., 4 + the length of 1121 the value field in octets. A value field whose length is not a 1122 multiple of four MUST be zero-padded so that the TLV is four- 1123 octet aligned. 1125 Type: 16 bits 1127 Indicates type of interface being identified. Defined values 1128 are: 1130 Type Length Format Description 1131 ----------------------------------------------------------------------- 1132 1 8 IPv4 Addr. IPv4 1133 2 20 IPv6 Addr. IPv6 1134 3 12 See below IF_INDEX (Interface Index) 1135 4 12 See below COMPONENT_IF_DOWNSTREAM (Component interface) 1136 5 12 See below COMPONENT_IF_UPSTREAM (Component interface) 1138 For types 3, 4 and 5 the Value field has the format: 1140 0 1 2 3 1141 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | IP Address | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Interface ID | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 IP Address: 32 bits 1149 The IP address field may carry either an IP address of a 1150 link, or an IP address associated with the router ID, 1151 where router ID may be the value carried in the router ID 1152 TLV of routing. See [MPLS-UNNUM] for details related to 1153 type 3 usage. 1155 Interface ID: 32 bits 1157 For type 3 usage, the Interface ID carries an interface 1158 identifier as defined in [MPLS-UNNUM]. 1160 For types 4 and 5, the Interface ID indicates a bundled 1161 component link, see [MPLS-BUNDLE]. The special value 1162 0xFFFFFFFF can be used to indicate the same label is to 1163 be valid across all component links. 1165 9.2. Fault Handling 1167 There are two new faults that must be handled when the control 1168 channel is independent of the data channel. In the first, there is a 1169 link or other type of failure the limits the ability of neighboring 1170 nodes to pass control messages. In this situation, neighboring nodes 1171 are unable to exchange control messages for a period of time. Once 1172 communication is restored the underlying signaling protocol must 1173 indicate that the nodes have maintained their state through the 1174 failure. The signaling protocol must also ensure that any state 1175 changes that were instantiated during the failure are synchronized 1176 between the nodes. 1178 In the the second, a node's control plane fails and then restarts and 1179 losses most of it's state information. In this case, both upstream 1180 and downstream nodes must synchronize their state information with 1181 the restarted node. In order for any resynchronization to occur the 1182 node undergoing the restart will need to preserve some information, 1183 such as it's mappings of incoming to outgoing labels. 1185 Both cases are addressed in protocol specific fashions, see [GMPLS- 1186 RSVP] and [GMPLS-LDP]. 1188 Note that these cases only apply when there are mechanisms to detect 1189 data channel failures independent of control channel failures. 1191 10. Acknowledgments 1193 This draft is the work of numerous authors and consists of a 1194 composition of a number of previous drafts in this area. A list of 1195 the drafts from which material and ideas were incorporated follows: 1197 draft-saha-rsvp-optical-signaling-00.txt 1198 draft-lang-mpls-rsvp-oxc-00.txt 1199 draft-kompella-mpls-optical-00.txt 1200 draft-fan-mpls-lambda-signaling-00.txt 1202 Valuable comments and input were received from a number of people, 1203 including Igor Bryskin, Adrian Farrel, Ben Mack-Crane, Dimitri 1204 Papadimitriou, Fong Liaw and Juergen Heiles. Some sections of this 1205 document are based on text proposed by Fong Liaw. 1207 11. Security Considerations 1209 This draft introduce no new security considerations to either [CR- 1210 LDP] or [RSVP-TE]. 1212 12. IANA Considerations 1214 There are multiple fields and values defined within this document. 1215 IANA is requested to administer assignment of new values. All values 1216 should be allocated through an IETF Consensus action. 1218 13. References 1220 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 1221 draft-ietf-mpls-cr-ldp-05.txt, February, 2001. 1223 [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - 1224 CR-LDP Extensions", Internet Draft, 1225 draft-ietf-mpls-generalized-cr-ldp-05.txt, 1226 November, 2001. 1228 [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - 1229 RSVP-TE Extensions", Internet Draft, 1230 draft-ietf-mpls-generalized-rsvp-te-06.txt, 1231 November, 2001. 1233 [GMPLS-RTG] Kompella, K., et al, "Routing Extensions in Support 1234 of Generalized MPLS", Internet Draft, 1235 draft-ietf-ccamp-gmpls-routing-00.txt, September, 2001. 1237 [GMPLS-SONET] Ashwood-Smith, P. et al, "GMPLS - SONET / SDH Specifics", 1238 Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-00.txt, 1239 April, 2001. 1241 [LDP] Andersson et al., "LDP Specification", RFC 3036. 1243 [LMP] Lang, et al. "Link Management Protocol", 1244 Internet Draft, draft-ietf-mpls-lmp-02.txt, March, 2001. 1246 [MPLS-ARCH] Rosen et al., "Multiprotocol label switching 1247 Architecture", RFC 3031. 1249 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling 1250 in MPLS Traffic Engineering", Internet Draft, 1251 draft-kompella-mpls-bundle-05.txt, Feb., 2001. 1253 [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 1254 MPLS TE", Internet Draft, 1255 draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. 1257 [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 1258 in RSVP-TE", Internet Draft, 1259 draft-ietf-mpls-rsvp-unnum-01.txt, February 2001 1261 [RSVP-TE] Awduche, et. al., "RSVP-TE: Extensions to RSVP for LSP 1262 Tunnels," Internet Draft, 1263 draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, Feb., 2001. 1265 [RECOVERY] Sharma, et al "A Framework for MPLS-based Recovery," 1266 draft-ieft-mpls-recovery-frmwrk-02.txt, March, 2001 1268 14. Authors' Addresses 1270 Peter Ashwood-Smith 1271 Nortel Networks Corp. 1272 P.O. Box 3511 Station C, 1273 Ottawa, ON K1Y 4H7 1274 Canada 1275 Phone: +1 613 763 4534 1276 Email: petera@nortelnetworks.com 1277 Ayan Banerjee 1278 Calient Networks 1279 5853 Rue Ferrari 1280 San Jose, CA 95138 1281 Phone: +1 408 972-3645 1282 Email: abanerjee@calient.net 1284 Lou Berger 1285 Movaz Networks, Inc. 1286 7926 Jones Branch Drive 1287 Suite 615 1288 McLean VA, 22102 1289 Phone: +1 703 847-1801 1290 Email: lberger@movaz.com 1292 Greg Bernstein 1293 Ciena Corporation 1294 10480 Ridgeview Court 1295 Cupertino, CA 94014 1296 Phone: +1 408 366 4713 1297 Email: greg@ciena.com 1299 John Drake 1300 Calient Networks 1301 5853 Rue Ferrari 1302 San Jose, CA 95138 1303 Phone: +1 408 972 3720 1304 Email: jdrake@calient.net 1306 Yanhe Fan 1307 Axiowave Networks, Inc. 1308 200 Nickerson Road 1309 Marlborough, MA 01752 1310 Phone: + 1 774 348 4627 1311 Email: yfan@axiowave.com 1313 Kireeti Kompella 1314 Juniper Networks, Inc. 1315 1194 N. Mathilda Ave. 1316 Sunnyvale, CA 94089 1317 Email: kireeti@juniper.net 1319 Jonathan P. Lang 1320 Calient Networks 1321 25 Castilian 1322 Goleta, CA 93117 1323 Email: jplang@calient.net 1324 Eric Mannie 1325 EBONE 1326 Terhulpsesteenweg 6A 1327 1560 Hoeilaart - Belgium 1328 Phone: +32 2 658 56 52 1329 Mobile: +32 496 58 56 52 1330 Fax: +32 2 658 51 18 1331 Email: eric.mannie@ebone.com 1333 Bala Rajagopalan 1334 Tellium, Inc. 1335 2 Crescent Place 1336 P.O. Box 901 1337 Oceanport, NJ 07757-0901 1338 Phone: +1 732 923 4237 1339 Fax: +1 732 923 9804 1340 Email: braja@tellium.com 1342 Yakov Rekhter 1343 Juniper Networks, Inc. 1344 Email: yakov@juniper.net 1346 Debanjan Saha 1347 Tellium Optical Systems 1348 2 Crescent Place 1349 Oceanport, NJ 07757-0901 1350 Phone: +1 732 923 4264 1351 Fax: +1 732 923 9804 1352 Email: dsaha@tellium.com 1354 Vishal Sharma 1355 Metanoia, Inc. 1356 335 Elan Village Lane, Unit 203 1357 San Jose, CA 95134-2539 1358 Phone: +1 408-943-1794 1359 Email: v.sharma@ieee.org 1361 George Swallow 1362 Cisco Systems, Inc. 1363 250 Apollo Drive 1364 Chelmsford, MA 01824 1365 Voice: +1 978 244 8143 1366 Email: swallow@cisco.com 1367 Z. Bo Tang 1368 Tellium, Inc. 1369 2 Crescent Place 1370 P.O. Box 901 1371 Oceanport, NJ 07757-0901 1372 Phone: +1 732 923 4231 1373 Fax: +1 732 923 9804 1374 Email: btang@tellium.com 1376 Generated on: Wed Nov 21 15:29:32 EST 2001