idnits 2.17.1 draft-ietf-mpls-lsp-hierarchy-08.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 == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 61 lines 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) == Missing Reference: 'RSVP-TE' is mentioned on line 90, but not defined == Missing Reference: 'CR-LDP' is mentioned on line 90, but not defined == Missing Reference: '1-4' is mentioned on line 355, but not defined == Unused Reference: 'GRSVP-TE' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'GSIG' is defined on line 506, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GCR-LDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-ISIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-OSPF' -- Possible downref: Non-RFC (?) normative reference: ref. 'GRSVP-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS-TE' ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNNUM-CRLDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNNUM-RSVP' == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-02 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kireeti Kompella 3 Internet Draft Juniper Networks 4 Expiration Date: March 2002 Yakov Rekhter 5 Juniper Networks 7 LSP Hierarchy with Generalized MPLS TE 9 draft-ietf-mpls-lsp-hierarchy-08.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 To improve scalability of Generalized Multi-Protocol Label Switching 35 (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by 36 creating a hierarchy of such LSPs. A way to create such a hierarchy 37 is by (a) a Label Switching Router (LSR) creating a Traffic 38 Engineering Label Switched Path (TE LSP), (b) the LSR forming a 39 forwarding adjacency (FA) out of that LSP (by advertising this LSP as 40 a Traffic Engineering (TE) link into the same instance of ISIS/OSPF 41 as the one that was used to create the LSP), (c) allowing other LSRs 42 to use FAs for their path computation, and (d) nesting of LSPs 43 originated by other LSRs into that LSP (by using the label stack 44 construct). 46 This document describes the mechanisms to accomplish this. 48 3. Specification of Requirements 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 4. Overview 56 An LSR uses Generalized MPLS (GMPLS) TE procedures to create and 57 maintain an LSP. The LSR then may (under local configuration control) 58 announce this LSP as a Traffic Engineering (TE) link into the same 59 instance of the GMPLS control plane (or more precisely its ISIS/OSPF 60 component) as the one that was used to create the LSP. We call such 61 a link a "forwarding adjacency" (FA). We refer to the LSP as the 62 "forwarding adjacency LSP", or just FA-LSP. Note that an FA-LSP is 63 both created and used as a TE link by exactly the same instance of 64 the GMPLS control plane. Thus the concept of an FA is applicable only 65 when an LSP is both created and used as a TE link by exactly the same 66 instance of the GMPLS control plane. Note also that an FA is a TE 67 link between two GMPLS nodes whose path transits zero or more (G)MPLS 68 nodes in the same instance of the GMPLS control plane. 70 The nodes connected by a 'basic' TE link may have a routing 71 adjacency; however, the nodes connected by an FA would not usually 72 have a routing adjacency. A TE link of any kind (either 'basic' or 73 FA) would have to have a signaling adjacency in order for it to be 74 used to establish an LSP across it. 76 In general, the creation/termination of an FA and its FA-LSP could be 77 driven either by mechanisms outside of GMPLS (e.g., via configuration 78 control on the LSR at the head-end of the adjacency), or by 79 mechanisms within GMPLS (e.g., as a result of the LSR at the head-end 80 of the adjacency receiving LSP setup requests originated by some 81 other LSRs). 83 ISIS/OSPF floods the information about FAs just as it floods the 84 information about any other links. As a result of this flooding, an 85 LSR has in its TE link state database the information about not just 86 basic TE links, but FAs as well. 88 An LSR, when performing path computation, uses not just basic TE 89 links, but FAs as well. Once a path is computed, the LSR uses 90 RSVP/CR-LDP [RSVP-TE, CR-LDP] for establishing label binding along 91 the path. 93 In this document we define mechanisms/procedures to accomplish the 94 above. These mechanisms/procedures cover both the routing 95 (ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects. 97 Note that an LSP may be advertised as a point-to-point link into ISIS 98 or OSPF, to be used in normal SPF by nodes other than the head end. 99 While this is similar in spirit to an FA, this is beyond the scope of 100 this document. 102 Scenarios where an LSP is created (and maintained) by one instance of 103 the GMPLS control plane, and is used as a (TE) link by another 104 instance of the GMPLS control plane are outside the scope of this 105 document. 107 5. Routing aspects 109 In this section we describe procedures for constructing FAs out of 110 LSPs, and handling of FAs by ISIS/OSPF. Specifically, this section 111 describes how to construct the information needed to advertise LSPs 112 as links into ISIS/OSPF. Procedures for creation/termination of such 113 LSPs are defined in Section "Controlling FA-LSPs boundaries". 115 FAs may be represented as either unnumbered or numbered links. If FAs 116 are numbered with IPv4 addresses, the local and remote IPv4 addresses 117 come out of a /31 that is allocated by the LSR that originates the 118 FA-LSP; the head-end address of the FA-LSP is the one specified as 119 the IPv4 tunnel sender address; the remote (tail-end) address can 120 then be inferred. If the LSP is bidirectional, the tail-end can thus 121 know the addresses to assign to the reverse FA. 123 If there are multiple LSPs that all originate on one LSR and all 124 terminate on another LSR, then at one end of the spectrum all these 125 LSPs could be merged (under control of the head-end LSR) into a 126 single FA using the concept of Link Bundling (see [BUNDLE]), while at 127 the other end of the spectrum each such LSP could be advertised as 128 its own adjacency. 130 When an FA is created under administrative control (static 131 provisioning), the attributes of the FA-LSP have to be provided via 132 configuration. Specifically, the following attributes may be 133 configured for the FA-LSP: the head-end address (if left 134 unconfigured, this defaults to the head-end LSR's Router ID); the 135 tail-end address; bandwidth and resource colors constraints. The 136 path taken by the FA-LSP may be either computed by the LSR at the 137 head-end of the FA-LSP, or specified by explicit configuration; this 138 choice is determined by configuration. 140 When an FA is created dynamically, the attributes of its FA-LSP are 141 inherited from the LSP which induced its creation. Note that the 142 bandwidth of the FA-LSP must be at least as big as the LSP that 143 induced it, but may be bigger if only discrete bandwidths are 144 available for the FA-LSP. In general, for dynamically provisioned 145 FAs, a policy-based mechanism may be needed to associate attributes 146 to the FA-LSPs. 148 5.1. Traffic Engineering parameters 150 In this section, the Traffic Engineering parameters (see [OSPF-TE] 151 and [ISIS-TE]) for FAs are described. 153 5.1.1. Link type (OSPF only) 155 The Link Type of an FA is set to "point-to-point". 157 5.1.2. Link ID (OSPF only) 159 The Link ID is set to the Router ID of the tail end of FA-LSP. 161 5.1.3. Local and remote interface IP address 163 If the FA is to be numbered, the local interface IP address (OSPF) or 164 IPv4 interface address (ISIS) is set to the head-end address of the 165 FA-LSP. The remote interface IP address (OSPF) or IPv4 neighbor 166 address (ISIS) is set to the tail-end address of the FA-LSP. 168 5.1.4. Local and Remote Link Identifiers 170 For an unnumbered FA the assignment and handling of the local and 171 remote link identifiers is specified in [UNNUM-RSVP], [UNNUM-CRLDP]. 173 5.1.5. Traffic Engineering metric 175 By default the TE metric on the FA is set to max(1, (the TE metric of 176 the FA-LSP path) - 1) so that it attracts traffic in preference to 177 setting up a new LSP. This may be overridden via configuration at 178 the head-end of the FA. 180 5.1.6. Maximum bandwidth 182 By default the Maximum Reservable Bandwidth and the initial Maximum 183 LSP Bandwidth for all priorities of the FA is set to the bandwidth of 184 the FA-LSP. These may be overridden via configuration at the head- 185 end of the FA (note that the Maximum LSP Bandwidth at any one 186 priority should be no more than the bandwidth of the FA-LSP). 188 5.1.7. Unreserved bandwidth 190 The initial unreserved bandwidth for all priority levels of the FA is 191 set to the bandwidth of the FA-LSP. 193 5.1.8. Resource class/color 195 By default, a FA does not have resource colors (administrative 196 groups). This may be overridden by configuration at the head-end of 197 the FA. 199 5.1.9. Interface Switching Capability 201 The (near end) Interface Switching Capability associated with the FA 202 is the (near end) Interface Switching Capability of the first link in 203 the FA-LSP. 205 When the (near end) Interface Switching Capability field is PSC-1, 206 PSC-2, PSC-3, or PSC-4, the specific information includes Interface 207 MTU and Minimum LSP Bandwidth. The Interface MTU is the minimum MTU 208 along the path of the FA-LSP; the Minimum LSP Bandwidth is the 209 bandwidth of the LSP. 211 5.1.10. SRLG information 213 An FA advertisement could contain the information about the Shared 214 Risk Link Groups (SRLG) for the path taken by the FA-LSP associated 215 with that FA. This information may be used for path calculation by 216 other LSRs. The information carried is the union of the SRLGs of the 217 underlying TE links that make up the FA-LSP path; it is carried in 218 the SRLG TLV in IS-IS or the SRLG sub-TLV of the TE Link TLV in OSPF. 219 See [GMPLS-ISIS, GMPLS-OSPF] for details on the format of this 220 information. 222 It is possible that the underlying path information might change over 223 time, via configuration updates, or dynamic route modifications, 224 resulting in the change of the SRLG TLV. 226 If FAs are bundled (via link bundling), and if the resulting bundled 227 link carries a SRLG TLV, it MUST be the case that the list of SRLGs 228 in the underlying path followed by each of the FA-LSPs that form the 229 component links is the same (note that the exact paths need not be 230 the same). 232 6. Other considerations 234 It is expected that FAs will not be used for establishing ISIS/OSPF 235 peering relation between the routers at the ends of the adjacency. 237 It may be desired in some cases that FAs only be used in Traffic 238 Engineering path computations. In IS-IS, this can be accomplished by 239 setting the default metric of the extended IS reachability TLV for 240 the FA to the maximum link metric (2^24 - 1). In OSPF, this can be 241 accomplished by not advertising the link as a regular LSA, but only 242 as a TE opaque LSA. 244 7. Controlling FA-LSPs boundaries 246 To facilitate controlling the boundaries of FA-LSPs this document 247 introduces two new mechanisms: Interface Switching Capability (see 248 [GMPLS-ISIS, GMPLS-OSPF], and "LSP region" (or just "region"). 250 7.1. LSP regions 252 The information carried in the Interface Switching Capabilities is 253 used to construct LSP regions, and determine regions' boundaries as 254 follows. 256 Define an ordering among interface switching capabilities as follows: 257 PSC-1 < PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. Given two 258 interfaces if-1 and if-2 with interface switching capabilities isc-1 259 and isc-2 respectively, say that if-1 < if-2 iff isc-1 < isc-2 or 260 isc-1 == isc-2 == TDM, and if-1's max LSP bandwidth is less than 261 if-2's max LSP bandwidth. 263 Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2, 264 node-2, ..., link-n, node-n. Moreover, for link-i denote by [link-i, 265 node-(i-1)] the interface that connects link-i to node-(i-1), and by 266 [link-i, node-i] the interface that connects link-i to node-i. 268 If [link-(i+1), node-i)] < [link-(i+1), node-(i+1)], we say that the 269 LSP has crossed a region boundary at node-i; with respect to that LSP 270 path, the LSR at node-i is an edge LSR. The 'other edge' of the 271 region with respect to the LSP path is node-k, where k is the 272 smallest number greater than i such that [link-(i+1), node-(i+1)] 273 equal [link-k, node-(k-1)], and [link-k, node-(k-1)] > [link-k, node- 274 k]. 276 Path computation may take into account region boundaries when 277 computing a path for an LSP. For example, path computation may 278 restrict the path taken by an LSP to only the links whose Interface 279 Switching Capability is PSC-1. 281 Note that an interface may have multiple Interface Switching 282 Capabilities. In such a case, the test whether if-i < if-j depends 283 on the Interface Switching Capabilities chosen for if-i and if-j, 284 which in turn determines whether or not there is a region boundary at 285 node-i. 287 8. Signalling aspects 289 In this section we describe procedures that an LSR at the head-end of 290 an FA uses for handling LSP setup originated by other LSR. 292 As we mentioned before, establishment/termination of FA-LSPs may 293 triggered either by mechanisms outside of GMPLS (e.g., via 294 administrative control), or by mechanisms within GMPLS (e.g., as a 295 result of the LSR at the edge of an aggregate LSP receiving LSP setup 296 requests originated by some other LSRs beyond LSP aggregate and its 297 edges). Procedures described in Section "Common procedures" applied 298 to both cases. Procedures described in Section "Specific procedures" 299 apply only to the latter case. 301 8.1. Common procedures 303 For the purpose of processing the ERO in a Path/Request message of an 304 LSP that is to be tunneled over an FA , an LSR at the head-end of the 305 FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP 306 hop away). 308 How this is to be achieved for RSVP-TE and CR-LDP is described in the 309 following subsections. 311 In either case (RSVP-TE or CR-LDP), when an LSP is tunneled through 312 an FA-LSP, the LSR at the head-end of the FA-LSP subtracts the LSP's 313 bandwidth from the unreserved bandwidth of the FA. 315 In the presence of link bundling (when link bundling is applied to 316 FAs), when an LSP is tunneled through an FA-LSP, the LSR at the head- 317 end of the FA-LSP also need to adjust Max LSP bandwidth of the FA. 319 8.1.1. RSVP-TE 321 If one uses RSVP-TE to signal an LSP to be tunneled over an FA-LSP, 322 then the Path message MUST contain an IF_ID RSVP_HOP object [GRSVP- 323 TE, GSIG] instead of an RSVP_HOP object; and the data interface 324 identification MUST identify the FA-LSP. 326 The preferred method of sending the Path message is to set the 327 destination IP address of the Path message to the computed NHOP for 328 that Path message. This NHOP address must be a routable address; in 329 the case of separate control and data planes, this must be a control 330 plane address. 332 Furthermore, the IP header for the Path message MUST NOT have the 333 Router Alert option. The Path message is intended to be IP-routed to 334 the tail end of the FA-LSP without being intercepted and processed as 335 an RSVP message by any of the intermediate nodes. 337 Finally, the IP TTL vs. RSVP TTL check MUST NOT be made. In general, 338 if the IF_ID RSVP_HOP object is used, this check must be disabled, as 339 the number of hops over the control plane may be greater than one. 340 Instead, the following check is done by the receiver Y of the IF_ID 341 RSVP_HOP object: 343 1. Make sure that the data interface identified in the IF_ID 344 RSVP_HOP object actually terminates on Y. 345 2. Find the "other end" of the above data interface, say X. 346 Make sure that the PHOP in the IF_ID RSVP_HOP object is a 347 control channel address that belongs to the same node as X. 349 How check #2 is carried out is beyond the scope of this document; 350 suffice it to say that it may require a Traffic Engineering Database, 351 or the use of LMP [LMP] or yet other means. 353 An alternative method is to encapsulate the Path message in an IP 354 tunnel (or, in the case that the Interface Switching Capability of 355 the FA-LSP is PSC[1-4], in the FA-LSP itself), and unicast the 356 message to the tail end of the FA-LSP, without the Router Alert 357 option. This option may be needed if intermediate nodes process RSVP 358 messages regardless of whether the Router Alert option is present. 360 A PathErr sent in response to a Path message with an IF_ID RSVP_HOP 361 object SHOULD contain an IF_ID HOP object. (Note: a PathErr does not 362 normally carry an RSVP_HOP object, but in the case of separated 363 control and data, it is necessary to identify the data channel in the 364 PathErr message.) 366 The Resv message back to the head-end of the FA-LSP (PHOP) is IP- 367 routed to the PHOP in the Path message. If necessary, Resv Messages 368 MAY be encapsulated in another IP header whose destination IP address 369 is the PHOP of the received Path message. 371 8.1.2. CR-LDP 373 If one uses CR-LDP to signal an LSP to be tunneled over an FA-LSP, 374 then the Request message MUST contain an IF_ID TLV [GCR-LDP] object; 375 and the data interface identification MUST identify the FA-LSP. 377 Furthermore, the head end LSR must create a targetted LDP session 378 with the tail end LSR. The Request (Mapping) message is unicast from 379 the head end (tail end) to the tail end (head end). 381 8.2. Specific procedures 383 When an LSR receives a Path/Request message, the LSR determines 384 whether it is at the edge of a region with respect to the ERO carried 385 in the message. The LSR does this by looking up the interface 386 switching capabilities of the previous hop and the next hop in its 387 IGP database, and comparing them using the relation defined in 388 Section "Specific procedures". If the LSR is not at the edge of a 389 region, the procedures in this section do not apply. 391 If the LSR is at the edge of a region, it must then determine the 392 other edge of the region with respect to the ERO, again using the IGP 393 database. The LSR then extracts from the ERO the subsequence of hops 394 from itself to the other end of the region. 396 The LSR then compares the subsequence of hops with all existing FA- 397 LSPs originated by the LSR; if a match is found, that FA-LSP has 398 enough unreserved bandwidth for the LSP being signaled, and the L3PID 399 of the FA-LSP is compatible with the L3PID of the LSP being signaled, 400 the LSR uses that FA-LSP as follows. The Path/Request message for the 401 original LSP is sent to the egress of the FA-LSP, not to the next hop 402 along the FA-LSP's path. The PHOP in the message is the address of 403 the LSR at the head-end of the FA-LSP. Before sending the 404 Path/Request message, the ERO in that message is adjusted by removing 405 the subsequence of the ERO that lies in the FA-LSP, and replacing it 406 with just the end point of the FA-LSP. 408 Otherwise (if no existing FA-LSP is found), the LSR sets up a new FA- 409 LSP. That is, it initiates a new LSP setup just for the FA-LSP. Note 410 that the new LSP may traverse either 'basic' TE links or FAs. 412 After the LSR establishes the new FA-LSP, the LSR announces this LSP 413 into IS-IS/OSPF as an FA. 415 The unreserved bandwidth of the FA is computed by subtracting the 416 bandwidth of sessions pending the establishment of the FA-LSP 417 associated from the bandwidth of the FA-LSP. 419 An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP 420 as a matter of policy local to the LSR. It is expected that the FA- 421 LSP would be torn down once there are no more LSPs carried by the FA- 422 LSP. When the FA-LSP is torn down, the FA associated with the FA-LSP 423 is no longer advertised into IS-IS/OSPF. 425 8.3. FA-LSP Holding Priority 427 The value of the holding priority of an FA-LSP must be the minimum of 428 the configured holding priority of the FA-LSP and the holding 429 priorities of the LSPs tunneling through the FA-LSP (note that 430 smaller priority values denote higher priority). Thus, if an LSP of 431 higher priority than the FA-LSP tunnels through the FA-LSP, the FA- 432 LSP is itself promoted to the higher priority. However, if the 433 tunneled LSP is torn down, the FA-LSP need not drop its priority to 434 its old value right away; it may be advisable to apply hysteresis in 435 this case. 437 If the holding priority of an FA-LSP is configured, this document 438 restricts it to 0. 440 9. Security Considerations 442 From a security point of view, the primary change introduced in this 443 document is that the implicit assumption of a binding between data 444 interfaces and the interface over which a control message is sent is 445 no longer valid. 447 This means that the "sending interface" or "receiving interface" is 448 no longer well defined, as the interface over which an RSVP message 449 is sent may change as routing changes; therefore, mechanisms that 450 depend on these concepts (for example, the definition of a security 451 association) need a clearer definition. 453 [RFC2747] provides a solution: in section 2.1, under "Key 454 Identifier", an IP address is a valid identifier for the sending (and 455 by analogy, receiving) interface. Since RSVP messages for a given 456 LSP are sent to an IP address that identifies the next/previous hop 457 for the LSP, one can replace all occurrences of 'sending [receiving] 458 interface' with 'receiver's [sender's] IP address' (respectively). 459 For example, in Section 4, third paragraph, instead of: 461 "Each sender SHOULD have distinct security associations (and keys) 462 per secured sending interface (or LIH). ... At the sender, 463 security association selection is based on the interface through 464 which the message is sent." 466 read: 468 "Each sender SHOULD have distinct security associations (and keys) 469 per secured receiver's IP address. ... At the sender, security 470 association selection is based on the IP address to which the 471 message is sent." 473 Note that CR-LDP does not have this issue, as CR-LDP messages are 474 sent over TCP sessions, and no assumption is made that these sessions 475 are to direct neighbors. The recommended mechanism for 476 authentication and integrity of LDP message exchange is to use the 477 TCP MD5 option [LDP]. 479 Another consequence (relevant to RSVP) of the changes proposed in 480 this document is that IP destination address of Path messages be set 481 to the receiver's address, not to the session destination. Thus, the 482 objections raised in section 1.2 of [RFC2747] should be revisited to 483 see if IPSec AH is now a viable means of securing RSVP-TE messages. 485 10. Acknowledgements 487 Many thanks to Alan Hannan, whose early discussions with Yakov 488 Rekhter contributed greatly to the notion of Forwarding Adjacencies. 489 We would also like to thank George Swallow, Quaizar Vohra and Ayan 490 Banerjee. 492 11. Normative References 494 [GCR-LDP] Ashwood-Smith, Berger et al, "Generalized MPLS - CR-LDP 495 Extensions" (work in progress). 497 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 498 Extensions in Support of Generalized MPLS", (work in progress). 500 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 501 Extensions in Support of Generalized MPLS", (work in progress). 503 [GRSVP-TE] Ashwood-Smith, Berger et al, "Generalized MPLS - RSVP-TE 504 Extensions" (work in progress). 506 [GSIG] Ashwood-Smith, Berger et al, "Generalized MPLS - Signaling 507 Functional Description" (work in progress). 509 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 510 Engineering", (work in progress). 512 [LDP] "Label Distribution Protocol", RFC3036 514 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 515 Extensions to OSPF", (work in progress). 517 [UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling 518 Unnumbered Links in CR-LDP", (work in progress). 520 [UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 521 in RSVP", (work in progress). 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 527 Authentication", RFC 2747, January 2000. 529 12. Non-normative References 531 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 532 MPLS Traffic Engineering", (work in progress). 534 [LMP] "Link Management Protocol (LMP)", draft-ietf-ccamp-lmp-02.txt, 535 (work in progress) 537 13. Author Information 539 Kireeti Kompella 540 Juniper Networks, Inc. 541 1194 N. Mathilda Ave 542 Sunnyvale, CA 94089 543 e-mail: kireeti@juniper.net 545 Yakov Rekhter 546 Juniper Networks, Inc. 547 1194 N. Mathilda Ave 548 Sunnyvale, CA 94089 549 e-mail: yakov@juniper.net