idnits 2.17.1 draft-vasseur-ccamp-te-node-cap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 644. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that a change in any of these capabilities MAY trigger CSPF computation, but MUST not trigger normal SPF computation. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that a change in any of these capabilities MAY trigger CSPF computation, but MUST not trigger normal SPF computation. -- 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 2005) is 6768 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: 'OSPF' is mentioned on line 124, but not defined == Missing Reference: 'ISIS-CAP' is mentioned on line 381, but not defined == Missing Reference: 'ISIS-TE' is mentioned on line 362, but not defined == Unused Reference: 'RFC' is defined on line 541, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'OSPF-v2' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RTG' is defined on line 582, but no explicit reference was found in the text -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in 'RFC'. ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (ref. 'IS-IS-TE') (Obsoleted by RFC 5305) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-01 Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group JP Vasseur (Ed.) 3 Cisco System Inc. 4 IETF Internet Draft JL Le Roux (Ed.) 5 France Telecom 7 Proposed Status: Standard Track 8 Expires: March 2006 October 2005 10 Routing extensions for discovery of Traffic Engineering Node 11 Capabilities 13 draft-vasseur-ccamp-te-node-cap-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 It is highly desired in several cases, to take into account Traffic 40 Engineering (TE) node capabilities during TE LSP path selection, such 41 as for instance the capability to act as a branch LSR of a P2MP LSP. 42 This requires advertising these capabilities within the IGP. 43 For that purpose, this document specifies OSPF and IS-IS traffic 44 engineering extensions for the advertisement of control plane and 45 data plane traffic engineering node capabilities. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC-2119. 53 Table of Contents 55 1. Contributors................................................3 56 2. Terminology.................................................3 57 3. Introduction................................................4 58 4. TE Node Capability Descriptor...............................4 59 4.1. Description.................................................4 60 4.2. Required Information........................................5 61 5. OSPF TE extensions..........................................6 62 5.1. OSPF TE Node Capability Descriptor TLV format...............6 63 5.1.1. The DATA-PLANE-CAP sub-TLV..................................7 64 5.1.2. The CONTROL-PLANE-CAP sub-TLV...............................8 65 5.2. Elements of Procedure.......................................9 66 6. IS-IS TE Extensions........................................10 67 6.1. IS-IS TE Node Capability Descriptor TLV format.............10 68 6.1.1. DATA-PLANE-CAP sub-TLV.....................................10 69 6.1.2. CONTROL-PLANE-CAP sub-TLV..................................11 70 6.2. Elements of procedure......................................12 71 7. Backward compatibility.....................................12 72 8. Security Considerations....................................12 73 9. IANA considerations........................................12 74 9.1. OSPF TLVs..................................................12 75 9.2. ISIS TLVs..................................................13 76 9.3. Capability bits............................................13 77 10. Acknowledgments............................................13 78 11. References.................................................14 79 11.1. Normative references........................................14 80 11.2. Informative References......................................14 81 12. Editors' Address...........................................15 82 13. Intellectual Property Statement............................15 84 1. Contributors 86 This document was the collective work of several. The text and 87 content of this document was contributed by the editors and the 88 co-authors listed below (the contact information for the editors 89 appears in section 12, and is not repeated below): 91 Paul Mabey Seisho Yasukawa 92 Qwest Communications NTT 93 950 17th street 9-11, Midori-Cho 3-Chome 94 Denver, CO 80202 Musashino-Shi, Tokyo 180-8585 95 USA JAPAN 96 Email: pmabey@qwest.com Email: yasukawa.seisho@lab.ntt.co.jp 98 Stefano Previdi Peter Psenak 99 Cisco System, Inc. Cisco System, Inc. 100 Via del Serafico 200 Pegasus Park 101 00142 Roma DE Kleetlaan 6A 102 ITALY 1831, Diegmen 103 Email: sprevidi@cisco.com BELGIUM 104 Email: ppsenak@cisco.com 106 2. Terminology 108 LSR: Label Switch Router. 110 TE LSP: Traffic Engineering Label Switched Path. 112 P2MP TE LSP: A TE LSP that has one unique 113 ingress LSR and one or more egress LSRs. 115 Branch LSR: An LSR on a P2MP LSP that has more than one directly 116 connected downstream LSRs. 118 Bud-LSR: An LSR on a P2MP LSP, that is an egress, but also has one or 119 more directly connected downstream LSRs. 121 3. Introduction 123 MPLS Traffic Engineering (MPLS-TE) routing ([IS-IS-TE], [OSPF-TE]) 124 relies on extensions to link state IGP routing protocols ([OSPF], 125 [IS-IS]) in order to carry Traffic Engineering (TE) link information 126 used for constraint based routing. Further Generalized MPLS (GMPLS) 127 related routing extensions are defined in [IS-IS-G] and [OSPF-G]. 129 It is desired to complement these routing extensions in order to 130 carry TE node capabilities, in addition to TE link information. These 131 TE node capabilities will be taken into account as constraints during 132 path selection. 133 Indeed, it is useful to advertise data plane TE node capabilities, 134 such as, for instance the capability to be a branch LSR or a bud-LSR 135 of a P2MP LSP. These capabilities are then taken into account as 136 constraints when computing TE LSP paths. 137 It is also useful to advertise control plane TE node capabilities 138 such as for instance the capability to support GMPLS 139 signaling for a packet LSR, or the capability to support P2MP (Point 140 to Multipoint) TE LSP signaling. This allows selecting a path that 141 avoids nodes that do not support a given signaling feature, or 142 triggering a mechanism to support such nodes. Hence this facilitates 143 backward compatibility. 145 For that purpose, this document specifies IGP (OSPF and IS-IS) 146 traffic engineering node capability TLVs in order to advertise data 147 plane and control plane capabilities of a node. 149 A new TLV is defined for ISIS and OSPF: the TE Node Capability 150 Descriptor TLV, to be carried within: 151 - the ISIS Capability TLV ([ISIS-CAP]) for ISIS 152 - the Router Information LSA ([OSPF-CAP]), for OSPF. 154 4. TE Node Capability Descriptor 156 4.1. Description 158 LSRs in a network may have distinct control plane and data plane 159 Traffic Engineering capabilities. The TE Node Capability Descriptor 160 information defined in this document describes data and control plane 161 capabilities of an LSR. Such information can be used for instance 162 during path computation so as to avoid nodes that do not support a 163 given TE feature either in the control or data plane or to trigger 164 procedure to handle these nodes. In some cases, this may also be 165 useful to ensure backward compatibility. 167 4.2. Required Information 169 The TE Node Capability Descriptor contains two variable length sets 170 of bit flags: 171 -The Data Plane Capabilities: This a variable length 172 set of bit flags where each bit corresponds to a given TE data plane 173 capability. 174 -The Control Plane Capabilities: This a variable length 175 set of bit flags where each bit corresponds to a given TE control 176 plane capability. 178 Two Data Plane Capabilities are currently defined: 179 -B bit: when set, this flag indicates that the LSR can act 180 as a branch node on a P2MP LSP (see [P2MP-REQ]) and [RSVP- 181 P2MP]). 182 -E bit: when set, this flag indicates that the LSR can act 183 as a bud LSR on a P2MP LSP, i.e. an LSR that is both 184 transit and egress. 186 Three Control Plane Capabilities are currently defined: 187 -M bit: when set, this flag indicates that the LSR supports 188 MPLS-TE signaling ([RSVP-TE]). 189 -G bit: when set this flag indicates that the LSR supports 190 GMPLS signaling ([RSVP-G]). 191 -P bit: when set, this flag indicates that the LSR supports 192 P2MP MPLS-TE signaling ([RSVP-P2MP]). 194 Note that new capabilities may be added in the future if required. 196 Note that bits numbers are under IANA control. 198 5. OSPF TE extensions 200 5.1. OSPF TE Node Capability Descriptor TLV format 202 The OSPF TE Node Capability Descriptor TLV is made of various non 203 ordered sub-TLVs. 204 The format of the OSPF TE Node Capability Descriptor TLV and its sub- 205 TLVs is the same as the TLV format used by the Traffic Engineering 206 Extensions to OSPF [OSPF-TE]. That is, the TLV is composed of 2 207 octets for the type, 2 octets specifying the TLV length and a value 208 field. 209 The TLV is padded to four-octet alignment; padding is not included in 210 the length field (so a three octet value would have a length of 211 three, but the total size of the TLV would be eight octets). Nested 212 TLVs are also 32-bit aligned. Unrecognized types are ignored. All 213 types between 32768 and 65535 are reserved for vendor-specific 214 extensions. All other undefined type codes are reserved for future 215 assignment by IANA. 217 The OSPF TE Node Capability Descriptor TLV has the following format: 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type | Length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 // sub-TLVs // 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Type To be defined by IANA 229 Length Variable 230 Value This comprises one or more sub-TLVs 232 Currently two sub-TLVs are defined: 233 Sub-TLV type Length Name 234 1 variable DATA-PLANE-CAP sub-TLV 235 2 variable CONTROL-PLANE-CAP sub-TLV 237 Any non recognized sub-TLV MUST be silently ignored. 238 More sub-TLVs could be added in the future to handle new 239 capabilities. 241 The OSPF TE Node Capability Descriptor TLV is carried within an OSPF 242 router information LSA which is defined in [OSPF-CAP]. 244 5.1.1. The DATA-PLANE-CAP sub-TLV 246 The DATA-PLANE-CAP sub-TLV is a series of bit flags, where each bit 247 correspond to a data plane TE node capability, and has a variable 248 length. 250 The format of the DATA-PLANE-CAP sub-TLV is as follows: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Type | Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Data Plane TE Node Capabilities | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Type To be assigned by IANA (suggested value =1) 261 Length It is set to N x 4 octets. N starts 262 from 1 and can be increased when there is a need. 263 Each 4 octets are referred to as a capability flag. 264 Value This comprises one or more capability flags. 265 For each 4 octets, the bits are indexed from the most 266 significant to the least significant, where each bit 267 represents one data plane TE node capability. When 268 the first 32 capabilities are defined, a new 269 capability flag will be used to accommodate the next 270 capability. These bits are under IANA control. 272 The following bits in the first capability flag are to be assigned by 273 IANA: 275 Bit Capabilities 277 0 B bit: P2MP Branch Node capability: When set this indicates 278 that the LSR can act as a branch node on a P2MP LSP 279 [P2MP-REQ]; 280 1 E bit: P2MP Bud-LSR capability: When set, this indicates 281 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 282 LSR that is both transit and egress [P2MP-REQ]; 284 2-31 Reserved for future assignments by IANA. 286 5.1.2. The CONTROL-PLANE-CAP sub-TLV 288 The CONTROL-PLANE-CAP sub-TLV is a series of bit flags, where each 289 bit correspond to a control plane TE node capability, and has a 290 variable length. 292 The format of the CONTROL-PLANE-CAP sub-TLV is as follows: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Control Plane TE Node Capabilities | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Type To be assigned by IANA (suggested value = 2) 303 Length It is set to N x 4 octets. N starts 304 from 1 and can be increased when there is a need. 305 Each 4 octets are referred to as a capability flag. 306 Value This comprises one or more capability flags. 307 For each 4 octets, the bits are indexed from the most 308 Significant to the least significant, where each bit 309 represents one control plane TE node capability. When 310 the first 32 capabilities are defined, a new 311 capability flag will be used to accommodate the next 312 capability. These bits are under IANA control. 314 The following bits in the first capability flag are to be assigned by 315 IANA: 317 Bit Capabilities 319 0 M bit: If set this indicates that the LSR supports 320 MPLS-TE signaling ([RSVP-TE]). 322 1 G bit: If set this indicates that the LSR supports 323 GMPLS signaling ([RSVP-G]). 325 2 P bit: If set this indicates that the LSR supports 326 P2MP MPLS-TE signaling ([RSVP-P2MP]). 328 3-31 Reserved for future assignments by IANA 330 5.2. Elements of Procedure 332 The TE Node Capability Descriptor TLV is carried within an OSPF 333 Router information opaque LSA (opaque type of 4, opaque ID of 0) 334 which is defined in [OSPF-CAP]. 336 A router MUST originate a new OSPF router information LSA whenever 337 the content of any of the carried TLVs changes or whenever 338 required by the regular OSPF procedure (LSA refresh (every 339 LSRefreshTime)). 341 The TE Node Capability Descriptor TLV advertises capabilities that 342 are taken into account as constraints during path selection. Hence 343 its flooding scope is area-local, and MUST be carried within a type 344 10 router information LSA. 346 TE Node Capability Descriptor TLVs are OPTIONAL. When an OSPF LSA 347 does not contain any TE Node capability Descriptor TLV, this means 348 that the TE Capabilities of that LSR are unknown. 350 Note that a change in any of these capabilities MAY trigger CSPF 351 computation, but MUST not trigger normal SPF computation. 353 6. IS-IS TE Extensions 355 6.1. IS-IS TE Node Capability Descriptor TLV format 357 The IS-IS TE Node Capability Descriptor TLV is made of various non 358 ordered sub-TLVs. 360 The format of the IS-IS TE Node Capability TLV and its sub-TLVs is 361 the same as the TLV format used by the Traffic Engineering Extensions 362 to IS-IS [ISIS-TE]. That is, the TLV is composed of 1 octet for the 363 type, 1 octet specifying the TLV length and a value field. 365 The IS-IS TE Node Capability Descriptor TLV has the following format: 367 TYPE: To be assigned by IANA 368 LENGTH: Variable, from 3 to 255 369 VALUE: set of one or more sub-TLVs 371 Currently two sub-TLVs are defined: 372 Sub-TLV type Length Name 373 1 variable DATA-PLANE-CAP sub-TLV 374 2 variable CONTROL-PLANE-CAP sub-TLV 376 Any non recognized sub-TLV MUST be silently ignored. 377 More sub-TLVs could be added in the future to handle new 378 capabilities. 380 The IS-IS TE Node Capability Descriptor TLV is carried within an IS- 381 IS CAPABILITY TLV which is defined in [ISIS-CAP]. 383 6.1.1. DATA-PLANE-CAP sub-TLV 385 The DATA-PLANE-CAP sub-TLV is a series of bit flags, where each bit 386 correspond to a data plane TE node capability, and has a variable 387 length. These bits are under IANA control. 389 The DATA-PLANE-CAP sub-TLV has the following format: 391 TYPE: To be assigned by IANA (Suggested value =1) 392 LENGTH: It is set to N. N starts from 1 and can be increased when 393 there is a need. Each octet is referred to as a 394 capability flag. 395 VALUE: This comprises one or more data plane TE node capability 396 flags. 398 The following bits in the first capability flag are to be assigned by 399 IANA: 401 0 1 2 3 4 5 6 7 402 +-+-+-+-+-+-+-+-+ 403 |B|E| Reserved | 404 +-+-+-+-+-+-+-+-+ 406 B bit: P2MP Branch node capability: When set this indicates 407 that the LSR can act as a branch node on a P2MP LSP 408 [P2MP-REQ] 409 E bit: P2MP bud-LSR capability: When set, this indicates 410 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 411 LSR that is both transit and egress [P2MP-REQ]. 413 Reserved bits are for future assignment by IANA 415 6.1.2. CONTROL-PLANE-CAP sub-TLV 417 The CONTROL-PLANE-CAP sub-TLV is a series of bit flags, where each 418 bit correspond to a control plane TE node capability, and has a 419 variable length. These bits are under IANA control. 421 The CONTROL-PLANE-CAP sub-TLV has the following format: 423 TYPE: To be assigned by IANA (suggested value = 2) 424 LENGTH: It is set to N. N starts from 1 and can be increased 425 when there is a need. Each octet is referred to as a 426 capability flag. 427 VALUE: This comprises one or more control plane TE node capability 428 flags. 430 The following bits in the first capability flag are to be assigned by 431 IANA. 433 0 1 2 3 4 5 6 7 434 +-+-+-+-+-+-+-+-+ 435 |M|G|P|Reserved | 436 +-+-+-+-+-+-+-+-+ 438 -M bit: If set this indicates that the LSR supports MPLS-TE 439 signaling ([RSVP-TE]). 441 -G bit: If set this indicates that the LSR supports GMPLS signaling 442 ([RSVP-G]). 444 -P bit: If set this indicates that the LSR supports P2MP MPLS-TE 445 signaling ([RSVP-P2MP]). 447 Reserved bits are for future assignment by IANA. 449 6.2. Elements of procedure 451 The TE Node Capability TLV is carried within an IS-IS CAPABILITY TLV 452 defined in [IS-IS-CAP]. 454 An IS-IS router MUST originate a new IS-IS LSP whenever the content 455 of any of the TE Node Capability TLV changes or whenever required by 456 the regular IS-IS procedure (LSP refresh). 458 The TE Node Capability Descriptor TLV advertises capabilities that 459 are taken into account as constraints during path selection. Hence 460 its flooding is area-local, and MUST be carried within an IS-IS 461 CAPABILITY TLV having the S flag cleared. 463 TE Node Capability Descriptor TLVs are OPTIONAL. When a IS-IS LSP 464 does not contain any TE Node capability Descriptor TLV, this means 465 that the TE Capabilities of that LSR are unknown. 467 Note that a change in any of these capabilities MAY trigger CSPF 468 computation, but MUST not trigger normal SPF computation. 470 7. Backward compatibility 472 The TE Node Capability Descriptor TLVs defined in this document do 473 not introduce any interoperability issue. For OSPF, a router not 474 supporting the TE Node Capability Descriptor TLV SHOULD just silently 475 ignore the TLV as specified in RFC2370. For IS-IS a router not 476 supporting the TE Node Capability Descriptor TLV SHOULD just silently 477 ignore the TLV. 479 8. Security Considerations 481 No new security issues are raised in this document. 483 9. IANA considerations 485 9.1. OSPF TLVs 487 IANA will assign a new codepoint for the TE Node Capability 488 Descriptor TLV defined in this document and carried within the Router 489 Information LSA. 491 Two sub-TLVs types are defined for this TLV and should be assigned by 492 IANA: 493 -CONTROL-PLANE-CAP sub-TLV (suggested value =1) 494 -DATA-PLANE-CAP sub-TLV (suggested value =2) 496 9.2. ISIS TLVs 498 IANA will assign a new codepoint for the TE Node Capability 499 Descriptor TLV defined in this document, and carried within the ISIS 500 CAPABILITY TLV. 502 Two sub-TLVs types are defined for this TLV and should be assigned by 503 IANA: 504 -CONTROL-PLANE-CAP sub-TLV (suggested value =1) 505 -DATA-PLANE-CAP sub-TLV (suggested value =2) 507 9.3. Capability bits 509 IANA is requested to manage the space of control plane and data plane 510 capability bit flags, numbering them in the usual IETF notation 511 starting at zero and continuing at least through 31. 512 New bit numbers may be allocated only by an IETF Consensus action. 513 Each bit should be tracked with the following qualities: 514 - Bit number 515 - Defining RFC 516 - Name of bit 518 Currently two bits are defined in the data plane capability flags. 519 Here are the suggested values: 520 -0x01: P2MP Branch LSR capability 521 -0x02: P2MP Bud LSR capability 523 Currently three bits are defined in the control plane capability 524 flags. Here are the suggested values: 525 -0x01: MPLS-TE support 526 -0x02: GMPLS support 527 -0x04: P2MP RSVP-TE support 529 10. Acknowledgments 531 We would like to thank Benoit Fondeviole, Adrian Farrel and Dimitri 532 Papadimitriou for their useful comments and suggestions. 534 We would also like to thank authors of [LSP-ATTRIBUTE] from which 535 some text of this document has been inspired. 537 11. References 539 11.1. Normative references 541 [RFC] Bradner, S., "Key words for use in RFCs to indicate 542 requirements levels", RFC 2119, March 1997. 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 548 3667, February 2004. 550 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 551 Technology", RFC 3979, March 2005. 553 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 555 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 556 Routing Exchange Protocol " ISO 10589. 558 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 559 dual environments", RFC 1195, December 1990. 561 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 562 Extensions to OSPF Version 2", RFC 3630, September 2003. 564 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 565 Engineering", RFC 3784, June 2004. 567 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 568 J.P., "Extensions to OSPF for advertising Optional Router 569 Capabilities", draft-ietf-ospf-cap, work in progress. 571 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 572 router information", draft-ietf-isis-caps, work in progress. 574 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 575 tunnels", RFC 3209, December 2001. 577 [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 578 RFC 3473, January 2003. 580 11.2. Informative References 582 [GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support 583 of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp- 584 gmpls-routing, work in progress. 586 [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of 587 Generalized Multi-protocol Label Switching", draft-ietf-ccamp-ospf- 588 gmpls-extensions, work in progress. 590 [IS-IS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 591 Generalized Multi-protocol Label Switching", draft-ietf-isis-gmpls- 592 extensions, work in progress. 594 [P2MP-REQ] Yasukawa, S., et. al., "Signaling Requirements for Point 595 to Multipoint Traffic Engineered MPLS LSPs", draft-ietf-mpls-p2mp- 596 sig-requirement, work in progress. 598 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 599 RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 600 p2mp-01, work in progress. 602 [LSP-ATTRIBUTE] Farrel, A., and al., "Encoding of attributes for MPLS 603 LSPs establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes, 604 work in progress. 606 12. Editors' Address 608 Jean-Philippe Vasseur 609 Cisco Systems, Inc. 610 300 Beaver Brook Road 611 Boxborough , MA - 01719 612 USA 613 Email: jpv@cisco.com 615 Jean-Louis Le Roux 616 France Telecom 617 2, avenue Pierre-Marzin 618 22307 Lannion Cedex 619 FRANCE 620 Email: jeanlouis.leroux@francetelecom.com 622 13. Intellectual Property Statement 624 The IETF takes no position regarding the validity or scope of any 625 Intellectual Property Rights or other rights that might be claimed to 626 pertain to the implementation or use of the technology described in 627 this document or the extent to which any license under such rights 628 might or might not be available; nor does it represent that it has 629 made any independent effort to identify any such rights. Information 630 on the procedures with respect to rights in RFC documents can be 631 found in BCP 78 and BCP 79. 633 Copies of IPR disclosures made to the IETF Secretariat and any 634 assurances of licenses to be made available, or the result of an 635 attempt made to obtain a general license or permission for the use of 636 such proprietary rights by implementers or users of this 637 specification can be obtained from the IETF on-line IPR repository at 638 http://www.ietf.org/ipr. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights that may cover technology that may be required to implement 643 this standard. Please address the information to the IETF at 644 ietf-ipr@ietf.org. 646 Disclaimer of Validity 648 This document and the information contained herein are provided on an 649 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 650 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 651 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 652 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 653 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 654 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 656 Copyright Statement 658 Copyright (C) The Internet Society (2005). This document is subject 659 to the rights, licenses and restrictions contained in BCP 78, and 660 except as set forth therein, the authors retain all their rights.