idnits 2.17.1 draft-ashwood-generalized-mpls-signaling-00.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 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 292: '...REQUEST/Path message SHOULD contain as...' RFC 2119 keyword, line 391: '... Transit nodes MUST verify that the ...' RFC 2119 keyword, line 393: '... MUST generate a PathErr/NOTIFICATIO...' RFC 2119 keyword, line 396: '...and egress nodes MUST verify that the ...' RFC 2119 keyword, line 399: '... node MUST generate a PathErr/NOTIFI...' (22 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 584, but not defined == Missing Reference: 'RSVP' is mentioned on line 1150, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-04 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-08 == 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 -- No information found for draft-ompls-isis-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OMPLS-ISIS' -- No information found for draft-ompls-ospf-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OMPLS-OSPF' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-06 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-te-feed-00 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Peter Ashwood-Smith 2 Internet Draft Yanhe Fan 3 Expiration Date: December 2000 Nortel Networks Corp. 5 Ayan Banerjee 6 John Drake 7 Jonathan P. Lang 8 Calient Networks 10 Lou Berger 11 LabN Consulting, LLC 13 Greg Bernstein 14 Ciena Corporation 16 Kireeti Kompella 17 Juniper Networks, Inc. 19 Eric Mannie 20 GTS Network Services 22 Bala Rajagopalan 23 Debanjan Saha 24 Z. Bo Tang 25 Tellium, Inc. 27 Yakov Rekhter 28 cisco Systems 30 Vishal Sharma 31 Tellabs 33 June 2000 35 Generalized MPLS - Signaling Functional Description 37 draft-ashwood-generalized-mpls-signaling-00.txt 39 Status of this Memo 41 This document is an Internet-Draft and is in full conformance with 42 all provisions of Section 10 of RFC2026. Internet-Drafts are working 43 documents of the Internet Engineering Task Force (IETF), its areas, 44 and its working groups. Note that other groups may also distribute 45 working documents as Internet-Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 To view the current status of any Internet-Draft, please check the 53 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 54 Directory, see http://www.ietf.org/shadow.html. 56 Abstract 58 This document describes extensions to MPLS signaling required to 59 support Generalized MPLS. Generalized MPLS extends MPLS to encompass 60 time-division (e.g. SONET ADMs), wavelength (optical lambdas) and 61 spatial switching (e.g. incoming port or fiber to outgoing port or 62 fiber). This document presents a functional description of the 63 extensions. Protocol specific formats and mechanisms are currently 64 included in this draft but are expected to be split out into 65 separate, per protocol documents. 67 Contents 69 1 Introduction ................................................ 4 70 2 Overview ................................................... 5 71 3 Label Related Formats ...................................... 7 72 3.1 Generalized Label Request ................................... 7 73 3.2 Generalized Label ........................................... 11 74 3.3 Waveband Switching .......................................... 16 75 3.4 Suggested Label ............................................. 18 76 3.5 Label Set ................................................... 19 77 4 Bidirectional LSPs .......................................... 22 78 4.1 Required Information ........................................ 23 79 4.2 Procedures .................................................. 23 80 4.3 Contention Resolution ....................................... 24 81 5 Notification ................................................ 26 82 5.1 Notify Message .............................................. 26 83 5.2 Non-Adjacent Message Bundling ............................... 27 84 6 Egress Control .............................................. 28 85 6.1 Required Information ........................................ 28 86 6.2 Procedures .................................................. 30 87 7 Acknowledgments ............................................. 30 88 8 Security Considerations ..................................... 31 89 9 References .................................................. 31 90 10 Authors' Addresses .......................................... 32 91 Changes from previous version: 93 o First revision. 95 1. Introduction 97 The Multiprotocol Label Switching (MPLS) architecture [MPLS-ARCH] has 98 been defined to support the forwarding of data based on a label. In 99 this architecture, Label Switching Routers (LSRs) were assumed to 100 have a forwarding plane that is capable of (a) recognizing either 101 packet or cell boundaries, and (b) being able to process either 102 packet headers (for LSRs capable of recognizing packet boundaries) or 103 cell headers (for LSRs capable of recognizing cell boundaries). 105 The original architecture has recently been extended to include LSRs 106 whose forwarding plane recognizes neither packet, nor cell 107 boundaries, and therefore, can't forward data based on the 108 information carried in either packet or cell headers. Specifically, 109 such LSRs include devices where the forwarding decision is based on 110 time slots, wavelengths, or physical ports. 112 Given the above, LSRs, or more precisely interfaces on LSRs, can be 113 subdivided into the following classes: 115 1. Interfaces that recognize packet/cell boundaries and can forward 116 data based on the content of the packet/cell header. Examples 117 include interfaces on routers that forward data based on the 118 content of the "shim" header, interfaces on ATM-LSRs that forward 119 data based on the ATM VPI/VCI. Such interfaces are referred to as 120 Packet-Switch Capable (PSC). 122 2. Interfaces that forward data based on the data's time slot in a 123 repeating cycle. An example of such an interface is an interface 124 on a SONET Cross-Connect. Such interfaces are referred to as 125 Time-Division Multiplex Capable (TDM). 127 3. Interfaces that forward data based on the wavelength on which the 128 data is received. An example of such an interface is an interface 129 on an Optical Cross-Connect that can operate at the level of an 130 individual wavelength. Such interfaces are referred to as Lambda 131 Switch Capable (LSC). 133 4. Interfaces that forward data based on a position of the data in 134 the real world physical spaces. An example of such an interface 135 is an interface on an Optical Cross-Connect that can operate at 136 the level of a single (or multiple) fibers. Such interfaces are 137 referred to as Fiber-Switch Capable (FSC). 139 Using the concept of nested LSPs (by using label stack) allows the 140 system to scale by building a forwarding hierarchy. At the top of 141 this hierarchy are FSC interfaces, followed by LSC interfaces, 142 followed by TDM interfaces, followed by PSC interfaces. This way, an 143 LSP that starts and ends on a PSC interface can be nested (together 144 with other LSPs) into an LSP that starts and ends on a TDM interface. 145 This LSP, in turn, can be nested (together with other LSPs) into an 146 LSP that starts and ends on a LSC interface, which in turn can be 147 nested (together with other LSPs) into an LSP that starts and ends on 148 a FSC interface. See [MPLS-HIERARCHY] for more information on LSP 149 hierarchies. 151 The establishment of LSPs that span only the first class of 152 interfaces is defined in the [LDP, CR-LDP, RSVP-TE]. This document 153 presents the extensions needed to support all four classes of 154 interfaces. 156 This document currently includes data formats for both CR-LDP and 157 RSVP-TE extensions. A future version of this document is expected to 158 move these protocol specific formats to per protocol drafts. 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 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.1. 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. 214 Generalized MPLS extends on the notion of restricting the range of 215 labels that may be selected by a downstream node, see Section 3.5. 216 In generalized MPLS, an ingress or other upstream node may restrict 217 the labels that may be used by an LSP along either a single hop or 218 along the whole LSP path. This feature is driven from the optical 219 domain where there are cases where wavelengths used by the path must 220 be restricted either to a small subset of possible wavelengths, or to 221 one specific wavelength. This requirement occurs because some 222 equipment may only be able to generate a small set of the wavelengths 223 that intermediate equipment may be able to switch, or because 224 intermediate equipment may not be able to switch a wavelength at all, 225 being only able to redirect it to a different fiber. 227 While traditional traffic engineered MPLS (and even LDP) are 228 unidirectional, generalized MPLS supports the establishment of 229 bidirectional LSPs, see Section 4. The need for bidirectional LSPs 230 come from non-PSC applications. There are multiple reasons why such 231 LSPs are needed, particularly possible resource contention when 232 allocating reciprocal LSPs via separate signaling sessions, and 233 simplifying failure restoration procedures in the non-PSC case. 235 Bidirectional LSPs also have the benefit of lower setup latency and 236 lower number of messages required during setup. 238 Other features supported by generalized MPLS are rapid failure 239 notification, see Section 5, and termination of an LSP on a specific 240 egress port, see Section 6. 242 3. Label Related Formats 244 To deal with the widening scope of MPLS into the optical and time 245 domain, several new forms of "label" are required. These new forms 246 of label are collectively referred to as a "generalized label". A 247 generalized label contains enough information to allow the receiving 248 node to program its cross connect, regardless of the type of this 249 cross connect, such at the ingress segments of the path are properly 250 joined. This section defines a generalized label request, a 251 generalized label, support for waveband switching, suggested label 252 and label sets. 254 Note that since the nodes sending and receiving the new form of label 255 know what kinds of link they are using, the generalized label does 256 not contain a type field, instead the nodes are expected to know from 257 context what type of label to expect. 259 3.1. Generalized Label Request 261 The Generalized Label Request supports communication of 262 characteristics required to support the LSP being requested. These 263 characteristics include desired link protection, LSP encoding, and 264 LSP payload. 266 The Generalized Label Request indicates the link protection type 267 desired for the LSP. If a particular protection type, i.e., 1+1, or 268 1:N, is requested, then a connection request is processed only if the 269 desired protection type can be honored. Note that the protection 270 capabilities of a link may be advertised in routing, see [OMPLS-ISIS, 271 OMPLS-OSPF]. Path computation algorithms may take this information 272 into account when computing paths for setting up LSPs. 274 The Generalized Label Request also carries an LSP encoding parameter, 275 called LSP Encoding Type. This parameter indicates the encoding 276 type, e.g., SONET/SDH/GigE etc., that will be used with the data 277 associated with the LSP. The LSP Encoding Type represents the nature 278 of the LSP, and not the nature of the links that the LSP traverses. 279 A link may support a set of encoding formats, where support means 280 that a link is able to carry and switch a signal of one or more of 281 these encoding formats depending on the resource availability and 282 capacity of the link. For example, consider an LSP signaled with 283 "photonic" encoding. It is expected that such an LSP would be 284 supported with no electrical conversion and no knowledge of the 285 modulation and speed by the transit nodes. If the bit rate is known 286 but not the modulation then a Clear encoding suffixed with the rate 287 may be signaled. For example, a bit rate of OC-1 but an encoding 288 type of clear can be signaled. The transit nodes would not look at 289 the frames, but would know the bit rate and as a result can do OEO 290 switching but not OXO switching. All other formats require framing 291 knowledge, and field parameters are broken into the framing type and 292 speed as shown below. A REQUEST/Path message SHOULD contain as 293 specific a LSP Encoding Type as possible to allow the maximum 294 flexibility in switching by transit LSRs. 296 3.1.1. Required Information 298 The Generalized Label Request object/TLV carries the desired 299 information, the format of which is as follows: 301 The format of a Generalized Label Request (in RSVP) 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 | Length | Class Num (19)| C_Type (5) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Reserved |Link Prot. Type| 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | LSP Encoding Type | G-PID | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 The format of a Generalized Labels (in CR-LDP) is: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |U|F| 0x0901 | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Reserved |Link Prot. Type| 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | LSP Encoding Type | G-PID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Link Protection Type: 8 bits 327 Indicates the desired link protection type of the connection 328 setup. A value of 0 implies that this connection does not care 329 about the available protection type. Other values are defined 330 in the [OMPLS-ISIS, OMPLS-OSPF] draft, which also defines how 331 link protection capabilities may be advertised. 333 LSP Encoding Type: 16 bits 335 Indicates the required encoding. This field is set by the 336 ingress node, transparently passed by transit nodes, and used 337 by the egress node. The following shows permitted values and 338 their meaning: 340 Value Bit Rate Encoding 341 ----- -------- -------- 342 0 N/A Packets 343 OC- SONET 1 <= <= 3072 344 3072 + STS- SDH 1 <= <= 3072 345 6144 + OC- Clear 1 <= <= 3072 347 9217 DS0 DS0 348 9218 DS1 DS1 349 9219 E1 E1 350 9220 DS2 DS2 351 9221 E2 E2 352 9222 DS3 DS3 353 9223 E3 E3 354 9224 J3 J3 355 9225 DS4 DS4 356 9226 E4 E4 357 9227 J4 J4 358 9228 1Gbps GigE 359 9229 10Gbps 10GigE 361 9230 VT-1.5/TU-11; 362 9231 VT-2/TU-12; 363 9232 VT-3; 364 9233 VT-6/TU-2; 365 9234 TU-3; 366 9235 Photonic Lambda 367 9236 Photonic Waveband 369 Generalized PID (G-PID): 16 bits 371 An identifier of the payload carried by an LSP. Standard 372 Ethertype values are used (with new Ethertype values defined as 373 needed). This field is set by the ingress node, transparently 374 passed by transit nodes, and used by the egress node. 376 3.1.2. Procedures 378 A node processing the Path/REQUEST message containing the Generalized 379 Label Request must verify that the requested parameters can be 380 satisfied by the node and by the outgoing interface. The node may 381 either directly support the LSP or it may use a tunnel (FA), i.e., 382 another class of switching. In either case, each parameter must be 383 checked. 385 Note that local node policy dictates when tunnels may be used and 386 when they may be created. Local policy may allow for tunnels to be 387 dynamically established or may be solely administratively controlled. 388 For more information on tunnels and processing of ER hops when using 389 tunnels see [MPLS-HIERARCHY]. 391 Transit nodes MUST verify that the outgoing interface or tunnel can 392 support the requested Link Protection Type. If it cannot, the node 393 MUST generate a PathErr/NOTIFICATION message, with a "Routing 394 problem/Unsupported Link Protection" indication. 396 Transit and egress nodes MUST verify that the node itself and, where 397 appropriate, that the outgoing interface or tunnel can support the 398 requested LSP Encoding Type. If encoding cannot be supported, the 399 node MUST generate a PathErr/NOTIFICATION message, with a "Routing 400 problem/Unsupported Encoding" indication. 402 The G-PID parameter is normally only examined at the egress. If the 403 indicated G-PID cannot be supported then the egress MUST generate a 404 PathErr/NOTIFICATION message, with a "Routing problem/Unsupported 405 GPID" indication. In the case of PSC and when penultimate hop 406 popping (PHP) is requested, the penultimate hop also examines the 407 (stored) G-PID during the processing of the Resv/MAPPING message. In 408 this case if the G-PID is not supported, then the penultimate hop 409 MUST generate a ResvErr/NOTIFICATION message with a "Routing 410 problem/Unacceptable label value" indication. 412 When an error message is not generated, normal processing occurs. In 413 the transit case this will typically result in a Path/REQUEST message 414 being propagated. In the egress case and PHP special case this will 415 typically result in a Resv/MAPPING message being generated. 417 3.2. Generalized Label 419 The Generalized Label extends the traditional Label Object in that it 420 allows the representation of not only labels which travel in-band 421 with associated data packets, but also labels which identify time- 422 slots, wavelengths, or space division multiplexed positions. For 423 example, the Generalized Label may carry a label that represents (a) 424 a single fiber in a bundle, (b) a single waveband within fiber, (c) a 425 single wavelength within a waveband (or fiber), or (d) a set of time- 426 slots within a wavelength (or fiber). It may also carry a label that 427 represents a generic MPLS label, a Frame Relay label, or an ATM label 428 (VCI/VPI). 430 A Generalized Label does not identify the "class" to which the label 431 belongs. This is implicit in the multiplexing capabilities of the 432 link on which the label is used. 434 A Generalized Label object only carries a single level of label, 435 i.e., it is non-hierarchical. When multiple levels of label (LSPs 436 within LSPs) are required, each LSP must be established separately, 437 see [MPLS-HIERARCHY]. 439 The Generalized Label supports link bundling by carrying the identity 440 of the component link. In the presence of link bundling, each 441 Generalized Label indicates label(s) within the context of a specific 442 component link, which is identified by the Link ID (which is carried 443 as part of Generalized Label). The values used to indicate Link ID 444 have local significance between two neighbors. Procedures for 445 determining Link ID are specified elsewhere, see [MPLS-BUNDLE]. 447 Each Generalized Label object carries a variable length label 448 parameter. 450 3.2.1. Required Information 452 The format of a Generalized Labels (in RSVP) is: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Length | Class Num (16)| C_Type (2) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Link ID | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Label | 462 | ... | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 The format of a Generalized Labels (in CR-LDP) is: 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 |U|F| 0x0902 | Length | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Link ID | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Label | 475 | ... | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Link ID: 32 bits 480 Indicates link on which label is being request, from the 481 message sender's perspective. Used when bundling several 482 (parallel) links, see [MPLS-BUNDLE]. MUST be zero when 483 bundling is not being used. Note, values only have 484 significance between two neighbors and the receiver may need to 485 convert the received value into a value that has local 486 significance. 488 Label: Variable 490 Carries label information. The semantics of this field depends 491 on the type of the link over which the label is used. 493 3.2.1.1. SDH Labels 495 For SDH time-slots, the format for the label is given below. If a 496 single label is given, that label is the lowest time-slot of a 497 contiguously concatenated signal; the bandwidth of the LSP request 498 indicates the number of labels to be concatenated to form the SDH 499 signal trail. If there are multiple labels, then the identified 500 labels are virtually concatenated to form the SDH signal trail. The 501 above representation limits virtual concatenation to remain within a 502 single (component) link. 504 The format of the label for TDM-LSRs is: 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | S | U | K | L | M | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 This is an extension of the numbering scheme defined in G.707 section 513 7.3, i.e. the (K, L, M) numbering. Each letter indicates a possible 514 branch number starting at the parent node in the naming tree. 515 Branches are considered as numbered starting from the high of the 516 figure, the numbering starts normally at 1 (0 is used to indicate an 517 exception). 519 1. S is the index of an STS signal in a multiplex. For SDH, S=1 520 denotes an STM-0 signal; otherwise, S must be a multiple of 3, 521 in which case, S/3 is the index of the STM signal. 523 2. U indicates a specific VC inside a given STS-1 or STM-1 524 signal. U=1 indicates a single VC-4, while U=2->4 indicates a 525 specific VC-3 inside the given signal. 527 3. K indicates possible branches of a VC-4. It is not meaningful 528 for the VC-3 multiplexing and must be 0 in that case. K=1 529 indicates that the VC-4 is not further sub-divided. K=2->4 530 indicates a specific TUG-3 inside the given VC-4. A multiplex 531 entry name with K=0 denotes a VC-3 multiplexing of an STM-1 532 (easy to test and read). 534 4. L indicates possible branches of either a TUG-3 or a VC-3. In 535 the first case, L=1 indicates that the TUG-3 is not further 536 sub-divided and contains simply a VC-3. L=2->8 indicates a 537 specific TUG-2 inside the given TUG-3. In the second case, L=1 538 indicates that the VC-3 is not further sub-divided. L=2->8 539 indicates a specific TUG-2 inside the given VC-3. 541 5. M indicates possible branches of a TUG-2. It is not meaningful 542 for an unstructured VC-4, TUG-3 or VC-3, it must be 0 in that 543 case. M=1 indicates that the TUG-2 is not further sub-divided 544 and contains simply a VC-2. M=2->4 indicates a specific VC-12 545 inside the given TUG-2. M=5->8 indicates a specific VC-11 546 inside the given TUG-2. A multiplex entry name with M=0 denotes 547 a VC-4 or VC-3. 549 3.2.1.2. SONET Labels 551 For SONET time-slots, the format for the label is given below. If a 552 single label is given, that label is the lowest time-slot of a 553 contiguously concatenated signal; the bandwidth of the LSP request 554 indicates the number of labels to be concatenated to form the SONET 555 signal trail. If there are multiple labels, then the identified 556 labels are virtually concatenated to form the SONET signal trail. The 557 above representation limits virtual concatenation to remain within a 558 single (component) link. 560 A STS-1 signal can contain seven VT Groups, where each of the VT 561 Groups can contain only one type of VT (of the four defined types, 562 namely, VT1.5, VT2, VT3, and VT6). Furthermore, a VT Group can 563 contain up to four VT1.5s, or three VT2s, or two VT3, or one VT6. 565 The format of the label for SONET TDM-LSRs is: 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | P | Q | R | S | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 where, in the tuple (P,Q,R,S), P denotes the STS-1 number in the STS- 574 N signal, Q denotes the Virtual Tributary (VT) Group number, R 575 defines the VT type (one of VT1.5, VT2, VT3, or VT6), and S denotes 576 the VTx number in the VT type. 578 3.2.1.3. Port and Wavelength Labels 580 Some configurations of fiber switching (FSC) and lambda switching 581 (LSC) use multiple data channels/links controlled by a single control 582 channel. In such cases the label indicates the data channel/link to 583 be used for the LSP. Note that this case is not the same as when 584 [MPLS-BUNDLING] is being used. 586 The format of a Port and Wavelength label is: 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Label | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Label: 32 bits 596 Indicates port/fiber or lambda to be used, from the sender's 597 perspective. Values used in this field only have significance 598 between two neighbors, and the receiver may need to convert the 599 received value into a value that has local significance. 600 Values may be configured or dynamically determined using a 601 protocol such as [LMP]. 603 3.2.1.4. Other Labels 605 Generic MPLS labels and Frame Relay labels are encoded right 606 justified aligned in 32 bits (4 octets). ATM labels are encoded with 607 the VPI right justified in bits 0-15 and the VCI right justified in 608 bits 16-31. 610 3.2.2. Procedures 612 The Generalized Label travels in the upstream direction in 613 MAPPING/Resv messages. 615 The presence of both a generalized and normal label object in a 616 Path/REQUEST message is a protocol error and should treated as a 617 malformed message by the recipient. 619 If link bundling is not being used, the Link ID MUST be zero on 620 transmission and ignored when received. 622 When link bundling is being used, the Link ID MUST contain a non zero 623 value which uniquely identifies which link (e.g., fiber, waveband or 624 wavelength) is to contain the label(s). See [MPLS-BUNDLE] for 625 details. 627 In the case where the the Link ID uniquely identifies the LSP (e.g., 628 wavelength) the label parameter SHOULD be set to zero (0) and MUST be 629 ignored when received. 631 The recipient of a Resv/MAPPING message containing a Generalized 632 Label verifies that the values passed are acceptable. If the Link ID 633 is being used and the value is unknown, the recipient MUST generate a 634 ResvErr/NOTIFICATION message with a "Routing problem/Unknown Link ID" 635 indication. If the combination of the Link ID value (when 636 applicable) and label is unacceptable then the recipient MUST 637 generate a ResvErr/NOTIFICATION message with a "Routing problem/MPLS 638 label allocation failure" indication. 640 3.3. Waveband Switching 642 A special case of lambda switching is waveband switching. A waveband 643 represents a set of contiguous wavelengths which can be switched 644 together to a new waveband. For optimization reasons it may be 645 desirable for an optical cross connect to optically switch multiple 646 wavelengths as a unit. This may reduce the distortion on the 647 individual wavelengths and may allow tighter separation of the 648 individual wavelengths. The Waveband Label is defined to support 649 this special case. 651 Waveband switching naturally introduces another level of label 652 hierarchy and as such the waveband is treated the same way all other 653 upper layer labels are treated. 655 As far as the MPLS protocols are concerned there is little difference 656 between a waveband label and a wavelength label except that 657 semantically the waveband can be subdivided into wavelengths whereas 658 the wavelength can only be subdivided into time or statistically 659 multiplexed labels. 661 3.3.1. Required information 663 Waveband switching uses the same format as the generalized label, see 664 section 3.2.1. For compatibility reasons, a new RSVP c-type and CR- 665 LDP type is assigned for the Waveband Label. 667 In the context of waveband switching, the generalized label has the 668 following format: 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Waveband Id | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Start Label | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | End Label | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Waveband Id: 32 bits 681 A waveband identifier. The value is selected by the sender and 682 reused in all subsequent related messages. 684 Start Label: 32 bits 686 Indicates the channel identifier, from the sender's 687 perspective, of the lowest value wavelength making up the 688 waveband. 690 End Label: 32 bits 692 Indicates the channel identifier, from the sender's 693 perspective, of the highest value wavelength making up the 694 waveband. 696 Channel identifiers are established either by configuration or by 697 means of a protocol such as LMP [LMP]. They are normally used in the 698 link id parameter of the Generalized Label Request when bundling is 699 being used or the label parameter for PSC and LSC links when bundling 700 is not being used. 702 3.3.2. Procedures 704 The procedures defined in Section 3.2.2 apply to waveband switching. 705 This includes generating a ResvErr/NOTIFICATION message with a 706 "Routing problem/MPLS label allocation failure" indication if any of 707 the label fields are unrecognized or unacceptable. 709 Additionally, when a waveband is switched to another waveband, it is 710 possible that the wavelengths within the waveband will be mirrored 711 about a center frequency. When this type of switching is employed, 712 the start and end label in the waveband label object MUST be flipped 713 before forwarding the label object with the new waveband Id. In this 714 manner an egress/ingress LSR which receives a waveband label which 715 has these values inverted, knows that it must also invert its egress 716 association to pick up the proper wavelengths. Without this 717 mechanism and with an odd number of mirrored switching operations, 718 the egress LSRs will not know that an input wavelength of say L1 will 719 emerge from the waveband tunnel as L100. 721 This operation MUST be performed in both directions when a 722 bidirectional waveband tunnel is being established. 724 3.4. Suggested Label 726 The Suggested Label is used to provide a downstream node with the 727 upstream node's label preference. This permits the upstream node to 728 start configuring it's hardware with the proposed label before the 729 label is communicated by the downstream node. Such early 730 configuration is valuable to systems that take non-trivial time to 731 establish a label in hardware. Such early configuration can reduce 732 setup latency, and may be important for restoration purposes where 733 alternate LSPs may need to be rapidly established as a result of 734 network failures. 736 The use of Suggested Label is only an optimization. If a downstream 737 node passes a different label upstream, an upstream LSR MUST 738 reconfigure itself so that it uses the label specified by the 739 downstream node, thereby maintaining the downstream control of a 740 label. 742 3.4.1. Required Information and Processing 744 The format of a suggested label is identical to a generalized label. 745 It is used in Path/REQUEST messages. In RSVP the Suggested Label 746 uses a new class number (TBD of form 10bbbbbb) and the C-type of the 747 label being suggested. In CR-LDP, Suggested Label uses type = 0x904. 749 Errors in received Suggested Labels MUST be ignored. This includes 750 any received inconsistent or unacceptable values. 752 3.5. Label Set 754 The Label Set is used to limit the label choices of a downstream node 755 to a set of acceptable labels. This limitation applies on a per hop 756 basis. 758 There are four cases where a Label Set is useful in the optical 759 domain. The first case is where the end equipment is only capable of 760 transmitting and receiving on a small specific set of 761 wavelengths/bands. The second case is where there are a sequence of 762 interfaces which cannot support wavelength conversion (CI-incapable) 763 and require the same wavelength be used end-to-end over a sequence of 764 hops, or even an entire path. The third case is where it is 765 desirable to limit the amount of wavelength conversion being 766 performed to reduce the distortion on the optical signals. The last 767 case is where two ends of a link support different sets of 768 wavelengths. 770 Label Set is used to restrict label ranges that may be used for a 771 particular LSP between two peers. The receiver of a Label Set must 772 restrict its choice of labels to one which is in the Label Set. Much 773 like a label, a Label Set may be present across multiple hops. In 774 this case each node generates it's own outgoing Label Set, possibly 775 based on the incoming Label Set and the node's hardware capabilities. 776 This case is expected to be the norm for nodes with conversion 777 incapable (CI-incapable) interfaces. 779 The use of Label Set is optional, if not present, all labels from the 780 valid label range may be used. Conceptually the absence of a Label 781 Set implies a Label Set whose value is {U}, the set of all valid 782 labels. 784 3.5.1. Required Information 786 This LabelSet is used in Path/REQUEST messages. 788 The data required to support the Label Set consists of a variable 789 sized array of labels, or label ranges. These labels are subchannel 790 identifiers and MUST lie within the link identified in Generalized 791 Label Request. 793 The format of a LabelSet (in RSVP) is: 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Length | Class Num (xx)|C_Type (xx) | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Reserved | Type | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Subchannel | 803 | ... | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 The format of a LabelSet (in CR-LDP) is: 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 |U|F| type=0x0904 | Length | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Reserved | Type | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Subchannel | 816 | ... | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 Type: 2 bits 821 0x00 means subchannel is a single element (inclusive) 822 0x01 means subchannel is a start element (inclusive) 823 0x02 means subchannel is an end element (inclusive) 824 0x03 means subchannel is a single element (exclusive) 826 Subchannel: 828 The subchannel represents the label (wavelength, fiber ... ) 829 which is eligible for allocation. This field has the same 830 format as described for labels under section 3.2. 832 Since subchannel to local channel identifiers (e.g., 833 wavelength) mappings are a local matter, when a Label Set is 834 propagated from one node to the next, the subchannels may have 835 to be remapped to new subchannel values for consistency. 837 A Label Set can be just a series of single elements (Type=0x00) 838 sorted in increasing order of subchannel value. 840 A Label Set can be a set of ranges (Type=0x01 followed by Type=0x02). 841 The ranges MUST be sorted. A range which is missing a beginning or 842 an end implies no bound where the bound is missing. A range which 843 contains a Type=0x03 (exclusive) means all subchannels in the range 844 except that subchannel are eligible. 846 3.5.2. Procedures 848 The absence of a Label Set implies that all labels are acceptable. A 849 Label Set is included when a node wishes to restrict the label(s) 850 that may be used downstream. 852 On reception of a Path/REQUEST message a CI-capable interface will 853 restrict its choice of labels to one which is in the Label Set. The 854 CI-capable receiver may also remove the Label Set prior to forwarding 855 the Path/REQUEST message. If the node is unable to pick a label from 856 the Label Set, then the request is terminated and a 857 PathErr/NOTIFICATION message with a "Routing problem/Label Set" 858 indication MUST be generated. It is a local matter if the Label Set 859 is stored for later selection on the RESV/Mapping or if the selection 860 is made immediately for propagation in the RESV/Mapping. 862 On reception of a Path/REQUEST message for a CI-incapable interface, 863 the Label Set in the message is compared against the set of available 864 labels at the downstream interface and the resulting intersecting 865 Label Set is forwarded in a Path/REQUEST message. When the resulting 866 Label Set is empty, the Path/REQUEST must be terminated, and a 867 PathErr/NOTIFICATION message, and a "Routing problem/Label Set" 868 indication MUST be generated. Note that intersection is based on the 869 physical labels (actual wavelength/band values) which may have 870 different logical values on different links, as a result it is the 871 responsibility of the node to map these values so that they have a 872 consistent physical meaning, or to drop the particular values from 873 the set if no suitable logical label value exists. 875 On reception of a Resv/MAPPING message at an intermediate node, the 876 label to propagate upstream is selected from within the (stored) 877 Label Set (preferred) or may be preselected from that set to save 878 memory. 880 Note, on reception of a Resv/MAPPING message for an interface which 881 is CI-incapable it has no other choice than to use the same physical 882 label (wavelength/band) as received in the Resv/MAPPING. In this 883 case, the use and propagation of a Label Set will significantly 884 reduce the chances that this allocation will fail when CI-incapable 885 nodes are traversed. 887 4. Bidirectional LSPs 889 This section defines direct support of bidirectional LSPs. Support 890 is defined for LSPs that have the same traffic engineering 891 requirements including fate sharing, protection and restoration, and 892 resource requirements (e.g., latency and jitter) in each direction. 893 In the remainder of this section, the term "initiator" is used to 894 refer to a node that starts the establishment of an LSP and the term 895 "terminator" is used to refer to the node that is the target of the 896 LSP. Note that for bidirectional LSPs, there is only one "initiator" 897 and one "terminator". 899 Normally to establish a bidirectional LSP when using [RSVP-TE] or 900 [CR-LDP] two unidirectional paths must be independently established. 901 This approach has the following disadvantages: 903 * The latency to establish the bidirectional LSP is equal to one 904 round trip signaling time plus one initiator-terminator signaling 905 transit delay. This not only extends the setup latency for 906 successful LSP establishment, but it extends the worst-case 907 latency for discovering an unsuccessful LSP to as much as two 908 times the initiator-terminator transit delay. These delays are 909 particularly significant for LSPs that are established for 910 restoration purposes. 912 * The control overhead is twice that of a unidirectional LSP. 913 This is because separate control messages (e.g. Path and Resv) 914 must be generated for both segments of the bidirectional LSP. 916 * Because the resources are established in separate segments, 917 route selection is complicated. There is also additional 918 potential race for conditions in assignment of resources, which 919 decreases the overall probability of successfully establishing 920 the bidirectional connection. 922 * It is more difficult to provide a clean interface for SONET 923 equipment that may rely on bidirectional hop-by-hop paths for 924 protection switching. Note that existing SONET gear transmits 925 the control information in-band with the data. 927 * Bidirectional optical LSPs (or lightpaths) are seen as a 928 requirement for many optical networking service providers. 930 With bidirectional LSPs both the downstream and upstream data paths, 931 i.e., from initiator to terminator and terminator to initiator, are 932 established using a single set of Path/REQUEST and Resv/MAPPING 933 messages. This reduces the setup latency to essentially one 934 initiator-terminator round trip time plus processing time, and limits 935 the control overhead to the same number of messages as a 936 unidirectional LSP. 938 4.1. Required Information 940 For bidirectional LSPs, two labels must be allocated. Bidirectional 941 LSP setup is indicated by the presence of an Upstream Label in the 942 REQUEST/Path message. An Upstream Label has the same format as the 943 generalized label, see Section 3.2. In RSVP the Upstream Label uses 944 a new class number (TBD of form 0bbbbbbb) and the C-type of the label 945 being suggested. In CR-LDP, Upstream Label uses type=0x0906 947 4.2. Procedures 949 The process of establishing a bidirectional LSP follows the 950 establishment of a unidirectional LSP with some additions. To 951 support bidirectional LSPs an Upstream Label is added to the 952 Path/REQUEST message. The Upstream Label MUST indicate a label that 953 is valid for forwarding at the time the Path/REQUEST message is sent. 955 When a Path/REQUEST message containing an Upstream Label is received, 956 the receiver first verifies that the upstream label is acceptable. 957 If the label is not acceptable, the receiver MUST issue a 958 PathErr/NOTIFICATION message with a "Routing problem/Unacceptable 959 label value" indication. 961 An intermediate node must also allocate a label on the outgoing 962 interface and establish internal data paths before filling in an 963 outgoing Upstream Label and propagating the Path/REQUEST message. If 964 an intermediate node is unable to allocate a label or internal 965 resources, then it MUST issue a PathErr/NOTIFICATION message with a 966 "Routing problem/Label allocation failure" indication. 968 Terminator nodes process Path/REQUEST messages as usual, with the 969 exception that the upstream label can immediately be used to 970 transport associated data upstream to the initiator. 972 When a bidirectional LSP is removed, both upstream and downstream 973 labels are invalidated and it is no longer valid to send data using 974 the associated labels. 976 4.3. Contention Resolution 978 Contention for labels may occur between two bidirectional LSP setup 979 requests traveling in opposite directions. This contention occurs 980 when both sides allocate the same resources (ports) at effectively 981 the same time. If there is no restriction on the ports that can be 982 used for bidirectional LSPs and if there are alternate resources, 983 then both nodes will pass different labels upstream and the 984 contention will be resolved naturally. However, if there is a 985 restriction on the ports that can be used for the bidirectional LSPs 986 (for example, if they must be physically coupled on a single I/O 987 card), or if there are no more resources available, then the 988 contention must be resolved by other means. To resolve contention, 989 the node with the higher node ID will win the contention and it MUST 990 issue a PathErr/NOTIFICATION message with a "Routing problem/Label 991 allocation failure" indication. Upon receipt of such an error, the 992 node SHOULD try to allocate a different Upstream label (and a 993 different Suggested Label if used) to the bidirectional path. 994 However, if no other resources are available, the node must proceed 995 with standard error handling. For the purposes of RSVP contention 996 resolution, the node ID is the IP address used in the RSVP_HOP 997 object. 999 To reduce the probability of contention, one may impose a policy that 1000 the node with the lower ID never suggests a label in the downstream 1001 direction and always accepts a Suggested Label from an upstream node 1002 with a higher ID. Furthermore, since the label sets are exchanged 1003 using LMP [LMP], an alternative local policy could further be imposed 1004 such that (with respect to the higher numbered node's label set) the 1005 higher numbered node could allocate labels from the high end of the 1006 label range while the lower numbered node allocates labels from the 1007 low end of the label range. This mechanism would augment any close 1008 packing algorithms that may be used for bandwidth (or wavelength) 1009 optimization. 1011 An example of contention between two nodes (PXC 1 and PXC 2) is shown 1012 in Figure 1. In this example PXC 1 assigns an Upstream Label for the 1013 channel corresponding to local BCId=2 (local BCId=7 on PXC 2) and 1014 sends a Suggested Label for the channel corresponding to local BCId=1 1015 (local BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream 1016 Label for the channel corresponding to its local BCId=6 (local BCId=1 1017 on PXC 1) and sends a Suggested Label for the channel corresponding 1018 to its local BCId=7 (local BCId=2 on PXC 1). If there is no 1019 restriction on the ports that can be used for bidirectional LSPs and 1020 if there are alternate resources available, then both PXC 1 and PXC 2 1021 will pass different labels upstream and the contention is resolved 1022 naturally (see Fig. 2). However, if there is a restriction on the 1023 ports that can be used for bidirectional LSPs (for example, if they 1024 must be physically coupled on a single I/O card), then the contention 1025 must be resolved using the router Id (see Fig. 3). 1027 +------------+ +------------+ 1028 + PXC 1 + + PXC 2 + 1029 + + SL1,UL2 + + 1030 + 1 +------------------------>+ 6 + 1031 + + UL1, SL2 + + 1032 + 2 +<------------------------+ 7 + 1033 + + + + 1034 + + + + 1035 + 3 +------------------------>+ 8 + 1036 + + + + 1037 + 4 +<------------------------+ 9 + 1038 +------------+ +------------+ 1039 Figure 1. Label Contention 1041 In this example, PXC 1 assigns an Upstream Label using BCId=2 (BCId=7 1042 on PXC 2) and a Suggested Label using BCId=1 (BCId=6 on PXC 2). 1043 Simultaneously, PXC 2 assigns an Upstream Label using BCId=6 (BCId=1 1044 on PXC 1) and a Suggested Label using BCId=7 (BCId=2 on PXC 1). 1046 +------------+ +------------+ 1047 + PXC 1 + + PXC 2 + 1048 + + UL2 + + 1049 + 1 +------------------------>+ 6 + 1050 + + UL1 + + 1051 + 2 +<------------------------+ 7 + 1052 + + + + 1053 + + L1 + + 1054 + 3 +------------------------>+ 8 + 1055 + + L2 + + 1056 + 4 +<------------------------+ 9 + 1057 +------------+ +------------+ 1058 Figure 2. Label Contention Resolution without resource restrictions 1060 In this example, there is no restriction on the ports that can be 1061 used by the bidirectional connection and contention is resolved 1062 naturally. 1064 +------------+ +------------+ 1065 + PXC 1 + + PXC 2 + 1066 + + UL2 + + 1067 + 1 +------------------------>+ 6 + 1068 + + L2 + + 1069 + 2 +<------------------------+ 7 + 1070 + + + + 1071 + + L1 + + 1072 + 3 +------------------------>+ 8 + 1073 + + UL1 + + 1074 + 4 +<------------------------+ 9 + 1075 +------------+ +------------+ 1076 Figure 3. Label Contention Resolution with resource restrictions 1078 In this example, ports 1,2 and 3,4 on PXC 1 (ports 6,7 and 8,9 on PXC 1079 2, respectively) must be used by the same bidirectional connection. 1080 Since PXC 2 has a higher node ID, it wins the contention and PXC 1 1081 must use a different set of labels. 1083 5. Notification 1085 This section defines two signaling extensions that enable expedited 1086 notification of failures and other events to nodes responsible for 1087 restoring failed LSPs. The first extension, the Notify message, 1088 provides for general event notification. The second allows for the 1089 combining of such notifications in a single message. These 1090 extensions are RSVP specific. 1092 5.1. Notify Message 1094 The Notify message provides a mechanism to inform non-adjacent nodes 1095 of LSP related events. This message differs from the currently 1096 defined error messages (i.e., PathErr and ResvErr messages of RSVP) 1097 in that it can be "targeted" to a node other than the immediate 1098 upstream or downstream neighbor and that it is a generalized 1099 notification mechanism. The Notify message does not replace existing 1100 error messages. The Notify message may be sent either (a) normally, 1101 where non-target nodes just forward the Notify message to the target 1102 node, similar to ResvConf processing in [RSVP]; or (b) encapsulated 1103 in a new IP header who's destination is equal to the target IP 1104 address. Regardless of the transmission mechanism, nodes receiving a 1105 Notify message not destined to the node forward the message, 1106 unmodified, towards the target. 1108 To support reliable delivery of the Notify message, an Ack Message 1109 [RSVP-RR] is used to acknowledge the receipt of a Notify Message. A 1110 node that receives the a Notify message MUST send a Notify_Ack 1111 message confirming receipt of the Notify message. 1113 5.1.1. Required Information 1115 The Notify message is a generalized notification message. The IP 1116 destination address is set to the IP address of the intended 1117 receiver. The Notify message is sent without the router alert 1118 option. 1120 ::= [] 1121 [...] 1122 [] 1124 ::= 1125 [] [] 1127 The ERROR_SPEC object specifies the error and includes the IP address 1128 of either the node that detected the error or the link that has 1129 failed. See ERROR_SPEC definition in RFC2205. The MESSAGE_ID object 1130 is defined in [RSVP-RR]. 1132 Note: for CR-LDP there is not currently a similar mechanism. In CR- 1133 LDP, when a failure is detected it will be propagated with 1134 RELEASE/WITHDRAW messages radially outward from the point of failure. 1135 Resources are to be released in this phase and actual resource 1136 information is fed back to the source using the feedback mechanisms 1137 of [FEEDBACK]. In this manner the source will have an accurate view 1138 of available resources and can start rerouting much sooner. 1140 5.2. Non-Adjacent Message Bundling 1142 [RSVP-RR] defines the bundle message which can be used to aggregate 1143 multiple signaling messages into a single packet. The defined 1144 mechanism is limited to adjacent RSVP nodes. This section defines 1145 the use of the bundle message between non-adjacent nodes. This is 1146 accomplished by setting the IP destination address of the bundle 1147 message to the address of the target node. The non-adjacent bundle 1148 message may be sent either (a) normally, where non-target nodes just 1149 forward the message to the target node (see ResvConf processing in 1150 [RSVP] for reference); or (b) encapsulated in a new IP header who's 1151 destination is equal to the target IP address. Regardless of the 1152 transmission mechanism, nodes receiving a bundle message not destined 1153 to the node just forward the message, unmodified, towards the target. 1154 The motivation for supporting non-adjacent message bundling is to 1155 support the bundling of Notify Messages. 1157 Non-adjacent bundle messages can only be sent to RSVP nodes that 1158 support bundling. Currently, the only method for discovering such 1159 information about a non-adjacent node is through manual 1160 configuration. 1162 5.2.1. Required Information 1164 The RSVP bundle message is defined in [RSVP-RR]. The only 1165 modification from what is specified in [RSVP-RR] is that the IP 1166 destination address does not have to be an immediate 1167 upstream/downstream neighbor. 1169 6. Egress Control 1171 The LSR at the head-end of an LSP can control the termination of the 1172 LSP by using the ERO. To terminate an LSP on a particular outgoing 1173 interface of the egress LSR, the head-end may specify the IP address 1174 of that interface as the last element in the ERO, provided that that 1175 interface has an associated IP address. 1177 There are cases where the use of IP address doesn't provide enough 1178 information to uniquely identify the egress termination. One case is 1179 when the outgoing interface on the egress LSR is a component link of 1180 a link bundle. Another case is when it is desirable to "splice" two 1181 LSPs together, i.e., where the tail of the first LSP would be 1182 "spliced" into the head of the second LSP. This last case is more 1183 likely to be used in the non-PSC classes of links. 1185 6.1. Required Information 1187 To handle scenarios described in the previous paragraph, the ERO 1188 subobject Egress Label type is introduced. 1190 For RSVP, this ERO subobject - Egress Label is defined as follows: 1192 0 1 2 3 1193 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 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 |L| Type | Length | Reserved | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Link ID | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Label | 1200 | ... | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 For CR-LDP the Egress Label ER-Hop is defined as follows: 1205 0 1 2 3 1206 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 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 |0|0| 0x901 | Length | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 |L| Reserved | Link ID | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Link ID (continued) | Label | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | Label (continued) | 1215 | ... | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 L 1220 This bit must be set to 0. 1222 Type (RSVP Only) 1224 3 Egress Label (To be assigned) 1226 Length 1228 The Length contains the total length of the subobject in bytes, 1229 including the Type and Length fields. The Length is always 1230 divisible by 4. 1232 Link ID 1234 Same definition as in Generalized Label. See Section 3.2.1. 1236 Label 1238 When an LSP has to be spliced into another LSP, this field 1239 identifies the label that the tail of the first LSP has to use 1240 in order to slice it into the head of the second LSP. In such 1241 cases the format of this field is identical to the one used by 1242 the Label field in the Generalized Label Object. In all other 1243 cases this field is omitted. 1245 6.2. Procedures 1247 The Egress Label subobject may appear only as the last subobject in 1248 the ERO/ER. Appearance of this subobject anywhere else in the ERO/ER 1249 is treated as a "Bad strict node" error. 1251 During an LSP setup, when a node processing the ERO/RR performs Next 1252 Hop selection finds that the second subobject is an Egress Label 1253 Subobject, the node uses the information carried in this subobject to 1254 determine the handling of the data received over that LSP. 1255 Specifically, if the Link ID field of the subobject is non zero, then 1256 this field identifies a specific (outgoing) link of the node that 1257 should be used for sending all the data received over the LSP. If 1258 the Label field of the subobject is not Implicit NULL label, this 1259 field specifies the label that should be used as an outgoing label on 1260 the data received over the LSP. 1262 Procedures by which an LSR at the head-end of an LSP obtains the 1263 information needed to construct the Egress Label subobject are 1264 outside the scope of this document. 1266 7. Acknowledgments 1268 This draft is the work of numerous authors and consists of a 1269 composition of a number of previous drafts in this area. A list of 1270 the drafts from which material and ideas were incorporated follows: 1272 draft-saha-rsvp-optical-signaling-00.txt 1273 draft-lang-mpls-rsvp-oxc-00.txt 1274 draft-kompella-mpls-optical-00.txt 1275 draft-fan-mpls-lambda-signaling-00.txt 1277 8. Security Considerations 1279 This draft does not introduce any new security considerations to 1280 either [CR-LDP] or [RSVP-TE]. 1282 9. References 1284 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 1285 draft-ietf-mpls-cr-ldp-04.txt, July, 2000. 1287 [LDP] Andersson et al., "LDP Specification", 1288 draft-ietf-mpls-ldp-08.txt, June 2000. 1290 [LMP] Lang, J.P., Mitra, K., Drake, J., Kompella, K., Rekhter, Y., 1291 Saha, D., Berger, L., Basak, D., "Link Management Protocol", 1292 Internet Draft, draft-lang-mpls-lmp-01.txt, July 2000. 1294 [MPLS-ARCH] Rosen et al., "Multiprotocol label switching 1295 Architecture", Internet Draft, 1296 draft-ietf-mpls-arch-06.txt, August 1999. 1298 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling 1299 in MPLS Traffic Engineering", Internet Draft, 1300 draft-kompella-mpls-bundle-02.txt, July 2000. 1302 [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 1303 MPLS TE", Internet Draft, 1304 draft-ietf-mpls-lsp-hierarchy-00.txt, July 2000. 1306 [OMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., 1307 Bernstein, G., Fedyk, D., Mannie, E., Saha, D., and 1308 Sharma, V., "IS-IS Extensions in Support of MPL(ambda)S", 1309 Internet Draft, draft-ompls-isis-extensions-00.txt, 1310 July 2000. 1312 [OMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., 1313 Bernstein, G., Fedyk, D., Mannie, E., Saha, D., and 1314 Sharma, V., "OSPF Extensions in Support of MPL(ambda)S", 1315 Internet Draft, draft-ompls-ospf-extensions-00.txt, 1316 July 2000. 1318 [RSVP-TE] Awduche, D.O., Berger, L., Gan, D.-H., Li, T., Swallow, G., 1319 and Srinivasan, V., "RSVP-TE: Extensions to RSVP for LSP 1320 Tunnels," Internet Draft, 1321 draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, July 2000. 1323 [RSVP-RR] Berger L., Gan D., Swallow G., Pan P., Tommasi F., 1324 Molendini S., "RSVP Refresh Overhead Reduction Extensions", 1325 draft-ietf-rsvp-refresh-reduct-05.txt, June 2000. 1327 [FEEDBACK] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, 1328 "Improving Topology Data Base Accuracy With LSP Feedback 1329 via CR-LDP", Internet Draft, draft-ietf-mpls-te-feed-00.txt. 1331 10. Authors' Addresses 1333 Peter Ashwood-Smith 1334 Nortel Networks Corp. 1335 P.O. Box 3511 Station C, 1336 Ottawa, ON K1Y 4H7 1337 Canada 1338 Phone: +1 613 763 4534 1339 Email: petera@nortelnetworks.com 1341 Ayan Banerjee 1342 Calient Networks 1343 5853 Rue Ferrari 1344 San Jose, CA 95138 1345 Phone: +1 408 972-3645 1346 Email: abanerjee@calient.net 1348 Lou Berger 1349 LabN Consulting, LLC 1350 Phone: +1 301 468 9228 1351 Email: lberger@labn.net 1353 Greg Bernstein 1354 Ciena Corporation 1355 10480 Ridgeview Court 1356 Cupertino, CA 94014 1357 Phone: +1 408 366 4713 1358 Email: greg@ciena.com 1360 John Drake 1361 Calient Networks 1362 5853 Rue Ferrari 1363 San Jose, CA 95138 1364 Phone: +1 408 972 3720 1365 Email: jdrake@calient.net 1366 Yanhe Fan 1367 Nortel Networks 1368 PO Box 3511 Station C 1369 Ottawa, ON, K1Y 4H7 1370 Canada 1371 Phone: +1 613 765 2315 1372 Email: yanhe@nortelnetworks.com 1374 Kireeti Kompella 1375 Juniper Networks, Inc. 1376 1194 N. Mathilda Ave. 1377 Sunnyvale, CA 94089 1378 Email: kireeti@juniper.net 1380 Jonathan P. Lang 1381 Calient Networks 1382 25 Castilian 1383 Goleta, CA 93117 1384 Email: jplang@calient.net 1386 Eric Mannie 1387 Optical Networking 1388 Network R&D 1389 GTS Network Services 1390 Terhulpsesteenweg 6A 1391 1560 Hoeilaart - Belgium 1392 Phone: +32 2 658 56 52 1393 Mobile: +32 496 58 56 52 1394 Fax: +32 2 658 51 18 1395 Email: eric.mannie@gtsgroup.com 1397 Bala Rajagopalan 1398 Tellium, Inc. 1399 2 Crescent Place 1400 P.O. Box 901 1401 Oceanport, NJ 07757-0901 1402 Phone: +1 732 923 4237 1403 Fax: +1 732 923 9804 1404 Email: braja@tellium.com 1406 Yakov Rekhter 1407 cisco Systems 1408 Email: yakov@cisco.com 1409 Debanjan Saha 1410 Tellium Optical Systems 1411 2 Crescent Place 1412 Oceanport, NJ 07757-0901 1413 Phone: +1 732 923 4264 1414 Fax: +1 732 923 9804 1415 Email: dsaha@tellium.com 1417 Vishal Sharma 1418 Tellabs Research Center 1419 One Kendall Square 1420 Bldg. 100, Ste. 121 1421 Cambridge, MA 02139-1562 1422 Phone: +1 617 577 8760 1423 Email: Vishal.Sharma@tellabs.com 1425 Z. Bo Tang 1426 Tellium, Inc. 1427 2 Crescent Place 1428 P.O. Box 901 1429 Oceanport, NJ 07757-0901 1430 Phone: +1 732 923 4231 1431 Fax: +1 732 923 9804 1432 Email: btang@tellium.com