idnits 2.17.1 draft-ietf-mpls-generalized-signaling-04.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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-SONET], [GMPLS-RSVP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 321: '... is reserved. It MUST be set to zero o...' RFC 2119 keyword, line 322: '... and MUST be ignored on receip...' RFC 2119 keyword, line 553: '...t label upstream, an upstream LSR MUST...' RFC 2119 keyword, line 650: '... is reserved. It MUST be set to zero o...' RFC 2119 keyword, line 651: '... and MUST be ignored on receip...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2001) is 8381 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 455, but not defined == Unused Reference: 'GMPLS-ISIS' is defined on line 994, but no explicit reference was found in the text == Unused Reference: 'GMPLS-OSPF' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: 'MPLS-BUNDLE' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'RECOVERY' is defined on line 1041, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-02 ** 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-02 == Outdated reference: A later version (-02) exists of draft-kompella-ospf-gmpls-extensions-01 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-OSPF' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-02 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-00 ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- Possible downref: Normative reference to a draft: ref. 'LMP' -- Possible downref: Normative reference to a draft: ref. 'MPLS-BUNDLE' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 -- No information found for draft-ieft-mpls-recovery-frmwrk - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RECOVERY' Summary: 8 errors (**), 0 flaws (~~), 16 warnings (==), 7 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: November 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 (EBONE) 9 Jonathan P. Lang (Calient Networks) 10 Bala Rajagopalan (Tellium, Inc.) 11 Yakov Rekhter (Juniper Networks, Inc.) 12 Debanjan Saha (Tellium, Inc.) 13 Vishal Sharma (Jasmine Networks) 14 George Swallow (Cisco Systems) 15 Z. Bo Tang (Tellium, Inc.) 17 May 2001 19 Generalized MPLS - Signaling Functional Description 21 draft-ietf-mpls-generalized-signaling-04.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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 To view the current status of any Internet-Draft, please check the 43 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 44 Directory, see http://www.ietf.org/shadow.html. 46 Abstract 48 This document describes extensions to MPLS signaling required to 49 support Generalized MPLS. Generalized MPLS extends the MPLS control 50 plane to encompass time-division (e.g. SONET ADMs), wavelength 51 (optical lambdas) and spatial switching (e.g. incoming port or fiber 52 to outgoing port or fiber). This document presents a functional 53 description of the extensions. Protocol specific formats and 54 mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP]. Technology 55 specific details are expected to be specified in independent 56 technology specific documents, e.g., [GMPLS-SONET]. 58 Contents 60 1 Introduction .............................................. 3 61 2 Overview ................................................. 4 62 3 Label Related Formats .................................... 6 63 3.1 Generalized Label Request ................................. 6 64 3.1.1 Required Information ...................................... 7 65 3.1.2 Bandwidth Encoding ........................................ 9 66 3.2 Generalized Label ......................................... 10 67 3.2.1 Required Information ...................................... 10 68 3.3 Waveband Switching ........................................ 11 69 3.3.1 Required information ...................................... 12 70 3.4 Suggested Label ........................................... 13 71 3.5 Label Set ................................................. 13 72 3.5.1 Required Information ...................................... 14 73 4 Bidirectional LSPs ........................................ 15 74 4.1 Required Information ...................................... 17 75 4.2 Contention Resolution ..................................... 17 76 5 Notification on Label Error ............................... 19 77 6 Explicit Label Control .................................... 19 78 6.1 Required Information ...................................... 20 79 7 Protection Information .................................... 20 80 7.1 Required Information ...................................... 21 81 8 Acknowledgments ........................................... 22 82 9 Security Considerations ................................... 23 83 10 References ................................................ 23 84 11 Authors' Addresses ........................................ 24 85 Changes from previous version: 87 o Fixed Label Set format (for LDP) 89 1. Introduction 91 The Multiprotocol Label Switching (MPLS) architecture [MPLS-ARCH] has 92 been defined to support the forwarding of data based on a label. In 93 this architecture, Label Switching Routers (LSRs) were assumed to 94 have a forwarding plane that is capable of (a) recognizing either 95 packet or cell boundaries, and (b) being able to process either 96 packet headers (for LSRs capable of recognizing packet boundaries) or 97 cell headers (for LSRs capable of recognizing cell boundaries). 99 The original architecture has recently been extended to include LSRs 100 whose forwarding plane recognizes neither packet, nor cell 101 boundaries, and therefore, can't forward data based on the 102 information carried in either packet or cell headers. Specifically, 103 such LSRs include devices where the forwarding decision is based on 104 time slots, wavelengths, or physical ports. 106 Given the above, LSRs, or more precisely interfaces on LSRs, can be 107 subdivided into the following classes: 109 1. Interfaces that recognize packet/cell boundaries and can forward 110 data based on the content of the packet/cell header. Examples 111 include interfaces on routers that forward data based on the 112 content of the "shim" header, interfaces on ATM-LSRs that forward 113 data based on the ATM VPI/VCI. Such interfaces are referred to as 114 Packet-Switch Capable (PSC). 116 2. Interfaces that forward data based on the data's time slot in a 117 repeating cycle. An example of such an interface is an interface 118 on a SONET Cross-Connect. Such interfaces are referred to as 119 Time-Division Multiplex Capable (TDM). 121 3. Interfaces that forward data based on the wavelength on which the 122 data is received. An example of such an interface is an interface 123 on an Optical Cross-Connect that can operate at the level of an 124 individual wavelength. Such interfaces are referred to as Lambda 125 Switch Capable (LSC). 127 4. Interfaces that forward data based on a position of the data in 128 the real world physical spaces. An example of such an interface 129 is an interface on an Optical Cross-Connect that can operate at 130 the level of a single (or multiple) fibers. Such interfaces are 131 referred to as Fiber-Switch Capable (FSC). 133 Using the concept of nested LSPs allows the system to scale by 134 building a forwarding hierarchy. At the top of this hierarchy are 135 FSC interfaces, followed by LSC interfaces, followed by TDM 136 interfaces, followed by PSC interfaces. This way, an LSP that starts 137 and ends on a PSC interface can be nested (together with other LSPs) 138 into an LSP that starts and ends on a TDM interface. This LSP, in 139 turn, can be nested (together with other LSPs) into an LSP that 140 starts and ends on an LSC interface, which in turn can be nested 141 (together with other LSPs) into an LSP that starts and ends on a FSC 142 interface. See [MPLS-HIERARCHY] for more information on LSP 143 hierarchies. 145 The establishment of LSPs that span only the first class of 146 interfaces is defined in [LDP, CR-LDP, RSVP-TE]. This document 147 presents a functional description of the extensions needed to 148 generalize the MPLS control plane to support each of the four classes 149 of interfaces. Only signaling protocol independent formats and 150 definitions are provided in this document. Protocol specific formats 151 are defined in [GMPLS-RSVP] and [GMPLS-LDP]. Technology specific 152 details are outside the scope of this document and will be specified 153 in technology specific documents, such as [GMPLS-SONET]. 155 2. Overview 157 Generalized MPLS differs from traditional MPLS in that it supports 158 multiple types of switching, i.e., the addition of support for TDM, 159 lambda, and fiber (port) switching. The support for the additional 160 types of switching has driven generalized MPLS to extend certain base 161 functions of traditional MPLS and, in some cases, to add 162 functionality. These changes and additions impact basic LSP 163 properties, how labels are requested and communicated, the 164 unidirectional nature of LSPs, how errors are propagated, and 165 information provided for synchronizing the ingress and egress. 167 In traditional MPLS Traffic Engineering, links traversed by an LSP 168 can include an intermix of links with heterogeneous label encodings. 169 For example, an LSP may span links between routers, links between 170 routers and ATM-LSRs, and links between ATM-LSRs. Generalized MPLS 171 extends this by including links where the label is encoded as a time 172 slot, or a wavelength, or a position in the real world physical 173 space. Just like with traditional MPLS TE, where not all LSRs are 174 capable of recognizing (IP) packet boundaries (e.g., an ATM-LSR) in 175 their forwarding plane, generalized MPLS includes support for LSRs 176 that can't recognize (IP) packet boundaries in their forwarding 177 plane. In traditional MPLS TE an LSP that carries IP has to start 178 and end on a router. Generalized MPLS extends this by requiring an 179 LSP to start and end on similar type of LSRs. Also, in generalized 180 MPLS the type of a payload that can be carried by an LSP is extended 181 to allow such payloads as SONET/SDH, or 1 or 10Gb Ethernet. These 182 changes from traditional MPLS are reflected in how labels are 183 requested and communicated in generalized MPLS, see Sections 3.1 and 184 3.2. A special case of Lambda switching, called Waveband switching 185 is also described in Section 3.3. 187 Another basic difference between traditional and non-PSC types of 188 generalized MPLS LSPs, is that bandwidth allocation for an LSP can be 189 performed only in discrete units, see Section 3.1.3. There are also 190 likely to be (much) fewer labels on non-PSC links than on PSC links. 191 Note that the use of Forwarding Adjacencies (FA), see [MPLS- 192 HIERARCHY], provides a mechanism that may improve bandwidth 193 utilization, when bandwidth allocation can be performed only in 194 discrete units, as well as a mechanism to aggregate forwarding state, 195 thus allowing the number of required labels to be reduced. 197 Generalized MPLS allows for a label to be suggested by an upstream 198 node, see Section 3.4. This suggestion may be overridden by a 199 downstream node but, in some cases, at the cost of higher LSP setup 200 time. The suggested label is valuable when establishing LSPs through 201 certain kinds of optical equipment where there may be a lengthy (in 202 electrical terms) delay in configuring the switching fabric. For 203 example micro mirrors may have to be elevated or moved, and this 204 physical motion and subsequent damping takes time. If the labels and 205 hence switching fabric are configured in the reverse direction (the 206 norm) the MAPPING/Resv message may need to be delayed by 10's of 207 milliseconds per hop in order to establish a usable forwarding path. 209 Generalized MPLS extends on the notion of restricting the range of 210 labels that may be selected by a downstream node, see Section 3.5. 211 In generalized MPLS, an ingress or other upstream node may restrict 212 the labels that may be used by an LSP along either a single hop or 213 along the whole LSP path. This feature is driven from the optical 214 domain where there are cases where wavelengths used by the path must 215 be restricted either to a small subset of possible wavelengths, or to 216 one specific wavelength. This requirement occurs because some 217 equipment may only be able to generate a small set of the wavelengths 218 that intermediate equipment may be able to switch, or because 219 intermediate equipment may not be able to switch a wavelength at all, 220 being only able to redirect it to a different fiber. 222 While traditional traffic engineered MPLS (and even LDP) are 223 unidirectional, generalized MPLS supports the establishment of 224 bidirectional LSPs, see Section 4. The need for bidirectional LSPs 225 comes from non-PSC applications. There are multiple reasons why such 226 LSPs are needed, particularly possible resource contention when 227 allocating reciprocal LSPs via separate signaling sessions, and 228 simplifying failure restoration procedures in the non-PSC case. 229 Bidirectional LSPs also have the benefit of lower setup latency and 230 lower number of messages required during setup. 232 Generalized MPLS supports the communication of a specific label to 233 use on a specific interface, see Section 6. [GMPLS-RSVP] also 234 supports an RSVP specific mechanism for rapid failure notification. 236 Generalized MPLS also allows for the inclusion of technology specific 237 parameters in signaling. The intent is for all technology specific 238 parameters to be carried, when using RSVP, in the SENDER_TSPEC and 239 other related objects, and when using CR-LDP, in the Traffic 240 Parameters TLV. Technology specific formats will be defined on an as 241 needed basis. For an example definition, see [GMPLS-SONET]. 243 3. Label Related Formats 245 To deal with the widening scope of MPLS into the optical and time 246 domain, several new forms of "label" are required. These new forms 247 of label are collectively referred to as a "generalized label". A 248 generalized label contains enough information to allow the receiving 249 node to program its cross connect, regardless of the type of this 250 cross connect, such that the ingress segments of the path are 251 properly joined. This section defines a generalized label request, a 252 generalized label, support for waveband switching, suggested label 253 and label sets. 255 Note that since the nodes sending and receiving the new form of label 256 know what kinds of link they are using, the generalized label does 257 not contain a type field, instead the nodes are expected to know from 258 context what type of label to expect. 260 3.1. Generalized Label Request 262 The Generalized Label Request supports communication of 263 characteristics required to support the LSP being requested. These 264 characteristics include LSP encoding and LSP payload. Note that 265 these characteristics may be used by transit nodes, e.g., to support 266 penultimate hop popping. 268 The Generalized Label Request carries an LSP encoding parameter, 269 called LSP Encoding Type. This parameter indicates the encoding 270 type, e.g., SONET/SDH/GigE etc., that will be used with the data 271 associated with the LSP. The LSP Encoding Type represents the nature 272 of the LSP, and not the nature of the links that the LSP traverses. 273 A link may support a set of encoding formats, where support means 274 that a link is able to carry and switch a signal of one or more of 275 these encoding formats depending on the resource availability and 276 capacity of the link. For example, consider an LSP signaled with 277 "photonic" encoding. It is expected that such an LSP would be 278 supported with no electrical conversion and no knowledge of the 279 modulation and speed by the transit nodes. All other formats require 280 framing knowledge, and field parameters are broken into the framing 281 type and speed as shown below. 283 3.1.1. Required Information 285 The information carried in a Generalized Label Request is: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | LSP Enc. Type | Reserved | G-PID | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 LSP Encoding Type: 8 bits 295 Indicates the encoding of the LSP being requested. The 296 following shows permitted values and their meaning: 298 Value Type 299 ----- ---- 300 1 Packet 301 2 Ethernet V2/DIX 302 3 ANSI PDH 303 4 ETSI PDH 304 5 SDH ITU-T G.707 1996 305 6 SONET ANSI T1.105-1995 306 7 Digital Wrapper 307 8 Lambda (photonic) 308 9 Fiber 309 10 Ethernet 802.3 310 11 SDH ITU-T G.707 2000 311 12 SONET ANSI T1.105-2000 313 The ANSI PDH and ETSI PDH types designate these respective 314 networking technologies. DS1 and DS3 are examples of ANSI PDH 315 LSPs. An E1 LSP would be ETSI PDH. The Lambda encoding type 316 refers to the switching of wavelengths. The Fiber encoding 317 type refers to switching at the fiber port level. 319 Reserved: 8 bits 321 This field is reserved. It MUST be set to zero on transmission 322 and MUST be ignored on receipt. 324 Generalized PID (G-PID): 16 bits 326 An identifier of the payload carried by an LSP, i.e. an 327 identifier of the client layer of that LSP. This is used by 328 the nodes at the endpoints of the LSP, and in some cases by the 329 penultimate hop. Standard Ethertype values are used for packet 330 and Ethernet LSPs; other values are: 332 Value Type Technology 333 ----- ---- ---------- 334 0 Unknown All 335 1 DS1 SF ANSI-PDH 336 2 DS1 ESF ANSI-PDH 337 3 DS3 M23 ANSI-PDH 338 4 DS3 C-Bit Parity ANSI-PDH 339 5 Asynchronous mapping of E4 SDH 340 6 Asynchronous mapping of DS3/T3 SDH 341 7 Asynchronous mapping of E3 SDH 342 8 Bit synchronous mapping of E3 SDH 343 9 Byte synchronous mapping of E3 SDH 344 10 Asynchronous mapping of DS2/T2 SDH 345 11 Bit synchronous mapping of DS2/T2 SDH 346 12 Byte synchronous mapping of DS2/T2 SDH 347 13 Asynchronous mapping of E1 SDH 348 14 Byte synchronous mapping of E1 SDH 349 15 Byte synchronous mapping of 31 * DS0 SDH 350 16 Asynchronous mapping of DS1/T1 SDH 351 17 Bit synchronous mapping of DS1/T1 SDH 352 18 Byte synchronous mapping of DS1/T1 SDH 353 19 Same as 12 but in a VC-12 SDH 354 20 Same as 13 but in a VC-12 SDH 355 21 Same as 14 but in a VC-12 SDH 356 22 DS1 SF Asynchronous SONET 357 23 DS1 ESF Asynchronous SONET 358 24 DS3 M23 Asynchronous SONET 359 25 DS3 C-Bit Parity Asynchronous SONET 360 26 VT SONET 361 27 STS SONET 362 28 POS - No Scrambling, 16 bit CRC SONET 363 29 POS - No Scrambling, 32 bit CRC SONET 364 30 POS - Scrambling, 16 bit CRC SONET 365 31 POS - Scrambling, 32 bit CRC SONET 366 32 ATM mapping SONET, SDH 367 33 Ethernet Lambda, Fiber 368 34 SDH Lambda, Fiber 369 35 SONET Lambda, Fiber 370 36 Digital Wrapper Lambda, Fiber 371 37 Lambda Fiber 373 3.1.2. Bandwidth Encoding 375 Bandwidth encodings are carried in in 32 bit number in IEEE floating 376 point format (the unit is bytes per second). For non-packet LSPs, it 377 is useful to define discrete values to identify the bandwidth of the 378 LSP. Some typical values for the requested bandwidth are enumerated 379 below. (These values are guidelines.) Additional values will be 380 defined as needed. Bandwidth encoding values are carried in a per 381 protocol specific manner, see [GMPLS-RSVP] and [GMPLS-LDP]. It 382 should be noted that these bandwidth encodings do not apply to 383 technologies, such as SONET/SDH, for which bandwidth encodings are 384 not transported in a generic form. 386 Signal Type (Bit-rate) Value (Bytes/Sec) 387 (IEEE Floating point) 388 -------------- --------------- --------------------- 389 DS0 (0.064 Mbps) 0x45FA0000 390 DS1 (1.544 Mbps) 0x483C7A00 391 E1 (2.048 Mbps) 0x487A0000 392 DS2 (6.312 Mbps) 0x4940A080 393 E2 (8.448 Mbps) 0x4980E800 394 Ethernet (10.00 Mbps) 0x49989680 395 E3 (34.368 Mbps) 0x4A831A80 396 DS3 (44.736 Mbps) 0x4AAAA780 397 STS-1 (51.84 Mbps) 0x4AC5C100 398 Fast Ethernet (100.00 Mbps) 0x4B3EBC20 399 E4 (139.264 Mbps) 0x4B84D000 400 OC-3/STM-1 (155.52 Mbps) 0x4B9450C0 401 OC-12/STM-4 (622.08 Mbps) 0x4C9450C0 402 GigE (1000.00 Mbps) 0x4CEE6B28 403 OC-48/STM-1 (2488.32 Mbps) 0x4D9450C0 404 OC-192/STM-64 (9953.28 Mbps) 0x4E9450C0 405 10GigE-LAN (10000.00 Mbps) 0x4E9502F9 406 OC-768/STM-256 (39813.12 Mbps) 0x4F9450C0 408 3.2. Generalized Label 410 The Generalized Label extends the traditional label by allowing the 411 representation of not only labels which travel in-band with 412 associated data packets, but also labels which identify time-slots, 413 wavelengths, or space division multiplexed positions. For example, 414 the Generalized Label may carry a label that represents (a) a single 415 fiber in a bundle, (b) a single waveband within fiber, (c) a single 416 wavelength within a waveband (or fiber), or (d) a set of time-slots 417 within a wavelength (or fiber). It may also carry a label that 418 represents a generic MPLS label, a Frame Relay label, or an ATM label 419 (VCI/VPI). 421 A Generalized Label does not identify the "class" to which the label 422 belongs. This is implicit in the multiplexing capabilities of the 423 link on which the label is used. 425 A Generalized Label only carries a single level of label, i.e., it is 426 non-hierarchical. When multiple levels of label (LSPs within LSPs) 427 are required, each LSP must be established separately, see [MPLS- 428 HIERARCHY]. 430 Each Generalized Label object carries a variable length label 431 parameter. 433 3.2.1. Required Information 435 The information carried in a Generalized Label is: 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Label | 441 | ... | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Label: Variable 446 Carries label information. The interpretation of this field 447 depends on the type of the link over which the label is used. 449 3.2.1.1. Port and Wavelength Labels 451 Some configurations of fiber switching (FSC) and lambda switching 452 (LSC) use multiple data channels/links controlled by a single control 453 channel. In such cases the label indicates the data channel/link to 454 be used for the LSP. Note that this case is not the same as when 455 [MPLS-BUNDLING] is being used. 457 The information carried in a Port and Wavelength label is: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Label | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Label: 32 bits 467 Indicates port/fiber or lambda to be used, from the sender's 468 perspective. Values used in this field only have significance 469 between two neighbors, and the receiver may need to convert the 470 received value into a value that has local significance. 471 Values may be configured or dynamically determined using a 472 protocol such as [LMP]. 474 3.2.1.2. Other Labels 476 Generic MPLS labels and Frame Relay labels are encoded right 477 justified aligned in 32 bits (4 octets). ATM labels are encoded with 478 the VPI right justified in bits 0-15 and the VCI right justified in 479 bits 16-31. 481 3.3. Waveband Switching 483 A special case of lambda switching is waveband switching. A waveband 484 represents a set of contiguous wavelengths which can be switched 485 together to a new waveband. For optimization reasons it may be 486 desirable for an optical cross connect to optically switch multiple 487 wavelengths as a unit. This may reduce the distortion on the 488 individual wavelengths and may allow tighter separation of the 489 individual wavelengths. The Waveband Label is defined to support 490 this special case. 492 Waveband switching naturally introduces another level of label 493 hierarchy and as such the waveband is treated the same way all other 494 upper layer labels are treated. 496 As far as the MPLS protocols are concerned there is little difference 497 between a waveband label and a wavelength label except that 498 semantically the waveband can be subdivided into wavelengths whereas 499 the wavelength can only be subdivided into time or statistically 500 multiplexed labels. 502 3.3.1. Required information 504 Waveband switching uses the same format as the generalized label, see 505 section 3.2.1. 507 In the context of waveband switching, the generalized label has the 508 following format: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Waveband Id | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Start Label | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | End Label | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Waveband Id: 32 bits 521 A waveband identifier. The value is selected by the sender and 522 reused in all subsequent related messages. 524 Start Label: 32 bits 526 Indicates the channel identifier, from the sender's 527 perspective, of the lowest value wavelength making up the 528 waveband. 530 End Label: 32 bits 532 Indicates the channel identifier, from the sender's 533 perspective, of the highest value wavelength making up the 534 waveband. 536 Channel identifiers are established either by configuration or by 537 means of a protocol such as LMP [LMP]. They are normally used in the 538 label parameter of the Generalized Label one PSC and LSC. 540 3.4. Suggested Label 542 The Suggested Label is used to provide a downstream node with the 543 upstream node's label preference. This permits the upstream node to 544 start configuring it's hardware with the proposed label before the 545 label is communicated by the downstream node. Such early 546 configuration is valuable to systems that take non-trivial time to 547 establish a label in hardware. Such early configuration can reduce 548 setup latency, and may be important for restoration purposes where 549 alternate LSPs may need to be rapidly established as a result of 550 network failures. 552 The use of Suggested Label is only an optimization. If a downstream 553 node passes a different label upstream, an upstream LSR MUST 554 reconfigure itself so that it uses the label specified by the 555 downstream node, thereby maintaining the downstream control of a 556 label. 558 The information carried in a suggested label is identical to a 559 generalized label. 561 3.5. Label Set 563 The Label Set is used to limit the label choices of a downstream node 564 to a set of acceptable labels. This limitation applies on a per hop 565 basis. 567 There are four cases where a Label Set is useful in the optical 568 domain. The first case is where the end equipment is only capable of 569 transmitting and receiving on a small specific set of 570 wavelengths/bands. The second case is where there is a sequence of 571 interfaces which cannot support wavelength conversion (CI-incapable) 572 and require the same wavelength be used end-to-end over a sequence of 573 hops, or even an entire path. The third case is where it is 574 desirable to limit the amount of wavelength conversion being 575 performed to reduce the distortion on the optical signals. The last 576 case is where two ends of a link support different sets of 577 wavelengths. 579 Label Set is used to restrict label ranges that may be used for a 580 particular LSP between two peers. The receiver of a Label Set must 581 restrict its choice of labels to one which is in the Label Set. Much 582 like a label, a Label Set may be present across multiple hops. In 583 this case each node generates it's own outgoing Label Set, possibly 584 based on the incoming Label Set and the node's hardware capabilities. 585 This case is expected to be the norm for nodes with conversion 586 incapable (CI-incapable) interfaces. 588 The use of Label Set is optional, if not present, all labels from the 589 valid label range may be used. Conceptually the absence of a Label 590 Set implies a Label Set whose value is {U}, the set of all valid 591 labels. 593 3.5.1. Required Information 595 A label set is composed of one or more Label_Set objects/TLVs. Each 596 object/TLV contains one or more elements of the Label Set. Each 597 element is referred to as a subchannel identifier and has the same 598 format as a generalized label. 600 The information carried in a Label_Set is: 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Action | Reserved | Label Type | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Subchannel 1 | 608 | ... | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 : : : 611 : : : 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Subchannel N | 614 | ... | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Action: 8 bits 619 0 - Inclusive List 621 Indicates that the object/TLV contains one or more 622 subchannel elements that are included in the Label Set. 624 1 - Exclusive List 626 Indicates that the object/TLV contains one or more 627 subchannel elements that are excluded from the Label Set. 629 2 - Inclusive Range 631 Indicates that the object/TLV contains a range of labels. 632 The object/TLV contains two subchannel elements. The first 633 element indicates the start of the range. The second 634 element indicates the end of the range. A value of zero 635 indicates that there is no bound on the corresponding 636 portion of the range. 638 3 - Exclusive Range 640 Indicates that the object/TLV contains a range of labels 641 that are excluded from the Label Set. The object/TLV 642 contains two subchannel elements. The first element 643 indicates the start of the range. The second element 644 indicates the end of the range. A value of zero indicates 645 that there is no bound on the corresponding portion of the 646 range. 648 Reserved: 10 bits 650 This field is reserved. It MUST be set to zero on transmission 651 and MUST be ignored on receipt. 653 Label Type: 14 bits 655 Indicates the type and format of the labels carried in the 656 object/TLV. Values are signaling protocol specific. 658 Subchannel: 660 The subchannel represents the label (wavelength, fiber ... ) 661 which is eligible for allocation. This field has the same 662 format as described for labels under section 3.2. 664 Note that subchannel to local channel identifiers (e.g., 665 wavelength) mappings are a local matter. 667 4. Bidirectional LSPs 669 This section defines direct support of bidirectional LSPs. Support 670 is defined for LSPs that have the same traffic engineering 671 requirements including fate sharing, protection and restoration, 672 LSRs, and resource requirements (e.g., latency and jitter) in each 673 direction. In the remainder of this section, the term "initiator" is 674 used to refer to a node that starts the establishment of an LSP and 675 the term "terminator" is used to refer to the node that is the target 676 of the LSP. Note that for bidirectional LSPs, there is only one 677 "initiator" and one "terminator". 679 Normally to establish a bidirectional LSP when using [RSVP-TE] or 680 [CR-LDP] two unidirectional paths must be independently established. 681 This approach has the following disadvantages: 683 * The latency to establish the bidirectional LSP is equal to one 684 round trip signaling time plus one initiator-terminator signaling 685 transit delay. This not only extends the setup latency for 686 successful LSP establishment, but it extends the worst-case 687 latency for discovering an unsuccessful LSP to as much as two 688 times the initiator-terminator transit delay. These delays are 689 particularly significant for LSPs that are established for 690 restoration purposes. 692 * The control overhead is twice that of a unidirectional LSP. 693 This is because separate control messages (e.g. Path and Resv) 694 must be generated for both segments of the bidirectional LSP. 696 * Because the resources are established in separate segments, 697 route selection is complicated. There is also additional 698 potential race for conditions in assignment of resources, which 699 decreases the overall probability of successfully establishing 700 the bidirectional connection. 702 * It is more difficult to provide a clean interface for SONET 703 equipment that may rely on bidirectional hop-by-hop paths for 704 protection switching. 706 * Bidirectional optical LSPs (or lightpaths) are seen as a 707 requirement for many optical networking service providers. 709 With bidirectional LSPs both the downstream and upstream data paths, 710 i.e., from initiator to terminator and terminator to initiator, are 711 established using a single set of signaling messages. This reduces 712 the setup latency to essentially one initiator-terminator round trip 713 time plus processing time, and limits the control overhead to the 714 same number of messages as a unidirectional LSP. 716 4.1. Required Information 718 For bidirectional LSPs, two labels must be allocated. Bidirectional 719 LSP setup is indicated by the presence of an Upstream Label 720 object/TLV in the appropriate signaling message. An Upstream Label 721 has the same format as the generalized label, see Section 3.2. 723 4.2. Contention Resolution 725 Contention for labels may occur between two bidirectional LSP setup 726 requests traveling in opposite directions. This contention occurs 727 when both sides allocate the same resources (labels) at effectively 728 the same time. If there is no restriction on the labels that can be 729 used for bidirectional LSPs and if there are alternate resources, 730 then both nodes will pass different labels upstream and there is no 731 contention. However, if there is a restriction on the labels that 732 can be used for the bidirectional LSPs (for example, if they must be 733 physically coupled on a single I/O card), or if there are no more 734 resources available, then the contention must be resolved by other 735 means. To resolve contention, the node with the higher node ID will 736 win the contention and it MUST issue a PathErr/NOTIFICATION message 737 with a "Routing problem/Label allocation failure" indication. Upon 738 receipt of such an error, the node SHOULD try to allocate a different 739 Upstream label (and a different Suggested Label if used) to the 740 bidirectional path. However, if no other resources are available, 741 the node must proceed with standard error handling. 743 To reduce the probability of contention, one may impose a policy that 744 the node with the lower ID never suggests a label in the downstream 745 direction and always accepts a Suggested Label from an upstream node 746 with a higher ID. Furthermore, since the labels may be exchanged 747 using LMP, an alternative local policy could further be imposed such 748 that (with respect to the higher numbered node's label set) the 749 higher numbered node could allocate labels from the high end of the 750 label range while the lower numbered node allocates labels from the 751 low end of the label range. This mechanism would augment any close 752 packing algorithms that may be used for bandwidth (or wavelength) 753 optimization. One special case that should be noted when using RSVP 754 and supporting this approach is that the neighbor's node ID might not 755 be known when sending an initial Path message. When this case 756 occurs, a node should suggest a label chosen at random from the 757 available label space. 759 An example of contention between two nodes (PXC 1 and PXC 2) is shown 760 in Figure 1. In this example PXC 1 assigns an Upstream Label for the 761 channel corresponding to local BCId=2 (local BCId=7 on PXC 2) and 762 sends a Suggested Label for the channel corresponding to local BCId=1 763 (local BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream 764 Label for the channel corresponding to its local BCId=6 (local BCId=1 765 on PXC 1) and sends a Suggested Label for the channel corresponding 766 to its local BCId=7 (local BCId=2 on PXC 1). If there is no 767 restriction on the labels that can be used for bidirectional LSPs and 768 if there are alternate resources available, then both PXC 1 and PXC 2 769 will pass different labels upstream and the contention is resolved 770 naturally (see Fig. 2). However, if there is a restriction on the 771 labels that can be used for bidirectional LSPs (for example, if they 772 must be physically coupled on a single I/O card), then the contention 773 must be resolved using the node ID (see Fig. 3). 775 +------------+ +------------+ 776 + PXC 1 + + PXC 2 + 777 + + SL1,UL2 + + 778 + 1 +------------------------>+ 6 + 779 + + UL1, SL2 + + 780 + 2 +<------------------------+ 7 + 781 + + + + 782 + + + + 783 + 3 +------------------------>+ 8 + 784 + + + + 785 + 4 +<------------------------+ 9 + 786 +------------+ +------------+ 787 Figure 1. Label Contention 789 In this example, PXC 1 assigns an Upstream Label using BCId=2 (BCId=7 790 on PXC 2) and a Suggested Label using BCId=1 (BCId=6 on PXC 2). 791 Simultaneously, PXC 2 assigns an Upstream Label using BCId=6 (BCId=1 792 on PXC 1) and a Suggested Label using BCId=7 (BCId=2 on PXC 1). 794 +------------+ +------------+ 795 + PXC 1 + + PXC 2 + 796 + + UL2 + + 797 + 1 +------------------------>+ 6 + 798 + + UL1 + + 799 + 2 +<------------------------+ 7 + 800 + + + + 801 + + L1 + + 802 + 3 +------------------------>+ 8 + 803 + + L2 + + 804 + 4 +<------------------------+ 9 + 805 +------------+ +------------+ 806 Figure 2. Label Contention Resolution without resource restrictions 808 In this example, there is no restriction on the labels that can be 809 used by the bidirectional connection and there is no contention. 811 +------------+ +------------+ 812 + PXC 1 + + PXC 2 + 813 + + UL2 + + 814 + 1 +------------------------>+ 6 + 815 + + L2 + + 816 + 2 +<------------------------+ 7 + 817 + + + + 818 + + L1 + + 819 + 3 +------------------------>+ 8 + 820 + + UL1 + + 821 + 4 +<------------------------+ 9 + 822 +------------+ +------------+ 823 Figure 3. Label Contention Resolution with resource restrictions 825 In this example, labels 1,2 and 3,4 on PXC 1 (labels 6,7 and 8,9 on 826 PXC 2, respectively) must be used by the same bidirectional 827 connection. Since PXC 2 has a higher node ID, it wins the contention 828 and PXC 1 must use a different set of labels. 830 5. Notification on Label Error 832 There are cases in traditional MPLS and in GMPLS that result in an 833 error message containing an "Unacceptable label value" indication, 834 see [RSVP-TE], [GMPLS-LDP] and [GMPLS-RSVP]. When these cases occur, 835 it can useful for the node generating the error message to indicate 836 which labels would be acceptable. To cover this case, GMPLS 837 introduces the ability to convey such information via the "Acceptable 838 Label Set". An Acceptable Label Set is carried in appropriate 839 protocol specific error messages, see [GMPLS-LDP] and [GMPLS-RSVP]. 841 The format of an Acceptable Label Set is identical to a Label Set, 842 see section 3.5.1. 844 6. Explicit Label Control 846 In traditional MPLS, the interfaces used by an LSP may be controlled 847 via an explicit route, i.e., ERO or ER-Hop. This enables the 848 inclusion of a particular node/interface, and the termination of an 849 LSP on a particular outgoing interface of the egress LSR. Where the 850 interface may be numbered or unnumbered, see [MPLS-UNNUM]. 852 There are cases where the existing explicit route semantics do not 853 provide enough information to control the LSP to the degree desired. 854 This occurs in the case when the LSP initiator wishes to select a 855 label used on a link. Specifically, the problem is that ERO and ER- 856 Hop do not support explicit label sub-objects. An example case where 857 such a mechanism is desirable is where there are two LSPs to be 858 "spliced" together, i.e., where the tail of the first LSP would be 859 "spliced" into the head of the second LSP. This last case is more 860 likely to be used in the non-PSC classes of links. 862 To cover this case, the Label ERO subobject / ER Hop is introduced. 864 6.1. Required Information 866 The Label Explicit Route contains: 868 L: 1 bit 870 This bit must be set to 0. 872 U: 1 bit 874 This bit indicates the direction of the label. It is 0 for the 875 downstream label. It is set to 1 for the upstream label and is 876 only used on bidirectional LSPs. 878 Label: Variable 880 This field identifies the label to be used. The format of this 881 field is identical to the one used by the Label field in 882 Generalized Label, see Section 3.2.1. 884 Placement and ordering of these parameters are signaling protocol 885 specific. 887 7. Protection Information 889 Protection Information is carried in a new object/TLV. They are used 890 to indicate link related protection attributes of a requested LSP. 891 The use of Protection Information for a particular LSP is optional. 892 Protection Information currently indicates the link protection type 893 desired for the LSP. If a particular protection type, i.e., 1+1, or 894 1:N, is requested, then a connection request is processed only if the 895 desired protection type can be honored. Note that the protection 896 capabilities of a link may be advertised in routing, see [GMPLS-ISIS, 897 GMPLS-OSPF]. Path computation algorithms may take this information 898 into account when computing paths for setting up LSPs. 900 Protection Information also indicates if the LSP is a primary or 901 secondary LSP. A secondary LSP is a backup to a primary LSP. The 902 resources of a secondary LSP are not used until the primary LSP 903 fails. The resources allocated for a secondary LSP MAY be used by 904 other LSPs until the primary LSP fails over to the secondary LSP. At 905 that point, any LSP that is using the resources for the secondary LSP 906 MUST be preempted. 908 7.1. Required Information 910 The following information is carried in Protection Information: 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 |S| Reserved | Link Flags| 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Secondary (S): 1 bit 920 When set, indicates that the requested LSP is a secondary LSP. 922 Link Flags: 6 bits 924 Indicates desired link protection type. As previously 925 mentioned, protection capabilities of a link may be advertised 926 in routing. A value of 0 implies that any, including no, link 927 protection may be used. More than one bit may be set to 928 indicate when multiple protection types are acceptable. When 929 multiple bits are set and multiple protection types are 930 available, the choice of protection type is a local (policy) 931 decision. 933 The following flags are defined: 935 0x20 Enhanced 937 Indicates that a protection scheme that is more reliable 938 than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS- 939 SPRING. 941 0x10 Dedicated 1+1 943 Indicates that a dedicated link layer protection scheme, 944 i.e., 1+1 protection, should be used to support the LSP. 946 0x08 Dedicated 1:1 948 Indicates that a dedicated link layer protection scheme, 949 i.e., 1:1 protection, should be used to support the LSP. 951 0x04 Shared 953 Indicates that a shared link layer protection scheme, 954 such as 1:N protection, should be used to support the 955 LSP. 957 0x02 Unprotected 959 Indicates that the LSP should not use any link layer 960 protection. 962 0x01 Extra Traffic 964 Indicates that the LSP should use links that are 965 protecting other (primary) traffic. Such LSPs may be 966 preempted when the links carrying the (primary) traffic 967 being protected fail. 969 8. Acknowledgments 971 This draft is the work of numerous authors and consists of a 972 composition of a number of previous drafts in this area. A list of 973 the drafts from which material and ideas were incorporated follows: 975 draft-saha-rsvp-optical-signaling-00.txt 976 draft-lang-mpls-rsvp-oxc-00.txt 977 draft-kompella-mpls-optical-00.txt 978 draft-fan-mpls-lambda-signaling-00.txt 980 Valuable comments and input were received from a number of people, 981 including Igor Bryskin, Adrian Farrel, Ben Mack-Crane and Dimitri 982 Papadimitriou. 984 9. Security Considerations 986 This draft introduce no new security considerations to either [CR- 987 LDP] or [RSVP-TE]. 989 10. References 991 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 992 draft-ietf-mpls-cr-ldp-05.txt, February, 2001. 994 [GMPLS-ISIS] Kompella, et. al, "IS-IS Extensions in Support of 995 Generalized MPLS", Internet Draft, 996 draft-ietf-isis-gmpls-extensions-02.txt, Feb., 2001 998 [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - 999 CR-LDP Extensions", Internet Draft, 1000 draft-ietf-mpls-generalized-cr-ldp-02.txt, 1001 April, 2001. 1003 [GMPLS-OSPF] Kompella, et. al., "OSPF Extensions in Support of GMPLS", 1004 Internet Draft, draft-kompella-ospf-gmpls- 1005 extensions-01.txt, 1006 March, 2001. 1008 [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - 1009 RSVP-TE Extensions", Internet Draft, 1010 draft-ietf-mpls-generalized-rsvp-te-02.txt, 1011 April, 2001. 1013 [GMPLS-SONET] Ashwood-Smith, P. et al, "GMPLS - SONET / SDH Specifics", 1014 Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-00.txt, 1015 April, 2001. 1017 [LDP] Andersson et al., "LDP Specification", RFC 3036. 1019 [LMP] Lang, et al. "Link Management Protocol", 1020 Internet Draft, draft-ietf-mpls-lmp-02.txt, March, 2001. 1022 [MPLS-ARCH] Rosen et al., "Multiprotocol label switching 1023 Architecture", RFC 3031. 1025 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling 1026 in MPLS Traffic Engineering", Internet Draft, 1027 draft-kompella-mpls-bundle-05.txt, Feb., 2001. 1029 [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 1030 MPLS TE", Internet Draft, 1031 draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. 1033 [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 1034 in RSVP-TE", Internet Draft, 1035 draft-ietf-mpls-rsvp-unnum-01.txt, February 2001 1037 [RSVP-TE] Awduche, et. al., "RSVP-TE: Extensions to RSVP for LSP 1038 Tunnels," Internet Draft, 1039 draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, Feb., 2001. 1041 [RECOVERY] Sharma, et al "A Framework for MPLS-based Recovery," 1042 draft-ieft-mpls-recovery-frmwrk-02.txt, March, 2001 1044 11. Authors' Addresses 1046 Peter Ashwood-Smith 1047 Nortel Networks Corp. 1048 P.O. Box 3511 Station C, 1049 Ottawa, ON K1Y 4H7 1050 Canada 1051 Phone: +1 613 763 4534 1052 Email: petera@nortelnetworks.com 1054 Ayan Banerjee 1055 Calient Networks 1056 5853 Rue Ferrari 1057 San Jose, CA 95138 1058 Phone: +1 408 972-3645 1059 Email: abanerjee@calient.net 1061 Lou Berger 1062 Movaz Networks, Inc. 1063 7926 Jones Branch Drive 1064 Suite 615 1065 McLean VA, 22102 1066 Phone: +1 703 847-1801 1067 Email: lberger@movaz.com 1069 Greg Bernstein 1070 Ciena Corporation 1071 10480 Ridgeview Court 1072 Cupertino, CA 94014 1073 Phone: +1 408 366 4713 1074 Email: greg@ciena.com 1075 John Drake 1076 Calient Networks 1077 5853 Rue Ferrari 1078 San Jose, CA 95138 1079 Phone: +1 408 972 3720 1080 Email: jdrake@calient.net 1082 Yanhe Fan 1083 Axiowave Networks, Inc. 1084 100 Nickerson Road 1085 Marlborough, MA 01752 1086 Phone: +1 508 460 6969 Ext. 627 1087 Email: yfan@axiowave.com 1089 Kireeti Kompella 1090 Juniper Networks, Inc. 1091 1194 N. Mathilda Ave. 1092 Sunnyvale, CA 94089 1093 Email: kireeti@juniper.net 1095 Jonathan P. Lang 1096 Calient Networks 1097 25 Castilian 1098 Goleta, CA 93117 1099 Email: jplang@calient.net 1101 Eric Mannie 1102 EBONE 1103 Terhulpsesteenweg 6A 1104 1560 Hoeilaart - Belgium 1105 Phone: +32 2 658 56 52 1106 Mobile: +32 496 58 56 52 1107 Fax: +32 2 658 51 18 1108 Email: eric.mannie@ebone.com 1110 Bala Rajagopalan 1111 Tellium, Inc. 1112 2 Crescent Place 1113 P.O. Box 901 1114 Oceanport, NJ 07757-0901 1115 Phone: +1 732 923 4237 1116 Fax: +1 732 923 9804 1117 Email: braja@tellium.com 1119 Yakov Rekhter 1120 Juniper Networks, Inc. 1121 Email: yakov@juniper.net 1122 Debanjan Saha 1123 Tellium Optical Systems 1124 2 Crescent Place 1125 Oceanport, NJ 07757-0901 1126 Phone: +1 732 923 4264 1127 Fax: +1 732 923 9804 1128 Email: dsaha@tellium.com 1130 Vishal Sharma 1131 Jasmine Networks, Inc. 1132 3061 Zanker Road, Suite B 1133 San Jose, CA 95134 1134 Phone: +1 408 895 5030 1135 Fax: +1 408 895 5050 1136 Email: vsharma@jasminenetworks.com 1138 George Swallow 1139 Cisco Systems, Inc. 1140 250 Apollo Drive 1141 Chelmsford, MA 01824 1142 Voice: +1 978 244 8143 1143 Email: swallow@cisco.com 1145 Z. Bo Tang 1146 Tellium, Inc. 1147 2 Crescent Place 1148 P.O. Box 901 1149 Oceanport, NJ 07757-0901 1150 Phone: +1 732 923 4231 1151 Fax: +1 732 923 9804 1152 Email: btang@tellium.com 1154 Generated on: Tue May 1 16:22:55 EDT 2001