idnits 2.17.1 draft-wood-dna-link-properties-advertisement-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 489. 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 (July 14, 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4938 (Obsoleted by RFC 5578) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Wood 3 Internet-Draft R. Asati 4 Intended status: Experimental D. Floreani 5 Expires: January 15, 2009 Cisco Systems 6 July 14, 2008 8 Link properties advertisement from modem to router 9 draft-wood-dna-link-properties-advertisement-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 15, 2009. 36 Abstract 38 Routers are increasingly connected to a variety of smart modems. 39 Such a modem's incoming and outgoing link rates can be varied over 40 time with adaptive coding and modulation to suit the channel 41 characteristics. The link rate and conditions offered by the modem 42 to connected devices therefore vary. For connected devices to 43 condition traffic and get the most out of the modem's link capacity, 44 they need to know the modem's link conditions. This document 45 describes one simple method for the modem to advertise link rate and 46 other characteristics, via UDP messages, and discusses alternative 47 approaches to communicating this information. 49 Table of Contents 51 1. Background and Introduction . . . . . . . . . . . . . . . . . 3 52 2. UDP messages providing link notifications . . . . . . . . . . 3 53 3. Other possible blocks . . . . . . . . . . . . . . . . . . . . 6 54 4. Router use of these notifications . . . . . . . . . . . . . . 7 55 5. Other approaches to the problem . . . . . . . . . . . . . . . 7 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Intellectual Property and Copyright Statements . . . . . . . . . . 12 65 1. Background and Introduction 67 Consider a wireless modem connected to a router. The modem and 68 router are connected via high-speed Ethernet, because Ethernet 69 interfaces are plentiful and cheap. The router needs to know the 70 link rate offered by the modem in order to set QoS and shaping 71 usefully for that link; simply sending 10/100Mbps traffic to the 72 modem and having the modem drop most of that traffic is not optimal. 74 It is possible to configure QoS and shaping on the router's Ethernet 75 interface to match the modem's link rate, effectively extending the 76 modem's link an extra hop to the router. However, such a static 77 configuration is only useful if the modem's link rate is also static. 78 Many modern modems are able to vary their communications according to 79 the channel characteristics they experience, or due to negotiation 80 with the modem at the other end of the link. Examples include the 81 Adaptive Coding and Modulation (ACM) and Variable Coding and 82 Modulation (VCM) used in DVB-S2, and ADSL2's Seamless Rate Adaptation 83 (SRA). Link characteristics may also vary due to layer-2 handovers, 84 e.g. IEEE 802.21 media-independent handoffs. 86 The router needs to learn about changes in modem link characteristics 87 in order to vary its QoS and shaping configurations to match the 88 current characteristics and get the most from the modem's link. The 89 aim is to make the link between router and modem behave as an 90 extension of the modem's own link. 92 The simplest approach to this problem, taken by this draft, is to 93 have the modem advertise its link conditions on its other local 94 interfaces. We describe using UDP packets [RFC0768] sent to link- 95 local multicast addresses to do this. This requires no explicit 96 configuration setup to communicate with connected routers. UDP is 97 well-understood and widely available, making deployment relatively 98 easy for all types of modem and router. 100 Updates are sent periodically or as notifications of link-layer 101 events when they happen. This falls into the scope of DNA [Detecting 102 Network Attachment] processes [RFC4957]. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119. [RFC2119] 108 2. UDP messages providing link notifications 110 The modem sends UDP updates, about changing link and interface 111 conditions, to connected routers, i.e. a link rate changes due to a 112 coding change, or the link and its interface go up or down. 114 As well as sending on event-triggered updates, the modem SHOULD send 115 periodic advertisements about link conditions, in case new router 116 devices have been connected on e.g. a broadcast Ethernet LAN. These 117 updates are sent over both IPv4 and IPv6. 119 This packet can include multiple Blocks containing different 120 information, where each Block is structured as a Type/Length/Data 121 field. This document defines a single Rate Block which has multiple 122 Link Instance sub-block sections for each input or output interface, 123 each identifying the input or output link interface, and describing 124 the link capacity available (current/maximum/minimum rates in bps). 125 The diagram below shows an example Rate Block with a single 126 (Incoming) Link Instance. If a modem is both IPv4- and IPv6-capable 127 over its link to the router, this information should be repeated in 128 IPv4 and IPv6 packets received by the router. 130 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 131 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | UDP source port | UDP destination port | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | UDP length | UDP checksum | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Rate Type Block ID (1) | Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 + no. of links | link rate size| modem flags (15 bits unused)|S| 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 + unique modem interface identifier | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 + interface flags (28 bits unused) |4|6|U|I| 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | current link rate (varies) - 32 bits is rate size of 1 | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | minimum supported rate - 32 bits is rate size of 1 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | maximum supported rate - 32 bits is rate size of 1 | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | IPv4 address of modem's local link interface, if 4 flag set | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | | 154 | IPv6 address of modem's local link interface, if 6 flag set | 155 | | 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 The following fields are defined in this packet's Rate Block: 160 +------------+------------------------------------------------------+ 161 | Name | Value | 162 +------------+------------------------------------------------------+ 163 | Type Block | 1 for Rate Blocks. Permits future definition of | 164 | ID | other Blocks conveying different types of | 165 | | information. | 166 | Length | Length of the Block data, until the next Block or | 167 | | end of packet. | 168 | no. of | total number of input or output interface sub-blocks | 169 | links | listed in this Rate Block. | 170 | link rate | The number of 32-bit words used for bps rate fields. | 171 | size | A value of 1 equates to 32 bits, which can describe | 172 | | rates up to 4Gibps, and is sufficient for most | 173 | | current modems. This is the first item in the Rate | 174 | | Block's Value data. | 175 | modem | Flags that can describe properties of the modem. | 176 | flags | Unused flag fields MUST be set to zero. One bit is | 177 | | currently in use. | 178 | S/A flag | indicates whether the Rate Block contains fields | 179 | | describing Some modem interfaces (flag set to 1), or | 180 | | All modem interfaces (0). Periodic messages SHOULD | 181 | | describe All interfaces. Updates triggered by an | 182 | | event on an interface, e.g. a link going down, where | 183 | | nothing else has changed, would be a Some update | 184 | | describing only that interface. If a complex modem | 185 | | contains so many interfaces that MTU would be | 186 | | exceeded by a single Rate Block, multiple packets | 187 | | are sent with separate Rate Blocks with the Some | 188 | | flag set. | 189 | unique | Identifies the modem's local incoming or outgoing | 190 | modem | link interface to disambiguate it from other links | 191 | interface | offered by the modem. | 192 | identifier | | 193 | interface | A 32-bit field with flags describing each individual | 194 | flags | link. Unused flag bits MUST be set to zero. Four | 195 | | bits are currently in use. | 196 | IPv4 flag | If set, an IPv4 address for the interface is | 197 | | appended to the description. | 198 | IPv6 flag | If set, an IPv6 address for the interface is | 199 | | appended to the description. | 200 | U/D flag | Indicates whether the link interface is currently Up | 201 | | or Down, i.e. accepting traffic (up, value 1), or | 202 | | not (down, value 0). | 203 | I/O flag | Indicates whether the rate information given for the | 204 | | interface describes the incoming rate to the modem | 205 | | (and router) or the outgoing rate from the modem | 206 | | (and router) over the modem's link to the remote | 207 | | modem. Describing outgoing rates is most likely to | 208 | | be useful for shaping traffic to be passed to the | 209 | | modem. Incoming is 1, Outgoing is 0. | 210 | Current | current offered link capacity in bps. When the link | 211 | link rate | rate size is 1 this is a 32-bit word indicating the | 212 | | range 0-4 Gibps. | 213 | Min rate | minimum supported link capacity in bps, specified as | 214 | | the current link rate is. | 215 | Max rate | maximum supported link capacity in bps, specified as | 216 | | the current link rate is. | 217 | IPv4 | IPv4 address of modem, if present as indicated by | 218 | address | the IPv4 flag. | 219 | IPv6 | IPv6 address of modem, if present as indicated by | 220 | address | the IPv6 flag. | 221 +------------+------------------------------------------------------+ 223 A bidirectional link on the modem will have incoming and outgoing 224 interfaces that MUST share the same local identifier, and SHOULD 225 share the same local IP address. These interfaces are identified in 226 separate sub-blocks with the I/O flag set appropriately, so that any 227 asymmetry can be described properly. This means that the common 228 interface identifier would be repeated for each sub-block, where one 229 sub-block describes describes Incoming information, and the other 230 Outgoing information. If a link is down, the D flag is taken as 231 'zero bit rate' and the 'current' rate indicates the last rate before 232 the modem took the link down. If the minimum and maximum rates are 233 set to zero, this indicates a fixed-speed link whose rate ia never 234 altered. An interface does not have to have any IP address. 236 3. Other possible blocks 238 Other possible blocks, not yet defined here, could express measured 239 error rate, current forward error-coding rate, latency (propagation 240 delay, serialisation delay), link MTU size, indicate link-level 241 security mechanisms in use, or provide authentication. 243 The resource and relative link quality metrics defined in [RFC4938] 244 may also be of use. Unlike [RFC4938], we deliberately define link 245 capacity in exact bps rather than degraded approximate kbps, knowing 246 that for very-low-rate modems, the exact bit rate matters for e.g. 247 call admission control. The lowest link rate that we have 248 encountered is 75bps for submarine applications. 250 4. Router use of these notifications 252 The router MUST be able to receive these UDP/IP packets sent to the 253 "all routers" multicast address. Information from this message is 254 used to construct or update the QoS and shaping policies applied on 255 the interface for traffic directed to the leads to the modem's link. 257 The router MAY use this information to update its routing table so 258 that the routing information associated with a route through the 259 modem is either deleted or added or updated with a new metric. 260 Changes in routing table information are then propagated further. 262 The modem MAY damp changes to Link Instance information, to prevent 263 advertising transient changes, in line with [RFC4907]. The router 264 MAY also damp responses to frequent changes in Link Instance 265 information received, so that related QoS policies and routing 266 information are not updated until a certain time period has elapsed. 267 This would be useful in the case of a rapidly-varying link rate, 268 where the router would stick to the minimum rate seen. 270 The router may also use this information as input to e.g. Call 271 Admission Control (CAC) functionality to reserve capacity for calls. 272 This can deny registered applications such as telephony call setup 273 etc. in the event of less-than-desired available link capacity 274 through the modem's interface. 276 5. Other approaches to the problem 278 The simplest approach to this problem is to have a fixed serial 279 interface between modem and router, with the modem altering the 280 serial rate clock to match the speed of its link, and the router 281 measuring the rate of the received clock. However, fast serial 282 interfaces are unfashionable, and Ethernet now dominates the world. 284 We considered using ICMP [RFC0792] [RFC4443] to provide this rate 285 information, using the framework for carrying extended information in 286 ICMP messages [RFC4884]. However, this extended information can only 287 be carried in Destination Unreachable and Time Exceeded ICMP messages 288 (for both IPv4 and IPv6) and Parameter Problem (for IPv4 only) ICMP 289 messages. These messages are responses to specific problems, and 290 should not be overloaded for general advertisements. The appropriate 291 ICMP message type would be the obsolete Information Request messge 292 (type 15), though requests are also sent unsolicited in this use. 293 Another factor in preferring UDP over ICMP is that sockets 294 programming for UDP is easier than for ICMP, easing implementation. 296 Other approaches to this problem have been proposed. 298 The authors have outlined an approach leveraging the Access Node 299 Control Protocol, used in the head-ends of DSL networks, within 300 DSLAMs [I-D.floreani-ancp-wireless]. However, ANCP is not 301 lightweight, and depends on GSMP, which depends on TCP. The ANCP 302 workgroup is currently focused on the DSL headend, and has yet to 303 extend beyond that environment, while this proposal is also useful at 304 the tail-end in customer networks. 306 Another approach aimed at improving communication between modems and 307 routers is outlined in [RFC4938] and [I-D.bberry-rfc4938bis]. That 308 approach assumes a PPPoE infrastructure. PPPoE is not always 309 architecturally suitable to network needs, and requiring a global 310 PPPoE infrastructure and introducing authentication dependencies for 311 what was just a simple local modem-router problem is overkill. That 312 approach may be suitable as an upgrade to existing PPPoE 313 environments. Adoption of the metrics described in [RFC4938] but 314 with communication separate from PPPoE could be very useful for a 315 wider market, and would provide more information than the link rate 316 information outlined in this draft. 318 Ethernet pause frames have also been suggested as one way of slowing 319 the Ethernet link to match the modem's link a hop further along 320 [GePause2004]. This approach has the disadvantage of being tied to a 321 particular layer-2 technology, while fine-tuning the pause frames to 322 match the modem's offered link rate has the potential to introduce 323 complex control loops and problems as the paused Ethernet rate 324 approximates the modem link rate and interacts with QoS and shaping 325 delay mechanisms on the router. 327 DHCP is intended for address configuration of hosts, so is not 328 considered suitable as a way of piggybacking this information. 330 6. Security Considerations 332 Link instance advertisements should only be local to connecting 333 devices, and should not be propagated further. 335 As packets are sent only to link-local multicast addresses, TTL 336 safeguards such as GTSM [RFC5082], which sets TTL to a hard-to-spoof 337 255, should be unnecessary. Deliberately setting a large TTL on any 338 multicast packet would be unwise if it were to be propagated further. 340 The decision to use this information more broadly feeds into routing 341 metric updates and policy decisions there; taking the information 342 beyond immediately-connected links becomes a routing problem, and has 343 not been described here. 345 Some form of authentication of the modem sender is required to 346 prevent spoofing from other local devices. It should be possible to 347 configure the UDP port number used by the router and modem, to avoid 348 attacks on a well-known port assigned by IANA. 350 7. IANA Considerations 352 IANA must allocate a UDP port for use. 354 Packets are sent to the well-known link-local "all routers" multicast 355 addresses (224.0.0.2 and ff02::2). No further addresses are needed. 357 8. Acknowledgements 359 We thank our colleagues at Cisco Systems for vigorous discussion on 360 this topic. 362 (We briefly considered calling this UDP message format Modem To 363 Router Link Advertisement, or MoToRoLA, but thought better of it. 364 Suggestions for a better name are welcome.) 366 9. References 368 9.1. Normative References 370 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 371 August 1980. 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 9.2. Informative References 378 [GePause2004] 379 Ge, A. and G. Chiruvolu, "Diffserv Compatible Extended 380 Pause (DiffPause) for Fair Congestion Control in Metro- 381 Ethernet", IEEE International Conference on 382 Communications, vol. 2 pp. 1248-1252 , June 2004. 384 [I-D.bberry-rfc4938bis] 385 Berry, B., Ratliff, S., Paradise, E., Kaiser, T., and M. 386 Adams, "PPP Over Ethernet (PPPoE) Extensions for Credit 387 Flow and Link Metrics", draft-bberry-rfc4938bis-00 (work 388 in progress), April 2008. 390 [I-D.floreani-ancp-wireless] 391 Floreani, D. and L. Wood, "Extension of ANCP for Satellite 392 and Terrestrial Wireless Modem Networks", 393 draft-floreani-ancp-wireless-00 (work in progress), 394 June 2007. 396 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 397 RFC 792, September 1981. 399 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 400 Message Protocol (ICMPv6) for the Internet Protocol 401 Version 6 (IPv6) Specification", RFC 4443, March 2006. 403 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 404 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 405 April 2007. 407 [RFC4907] Aboba, B., "Architectural Implications of Link 408 Indications", RFC 4907, June 2007. 410 [RFC4938] Berry, B. and H. Holgate, "PPP Over Ethernet (PPPoE) 411 Extensions for Credit Flow and Link Metrics", RFC 4938, 412 June 2007. 414 [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., 415 and A. Yegin, "Link-Layer Event Notifications for 416 Detecting Network Attachments", RFC 4957, August 2007. 418 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 419 Pignataro, "The Generalized TTL Security Mechanism 420 (GTSM)", RFC 5082, October 2007. 422 Authors' Addresses 424 Lloyd Wood 425 Cisco Systems 426 11 New Square Park, Bedfont Lakes 427 Feltham, Middlesex TW14 8HA 428 United Kingdom 430 Phone: +44-20-8824-4236 431 Email: lwood@cisco.com 432 Rajiv Asati 433 Cisco Systems 434 7025-6 Kit Creek Road 435 Research Triangle Park, North Carolina 27709-4987 436 United States 438 Phone: +1 919 392 8558 439 Email: rajiva@cisco.com 441 Daniel Floreani 442 Cisco Systems 443 Westpac House 444 91 King William Street 445 Adelaide, South Australia 5000 446 Australia 448 Phone: +61 8 8124 2206 449 Email: danielf@cisco.com 451 Full Copyright Statement 453 Copyright (C) The IETF Trust (2008). 455 This document is subject to the rights, licenses and restrictions 456 contained in BCP 78, and except as set forth therein, the authors 457 retain all their rights. 459 This document and the information contained herein are provided on an 460 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 461 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 462 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 463 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 464 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 465 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 467 Intellectual Property 469 The IETF takes no position regarding the validity or scope of any 470 Intellectual Property Rights or other rights that might be claimed to 471 pertain to the implementation or use of the technology described in 472 this document or the extent to which any license under such rights 473 might or might not be available; nor does it represent that it has 474 made any independent effort to identify any such rights. Information 475 on the procedures with respect to rights in RFC documents can be 476 found in BCP 78 and BCP 79. 478 Copies of IPR disclosures made to the IETF Secretariat and any 479 assurances of licenses to be made available, or the result of an 480 attempt made to obtain a general license or permission for the use of 481 such proprietary rights by implementers or users of this 482 specification can be obtained from the IETF on-line IPR repository at 483 http://www.ietf.org/ipr. 485 The IETF invites any interested party to bring to its attention any 486 copyrights, patents or patent applications, or other proprietary 487 rights that may cover technology that may be required to implement 488 this standard. Please address the information to the IETF at 489 ietf-ipr@ietf.org.