idnits 2.17.1 draft-vasseur-mpls-ospf-te-cap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 859 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([18]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1 has weird spacing: '...t draft draf...' == Line 52 has weird spacing: '...t draft dra...' == Line 104 has weird spacing: '...t draft dra...' == Line 158 has weird spacing: '...t draft dra...' == Line 210 has weird spacing: '...t draft dra...' == (8 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2002) is 7863 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) == Unused Reference: '1' is defined on line 610, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 612, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 615, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 624, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 627, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 630, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 633, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 641, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 645, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 650, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 653, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 656, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 659, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 662, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 665, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. '2') ** Obsolete normative reference: RFC 2370 (ref. '3') (Obsoleted by RFC 5250) -- No information found for draft-vasseur-mpls-computation-rsvp-te - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-04 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-03 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. '6') == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-01 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-06 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 == Outdated reference: A later version (-01) exists of draft-lefaucheur-te-metric-igp-00 -- Possible downref: Normative reference to a draft: ref. '16' -- Possible downref: Normative reference to a draft: ref. '17' -- Possible downref: Normative reference to a draft: ref. '18' Summary: 8 errors (**), 0 flaws (~~), 32 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 3 Network Working Group JP Vasseur 4 Internet Draft Peter Psenak 5 Document: draft-vasseur-mpls-ospf-te-cap-00.txt Cisco Systems, Inc 7 IETF Internet Draft 8 Expires: May, 2003 9 October 2002 11 OSPF Traffic Engineering capability TLVs 13 draft-vasseur-mpls-ospf-te-cap-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are 19 Working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This draft proposes OSPF traffic engineering capability TLVs. Two 36 capability TLVs are defined in the current draft: the Path 37 Computation Server Discovery (PCSD) TLV that allows a router to 38 announce its Path Computation Server capability to other LSRs within 39 an OSPF area or a routing domain and the Mesh-group TLV used by an 40 LSR to indicate its desire to participate to a mesh of Traffic 41 Engineering Label Switched Path (this mesh of TE LSPs is identified 42 by a mesh-group number). They are both used in the context of MPLS 43 Traffic Engineering. Additional OSPF TE capability TLVs may be added 44 in further revision of this draft. Those OSPF TE capability TLVs 45 will be carried within the OSPF router information LSA (opaque type 46 of 4, opaque ID of 0) defined in [18]. 48 1. Where does this draft fit in the picture of the Sub-IP and OSPF WG ? 50 Vasseur and Psenak 1 52 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 54 This document specifies OSPF extensions in support of MPLS Traffic 55 Engineering. It will be discussed in the CCAMP Working Group with a 56 review of the OSPF Working Group. 58 2. Terminology 60 Terminology used in this draft 62 LSR: Label Switch Router 64 PCS: Path Computation Server (may be an LSR (ABR, ASBR, ...) or a 65 dedicated path computation server (typically a UNIX machine) not 66 forwarding packet. 68 PCC: Path Computation Client (any head-end LSR) requesting a path 69 computation to the Path Computation Server. 71 TE LSP: Traffic Engineering Label Switched Path 73 Head-end TE LSP: head/source of the TE LSP 75 Tail-end TE LSP: tail/destination of the TE LSP 77 Intra-area TE LSP: TE LSP whose head-end and tail-end reside in the 78 same area 80 Inter-area TE LSP: TE LSP whose head-end and tail-end reside in 81 different areas (the TE LSP spans areas) 83 Inter-AS TE LSP: TE LSP whose head-end and tail-end reside in 84 different Autonomous Systems (the TE LSP spans AS) 86 3. Introduction 88 This section describes the usage of the two OSPF capabilities TLV: 89 the Path Computation Server Discovery TLV and the Mesh-Group TLV. 90 Those OSPF TE capability TLVs will be carried within the OSPF router 91 information LSA (opaque type of 4, opaque ID of 0) defined in [18]. 93 3.1 Path Computation Server Discovery (PCSD) TLV 95 This draft specifies a new OSPF TE capability TLV called the PCSD 96 TLV for the Auto-discovery of one or more Path Computation 97 Server(s). In various situations (GMPLS, inter-area TE, ...), an LSR 98 may send a request to a Path Computation Server (PCS) to compute one 99 or more Traffic Engineering LSP paths obeying a set of specified 100 constraints. 102 Vasseur et Psenak 2 104 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 106 [4] specifies RSVP extensions: 107 - for a PCC to send path computation requests to a PCS to 108 compute TE LSP(s) obeying a set of specified constraints, 109 - for the PCS to provide to the PCC one or more computed paths 110 obeying the set of constraints (or to return an indication 111 mentioning no path obeying the constraints could be found). 113 The scope of this document is to define a new OSPF TE capability TLV 114 carried within an OSPF router information LSA such that a 115 LSR/centralized path computation tool may announce its capability to 116 be a Path Computation Server within an area or an Autonomous System. 117 This allows every LSR in the network to automatically discover the 118 Path Computation Server(s), which substantially simplifies head-end 119 LSRs configuration. Moreover, this allows to detect dynamically any 120 new PCS or that a PCS is no longer active. 122 3.2 Mesh-group TLV 124 As of today, there are different approaches in deploying MPLS 125 Traffic Engineering: 126 (1) the systematic approach consisting of setting up a full 127 mesh of tunnels between P or PE routers, with the objective of 128 optimizing the bandwidth usage in the core, 129 (2) the "by exception" approach where a set TE LSPs are set up 130 on hot spots to alleviate a congestion resulting in an 131 unexpected traffic growth in some part of the network. 133 The systematic approach requires setting up a full mesh of TE LSPs, 134 which implies the configuration of a large number of tunnels on 135 every Hean-End LSR (P or PE LSR). A full TE mesh of n LSRs requires 136 the set up of O(n^2) TE LSPs. Furthermore, the addition of any new 137 LSR in the mesh implies to configure n TE LSPs on the new LSR and to 138 add a new TE LSP on every LSR ending to this new LSR, which gives a 139 total of 2*n TE LSPs. This is not only time consuming but also not a 140 low risk operation for Service Providers. So a more automatic way of 141 setting up full mesh of TE LSP might be desirable. This requires to 142 define a new TE capability TLV (called the Mesh-group TLV) such that 143 an LSR can announce its desire to join a particular TE LSP mesh, 144 identified by a mesh-group number. 146 4. PCSD and Mesh-group TLV formats 148 This section defines the PCSD and the Mesh-group TLV formats carried 149 in an OSFP router information LSA as defined in [18]. 151 The PCSD and the Mesh-group TLV have the following format: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 Vasseur et Psenak 3 158 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 160 | Type | length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 // Value // 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Where 168 Type: identifies the TLV type 169 Length: length of the value field in octets 171 The format of the TLV is the same as the TLV format used by the 172 Traffic Engineering Extensions to OSPF [5]. The TLV is padded to 173 four-octet alignment; padding is not included in the length field (so 174 a three octet value would have a length of three, but the total size 175 of the TLV would be eight octets). Nested TLVs are also 32-bit 176 aligned. Unrecognized types are ignored. All types between 32768 177 and 65535 are reserved for vendor-specific extensions. All other 178 undefined type codes are reserved for future assignment by IANA. 180 Note that a sub-TLV is similar to a TLV: TLV are carried within an 181 LSA as sub-TLVs are carried within TLVs. Each sub-TLV describes a 182 particular Path Computation Server capability. In the rest of this 183 document both terms will be used interchangeably. 185 The PCSD TLV type is 2. The PCSD TLV is made of a set of non ordered 186 TLVs each having the same format as described above. 188 The Mesh-group TLV type is 3. The Mesh-group TLV does not have any 189 sub-TLV currently defined. 191 4.1 PCSD sub-TLVs 193 This section defines the sub-TLVs carried within the PCSD TLV 194 payload. 196 The PCSD TLV is made of various non ordered TLVs defined bellow: 198 TLV type Length Name 199 1 4 Path computation server scope TLV 200 2 variable Path computation server address TLV 201 3 8 Path computation server capability TLV 202 4 8 AS-domain TLV 204 Any non recognized TLV must be silently ignored. 206 4.1.1 Path computation server scope TLV 208 Vasseur et Psenak 4 210 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 212 The path computation server scope TLV specifies the zone for which 213 the path computation server is capable of performing TE LSP path 214 computation. 216 The path computation server scope TLV type is 1, its length is 4, and 217 the value is a set of flags: 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 | 1 | 4 | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Reserved | Flags | |A|I|L| 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Path computation server scope TLV format 228 Flags: no flags are currently defined. 230 Scope 232 L (local scope). When set, this flag indicates that the PCS can 233 compute paths for the area the LSA is flooded into (i.e the PCS can 234 compute TE LSP path for intra-area TE LSPs). 236 I (inter-area scope). When set, the PCS can perform TE LSP path 237 computation for inter-area TE LSPs (i.e TE LSP whose destination IP 238 address belongs to another area of the head-end LSR) but within the 239 same AS. 241 A (multi-domain scope). When set, the PCS can perform path 242 computation for inter-domain TE LSP. In this case, the PCSD TLV must 243 contain one or more AS-domain TLV(s) each describing the domain for 244 which the PCS can compute TE LSPs paths having their destination 245 address in this domain. 247 Note that a PCS may set one or more flags. 249 See section 5 for a detailed description of the elements of 250 procedure. 252 4.1.2 Path Computation Server address TLV 254 The PCS address TLV specifies the IP address to be used to reach the 255 PCS described by this PCSD TLV. This address will typically be a 256 loop-back address, always reachable, provided the router is not 257 isolated. The Path Computation Server Address TLV is mandatory. 259 Vasseur et Psenak 5 261 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 263 The PCS address TLV type is 2, length is 8 octets for an IPv4 264 address and 20 octets for an IPv6 address, and the value is the PCS 265 IPv4 or IPv6 address. 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | 2 | variable (8 or 20) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | address-type | Reserved | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 // PCS IP address // 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Path Computation Server address TLV format 280 Address-type: 281 1 IPv4 282 2 IPv6 284 The Path Computation Server address TLV MUST appear exactly once in 285 the PCSD TLV originated by a router. The only exception is when the 286 PCS has both an IPv4 and IPv6 address; in this case, two path 287 computation server address TLVs might be inserted: one for the IPv4 288 address, one for the IPv6 address. 290 4.1.3 Path Computation Server capability TLV 292 The PCS capability TLV is used by the PCS to signal its path 293 computation server capabilities. This TLV is optional. 295 The PCS capability TLV type is 3 and the length is 8 octets. 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | 3 | 8 | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Reserved | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |P|M|D|E|G| Reserved | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 PCS capability TLV format 308 P bit 309 The notion of request priority allows a PCC to specify how urgent is 310 the request setting a flag in the REQUEST_ID object of the Path 311 computation request message. See [4] for more details. 313 Vasseur et Psenak 6 315 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 317 P=1: the PCS takes into account the ''request priority'' in its 318 scheduling of the various requests. 319 P=0: the PCS does not take the request priority into account 321 M bit 322 M=1: the PCS is capable of computing more than one paths obeying a 323 set of specified constraints, provided that they exist. 324 M=0: the PCS cannot compute more than one path obeying a set of 325 specified constraints. 327 D bit 328 The PCC may request the PCS to compute N diversely routed paths 329 obeying a set of specified constraints. 330 Such N paths may not exist of course depending on the current state 331 of the network. See [4] for more details. 332 D=1: the PCS is capable of computing diversely (link, node, SRLG) 333 routed paths. 334 D=0: the PCS is not capable of computing diversely routed paths. 335 The D bit is relevant if and only if the M bit has been set to 1. It 336 must be set to 0 if the M bit is set to 0. 338 E bit 339 The PCC may request the PCS the computation of a path obeying a set 340 of constraints one of those constraints being that one or more 341 specified network element object must not be traversed by the LSP (a 342 network element may be a link, an LSR or an Autonomous System). See 343 [4] for more details. 344 E=1: the PCS is capable of computing TE LSP paths excluding some 345 network elements. 346 E=0: the PCS is not capable of computing paths excluding network 347 elements. 349 G bit 350 As defined in [4], the PCC may send a request specifying the metric 351 to be used by the PCS when computing the shortest path during the 352 CSPF. 353 G=1: the PCS supports the computation of CSPF with various metrics 354 G=0: the PCS just computes the CSPF based on the TE metric 356 Note that for future capability, it may be desirable to introduce 357 new flags or may be new TLV to be carried in the PCSD capability TLV 358 if the capability needs more than just a single flag to be 359 described. 361 4.1.4 AS-domain TLV 363 When the PCS can perform path computation for inter-domain TE LSP, 364 the A bit of the path computation server scope TLV must be set. 365 Moreover, one or more TLVs MUST included within the PCSD TLV, each 366 TLV identifying an AS number. Each TLV will have the following form: 368 Vasseur et Psenak 7 370 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | 4 | 4 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | AS Number | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 AS-domain TLV format 381 The AS-domain TLV type is 4, length is 4 octets, and the value is the 382 AS number identifying the AS for which the PCS can compute inter- 383 domain TE LSP paths (TE LSP having their destination address in this 384 domain). When coded on two bytes (which is the current defined format 385 as the time of writing), the AS Number field must have its left two 386 bytes set to 0. 388 The set of AS-domain TLVs specifies a list of ASes (AS1, ... , ASn). 389 This means that the PCS can compute TE LSP path such that the 390 destination address of the TE LSP belong to this set of ASes. 392 4.2 Mesh-group TLV format 394 The mesh-group TLV has the following format: 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | 3 |Length: Variable (N*8 octets) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | mesh-group-number | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Tail-end address | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 // // 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Mesh-group TLV format 409 N is the number of mesh-groups. 411 For each Mesh-group announced by the LSR, the TLV contains: 412 - a mesh-group-number: identifies the mesh-group number, 413 - a Tail-end address: IP address to be used as a tail-end 414 address by other LSR belonging to the same mesh-group. 416 5. Elements of procedure 418 The PCSD and Mesh-group TLVs are carried within an OSPF router 419 information opaque LSA (opaque type of 4, opaque ID of 0) as defined 420 in [18]. 421 Vasseur et Psenak 8 423 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 425 A router must originate a new OSPF router information LSA whenever 426 the content of the PCSD or Mesh-group TLV changes or whenever 427 required by the regular OSPF procedure (LSA refresh (every 428 LSRefreshTime, ...)). 430 As defined in RFC2370, an opaque LSA has a flooding scope determined 431 by its LSA type: 432 - link-local (type 9), 433 - area-local (type 10) 434 - entire OSPF routing domain (type 11). In this case, the 435 flooding scope is equivalent to the Type 5 LSA flooding scope. 437 A router may generate multiple OSPF router information LSA with 438 different flooding scope. 440 The PCSD TLV may be carried within a type 10 or 11 router 441 information LSA depending on the path computation server scope. 443 - If the PCS can compute intra-area TE LSP, the L bit of the 444 path computation server scope sub-TLV of the PCSD TLV must be 445 set and the PCSD TLV must be generated within a Type 10 router 446 information LSA, 448 - If the PCS can compute inter-area TE LSP, the I bit of the 449 path computation server scope sub-TLV of the PCSD TLV must be 450 set. The PCSD TLV must be generated: 451 - within a Type 10 router information LSA if the PCS 452 can compute inter-area TE LSP path for the LSRs in the 453 area it is attached to (for instance the PCS is an ABR 454 computing inter-area TE LSP path for its attached 455 areas) 456 - within a Type 11 router information LSA is the PCS 457 can compute inter-area TE LSP path for the whole 458 domain. 460 - If the PCS can compute inter-AS TE LSP, the A bit of the path 461 computation server scope sub-TLV of the PCSD TLV must be set 462 and the PCSD TLV must be generated within a Type 11 router 463 information LSA, 465 The Mesh-group TLV may be carried within a type 10 or 11 router 466 information LSA depending on the MPLS TE mesh-group profile: 468 - If the MPLS TE mesh-group is contained with a single area 469 (all the LSR have their Head-End and Tail-End within the same 470 area), the Mesh-group TLV must be generated within a Type 10 471 router information LSA, 472 - If the MPLS TE mesh-group spans multiple OSPF areas, the 473 Mesh-group TLV must be generated within a Type 11 router 474 information LSA, 476 Vasseur et Psenak 9 478 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 480 Note: if the PCS can both compute intra and inter-area TE LSP paths, 481 both the L and I bits of the path computation server scope TLV must 482 be set. The flags are not exclusive. This only applies to the PCSD 483 TLV carried within the type 10 router information LSA. 485 If a PCS can compute intra-area TE LSP and inter-area or inter-AS TE 486 LSP path, it must originate: 487 - a type 10 OSPF router information LSA with a PCSD TLV having 488 L=1 and the I and A flags of its Path Computation Server scope 489 TLV set as described above , 490 - a type 11 OSPF router information LSA with a PCSD TLV having 491 L=0 and the I and A flags of its Path Computation Server scope 492 TLV set as described above, 494 Example 496 <-----------------AS1-----------------> 498 <---area 1--><----area 0-----><-area 2-> 500 R1---------ABR1*------------ABR3*-----| ------------ 501 | | | | | | 502 | S1 | S2 | ASBR1*--eBGP--ASBR2-| AS2 | 503 | | | | | | 504 R2---------ABR2*------------ABR4------| ------------ 506 The areas contents are not detailed. 508 Assumptions: 509 - area 1 and area 2 are regular areas 510 - the * indicates a Path computation server capability 511 - ABR1 is a PCS for area 1 only 512 - ABR2 is a PCS for intra and inter-area TE LSP path computation in 513 area 0 and 1 514 - ABR3 is a PCS for only inter-area TE LSP path computation for the 515 whole domain, 516 - S1 is a PCS for area 1 only 517 - S2 is a PCS for the whole domain, 518 - ASBR1 is a PCS for inter-AS TE LSP only whose destination resides 519 in AS2 (not for intra or inter-area area TE LSPs). 521 In the example above: 522 - S1 originates a type 10 router information LSA with a PCSD TLV 523 such that: 524 o The L bit of the path computation server scope TLV is set, 525 o The I and A bits of the path computation server scope TLV are 526 cleared. 528 - ABR1 originates in area 1 a type 10 router information LSA with a 529 PCSD TLV such that: 530 Vasseur et Psenak 10 532 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 534 o The L bit of the path computation server scope TLV is set, 535 o The I and A bits of the path computation server scope TLV are 536 cleared, 538 - ABR2 originates in both area 0 and 1 a type 10 router information 539 LSA with a PCSD TLV such that: 540 o The L and I bits of the path computation server scope TLV are 541 set, 542 o The A bit of the path computation server scope TLV is 543 cleared 545 - ABR3 originates a type 11 router information LSA with a PCSD TLV 546 such that: 547 o The L bit of the path computation server scope TLV is 548 cleared, 549 o The I bit of the path computation server scope TLV is set, 550 o The A bit of the path computation server scope TLV is 551 cleared, 553 - S2 originates: 554 - in area 0 a type 10 router information LSA with a PCSD TLV 555 such that: 556 o The L and I bits of the path computation server scope 557 TLV are set, 558 o The A bit of the path computation server scope TLV 559 is cleared, 560 - a type 11 router information LSA with a PCSD TLV such that: 561 o The L bit of the path computation server scope TLV is 562 cleared, 563 o The I bit of the path computation server scope TLV is 564 set, 565 o The A bit of the path computation server scope TLV 566 is cleared, 568 - ASBR1 originates a type 11 router information LSA with a PCSD TLV 569 such that: 570 o The L bit and the I bit of the path computation server scope 571 TLV are cleared, 572 o The A bit of the path computation server scope TLV set, 573 o One AS-domain TLV within the PCSD TLV with AS number = AS2 575 The receipt of a new router information LSA carrying a PCSD TLV 576 never triggers an SPF calculation. 578 When an LSR or a dedicated path computation server is newly 579 configured as a PCS, the corresponding router information LSA must 580 be immediately flooded. 582 When a PCS capability changes, the corresponding router information 583 LSA must be immediately flooded. 585 Vasseur et Psenak 11 587 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 589 When an LSR or a dedicated path computation server looses its path 590 computation server capability, the corresponding router information 591 LSA must be immediately flooded with LS age = MaxAge. 593 5. Interoperability with routers non supporting this capability 595 There is no interoperability issue as a router non-supporting the 596 PCSD and Mesh-Group TLVs should just silently discard those TLVs as 597 specified in RFC2370. 599 6. Security Considerations 601 No new security issues are raised in this document. 603 7. Acknowledgments 605 The authors would like to thank Abhay Roy, Dan Tappan, Robert Raszuk 606 and Vishwas Manral for their comments. 608 8. References 610 [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 612 [2] Awduche, D., et al, "Requirements for Traffic Engineering Over 613 MPLS," RFC 2702, September 1999. 615 [3] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998. 617 [4] Vasseur et al, "RSVP Path computation request and reply 618 messages ", draft-vasseur-mpls-computation-rsvp-te-03.txt, work in 619 progress. 621 [5] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", 622 draft-katz-yeung-ospf-traffic-04.txt 624 [6] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering," 625 draft-ietf-isis-traffic-03.txt, work in progress. 627 [7] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE", 628 Internet Draft, draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001. 630 [8] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in RSVP- 631 TE", Internet Draft, draft-ietf-mpls-rsvp-unnum-01.txt, February 2001 633 [9] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 634 Extensions in Support of Generalized MPLS", draft-ietf-ccamp- 635 ospf-gmpls-extensions-06.txt (work in progress) 637 Vasseur et Psenak 12 639 Internet draft draft-vasseur-mpls-ospf-te-cap-00.txt October 2002 641 [10] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - CR-LDP 642 Extensions", Internet Draft, draft-ietf-mpls-generalized-cr-ldp- 643 01.txt, February 2001. 645 [11] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling 646 Functional Description", Internet Draft, draft-ietf-mpls-generalized- 647 signaling-02.txt, 648 February 2001. 650 [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement 651 Levels," RFC 2119. 653 [13] Braden, R. Ed. et al, "Resource ReserVation Protocol-- Version 1 654 Functional Specification", RFC 2205, September 1997. 656 [14] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 657 RFC 3209, December 2001. 659 [15] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini S., 660 "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. 662 [16] Le faucheur, "Use of IGP Metric as a second TE Metric", 663 Internet draft, draft-lefaucheur-te-metric-igp-00.txt. 665 [17] Fedyk D., Ghanwani A., Ash J., Vedrenne A. "Multiple Metrics 666 for Traffic Engineering with IS-IS and OSPF", Internet draft, 667 draft-fedyk-isis-ospf-te-metrics-01.txt 669 [18] Aggarwal et all, ''Extensions to IS-IS and OSPF for Advertising 670 Optional Router Capabilities'', Internet draft, draft-raggarwa-igp- 671 cap-01.txt, October 2002. 673 9. Author's Addresses 675 JP Vasseur 676 CISCO Systems, Inc. 677 300 Apollo Drive 678 Chelmsford, 01824 679 Email: jpv@cisco.com 681 Peter Psenak 682 CISCO Systems, Inc. 683 Pegasus Parc 684 De Kleetlaan 6A 685 1831, Diegem 686 BELGIUM 687 Email: ppsenak@cisco.com 689 Vasseur et Psenak 13