idnits 2.17.1 draft-ietf-mpls-generalized-cr-ldp-03.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 62 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-RSVP], [GMPLS-SIG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 8382 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) == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-02 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-crldp-unnum-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 2 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 - CR-LDP Extensions 21 draft-ietf-mpls-generalized-cr-ldp-03.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 CR-LDP signaling required to 49 support Generalized MPLS. Generalized MPLS extends MPLS to encompass 50 time-division (e.g. SONET ADMs), wavelength (optical lambdas) and 51 spatial switching (e.g. incoming port or fiber to outgoing port or 52 fiber). This document presents a CR-LDP specific description of the 53 extensions. An RSVP-TE specific description can be found in [GMPLS- 54 RSVP]. A generic functional description is presented in [GMPLS-SIG]. 56 Contents 58 1 Introduction .............................................. 3 59 2 Label Related Formats .................................... 3 60 2.1 Generalized Label Request ................................. 3 61 2.1.1 Procedures ................................................ 4 62 2.1.2 Bandwidth Encoding ........................................ 5 63 2.2 Generalized Label ......................................... 5 64 2.2.1 Procedures ................................................ 5 65 2.3 Waveband Switching ........................................ 6 66 2.3.1 Procedures ................................................ 6 67 2.4 Suggested Label ........................................... 7 68 2.5 Label Set ................................................. 7 69 2.5.1 Procedures ................................................ 7 70 3 Bidirectional LSPs ........................................ 8 71 3.1 Procedures ................................................ 9 72 4 Notification on Label Error ............................... 9 73 5 Explicit Label Control .................................... 10 74 5.1 Procedures ................................................ 10 75 6 Protection TLV ............................................ 11 76 6.1 Procedures ................................................ 12 77 7 Acknowledgments ........................................... 12 78 8 Security Considerations ................................... 12 79 9 References ................................................ 12 80 10 Authors' Addresses ........................................ 13 81 Changes from previous version: 83 o Fixed Label Set format 85 1. Introduction 87 Generalized MPLS extends MPLS from supporting packet (PSC) interfaces 88 and switching to include support of three new classes of interfaces 89 and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and 90 Fiber-Switch (FSC). A functional description of the extensions to 91 MPLS signaling needed to support the new classes of interfaces and 92 switching is provided in [GMPLS-SIG]. This document presents CR-LDP 93 specific formats and mechanisms needed to support all four classes of 94 interfaces. RSVP-TE extensions can be found in [GMPLS-RSVP]. 96 [GMPLS-SIG] should be viewed as a companion document to this 97 document. The format of this document parallels [GMPLS-SIG]. It 98 should be noted that the RSVP-TE specific version of Generalized MPLS 99 includes RSVP specific support for rapid failure notification, see 100 Section 4 [GMPLS-RSVP]. For CR-LDP there is not currently a similar 101 mechanism. When a failure is detected it will be propagated with 102 RELEASE/WITHDRAW messages radially outward from the point of failure. 103 Resources are to be released in this phase and actual resource 104 information may be fed back to the source using a feedback 105 mechanisms. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2. Label Related Formats 113 This section defines formats for a generalized label request, a 114 generalized label, support for waveband switching, suggested label 115 and label sets. 117 2.1. Generalized Label Request 119 A REQUEST message SHOULD contain as specific an LSP Encoding Type as 120 possible to allow the maximum flexibility in switching by transit 121 LSRs. A Generalized Label Request TLV is set by the ingress node, 122 transparently passed by transit nodes, and used by the egress node. 124 The format of a Generalized Label Request is: 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 |U|F| 0x0901 | Length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | LSP Enc. Type | Reserved | G-PID | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 See [GMPLS-SIG] for a description of parameters. 136 2.1.1. Procedures 138 A node processing a REQUEST message containing a Generalized Label 139 Request must verify that the requested parameters can be satisfied by 140 the incoming interface, the node and by the outgoing interface. The 141 node may either directly support the LSP or it may use a tunnel (FA), 142 i.e., another class of switching. In either case, each parameter 143 must be checked. 145 Note that local node policy dictates when tunnels may be used and 146 when they may be created. Local policy may allow for tunnels to be 147 dynamically established or may be solely administratively controlled. 148 For more information on tunnels and processing of ER hops when using 149 tunnels see [MPLS-HIERARCHY]. 151 Transit and egress nodes MUST verify that the node itself and, where 152 appropriate, that the outgoing interface or tunnel can support the 153 requested LSP Encoding Type. If encoding cannot be supported, the 154 node MUST generate a NOTIFICATION message, with a "Routing 155 problem/Unsupported Encoding" indication. 157 The G-PID parameter is normally only examined at the egress. If the 158 indicated G-PID cannot be supported then the egress MUST generate a 159 NOTIFICATION message, with a "Routing problem/Unsupported GPID" 160 indication. In the case of PSC and when penultimate hop popping 161 (PHP) is requested, the penultimate hop also examines the (stored) G- 162 PID during the processing of the MAPPING message. In this case if 163 the G-PID is not supported, then the penultimate hop MUST generate a 164 NOTIFICATION message with a "Routing problem/Unacceptable label 165 value" indication. The generated NOTIFICATION message MAY include an 166 Acceptable Label Set, see Section 4. 168 When an error message is not generated, normal processing occurs. In 169 the transit case this will typically result in a REQUEST message 170 being propagated. In the egress case and PHP special case this will 171 typically result in a MAPPING message being generated. 173 2.1.2. Bandwidth Encoding 175 Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV. 176 See [GMPLS-SIG] for a definition of values to be used for specific 177 signal types. These values are set in the Peak and Committed Data 178 Rate fields of the Traffic Parameters TLV. Other bandwidth/service 179 related parameters in the TLV are ignored and carried transparently. 181 2.2. Generalized Label 183 The format of a Generalized Label is: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 |U|F| 0x0902 | Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Label | 191 | ... | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 See [GMPLS-SIG] for a description of parameters and encoding of 195 labels. 197 2.2.1. Procedures 199 The Generalized Label travels in the upstream direction in MAPPING 200 messages. 202 The presence of both a generalized and normal label TLV in a MAPPING 203 message is a protocol error and should treated as a malformed message 204 by the recipient. 206 The recipient of a MAPPING message containing a Generalized Label 207 verifies that the values passed are acceptable. If the label is 208 unacceptable then the recipient MUST generate a NOTIFICATION message 209 with a "Routing problem/MPLS label allocation failure" indication. 210 The generated NOTIFICATION message MAY include an Acceptable Label 211 Set, see Section 4. 213 2.3. Waveband Switching 215 Waveband switching uses the same format as the generalized label, see 216 section 2.2. The type (0x0903) is assigned for the Waveband Label. 218 In the context of waveband switching, the generalized label has the 219 following format: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |U|F| 0x0903 | Length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Waveband Id | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Start Label | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | End Label | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 See [GMPLS-SIG] for a description of parameters. 235 2.3.1. Procedures 237 The procedures defined in Section 2.2.1 apply to waveband switching. 238 This includes generating a NOTIFICATION message with a "Routing 239 problem/MPLS label allocation failure" indication if any of the label 240 fields are unrecognized or unacceptable. 242 Additionally, when a waveband is switched to another waveband, it is 243 possible that the wavelengths within the waveband will be mirrored 244 about a center frequency. When this type of switching is employed, 245 the start and end label in the waveband label TLV MUST be flipped 246 before forwarding the label TLV with the new waveband Id. In this 247 manner an egress/ingress LSR which receives a waveband label which 248 has these values inverted, knows that it must also invert its egress 249 association to pick up the proper wavelengths. Without this 250 mechanism and with an odd number of mirrored switching operations, 251 the egress LSRs will not know that an input wavelength of say L1 will 252 emerge from the waveband tunnel as L100. 254 This operation MUST be performed in both directions when a 255 bidirectional waveband tunnel is being established. 257 2.4. Suggested Label 259 The format of a suggested label is identical to a generalized label. 260 It is used in REQUEST messages. Suggested Label uses type = 0x904. 262 Errors in received Suggested Labels MUST be ignored. This includes 263 any received inconsistent or unacceptable values. 265 2.5. Label Set 267 The format of a Label_Set is: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |U|F| type=0x0905 | Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Action | Reserved | Label Type | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Subchannel 1 | 277 | ... | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 : : : 280 : : : 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Subchannel N | 283 | ... | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Label Type: 14 bits 288 Indicates the type and format of the labels carried in the TLV. 289 Values match the TLV type of the appropriate Label TLV. 291 See [GMPLS-SIG] for a description of other parameters. 293 2.5.1. Procedures 295 A Label Set is defined via one or more Label_Set TLVs. Specific 296 labels/subchannels can be added to or excluded from a Label Set via 297 Action zero (0) and one (1) TLVs respectively. Ranges of 298 labels/subchannels can be added to or excluded from a Label Set via 299 Action two (2) and three (3) TLVs respectively. When the Label_Set 300 TLVs only list labels/subchannels to exclude, this implies that all 301 other labels are acceptable. 303 The absence of any Label_Set TLVs implies that all labels are 304 acceptable. A Label Set is included when a node wishes to restrict 305 the label(s) that may be used downstream. 307 On reception of a REQUEST message, the receiving node will restrict 308 its choice of labels to one which is in the Label Set. Nodes capable 309 of performing label conversion may also remove the Label Set prior to 310 forwarding the REQUEST message. If the node is unable to pick a 311 label from the Label Set or if there is a problem parsing the 312 Label_Set TLVs, then the request is terminated and a NOTIFICATION 313 message with a "Routing problem/Label Set" indication MUST be 314 generated. It is a local matter if the Label Set is stored for later 315 selection on the MAPPING or if the selection is made immediately for 316 propagation in the MAPPING. 318 On reception of a REQUEST message, the Label Set represented in the 319 message is compared against the set of available labels at the 320 downstream interface and the resulting intersecting Label Set is 321 forwarded in a REQUEST message. When the resulting Label Set is 322 empty, the REQUEST must be terminated, and a NOTIFICATION message, 323 and a "Routing problem/Label Set" indication MUST be generated. Note 324 that intersection is based on the physical labels (actual 325 wavelength/band values) which may have different logical values on 326 different links, as a result it is the responsibility of the node to 327 map these values so that they have a consistent physical meaning, or 328 to drop the particular values from the set if no suitable logical 329 label value exists. 331 When processing a MAPPING message at an intermediate node, the label 332 propagated upstream MUST fall within the Label Set. 334 Note, on reception of a MAPPING message a node that is incapable of 335 performing label conversion has no other choice than to use the same 336 physical label (wavelength/band) as received in the MAPPING message. 337 In this case, the use and propagation of a Label Set will 338 significantly reduce the chances that this allocation will fail. 340 3. Bidirectional LSPs 342 Bidirectional LSP setup is indicated by the presence of an Upstream 343 Label in the REQUEST message. An Upstream Label has the same format 344 as the generalized label, see Section 2.2. Upstream Label uses 345 type=0x0906 347 3.1. Procedures 349 The process of establishing a bidirectional LSP follows the 350 establishment of a unidirectional LSP with some additions. To 351 support bidirectional LSPs an Upstream Label is added to the REQUEST 352 message. The Upstream Label MUST indicate a label that is valid for 353 forwarding at the time the REQUEST message is sent. 355 When a REQUEST message containing an Upstream Label is received, the 356 receiver first verifies that the upstream label is acceptable. If 357 the label is not acceptable, the receiver MUST issue a NOTIFICATION 358 message with a "Routing problem/Unacceptable label value" indication. 359 The generated NOTIFICATION message MAY include an Acceptable Label 360 Set, see Section 4. 362 An intermediate node must also allocate a label on the outgoing 363 interface and establish internal data paths before filling in an 364 outgoing Upstream Label and propagating the REQUEST message. If an 365 intermediate node is unable to allocate a label or internal 366 resources, then it MUST issue a NOTIFICATION message with a "Routing 367 problem/Label allocation failure" indication. 369 Terminator nodes process REQUEST messages as usual, with the 370 exception that the upstream label can immediately be used to 371 transport data traffic associated with the LSP upstream towards the 372 initiator. 374 When a bidirectional LSP is removed, both upstream and downstream 375 labels are invalidated and it is no longer valid to send data using 376 the associated labels. 378 4. Notification on Label Error 380 This section defines the Acceptable_Label_Set TLV to support 381 Notification on Label Error per [GMPLS-SIG]. An Acceptable_Label_Set 382 TLV uses a type value of 0x0907. The remaining contents of the TLV 383 have the identical format as the Label_Set TLV, see Section 2.5. 385 Acceptable_Label_Set TLVs may be carried in NOTIFICATION messages. 386 The procedures for defining an Acceptable Label Set follow the 387 procedures for defining a Label Set, see Section 2.5.1. 388 Specifically, an Acceptable Label Set is defined via one or more 389 Acceptable_Label_Set TLVs. Specific labels/subchannels can be added 390 to or excluded from an Acceptable Label Set via Action zero (0) and 391 one (1) TLVs respectively. Ranges of labels/subchannels can be added 392 to or excluded from an Acceptable Label Set via Action two (2) and 393 three (3) TLVs respectively. When the Acceptable_Label_Set TLVs only 394 list labels/subchannels to exclude, this implies that all other 395 labels are acceptable. 397 The inclusion of Acceptable_Label_Set TLVs is optional. If included, 398 the NOTIFICATION message SHOULD contain a "Routing 399 problem/Unacceptable label value" indication. The absence of 400 Acceptable_Label_Set TLVs does not have any specific meaning. 402 5. Explicit Label Control 404 The Label ER-Hop is defined as follows: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |0|0| 0x0806 | Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 |L|U| Reserved | Label | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Label (continued) | 414 | ... | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 See [GMPLS-SIG] for a description of L, U and Label parameters. 419 5.1. Procedures 421 The Label ER-Hop follows a ER-Hop containing the IP address, or the 422 interface identifier [MPLS-UNNUM], associated with the link on which 423 it is to be used. The preceding ER-Hop must be strict. Up to two 424 label ER-Hops may be present, one for the downstream label and one 425 for the upstream label. The following SHOULD result in "Bad 426 EXPLICIT_ROUTE" errors: 427 - If the first label ER-Hop is not preceded by a ER-Hop 428 containing an IP address, or a interface identifier 429 [MPLS-UNNUM], associated with an output link. 430 - For a label ER-Hop to follow a ER-Hop that has the L-bit 431 set 432 - On unidirectional LSP setup, for there to be a label ER-Hop 433 with the U-bit set 434 - For there to be two label ER-Hops with the same U-bit values 436 To support the label ER-Hop, a node must check to see if the ER-Hop 437 following it's associate address/interface is a label ER-Hop. If it 438 is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops 439 for bidirectional LSPs. If the U-bit of the ER-Hop being examined is 440 clear (0), then value of the label is copied into a new Label_Set 441 TLV. This Label_Set TLV MUST be included on the corresponding 442 outgoing MAPPING message. 444 If the U-bit of the ER-Hop being examined is set (1), then value of 445 the label is label to be used for upstream traffic associated with 446 the bidirectional LSP. If this label is not acceptable, a "Bad 447 EXPLICIT_ROUTE" error SHOULD be generated. If the label is 448 acceptable, the label is copied into a new Upstream Label TLV. This 449 Upstream Label TLV MUST be included on the corresponding outgoing 450 MAPPING message. 452 After processing, the label ER-Hops are removed from the ER. 454 Note an implication of the above procedures is that the label ER-Hop 455 should never be the first ER-Hop in a newly received message. If the 456 label ER-Hop is the the first ER-Hop an a received ER, then it SHOULD 457 be treated as a "Bad strict node" error. 459 Procedures by which an LSR at the head-end of an LSP obtains the 460 information needed to construct the Label ER-Hop are outside the 461 scope of this document. 463 6. Protection TLV 465 The use of the Protection TLV is optional. The TLV is included to 466 indicate specific protection attributes of an LSP. 468 The format of Protection Information TLV is: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |U|F| 0x0908 | Length | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 |S| Reserved | Link Flags| 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 See [GMPLS-SIG] for a description of parameters. 480 6.1. Procedures 482 Transit nodes processing a REQUEST message containing a Protection 483 TLV MUST verify that the requested protection can be satisfied by the 484 outgoing interface or tunnel (FA). If it cannot, the node MUST 485 generate a NOTIFICATION message, with a "Routing problem/Unsupported 486 Link Protection" indication. 488 7. Acknowledgments 490 This draft is the work of numerous authors and consists of a 491 composition of a number of previous drafts in this area. A list of 492 the drafts from which material and ideas were incorporated follows: 494 draft-saha-rsvp-optical-signaling-00.txt 495 draft-lang-mpls-rsvp-oxc-00.txt 496 draft-kompella-mpls-optical-00.txt 497 draft-fan-mpls-lambda-signaling-00.txt 499 Valuable comments and input were received from a number of people, 500 notably Adrian Farrel. 502 8. Security Considerations 504 This draft introduce no new security considerations to [CR-LDP]. 506 9. References 508 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 509 draft-ietf-mpls-cr-ldp-05.txt, Feb., 2001. 511 [MPLS-HIERARCHY] Kompella, K., and Rekhter, Y., "LSP Hierarchy with 512 MPLS TE", Internet Draft, 513 draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. 514 [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 515 in CR-LDP", Internet Draft, 516 draft-ietf-mpls-crldp-unnum-01.txt, February 2001 518 [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - 519 RSVP-TE Extensions", Internet Draft, 520 draft-ietf-mpls-generalized-rsvp-te-01.txt, 521 February 2001. 523 [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - 524 Signaling Functional Description", Internet Draft, 525 draft-ietf-mpls-generalized-signaling-02.txt, 526 February 2001. 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels," RFC 2119. 531 10. Authors' Addresses 533 Peter Ashwood-Smith 534 Nortel Networks Corp. 535 P.O. Box 3511 Station C, 536 Ottawa, ON K1Y 4H7 537 Canada 538 Phone: +1 613 763 4534 539 Email: petera@nortelnetworks.com 541 Ayan Banerjee 542 Calient Networks 543 5853 Rue Ferrari 544 San Jose, CA 95138 545 Phone: +1 408 972-3645 546 Email: abanerjee@calient.net 548 Lou Berger 549 Movaz Networks, Inc. 550 7926 Jones Branch Drive 551 Suite 615 552 McLean VA, 22102 553 Phone: +1 703 847-1801 554 Email: lberger@movaz.com 556 Greg Bernstein 557 Ciena Corporation 558 10480 Ridgeview Court 559 Cupertino, CA 94014 560 Phone: +1 408 366 4713 561 Email: greg@ciena.com 563 John Drake 564 Calient Networks 565 5853 Rue Ferrari 566 San Jose, CA 95138 567 Phone: +1 408 972 3720 568 Email: jdrake@calient.net 569 Yanhe Fan 570 Axiowave Networks, Inc. 571 100 Nickerson Road 572 Marlborough, MA 01752 573 Phone: +1 508 460 6969 Ext. 627 574 Email: yfan@axiowave.com 576 Kireeti Kompella 577 Juniper Networks, Inc. 578 1194 N. Mathilda Ave. 579 Sunnyvale, CA 94089 580 Email: kireeti@juniper.net 582 Jonathan P. Lang 583 Calient Networks 584 25 Castilian 585 Goleta, CA 93117 586 Email: jplang@calient.net 588 Eric Mannie 589 EBONE 590 Terhulpsesteenweg 6A 591 1560 Hoeilaart - Belgium 592 Phone: +32 2 658 56 52 593 Mobile: +32 496 58 56 52 594 Fax: +32 2 658 51 18 595 Email: eric.mannie@ebone.com 597 Bala Rajagopalan 598 Tellium, Inc. 599 2 Crescent Place 600 P.O. Box 901 601 Oceanport, NJ 07757-0901 602 Phone: +1 732 923 4237 603 Fax: +1 732 923 9804 604 Email: braja@tellium.com 606 Yakov Rekhter 607 Juniper Networks, Inc. 608 Email: yakov@juniper.net 609 Debanjan Saha 610 Tellium Optical Systems 611 2 Crescent Place 612 Oceanport, NJ 07757-0901 613 Phone: +1 732 923 4264 614 Fax: +1 732 923 9804 615 Email: dsaha@tellium.com 617 Vishal Sharma 618 Jasmine Networks, Inc. 619 3061 Zanker Road, Suite B 620 San Jose, CA 95134 621 Phone: +1 408 895 5030 622 Fax: +1 408 895 5050 623 Email: vsharma@jasminenetworks.com 625 George Swallow 626 Cisco Systems, Inc. 627 250 Apollo Drive 628 Chelmsford, MA 01824 629 Voice: +1 978 244 8143 630 Email: swallow@cisco.com 632 Z. Bo Tang 633 Tellium, Inc. 634 2 Crescent Place 635 P.O. Box 901 636 Oceanport, NJ 07757-0901 637 Phone: +1 732 923 4231 638 Fax: +1 732 923 9804 639 Email: btang@tellium.com 641 Generated on: Tue May 1 16:25:40 EDT 2001