idnits 2.17.00 (12 Aug 2021) /tmp/idnits44419/draft-leroux-mpls-p2mp-te-bypass-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 495. 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? 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 137 has weird spacing: '... to the prote...' -- 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 (March 2007) is 5545 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: 'RFC2119' is defined on line 416, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4461 == Outdated reference: draft-ietf-mpls-rsvp-te-p2mp has been published as RFC 4875 == Outdated reference: draft-ietf-mpls-upstream-label has been published as RFC 5331 -- Possible downref: Normative reference to a draft: ref. 'RSVP-UP' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.L. Le Roux 3 Internet Draft France Telecom 4 Category: Standard Track 5 Expires: September 2007 R. Aggarwal 6 Juniper Networks 8 J.P. Vasseur 9 Cisco Systems, Inc. 11 M. Vigoureux 12 Alcatel-Lucent 14 March 2007 16 P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels 18 draft-leroux-mpls-p2mp-te-bypass-01.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet- Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 This document defines procedures for fast reroute protection of 45 Point-To-MultiPoint (P2MP) Traffic Engineering Label Switched Paths 46 (TE-LSP) in MultiProtocol Label Switching (MPLS) networks, based 47 upon Point-To-MultiPoint bypass tunnels. The motivation for using 48 P2MP bypass tunnels is to avoid potentially expensive data 49 duplication along the backup path that could occur if point-to-point 50 bypass tunnels where used, i.e. to optimize the bandwidth usage, 51 during fast reroute protection of a link or a node. During link or 52 node failure the traffic carried onto a protected P2MP TE-LSP is 53 tunnelled within one or several P2MP bypass tunnels towards a set of 54 Merge Points. To avoid data duplication backup labels (i.e. inner 55 labels) are assigned by the Point of Local Repair (PLR) following the 56 RSVP-TE upstream label assignment procedure. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119. 64 Table of Contents 66 1. Terminology.................................................3 67 2. Introduction................................................3 68 3. Solution overview...........................................4 69 4. PLR procedures..............................................6 70 4.1. Before failure..............................................6 71 4.1.1. P2MP Bypass Tunnel(s) Selection.............................6 72 4.1.2. P2MP Backup LSP Signalling..................................7 73 4.2. During failure..............................................8 74 5. MP Procedures...............................................8 75 6. To be included in future revisions..........................9 76 7. Security Considerations.....................................9 77 8. Acknowledgments.............................................9 78 9. References..................................................9 79 9.1. Normative references........................................9 80 10. Authors' Addresses:........................................10 81 11. Intellectual Property Statement............................11 83 1. Terminology 85 This document uses terminologies defined in [RFC3031], [RFC3209], 86 [RFC4090] and [RFC4461]. It defines the following new terms: 88 P2MP Bypass tunnel: Point-to-Multipoint Bypass Tunnel. A P2MP TE- 89 LSP that is used to protect a set of P2MP TE-LSPs traversing a 90 common facility (link or node). 92 P2MP Facility Backup: A local repair method in which a P2MP bypass 93 tunnel is used to protect one or more P2MP TE-LSPs that 94 traverse the Point of Local Repair (P2MP Bypass Ingress) and the 95 resource being protected. 97 Backup P2MP LSP: The LSP that is used to backup up one of the 98 many protected P2MP LSPs in P2MP Facility Backup. 100 Backup S2L sub-LSP: A S2L sub-LSP of a backup P2MP LSP. 102 PLR: Point of Local Repair: Head-end LSR of the bypass tunnel 104 MP: Merge Point: LSR where a primary LSP and its backup LSP merge. 106 . 107 2. Introduction 109 [RFC4090] defines fast reroute extensions to RSVP-TE [RFC3209] for 110 local protection of Point-To-Point (P2P) Traffic Engineered Label 111 Switched Paths (TE LSP) in MultiProtocol Label Switching (MPLS) 112 networks. Two techniques are defined: the one-to-one backup method, 113 which creates a detour LSP for each protected LSP at each point of 114 local repair (PLR), and the facility backup method, which creates a 115 bypass tunnel that can be used to protect a set of TE LSPs by taking 116 advantage of MPLS label stacking. 118 [RSVP-P2MP] defines extensions to RSVP-TE for setting up Point-To- 119 Multipoint (P2MP) TE LSPs. It specifies extensions to one-to-one and 120 facility backup Fast Reroute procedures defined in [RFC4090] so as to 121 support fast reroute protection of P2MP TE LSPs. 122 The facility backup solution defined in [RSVP-P2MP] only relies on 123 P2P bypass tunnels for link and node protection. This faces the 124 following limitations: 126 - The protection of a downstream link of a P2MP TE LSP on a 127 branch LSR may require a P2P Bypass LSP that uses another 128 downstream link of the P2MP LSP, and this leads to twice the 129 traffic on that link during failure, which is inefficient. 130 Finding a bypass path that avoids all downstream links on the 131 P2MP LSP would be a solution but this is often not achievable in 132 lowly meshed topologies. 134 - The protection of a P2MP TE LSP against node failures 135 requires, when the protected node is a Branch LSR, a set of P2P 136 Next-Next-Hop (NNHOP) Bypass tunnels toward all LSRs downstream 137 to the protected node. During failure the PLR has to replicate 138 traffic on each P2P NNHOP bypass tunnel. If there are K next- 139 next-hops, this may lead to K times the traffic on some links, 140 which is not acceptable (as K is of the order of magnitude of 141 the squared node degree). 143 - Similarly the protection of a P2MP TE LSP against the failure 144 of a LAN interface that connects a branch LSR and a set of K 145 downstream LSRs requires one P2P bypass tunnel per downstream 146 LSR, which may lead to K times the traffic on some links during 147 failure. 149 To overcome these limitations it is highly desirable to define 150 extensions to the fast reroute facility backup solution, so as to 151 support P2MP bypass tunnels. This retains the scalability advantages 152 of MPLS label stacking and avoids sending multiple copies of a packet 153 on some links during failure. 155 This draft specifies extensions to the Fast ReRoute (FRR) procedures 156 defined in [RFC4090] and [RSVP-P2MP] to support local repair of P2MP 157 TE LSP with P2MP bypass tunnels. 159 Procedures defined in [RFC3209], [RFC4090] and [RSVP-P2MP] MUST be 160 followed unless specified below. 162 3. Solution overview 164 The P2MP Facility Backup method defined in this document relies on 165 the use of P2MP bypass tunnels. Similarly to the P2P case, the same 166 P2MP bypass tunnel can be used to protect a set of P2MP TE LSPs, by 167 taking advantage of MPLS label stacking. 169 A P2MP Bypass tunnel can be used to protect a P2MP TE-LSP against 170 downstream link or node failures. There are various options for the 171 protection of a downstream link or node: 173 - Rely on a single P2MP bypass tunnel whose leaf LSRs exactly 174 matches the set of Merge Points (MP). Merge points are 175 transit or egress LSRs on the protected P2MP LSP downstream 176 to the PLR or downstream to the protected element (link or 177 node). 178 - Rely on a single P2MP Bypass tunnel whose set of leaf LSRs is 179 a superset of the set of MPs. Leaf LSRs which are not MP have 180 to drop the traffic. 181 - Rely on a combination of P2MP bypass LSPs whose leaf LSRs are 182 a subset of the set of MP but there combination encompass all 183 MPs. 185 These three options differ in terms of bandwidth optimization and 186 control plane state minimization. Option 1 increases the number of 187 states compared to option 2 (it implies more P2MP bypass LSPs), but 188 is less expensive in terms of bandwidth (traffic only sent to MPs). 189 With point-to-multipoint hierarchy there is always a tension between 190 minimizing the amount of control plane state and minimizing bandwidth 191 consumption. Choosing one of these options is a decision local to the 192 PLR. The choice depends on the desired trade-off between control 193 plane and data plane optimization, and the operational complexity 194 associated with the different options. 196 When the P2MP facility backup method is used, during failure the PLR 197 MUST send data for each protected P2MP LSP into the set of one or 198 more P2MP bypass tunnel. Label stacking is used: the inner label is 199 the backup label for the backup P2MP LSP, that will be used on the MP 200 to forward traffic to the corresponding protected P2MP LSP, and the 201 outer label is the P2MP bypass tunnel label. 203 To avoid data replication on the PLR, the same backup label MUST be 204 used for all S2L sub-LSPs of a given backup P2MP LSP, tunneled within 205 the same P2MP bypass tunnel. This backup label will indicate to the 206 Merge Points that packets received with that label should be switched 207 along the protected P2MP LSP. 209 For that purpose upstream label assignment procedures defined in 210 [MPLS-UPSTREAM] and RSVP-TE extensions for upstream label assignment 211 defined in [RSVP-UP] MUST be used. To signal a backup P2MP LSP, the 212 same backup label, is distributed by the PLR to all MPs belonging to 213 a same P2MP Bypass tunnel, in the context of this P2MP bypass tunnel. 214 This requires the backup P2MP LSP to be signalled prior to the 215 failure. 217 On the MP, backup S2L sub-LSPs (i.e. S2L sub-LSPs of the backup P2MP 218 LSP) are merged with protected S2L sub-LSPs. A MP (i.e. the bypass 219 tunnel leaf LSRs), maintains a context specific ILM for the P2MP 220 Bypass tunnel. This can be implemented by maintaining a different 221 context specific ILM for each LSR that is the root of a P2MP Bypass 222 tunnel, or by maintaining a different context specific ILM for each 223 P2MP Bypass tunnel. The context of an inner label (i.e a backup label) 224 is determined by the underlying P2MP bypass tunnel on which it is 225 received. This requires deactivating PHP on the P2MP bypass tunnel. A 226 label, in a given Bypass tunnel specific ILM, is mapped to the 227 outgoing interface(s) and label(s) of the corresponding protected 228 P2MP LSP. 230 4. PLR procedures 232 4.1. Before failure 234 4.1.1. P2MP Bypass Tunnel(s) Selection 236 To protect a P2MP TE LSP against a downstream link or node failure, a 237 PLR MUST select a set of one or more P2MP bypass tunnel(s), denoted 238 {B1.Bm}, as follows: 240 - The bypass tunnel(s) MUST NOT traverse the protected 241 link/node/SRLG. 243 - The set of leaf LSRs of bypass tunnels {B1.Bm}, denoted {LSR1. 244 LSRn} must include a set of Merge Points (MP), on the protected 245 P2MP LSP. These Merge Points are transit or egress LSRs on the 246 protected P2MP LSP downstream to the PLR or downstream to the 247 protected element (link or node). We will denote this set of 248 Merge Points as {MP1.MPq}. Note that the case where some MPs are 249 LSRs downstream to the PLR but not downstream to the failed 250 element allows avoiding sending twice the traffic on downstream 251 links during failure. 253 - In the event of failure of the protected link or node, traffic 254 received on the protected P2MP LSP by the PLR, can be delivered 255 to all the leaves of the protected P2MP LSP downstream to the 256 PLR, if it is tunnelled to {MP1.MPq} over the set of one or more 257 P2MP bypass tunnel(s) {B1.Bm}. 259 The PLR will assign upstream labels to Merge Points {MP1.MPq} for the 260 backup P2MP LSP. The same backup label will be assigned to all Merge 261 Points belonging to the same P2MP Bypass tunnel. 263 A MP may actually be leaf LSR of multiple bypass tunnels, but will be 264 associated to only one bypass tunnel. That is a PLR will signal the 265 P2MP backup LSP to that MP, for a single P2MP bypass tunnel context. 267 {LSR1.LSRn} may be a superset of {MP1.MPq}, that is some leaf LSRs of 268 a given P2MP bypass tunnel, noted {LSRx.LSRy}, may not belong to 269 {MP1.MPq}. The PLR will not assign upstream labels for the backup 270 P2MP LSP to these LSRs {LSRx.LSRy}. During failure packets with a 271 backup label will also be delivered onto the P2MP bypass tunnel to 272 {LSRx.LSRy} which will discard these packets based on no entry for 273 this label in the context specific ILM for that bypass tunnel. This 274 requires that {LSRx.LSRy} create a context specific ILM for that 275 bypass tunnel. 277 PHP MUST be deactivated on the P2MP Bypass tunnel, in order to allow 278 MPs to determine the context for the backup labels assigned by the 279 PLR. 281 Note that P2MP bypass LSPs may be signalled in advance either 282 automatically or via configuration, or may be dynamically setup upon 283 protected P2MP LSP signalling. Such procedures rely on local 284 implementation issues and are beyond the scope of this document. 286 4.1.2. P2MP Backup LSP Signalling 288 The same backup label (i.e. the inner label) MUST be used for all 289 backup S2L sub-LSPs which are tunneled within the same P2MP Bypass 290 tunnel, so as to avoid traffic replication on the PLR. This label 291 MUST be assigned by the PLR using upstream label assignment 292 procedures. 294 Backup P2MP LSPs MUST be signaled prior to the failure. To signal the 295 backup P2MP LSP, the PLR will send one or more Path messages, 296 referred to as a backup LSP's Path message, to each MP, as specified 297 in [RSVP-P2MP]. A backup LSP's Path message to a given MP comprises 298 one or more backup S2L sub-LSPs that transit through this MP. 299 A backup Path message MUST be sent to the MP using directed 300 signaling; i.e., it is addressed to the MP, without Router Alert 301 option. 303 As specified in [RSVP-P2MP] it is RECOMMENDED that the PLR use the 304 sender template specific method to identify a backup LSP's Path 305 message, that is, the PLR will set the source address in the sender 306 template to a local PLR address. 308 The backup label MUST be assigned by the PLR, in the context of the 309 underlying P2MP Bypass tunnel, following upstream label assignment 310 and P2MP RSVP-TE context identification procedures defined in [RSVP- 311 UP]. Hence, a backup LSP's Path message sent to a given MP MUST 312 include an Upstream Assigned Label object carrying the value of the 313 backup label. It MUST also include an RSVP-TE P2MP LSP TLV within an 314 IF_ID RSVP object, that carries the session object of the underlying 315 P2MP Bypass tunnel. This allows the MP to identify the label space of 316 the backup label assigned by the PLR. The same backup label MUST be 317 sent to all MPs belonging to a given P2MP Bypass tunnel. 319 Note that the PLR MUST continue to refresh Path messages for the 320 protected P2MP TE LSP along the nominal route. 322 The processing of backup S2L sub-LSP SEROs/SRROs MUST follow 323 backup LSP ERO/RRO processing described in [RFC4090]. 325 4.2. During failure 327 When the PLR detects a link or/and node failure condition, it has to 328 reroute a protected P2MP LSP onto a set of one or more P2MP bypass 329 tunnels using as inner label(s) the backup label(s) assigned for this 330 P2MP LSP. 332 Note that when some MPs are LSRs downstream to the PLR but not 333 downstream to the failed element, the PLR MUST stop sending traffic 334 directly within the protected P2MP TE LSP towards these MPs. This 335 allows avoiding sending twice the traffic on downstream links during 336 failure. 338 The PLR MUST continue to send Path messages for the backup P2MP LSP. 339 The RRO/ERO flags MUST be updated as per defined in [RFC4090] 341 5. MP Procedures 343 A MP receives one or more Path messages for the protected P2MP TE LSP 344 and one or more Path messages for the backup P2MP LSP. 346 Note that, as specified in [RFC4090], the reception of a backup LSP's 347 Path message does not indicate that a failure has occurred or that 348 the incoming protected LSP will no longer be used. 350 A S2L sub-LSP is received within a Path message for the protected 351 P2MP LSP and within a Path message for the backup P2MP LSP. These two 352 Path messages are distinguished thanks to the sender-template 353 specific method. As specified in [RFC4090], each of these Path 354 messages will have a different sender address. The protected LSP can 355 be recognized because it will include the FAST_REROUTE object or have 356 the "local protection desired" flag set in the SESSION_ATTRIBUTE 357 object, or both. 359 A MP MUST maintain one context specific ILM table per PLR or per P2MP 360 bypass tunnel for which it is a leaf. 362 A MP MUST install the upstream assigned label received in a backup 363 LSP's Path message, within an ILM specific to the underlying bypass 364 tunnel, which is identified by its session object, carried within the 365 IF_ID RSVP_HOP object of the backup LSP's Path message. An upstream 366 assigned label for a backup P2MP LSP MUST be mapped to the outgoing 367 interface(s) and label(s) of the corresponding protected P2MP LSP. 369 As specified in [RSVP-UP], the Resv message sent by a MP to the PLR, 370 does not carry any Label Object. 372 The processing of backup S2L sub-LSP SEROs/SRROs MUST follow 373 backup tunnel ERO/RRO processing described in [RFC4090]. 375 6. To be included in future revisions 377 The following items will be included in further revisions of this 378 document: 380 - Combination of P2P and P2MP bypass tunnels to protect a given 381 link/node. This will allow backward compatibility with LSRs 382 that do not support upstream label assignment. 384 - Cases where the PLR is not directly upstream to the protected 385 element. 387 - Partial protection: that is the case where only a subset of 388 Merge Points can be covered. 390 - New RSPV-TE Attribute flags: 392 o A flag in the ATTRIBUTE FLAGS TLV to indicate that 393 protection with P2MP bypass tunnels is desired, and to 394 record such protection. 395 o A flag in the ATTRIBUTE FLAGS TLV to indicate whether 396 partial protection is allowed or not and to record 397 partial protection. 398 o A flag in the ATTRIBUTE FLAGS TLV to indicate that PHP 399 must be deactivated, and to record PHP status (this has 400 a broader scope so this may belong to a dedicated 401 draft). 403 7. Security Considerations 405 No new security issues are raised in this document. 407 8. Acknowledgments 409 We would like to thank Kireeti Kompella and Venu Hemige, for the 410 useful comments and discussions. 412 9. References 414 9.1. Normative references 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture", 420 RFC 3031. 422 [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP 423 Tunnels", RFC3209. 425 [RFC4461] S. Yasukawa et al., "Signaling Requirements for Point-to- 426 Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", 427 RFC4461. 429 [RFC4090] Pan, Swallow, Atlas, et al., "Fast Reroute Extensions to 430 RSVP-TE for LSP Tunnels", RFC4090. 432 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa et al. "Extensions to 433 RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 434 p2mp, work in progress. 436 [MPLS-UPSTREAM] Aggarwal, Rekhter, Rosen, "MPLS Upstream Label 437 Assignment and Context Specific Label Space", draft-ietf-mpls- 438 upstream-label, work in progress. 440 [RSVP-UP] Aggarwal, Le Roux, " MPLS Upstream Label Assignment for 441 RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress. 443 10. Authors' Addresses: 445 Jean-Louis Le Roux 446 France Telecom 447 2, avenue Pierre-Marzin 448 22307 Lannion Cedex 449 FRANCE 450 Email: jeanlouis.leroux@orange-ftgroup.com 452 Rahul Aggarwal 453 Juniper Networks 454 1194 North Mathilda Ave. 455 Sunnyvale, CA 94089 456 USA 457 Email: rahul@juniper.net 459 Jean-Philippe Vasseur 460 Cisco Systems, Inc. 461 1414 Massachusetts avenue 462 Boxborough , MA - 01719 463 USA 464 Email: jpv@cisco.com 466 M. Vigoureux 467 Alcatel-Lucent France 468 Route de Villejust 469 91620 Nozay 470 FRANCE 471 Email: martin.vigoureux@alcatel-lucent.fr 473 11. Intellectual Property Statement 475 The IETF takes no position regarding the validity or scope of any 476 Intellectual Property Rights or other rights that might be claimed to 477 pertain to the implementation or use of the technology described in 478 this document or the extent to which any license under such rights 479 might or might not be available; nor does it represent that it has 480 made any independent effort to identify any such rights. Information 481 on the procedures with respect to rights in RFC documents can be 482 found in BCP 78 and BCP 79. 484 Copies of IPR disclosures made to the IETF Secretariat and any 485 assurances of licenses to be made available, or the result of an 486 attempt made to obtain a general license or permission for the use of 487 such proprietary rights by implementers or users of this 488 specification can be obtained from the IETF on-line IPR repository at 489 http://www.ietf.org/ipr. 491 The IETF invites any interested party to bring to its attention any 492 copyrights, patents or patent applications, or other proprietary 493 rights that may cover technology that may be required to implement 494 this standard. Please address the information to the IETF at 495 ietf-ipr@ietf.org. 497 Disclaimer of Validity 499 This document and the information contained herein are provided 500 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 501 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 502 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 503 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 504 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 505 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 506 FOR A PARTICULAR PURPOSE. 508 Copyright Statement 510 Copyright (C) The IETF Trust (2007). This document is subject to the 511 rights, licenses and restrictions contained in BCP 78, and except as 512 set forth therein, the authors retain all their rights.