idnits 2.17.1 draft-ietf-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 26. -- Found old boilerplate from RFC 3978, Section 5.5 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 667. ** 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 == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == 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 (June 2006) is 6525 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: 'RFC3031' is mentioned on line 92, but not defined == Missing Reference: 'RFC3209' is mentioned on line 92, but not defined == Missing Reference: 'RFC4461' is mentioned on line 93, but not defined == Missing Reference: 'ISIS-CAP' is mentioned on line 485, but not defined == Missing Reference: 'OSPFv3' is mentioned on line 404, but not defined == Unused Reference: 'RFC' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'OSPF-v3' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RTG' is defined on line 581, 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) ** Obsolete normative reference: RFC 2740 (ref. 'OSPF-v3') (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (ref. 'IS-IS-TE') (Obsoleted by RFC 5305) -- Obsolete informational reference (is this intentional?): RFC 4205 (ref. 'IS-IS-G') (Obsoleted by RFC 5307) -- Obsolete informational reference (is this intentional?): RFC 4420 (ref. 'LSP-ATTRIBUTE') (Obsoleted by RFC 5420) Summary: 10 errors (**), 0 flaws (~~), 17 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.P. Vasseur (Editor) 3 Cisco Systems, Inc. 4 IETF Internet Draft J.L. Le Roux (Editor) 5 France Telecom 6 Proposed Status: Standard Track S. Yasukawa 7 Expires: December 2006 NTT 8 S. Previdi 9 P. Psenak 10 Cisco Systems, Inc. 11 Paul Mabey 12 Comcast 14 June 2006 16 Routing extensions for discovery of Traffic Engineering Node 17 Capabilities 19 draft-ietf-ccamp-te-node-cap-01.txt 21 Status of this Memo 23 By submitting this Internet-Draft, each author represents that any 24 applicable patent or other IPR claims of which he or she is aware 25 have been or will be disclosed, and any of which he or she becomes 26 aware will be disclosed, in accordance with Section 6 of BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that other 30 groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 It is highly desired in several cases, to take into account Traffic 46 Engineering (TE) node capabilities during TE LSP path selection, such 47 as for instance the capability to act as a branch LSR of a P2MP LSP. 48 This requires advertising these capabilities within the IGP. 49 For that purpose, this document specifies OSPF and IS-IS traffic 50 engineering extensions for the advertisement of control plane and 51 data plane traffic engineering node capabilities. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC-2119. 59 Table of Contents 61 1. Terminology.................................................3 62 2. Introduction................................................3 63 3. TE Node Capability Descriptor...............................4 64 3.1. Description.................................................4 65 3.2. Required Information........................................4 66 4. TE Node Capability Descriptor TLV formats...................5 67 4.1. OSPF TE Node Capability Descriptor TLV format...............5 68 4.1.1. The DATA-PLANE-CAP sub-TLV..................................5 69 4.1.2. The CONTROL-PLANE-CAP sub-TLV...............................6 70 4.2. IS-IS TE Node Capability Descriptor TLV format..............7 71 4.2.1. DATA-PLANE-CAP sub-TLV......................................8 72 4.2.2. CONTROL-PLANE-CAP sub-TLV...................................8 73 5. Elements of procedure.......................................9 74 5.1. OSPF........................................................9 75 5.2. IS-IS......................................................10 76 6. Backward compatibility.....................................10 77 7. Security Considerations....................................10 78 8. IANA considerations........................................10 79 8.1. OSPF TLVs..................................................10 80 8.2. ISIS TLVs..................................................11 81 8.3. Capability bits............................................11 82 9. Acknowledgments............................................12 83 10. References.................................................12 84 10.1. Normative references.......................................12 85 10.2. Informative References.....................................13 86 11. Editors Address............................................13 87 12. Contributors address.......................................14 88 13. Intellectual Property Statement............................14 90 1. Terminology 92 This document uses terminologies defined in [RFC3031], [RFC3209] and 93 [RFC4461]. 95 2. Introduction 97 MPLS Traffic Engineering (MPLS-TE) routing ([IS-IS-TE], [OSPF-TE]) 98 relies on extensions to link state IGP routing protocols ([OSPF-v2], 99 [IS-IS]) in order to advertise Traffic Engineering (TE) link 100 information used for constraint based routing. Further Generalized 101 MPLS (GMPLS) related routing extensions are defined in [IS-IS-G] and 102 [OSPF-G]. 104 It is desired to complement these routing extensions in order to 105 advertise TE node capabilities, in addition to TE link information. 106 These TE node capabilities will be taken into account as constraints 107 during path selection. 109 Indeed, it is useful to advertise data plane TE node capabilities, 110 such as, for instance the capability for an LSR to be a branch LSR or 111 a bud-LSR of a P2MP LSP. These capabilities can then be taken into 112 account as constraints when computing TE LSP paths. 114 It is also useful to advertise control plane TE node capabilities 115 such as for instance the capability to support GMPLS signaling for a 116 packet LSR, or the capability to support P2MP (Point to Multipoint) 117 TE LSP signaling. This allows selecting a path that avoids nodes 118 that do not support a given signaling feature, or triggering a 119 mechanism to support such nodes. Hence this facilitates backward 120 compatibility. 122 For that purpose, this document specifies IGP (OSPF and IS-IS) 123 traffic engineering node capability TLVs in order to advertise data 124 plane and control plane capabilities of a node. 126 A new TLV is defined for ISIS and OSPF: the TE Node Capability 127 Descriptor TLV, to be carried within: 128 - The ISIS Capability TLV ([ISIS-CAP]) for ISIS 129 - The Router Information LSA ([OSPF-CAP]) for OSPF. 131 3. TE Node Capability Descriptor 133 3.1. Description 135 LSRs in a network may have distinct control plane and data plane 136 Traffic Engineering capabilities. The TE Node Capability Descriptor 137 information defined in this document describes data and control plane 138 capabilities of an LSR. Such information can be used for instance 139 during path computation so as to avoid nodes that do not support a 140 given TE feature either in the control or data plane or to trigger 141 procedure to handle these nodes along the path (e.g trigger LSP 142 hierarchy to support a legacy transit LSR on a P2MP LSP (see [RSVP- 143 P2MP]). In some cases, this may also be useful to ensure backward 144 compatibility. 146 3.2. Required Information 148 The TE Node Capability Descriptor contains two variable length sets 149 of bit flags: 150 - The Data Plane Capabilities: This a variable length 151 set of bit flags where each bit corresponds to a given TE data plane 152 capability. 153 - The Control Plane Capabilities: This a variable length 154 set of bit flags where each bit corresponds to a given TE control 155 plane capability. 157 Two Data Plane Capabilities are currently defined: 158 - B bit: when set, this flag indicates that the LSR can act 159 as a branch node on a P2MP LSP (see [P2MP-REQ]); 160 - E bit: when set, this flag indicates that the LSR can act 161 as a bud LSR on a P2MP LSP, i.e. an LSR that is both 162 transit and egress (see [P2MP-REQ]). 164 Three Control Plane Capabilities are currently defined: 165 - M bit: when set, this flag indicates that the LSR supports 166 MPLS-TE signaling ([RSVP-TE]); 167 - G bit: when set this flag indicates that the LSR supports 168 GMPLS signaling ([RSVP-G]); 169 - P bit: when set, this flag indicates that the LSR supports 170 P2MP MPLS-TE signaling ([RSVP-P2MP]). 172 Note that new capability bits may be added in the future if required. 173 Also more complex capabilities encoded within sub-TLVs may be added 174 in the future if required. 176 4. TE Node Capability Descriptor TLV formats 178 4.1. OSPF TE Node Capability Descriptor TLV format 180 The OSPF TE Node Capability Descriptor TLV is made of various non- 181 ordered sub-TLVs. 183 The format of the OSPF TE Node Capability Descriptor TLV and its sub- 184 TLVs is the same as the TLV format used by the Traffic Engineering 185 Extensions to OSPF [OSPF-TE]. That is, the TLV is composed of 2 186 octets for the type, 2 octets specifying the TLV length and a value 187 field. The TLV is padded to four-octet alignment; padding is not 188 included in the length field (so a three octet value would have a 189 length of three, but the total size of the TLV would be eight 190 octets). Sub-TLVs are also 32-bit aligned. Unrecognized types are 191 ignored. All types between 32768 and 65535 are reserved for vendor- 192 specific extensions. All other undefined type codes are reserved for 193 future assignment by IANA. 195 The OSPF TE Node Capability Descriptor TLV has the following format: 197 TYPE To be defined by IANA 198 LENGHT Variable 199 VALUE This comprises one or more sub-TLVs 201 Currently two sub-TLVs are defined: 202 Sub-TLV type Length Name 203 1 variable DATA-PLANE-CAP sub-TLV 204 2 variable CONTROL-PLANE-CAP sub-TLV 206 Any unrecognized sub-TLV MUST be silently ignored. 208 More sub-TLVs could be added in the future to handle new 209 capabilities. 211 The OSPF TE Node Capability Descriptor TLV is carried within an OSPF 212 Router Information LSA which is defined in [OSPF-CAP]. 214 4.1.1. The DATA-PLANE-CAP sub-TLV 216 The DATA-PLANE-CAP sub-TLV is a series of bit flags, where each bit 217 correspond to a data plane TE node capability, and has a variable 218 length. 220 The format of the DATA-PLANE-CAP sub-TLV is as follows: 222 TYPE To be assigned by IANA (suggested value =1) 223 LENGTH It is set to N x 4 octets. N starts 224 from 1 and can be increased when there is a need. 225 Each 4 octets are referred to as a capability flag. 226 VALUE This comprises one or more capability flags. 227 For each 4 octets, the bits are indexed from the most 228 significant to the least significant, where each bit 229 represents one data plane TE node capability. When 230 the first 32 capabilities are defined, a new 231 capability flag will be used to accommodate the next 232 capability. These bits are under IANA control. 234 The following bits are defined the first capability flag: 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |B|E| Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Bit Capabilities 242 0 B bit: P2MP Branch Node capability: When set this indicates 243 that the LSR can act as a branch node on a P2MP LSP 244 [P2MP-REQ]; 245 1 E bit: P2MP Bud-LSR capability: When set, this indicates 246 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 247 LSR that is both transit and egress [P2MP-REQ]; 249 The values for the B and E bits are to be assigned by IANA. 251 2-31 Reserved for future assignments by IANA. 253 4.1.2. The CONTROL-PLANE-CAP sub-TLV 255 The CONTROL-PLANE-CAP sub-TLV is a series of bit flags, where each 256 bit correspond to a control plane TE node capability, and has a 257 variable length. 259 The format of the CONTROL-PLANE-CAP sub-TLV is as follows: 261 TYPE To be assigned by IANA (suggested value = 2) 262 LENGHT It is set to N x 4 octets. N starts 263 from 1 and can be increased when there is a need. 264 Each 4 octets are referred to as a capability flag. 265 VALUE This comprises one or more capability flags. 266 For each 4 octets, the bits are indexed from the most 267 significant to the least significant, where each bit 268 represents one control plane TE node capability. When 269 the first 32 capabilities are defined, a new 270 capability flag will be used to accommodate the next 271 capability. These bits are under IANA control. 273 The following bits are defined in the first capability: 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |M|G|P| Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Bit Capabilities 281 0 M bit: If set this indicates that the LSR supports 282 MPLS-TE signaling ([RSVP-TE]). 284 1 G bit: If set this indicates that the LSR supports 285 GMPLS signaling ([RSVP-G]). 287 2 P bit: If set this indicates that the LSR supports 288 P2MP MPLS-TE signaling ([RSVP-P2MP]). 290 3-31 Reserved for future assignments by IANA 292 The values for the M, G and P bits are to be assigned by IANA. 294 4.2. IS-IS TE Node Capability Descriptor TLV format 296 The IS-IS TE Node Capability Descriptor TLV is made of various non 297 ordered sub-TLVs. 299 The format of the IS-IS TE Node Capability TLV and its sub-TLVs is 300 the same as the TLV format used by the Traffic Engineering Extensions 301 to IS-IS [IS-IS-TE]. That is, the TLV is composed of 1 octet for the 302 type, 1 octet specifying the TLV length and a value field. 304 The IS-IS TE Node Capability Descriptor TLV has the following format: 306 TYPE: To be assigned by IANA 307 LENGTH: Variable, from 3 to 255 308 VALUE: set of one or more sub-TLVs 310 Currently two sub-TLVs are defined: 311 Sub-TLV type Length Name 312 1 variable DATA-PLANE-CAP sub-TLV 313 2 variable CONTROL-PLANE-CAP sub-TLV 315 Any unrecognized sub-TLV MUST be silently ignored. More sub-TLVs 316 could be added in the future to handle new capabilities. 318 The IS-IS TE Node Capability Descriptor TLV is carried within an IS- 319 IS CAPABILITY TLV which is defined in [ISIS-CAP]. 321 4.2.1. DATA-PLANE-CAP sub-TLV 323 The DATA-PLANE-CAP sub-TLV is a series of bit flags, where each bit 324 correspond to a data plane TE node capability, and has a variable 325 length. These bits are under IANA control. 327 The DATA-PLANE-CAP sub-TLV has the following format: 329 TYPE: To be assigned by IANA (Suggested value =1) 330 LENGTH: It is set to N. N starts from 1 and can be increased when 331 there is a need. Each octet is referred to as a 332 capability flag. 333 VALUE: This comprises one or more data plane TE node capability 334 flags. 336 The following bits are defined in the first capability flag: 338 0 1 2 3 4 5 6 7 339 +-+-+-+-+-+-+-+-+ 340 |B|E| Reserved | 341 +-+-+-+-+-+-+-+-+ 343 B bit: P2MP Branch node capability: When set this indicates 344 that the LSR can act as a branch node on a P2MP LSP 345 ([P2MP-REQ]). 346 E bit: P2MP bud-LSR capability: When set, this indicates 347 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 348 LSR that is both transit and egress ([P2MP-REQ]). 350 Reserved bits are for future assignment by IANA 352 The values for the B and E bits are to be assigned by IANA. 354 4.2.2. CONTROL-PLANE-CAP sub-TLV 356 The CONTROL-PLANE-CAP sub-TLV is a series of bit flags, where each 357 bit correspond to a control plane TE node capability, and has a 358 variable length. These bits are under IANA control. 360 The CONTROL-PLANE-CAP sub-TLV has the following format: 362 TYPE: To be assigned by IANA (suggested value = 2) 363 LENGTH: It is set to N. N starts from 1 and can be increased 364 when there is a need. Each octet is referred to as a 365 capability flag. 366 VALUE: This comprises one or more control plane TE node capability 367 flags. 369 The following bits defined in the first capability flag: 371 0 1 2 3 4 5 6 7 372 +-+-+-+-+-+-+-+-+ 373 |M|G|P|Reserved | 374 +-+-+-+-+-+-+-+-+ 376 -M bit: If set this indicates that the LSR supports MPLS-TE 377 signaling ([RSVP-TE]). 379 -G bit: If set this indicates that the LSR supports GMPLS signaling 380 ([RSVP-G]). 382 -P bit: If set this indicates that the LSR supports P2MP MPLS-TE 383 signaling ([RSVP-P2MP]). 385 Reserved bits are for future assignment by IANA. 387 The values for the M, G and P bits are to be assigned by IANA. 389 5. Elements of procedure 391 5.1. OSPF 393 The TE Node Capability Descriptor TLV is advertised, within an OSPFv2 394 Router Information LSA (Opaque type of 4 and Opaque ID of 0) 395 or OSPFv3 Router information LSA (function code of 12) which are 396 defined in [OSPF-CAP]. As such, elements of procedure are inherited 397 from those defined in [OSPF-CAP]. 399 The TE Node Capability Descriptor TLV advertises capabilities that 400 may be taken into account as constraints during path selection. Hence 401 its flooding scope is area-local, and it MUST be carried within 402 OSPFv2 type 10 Router Information LSA (as defined in [RFC2370]) or an 403 OSPFv3 Router Information LSA with the S1 bit set and the S2 bit 404 cleared (as defined in [OSPFv3]). 406 A router MUST originate a new OSPF router information LSA whenever 407 the content of any of the TE Node Capability Descriptor TLV changes 408 or whenever required by the regular OSPF procedure (LSA refresh 409 (every LSRefreshTime)). 411 The TE Node Capability Descriptor TLV is OPTIONAL and must at most 412 appear once in an OSPF Router Information LSA or ISIS Router 413 Capability TLV. 415 When an OSPF LSA or ISIS LSP does not contain any TE Node capability 416 Descriptor TLV, this means that the TE Capabilities of that LSR are 417 unknown. 419 Note that a change in any of these capabilities MAY trigger CSPF 420 computation, but MUST not trigger normal SPF computation. 422 Note also that TE node capabilities are expected to be fairly static. 424 5.2. IS-IS 426 The TE Node Capability TLV is carried within an IS-IS CAPABILITY TLV 427 defined in [IS-IS-CAP]. As such, elements of procedure are inherited 428 from those defined in [IS-IS-CAP]. 430 The TE Node Capability Descriptor TLV advertises capabilities that 431 may be taken into account as constraints during path selection. Hence 432 its flooding is area-local, and MUST be carried within an IS-IS 433 CAPABILITY TLV having the S flag cleared. 435 An IS-IS router MUST originate a new IS-IS LSP whenever the content 436 of any of the TE Node Capability TLV changes or whenever required by 437 the regular IS-IS procedure (LSP refresh). 439 The TE Node Capability Descriptor TLV is OPTIONAL and must at most 440 appear once in an OSPF Router Information LSA or ISIS Router 441 Capability TLV. 443 When a IS-IS LSP does not contain any TE Node capability Descriptor 444 TLV, this means that the TE Capabilities of that LSR are unknown. 446 Note that a change in any of these capabilities MAY trigger CSPF 447 computation, but MUST not trigger normal SPF computation. 449 Note also that TE node capabilities are expected to be fairly static. 451 6. Backward compatibility 453 The TE Node Capability Descriptor TLVs defined in this document do 454 not introduce any interoperability issue. For OSPF, a router not 455 supporting the TE Node Capability Descriptor TLV MUST just silently 456 ignore the TLV as specified in [OSPF-CAP]. For IS-IS a router not 457 supporting the TE Node Capability Descriptor TLV MUST just silently 458 ignore the TLV as specified in [IS-IS-CAP]. 460 7. Security Considerations 462 No new security issues are raised in this document. 464 8. IANA considerations 466 8.1. OSPF TLVs 468 IANA is in charge of the assignment of TLV code points for the Router 469 Information LSA defined in [OSPF-CAP]. 471 IANA will assign a new codepoint for the TE Node Capability 472 Descriptor TLV defined in this document and carried within the Router 473 Information LSA. 475 IANA will be in charge of the assignment of sub-TLV code points for 476 the TE Node Capability Descriptor TLV defined in this document. 477 Two sub-TLVs types are defined for this TLV and should be assigned by 478 IANA: 479 -CONTROL-PLANE-CAP sub-TLV (suggested value =1) 480 -DATA-PLANE-CAP sub-TLV (suggested value =2) 482 8.2. ISIS TLVs 484 IANA is in charge of the assignment of sub-TLV code points for the 485 ISIS CAPABILITY TLV defined in [ISIS-CAP]. 486 IANA will assign a new codepoint for the TE Node Capability 487 Descriptor TLV defined in this document, and carried within the ISIS 488 CAPABILITY TLV. 490 IANA will be in charge of the assignment of sub-TLV code points for 491 the TE Node Capability Descriptor TLV defined in this document. 492 Two sub-TLVs types are defined for this TLV and should be assigned by 493 IANA: 494 -CONTROL-PLANE-CAP sub-TLV (suggested value =1) 495 -DATA-PLANE-CAP sub-TLV (suggested value =2) 497 8.3. Capability bits 499 IANA is requested to manage the space of control plane and data plane 500 capability bit flags carried within the OSPF and ISIS TE Node 501 Capability Descriptor TLVs, numbering them in the usual IETF notation 502 starting at zero and continuing at least through 31. 503 New bit numbers may be allocated only by an IETF Consensus action. 504 Each bit should be tracked with the following qualities: 505 - Bit number 506 - Defining RFC 507 - Name of bit 509 Currently two capabilies are defined in the data plane capability 510 flags and must be assigned by IANA. Here are the suggested values: 511 -0x01: P2MP Branch LSR capability 512 -0x02: P2MP Bud LSR capability 514 Currently three capabilities are defined in the control plane 515 capability flags and must be assigned by IANA. Here are the suggested 516 values: 517 -0x01: MPLS-TE support 518 -0x02: GMPLS support 519 -0x04: P2MP RSVP-TE support 521 9. Acknowledgments 523 We would like to thank Benoit Fondeviole, Adrian Farrel, Dimitri 524 Papadimitriou, Acee Lindem and David Ward for their useful comments 525 and suggestions. 527 We would also like to thank authors of [LSP-ATTRIBUTE] and [OSPF-CAP] 528 from which some text of this document has been inspired. 530 10. References 532 10.1. Normative references 534 [RFC] Bradner, S., "Key words for use in RFCs to indicate 535 requirements levels", RFC 2119, March 1997. 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 541 3667, February 2004. 543 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 544 Technology", RFC 3979, March 2005. 546 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 548 [OSPF-v3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 549 RFC 2740, December 1999. 551 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 552 July 1998. 554 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 555 Routing Exchange Protocol " ISO 10589. 557 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 558 dual environments", RFC 1195, December 1990. 560 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 561 Extensions to OSPF Version 2", RFC 3630, September 2003. 563 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 564 Engineering", RFC 3784, June 2004. 566 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 567 J.P., "Extensions to OSPF for advertising Optional Router 568 Capabilities", draft-ietf-ospf-cap, work in progress. 570 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 571 router information", draft-ietf-isis-caps, work in progress. 573 10.2. Informative References 575 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 576 tunnels", RFC 3209, December 2001. 578 [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 579 RFC 3473, January 2003. 581 [GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support 582 of Generalized Multi-Protocol Label Switching", RFC4202, October 583 2005. 585 [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of 586 Generalized Multi-protocol Label Switching", RFC4203, October 2005. 588 [IS-IS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 589 Generalized Multi-protocol Label Switching", RFC4205, October 2005. 591 [P2MP-REQ] Yasukawa, S., et. al., "Signaling Requirements for Point 592 to Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006. 594 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 595 RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 596 p2mp, work in progress. 598 [LSP-ATTRIBUTE] Farrel, A., and al., "Encoding of attributes for MPLS 599 LSPs establishment Using RSVP-TE", RFC4420, February 2006. 601 11. Editors Address 603 Jean-Philippe Vasseur 604 Cisco Systems, Inc. 605 1414 Massachusetts Avenue 606 Boxborough , MA - 01719 607 USA 608 Email: jpv@cisco.com 610 Jean-Louis Le Roux 611 France Telecom 612 2, avenue Pierre-Marzin 613 22307 Lannion Cedex 614 FRANCE 615 Email: jeanlouis.leroux@francetelecom.com 617 12. Contributors address 619 Seisho Yasukawa 620 NTT 621 9-11, Midori-Cho 3-Chome 622 Tokyo, 180-8585 623 JAPAN 624 Email: yasukawa.seisho@lab.ntt.co.jp 626 Stefano Previdi 627 Cisco Systems, Inc 628 Via Del Serafico 200 629 Roma, 00142 630 Italy 631 Email: sprevidi@cisco.com 633 Peter Psenak 634 Cisco Systems, Inc 635 Pegasus Park DE Kleetlaan 6A 636 Diegmen, 1831 637 BELGIUM 638 Email: ppsenak@cisco.com 640 Paul Mabbey 641 Comcast 642 USA 643 Email: 645 13. Intellectual Property Statement 647 The IETF takes no position regarding the validity or scope of any 648 Intellectual Property Rights or other rights that might be claimed to 649 pertain to the implementation or use of the technology described in 650 this document or the extent to which any license under such rights 651 might or might not be available; nor does it represent that it has 652 made any independent effort to identify any such rights. Information 653 on the procedures with respect to rights in RFC documents can be 654 found in BCP 78 and BCP 79. 656 Copies of IPR disclosures made to the IETF Secretariat and any 657 assurances of licenses to be made available, or the result of an 658 attempt made to obtain a general license or permission for the use of 659 such proprietary rights by implementers or users of this 660 specification can be obtained from the IETF on-line IPR repository at 661 http://www.ietf.org/ipr. 663 The IETF invites any interested party to bring to its attention any 664 copyrights, patents or patent applications, or other proprietary 665 rights that may cover technology that may be required to implement 666 this standard. Please address the information to the IETF at 667 ietf-ipr@ietf.org. 669 Disclaimer of Validity 671 This document and the information contained herein are provided on an 672 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 673 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 674 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 675 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 676 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 677 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 679 Copyright Statement 681 Copyright (C) The Internet Society (2006). This document is subject 682 to the rights, licenses and restrictions contained in BCP 78, and 683 except as set forth therein, the authors retain all their rights.