idnits 2.17.1 draft-ietf-ccamp-te-node-cap-02.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 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 697. ** 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 2006) is 6404 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 98, but not defined == Missing Reference: 'OSPFv3-TE' is mentioned on line 104, but not defined == Missing Reference: 'RFC4205' is mentioned on line 108, but not defined ** Obsolete undefined reference: RFC 4205 (Obsoleted by RFC 5307) == Missing Reference: 'RFC4203' is mentioned on line 109, but not defined == Missing Reference: 'ISIS-CAP' is mentioned on line 506, but not defined == Missing Reference: 'RFC3473' is mentioned on line 364, but not defined == Missing Reference: 'ISIS-HMAC' is mentioned on line 480, but not defined == Missing Reference: 'OSPF-SIG' is mentioned on line 480, but not defined == Unused Reference: 'RFC2119' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC3567' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC2154' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RSVP-G' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'OSPF-G' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'IS-IS-G' is defined on line 625, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2740 (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 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) ** Downref: Normative reference to an Experimental RFC: RFC 2154 -- 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: 11 errors (**), 0 flaws (~~), 18 warnings (==), 10 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: April 2007 NTT 8 S. Previdi 9 P. Psenak 10 Cisco Systems, Inc. 11 Paul Mabey 12 Comcast 14 October 2006 16 IGP Routing Protocol Extensions for Discovery of Traffic Engineering 17 Node Capabilities 19 draft-ietf-ccamp-te-node-cap-02.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 Multi Protocol Label 47 Switching (MPLS) Traffic Engineered Label Switched Path (TE-LSP) 48 selection, such as for instance the capability to act as a branch 49 Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP. 50 This requires advertising these capabilities within the Interior 51 Gateway Protocol (IGP). For that purpose, this document specifies 52 Open Shortest Path First (OSPF) and Intermediate System-Intermediate 53 System (IS-IS) traffic engineering extensions for the advertisement 54 of control plane and data plane traffic engineering node 55 capabilities. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119. 63 Table of Contents 65 1. Terminology.................................................3 66 2. Introduction................................................3 67 3. TE Node Capability Descriptor...............................4 68 3.1. Description.................................................4 69 3.2. Required Information........................................4 70 4. TE Node Capability Descriptor TLV formats...................5 71 4.1. OSPF TE Node Capability Descriptor TLV format...............5 72 4.1.1. The DATA-PLANE-CAP sub-TLV..................................5 73 4.1.2. The CONTROL-PLANE-CAP sub-TLV...............................6 74 4.2. IS-IS TE Node Capability Descriptor TLV format..............7 75 4.2.1. DATA-PLANE-CAP sub-TLV......................................7 76 4.2.2. CONTROL-PLANE-CAP sub-TLV...................................8 77 5. Elements of procedure.......................................9 78 5.1. OSPF........................................................9 79 5.2. IS-IS......................................................10 80 6. Backward compatibility.....................................10 81 7. Security Considerations....................................11 82 8. IANA considerations........................................11 83 8.1. OSPF TLVs..................................................11 84 8.2. ISIS TLVs..................................................11 85 8.3. Capability Registries......................................12 86 8.3.1. Data Plane Capabilities Registry...........................12 87 8.3.2. Control Plane Capabilities Registry........................12 88 9. Acknowledgments............................................13 89 10. References.................................................13 90 10.1. Normative references.......................................13 91 10.2. Informative References.....................................14 92 11. Editors' Addresses.........................................14 93 12. Contributors' Addresses....................................14 94 13. Intellectual Property Statement............................15 96 1. Terminology 98 This document uses terminologies defined in [RFC3031], [RFC3209] and 99 [RFC4461]. 101 2. Introduction 103 Multi Protocol Label Switching-Traffic Engineering (MPLS-TE) routing 104 ([RFC3784], [RFC3630], [OSPFv3-TE]) relies on extensions to link 105 state Interior Gateway Protocols (IGP) ([IS-IS], [RFC2328], 106 [RFC2740]) in order to advertise Traffic Engineering (TE) link 107 information used for constraint based routing. Further Generalized 108 MPLS (GMPLS) related routing extensions are defined in [RFC4205] and 109 [RFC4203]. 111 It is desired to complement these routing extensions in order to 112 advertise TE node capabilities, in addition to TE link information. 113 These TE node capabilities will be taken into account as constraints 114 during path selection. 116 Indeed, it is useful to advertise data plane TE node capabilities, 117 such as the capability for a Label Switching Router (LSR) to be a 118 branch LSR or a bud-LSR of a Point-To-MultiPoint (P2MP) Label 119 Switched Path (LSP). These capabilities can then be taken into 120 account as constraints when computing the route of TE LSPs. 122 It is also useful to advertise control plane TE node capabilities 123 such as the capability to support GMPLS signaling for a packet LSR, 124 or the capability to support P2MP (Point to Multipoint) TE LSP 125 signaling. This allows selecting a path that avoids nodes that do 126 not support a given signaling feature, or triggering a mechanism to 127 support such nodes. Hence this facilitates backward compatibility. 129 For that purpose, this document specifies IGP (OSPF and IS-IS) 130 traffic engineering node capability TLVs in order to advertise data 131 plane and control plane capabilities of a node. 133 A new TLV is defined for ISIS and OSPF: the TE Node Capability 134 Descriptor TLV, to be carried within: 135 - The ISIS Capability TLV ([ISIS-CAP]) for ISIS 136 - The Router Information LSA ([OSPF-CAP]) for OSPF. 138 3. TE Node Capability Descriptor 140 3.1. Description 142 LSRs in a network may have distinct control plane and data plane 143 Traffic Engineering capabilities. The TE Node Capability Descriptor 144 information defined in this document describes data and control plane 145 capabilities of an LSR. Such information can be used during path 146 computation so as to avoid nodes that do not support a given TE 147 feature either in the control or data plane, or to trigger procedures 148 to handle these nodes along the path (e.g, trigger LSP hierarchy to 149 support a legacy transit LSR on a P2MP LSP (see [RSVP-P2MP])). 151 3.2. Required Information 153 The TE Node Capability Descriptor contains two variable length sets 154 of bit flags: 155 - The Data Plane Capabilities: This is a variable length 156 set of bit flags where each bit corresponds to a given data 157 plane TE node capability. 158 - The Control Plane Capabilities: This is a variable length 159 set of bit flags where each bit corresponds to a given 160 control plane TE node capability. 162 Two Data Plane Capabilities are defined in this document: 163 - B bit: when set, this flag indicates that the LSR can act 164 as a branch node on a P2MP LSP (see [RFC4461]); 165 - E bit: when set, this flag indicates that the LSR can act 166 as a bud LSR on a P2MP LSP, i.e. an LSR that is both 167 transit and egress (see [RFC4461]). 169 Three Control Plane Capabilities are defined in this document: 170 - M bit: when set, this flag indicates that the LSR supports 171 MPLS-TE signaling ([RFC3209]); 172 - G bit: when set this flag indicates that the LSR supports 173 GMPLS signaling ([RFC3473]); 174 - P bit: when set, this flag indicates that the LSR supports 175 P2MP MPLS-TE signaling ([RSVP-P2MP]). 177 Note that new capability bits may be added in the future if required. 178 Also, more complex capabilities encoded within sub-TLVs may be added 179 in the future if required. 181 4. TE Node Capability Descriptor TLV formats 183 4.1. OSPF TE Node Capability Descriptor TLV format 185 The OSPF TE Node Capability Descriptor TLV contains a non ordered set 186 of sub-TLVs. 188 The format of the OSPF TE Node Capability Descriptor TLV and its sub- 189 TLVs is the same as the TLV format used by the Traffic Engineering 190 Extensions to OSPF [RFC3630]. That is, the TLV is composed of 2 191 octets for the type, 2 octets specifying the length of the value 192 field and a value field. The TLV is zero padded to four-octet 193 alignment; padding is not included in the length field value (so a 194 three octet value would have a length of three, but the total size of 195 the TLV would be eight octets). Sub-TLVs are also 32-bit aligned. 196 Unrecognized types are ignored. All types between 32768 and 65535 197 are reserved for vendor-specific extensions. All other undefined 198 type codes are reserved for future assignment by IANA. 200 The OSPF TE Node Capability Descriptor TLV has the following format: 202 TYPE To be defined by IANA 203 LENGTH Variable 204 VALUE This comprises one or more sub-TLVs 206 Currently two sub-TLVs are defined: 207 Sub-TLV type Length Name 208 1 variable DATA-PLANE-CAP sub-TLV 209 2 variable CONTROL-PLANE-CAP sub-TLV 211 Any unrecognized sub-TLV MUST be silently ignored. 212 More sub-TLVs could be added in the future to handle new 213 capabilities. 215 The OSPF TE Node Capability Descriptor TLV is carried within an OSPF 216 Router Information LSA which is defined in [OSPF-CAP]. 218 4.1.1. The DATA-PLANE-CAP sub-TLV 220 The DATA-PLANE-CAP sub-TLV is a variable length TLV that contains a 221 series of bit flags, where each bit correspond to a data plane TE 222 node capability. 224 The format of the DATA-PLANE-CAP sub-TLV is as follows: 226 TYPE To be assigned by IANA (suggested value =1). 227 LENGTH Variable (multiple of 4). 228 VALUE Array of units of 32 flags numbered from the most 229 significant bit as bit zero, where each bit represents 230 a data plane TE node capability. 232 The following bits are defined: 234 Bit Capabilities 236 0 B bit: P2MP Branch Node capability: When set this indicates 237 that the LSR can act as a branch node on a P2MP LSP 238 [RFC4461]. 239 1 E bit: P2MP Bud-LSR capability: When set, this indicates 240 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 241 LSR that is both transit and egress [RFC4461]. 243 The values for the B and E bits are to be assigned by IANA. 245 2-31 Reserved for future assignments by IANA. 247 Unassigned bits are considered as reserved and MUST be set to zero on 248 transmission by the advertising LSR. 250 4.1.2. The CONTROL-PLANE-CAP sub-TLV 252 The CONTROL-PLANE-CAP sub-TLV is a variable length TLV that contains 253 a series of bit flags, where each bit correspond to a control plane 254 TE node capability. 256 The format of the CONTROL-PLANE-CAP sub-TLV is as follows: 258 TYPE To be assigned by IANA (suggested value = 2). 259 LENGTH Variable (multiple of 4). 260 VALUE Array of units of 32 flags numbered from the most 261 significant bit as bit zero, where each bit represents 262 a control plane TE node capability. 264 The following bits are defined: 266 Bit Capabilities 268 0 M bit: If set this indicates that the LSR supports 269 MPLS-TE signaling ([RFC3209]). 271 1 G bit: If set this indicates that the LSR supports 272 GMPLS signaling ([RFC3473]). 274 2 P bit: If set this indicates that the LSR supports 275 P2MP MPLS-TE signaling ([RSVP-P2MP]). 277 3-31 Reserved for future assignments by IANA 279 The values for the M, G and P bits are to be assigned by IANA. 280 Unassigned bits are considered as reserved and MUST be set to zero on 281 transmission by the advertising LSR. 283 4.2. IS-IS TE Node Capability Descriptor TLV format 285 The IS-IS TE Node Capability Descriptor TLV contains a non ordered 286 set of sub-TLVs. 288 The format of the IS-IS TE Node Capability TLV and its sub-TLVs is 289 the same as the TLV format used by the Traffic Engineering Extensions 290 to IS-IS [RFC3784]. That is, the TLV is composed of 1 octet for the 291 type, 1 octet specifying the TLV length and a value field. 293 The IS-IS TE Node Capability Descriptor TLV has the following format: 295 TYPE: To be assigned by IANA 296 LENGTH: Variable, from 3 to 255 297 VALUE: set of one or more sub-TLVs 299 Currently two sub-TLVs are defined: 300 Sub-TLV type Length Name 301 1 variable DATA-PLANE-CAP sub-TLV 302 2 variable CONTROL-PLANE-CAP sub-TLV 304 Any unrecognized sub-TLV MUST be silently ignored. More sub-TLVs 305 could be added in the future to handle new capabilities. 307 The IS-IS TE Node Capability Descriptor TLV is carried within an IS- 308 IS CAPABILITY TLV which is defined in [ISIS-CAP]. 310 4.2.1. DATA-PLANE-CAP sub-TLV 312 The DATA-PLANE-CAP sub-TLV is a variable length TLV that contains a 313 series of bit flags, where each bit correspond to a data plane TE 314 node capability. 316 The DATA-PLANE-CAP sub-TLV has the following format: 318 TYPE: To be assigned by IANA (Suggested value =1) 319 LENGTH: Variable 320 VALUE: Array of units of 8 flags numbered from the most 321 significant bit as bit zero, where each bit represents 322 a data plane TE node capability. 324 The following bits are defined: 326 Bit Capabilities 328 0 B bit: P2MP Branch Node capability: When set this indicates 329 that the LSR can act as a branch node on a P2MP LSP 330 [RFC4461]. 331 1 E bit: P2MP Bud-LSR capability: When set, this indicates 332 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 333 LSR that is both transit and egress [RFC4461]. 335 The values for the B and E bits are to be assigned by IANA. 337 2-7 Reserved for future assignments by IANA. 339 Unassigned bits are considered as reserved and MUST be set to zero on 340 transmission by the advertising LSR. 342 4.2.2. CONTROL-PLANE-CAP sub-TLV 344 The CONTROL-PLANE-CAP sub-TLV is a variable length TLV that contains 345 a series of bit flags, where each bit correspond to a control plane 346 TE node capability. 348 The CONTROL-PLANE-CAP sub-TLV has the following format: 350 TYPE: To be assigned by IANA (suggested value = 2). 351 LENGTH: Variable. 352 VALUE: Array of units of 8 flags numbered from the most 353 significant bit as bit zero, where each bit represents 354 a control plane TE node capability. 356 The following bits are defined: 358 Bit Capabilities 360 0 M bit: If set this indicates that the LSR supports 361 MPLS-TE signaling ([RFC3209]). 363 1 G bit: If set this indicates that the LSR supports 364 GMPLS signaling ([RFC3473]). 366 2 P bit: If set this indicates that the LSR supports 367 P2MP MPLS-TE signaling ([RSVP-P2MP]). 369 3-7 Reserved for future assignments by IANA 371 The values for the M, G and P bits are to be assigned by IANA. 373 Unassigned bits are considered as reserved and MUST be set to zero on 374 transmission by the advertising LSR. 376 5. Elements of procedure 378 5.1. OSPF 380 The TE Node Capability Descriptor TLV is advertised, within an OSPFv2 381 Router Information LSA (Opaque type of 4 and Opaque ID of 0) 382 or an OSPFv3 Router information LSA (function code of 12) which are 383 defined in [OSPF-CAP]. As such, elements of procedure are inherited 384 from those defined in [RFC2328], [RFC2740], and [OSPF-CAP]. 386 The TE Node Capability Descriptor TLV advertises capabilities that 387 may be taken into account as constraints during path selection. Hence 388 its flooding scope is area-local, and it MUST be carried within 389 OSPFv2 type 10 Router Information LSA (as defined in [RFC2370]) or an 390 OSPFv3 Router Information LSA with the S1 bit set and the S2 bit 391 cleared (as defined in [RFC2740]). 393 A router MUST originate a new OSPF router information LSA whenever 394 the content of the TE Node Capability Descriptor TLV changes or 395 whenever required by the regular OSPF procedure (LSA refresh (every 396 LSRefreshTime)). 398 The TE Node Capability Descriptor TLV is OPTIONAL and MUST appear at 399 most once in an OSPF Router Information LSA. If a TE Node Capability 400 Descriptor TLV appears more than once in an OSPF Router Information 401 LSA, only the first occurrence MUST be processed, other occurrences 402 MUST be discarded. 404 The TE Node Capability Descriptor TLV MUST contain at least one sub- 405 TLV. An empty TE Node Capability Descriptor MUST be discarded. 407 When an OSPF LSA does not contain any TE Node capability Descriptor 408 TLV, this means that the TE Capabilities of that LSR are unknown. 410 Note that a change in any of these capabilities MAY trigger CSPF 411 computation, but MUST not trigger normal SPF computation. 413 Note also that TE node capabilities are expected to be fairly static. 414 They may change as the result of configuration change, or software 415 upgrade. This is expected not to appear more than once a day. 417 5.2. IS-IS 419 The TE Node Capability TLV is carried within an IS-IS CAPABILITY TLV 420 defined in [IS-IS-CAP]. As such, elements of procedure are inherited 421 from those defined in [IS-IS-CAP]. 423 The TE Node Capability Descriptor TLV advertises capabilities that 424 may be taken into account as constraints during path selection. Hence 425 its flooding is area-local, and MUST be carried within an IS-IS 426 CAPABILITY TLV having the S flag cleared. 428 An IS-IS router MUST originate a new IS-IS LSP whenever the content 429 of any of the TE Node Capability TLV changes or whenever required by 430 the regular IS-IS procedure (LSP refresh). 432 The TE Node Capability Descriptor TLV is OPTIONAL and MUST appear at 433 most once in an ISIS Router Capability TLV. If a TE Node Capability 434 Descriptor TLV appears more than once in an ISIS Capability TLV, only 435 the first occurrence MUST be processed, other occurrences MUST be 436 discarded. 438 The TE Node Capability Descriptor TLV MUST contain at least one sub- 439 TLV. An empty TE Node Capability Descriptor MUST be discarded. 441 When an IS-IS LSP does not contain any TE Node capability Descriptor 442 TLV, this means that the TE Capabilities of that LSR are unknown. 444 Note that a change in any of these capabilities MAY trigger CSPF 445 computation, but MUST not trigger normal SPF computation. 447 Note also that TE node capabilities are expected to be fairly static. 448 They may change as the result of configuration change, or software 449 upgrade. This is expected not to appear more than once a day. 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 When the TE Node capability Descriptor TLV is absent, this means that 461 the TE Capabilities of that LSR are unknown. 463 When the TE Node Capability Descriptor TLV is present, but a sub-TLV 464 is absent, this means that capabilities in that sub-TLV are unknown. 466 The absence of a word of capability flags in OSPF or an octet of 467 capability flags in IS-IS means that these capabilities are unknown. 469 An unknown sub-TLV carried within the TE Node Capability Descriptor 470 MUST be silently ignored. 472 7. Security Considerations 474 This document specifies the content of the TE Node Capability 475 Descriptor TLV in ISIS and OSPF, to be used for (G)MPLS-TE path 476 computation. As this TLV is not used for SPF computation or normal 477 routing, the extensions specified here have no direct effect on IP 478 routing. Tampering with this TLV may have an effect on Traffic 479 Engineering computation. Mechanisms defined to secure ISIS Link State 480 PDUs [ISIS-HMAC], OSPF LSAs [OSPF-SIG], and their TLVs, can be used 481 to secure this TLV as well. 483 8. IANA considerations 485 8.1. OSPF TLVs 487 IANA is in charge of the assignment of TLV code points for the Router 488 Information LSA defined in [OSPF-CAP]. 489 IANA will assign a new codepoint for the TE Node Capability 490 Descriptor TLV defined in this document and carried within the Router 491 Information LSA (suggested value = 1). 493 IANA will be in charge of the assignment of sub-TLV code points for 494 the OSPF TE Node Capability Descriptor TLV defined in this document. 495 New TLV type values may be allocated only by an IETF Consensus 496 action. 498 Two sub-TLVs types are defined for this TLV and must be assigned by 499 IANA: 500 -DATA-PLANE-CAP sub-TLV (suggested value =1) 501 -CONTROL-PLANE-CAP sub-TLV (suggested value =2) 503 8.2. ISIS TLVs 505 IANA is in charge of the assignment of sub-TLV code points for the 506 ISIS CAPABILITY TLV defined in [ISIS-CAP]. 507 IANA will assign a new codepoint for the TE Node Capability 508 Descriptor TLV defined in this document, and carried within the ISIS 509 CAPABILITY TLV (suggested value = 1). 511 IANA will be in charge of the assignment of sub-TLV code points for 512 the ISIS TE Node Capability Descriptor TLV defined in this document. 513 New TLV type values may be allocated only by an IETF Consensus 514 action. 516 Two sub-TLVs types are defined for this TLV and must be assigned by 517 IANA: 518 -DATA-PLANE-CAP sub-TLV (suggested value =1) 519 -CONTROL-PLANE-CAP sub-TLV (suggested value =2) 521 Note that ISIS and OSPF TE Node Capability Descriptor sub-TLVs types 522 must be aligned. 524 8.3. Capability Registries 526 8.3.1. Data Plane Capabilities Registry 528 IANA is requested to manage the space of data plane capability bit 529 flags carried within the OSPF and ISIS DATA-PLANE-CAP sub-TLVs, 530 numbering them in the usual IETF notation starting at zero, with the 531 most significant bit as bit zero. A single registry must be defined 532 for both protocols. 533 New bit numbers may be allocated only by an IETF Consensus action. 534 Each bit should be tracked with the following qualities: 535 - Bit number 536 - Defining RFC 537 - Name of bit 539 Two data plane capabilities are defined in this document and must be 540 assigned by IANA. Here are the suggested values: 541 1 : B Bit = P2MP Branch LSR capability 542 2 : E bit = P2MP Bud LSR capability 544 8.3.2. Control Plane Capabilities Registry 546 IANA is requested to manage the space of control plane capability bit 547 flags carried within the OSPF and ISIS CONTROL-PLANE-CAP sub-TLVs, 548 numbering them in the usual IETF notation starting at zero, with the 549 most significant bit as bit zero. A single registry must be defined 550 for both protocols. 551 New bit numbers may be allocated only by an IETF Consensus action. 552 Each bit should be tracked with the following qualities: 553 - Bit number 554 - Defining RFC 555 - Name of bit 557 Three control plane capabilities are defined in this document and 558 must be assigned by IANA. Here are the suggested values: 559 1 : M bit = MPLS-TE support ([RFC3209]) 560 2 : G bit = GMPLS support (RFC3473)) 561 3 : P bit = P2MP RSVP-TE support ([RSVP-P2MP]) 563 9. Acknowledgments 565 We would like to thank Benoit Fondeviole, Adrian Farrel, Dimitri 566 Papadimitriou, Acee Lindem and David Ward for their useful comments 567 and suggestions. 569 We would also like to thank authors of [LSP-ATTRIBUTE] and [OSPF-CAP] 570 from which some text of this document has been inspired. 572 10. References 574 10.1. Normative references 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, March 1997. 579 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 581 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 582 RFC 2740, December 1999. 584 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 585 July 1998. 587 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 588 Routing Exchange Protocol " ISO 10589. 590 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 591 Extensions to OSPF Version 2", RFC 3630, September 2003. 593 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 594 Engineering", RFC 3784, June 2004. 596 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 597 J.P., "Extensions to OSPF for advertising Optional Router 598 Capabilities", draft-ietf-ospf-cap, work in progress. 600 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 601 router information", draft-ietf-isis-caps, work in progress. 603 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 604 Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, 605 July 2003. 607 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 608 Digital Signatures", RFC 2154, June 1997. 610 [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 611 tunnels", RFC 3209, December 2001. 613 [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 614 RFC 3473, January 2003. 616 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 617 RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 618 p2mp, work in progress. 620 10.2. Informative References 622 [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of 623 Generalized Multi-protocol Label Switching", RFC4203, October 2005. 625 [IS-IS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 626 Generalized Multi-protocol Label Switching", RFC4205, October 2005. 628 [RFC4461] Yasukawa, S., et. al., "Signaling Requirements for Point to 629 Multipoint Traffic Engineered MPLS LSPs", RFC4461, April 2006. 631 [LSP-ATTRIBUTE] Farrel, A., and al., "Encoding of attributes for MPLS 632 LSPs establishment Using RSVP-TE", RFC4420, February 2006. 634 11. Editors' Addresses 636 Jean-Philippe Vasseur 637 Cisco Systems, Inc. 638 1414 Massachusetts Avenue 639 Boxborough , MA - 01719 640 USA 641 Email: jpv@cisco.com 643 Jean-Louis Le Roux 644 France Telecom 645 2, avenue Pierre-Marzin 646 22307 Lannion Cedex 647 FRANCE 648 Email: jeanlouis.leroux@orange-ft.com 650 12. Contributors' Addresses 652 Seisho Yasukawa 653 NTT 654 3-9-11 Midori-cho, 655 Musashino-shi, Tokyo 180-8585, Japan 656 Email: s.yasukawa@hco.ntt.co.jp 658 Stefano Previdi 659 Cisco Systems, Inc 660 Via Del Serafico 200 661 Roma, 00142 662 Italy 663 Email: sprevidi@cisco.com 664 Peter Psenak 665 Cisco Systems, Inc 666 Pegasus Park DE Kleetlaan 6A 667 Diegmen, 1831 668 BELGIUM 669 Email: ppsenak@cisco.com 671 Paul Mabbey 672 Comcast 673 USA 675 13. Intellectual Property Statement 677 The IETF takes no position regarding the validity or scope of any 678 Intellectual Property Rights or other rights that might be claimed to 679 pertain to the implementation or use of the technology described in 680 this document or the extent to which any license under such rights 681 might or might not be available; nor does it represent that it has 682 made any independent effort to identify any such rights. Information 683 on the procedures with respect to rights in RFC documents can be 684 found in BCP 78 and BCP 79. 686 Copies of IPR disclosures made to the IETF Secretariat and any 687 assurances of licenses to be made available, or the result of an 688 attempt made to obtain a general license or permission for the use of 689 such proprietary rights by implementers or users of this 690 specification can be obtained from the IETF on-line IPR repository at 691 http://www.ietf.org/ipr. 693 The IETF invites any interested party to bring to its attention any 694 copyrights, patents or patent applications, or other proprietary 695 rights that may cover technology that may be required to implement 696 this standard. Please address the information to the IETF at 697 ietf-ipr@ietf.org. 699 Disclaimer of Validity 701 This document and the information contained herein are provided on an 702 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 703 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 704 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 705 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 706 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 707 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 709 Copyright Statement 711 Copyright (C) The Internet Society (2006). This document is subject 712 to the rights, licenses and restrictions contained in BCP 78, and 713 except as set forth therein, the authors retain all their rights.