idnits 2.17.1 draft-kompella-mpls-entropy-label-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 471. -- 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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-kompella-mpls-entropy-label-01', but the file name used is 'draft-kompella-mpls-entropy-label-00' 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.) -- The draft header indicates that this document updates RFC3031, 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 lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Entropy labels are generated by an ingress LSR, based entirely on load balancing information. However, they MUST not have values in the reserved label space (0-15). Entropy labels MUST be at the bottom of the label stack, and thus the "end-of-stack" bit in the label should be set. To ensure that they are not used inadvertently for forwarding, entropy labels SHOULD have a TTL of 0. (Using the creation date from RFC3031, updated by this document, for RFC5378 checks: 1998-03-17) -- 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 (July 7, 2008) is 5743 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 (-03) exists of draft-bryant-filsfils-fat-pw-01 -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft Juniper Networks 4 Updates: 3031 (if approved) S. Amante 5 Intended status: Standards Track Level 3 Communications, LLC 6 Expires: January 8, 2009 July 7, 2008 8 The Use of Entropy Labels in MPLS Forwarding 9 draft-kompella-mpls-entropy-label-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 8, 2009. 36 Abstract 38 Load balancing is a powerful tool for engineering traffic across a 39 network. This memo suggests ways of improving load balancing across 40 MPLS networks using the notion of "entropy labels". It defines the 41 concept, describes why they are needed, suggests how they can be 42 used, and enumerates properties of entropy labels that allow optimal 43 benefit. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 49 1.2. Conventions used . . . . . . . . . . . . . . . . . . . . . 6 50 2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 7 51 3. Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 8 52 4. Forwarding and Load Balancing Behaviors for Entropy Labels . . 9 53 4.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 9 54 4.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 9 55 4.3. Egress LSRs . . . . . . . . . . . . . . . . . . . . . . . 10 56 5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 11 57 5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 11 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 64 Intellectual Property and Copyright Statements . . . . . . . . . . 16 66 1. Introduction 68 Load balancing, or multi-pathing, is an attempt to balance traffic 69 across a network by allowing the traffic to use several paths, not 70 just a single shortest path. Load balancing has several benefits: it 71 eases capacity planning; it can help absorb traffic surges by 72 spreading them across several links; it allow better resilience by 73 offering alternate paths should a link or node fail. 75 As providers scale their networks, they resort to a small number of 76 techniques to achieve greater bandwidth between nodes and, 77 subsequently, depend on load-balancing of traffic over those paths. 78 Two widely used techniques are: Link Aggregation (LAG) and Equal-Cost 79 Multi-Path (ECMP). LAG is only used to bond together several 80 physical circuits between two adjacent nodes so they appear to 81 higher-layer protocols as a single, higher bandwidth "virtual" pipe. 82 On the other hand, ECMP is used between two nodes, separated by one 83 or more hops, to allow load-sharing over more than just the shortest 84 path in the network -- this is typically obtained by arranging IGP 85 metrics such that there are several equal cost paths between source- 86 destination pairs. In summary, both of these techniques may, and 87 oftentimes do, co-exist in various parts of a given providers 88 network, depending on various choices made by the provider. 90 A very important consideration when load balancing is that packets 91 belonging to a given "flow" MUST be mapped to the same path, i.e., 92 the same exact sequence of links across the network. This is to 93 avoid jitter, latency and re-ordering issues for the flow. However, 94 what constitutes a flow varies considerably. A common example of a 95 flow is a TCP session. Other examples are L2TP sessions 96 corresponding to broadband users, or traffic within an ATM virtual 97 circuit. A flow is usually defined, for the purposes of forwarding 98 and load balancing, by a hash computed on packet headers such that 99 packets belonging to a given flow map to the same hash value. The 100 fields chosen for such a hash depend on the packet type; a typical 101 set (for IP packets) is the IP source and destination address, the 102 protocol type, and (for TCP and UDP traffic) the source and 103 destination port numbers. A conservative choice of fields leads to 104 many flows mapping to the same hash value (and consequently poor load 105 balancing); an overly aggressive choice may map a flow to multiple 106 values, potentially causing the issues mentioned above. 108 For MPLS networks, most of the same principles (and benefits) apply. 109 However, finding useful fields in a packet for the purpose of load 110 balancing can be more of a challenge. In many cases, the extra 111 encapsulation may require fairly deep inspection of packets to find 112 these fields at every hop. An idea for removing the need for this 113 deep inspection is to extract this information *once*, at the ingress 114 of an MPLS Label Switched Path (LSP), and encode, within the label 115 stack itself, in addition to the forwarding semantics of the label 116 stack, the load balancing information. This information can then be 117 used on all MPLS hops across the network. There are three key 118 reasons why this is beneficial: 120 1. at the ingress of the LSP, MPLS encapsulation hasn't yet 121 occurred, so deep inspection is not necessary; 123 2. the ingress of an LSP has more context and information about 124 incoming packets than transit nodes; and 126 3. ingress nodes usually operate at lower bandwidths than transit 127 nodes, allowing them to do more work per packet. 129 This memo describes a few approaches to solving this problem, and 130 focuses on one method, which uses the notion of entropy labels. This 131 memo goes on to define entropy labels, and describes why they are 132 needed, and the properties of entropy labels in the forwarding plane: 133 how they are generated and received and what is expected of transit 134 Label Switching Routers (LSRs). Finally, it describes in general how 135 signaling works and what needs to be signaled, as well as specifics 136 for LDP. 138 1.1. Motivation 140 MPLS is very successful generic forwarding substrate that may 141 transport several dozen types of protocols, most notably: IP, PWE3, 142 VPLS and IP VPN's. Within each type of protocol, there typically 143 exist several variants as it relates to load-sharing, e.g.: IP: IPv4, 144 IPv6, IPv6 in IPv4, etc.; PWE3: Ethernet, ATM, Frame-Relay, etc. 145 There are also several different types of Ethernet over PW 146 encapsulation, ATM over PW encapsulation, etc. as well. Finally, 147 given the popularity of MPLS, it is likely that it will continue to 148 be extended to transport new protocols as the need arises. 150 Currently, each MPLS LSR along a given path needs to individually 151 infer the underlying protocol within a MPLS packet in order to then 152 extract appropriate keys from the payload. Those keys are then used 153 as input into a hash algorithm to determine the specific output 154 interface on a LSR that is used for that given "microflow". 155 Unfortunately, if the MPLS LSR is unable to infer the MPLS packet's 156 payload (as is often the case), they typically will resort to using 157 the topmost MPLS labels in the MPLS stack as keys to the load-hashing 158 algorithm. The result is an extremely inequitable distribution of 159 traffic across multiple equal-cost paths exiting that node, simply 160 because the topmost MPLS labels are very coarse-grained forwarding 161 labels that typically describe a next-hop, or provide some other type 162 of mux/demux forwarding function, and do not describe the granularity 163 of the underlying traffic. 165 On the other hand, ingress MPLS LER's (PE routers) have detailed 166 knowledge of an MPLS packet's contents, typically through a priori 167 configuration of encapsulation(s) that are expected at a given PE-CE 168 interface, (e.g.: IPv4, IPv6, VPLS, etc.). PE routers need this 169 information to: a) discern the packet's CoS forwarding treatment, b) 170 apply filters to forward or block traffic to/from the CE; c) to 171 forward routing/control traffic to an onboard management processor; 172 or, d) load-share the traffic on its uplinks to P routers. By 173 knowing the expected encapsulation types, an ingress PE router could 174 apply a smaller subset of payload parsing routines to extract keys 175 appropriate for the given protocol. Ultimately, this should allow 176 for significantly improved accuracy in determining the appropriate 177 load-balancing behavior for each protocol. 179 In addition, compared to MPLS LSR's, PE routers typically operate at 180 lower forwarding rates as well as have more flexible forwarding 181 hardware. As a result, a PE router can typically adapt much more 182 quickly to new/emerging protocols and determine the appropriate keys 183 used for load-sharing traffic that type of traffic through the 184 network. 186 An additional advantage of applying entropy labels only at the edge 187 of the network, on PE routers, would be that core/transit MPLS LSR's 188 could once again return to being completely oblivious to the contents 189 of each MPLS packet, and only use the outer MPLS labels to determine 190 forwarding and forwarding treatment of MPLS packets. Specifically, 191 there will be no reason to duplicate, from MPLS LER's, extremely 192 complex packet/payload parsing functionality within MPLS LSR's and 193 attempt to keep to keep this functionality at parity across all 194 network elements, e.g.: both MPLS LSR's and LER's. Ultimately, this 195 should result in less complexity within core LSR's allowing them to 196 more easily scale to higher forwarding rates, larger port density, 197 consume less power, etc. Finally, the approach discussed in this 198 memo would allow for more rapid deployment of new protocols, since 199 MPLS LSR's will not have to be developed or modified to understand 200 how to properly extract keys to achieve good load-sharing of traffic 201 throughout the network. 203 In summary, MPLS LSR's are ill-equipped to infer the protocol within 204 a packet's payload and choose appropriate keys within the payload to 205 correctly identify a given "microflow", which is required to provide 206 the most equitable load-sharing over multiple equal cost paths. On 207 the other hand, PE routers have both the knowledge and capabilities 208 to more accurately determine the load-sharing treatment that should 209 be applied to a given protocol encapsulated within MPLS by MPLS 210 LSR's. 212 1.2. Conventions used 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 Labels stacks are denoted , which L1 is the "outermost" 219 label and L3 the innermost (closest to the payload). Packet flows 220 are depicted left to right, and signaling is shown right to left 221 (unless otherwise indicated). 223 2. Approaches 225 There are two main approaches to encoding load balancing information 226 in the label stack. The first allocates multiple labels for a 227 particular Forwarding Equivalance Class (FEC). These labels are 228 equivalent in terms of forwarding semantics, but having several 229 allows flexibility in assigning labels to flows from the same FEC. 230 The other approach encodes the load balancing information as a 231 separate label in the label stack. Here, there are two sub- 232 approaches, based on whether this load-balancing label is signaled or 233 not. 235 The first approach has the advantage that the label stack stays the 236 same depth whether using label-based load balancing or not; and so, 237 consequently, do forwarding operations on transit and egress LSRs. 238 However, it has a major drawback in that signaling and forwarding 239 state are both increased significantly. The number of independent 240 choices for load balancing packets belonging to a FEC limits the 241 effectiveness of load balancing, so one would like this number to be 242 large. However, the larger this number is, the greater the signaling 243 and forwarding state in the network. 245 The second approach increases the size of the label stack by one 246 label. This consequently affects operations on ingress, transit and 247 egress LSRs. The sub-approach of signaling the load-balancing labels 248 increases signaling and forwarding state, and so suffers from some of 249 the problems of the first approach. 251 The approach advocated by this memo, and the only one described in 252 detail, is the one where the load-balancing labels are not signaled. 253 With this approach, there is minimal change to signaling state for a 254 FEC; also, there is no change in forwarding operations in transit 255 LSRs, and no increase of forwarding state in any LSR. The only 256 purpose of these labels is to increase the entropy in the label 257 stack, so they are called "entropy labels". 259 3. Entropy Labels 261 An entropy label (as used here) is a label: 263 1. that is not used for forwarding; 265 2. that is not signaled; and 267 3. whose only purpose in the label stack is to provide "entropy" to 268 improve load balancing. 270 Entropy labels are generated by an ingress LSR, based entirely on 271 load balancing information. However, they MUST not have values in 272 the reserved label space (0-15). Entropy labels MUST be at the 273 bottom of the label stack, and thus the "end-of-stack" bit in the 274 label should be set. To ensure that they are not used inadvertently 275 for forwarding, entropy labels SHOULD have a TTL of 0. 277 Since entropy labels are generated by the ingress LSR, an egress LSR 278 MUST be able to tell unambiguously that a given label is an entropy 279 label. This of course depends on the underlying application. If any 280 ambiguity is possible, the label above the entropy label MUST be an 281 "entropy label indicator" (ELI), which says that the following label 282 is an entropy label. The ELI may be signaled, or may be a reserved 283 label reserved specifically for this purpose. Fortunately, for many 284 applications, the use of entropy labels is unambiguous, and does not 285 need an ELI. 287 Applications for MPLS entropy labels include pseudowires ([RFC4447], 288 [I-D.bryant-filsfils-fat-pw]), Layer 3 VPNs ([RFC4364]), VPLS 289 ([RFC4761], [RFC4762]) and tunnel LSPs. This memo specifies general 290 properties of entropy labels, and the signaling of entropy labels for 291 LDP ([RFC3036]) tunnel LSPs. Other memos will specify the signaling 292 and use of entropy labels for specific applications. 294 4. Forwarding and Load Balancing Behaviors for Entropy Labels 296 4.1. Ingress LSR 298 Suppose that for a particular application (or FEC), an ingress LSR X 299 has to push label stack , where TL is the "tunnel label" and 300 AL is the application label. (Note the use of the convention for 301 label stacks described in Section 1.2. The use of a two-label stack 302 is just for illustrative purposes.) Suppose furthermore that X is to 303 use entropy labels for this application. Thus, the resultant label 304 stack will be , where EL is the entropy label. 306 When a packet for this FEC arrives at X, X must first determine the 307 fields that it will use for load balancing. Typically, X will then 308 generate a hash H over those fields. X will then pick an outgoing 309 label stack to push on the packet. However, X must also 310 generate an entropy label EL (based either directly on the load 311 balancing fields, or on the hash H). EL is a "regular" 32-bit label, 312 encoded in the usual way; however, the EOS bit MUST be 1 and the TTL 313 field MUST be 0. X then pushes on to the packet before 314 forwarding it to the next LSR. If X is told (via signaling) that it 315 must use an entropy label indicator ELI, then X instead pushes on to the packet. 318 Note that ingress LSR X MUST NOT include an entropy label unless the 319 egress LSR for this FEC has indicated that it is ready to receive 320 entropy labels. Furthermore, if the egress LSR has signaled that an 321 ELI is needed, then X MUST include the ELI with the entropy label; 322 otherwise, X MUST NOT use entropy labels. 324 4.2. Transit LSR 326 Transit LSRs have no change in forwarding behavior. For load 327 balancing, transit LSRs SHOULD use the whole label stack (e.g., for 328 computing the load balance hash). Transit LSRs MAY choose to look 329 beyond the label stack for further load balancing information; 330 however, if entropy labels are being used, this may not be very 331 useful. In a mixed environment (or for backward compatibility), this 332 is the simplest approach. 334 Thus, transit LSRs are almost unaffected by the use of entropy 335 labels. If transit LSRs were programmed to use a subset of the label 336 stack, they may have to be reconfigured to use the full stack. But 337 otherwise, no changes are needed. 339 4.3. Egress LSRs 341 An ingress LSR X MUST NOT send entropy labels to an egress LSR Y 342 unless Y has signaled its readiness to receive such labels. Y must 343 also determine (for a particular application or FEC), whether it can 344 distinguish whether the ingress has added an entropy label or not; if 345 Y cannot do so, Y MUST request that an ELI be used for this FEC. 346 Alternatively, Y MUST require the use of entropy labels. (See 347 Section 5 for more details on signaling.) 349 Suppose Y has signaled that it is prepared to receive entropy labels 350 for a given FEC. In this case, Y must be able to distinguish whether 351 an ingress LSR has inserted an entropy label or not based solely on 352 the 'end-of-stack' (EOS) bit on the application label for this FEC. 353 When Y receives a packet with this application label, then Y looks to 354 see if the EOS bit is set. If not, Y assumes that the label below is 355 an entropy label and pops it. Y MAY choose to ensure that the 356 entropy label has its EOS bit set and TTL=0. Y then processes the 357 packet as usual. Implementations may choose to the order in which 358 they apply these operations, but the net result should be as 359 specified. 361 5. Signaling for Entropy Labels 363 Signaling for entropy labels exchanges three types of information: 365 1. whether an LSR Y is prepared to receive entropy labels, or that Y 366 MUST receive entropy labels, 368 2. whether receiving LSR Y requires ELIs with entropy labels, and if 369 so, what label to use as the ELI, and 371 3. whether an LSR X is able to send entropy labels. 373 The uses of this information can be illustrated as follows. If an 374 LSR Y is prepared to receive entropy labels for an application (or 375 FEC), it signals that to the ingress LSR(s). That means that an 376 ingress LSR for this application MAY send an entropy label for this 377 application; Y MUST be able to distinguish whether or not an entropy 378 label was sent based solely on the EOS bit on the application label. 379 If this is not the case, Y can choose one of two approaches. Y can 380 signal that an ELI MUST be used for this FEC; Y may also signal what 381 ELI to use. In this case, an ingress LSR will either not send an 382 entropy label, or push the ELI before the entropy label. This makes 383 the use/non-use of an entropy label unambiguous. However, this also 384 increases the size of the label stack. An alternative approach is 385 that Y signals that entropy labels MUST be used. An ingress LSR MUST 386 acknowledge that it will do so (via signaling); if an ingress LSR 387 cannot do so, the signaling for this application MUST renegotiate to 388 not use entropy labels (or fail). 390 The specific protocols and encoding details for the above will depend 391 on the underlying application; see [I-D.bryant-filsfils-fat-pw] for 392 an example for pseudowires. 394 5.1. LDP Signaling 396 TBD 398 6. Security Considerations 400 Having security is a Good Thing. 402 7. Acknowledgments 404 We wish to thank Ulrich Drafz for his contributions, as well as the 405 entire "hash label" team for their valuable comments and discussion. 407 8. References 409 8.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 8.2. Informative References 416 [I-D.bryant-filsfils-fat-pw] 417 Bryant, S., Filsfils, C., and U. Drafz, "Load Balancing 418 Fat MPLS Pseudowires", draft-bryant-filsfils-fat-pw-01 419 (work in progress), February 2008. 421 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 422 B. Thomas, "LDP Specification", RFC 3036, January 2001. 424 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 425 Networks (VPNs)", RFC 4364, February 2006. 427 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 428 Heron, "Pseudowire Setup and Maintenance Using the Label 429 Distribution Protocol (LDP)", RFC 4447, April 2006. 431 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 432 (VPLS) Using BGP for Auto-Discovery and Signaling", 433 RFC 4761, January 2007. 435 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 436 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 437 RFC 4762, January 2007. 439 Authors' Addresses 441 Kireeti Kompella 442 Juniper Networks 443 1194 N. Mathilda Ave. 444 Sunnyvale, CA 94089 445 US 447 Email: kireeti@juniper.net 449 Shane Amante 450 Level 3 Communications, LLC 451 1025 Eldorado Blvd 452 Broomfield, CO 453 US 455 Email: shane@level3.net 457 Full Copyright Statement 459 Copyright (C) The IETF Trust (2008). 461 This document is subject to the rights, licenses and restrictions 462 contained in BCP 78, and except as set forth therein, the authors 463 retain all their rights. 465 This document and the information contained herein are provided on an 466 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 467 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 468 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 469 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 470 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 471 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 473 Intellectual Property 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.