idnits 2.17.1 draft-ietf-mpls-generalized-signaling-01.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([GMPLS-LDP], [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 607: '...ant in a particular context it MUST be...' RFC 2119 keyword, line 608: '...transmitted, and MUST be ignored when ...' RFC 2119 keyword, line 645: '... MUST NOT be used for SDH since t...' RFC 2119 keyword, line 789: '...t label upstream, an upstream LSR MUST...' RFC 2119 keyword, line 968: '...ID will win the contention and it MUST...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 406 has weird spacing: '...l Range is:...' -- 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 2000) is 8556 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 691, but not defined == Missing Reference: 'MPLS-UNNUM' is mentioned on line 1071, but not defined == Unused Reference: 'MPLS-BUNDLE' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'GMPLS-ISIS' is defined on line 1152, but no explicit reference was found in the text == Unused Reference: 'GMPLS-OSPF' is defined on line 1162, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-04 == Outdated reference: A later version (-02) exists of draft-lang-mpls-lmp-01 -- Possible downref: Normative reference to a draft: ref. 'LMP' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-06 == Outdated reference: A later version (-05) exists of draft-kompella-mpls-bundle-02 -- Possible downref: Normative reference to a draft: ref. 'MPLS-BUNDLE' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-00 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-00 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-00 -- No information found for draft-ompls-ospf-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-OSPF' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-06 -- 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 (~~), 16 warnings (==), 8 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 2001 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 (GTS) 9 Jonathan P. Lang (Calient Networks) 10 Bala Rajagopalan (Tellium, Inc.) 11 Yakov Rekhter (Cisco Systems) 12 Debanjan Saha (Tellium, Inc.) 13 Vishal Sharma (Tellabs) 14 George Swallow (Cisco Systems) 15 Z. Bo Tang (Tellium, Inc.) 17 November 2000 19 Generalized MPLS - Signaling Functional Description 21 draft-ietf-mpls-generalized-signaling-01.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 MPLS to encompass 44 time-division (e.g. SONET ADMs), wavelength (optical lambdas) and 45 spatial switching (e.g. incoming port or fiber to outgoing port or 46 fiber). This document presents a functional description of the 47 extensions. Protocol specific formats and mechanisms are specified 48 in [GMPLS-RSVP] and [GMPLS-LDP]. 50 Contents 52 1 Introduction ................................................ 3 53 2 Overview ................................................... 4 54 3 Label Related Formats ...................................... 6 55 3.1 Generalized Label Request ................................... 6 56 3.2 Generalized Label ........................................... 12 57 3.3 Waveband Switching .......................................... 17 58 3.4 Suggested Label ............................................. 18 59 3.5 Label Set ................................................... 19 60 4 Bidirectional LSPs .......................................... 21 61 4.1 Required Information ........................................ 22 62 4.2 Contention Resolution ....................................... 22 63 5 Explicit Label Control ...................................... 25 64 5.1 Required Information ........................................ 26 65 6 Acknowledgments ............................................. 26 66 7 Security Considerations ..................................... 27 67 8 References .................................................. 27 68 9 Authors' Addresses .......................................... 28 70 Changes from previous version: 72 o Moved protocol specific details into two documents, one for RSVP-TE 73 and one for CR-LDP. 74 o Clarified Label Set 75 o Fixed bandwidth encodings 76 o Minor text cleanup 78 1. Introduction 80 The Multiprotocol Label Switching (MPLS) architecture [MPLS-ARCH] has 81 been defined to support the forwarding of data based on a label. In 82 this architecture, Label Switching Routers (LSRs) were assumed to 83 have a forwarding plane that is capable of (a) recognizing either 84 packet or cell boundaries, and (b) being able to process either 85 packet headers (for LSRs capable of recognizing packet boundaries) or 86 cell headers (for LSRs capable of recognizing cell boundaries). 88 The original architecture has recently been extended to include LSRs 89 whose forwarding plane recognizes neither packet, nor cell 90 boundaries, and therefore, can't forward data based on the 91 information carried in either packet or cell headers. Specifically, 92 such LSRs include devices where the forwarding decision is based on 93 time slots, wavelengths, or physical ports. 95 Given the above, LSRs, or more precisely interfaces on LSRs, can be 96 subdivided into the following classes: 98 1. Interfaces that recognize packet/cell boundaries and can forward 99 data based on the content of the packet/cell header. Examples 100 include interfaces on routers that forward data based on the 101 content of the "shim" header, interfaces on ATM-LSRs that forward 102 data based on the ATM VPI/VCI. Such interfaces are referred to as 103 Packet-Switch Capable (PSC). 105 2. Interfaces that forward data based on the data's time slot in a 106 repeating cycle. An example of such an interface is an interface 107 on a SONET Cross-Connect. Such interfaces are referred to as 108 Time-Division Multiplex Capable (TDM). 110 3. Interfaces that forward data based on the wavelength on which the 111 data is received. An example of such an interface is an interface 112 on an Optical Cross-Connect that can operate at the level of an 113 individual wavelength. Such interfaces are referred to as Lambda 114 Switch Capable (LSC). 116 4. Interfaces that forward data based on a position of the data in 117 the real world physical spaces. An example of such an interface 118 is an interface on an Optical Cross-Connect that can operate at 119 the level of a single (or multiple) fibers. Such interfaces are 120 referred to as Fiber-Switch Capable (FSC). 122 Using the concept of nested LSPs (by using label stack) allows the 123 system to scale by building a forwarding hierarchy. At the top of 124 this hierarchy are FSC interfaces, followed by LSC interfaces, 125 followed by TDM interfaces, followed by PSC interfaces. This way, an 126 LSP that starts and ends on a PSC interface can be nested (together 127 with other LSPs) into an LSP that starts and ends on a TDM interface. 128 This LSP, in turn, can be nested (together with other LSPs) into an 129 LSP that starts and ends on an LSC interface, which in turn can be 130 nested (together with other LSPs) into an LSP that starts and ends on 131 a FSC interface. See [MPLS-HIERARCHY] for more information on LSP 132 hierarchies. 134 The establishment of LSPs that span only the first class of 135 interfaces is defined in the [LDP, CR-LDP, RSVP-TE]. This document 136 presents a functional description of the extensions needed to support 137 each of the four classes of interfaces. Only signaling protocol 138 independent formats and definitions are provided in this document. 139 Protocol specific formats are defined in [GMPLS-RSVP] and [GMPLS- 140 LDP]. 142 2. Overview 144 Generalized MPLS differs from traditional MPLS in that it supports 145 multiple types of switching, i.e., the addition of support for TDM, 146 lambda, and fiber (port) switching. The support for the additional 147 types of switching has driven generalized MPLS to extend certain base 148 functions of traditional MPLS and, in some cases, to add 149 functionality. These changes and additions impact basic LSP 150 properties, how labels are requested and communicated, the 151 unidirectional nature of LSPs, how errors are propagated, and 152 information provided for synchronizing the ingress and egress. 154 In traditional MPLS Traffic Engineering, links traversed by an LSP 155 can include an intermix of links with heterogeneous label encodings. 156 For example, an LSP may span links between routers, links between 157 routers and ATM-LSRs, and links between ATM-LSRs. Generalized MPLS 158 extends this by including links where the label is encoded as a time 159 slot, or a wavelength, or a position in the real world physical 160 space. Just like with traditional MPLS TE, where not all LSRs are 161 capable of recognizing (IP) packet boundaries (e.g., an ATM-LSR) in 162 their forwarding plane, generalized MPLS includes support for LSRs 163 that can't recognize (IP) packet boundaries in their forwarding 164 plane. In traditional MPLS TE an LSP that carries IP has to start 165 and end on a router. Generalized MPLS extends this by requiring an 166 LSP to start and end on similar type of LSRs. Also, in generalized 167 MPLS the type of a payload that can be carried by an LSP is extended 168 to allow such payloads as SONET/SDH, or 1 or 10Gb Ethernet. These 169 changes from traditional MPLS are reflected in how labels are 170 requested and communicated in generalized MPLS, see Sections 3.1 and 171 3.2. A special case of Lambda switching, called Waveband switching 172 is also described in Section 3.3. 174 Another basic difference between traditional and non-PSC types of 175 generalized MPLS LSPs, is that bandwidth allocation for an LSP can be 176 performed only in discrete units, see Section 3.1.3. There are also 177 likely to be (much) fewer labels on non-PSC links than on PSC links. 178 Note that the use of Forwarding Adjacencies (FA), see [MPLS- 179 HIERARCHY], provides a mechanism that may improve bandwidth 180 utilization, when bandwidth allocation can be performed only in 181 discrete units, as well as a mechanism to aggregate forwarding state, 182 thus allowing the number of required labels to be reduced. 184 Generalized MPLS allows for a label to be suggested by an upstream 185 node, see Section 3.4. This suggestion may be overridden by a 186 downstream node but, in some cases, at the cost of higher LSP setup 187 time. The suggested label is valuable when establishing LSPs through 188 certain kinds of optical equipment where there may be a lengthy (in 189 electrical terms) delay in configuring the switching fabric. For 190 example micro mirrors may have to be elevated or moved, and this 191 physical motion and subsequent damping takes time. If the labels and 192 hence switching fabric are configured in the reverse direction (the 193 norm) the MAPPING/Resv message may need to be delayed by 10's of 194 milliseconds per hop in order to establish a usable forwarding path. 196 Generalized MPLS extends on the notion of restricting the range of 197 labels that may be selected by a downstream node, see Section 3.5. 198 In generalized MPLS, an ingress or other upstream node may restrict 199 the labels that may be used by an LSP along either a single hop or 200 along the whole LSP path. This feature is driven from the optical 201 domain where there are cases where wavelengths used by the path must 202 be restricted either to a small subset of possible wavelengths, or to 203 one specific wavelength. This requirement occurs because some 204 equipment may only be able to generate a small set of the wavelengths 205 that intermediate equipment may be able to switch, or because 206 intermediate equipment may not be able to switch a wavelength at all, 207 being only able to redirect it to a different fiber. 209 While traditional traffic engineered MPLS (and even LDP) are 210 unidirectional, generalized MPLS supports the establishment of 211 bidirectional LSPs, see Section 4. The need for bidirectional LSPs 212 comes from non-PSC applications. There are multiple reasons why such 213 LSPs are needed, particularly possible resource contention when 214 allocating reciprocal LSPs via separate signaling sessions, and 215 simplifying failure restoration procedures in the non-PSC case. 216 Bidirectional LSPs also have the benefit of lower setup latency and 217 lower number of messages required during setup. 219 Generalized MPLS also supports the termination of an LSP on a 220 specific egress port, see Section 5. [GMPLS-RSVP] also supports an 221 RSVP specific mechanism for rapid failure notification. 223 3. Label Related Formats 225 To deal with the widening scope of MPLS into the optical and time 226 domain, several new forms of "label" are required. These new forms 227 of label are collectively referred to as a "generalized label". A 228 generalized label contains enough information to allow the receiving 229 node to program its cross connect, regardless of the type of this 230 cross connect, such that the ingress segments of the path are 231 properly joined. This section defines a generalized label request, a 232 generalized label, support for waveband switching, suggested label 233 and label sets. 235 Note that since the nodes sending and receiving the new form of label 236 know what kinds of link they are using, the generalized label does 237 not contain a type field, instead the nodes are expected to know from 238 context what type of label to expect. 240 3.1. Generalized Label Request 242 The Generalized Label Request supports communication of 243 characteristics required to support the LSP being requested. These 244 characteristics include desired link protection, LSP encoding, and 245 LSP payload. 247 The Generalized Label Request indicates the link protection type 248 desired for the LSP. If a particular protection type, i.e., 1+1, or 249 1:N, is requested, then a connection request is processed only if the 250 desired protection type can be honored. Note that the protection 251 capabilities of a link may be advertised in routing, see [GMPLS-ISIS, 252 GMPLS-OSPF]. Path computation algorithms may take this information 253 into account when computing paths for setting up LSPs. 255 The Generalized Label Request also carries an LSP encoding parameter, 256 called LSP Encoding Type. This parameter indicates the encoding 257 type, e.g., SONET/SDH/GigE etc., that will be used with the data 258 associated with the LSP. The LSP Encoding Type represents the nature 259 of the LSP, and not the nature of the links that the LSP traverses. 260 A link may support a set of encoding formats, where support means 261 that a link is able to carry and switch a signal of one or more of 262 these encoding formats depending on the resource availability and 263 capacity of the link. For example, consider an LSP signaled with 264 "photonic" encoding. It is expected that such an LSP would be 265 supported with no electrical conversion and no knowledge of the 266 modulation and speed by the transit nodes. All other formats require 267 framing knowledge, and field parameters are broken into the framing 268 type and speed as shown below. 270 3.1.1. Generalized Label Request Information 272 The information carried in a Generalized Label Request is: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | LSP Enc. Type |Link Prot.Flags| G-PID | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 LSP Encoding Type: 8 bits 282 Indicates the encoding of the LSP being requested. The 283 following shows permitted values and their meaning: 285 Value Type 286 ----- ---- 287 1 Packet 288 2 Ethernet 289 3 ANSI PDH 290 4 ETSI PDH 291 5 SDH 292 6 SONET 293 7 Digital Wrapper 294 8 Lambda (photonic) 295 9 Fiber 297 The ANSI PDH and ETSI PDH types designate these respective 298 networking technologies. DS1 and DS3 are examples of ANSI PDH 299 LSPs. An E1 LSP would be ETSI PDH. The Lambda encoding type 300 refers to the switching of wavelengths. The Fiber encoding 301 type refers to switching at the fiber port level. 303 Link Protection Flags: 8 bits 305 Link Protection Flags indicate the desired protection level(s) 306 for each link along the LSP. Note that the flags are distinct 307 from MPLS-level LSP protection, see [RECOVERY]. A value of 0 308 implies that this connection does not care about which, if any, 309 link protection is used. More than one bit may be set to 310 indicate when multiple protection types are acceptable. When 311 multiple bits are set and multiple protection types are 312 available, the choice of protection type is a local (policy) 313 decision. 315 The following flags are defined: 317 0x01 Unprotected 319 Indicates that the LSP should not use any link layer 320 protection. 322 0x02 Shared 324 Indicates that a shared link layer protection scheme, 325 such as 1:N protection, should be used to support the 326 LSP. 328 0x04 Dedicated 1:1 330 Indicates that a dedicated link layer protection scheme, 331 i.e., 1:1 protection, should be used to support the LSP. 333 0x08 Dedicated 1+1 335 Indicates that a dedicated link layer protection scheme, 336 i.e., 1+1 protection, should be used to support the LSP. 338 0x10 Enhanced 340 Indicates that a protection scheme that is more reliable 341 than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS- 342 SPRING. 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 must be 348 interpreted according to the technology encoding type of the 349 LSP and is used by the nodes at the endpoints of the LSP. 350 Standard Ethertype values are used for packet and Ethernet 351 LSPs; other values are: 353 Value Type Technology 354 ----- ---- ---------- 355 0 Unknown All 356 1 DS1 SF ANSI-PDH 357 2 DS1 ESF ANSI-PDH 358 3 DS3 M23 ANSI-PDH 359 4 DS3 C-Bit Parity ANSI-PDH 360 5 Asynchronous mapping of E4 SDH 361 6 Asynchronous mapping of DS3/T3 SDH 362 7 Asynchronous mapping of E3 SDH 363 8 Bit synchronous mapping of E3 SDH 364 9 Byte synchronous mapping of E3 SDH 365 10 Asynchronous mapping of DS2/T2 SDH 366 11 Bit synchronous mapping of DS2/T2 SDH 367 12 Byte synchronous mapping of DS2/T2 SDH 368 13 Asynchronous mapping of E1 SDH 369 14 Byte synchronous mapping of E1 SDH 370 15 Byte synchronous mapping of 31 * DS0 SDH 371 16 Asynchronous mapping of DS1/T1 SDH 372 17 Bit synchronous mapping of DS1/T1 SDH 373 18 Byte synchronous mapping of DS1/T1 SDH 374 19 Same as 12 but in a VC-12 SDH 375 20 Same as 13 but in a VC-12 SDH 376 21 Same as 14 but in a VC-12 SDH 377 22 ATM mapping SDH, SONET 378 22 DS1 SF Asynchronous SONET 379 23 DS1 ESF Asynchronous SONET 380 24 DS3 M23 Asynchronous SONET 381 25 DS3 C-Bit Parity Asynchronous SONET 382 26 VT SONET 383 27 POS SONET 384 28 STS SONET 385 29 Ethernet Lambda, Fiber 386 30 SDH Lambda, Fiber 387 31 SONET Lambda, Fiber 388 32 Digital Wrapper Lambda, Fiber 389 33 Lambda Fiber 391 3.1.2. Generalized Label Request with SONET/SDH Label Range 393 The Generalized Label Request with SONET/SDH Label Range object/TLV 394 is used to represent specific characteristics related to the two TDM 395 technologies. If the RGT, RT, and RNC, fields are all set to zero, it 396 means that no concatenation, bundling or transparency is requested. 397 If the requested LSP is itself a grouping of several components (e.g. 398 a SONET concatenation), it is assumed that all components have the 399 same characteristics. Note that the bandwidth carried in the 400 signaling messages, see Section 3.1.4, are the aggregate bandwidth; 401 in the instance where multiple components are signaled for, the 402 individual component bandwidth is obtained by dividing this 403 aggregated value by the requested number of components. 405 The information carried in a Generalized Label Request with SONET/SDH 406 Label Range is: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | LSP Enc. Type |Link Prot.Flags| G-PID | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | RGT | RT | Reserved | RNC | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 LSP Encoding Type: 8 bits 418 See Section 3.1.1. 420 Link Protection Flags: 8 bits 422 See Section 3.1.1. 424 Generalized PID (G-PID): 16 bits 426 See Section 3.1.1. 428 Requested Grouping Type (RGT): 4 bits 430 This field indicates the SDH/SONET type of grouping requested 431 for the LSP, it is used to constraint the type of 432 concatenation. The values are defined in the following table: 434 Value Grouping type 435 ----- ---------------------------------- 436 0 (Implies no concatenation/bundling when RNC = RT = 0) 437 1 Virtual concatenation 438 2 Contiguous standard concatenation 439 3 Contiguous arbitrary concatenation 440 4 Bundle (group of individual signals) 442 Requested Transparency (RT): 4 bits 444 This field indicates the type of SDH/SONET transparency 445 ("emulation") requested for that LSP. The values are defined in 446 the following table: 448 Value Requested transparency 449 ----- ---------------------------------------------- 450 0 (Implies no concatenation/bundling when RNC = RGT = 0) 451 1 SDH Regenerator Section/SONET Section transparency 452 2 SDH Multiplex Section/SONET Line transparency 453 3 SDH Path/SONET Path transparency 455 Requested Number of Components (RNC): 16 bits 457 This field indicates the number of identical SDH/SONET signal 458 types that are requested to be concatenated or inverse 459 multiplexed in that LSP, as specified in the previous field. In 460 these cases, the bandwidth of each component of that 461 concatenation/bundling is obtained by dividing the aggregate 462 bandwidth by the number of components requested. It is assumed 463 that all these components have identical characteristics. This 464 field is set to zero if non concatenation or bundling is 465 requested. 467 3.1.3. Bandwidth Encoding 469 Bandwidth encodings are carried in in 32 bit number in IEEE floating 470 point format (the unit is bytes per second). For non-packet LSPs, it 471 is useful to define discrete values to identify the bandwidth of the 472 LSP. Some typical values for the requested bandwidth are enumerated 473 below. Additional values will be defined as needed. Bandwidth 474 encoding values are carried in a per protocol specific manner, see 476 [GMPLS-RSVP] and [GMPLS-LDP]. 478 Signal Type (Bit-rate) Value (Bytes/Sec) 479 (IEEE Floating point) 480 ----------- ----------- ------------ 481 DS0 (0.064 Mbps) 0x45FA0000 482 DS1 (1.544 Mbps) 0x483C7A00 483 E1 (2.048 Mbps) 0x487A0000 484 DS2 (6.312 Mbps) 0x4940A080 485 E2 (8.448 Mbps) 0x4980E800 486 Ethernet (10.00 Mbps) 0x49989680 487 E3 (34.368 Mbps) 0x4A831A80 488 DS3 (44.736 Mbps) 0x4AAAA780 489 STS-1 (51.84 Mbps) 0x4AC5C100 490 Fast Ethernet (100.00 Mbps) 0x4B3EBC20 491 E4 (139.264 Mbps) 0x4B84D000 492 OC-3/STM-1 (155.52 Mbps) 0x4B9450C0 493 OC-12/STM-4 (622.08 Mbps) 0x4C9450C0 494 GigE (1000.00 Mbps) 0x4CEE6B28 495 OC-48 (2488.32 Mbps) 0x4D9450C0 496 OC-192 (9953.28 Mbps) 0x4E9450C0 497 10GigE-LAN (10000.00 Mbps) 0x4E9502F9 499 3.2. Generalized Label 501 The Generalized Label extends the traditional label by allowing the 502 representation of not only labels which travel in-band with 503 associated data packets, but also labels which identify time-slots, 504 wavelengths, or space division multiplexed positions. For example, 505 the Generalized Label may carry a label that represents (a) a single 506 fiber in a bundle, (b) a single waveband within fiber, (c) a single 507 wavelength within a waveband (or fiber), or (d) a set of time-slots 508 within a wavelength (or fiber). It may also carry a label that 509 represents a generic MPLS label, a Frame Relay label, or an ATM label 510 (VCI/VPI). 512 A Generalized Label does not identify the "class" to which the label 513 belongs. This is implicit in the multiplexing capabilities of the 514 link on which the label is used. 516 A Generalized Label only carries a single level of label, i.e., it is 517 non-hierarchical. When multiple levels of label (LSPs within LSPs) 518 are required, each LSP must be established separately, see [MPLS- 519 HIERARCHY]. 521 Each Generalized Label object carries a variable length label 522 parameter. 524 3.2.1. Required Information 526 The information carried in a Generalized Label is: 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Label | 532 | ... | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Label: Variable 537 Carries label information. The semantics of this field depends 538 on the type of the link over which the label is used. 540 3.2.1.1. SDH and SONET Labels 542 SDH and SONET each define a multiplexing structure. These two 543 structures are trees whose roots are respectively an STM-N or an STS- 544 N; and whose leaves are the signals (time-slots) that can be 545 transported and switched, i.e. a VC-x or a VT-x. A label will 546 identify the type of a particular signal and its exact position in a 547 multiplexing structure (both are related). 549 These multiplexing structures will be used as naming trees to create 550 unique multiplex entry names or labels. Since the SONET multiplexing 551 structure may be seen as a subset of the SDH multiplexing structure, 552 the same format of label is used for SDH and SONET. As explained 553 before (section 3.2), a label does not identify the "class" to which 554 the label belongs. This is implicitly determined by the link on which 555 the label is used. However, the encoding specified hereafter makes 556 the direct distinction between SDH and SONET. 558 In case of signal concatenation or bundling, a list of labels may 559 appear in the Label field of a Generalized Label. 561 In case of virtual concatenation, the explicit list of all signals in 562 the concatenation is given. The signals identified by these labels 563 are virtually concatenated to form the SDH or SONET signal trail. The 564 above representation limits virtual concatenation to remain within a 565 single (component) link. 567 In case of any type of contiguous concatenation (e.g. standard or 568 arbitrary SONET concatenation), only one label appears in the Label 569 field. That label is the lowest signal of the contiguously 570 concatenated signal. The bandwidth of the LSP request indicates the 571 number of labels to be concatenated to form the SDH or SONET signal 572 trail. By lowest signal we mean the one having the lowest label when 573 compared as integer values, i.e. the first component signal of the 574 concatenated signal encountered when descending the tree. 576 In case of bundling, the explicit list of all signals that take part 577 in the bundling is given. An example of bundling is inverse 578 multiplexing, it is useful when a higher order signal needs to be 579 transported over a number of lower order signals, e.g. when a 10Gbps 580 signal must be transported over four 2.5Gbps signals. In that case, 581 the lower order signals must follow exactly the same path, and be 582 treated in the same way, in order to achieve the same characteristics 583 (e.g. delay). To support inverse multiplexing, a request is made to 584 open in parallel and in one single operation several LSPs at the same 585 time. 587 The format of the label for SDH and/or SONET TDM-LSR link is: 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | S | U | K | L | M | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 For SDH, this is an extension of the numbering scheme defined in 596 G.707 section 7.3, i.e. the (K, L, M) numbering. For SONET, the U and 597 K fields are not significant and must be set to zero. Only the S, L 598 and M fields are significant for SONET and have a similar meaning as 599 for SDH. 601 Each letter indicates a possible branch number starting at the parent 602 node in the multiplex structure. Branches are considered as numbered 603 in increasing order, starting from the top of the multiplexing 604 structure. The numbering starts at 1, zero is used to indicate a non- 605 significant field. 607 When a field is not significant in a particular context it MUST be 608 set to zero when transmitted, and MUST be ignored when received. This 609 simple rule allows distinguishing very easily between an SDH label 610 and an SONET label. A label with U=0 will always indicate a SONET 611 label. This is a nice feature for debugging purposes. Note that it is 612 easier to test U and K together, rather than only the U field alone, 613 since they fit exactly in the third octet of the label. 615 1. S is the index of a particular STM-1/STS-1 signal. S=1->N 616 indicates a specific STM-1/STS-1 inside an STM-N/STS-N 617 multiplex. For example, S=1 indicates the first STM-1/STS-1, 618 and S=N indicates the last STM-1/STS-1 of this multiplex. S=0 619 is invalid. 621 2. U is only significant for SDH and must be ignored for SONET. It 622 indicates a specific VC inside a given STM-1. U=1 indicates a 623 single VC-4, while U=2->4 indicates a specific VC-3 inside the 624 given STM-1. 626 3. K is only significant for SDH and must be ignored for SONET. It 627 indicates a specific branch of a VC-4. K=1 indicates that the 628 VC-4 is not further sub- divided and contains a C-4. K=2->4 629 indicates a specific TUG-3 inside the VC-4. K is not 630 significant when the STM-1 is divided into VC-3s (easy to read 631 and test). 633 4. L indicates a specific branch of a TUG-3, VC-3 or STS-1 SPE. It 634 is not significant for an unstructured VC-4. L=1 indicates that 635 the TUG-3/VC-3/STS-1 SPE is not further sub-divided and 636 contains a VC-3/C-3 in SDH or the equivalent in SONET. L=2->8 637 indicates a specific TUG-2/VT Group inside the corresponding 638 higher order signal. 640 5. M indicates a specific branch of a TUG-2/VT Group. It is not 641 significant for an unstructured VC-4, TUG-3, VC-3 or STS-1 642 SPE. M=1 indicates that the TUG-2/VT Group is not further 643 sub-divided and contains a VC-2/VT-6. M=2->3 indicates a 644 specific VT-3 inside the corresponding VT Group, these values 645 MUST NOT be used for SDH since there is no equivalent of VT-3 646 with SDH. M=4->6 indicates a specific VC-12/VT-2 inside the 647 corresponding TUG-2/VT Group. M=7->10 indicates a specific 648 VC-11/VT-1.5 inside the corresponding TUG-2/VT Group. Note that 649 M=0 denotes an unstructured VC-4, VC-3 or STS-1 SPE (easy for 650 debugging). 652 The M encoding is summarized in the following table: 654 M SDH SONET 655 ---------------------------------------------------------- 656 0 unstructured VC-4/VC-3 unstructured STS-1 SPE 657 1 VC-2 VT-6 658 2 - 1st VT-3 659 3 - 2nd VT-3 660 4 1st VC-12 1st VT-2 661 5 2nd VC-12 2nd VT-2 662 6 3rd VC-12 3rd VT-2 663 7 1st VC-11 1st VT-1.5 664 8 2nd VC-11 2nd VT-1.5 665 9 3rd VC-11 3rd VT-1.5 666 10 4th VC-11 4th VT-1.5 668 For instance, 670 Example 1: S>0, U=1, K=1, L=0, M=0 671 Denotes the unstructured VC-4 of the Sth STM-1. 673 Example 2: S>0, U=1, K>1, L=1, M=0 674 Denotes the unstructured VC-3 of the Kth-1 TUG-3 of the Sth STM-1. 676 Example 3: S>0, U=0, K=0, L=0, M=0) 677 Denotes the unstructured STS-1 SPE of the Sth STS-1. 679 Example 4: S>0, U=0, K=0, L>1, M=1 680 Denotes the VT-6 in the Lth-1 VT Group in the Sth STS-1. 682 Example 5: S>0, U=0, K=0, L>1, M=9 683 Denotes the 3rd VT-1.5 in the Lth-1 VT Group in the Sth STS-1. 685 3.2.1.2. Port and Wavelength Labels 687 Some configurations of fiber switching (FSC) and lambda switching 688 (LSC) use multiple data channels/links controlled by a single control 689 channel. In such cases the label indicates the data channel/link to 690 be used for the LSP. Note that this case is not the same as when 691 [MPLS-BUNDLING] is being used. 693 The information carried in a Port and Wavelength label is: 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Label | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Label: 32 bits 703 Indicates port/fiber or lambda to be used, from the sender's 704 perspective. Values used in this field only have significance 705 between two neighbors, and the receiver may need to convert the 706 received value into a value that has local significance. 707 Values may be configured or dynamically determined using a 708 protocol such as [LMP]. 710 3.2.1.3. Other Labels 712 Generic MPLS labels and Frame Relay labels are encoded right 713 justified aligned in 32 bits (4 octets). ATM labels are encoded with 714 the VPI right justified in bits 0-15 and the VCI right justified in 715 bits 16-31. 717 3.3. Waveband Switching 719 A special case of lambda switching is waveband switching. A waveband 720 represents a set of contiguous wavelengths which can be switched 721 together to a new waveband. For optimization reasons it may be 722 desirable for an optical cross connect to optically switch multiple 723 wavelengths as a unit. This may reduce the distortion on the 724 individual wavelengths and may allow tighter separation of the 725 individual wavelengths. The Waveband Label is defined to support 726 this special case. 728 Waveband switching naturally introduces another level of label 729 hierarchy and as such the waveband is treated the same way all other 730 upper layer labels are treated. 732 As far as the MPLS protocols are concerned there is little difference 733 between a waveband label and a wavelength label except that 734 semantically the waveband can be subdivided into wavelengths whereas 735 the wavelength can only be subdivided into time or statistically 736 multiplexed labels. 738 3.3.1. Required information 740 Waveband switching uses the same format as the generalized label, see 741 section 3.2.1. 743 In the context of waveband switching, the generalized label has the 744 following format: 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Waveband Id | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Start Label | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | End Label | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Waveband Id: 32 bits 757 A waveband identifier. The value is selected by the sender and 758 reused in all subsequent related messages. 760 Start Label: 32 bits 762 Indicates the channel identifier, from the sender's 763 perspective, of the lowest value wavelength making up the 764 waveband. 766 End Label: 32 bits 768 Indicates the channel identifier, from the sender's 769 perspective, of the highest value wavelength making up the 770 waveband. 772 Channel identifiers are established either by configuration or by 773 means of a protocol such as LMP [LMP]. They are normally used in the 774 label parameter of the Generalized Label one PSC and LSC. 776 3.4. Suggested Label 778 The Suggested Label is used to provide a downstream node with the 779 upstream node's label preference. This permits the upstream node to 780 start configuring it's hardware with the proposed label before the 781 label is communicated by the downstream node. Such early 782 configuration is valuable to systems that take non-trivial time to 783 establish a label in hardware. Such early configuration can reduce 784 setup latency, and may be important for restoration purposes where 785 alternate LSPs may need to be rapidly established as a result of 786 network failures. 788 The use of Suggested Label is only an optimization. If a downstream 789 node passes a different label upstream, an upstream LSR MUST 790 reconfigure itself so that it uses the label specified by the 791 downstream node, thereby maintaining the downstream control of a 792 label. 794 The information carried in a suggested label is identical to a 795 generalized label. 797 3.5. Label Set 799 The Label Set is used to limit the label choices of a downstream node 800 to a set of acceptable labels. This limitation applies on a per hop 801 basis. 803 There are four cases where a Label Set is useful in the optical 804 domain. The first case is where the end equipment is only capable of 805 transmitting and receiving on a small specific set of 806 wavelengths/bands. The second case is where there is a sequence of 807 interfaces which cannot support wavelength conversion (CI-incapable) 808 and require the same wavelength be used end-to-end over a sequence of 809 hops, or even an entire path. The third case is where it is 810 desirable to limit the amount of wavelength conversion being 811 performed to reduce the distortion on the optical signals. The last 812 case is where two ends of a link support different sets of 813 wavelengths. 815 Label Set is used to restrict label ranges that may be used for a 816 particular LSP between two peers. The receiver of a Label Set must 817 restrict its choice of labels to one which is in the Label Set. Much 818 like a label, a Label Set may be present across multiple hops. In 819 this case each node generates it's own outgoing Label Set, possibly 820 based on the incoming Label Set and the node's hardware capabilities. 821 This case is expected to be the norm for nodes with conversion 822 incapable (CI-incapable) interfaces. 824 The use of Label Set is optional, if not present, all labels from the 825 valid label range may be used. Conceptually the absence of a Label 826 Set implies a Label Set whose value is {U}, the set of all valid 827 labels. 829 3.5.1. Required Information 831 A label set is composed of one or more Label_Set objects/TLVs. Each 832 object/TLV contains one or more elements of the Label Set. Each 833 element is referred to as a subchannel identifier and has the same 834 format as a label. 836 The information carried in a Label_Set is: 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Reserved | Label Type | Action | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Subchannel 1 | 844 | ... | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 : : : 847 : : : 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Subchannel N | 850 | ... | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 Label Type: 8 bits 855 Indicates the type and format of the labels carried in the 856 object/TLV. Values are signaling protocol specific. 858 Action: 8 bits 860 0 - Inclusive List 862 Indicates that the object/TLV contains one or more 863 subchannel elements that are included in the Label Set. 865 1 - Exclusive List 867 Indicates that the object/TLV contains one or more 868 subchannel elements that are excluded from the Label Set. 870 2 - Inclusive Range 872 Indicates that the object/TLV contains a range of labels. 873 The object/TLV contains two subchannel elements. The first 874 element indicates the start of the range. The second 875 element indicates the end of the range. A value of zero 876 indicates that there is no bound on the corresponding 877 portion of the range. 879 3 - Exclusive Range 881 Indicates that the object/TLV contains a range of labels 882 that are excluded from the Label Set. The object/TLV 883 contains two subchannel elements. The first element 884 indicates the start of the range. The second element 885 indicates the end of the range. A value of zero indicates 886 that there is no bound on the corresponding portion of the 887 range. 889 Subchannel: 891 The subchannel represents the label (wavelength, fiber ... ) 892 which is eligible for allocation. This field has the same 893 format as described for labels under section 3.2. 895 Note that subchannel to local channel identifiers (e.g., 896 wavelength) mappings are a local matter. 898 4. Bidirectional LSPs 900 This section defines direct support of bidirectional LSPs. Support 901 is defined for LSPs that have the same traffic engineering 902 requirements including fate sharing, protection and restoration, 903 LSRs, and resource requirements (e.g., latency and jitter) in each 904 direction. In the remainder of this section, the term "initiator" is 905 used to refer to a node that starts the establishment of an LSP and 906 the term "terminator" is used to refer to the node that is the target 907 of the LSP. Note that for bidirectional LSPs, there is only one 908 "initiator" and one "terminator". 910 Normally to establish a bidirectional LSP when using [RSVP-TE] or 911 [CR-LDP] two unidirectional paths must be independently established. 912 This approach has the following disadvantages: 914 * The latency to establish the bidirectional LSP is equal to one 915 round trip signaling time plus one initiator-terminator signaling 916 transit delay. This not only extends the setup latency for 917 successful LSP establishment, but it extends the worst-case 918 latency for discovering an unsuccessful LSP to as much as two 919 times the initiator-terminator transit delay. These delays are 920 particularly significant for LSPs that are established for 921 restoration purposes. 923 * The control overhead is twice that of a unidirectional LSP. 924 This is because separate control messages (e.g. Path and Resv) 925 must be generated for both segments of the bidirectional LSP. 927 * Because the resources are established in separate segments, 928 route selection is complicated. There is also additional 929 potential race for conditions in assignment of resources, which 930 decreases the overall probability of successfully establishing 931 the bidirectional connection. 933 * It is more difficult to provide a clean interface for SONET 934 equipment that may rely on bidirectional hop-by-hop paths for 935 protection switching. Note that existing SONET gear transmits 936 the control information in-band with the data. 938 * Bidirectional optical LSPs (or lightpaths) are seen as a 939 requirement for many optical networking service providers. 941 With bidirectional LSPs both the downstream and upstream data paths, 942 i.e., from initiator to terminator and terminator to initiator, are 943 established using a single set of signaling messages. This reduces 944 the setup latency to essentially one initiator-terminator round trip 945 time plus processing time, and limits the control overhead to the 946 same number of messages as a unidirectional LSP. 948 4.1. Required Information 950 For bidirectional LSPs, two labels must be allocated. Bidirectional 951 LSP setup is indicated by the presence of an Upstream Label 952 object/TLV in the appropriate signaling message. An Upstream Label 953 has the same format as the generalized label, see Section 3.2. 955 4.2. Contention Resolution 957 Contention for labels may occur between two bidirectional LSP setup 958 requests traveling in opposite directions. This contention occurs 959 when both sides allocate the same resources (ports) at effectively 960 the same time. If there is no restriction on the ports that can be 961 used for bidirectional LSPs and if there are alternate resources, 962 then both nodes will pass different labels upstream and the 963 contention will be resolved naturally. However, if there is a 964 restriction on the ports that can be used for the bidirectional LSPs 965 (for example, if they must be physically coupled on a single I/O 966 card), or if there are no more resources available, then the 967 contention must be resolved by other means. To resolve contention, 968 the node with the higher node ID will win the contention and it MUST 969 issue a PathErr/NOTIFICATION message with a "Routing problem/Label 970 allocation failure" indication. Upon receipt of such an error, the 971 node SHOULD try to allocate a different Upstream label (and a 972 different Suggested Label if used) to the bidirectional path. 973 However, if no other resources are available, the node must proceed 974 with standard error handling. 976 To reduce the probability of contention, one may impose a policy that 977 the node with the lower ID never suggests a label in the downstream 978 direction and always accepts a Suggested Label from an upstream node 979 with a higher ID. Furthermore, since the label sets are exchanged 980 using LMP [LMP], an alternative local policy could further be imposed 981 such that (with respect to the higher numbered node's label set) the 982 higher numbered node could allocate labels from the high end of the 983 label range while the lower numbered node allocates labels from the 984 low end of the label range. This mechanism would augment any close 985 packing algorithms that may be used for bandwidth (or wavelength) 986 optimization. One special case that should be noted when using RSVP 987 and supporting this approach is that the neighbor's node ID might not 988 be known when sending an initial Path message. When this case 989 occurs, a node should suggest a label choosen at random from the 990 available label space. 992 An example of contention between two nodes (PXC 1 and PXC 2) is shown 993 in Figure 1. In this example PXC 1 assigns an Upstream Label for the 994 channel corresponding to local BCId=2 (local BCId=7 on PXC 2) and 995 sends a Suggested Label for the channel corresponding to local BCId=1 996 (local BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream 997 Label for the channel corresponding to its local BCId=6 (local BCId=1 998 on PXC 1) and sends a Suggested Label for the channel corresponding 999 to its local BCId=7 (local BCId=2 on PXC 1). If there is no 1000 restriction on the ports that can be used for bidirectional LSPs and 1001 if there are alternate resources available, then both PXC 1 and PXC 2 1002 will pass different labels upstream and the contention is resolved 1003 naturally (see Fig. 2). However, if there is a restriction on the 1004 ports that can be used for bidirectional LSPs (for example, if they 1005 must be physically coupled on a single I/O card), then the contention 1006 must be resolved using the router Id (see Fig. 3). 1008 +------------+ +------------+ 1009 + PXC 1 + + PXC 2 + 1010 + + SL1,UL2 + + 1011 + 1 +------------------------>+ 6 + 1012 + + UL1, SL2 + + 1013 + 2 +<------------------------+ 7 + 1014 + + + + 1015 + + + + 1016 + 3 +------------------------>+ 8 + 1017 + + + + 1018 + 4 +<------------------------+ 9 + 1019 +------------+ +------------+ 1020 Figure 1. Label Contention 1022 In this example, PXC 1 assigns an Upstream Label using BCId=2 (BCId=7 1023 on PXC 2) and a Suggested Label using BCId=1 (BCId=6 on PXC 2). 1024 Simultaneously, PXC 2 assigns an Upstream Label using BCId=6 (BCId=1 1025 on PXC 1) and a Suggested Label using BCId=7 (BCId=2 on PXC 1). 1027 +------------+ +------------+ 1028 + PXC 1 + + PXC 2 + 1029 + + UL2 + + 1030 + 1 +------------------------>+ 6 + 1031 + + UL1 + + 1032 + 2 +<------------------------+ 7 + 1033 + + + + 1034 + + L1 + + 1035 + 3 +------------------------>+ 8 + 1036 + + L2 + + 1037 + 4 +<------------------------+ 9 + 1038 +------------+ +------------+ 1039 Figure 2. Label Contention Resolution without resource restrictions 1041 In this example, there is no restriction on the ports that can be 1042 used by the bidirectional connection and contention is resolved 1043 naturally. 1045 +------------+ +------------+ 1046 + PXC 1 + + PXC 2 + 1047 + + UL2 + + 1048 + 1 +------------------------>+ 6 + 1049 + + L2 + + 1050 + 2 +<------------------------+ 7 + 1051 + + + + 1052 + + L1 + + 1053 + 3 +------------------------>+ 8 + 1054 + + UL1 + + 1055 + 4 +<------------------------+ 9 + 1056 +------------+ +------------+ 1057 Figure 3. Label Contention Resolution with resource restrictions 1059 In this example, ports 1,2 and 3,4 on PXC 1 (ports 6,7 and 8,9 on PXC 1060 2, respectively) must be used by the same bidirectional connection. 1061 Since PXC 2 has a higher node ID, it wins the contention and PXC 1 1062 must use a different set of labels. 1064 5. Explicit Label Control 1066 The LSR at the initiator of an LSP can control nodes used by an LSP 1067 and the termination of the LSP by using an explicit route, i.e., ERO 1068 or ER-Hop. To require the usage of a particular node, that node is 1069 included in the explicit route. To terminate an LSP on a particular 1070 outgoing interface of the egress LSR, the head-end may specify the IP 1071 address or the interface identifier [MPLS-UNNUM] of that interface as 1072 the last element in the explicit route, provided that that interface 1073 has an associated IP address. 1075 There are cases where the existing explicit route semantics do not 1076 provide enough information to control the LSP to the degree desired. 1077 This occurs in the case when the LSP initiator wishes to select a 1078 label used on a link. An example of this is when it is desirable to 1079 "splice" two LSPs together, i.e., where the tail of the first LSP 1080 would be "spliced" into the head of the second LSP. This last case 1081 is more likely to be used in the non-PSC classes of links. 1083 To to cover this case, the Label ERO subobject / ER Hop is 1084 introduced. 1086 5.1. Required Information 1088 The Label Explicit Route contains: 1090 L: 1 bit 1092 This bit must be set to 0. 1094 U: 1 bit 1096 This bit indicates the direction of the label. It is 0 for the 1097 downstream label. It is set to 1 for the upstream label and is 1098 only used on bidirectional LSPs. 1100 Label: Variable 1102 This field identifies the label to be used. The format of this 1103 field is identical to the one used by the Label field in 1104 Generalized Label, see Section 3.2.1. 1106 Placement and ordering of these parameters are signaling protocol 1107 specific. 1109 6. Acknowledgments 1111 This draft is the work of numerous authors and consists of a 1112 composition of a number of previous drafts in this area. A list of 1113 the drafts from which material and ideas were incorporated follows: 1115 draft-saha-rsvp-optical-signaling-00.txt 1116 draft-lang-mpls-rsvp-oxc-00.txt 1117 draft-kompella-mpls-optical-00.txt 1118 draft-fan-mpls-lambda-signaling-00.txt 1120 Valuable comments and input were received from a number of people, 1121 including Igor Bryskin and Adrian Farrel. 1123 7. Security Considerations 1125 This draft introduce no new security considerations to either [CR- 1126 LDP] or [RSVP-TE]. 1128 8. References 1130 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 1131 draft-ietf-mpls-cr-ldp-04.txt, July, 2000. 1133 [LDP] Andersson et al., "LDP Specification", 1134 draft-ietf-mpls-ldp-11.txt, August 2000. 1136 [LMP] Lang, J.P., Mitra, K., Drake, J., Kompella, K., Rekhter, Y., 1137 Saha, D., Berger, L., Basak, D., "Link Management Protocol", 1138 Internet Draft, draft-lang-mpls-lmp-01.txt, July 2000. 1140 [MPLS-ARCH] Rosen et al., "Multiprotocol label switching 1141 Architecture", Internet Draft, 1142 draft-ietf-mpls-arch-06.txt, August 1999. 1144 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling 1145 in MPLS Traffic Engineering", Internet Draft, 1146 draft-kompella-mpls-bundle-02.txt, July 2000. 1148 [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 1149 MPLS TE", Internet Draft, 1150 draft-ietf-mpls-lsp-hierarchy-00.txt, July 2000. 1152 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., 1153 Bernstein, G., Fedyk, D., Mannie, E., Saha, D., and 1154 Sharma, V., "IS-IS Extensions in Support of Generalized 1155 MPLS", Internet Draft, 1156 draft-ietf-isis-gmpls-extensions-00.txt, July 2000. 1157 [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - 1158 CR-LDP Extensions", Internet Draft, 1159 draft-ietf-mpls-generalized-cr-ldp-00.txt, 1160 November 2000. 1162 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., 1163 Bernstein, G., Fedyk, D., Mannie, E., Saha, D., and 1164 Sharma, V., "OSPF Extensions in Support of MPLambdaS", 1165 Internet Draft, draft-ompls-ospf-extensions-00.txt, 1166 July 2000. 1168 [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - 1169 RSVP-TE Extensions", Internet Draft, 1170 draft-ietf-mpls-generalized-rsvp-te-00.txt, 1171 November 2000. 1173 [RSVP-TE] Awduche, D.O., Berger, L., Gan, D.-H., Li, T., Swallow, G., 1174 and Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP 1175 Tunnels," Internet Draft, 1176 draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, July 2000. 1178 [RECOVERY] Makam, et al "A Framework for MPLS-based Recovery," 1179 draft-ieft-mpls-recovery-frmwrk-00.txt, August 2000. 1181 9. Authors' Addresses 1183 Peter Ashwood-Smith 1184 Nortel Networks Corp. 1185 P.O. Box 3511 Station C, 1186 Ottawa, ON K1Y 4H7 1187 Canada 1188 Phone: +1 613 763 4534 1189 Email: petera@nortelnetworks.com 1191 Ayan Banerjee 1192 Calient Networks 1193 5853 Rue Ferrari 1194 San Jose, CA 95138 1195 Phone: +1 408 972-3645 1196 Email: abanerjee@calient.net 1198 Lou Berger 1199 Movaz Networks 1200 Phone: +1 301 468 9228 1201 Email: lberger@movaz.com 1203 Greg Bernstein 1204 Ciena Corporation 1205 10480 Ridgeview Court 1206 Cupertino, CA 94014 1207 Phone: +1 408 366 4713 1208 Email: greg@ciena.com 1209 John Drake 1210 Calient Networks 1211 5853 Rue Ferrari 1212 San Jose, CA 95138 1213 Phone: +1 408 972 3720 1214 Email: jdrake@calient.net 1216 Yanhe Fan 1217 Axiowave Networks, Inc. 1218 100 Nickerson Road 1219 Marlborough, MA 01752 1220 Phone: +1 508 460 6969 Ext. 627 1221 Email: yfan@axiowave.com 1223 Kireeti Kompella 1224 Juniper Networks, Inc. 1225 1194 N. Mathilda Ave. 1226 Sunnyvale, CA 94089 1227 Email: kireeti@juniper.net 1229 Jonathan P. Lang 1230 Calient Networks 1231 25 Castilian 1232 Goleta, CA 93117 1233 Email: jplang@calient.net 1235 Eric Mannie 1236 GTS 1237 Terhulpsesteenweg 6A 1238 1560 Hoeilaart - Belgium 1239 Phone: +32 2 658 56 52 1240 Mobile: +32 496 58 56 52 1241 Fax: +32 2 658 51 18 1242 Email: eric.mannie@gts.com 1244 Bala Rajagopalan 1245 Tellium, Inc. 1246 2 Crescent Place 1247 P.O. Box 901 1248 Oceanport, NJ 07757-0901 1249 Phone: +1 732 923 4237 1250 Fax: +1 732 923 9804 1251 Email: braja@tellium.com 1253 Yakov Rekhter 1254 cisco Systems 1255 Email: yakov@cisco.com 1256 Debanjan Saha 1257 Tellium Optical Systems 1258 2 Crescent Place 1259 Oceanport, NJ 07757-0901 1260 Phone: +1 732 923 4264 1261 Fax: +1 732 923 9804 1262 Email: dsaha@tellium.com 1264 Vishal Sharma 1265 Tellabs Research Center 1266 One Kendall Square 1267 Bldg. 100, Ste. 121 1268 Cambridge, MA 02139-1562 1269 Phone: +1 617 577 8760 1270 Email: Vishal.Sharma@tellabs.com 1272 George Swallow 1273 Cisco Systems, Inc. 1274 250 Apollo Drive 1275 Chelmsford, MA 01824 1276 Voice: +1 978 244 8143 1277 Email: swallow@cisco.com 1279 Z. Bo Tang 1280 Tellium, Inc. 1281 2 Crescent Place 1282 P.O. Box 901 1283 Oceanport, NJ 07757-0901 1284 Phone: +1 732 923 4231 1285 Fax: +1 732 923 9804 1286 Email: btang@tellium.com