idnits 2.17.1 draft-kompella-mpls-bundle-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 116: '...chanisms is used SHOULD be configurabl...' RFC 2119 keyword, line 157: '... bundled links) MUST be unique in the...' RFC 2119 keyword, line 206: '...mpatibility, one MAY advertise the Max...' RFC 2119 keyword, line 286: '...are down, the bundled link MUST not be...' RFC 2119 keyword, line 377: '... class, per [RSVP], it SHOULD send an error message with an "Unknown...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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: If one of the component links goes down, the associated bundled link remains up and continues to be advertised, provided that at least one component link associated with the bundled link is up. The unreserved bandwidth of the component link that is down is set to zero, and the unreserved bandwidth and maximum LSP bandwidth of the bundle must be recomputed. If all the component links associated with a given bundled link are down, the bundled link MUST not be advertised into OSPF/IS-IS. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RSVP-TE' is defined on line 464, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-02) exists of draft-kompella-ospf-gmpls-extensions-01 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-OSPF' -- No information found for draft-ietf-generalized-mpls-signalling - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-SIG' == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS') ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- Possible downref: Normative reference to a draft: ref. 'LMP' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-01 == Outdated reference: A later version (-01) exists of draft-ietf-ospf-ppp-flood-00 -- Possible downref: Normative reference to a draft: ref. 'MOY' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-04 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-crldp-unnum-01 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-01 == Outdated reference: A later version (-01) exists of draft-ietf-ospf-isis-flood-opt-00 -- Possible downref: Normative reference to a draft: ref. 'ZININ' Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kireeti Kompella 2 Internet Draft Juniper Networks 3 Expiration Date: August 2001 Yakov Rekhter 4 Juniper Networks 5 Lou Berger 6 Movaz Networks 8 Link Bundling in MPLS Traffic Engineering 10 draft-kompella-mpls-bundle-05.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 In some cases a pair of Label Switching Routers (LSRs) may be 36 connected by several (parallel) links. From the MPLS Traffic 37 Engineering point of view for reasons of scalability it may be 38 desirable to advertise all these links as a single link into OSPF 39 and/or IS-IS. This document describes a mechanism to accomplish 40 this. This document also defines corresponding signaling (RSVP-TE 41 and CR-LDP) support. 43 3. Link Bundling 45 When a pair of LSRs are connected by multiple links, then for the 46 purpose of MPLS Traffic Engineering it is possible to advertise 47 several (or all) of these links as a single link into OSPF and/or IS- 48 IS. We refer to this process as "link bundling", or just "bundling". 49 We refer to the link that is advertised into OSPF/IS-IS as a "bundled 50 link". We refer to the links associated with that bundled link as 51 "component links". 53 The purpose of link bundling is to improve routing scalability by 54 reducing the amount of information that has to be handled by OSPF 55 and/or IS-IS. This reduction is accomplished by performing 56 information aggregation/abstraction. As with any other information 57 aggregation/abstraction, this results in losing some of the 58 information. To limit the amount of losses one need to restrict the 59 type of the information that can be aggregated/abstracted. 61 3.1. Restrictions on Bundling 63 All component links in a bundle must begin and end on the same pair 64 of LSRs, have the same Link Type (i.e., point-to-point or multi- 65 access), the same Traffic Engineering metric, the same set of 66 resource classes, and the same Link Multiplex Capability (see [LSP- 67 HIER]). A Forwarding Adjacency may be a component link; in fact, a 68 bundle can consist of a mix of point-to-point links and FAs. 70 If the component links are all multi-access links, the set of IS-IS 71 or OSPF routers connected to each component link must be the same, 72 and the Designated Router for each component link must be the same. 73 If these conditions cannot be enforced, multi-access links must not 74 be bundled. 76 3.2. Routing Considerations 78 A bundled link is just another kind of Traffic Engineering (TE) link 79 (see [GMPLS-ISIS] and [GMPLS-OSPF]). The "liveness" of the bundled 80 link is determined by the liveness of each of the component links 81 within the bundled link. The liveness of a component link can be 82 determined by any of several means: IS-IS or OSPF hellos over the 83 component link, or RSVP Hello, or LMP hellos (see [LMP]), or from 84 layer 1 or layer 2 indications. 86 Once a bundled link is determined to be alive, it can be advertised 87 as a TE link and the TE information can be flooded. If IS-IS/OSPF 88 hellos are run over the component links, IS-IS/OSPF flooding can be 89 restricted to just one of the component links [ZININ] [MOY]. 91 Note that advertising a (bundled) TE link between a pair of LSRs 92 doesn't imply that there is an IGP adjacency between these LSRs that 93 is associated with just that link. In fact, in certain cases a TE 94 link between a pair of LSRs could be advertised even if there is no 95 IGP adjacency at all between the LSR (e.g., when the TE link is an 96 FA). 98 In the future, as new Traffic Engineering parameters are added to IS- 99 IS and OSPF, they should be accompanied by descriptions as to how 100 they can be bundled, and possible restrictions on bundling. 102 3.3. Signaling Considerations 104 Typically, an LSP's ERO will choose the bundled link to be used for 105 the LSP, but not the component link(s), since information about the 106 bundled link is flooded, but information about the component links is 107 kept local to the LSR. If the ERO chooses the component links by 108 means outside the scope of this document, neither this section nor 109 section 5.2 applies. Otherwise, the choice of the component link(s) 110 for the LSP is a local matter between the two LSRs at each end of the 111 bundled link. 113 The choice of the component link to use is always made by the sender 114 of the Path/REQUEST message. Three mechanisms for indicating this 115 choice to the receiver of the Path/REQUEST message are discussed 116 below; which of these mechanisms is used SHOULD be configurable by 117 the user, preferably on a per-bundle basis. 119 3.3.1. Mechanism 1: Implicit Indication 121 This mechanism requires that each component link has a dedicated 122 signaling channel (for example, the link is packet-switch capable; or 123 the link is a SONET link with an in-band channel for signaling). The 124 sender of the Path/REQUEST message tells the receiver which component 125 link to use by sending the message over the chosen component link's 126 dedicated signaling channel. 128 3.3.2. Mechanism 2: Explicit Indication by IP Address 130 This mechanism requires that each component link has a unique remote 131 IP address. The sender can either send the Path/REQUEST message 132 addressed to the remote IP address for the component link or 133 encapsulate the message in an IP header whose destination address is 134 the remote IP address. This mechanism does not require each 135 component link to have its own control channel. In fact, it doesn't 136 even require the whole (bundled) link to have its own control 137 channel. 139 3.3.3. Mechanism 3: Explicit Indication by Component Interface ID 141 This mechanism requires that each component link is assigned a unique 142 Interface Identifier per [UNNUM-RSVP] or [UNNUM-CRLDP] and that the 143 assigned identifiers be exchanged by the two LSRs at each end of the 144 bundled link. This identifier is referred to as "component interface 145 identifier". The choice of the component link is indicated by the 146 sender of the Path/REQUEST message by including the component link's 147 interface identifier in the message, as described in section 5.2. 149 3.4. Unnumbered Bundled Links 151 Note that a bundled link may itself be numbered or unnumbered 152 independent of whether the component links are numbered or not. This 153 affects how the bundled link is advertised in IS-IS/OSPF, and the 154 format of LSP EROs that traverse the bundled link. Furthermore, 155 unnumbered Interface Identifiers for all unnumbered outgoing links of 156 a given LSR (whether component links, Forwarding Adjacencies or 157 bundled links) MUST be unique in the context of that LSR. 159 4. Traffic Engineering Parameters for Bundled Links 161 In this section, we define the Traffic Engineering parameters to be 162 advertised for a bundled link, based on the configuration of the 163 component links and of the bundled link. The definition of these 164 parameters for component links was undertaken in [ISIS] and [OSPF]; 165 we use the terminology from [OSPF]. 167 4.1. OSPF Link Type 169 The Link Type of a bundled link is the (unique) Link Type of the 170 component links. (Note: this parameter is not present in IS-IS.) 172 4.2. OSPF Link ID 174 For point-to-point links, the Link ID of a bundled link is the 175 (unique) Router ID of the neighbor. For multi-access links, this is 176 the interface address of the (unique) Designated Router. (Note: this 177 parameter is not present in IS-IS.) 179 4.3. Local and Remote Interface IP Address 181 (Note: in IS-IS, these are known as IPv4 Interface Address and IPv4 182 Neighbor Address, respectively.) 184 If the bundled link is numbered, the Local Interface IP Address is 185 the local address of the bundled link; similarly, the Remote 186 Interface IP Address is the remote address of the bundled link. 188 4.4. Outgoing and Incoming Interface Identifiers 190 If the bundled link is unnumbered, the Outgoing Interface Identifier 191 is set to the outgoing interface identifier chosen for the bundle by 192 the advertising LSR. The Incoming Interface Identifier is set to the 193 outgoing interface identifier chosen by the neighboring LSR for the 194 reverse link corresponding to this bundle, if known; otherwise, this 195 is set to 0. 197 4.5. Traffic Engineering Metric 199 The Traffic Engineering Metric for a bundled link is that of the 200 component links. 202 4.6. Maximum Link Bandwidth 204 This TLV is not used. The maximum LSP Bandwidth (as described below) 205 replaces the maximum link bandwidth for bundled links. For backward 206 compatibility, one MAY advertise the Maximum LSP Bandwidth at 207 priority 7 of the bundle as the Maximum Link Bandwidth. 209 4.7. Maximum Reservable Bandwidth 211 We assume that for a given bundled link either each of its component 212 links is configured with the maximum reservable bandwidth, or the 213 bundled link is configured with the maximum reservable bandwidth. In 214 the former case, the Maximum Reservable Bandwidth of the bundled link 215 is set to the sum of the maximum reservable bandwidths of all 216 component links associated with the bundled link. 218 4.8. Unreserved Bandwidth 220 The unreserved bandwidth of a bundled link at priority p is the sum 221 of the unreserved bandwidths at priority p of all the component links 222 associated with the bundled link. 224 4.9. Resource Classes (Administrative Groups) 226 The Resource Classes for a bundled link are the same as those of the 227 component links. 229 4.10. Maximum LSP Bandwidth 231 The Maximum LSP Bandwidth takes the place of the Maximum Link 232 Bandwidth. However, while Maximum Link Bandwidth is a single fixed 233 value (usually simply the link capacity), Maximum LSP Bandwidth is 234 carried per priority, and may vary as LSPs are set up and torn down. 236 The Maximum LSP Bandwidth of a bundled link at priority p is defined 237 to be the maximum of the Maximum LSP Bandwidth at priority p of each 238 component link. 240 If a component link is a simple (unbundled) link, define its Maximum 241 LSP Bandwidth at priority p to be the smaller of its unreserved 242 bandwidth at priority p and its maximum link bandwidth. 244 Since bundling may be applied recursively, a component link may 245 itself be a bundled link. In this case, its Maximum LSP Bandwidth as 246 a component link is the same as its Maximum LSP Bandwidth as a 247 bundled link. 249 The details of how Maximum LSP Bandwidth is carried in IS-IS is given 250 in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried 251 in OSPF is given in [GMPLS-OSPF]. 253 5. Procedures 255 5.1. Bandwidth Accounting 257 The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an 258 LSR with bundled links must apply admission control on a per- 259 component link basis. An LSP with a bandwidth requirement b and 260 setup priority p fits in a bundled link if at least one component 261 link has maximum LSP bandwidth >= b at priority p. If there are 262 several such links, the choice of which link is used for the LSP is 263 up to the implementation. 265 In order to know the maximum LSP bandwidth (per priority) of each 266 component link, the Traffic Control module must track the unreserved 267 bandwidth (per priority) for each component link. This is done as 268 follows. If an LSP with bandwidth b and holding priority p is set up 269 through a component link, that component link's unreserved bandwidth 270 at priority p and lower is reduced by b. If an LSP with bandwidth b 271 and holding priority p that is currently set up through a component 272 link is torn down, the unreserved bandwidth at priority p and lower 273 for that component link is increased by b. 275 A change in the unreserved bandwidth of a component link results in a 276 change in the unreserved bandwidth of the bundled link. It also 277 potentially results in a change in the maximum LSP bandwidth of the 278 bundle; thus, the maximum LSP bandwidth should be recomputed. 280 If one of the component links goes down, the associated bundled link 281 remains up and continues to be advertised, provided that at least one 282 component link associated with the bundled link is up. The 283 unreserved bandwidth of the component link that is down is set to 284 zero, and the unreserved bandwidth and maximum LSP bandwidth of the 285 bundle must be recomputed. If all the component links associated 286 with a given bundled link are down, the bundled link MUST not be 287 advertised into OSPF/IS-IS. 289 5.2. Signaling 291 Signaling must identify both the component link to use and the label 292 to use. The sender of the Path/REQUEST message always chooses the 293 component link(s) to be used for the LSP (if the LSP is bidirectional 294 [GMPLS-SIG], the sender chooses a component link in each direction). 296 For unidirectional LSPs and the forward direction of a bidirectional 297 LSP, the sender of a MAPPING/Resv message chooses the label (if 298 needed). For the reverse direction of a bidirectional LSP, the 299 sender of the Path/REQUEST message selects the upstream label (if 300 needed). 302 As mentioned above, there are three methods for communicating the 303 selected component link, implicit indication and explicit indication 304 by IP address and by component interface identifier. The first two 305 are described in sections 3.3.1 and 3.3.2. In this section, we 306 define the objects needed to indicate the component link by component 307 interface identifier. 309 In explicit indication by component interface identifier, the sender 310 of the Path (REQUEST) message communicates the selected component 311 link via the COMPONENT_INTERFACE_ID object class (Component Interface 312 ID TLV) defined below. Doing this assumes that an LSR connected to a 313 component link knows the component interface identifier assigned to 314 that link by the LSR at the other end of the link. Exchanging the 315 identity of a component link between the LSRs connected by that link 316 may be accomplished by configuration, by means of a protocol such as 317 [LMP], by means of RSVP/CR-LDP (especially in the case where a 318 component link is a Forwarding Adjacency), or by means of IS-IS or 319 OSPF extensions. 321 In both RSVP and CR-LDP, if a Component Interface Identifier has the 322 special value of 0xFFFFFFFF, this means that the same label is to be 323 valid across all component links. 325 5.2.1. RSVP-TE COMPONENT_INTERFACE_ID Object Class 327 A new object class, the COMPONENT_INTERFACE_ID object class, is 328 defined. The Length field is set to 8. The Class Num (TBD) is of 329 the form 0bbbbbbb. The DOWNSTREAM_COMPONENT_INTERFACE_ID object, 330 which has a C_Type of 1, is used to indicate the component interface 331 to be used for traffic flowing in the downstream direction. The 332 UPSTREAM_COMPONENT_INTERFACE_ID object, which has a C_Type of 2, is 333 used to indicate the component interface to be used for traffic 334 flowing in the upstream direction. Both objects have the same format 335 and carry a 32-bit Component Interface Identifier. The format of the 336 objects are: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Length |Class Num (TBD)| C_Type (1|2) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Component Interface Identifier | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 5.2.2. COMPONENT_INTERFACE_ID Object Class Usage 348 The COMPONENT_INTERFACE_ID objects are carried in RSVP messages as 349 part of the sender descriptor. They are optional with respect to the 350 protocol, and are only used when component links are being identified 351 using the COMPONENT_INTERFACE_ID objects. There are two formats for 352 the sender descriptor, one for traditional LSPs and one for 353 bidirectional LSPs. 355 The format of the sender descriptor for unidirectional LSPs is: 357 ::= 358 [ ] 359 [ ] 360 361 [ ] 363 The format of the sender descriptor for bidirectional LSPs is: 365 ::= 366 [ ] 367 [ ] 368 369 [ ] 370 371 373 We introduce a new error value for the error code "Routing problem", 374 namely "Unknown Component Interface ID" with error value 11. 376 If the receiver doesn't recognize the COMPONENT_INTERFACE_ID object 377 class, per [RSVP], it SHOULD send an error message with an "Unknown 378 Object Class". If the class is recognized but the C-Type is not, per 379 [RSVP], the receiver SHOULD send an "Unknown Object C-Type" error. A 380 node that recognizes either COMPONENT_INTERFACE_ID objects, but that 381 is unable to support it (possibly because of a failure to allocate 382 labels) SHOULD send an error message with the error code "Routing 383 problem" and the error value "MPLS label allocation failure." If LMP 384 or some other link identification protocol is not running, or there 385 is no component link with the Component Interface Identifier in 386 either object, the receiver SHOULD send an error message with the 387 error code "Routing problem" and the error value "Unknown Component 388 Interface ID". 390 5.2.3. CR-LDP Component Interface ID TLVs 392 Two new TLVs are introduced to support bundling in CR-LDP. Both TLVs 393 are carried in LDP REQUEST messages. The TLVs share a common format 394 and differ in the direction of the component link being identified. 395 The Downstream Component Interface ID TLV, which has a Type value to 396 be determined by IETF consensus, is used to indicate the component 397 interface to be used for traffic flowing in the downstream direction. 398 The Upstream Component Interface ID TLV, which has a Type value to be 399 determined by IETF consensus, is used to indicate the component 400 interface to be used for traffic flowing in the upstream direction. 401 Both TLVs have the same format and carry a 32-bit Component Interface 402 Identifier. The format of the TLVs are: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |U|F| Type = (TBD | TBD) | Length (8) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Component Interface Identifier | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 We introduce a new status code "Unknown Component Interface ID" with 413 value 0x1A. 415 If the receiver doesn't recognize either Component Interface ID TLV 416 class, per [LDP], it SHOULD send a Notification message with an "Unknown 417 TLV" Status Code. A node that recognizes either Component Interface ID 418 TLV, but that is unable to support it (possibly because of a failure to 419 allocate labels) SHOULD send a Notification message with a "No Label 420 Resources" Status Code. If LMP or some other link identification 421 protocol is not running, or there is no component link with the 422 Component Interface Identifier in either TLV, the receiver SHOULD send a 423 Notification message with an "Unknown Component Interface ID" Status 424 Code. 426 6. Security Considerations 428 This document raises no new security issues for RSVP or CR-LDP. 430 7. References 432 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 433 Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- 434 extensions-02.txt (work in progress) 436 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 437 Extensions in Support of Generalized MPLS", draft-kompella-ospf- 438 gmpls-extensions-01.txt (work in progress) 440 [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling 441 Functional Description", draft-ietf-generalized-mpls- 442 signalling-02.txt 444 [ISIS] Smit, H., Li, T., "IS-IS extensions for Traffic Engineering", 445 draft-ietf-isis-traffic-02.txt (work in progress) 447 [LDP] Andersson, L. et al, "LDP Specification", RFC 3036, January 448 2001. 450 [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", 451 draft-ietf-mpls-lmp-02.txt (work in progress) 453 [LSP-HIER] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", 454 draft-ietf-mpls-lsp-hierarchy-01.txt (work in progress) 456 [MOY] Moy, J., draft-ietf-ospf-ppp-flood-00.txt (work in progress) 458 [OSPF] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", 459 draft-katz-yeung-ospf-traffic-04.txt (work in progress) 461 [RSVP] Braden, Ed., et. al., "Resource ReSerVation Protocol (RSVP) -- 462 Version 1 Functional Specification", RFC2205, September 1997. 464 [RSVP-TE] Awduche, D., Berger, L., Gan, D., et al, "Extensions to 465 RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-08.txt (work 466 in progress) 468 [UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling 469 Unnumbered Links in CR-LDP", draft-ietf-mpls-crldp-unnum-01.txt (work 470 in progress) 472 [UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 473 in RSVP-TE", draft-ietf-mpls-rsvp-unnum-01.txt (work in progress) 475 [ZININ] Zinin, A., Shand, M., "Flooding optimizations in link-state 476 routing protocols", draft-ietf-ospf-isis-flood-opt-00.txt (work in 477 progress) 479 8. Author Information 481 Kireeti Kompella 482 Juniper Networks, Inc. 483 1194 N. Mathilda Ave. 484 Sunnyvale, CA 94089 485 Email: kireeti@juniper.net 487 Yakov Rekhter 488 Juniper Networks, Inc. 489 1194 N. Mathilda Ave. 490 Sunnyvale, CA 94089 491 Email: yakov@juniper.net 493 Lou Berger 494 Movaz Networks, Inc. 495 Voice: +1 301 468 9228 496 Email: lberger@movaz.com