idnits 2.17.1 draft-ietf-ccamp-path-key-ero-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group A. Farrel (Ed.) 3 Internet-Draft Old Dog Consulting 4 Intended Status: Standards Track R. Bradford 5 Created: March 7, 2009 JP. Vasseur 6 Expires: September 7, 2009 Cisco Systems, Inc. 8 RSVP Extensions for Path Key Support 10 draft-ietf-ccamp-path-key-ero-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 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 Abstract 35 The paths taken by Multiprotocol Label Switching (MPLS) and 36 Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched 37 Paths (LSPs) may be computed by Path Computation Elements (PCEs). 38 Where the TE LSP crosses multiple domains, such as Autonomous Systems 39 (ASes), the path may be computed by multiple PCEs that cooperate, 40 with each responsible for computing a segment of the path. 42 To preserve confidentiality of topology within each AS, the PCEs 43 support a mechanism to hide the contents of a segment of a path (such 44 as the segment of the path that traverses an AS), called the 45 Confidential Path Segment (CPS), by encoding the contents as a Path 46 Key Subobject (PKS) and embedding this subobject within the result of 47 its path computation. 49 This document describes how to carry Path Key Subobjects in the 50 Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) 51 and Record Route Object (RROs) so as to facilitate confidentiality in 52 the signaling of inter-domain TE LSPs. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 57 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 58 "OPTIONAL" in this document are to be interpreted as described in 59 RFC-2119 [RFC2119]. 61 1. Introduction 63 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 64 Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled 65 using the TE extensions to the Resource Reservation Protocol 66 (RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and 67 GMPLS TE LSPs may be computed by Path Computation Elements (PCEs) 68 [RFC4655]. 70 Where the TE LSP crosses multiple domains [RFC4726], such as 71 Autonomous Systems (ASes), the path may be computed by multiple PCEs 72 that cooperate, with each responsible for computing a segment of the 73 path. To preserve confidentiality of topology with each AS, the 74 PCE Communications Protocol (PCEP) [RFC5440] supports a mechanism to 75 hide the contents of a segment of a path, called the Confidential 76 Path Segment (CPS), by encoding the contents as a Path Key 77 Subobject (PKS) [PCE-PKS]. 79 This document defines RSVP-TE protocol extensions necessary to 80 support the use of Path Key Subobjects in MPLS and GMPLS signaling by 81 including them in Explicit Route Objects (EROs) and Record Route 82 Object (RROs) so as to facilitate confidentiality in the signaling of 83 inter-domain TE LSPs. 85 1.1. Usage Scenario 87 Figure 1 shows a simple network constructed of two ASes. An LSP is 88 desired from the ingress in AS-1 to the egress in AS-2. As described 89 in [RFC4655], the ingress Label Switching Router (LSR) acts as a Path 90 Computation Client (PCC) and sends a request to its PCE (PCE-1). 91 PCE-1 can compute the path within AS-1, but has no visibility into 92 AS-2. So PCE-1 cooperates with PCE-2 to complete the path 93 computation. 95 However, PCE-2 does not want to share the information about the 96 path across AS-2 with nodes outside the AS. So, as described in 98 [PCE-PKS], PCE-2 reports the AS-2 path segment using a PKS rather 99 than the explicit details of the path. 101 PCE-1 can now return the path to be signaled to the ingress LSR in a 102 path computation response with the AS-2 segment still hidden as a 103 PKS. 105 In order to set up the LSP, the ingress LSR signals using RSVP-TE and 106 encodes the path reported by PCE-1 in the Explicit Route Object 107 (ERO). This process is as normal for RSVP-TE, but requires that the 108 PKS is also included in the ERO using the mechanisms defined in this 109 document. 111 When the signaling message (the RSVP-TE Path message) reaches ASBR-2 112 it consults PCE-2 to 'decode' the PKS and return the expanded 113 explicit path segment to ASBR-2. (The information that PCE-2 uses to 114 decode the PKS is encoded within the PKS itself.) The PKS is replaced 115 in the ERO with the expanded information about the path. 117 ----------------------------- ---------------------------- 118 | AS-1 | | AS-2 | 119 | | | | 120 | ------- | | ------- | 121 | | PCE-1 |<---------------+--+-->| PCE-2 | | 122 | ------- | | ------- | 123 | ^ | | ^ | 124 | | | | | | 125 | v | | v | 126 | ------- ---- | | ---- | 127 | | PCC | - - |ASBR| | | |ASBR| - - ------ | 128 | |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| | 129 | ------- - - ----- | | ---- - - ------ | 130 | | | | 131 ----------------------------- ---------------------------- 133 Figure 1 : A Simple network to demonstrate the use of the PKS 135 2. Terminology 137 CPS: Confidential Path Segment. A segment of a path that contains 138 nodes and links that the AS policy requires to not be disclosed 139 outside the AS. 141 PCE: Path Computation Element: an entity (component, application 142 or network node) that is capable of computing a network path or 143 route based on a network graph and applying computational 144 constraints. 146 PKS: Path Key Subobject. A subobject of an Explicit Route Object 147 which encodes a CPS, so as to preserve confidentiality. 149 3. RSVP-TE Path Key Subobject 151 The Path Key Subobject (PKS) may be carried in the Explicit Route 152 Object (ERO) of a RSVP-TE Path message [RFC3209]. The PKS is a fixed- 153 length subobject containing a Path Key and a PCE-ID. The Path Key is 154 an identifier, or token used to represent the CPS within the context 155 of the PCE identified by the PCE-ID. The PCE-ID identifies the PCE 156 that can decode the Path Key using a reachable IPv4 or IPv6 address 157 of the PCE. In most cases, the decoding PCE is also the PCE that 158 computed the Path Key and the associated path. Because of the IPv4 159 and IPv6 variants, two subobjects are defined as follows. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 |L| Type | Length | Path Key | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | PCE ID (4 bytes) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 L 171 The L bit SHOULD NOT be set, so that the subobject represents a 172 strict hop in the explicit route. 174 Type 176 Subobject Type for a Path Key with 32-bit PCE ID as assigned by 177 IANA. 179 Length 181 The Length contains the total length of the subobject in bytes, 182 including the Type and Length fields. The Length is always 8. 184 PCE ID 186 A 32-bit identifier of the PCE that can decode this key. The 187 identifier MUST be unique within the scope of the domain that the 188 CPS crosses, and MUST be understood by the LSR that will act as 189 PCC for the expansion of the PKS. The interpretation of the 190 PCE-ID is subject to domain-local policy. It MAY be an IPv4 191 address of the PCE that is always reachable, and MAY be an 192 address that is restricted to the domain in which the LSR that is 193 called upon to expand the CPS lies. Other values that have no 194 meaning outside the domain (for example, the Router ID of the 195 PCE) MAY be used to increase security or confidentiality. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |L| Type | Length | Path Key | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | PCE ID (16 bytes) | 203 | | 204 | | 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 L 210 As above. 212 Type 214 Subobject Type for a Path Key with 128-bit PCE ID as assigned by 215 IANA. 217 Length 219 The Length contains the total length of the subobject in bytes, 220 including the Type and Length fields. The Length is always 20. 222 PCE ID 224 A 128-bit identifier of the PCE that can decode this key. The 225 identifier MUST be unique within the scope of the domain that the 226 CPS crosses, and MUST be understood by the LSR that will act as 227 PCC for the expansion of the PKS. The interpretation of the 228 PCE-ID is subject to domain-local policy. It MAY be an IPv6 229 address of the PCE that is always reachable, but MAY be an 230 address that is restricted to the domain in which the LSR that is 231 called upon to expand the CPS lies. Other values that have no 232 meaning outside the domain (for example, the IPv6 TE Router ID) 233 MAY be used to increase security (see Section 5). 235 Note: The twins of these sub-objects are carried in PCEP messages 236 as defined in [PCE-PKS]. 238 3.1. Explicit Route Object Processing Rules 240 The basic processing rules of an ERO are not altered. Refer to 241 [RFC3209] for details. In particular, an LSR is not required to "look 242 ahead" in the ERO beyond the first subobject that is non-local. 244 [PCE-PKS] requires that any path fragment generated by a PCE that 245 contains a PKS is such that the PKS is immediately preceded by an 246 subobject that identifies the head end of the PKS (for example, an 247 incoming interface, or a node ID). This rule is extended to the PKS 248 in the ERO so that the following rules are defined. 250 - If an LSR receives a Path message where the first subobject of the 251 ERO is a PKS, it MUST respond with a PathErr message carrying the 252 error code/value combination "Routing Problem"/"Bad initial 253 subobject". 255 - If an LSR strips all local sub-objects from an ERO carried in a 256 Path message (according to the procedures in [RFC3209]) and finds 257 that the next subobject is a PKS it MUST attempt to resolve the PKS 258 to a CPS. 260 Resolution of the PKS MAY take any of the following forms or use 261 some other technique subject to local policy and network 262 implementation. 264 - The LSR can use the PCE-ID contained in the PKS to contact the 265 identified PCE using PCEP [RFC5440] and request that the PKS be 266 expanded. 268 - The LSR can contact any PCE using PCEP [RFC5440] to request that 269 the PKS be expanded relying on cooperation between the PCEs. 271 - The LSR can use the information in the PKS to index a CPS 272 previously supplied to it by the PCE that originated the PKS. 274 If a CPS is derived, the path fragment SHOULD be inserted into the 275 ERO of the Path message as a direct replacement for the PKS. Other 276 processing of the CPS and ERO are permitted as described in 277 [RFC3209]. 279 This processing can give rise to the following error cases: 281 - PCE-ID cannot be matched to a PCE to decode the PKS. 283 The LSR sends a PathErr message with the error code "Routing 284 Problem" and a new error value "Unknown PCE-ID for PKS expansion" 285 (see Section 6.3). 287 - PCE identified by the PCE-ID cannot be reached. 289 The LSR sends a PathErr message with the error code "Routing 290 Problem" and a new error value "Unreachable PCE for PKS 291 expansion" (see Section 6.3). 293 - The PCE is unable to decode the PKS, perhaps because the Path Key 294 has expired. 296 The LSR sends a PathErr message with the error code "Routing 297 Problem" and a new error value "Unknown Path Key for PKS 298 expansion" (see Section 6.3). 300 - PKS cannot be decoded for policy reasons. 302 The LSR sends a PathErr message with the error code "Policy 303 Control Failure" and the error value "Inter-domain policy 304 failure". 306 - Addition of CPS to ERO causes Path message to become too large. 308 The LSR MAY replace part of the ERO with loose hops [RFC3209] or 309 with a further PKS according to local policy if the loss in 310 specifics within the explicit path is acceptable. If the LSR is 311 unable to take steps to reduce the size of the ERO it MUST send a 312 PathErr message with the error code "Routing Problem" and a new 313 error value "ERO too large for MTU" (see Section 6.3). 315 - An LSR that is called on to process a PKS within an ERO, but does 316 not recognize the subobject will react according to [RFC3209] and 317 send a PathErr message with the error code/value combination 318 "Routing Problem"/"Bad Explicit Route Object". 320 3.2. Reporting Path Key Segments in Record Route Objects 322 The Record Route Object (RRO) is used in RSVP-TE to record the route 323 traversed by an LSP. The RRO may be present on a Path message and on 324 a Resv message. The intention [RFC3209] is that an RRO on a Resv 325 message received by an ingress LSR is suitable for use as an ERO on a 326 Path message sent by that LSR to achieve an identical LSP. 328 The PKS offers an alternative that can be more useful to diagnostics. 329 When the signaling message crosses a domain boundary, the path 330 segment that needs to be hidden (that is, a CPS) MAY be replaced in 331 the RRO with a PKS. In the case of an RRO on a Resv message, the PKS 332 used SHOULD be the one originally signaled in the ERO of the Path 333 message. On a Path message, the PKS SHOULD identify the LSR replacing 334 the CPS, and provide a Path Key that can be used to expand the path 335 segment. In the latter case, the Path Key and its expansion SHOULD be 336 retained by the LSR that performs the substitution for at least the 337 lifetime of the LSP. In both cases, the expansion of the PKS SHOULD 338 be made available to diagnostic tools under the control of local 339 policy. 341 4. Security Considerations 343 The protocol interactions required by the mechanisms described in 344 this document are point to point and can be authenticated and made 345 secure as described in [RFC5440] and [RFC3209]. The protocol 346 interactions for PCEP are listed in [PCE-PKS], while general 347 considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can 348 be found in [MPLS-SEC]. 350 Thus, the security issues can be dealt with using standard techniques 351 for securing and authenticating point-to-point communications. In 352 addition, it is RECOMMENDED that the PCE providing a PKS expansion 353 checks that the LSR that issued the request for PKS expansion is the 354 head end of the resulting CPS. 356 Further protection can be provided by using a PCE ID to identify 357 the decoding PCE that is only meaningful within the domain that 358 contains the LSR at the head of the CPS. This may be an IP address 359 that is only reachable from within the domain, or some non-address 360 value. The former requires configuration of policy on the PCEs, 361 the latter requires domain-wide policy. 363 The following specific security issues need to be considered. 365 - Confidentiality of the CPS. The question to be answered is whether 366 other network elements can probe a PCE for the expansion of PKSs, 367 possibly generating path keys at random. This can be protected 368 against by only allowing PKS expansion to be successfully completed 369 if requested by the LSR that is at the head end of the resulting 370 CPS. Under specific circumstances, PKS expansion might also be 371 allowed by configured management stations. 373 The CPS itself may be kept confidential as it is exchanged in the 374 PCEP and RSVP-TE protocols using standard security mechanisms 375 defined for those protocols. 377 - Determination of information by probing. In addition to the probing 378 described above, a node might deduce information from the error 379 responses generated when PKS expansion fails as described in 380 Section 3.1. Any LSR that considers that supplying one of the 381 detailed error codes described in Section 3.1 might provide too 382 much information that could be used as part of a systematic attack, 383 MAY simply use the error code/value "Policy Control Failure"/ 384 "Inter-domain policy failure" in all cases. 386 - Authenticity of the path key. A concern is that the path key in the 387 PKS will be altered or faked leading to erroneous path key 388 expansion and the use of the wrong CPS. The consequence would be a 389 bad ERO in a Path message causing the LSP to be set up incorrectly 390 resulting in incorrect network resource usage, diversion of traffic 391 to where it can be intercepted, or failure to set up the LSP. These 392 problems can be prevented by protecting the protocol exchanges in 393 PCEP and RSVP-TE using the security techniques described in 394 [RFC5440], [RFC3209], and [MPLS-SEC]. 396 - Resilience to DoS attacks. A PCE can be attacked through a flood of 397 path key expansion requests - this issue is addressed in [PCE-PKS] 398 and is out of scope for this document. A further attack might 399 consist of sending a flood of RSVP-TE Path messages with 400 deliberately spurious PKSs. This attack is prevented by ensuring 401 the integrity of the Path messages using standard RSVP-TE security 402 mechanisms, and by enforcing the RSVP-TE chain of trust security 403 model. 405 5. Manageability Considerations 407 5.1. Control of Function Through Configuration and Policy 409 Policy forms an important part of the use of PKSs in EROs and RROs. 410 There are local and domain-wide policies that SHOULD be available for 411 configuration in an implementation. 413 - Handling of an ERO containing a PKS. As described in Section 3.1 an 414 LSR that receives a Path message containing a PKS can be configured 415 to reject the Path message according to policy. 417 - Handling of PKS requests at a PCE. As described in Section 3.1, in 418 [PCE-PKS], and in [RFC5394] a PCE can be configured with policy 419 about how it should handle requests for PKS expansion. 421 - PKS expansion. Section 3.1 explains that the PKS can be expanded by 422 the local LSR, the specific PCE identified in the PKS, any PCE 423 acting as a proxy, or by some other method. The behavior of the LSR 424 needs to be locally configurable, but is subject the domain-wide 425 policy. 427 - Interpretation of PCE-ID. The interpretation of the PCE-ID 428 component of PKSs is subject to domain-local policy and needs to be 429 configurable as such. See Section 3 and Section 4 for the options. 431 - ERO too large. The behavior of an LSR when it finds that adding a 432 CPS to the ERO causes the Path message to be too large, is an 433 implementation choice. However, implementations may choose to 434 provide configuration of behavior as described in Section 3.1. 436 - Masking of RRO. As described in Section 3.2, a border router can 437 choose to mask segments of the path by replacing them with PKSs. 438 This behavior needs to be configurable with the default being to 439 not hide any part of the RRO. 441 - Inspection / decode of PKS by diagnostic tools. A PCE can allow 442 access from management or diagnostic tools to request the expansion 443 of a PKS. Note that this must be regulated with the security and 444 confidentiality behavior described in Section 4. 446 - Hiding of reason codes. An LSR can support the configuration of 447 local policy to hide reason codes associated with the failure to 448 expand a PKS, and as described in Section 4, report all errors as 449 policy failures. 451 The treatment of a path segment as a CPS, and its substitution in 452 a PCRep ERO with a PKS, is a PCE function and is described in 453 [PCE-PKS]. 455 6. IANA considerations 457 6.1. Explicit Route Object Subobjects 459 IANA maintains a registry called "Resource Reservation Protocol 460 (RSVP) Parameters" with a subregistry called "Class Names, Class 461 Numbers, and Class Types". 463 Within this subregistry there is a definition of the EXPLICIT_ROUTE 464 object with Class Number 20. The object definition lists a number of 465 acceptable sub-objects for the Class Type 1. 467 IANA is requested to allocate two further sub-objects as described in 468 Section 3. The resulting entry in the registry should look as 469 follows. 471 20 EXPLICIT_ROUTE [RFC3209] 472 Class Types or C-Types: 473 1 Type 1 Explicit Route [RFC3209] 474 Sub-object type 475 64 Path Key with 32-bit PCE ID [This.I-D] 476 65 Path Key with 128-bit PCE ID [This.I-D] 478 Note well: [PCE-PKS] defines the PKS for use in PCEP. IANA is 479 requested to assign the same sub-object numbers for use in RSVP-TE as 480 are assigned for the PKS in PCEP. The numbers suggested above are the 481 same as are suggested in [PCE-PKS]. 483 6.2. Record Route Objects Subobjects 485 IANA maintains a registry called "Resource Reservation Protocol 486 (RSVP) Parameters" with a subregistry called "Class Names, Class 487 Numbers, and Class Types". 489 Within this subregistry there is a definition of the ROUTE_RECORD 490 object (also known as the RECORD_ROUTE object) with Class Number 21. 491 The object definition lists a number of acceptable sub-objects for 492 the Class Type 1. 494 IANA is requested to allocate two further sub-objects as described in 495 Section 3. The resulting entry in the registry should look as 496 follows. 498 21 ROUTE_RECORD [RFC3209] 499 (also known as RECORD_ROUTE) 500 Class Types or C-Types: 501 1 Type 1 Route Record [RFC3209] 502 Sub-object type 503 64 Path Key with 32-bit PCE ID [This.I-D] 504 65 Path Key with 128-bit PCE ID [This.I-D] 506 Note well: IANA is requested to use the same sub-object numbers as 507 are defined for the EXPLICIT_ROUTE object in Section 6.1. 509 6.3. Error Codes and Error Values 511 IANA maintains a registry called "Resource Reservation Protocol 512 (RSVP) Parameters" with a subregistry called "Error Codes and 513 Globally-Defined Error Value Sub-Codes". 515 Within this subregistry there is a definition of the "Routing 516 Problem" error code with error code value 24. The definition lists a 517 number of error values that may be used with this error code. 519 IANA is requested to allocate further error values for use with this 520 error value as described in Section 3.1. The resulting entry in the 521 registry should look as follows. 523 24 Routing Problem [RFC3209] 525 This Error Code has the following globally-defined Error 526 Value sub-codes: 528 31 = Unknown PCE-ID for PKS expansion [This.ID] 529 32 = Unreachable PCE for PKS expansion [This.ID] 530 33 = Unknown Path Key for PKS expansion [This.ID] 531 34 = ERO too large for MTU [This.ID] 533 The values shown above are suggested values. 535 7. References 537 7.1. Normative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 543 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 544 Tunnels", RFC 3209, December 2001. 546 [RFC3473] Berger, L., et al. "GMPLS Singaling RSVP-TE extensions", 547 RFC3473, January 2003. 549 7.2. Informational References 551 [RFC4655] Farrel, A., Vasseur, J.P., and Ash, J., "Path Computation 552 Element (PCE) Architecture", RFC 4655, August 2006. 554 [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A Framework 555 for Inter-Domain Multiprotocol Label Switching Traffic 556 Engineering", RFC 4726, November 2006. 558 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L. and Ash, J., 559 "Policy-Enabled Path Computation Framework", RFC 5394, 560 December 2008. 562 [RFC5440] J.P. Vasseur, et al., "Path Computation Element (PCE) 563 Communication Protocol (PCEP)", RFC 5440, March 2009. 565 [MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS 566 Networks", draft-ietf-mpls-mpls-and-gmpls-security- 567 framework, work in progress. 569 [PCE-PKS] Bradford, R., Vasseur, J.P., and Farrel, A., "Preserving 570 Topology Confidentiality in Inter-Domain Path Computation 571 Using a Key-Based Mechanism", draft-ietf-pce-path-key, 572 work in progress. 574 8. Authors' Addresses: 576 Adrian Farrel 577 Old Dog Consulting 578 EMail: adrian@olddog.co.uk 580 Rich Bradford 581 Cisco Systems, Inc. 582 1414 Massachusetts Avenue 583 Boxborough, MA - 01719 584 USA 585 Email: rbradfor@cisco.com 587 Jean-Philippe Vasseur 588 Cisco Systems, Inc. 589 1414 Massachusetts Avenue 590 Boxborough, MA - 01719 591 USA 592 Email: jpv@cisco.com 594 Intellectual Property 596 The IETF Trust takes no position regarding the validity or scope of 597 any Intellectual Property Rights or other rights that might be 598 claimed to pertain to the implementation or use of the technology 599 described in any IETF Document or the extent to which any license 600 under such rights might or might not be available; nor does it 601 represent that it has made any independent effort to identify any 602 such rights. 604 Copies of Intellectual Property disclosures made to the IETF 605 Secretariat and any assurances of licenses to be made available, or 606 the result of an attempt made to obtain a general license or 607 permission for the use of such proprietary rights by implementers or 608 users of this specification can be obtained from the IETF on-line IPR 609 repository at http://www.ietf.org/ipr 611 The IETF invites any interested party to bring to its attention any 612 copyrights, patents or patent applications, or other proprietary 613 rights that may cover technology that may be required to implement 614 any standard or specification contained in an IETF Document. Please 615 address the information to the IETF at ietf-ipr@ietf.org. 617 The definitive version of an IETF Document is that published by, or 618 under the auspices of, the IETF. Versions of IETF Documents that are 619 published by third parties, including those that are translated into 620 other languages, should not be considered to be definitive versions 621 of IETF Documents. The definitive version of these Legal Provisions 622 is that published by, or under the auspices of, the IETF. Versions of 623 these Legal Provisions that are published by third parties, including 624 those that are translated into other languages, should not be 625 considered to be definitive versions of these Legal Provisions. 627 For the avoidance of doubt, each Contributor to the IETF Standards 628 Process licenses each Contribution that he or she makes as part of 629 the IETF Standards Process to the IETF Trust pursuant to the 630 provisions of RFC 5378. No language to the contrary, or terms, 631 conditions or rights that differ from or are inconsistent with the 632 rights and licenses granted under RFC 5378, shall have any effect and 633 shall be null and void, whether published or posted by such 634 Contributor, or included with or in such Contribution. 636 Disclaimer of Validity 638 All IETF Documents and the information contained therein are provided 639 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 640 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 641 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 642 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 643 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 644 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 645 FOR A PARTICULAR PURPOSE. 647 Full Copyright Statement 649 Copyright (c) 2009 IETF Trust and the persons identified as the 650 document authors. All rights reserved. 652 This document is subject to BCP 78 and the IETF Trust's Legal 653 Provisions Relating to IETF Documents in effect on the date of 654 publication of this document (http://trustee.ietf.org/license-info). 655 Please review these documents carefully, as they describe your 656 rights and restrictions with respect to this document. 658 This document may contain material from IETF Documents or IETF 659 Contributions published or made publicly available before November 660 10, 2008. The person(s) controlling the copyright in some of this 661 material may not have granted the IETF Trust the right to allow 662 modifications of such material outside the IETF Standards Process. 663 Without obtaining an adequate license from the person(s) 664 controlling the copyright in such materials, this document may not 665 be modified outside the IETF Standards Process, and derivative 666 works of it may not be created outside the IETF Standards Process, 667 except to format it for publication as an RFC or to translate it 668 into languages other than English.