idnits 2.17.1 draft-ietf-bfd-mpls-07.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 529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 515. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1122, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC1122, updated by this document, for RFC5378 checks: 1989-10-01) -- 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 20, 2008) is 5781 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 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 Updates: 1122 K. Kompella 6 Expiration Date: December 17, 2008 Juniper Networks 8 T. Nadeau 9 BT 11 G. Swallow 12 Cisco Systems, Inc. 14 June 20, 2008 16 BFD For MPLS LSPs 18 draft-ietf-bfd-mpls-07.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 [RFC5036] 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 address range 127/8 is the same as 346 specified in section 2.1 of [RFC4379]. This is an exception to the 347 behavior defined in [RFC1122]. 349 The IP TTL or hop limit MUST be set to 1 [RFC4379]. 351 BFD control packets sent by the egress LSR are UDP packets. The 352 source IP address is a routable address of the replier. 354 The BFD control packet sent by the egress LSR to the ingress LSR MAY 355 be routed based on the destination IP address as per the procedures 356 in [BFD-MHOP]. If this is the case the destination IP address MUST be 357 set to the source IP address of the LSP-Ping echo request message, 358 received by the egress LSR from the ingress LSR. 360 Or the BFD control packet sent by the egress LSR to the ingress LSR 361 MAY be encapsulated in a MPLS label stack. In this case the presence 362 of the fault detection message is indicated as described above. This 363 may be the case if the FEC for which the fault detection is being 364 perfomed corresponds to a bi-directional LSP or a MPLS PW. This may 365 also be the case when there is a return LSP from the egress LSR to 366 the ingress LSR. In this case the destination IP address MUST be 367 randomly chosen from the 127/8 range for IPv4 and from the 368 0:0:0:0:0:FFFF:7F00/104 range for IPv6. 370 The BFD control packet sent by the egress LSR MUST have a well known 371 destination port 4784, if it is routed [BFD-MHOP], or it MUST have a 372 well known destination port 3784 [BFD-IP] if it is encapsulated in a 373 MPLS label stack. The source port MUST be assigned by the egress LSR 374 as per the procedures in [BFD-IP]. 376 Note that once the BFD session for the MPLS LSP is UP, either end of 377 the BFD session MUST NOT change the source IP address and the local 378 discriminator values of the BFD control packets it generates, unless 379 it first brings down the session. This implies that a LSR MUST ignore 380 BFD packets for a given session, that is demultiplexed using the 381 received Your Discriminator field, if the session is in UP state and 382 if the My Discriminator or the Source IP address fields of the 383 received packet do not match the values associated with the session. 385 8. Security Considerations 387 Security considerations discussed in [BFD], [BFD-MHOP] and [RFC4379] 388 apply to this document. For BFD control packets sent by the ingress 389 LSR or when the BFD control packet sent by the egress LSR are 390 encapsulated in a MPLS label stack, MPLS security considerations 391 apply. These are discussed in [MPLS-SEC]. When BFD control packets 392 sent by the egress LSR are routed the authentication considerations 393 discussed in [BFD-MHOP] should be followed. 395 9. IANA Considerations 397 This document introduces a BFD discriminator TLV in LSP-Ping. This 398 has to be assigned from the TLV type registry maintained by IANA. 399 IANA is requested to assign a value of 15 to this TLV. 401 10. Acknowledgments 403 We would like to thank Yakov Rekhter, Dave Katz and Ina Minei for 404 contributing to the discussions that formed the basis of this 405 document and for their comments. Thanks to Dimitri Papadimitriou for 406 his comments and review. Thanks to Carlos Pignataro for his comments 407 and review. 409 11. References 411 11.1. Normative References 413 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 414 Detection", 415 draft-ietf-bfd-base-08.txt. 417 [BFD-IP] D. Katz, D. Ward, "BFD for IPv4 and IPv6 (Single Hop)", 418 draft-ietf-bfd-v4v6-1hop-08.txt 420 [RFC4379] K. Kompella et. al., "Detecting MPLS Data Plane Failures", 421 RFC 4379, February 2006. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC1122] Braden, R., "Requirements for Internet Hosts - 427 Communication Layers", STD 3, RFC 1122, October 1989. 429 11.2. Informative References 431 [BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths", 432 draft-ietf-bfd-multihop-06.txt 434 [RFC5085] T. Nadeau, C. Pignataro, "Pseudo Wire (PW) Virtual Circuit 435 Connectivity Verification ((VCCV): A Control Channel 436 for Pseudowires", RFC 5085 438 [RFC3209] Awduche, D., et. al, "RSVP-TE: Extensions to RSVP for LSP 439 tunnels", RFC 3209, December 2001. 441 [RFC4090] P. Pan, et. al., "Fast Reroute Extensions to RSVP-TE for 442 LSP Tunnels", May 2005. 444 [RFC5036] Andersson, L., et al, "LDP Specification", RFC 5036. 446 [RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP VPNs", RFC 4364, 447 February 2006. 449 [L2-VPN] K. Kompella, et. al., "Layer 2 VPNs Over Tunnels", 450 draft-kompella-ppvpn-l2vpn-03.txt 452 [RFC4447] L. Martini et. al.,"Pseudowire Setup and Maintenance 453 using LDP", RFC 4447, April 2006. 455 [RFC3107] Y. Rekhter, E. Rosen, "Carrying Label Information in 456 BGP-4", 457 RFC 3107, May 2001 459 [RFC4377] Nadeau, T., et. al, "OAM Requirements for MPLS 460 Networks", RFC 4377, February 2006. 462 [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS 463 Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-02.txt 465 12. Author's Address 467 Rahul Aggarwal 468 Juniper Networks 469 1194 North Mathilda Ave. 470 Sunnyvale, CA 94089 471 Email: rahul@juniper.net 473 Kireeti Kompella 474 Juniper Networks 475 1194 North Mathilda Ave. 476 Sunnyvale, CA 94089 477 Email: kireeti@juniper.net 479 Thomas D. Nadeau 480 BT 481 BT Centre 482 81 Newgate Street 483 EC1A 7AJ 484 London 485 Email: tom.nadeau@bt.com 486 George Swallow 487 Cisco Systems, Inc. 488 300 Beaver Brook Road 489 Boxborough , MA - 01719 490 USA 491 Email: swallow@cisco.com 493 13. Intellectual Property Statement 495 The IETF takes no position regarding the validity or scope of any 496 Intellectual Property Rights or other rights that might be claimed to 497 pertain to the implementation or use of the technology described in 498 this document or the extent to which any license under such rights 499 might or might not be available; nor does it represent that it has 500 made any independent effort to identify any such rights. Information 501 on the procedures with respect to rights in RFC documents can be 502 found in BCP 78 and BCP 79. 504 Copies of IPR disclosures made to the IETF Secretariat and any 505 assurances of licenses to be made available, or the result of an 506 attempt made to obtain a general license or permission for the use of 507 such proprietary rights by implementers or users of this 508 specification can be obtained from the IETF on-line IPR repository at 509 http://www.ietf.org/ipr. 511 The IETF invites any interested party to bring to its attention any 512 copyrights, patents or patent applications, or other proprietary 513 rights that may cover technology that may be required to implement 514 this standard. Please address the information to the IETF at ietf- 515 ipr@ietf.org. 517 14. Full Copyright Statement 519 Copyright (C) The IETF Trust (2008). This document is subject to the 520 rights, licenses and restrictions contained in BCP 78, and except as 521 set forth therein, the authors retain all their rights. 523 This document and the information contained herein are provided on an 524 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 525 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 526 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 527 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 528 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 529 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE,