idnits 2.17.1 draft-ietf-isis-gmpls-extensions-17.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 an Authors' Addresses Section. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 469 has weird spacing: '...for the purpo...' -- 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 (October 2003) is 7496 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-08 ** Obsolete normative reference: RFC 3373 (ref. 'ISIS-3way') (Obsoleted by RFC 5303) == Outdated reference: A later version (-05) exists of draft-ietf-isis-restart-04 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella, Editor 3 Internet Draft Y. Rekhter, Editor 4 Category: Informational Juniper Networks 5 Updates: October 2003 6 Expires: April 2004 8 IS-IS Extensions in Support of Generalized MPLS 10 draft-ietf-isis-gmpls-extensions-17.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document specifies encoding of extensions to the IS-IS routing 40 protocol in support of Generalized Multi-Protocol Label Switching. 42 Specification of Requirements 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 Changes since last revision 50 (RFC Editor: remove this section before publication.) 52 Formatting changes. 54 Updated references. 56 1. Introduction 58 This document specifies extensions to the IS-IS routing protocol in 59 support of carrying link state information for Generalized 60 Multi-Protocol Label Switching (GMPLS). The set of required 61 enhancements to IS-IS are outlined in [GMPLS-ROUTING]. Support for 62 unnumbered interfaces assumes support for the "Point-to-Point 63 Three-Way Adjacency" IS-IS Option type [ISIS-3way]. 65 2. IS-IS Routing Enhancements 67 In this section we define the enhancements to the TE properties of 68 GMPLS TE links that can be announced in IS-IS Link State Protocol 69 Data Units. 71 In this document, we enhance the sub-TLVs for the extended IS 72 reachability TLV (see [ISIS-TE]) in support of GMPLS. Specifically, 73 we add the following sub-TLVs: 75 Sub-TLV Type Length Name 76 4 8 Link Local/Remote Identifiers 77 20 2 Link Protection Type 78 21 variable Interface Switching Capability 79 Descriptor 81 We further add one new TLV to the TE TLVs: 83 TLV Type Length Name 84 138 variable Shared Risk Link Group 86 2.1. Link Local/Remote Identifiers 88 A Link Local Interface Identifiers is a sub-TLV of the extended IS 89 reachability TLV. The type of this sub-TLV is 4, and length is eight 90 octets. The value field of this sub-TLV contains four octets of Link 91 Local Identifier followed by four octets of Link Remote Idenfier (see 92 Section "Support for unnumbered links" of [GMPLS-ROUTING]). If the 93 Link Remote Identifier is unknown, it is set to 0. 95 The following illustrates encoding of the Value field of the Link 96 Local/Remote Identifiers sub-TLV. 98 0 1 2 3 99 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 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Link Local Identifier | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Link Remote Identifier | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 The Link Local/Remote Identifiers sub-TLV MUST NOT occur more than 107 once within the extended IS reachability TLV. If the Link 108 Local/Remote Idenfitiers sub-TLV occurs more than once within the 109 extended IS reachability TLV, the receiver SHOULD ignore all these 110 sub-TLVs. 112 2.2. Link Protection Type 114 The Link Protection Type is is a sub-TLV (of type 20) of the 115 extended IS reachability TLV, with length two octets. 117 The following illustrates encoding of the Value field of the Link 118 Protection Type sub-TLV. 120 0 1 121 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 |Protection Cap | Reserved | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 The first octet is a bit vector describing the protection 127 capabilities of the link (see Section "Link Protection Type" of 128 [GMPLS-ROUTING]). They are: 130 0x01 Extra Traffic 132 0x02 Unprotected 134 0x04 Shared 136 0x08 Dedicated 1:1 138 0x10 Dedicated 1+1 140 0x20 Enhanced 142 0x40 Reserved 144 0x80 Reserved 146 The second octet SHOULD be set to zero by the sender, and SHOULD be 147 ignored by the receiver. 149 The Link Protection Type sub-TLV MUST NOT occur more than once within 150 the extended IS reachability TLV. If the Link Protection Type 151 sub-TLV occurs more than once within the extended IS reachability 152 TLV, the receiver SHOULD ignore all these sub-TLVs. 154 2.3. Interface Switching Capability Descriptor 156 The Interface Switching Capability Descriptor is a sub-TLV (of type 157 21) of the extended IS reachability TLV. The length is the length of 158 value field in octets. The following illustrates encoding of the 159 Value field of the Interface Switching Capability Descriptor sub-TLV. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Switching Cap | Encoding | Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Max LSP Bandwidth at priority 0 | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Max LSP Bandwidth at priority 1 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Max LSP Bandwidth at priority 2 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Max LSP Bandwidth at priority 3 | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Max LSP Bandwidth at priority 4 | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Max LSP Bandwidth at priority 5 | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Max LSP Bandwidth at priority 6 | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Max LSP Bandwidth at priority 7 | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Switching Capability-specific information | 183 | (variable) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 The Switching Capability (Switching Cap) field contains one of the 187 following values: 189 1 Packet-Switch Capable-1 (PSC-1) 190 2 Packet-Switch Capable-2 (PSC-2) 191 3 Packet-Switch Capable-3 (PSC-3) 192 4 Packet-Switch Capable-4 (PSC-4) 193 51 Layer-2 Switch Capable (L2SC) 194 100 Time-Division-Multiplex Capable (TDM) 195 150 Lambda-Switch Capable (LSC) 196 200 Fiber-Switch Capable (FSC) 198 The Encoding field contains one of the values specified in Section 199 3.1.1 of [GMPLS-SIG]. 201 Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in 202 the IEEE floating point format, with priority 0 first and priority 7 203 last. The units are bytes (not bits!) per second. 205 The content of the Switching Capability specific information field 206 depends on the value of the Switching Capability field. 208 When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, 209 the Switching Capability specific information field includes Minimum 210 LSP Bandwidth and Interface MTU. 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Minimum LSP Bandwidth | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Interface MTU | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 The Minimum LSP Bandwidth is is encoded in a 4 octets field in the 221 IEEE floating point format. The units are bytes (not bits!) per 222 second. The Interface MTU is encoded as a 2 octets integer, and 223 carries the MTU value in the units of bytes. 225 When the Switching Capability field is L2SC, there is no Switching 226 Capability specific information field present. 228 When the Switching Capability field is TDM, the Switching Capability 229 specific information field includes Minimum LSP Bandwidth and an 230 indication whether the interface supports Standard or Arbitrary 231 SONET/SDH. 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Minimum LSP Bandwidth | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Indication | 239 +-+-+-+-+-+-+-+-+ 241 The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE 242 floating point format. The units are bytes (not bits!) per second. 243 The indication whether the interface supports Standard or Arbitrary 244 SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the 245 interface supports Standard SONET/SDH, and 1 if the interface 246 supports Arbitrary SONET/SDH. 248 When the Switching Capability field is LSC, there is no Switching 249 Capability specific information field present. 251 To support interfaces that have more than one Interface Switching 252 Capability Descriptor (see Section "Interface Switching Capability 253 Descriptor" of [GMPLS-ROUTING]) the Interface Switching Capability 254 Descriptor sub-TLV MAY occur more than once within the extended IS 255 reachability TLV. 257 2.4. Shared Risk Link Group TLV 259 The SRLG TLV (of type 138 TBD) contains a data structure consisting 260 of: 262 6 octets of System ID 263 1 octet of Pseudonode Number 264 1 octet Flag 265 4 octets of IPv4 interface address or 4 octets of a Link Local 266 Identifier 267 4 octets of IPv4 neighbor address or 4 octets of a Link Remote 268 Identifier 269 (variable) list of SRLG values, where each element in the list 270 has 4 octets. 272 The following illustrates encoding of the Value field of the SRLG 273 TLV. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | System ID | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | System ID (cont.) | Pseudonode num| Flags | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | IPv4 interface address/Link Local Identifier | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | IPv4 neighbors address/Link Remote Identifier | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Shared Risk Link Group Value | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | ............ | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Shared Risk Link Group Value | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 The neighbor is identified by its System Id (6-octets), plus one 294 octet to indicate the pseudonode number if the neighbor is on a LAN 295 interface. 297 The Least Significant Bit of the Flag octet indicates whether the 298 interface is numbered (set to 1), or unnumbered (set to 0). All 299 other bits are reserved and should be set to 0. 301 The length of this TLV is 16 + 4 * (number of SRLG values). 303 This TLV carries the Shared Risk Link Group information (see Section 304 "Shared Risk Link Group Information" of [GMPLS-ROUTING]). 306 The SRLG TLV MAY occur more than once within the IS-IS Link State 307 Protocol Data Units. 309 2.5. Link Identifier for Unnumbered Interfaces 311 Link Identifiers are exchanged in the Extended Local Circuit ID field 312 of the "Point-to-Point Three-Way Adjacency" IS-IS Option type 313 [ISIS-3way]. 315 3. Implications on Graceful Restart 317 The restarting node SHOULD follow the ISIS restart procedures 318 [ISIS-RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP]. 320 When the restarting node is going to originate its IS-IS Link State 321 Protocol data units for TE links, these Link State Protocol data 322 units SHOULD be originated with 0 unreserved bandwidth, Traffic 323 Engineering Default metric set to 0xffffff, and if the link has LSC 324 or FSC as its Switching Capability then also with 0 as Max LSP 325 Bandwidth, until the node is able to determine the amount of 326 unreserved resources taking into account the resources reserved by 327 the already established LSPs that have been preserved across the 328 restart. Once the restarting node determines the amount of 329 unreserved resources, taking into account the resources reserved by 330 the already established LSPs that have been preserved across the 331 restart, the node SHOULD advertise these resources in its Link State 332 Protocol data units. 334 In addition in the case of a planned restart prior to restarting, the 335 restarting node SHOULD originate the IS-IS Link State Protocol data 336 units for TE links with 0 as unreserved bandwidth, and if the link 337 has LSC or FSC as its Switching Capability then also with 0 as Max 338 LSP Bandwidth. This would discourage new LSP establishment through 339 the restarting router. 341 Neighbors of the restarting node SHOULD continue advertise the actual 342 unreserved bandwidth on the TE links from the neighbors to that node. 344 4. Normative References 346 [GMPLS-ROUTING] Kompella, K., and Rekhter, Y. (Editors), "Routing 347 Extensions in Support of Generalized Multi-Protocol Label 348 Switching", (work in progress) [draft-ietf-ccamp-gmpls- 349 routing-08.txt] 351 [GMPLS-RSVP] Berger, L., (Editor), "Generalized Multi-Protocol Label 352 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 353 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003 355 [GMPLS-SIG] Berger, L. (Editor), "Generalized Multi-Protocol Label 356 Switching (GMPLS) Signaling Functional Description", RFC 3471, 357 January 2003 359 [ISIS-3way] Katz, D., and Saluja, R., "Three-Way Handshake for 360 Intermediate System to Intermediate System (IS-IS) Point-to-Point 361 Adjacencies", RFC 3373, September 2002 363 [ISIS-RESTART] Shand, M. and L. Ginsburg, "Restart signaling for 364 ISIS", (work in progress) [draft-ietf-isis-restart-04.txt] 366 [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic 367 Engineering", (work in progress) [draft-ietf-isis-traffic-05.txt] 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 5. Security Considerations 374 This document raises no security concerns beyond those addressed in 375 [ISIS-TE]. 377 6. Acknowledgements 379 The authors would like to thank Jim Gibson, Suresh Katukam, Jonathan 380 Lang and Quaizar Vohra for their comments on the draft. 382 7. Contributors 383 Ayan Banerjee 384 Calient Networks 385 5853 Rue Ferrari 386 San Jose, CA 95138 387 Phone: +1 408 972 3645 388 EMail: abanerjee@calient.net 390 John Drake 391 Calient Networks 392 5853 Rue Ferrari 393 San Jose, CA 95138 394 Phone: +1 408 972 3720 395 EMail: jdrake@calient.net 397 Greg Bernstein 398 Grotto Networking 399 EMail: gregb@grotto-networking.com 401 Don Fedyk 402 Nortel Networks Corp. 403 600 Technology Park Drive 404 Billerica, MA 01821 405 Phone: +1 978 288 4506 406 EMail: dwfedyk@nortelnetworks.com 408 Eric Mannie 409 Independent Consultant 410 E-mail: eric_mannie@hotmail.com 411 Debanjan Saha 412 Tellium Optical Systems 413 2 Crescent Place 414 P.O. Box 901 415 Ocean Port, NJ 07757 416 Phone: +1 732 923 4264 417 EMail: dsaha@tellium.com 419 Vishal Sharma 420 EMail: v.sharma@ieee.org 421 8. Authors' Information 423 Kireeti Kompella 424 Juniper Networks, Inc. 425 1194 N. Mathilda Ave 426 Sunnyvale, CA 94089 427 EMail: kireeti@juniper.net 429 Yakov Rekhter 430 Juniper Networks, Inc. 431 1194 N. Mathilda Ave 432 Sunnyvale, CA 94089 433 EMail: yakov@juniper.net 435 9. Intellectual Property Rights Notices 437 The IETF takes no position regarding the validity or scope of any 438 intellectual property or other rights that might be claimed to 439 pertain to the implementation or use of the technology described in 440 this document or the extent to which any license under such rights 441 might or might not be available; neither does it represent that it 442 has made any effort to identify any such rights. Information on the 443 IETF's procedures with respect to rights in standards-track and 444 standards-related documentation can be found in BCP-11. Copies of 445 claims of rights made available for publication and any assurances of 446 licenses to be made available, or the result of an attempt made to 447 obtain a general license or permission for the use of such 448 proprietary rights by implementors or users of this specification can 449 be obtained from the IETF Secretariat. 451 The IETF invites any interested party to bring to its attention any 452 copyrights, patents or patent applications, or other proprietary 453 rights which may cover technology that may be required to practice 454 this standard. Please address the information to the IETF Executive 455 Director. 457 Full Copyright Statement 459 Copyright (C) The Internet Society (2003). All Rights Reserved. 461 This document and translations of it may be copied and furnished to 462 others, and derivative works that comment on or otherwise explain it 463 or assist in its implementation may be prepared, copied, published 464 and distributed, in whole or in part, without restriction of any 465 kind, provided that the above copyright notice and this paragraph are 466 included on all such copies and derivative works. However, this 467 document itself may not be modified in any way, such as by removing 468 the copyright notice or references to the Internet Society or other 469 Internet organizations, except as needed for the purpose of 470 developing Internet standards in which case the procedures for 471 copyrights defined in the Internet Standards process must be 472 followed, or as required to translate it into languages other than 473 English. 475 The limited permissions granted above are perpetual and will not be 476 revoked by the Internet Society or its successors or assigns. 478 This document and the information contained herein is provided on an 479 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 480 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 481 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 482 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 483 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 Acknowledgement 487 Funding for the RFC Editor function is currently provided by the 488 Internet Society.