idnits 2.17.1 draft-ietf-bfd-mpls-06.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 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 512. 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 Copyright Line does not match the current year -- 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 (June 17, 2008) is 5785 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) == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-08 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-08 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-06 -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal 3 Internet Draft Juniper Networks 4 Intended Status: Standards Track 5 Expiration Date: December 17, 2008 K. Kompella 6 Juniper Networks 8 T. Nadeau 9 BT 11 G. Swallow 12 Cisco Systems, Inc. 14 June 17, 2008 16 BFD For MPLS LSPs 18 draft-ietf-bfd-mpls-06.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 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 One desirable application of Bi-directional Forwarding Detection 46 (BFD) is to detect a Multi Protocol Label Switched (MPLS) Label 47 Switched Path (LSP) data plane failure. LSP-Ping is an existing 48 mechanism for detecting MPLS data plane failures and for verifying 49 the MPLS LSP data plane against the control plane. BFD can be used 50 for the former, but not for the latter. However the control plane 51 processing required for BFD control packets is relatively smaller 52 than the processing required for LSP-Ping messages. A combination of 53 LSP-Ping and BFD can be used to provide faster data plane failure 54 detection and/or make it possible to provide such detection on a 55 greater number of LSPs. This document describes the applicability of 56 BFD in relation to LSP-Ping for this application. It also describes 57 procedures for using BFD in this environment. 59 Table of Contents 61 1 Specification of requirements ......................... 3 62 2 Introduction .......................................... 3 63 3 Applicability ......................................... 3 64 3.1 BFD for MPLS LSPs: Motivation ......................... 3 65 3.2 Using BFD in Conjunction with LSP-Ping ................ 5 66 4 Theory of Operation ................................... 6 67 5 Initialization and Demultiplexing ..................... 7 68 6 Session Establishment ................................. 7 69 6.1 BFD Discriminator TLV in LSP-Ping ..................... 8 70 7 Encapsulation ......................................... 8 71 8 Security Considerations ............................... 9 72 9 IANA Considerations ................................... 10 73 10 Acknowledgments ....................................... 10 74 11 References ............................................ 10 75 11.1 Normative References .................................. 10 76 11.2 Informative References ................................ 10 77 12 Author's Address ...................................... 11 78 13 Intellectual Property Statement ....................... 12 79 14 Full Copyright Statement .............................. 12 80 1. Specification of requirements 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Introduction 88 One desirable application of Bi-directional Forwarding Detection 89 (BFD) is to track the liveliness of a Multi Protocol Label Switched 90 (MPLS) Label Switched Path (LSP). In particular BFD can be used to 91 detect a data plane failure in the forwarding path of a MPLS LSP. 92 LSP-Ping [RFC4379] is an existing mechanism for detecting MPLS LSP 93 data plane failures and for verifying the MPLS LSP data plane against 94 the control plane. This document describes the applicability of BFD 95 in relation to LSP-Ping for detecting MPLS LSP data plane failures. 96 It also describes procedures for using BFD for detecting MPLS LSP 97 data plane failures. 99 3. Applicability 101 In the event of a MPLS LSP failing to deliver data traffic, it may 102 not always be possible to detect the failure using the MPLS control 103 plane. For instance the control plane of the MPLS LSP may be 104 functional while the data plane may be mis-forwarding or dropping 105 data. Hence there is a need for a mechanism to detect a data plane 106 failure in the MPLS LSP path [RFC4377]. 108 3.1. BFD for MPLS LSPs: Motivation 110 LSP-Ping described in [RFC4379] is an existing mechanism for 111 detecting a MPLS LSP data plane failure. In addition LSP-Ping also 112 provides a mechanism for verifying the MPLS control plane against the 113 data plane. This is done by ensuring that the LSP is mapped to the 114 same Forwarding Equivalence Class (FEC), at the egress, as the 115 ingress. 117 BFD cannot be used for verifying the MPLS control plane against the 118 data plane. However BFD can be used to detect a data plane failure 119 in the forwarding path of a MPLS LSP. The LSP may be associated with 120 any of the following FECs: 121 a) Resource Reservation Protocol (RSVP) LSP_Tunnel IPv4/IPv6 122 Session [RFC3209] 123 b) Label Distribution Protocol (LDP) IPv4/IPv6 prefix [RFC3036] 124 c) Virtual Private Network (VPN) IPv4/IPv6 prefix [RFC4364] 125 d) Layer 2 VPN [L2-VPN] 126 e) Pseudowires based on PWid FEC and Generalized PWid FEC [RFC4447] 127 f) Border Gateway Protocol (BGP) labeled prefixes [RFC3107] 129 LSP-Ping includes extensive control plane verification. BFD on the 130 other hand was designed as a light-weight means of testing only the 131 data plane. As a result, LSP-Ping is computationally more expensive 132 than BFD for detecting MPLS LSP data plane faults. BFD is also more 133 suitable for being implemented in hardware or firmware due to its 134 fixed packet format. Thus the use of BFD for detecting MPLS LSP data 135 plane faults has the following advantages: 137 a) Support for fault detection for greater number of LSPs. 139 b) Fast detection. Detection with sub-second granularity is 140 considered as fast detection. LSP-Ping is intended to be used in an 141 environment where fault detection messages are exchanged, either for 142 diagnostic purposes or for infrequent periodic fault detection, in 143 the order of tens of seconds or minutes. Hence its not appropriate 144 for fast detection. BFD on the other hand is designed for sub-second 145 fault detection intervals. Following are some potential cases when 146 fast detection may be desirable for MPLS LSPs: 148 1. In the case of a bypass LSP used for facility based link or 149 node protection [RFC4090]. In this case the bypass LSP is essentially 150 being used as an alternate link to protect one or more LSPs. It 151 represents an aggregate and is used to carry data traffic belonging 152 to one or more LSPs, when the link or the node being protected fails. 153 Hence fast failure detection of the bypass LSP may be desirable 154 particularly in the event of link or node failure when the data 155 traffic is moved to the bypass LSP. 157 2. MPLS Pseudo Wires (PW). Fast detection may be desired for MPLS 158 PWs depending on i) the model used to layer the MPLS network with the 159 layer 2 network. and ii) the service that the PW is emulating. For a 160 non-overlay model between the layer 2 network and the MPLS network 161 the provider may rely on PW fault detection to provide service status 162 to the end-systems. Also in that case interworking scenarios such as 163 ATM/Frame Relay interworking may force periodic PW fault detection 164 messages. Depending on the requirements of the service that the MPLS 165 PW is emulating, fast failure detection may be desirable. 167 There may be other potential cases where fast failure detection is 168 desired for MPLS LSPs. 170 3.2. Using BFD in Conjunction with LSP-Ping 172 BFD can be used for MPLS LSP data plane fault detection. However it 173 does not have all the funcitonality of LSP-Ping. In paticular it 174 cannot be used for verifying the control plane against the data 175 plane. LSP Ping performs the following functions that are outside the 176 scope of BFD: 178 a) Association of a LSP-Ping echo request message with a FEC. In 179 the case of Penultimate Hop Popping (PHP) or when the egress LSR 180 distributes an explicit null label to the penultimate hop router, for 181 a single label stack LSP, the only way to associate a fault detection 182 message with a FEC is by carrying the FEC in the message. LSP-Ping 183 provides this functionality. Next-hop label allocation also makes it 184 necessary to carry the FEC in the fault detection message as the 185 label alone is not sufficient to identify the LSP being verified. In 186 addition to this presence of the FEC in the echo request message 187 makes it possible to verify the control plane against the data plane 188 at the egress LSR. 190 b) Equal cost multi-path (ECMP) considerations. LSP-Ping traceroute 191 makes it possible to probe multiple alternate paths for LDP IP FECs. 193 c) Traceroute. LSP-Ping supports traceroute for a FEC and it can be 194 used for fault isolation. 196 Hence BFD is used in conjunction with LSP-Ping for MPLS LSP fault 197 detection: 199 i) LSP-Ping is used for boot-strapping the BFD session as described 200 later in this document. 202 ii) BFD is used to exchange fault detection (i.e. BFD session) 203 packets at the required detection interval. 205 iii) LSP-Ping is used to periodically verify the control plane 206 against the data plane by ensuring that the LSP is mapped to the same 207 FEC, at the egress, as the ingress. 209 4. Theory of Operation 211 To use BFD for fault detection on a MPLS LSP a BFD session MUST be 212 established for that particular MPLS LSP. BFD control packets MUST be 213 sent along the same data path as the LSP being verified and are 214 processed by the BFD processing module of the egress LSR. If the LSP 215 is associated with multiple FECs, a BFD session SHOULD established 216 for each FEC. For instance this may happen in the case of next-hop 217 label allocation. Hence the operation is conceptually similar to the 218 data plane fault detection procedures of LSP-Ping. 220 If MPLS fast-reroute is being used for the MPLS LSP the use of BFD 221 for fault detection can result in false fault detections if the BFD 222 fault detection interval is less than the MPLS fast-reroute 223 switchover time. When MPLS fast-reroute is triggered because of a 224 link or node failure BFD control packets will be dropped until 225 traffic is switched on to the backup LSP. If the time taken to 226 perform the switchover exceeds the BFD fault detection interval a 227 fault will be declared even though the MPLS LSP is being locally 228 repaired. To avoid this the BFD fault detection interval should be 229 greater than the fast-reroute switchover time. An implementation 230 SHOULD provide configuration options to control the BFD fault 231 detection interval. 233 If there are multiple alternate paths from an ingress LSR to an 234 egress LSR for a LDP IP FEC, LSP-Ping traceroute MAY be used to 235 determine each of these alternate paths. A BFD session SHOULD be 236 established for each alternate path that is discovered. 238 Periodic LSP-Ping echo request messages SHOULD be sent by the ingress 239 LSR to the egress LSR along the same data path as the LSP. This is to 240 periodically verify the control plane against the data plane by 241 ensuring that the LSP is mapped to the same FEC, at the egress, as 242 the ingress. The rate of generation of these LSP-Ping echo request 243 messages SHOULD be significantly less than the rate of generation of 244 the BFD control packets. An implemetation MAY provide configuration 245 options to control the rate of generation of the periodic LSP-Ping 246 echo request messages. 248 To enable fault detection procedures specified in this document, for 249 a particular MPLS LSP, this document requires the ingress and egress 250 LSRs to be configured. This includes configuration for supporting BFD 251 and LSP-Ping as specified in this document. It also includes 252 configuration that enables to the ingress LSR to determine the method 253 used by the egress LSR to identify OAM packets e.g. whether the TTL 254 of the innermost MPLS label needs to be set to 1 to enable the egress 255 LSR to identify the OAM packet. For fault detection for MPLS PWs, 256 this document assumes that the PW control channel type [RFC5085], is 257 configured and the support of LSP-Ping is also configured. 259 5. Initialization and Demultiplexing 261 A BFD session may be established for a FEC associated with a MPLS 262 LSP. As desribed above in the case of PHP or when the egress LSR 263 distributes an explicit null label to the penultimate hop router, or 264 next-hop label allocation the BFD control packet received by the 265 egress LSR does not contain sufficient information to associate it 266 with a BFD session. Hence the demultiplexing MUST be done using the 267 remote discriminator field in the received BFD control packet. The 268 exchange of BFD discriminators for this purpose is described in the 269 next section. 271 6. Session Establishment 273 A BFD session is boot-strapped using LSP-Ping. This specification 274 describes procedures only for BFD asynchronous mode. BFD demand mode 275 is outside the scope of this specification. Further the use of the 276 echo function is outside the scope of this specification. The 277 initiation of fault detection for a particular 278 combination results in the exchange of LSP-Ping echo request and echo 279 reply packets, in the ping mode, between the ingress and egress LSRs 280 for that . To establish a BFD session a LSP-Ping echo 281 request message MUST carry the local discriminator assigned by the 282 ingress LSR for the BFD session. This MUST subsequently be used as 283 the My Discriminator field in the BFD session packets sent by the 284 ingress LSR. 286 On receipt of the LSP-Ping echo request message, the egress LSR MUST 287 send a BFD control packet to the ingress LSR, if the validation of 288 the FEC in the LSP-Ping echo request message succeeds. This BFD 289 control packet MUST set the Your Discriminator field to the 290 discriminator received from the ingress LSR in the LSP-Ping echo 291 request message. The egress LSR MAY respond with a LSP-Ping echo 292 reply message that carries the local discriminator assigned by it for 293 the BFD session. The local discriminator assigned by the egress LSR 294 MUST be used as the My Discriminator field in the BFD session packets 295 sent by the egress LSR. 297 The ingress LSR follows the procedures in [BFD] to send BFD control 298 packets to the egress LSR in response to the BFD control packets 299 received from the egress LSR. The BFD control packets from the 300 ingress to the egress LSR MUST set use the local discriminator of the 301 egress LSR, in the Your Discriminator field. The egress LSR 302 demultiplexes the BFD session based on the received Your 303 Discriminator field. As mentioned above the egress LSR MUST send 304 control packets to the ingress LSR with the Your Discriminator field 305 set to the local discriminator of the ingress LSR. The ingress LSR 306 uses this to demultiplex the BFD session. 308 6.1. BFD Discriminator TLV in LSP-Ping 310 LSP-Ping echo request and echo reply messages carry a BFD 311 discriminator TLV for the purpose of session establishment as 312 described above. IANA is requested to assign a type value of 15 to 313 this TLV. This TLV has a length of 4. The value contains the 4 byte 314 local discriminator that the LSR, sending the LSP-Ping message, 315 associates with the BFD session. 317 If the BFD session is not in UP state, the periodic LSP-Ping echo 318 request messages MUST include the BFD discriminator TLV. 320 7. Encapsulation 322 BFD control packets sent by the ingress LSR MUST be encapsulated in 323 the MPLS label stack that corresponds to the FEC for which fault 324 detection is being performed. If the label stack has a depth greater 325 than one, the TTL of the inner MPLS label MAY be set to 1. This may 326 be necessary for certain FECs to enable the egress LSR's control 327 plane to receive the packet [RFC4379]. For MPLS PWs, alternatively, 328 the presence of a fault detection message may be indicated by setting 329 a bit in the control word [RFC5085]. 331 The BFD control packet sent by the ingress LSR MUST be a UDP packet 332 with a well known destination port 3784 [BFD-IP] and a source port 333 assigned by the sender as per the procedures in [BFD-IP]. The source 334 IP address is a routable address of the sender. The destination IP 335 address MUST be randomly chosen from the 127/8 range for IPv4 and 336 from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6 with the following 337 exception. If the FEC is a LDP IP FEC the ingress LSR may discover 338 multiple alternate paths to the egress LSR for this FEC using LSP- 339 ping traceroute. In this case the destination IP address, used in a 340 BFD session established for one such alternate path, is the address 341 in the 127/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 342 discovered by LSP-ping traceroute [RFC4379] to exercise that 343 particular alternate path. 345 The motivation for using the destination address from the 127/8 range 346 is the same as that provided in [RFC4379]. 348 The IP TTL or hop limit MUST be set to 1 [RFC4379]. 350 BFD control packets sent by the egress LSR are UDP packets. The 351 source IP address is a routable address of the replier. 353 The BFD control packet sent by the egress LSR to the ingress LSR MAY 354 be routed based on the destination IP address as per the procedures 355 in [BFD-MHOP]. If this is the case the destination IP address MUST be 356 set to the source IP address of the LSP-Ping echo request message, 357 received by the egress LSR from the ingress LSR. 359 Or the BFD control packet sent by the egress LSR to the ingress LSR 360 MAY be encapsulated in a MPLS label stack. In this case the presence 361 of the fault detection message is indicated as described above. This 362 may be the case if the FEC for which the fault detection is being 363 perfomed corresponds to a bi-directional LSP or a MPLS PW. This may 364 also be the case when there is a return LSP from the egress LSR to 365 the ingress LSR. In this case the destination IP address MUST be 366 randomly chosen from the 127/8 range for IPv4 and from the 367 0:0:0:0:0:FFFF:7F00/104 range for IPv6. 369 The BFD control packet sent by the egress LSR MUST have a well known 370 destination port 4784, if it is routed [BFD-MHOP], or it MUST have a 371 well known destination port 3784 [BFD-IP] if it is encapsulated in a 372 MPLS label stack. The source port MUST be assigned by the egress LSR 373 as per the procedures in [BFD-IP]. 375 Note that once the BFD session for the MPLS LSP is UP, either end of 376 the BFD session MUST NOT change the source IP address and the local 377 discriminator values of the BFD control packets it generates, unless 378 it first brings down the session. This implies that a LSR MUST ignore 379 BFD packets for a given session, that is demultiplexed using the 380 received Your Discriminator field, if the session is in UP state and 381 if the My Discriminator or the Source IP address fields of the 382 received packet do not match the values associated with the session. 384 8. Security Considerations 386 Security considerations discussed in [BFD], [BFD-MHOP] and [RFC4379] 387 apply to this document. For BFD control packets sent by the ingress 388 LSR or when the BFD control packet sent by the egress LSR are 389 encapsulated in a MPLS label stack, MPLS security considerations 390 apply. These are discussed in [MPLS-SEC]. When BFD control packets 391 sent by the egress LSR are routed the authentication considerations 392 discussed in [BFD-MHOP] should be followed. 394 9. IANA Considerations 396 This document introduces a BFD discriminator TLV in LSP-Ping. This 397 has to be assigned from the TLV type registry maintained by IANA. 398 IANA is requested to assign a value of 15 to this TLV. 400 10. Acknowledgments 402 We would like to thank Yakov Rekhter, Dave Katz and Ina Minei for 403 contributing to the discussions that formed the basis of this 404 document and for their comments. Thanks to Dimitri Papadimitriou for 405 his comments and review. Thanks to Carlos Pignataro for his comments 406 and review. 408 11. References 410 11.1. Normative References 412 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 413 Detection", 414 draft-ietf-bfd-base-08.txt. 416 [BFD-IP] D. Katz, D. Ward, "BFD for IPv4 and IPv6 (Single Hop)", 417 draft-ietf-bfd-v4v6-1hop-08.txt 419 [RFC4379] K. Kompella et. al., "Detecting MPLS Data Plane Failures", 420 RFC 4379, February 2006. 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, March 1997. 425 11.2. Informative References 427 [BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths", 428 draft-ietf-bfd-multihop-06.txt 430 [RFC5085] T. Nadeau, C. Pignataro, "Pseudo Wire (PW) Virtual Circuit 431 Connectivity Verification ((VCCV): A Control Channel 432 for Pseudowires", RFC 5085 434 [RFC3209] Awduche, D., et. al, "RSVP-TE: Extensions to RSVP for LSP 435 tunnels", RFC 3209, December 2001. 437 [RFC4090] P. Pan, et. al., "Fast Reroute Extensions to RSVP-TE for 438 LSP Tunnels", May 2005. 440 [RFC3036] Andersson, L., et al, "LDP Specification", RFC 3036. 442 [RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP VPNs", RFC 4364, 443 February 2006. 445 [L2-VPN] K. Kompella, et. al., "Layer 2 VPNs Over Tunnels", 446 draft-kompella-ppvpn-l2vpn-03.txt 448 [RFC4447] L. Martini et. al.,"Pseudowire Setup and Maintenance 449 using LDP", RFC 4447, April 2006. 451 [RFC3107] Y. Rekhter, E. Rosen, "Carrying Label Information in 452 BGP-4", 453 RFC 3107, May 2001 455 [RFC4377] Nadeau, T., et. al, "OAM Requirements for MPLS 456 Networks", RFC 4377, February 2006. 458 [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS 459 Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-02.txt 461 12. Author's Address 463 Rahul Aggarwal 464 Juniper Networks 465 1194 North Mathilda Ave. 466 Sunnyvale, CA 94089 467 Email: rahul@juniper.net 469 Kireeti Kompella 470 Juniper Networks 471 1194 North Mathilda Ave. 472 Sunnyvale, CA 94089 473 Email: kireeti@juniper.net 475 Thomas D. Nadeau 476 BT 477 BT Centre 478 81 Newgate Street 479 EC1A 7AJ 480 London 481 Email: tom.nadeau@bt.com 483 George Swallow 484 Cisco Systems, Inc. 485 300 Beaver Brook Road 486 Boxborough , MA - 01719 487 USA 488 Email: swallow@cisco.com 490 13. Intellectual Property Statement 492 The IETF takes no position regarding the validity or scope of any 493 Intellectual Property Rights or other rights that might be claimed to 494 pertain to the implementation or use of the technology described in 495 this document or the extent to which any license under such rights 496 might or might not be available; nor does it represent that it has 497 made any independent effort to identify any such rights. Information 498 on the procedures with respect to rights in RFC documents can be 499 found in BCP 78 and BCP 79. 501 Copies of IPR disclosures made to the IETF Secretariat and any 502 assurances of licenses to be made available, or the result of an 503 attempt made to obtain a general license or permission for the use of 504 such proprietary rights by implementers or users of this 505 specification can be obtained from the IETF on-line IPR repository at 506 http://www.ietf.org/ipr. 508 The IETF invites any interested party to bring to its attention any 509 copyrights, patents or patent applications, or other proprietary 510 rights that may cover technology that may be required to implement 511 this standard. Please address the information to the IETF at ietf- 512 ipr@ietf.org. 514 14. Full Copyright Statement 516 Copyright (C) The IETF Trust (2008). This document is subject to the 517 rights, licenses and restrictions contained in BCP 78, and except as 518 set forth therein, the authors retain all their rights. 520 This document and the information contained herein are provided on an 521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 523 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 524 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 525 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE,