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