idnits 2.17.1 draft-ietf-manet-jitter-04.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 538. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 4, 2007) is 5980 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-manet-packetbb-11 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique, France 4 Intended status: Informational C. Dearlove 5 Expires: June 6, 2008 BAE Systems Advanced Technology 6 Centre 7 B. Adamson 8 U.S. Naval Research Laboratory 9 December 4, 2007 11 Jitter considerations in Mobile Ad Hoc Networks (MANETs) 12 draft-ietf-manet-jitter-04 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 6, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document provides recommendations for jittering (randomly 46 modifying timing) of control traffic transmissions in Mobile Ad hoc 47 NETwork (MANET) routing protocols to reduce the probability of 48 transmission collisions. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 55 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 7 56 5. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 5.1. Periodic Message Generation . . . . . . . . . . . . . . . 8 58 5.2. Externally-Triggered Message Generation . . . . . . . . . 9 59 5.3. Message Forwarding . . . . . . . . . . . . . . . . . . . . 10 60 5.4. Maximum Jitter Determination . . . . . . . . . . . . . . . 11 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 68 Intellectual Property and Copyright Statements . . . . . . . . . . 18 70 1. Introduction 72 In a wireless network, simultaneous packet transmission by nearby 73 nodes is often undesirable. This is because any resulting collision 74 between these packets may cause a receiving node to fail to receive 75 some or all of these packets. This is a physical problem, which 76 occurs before packets can be inserted into the receiver queue. 77 Depending on the characteristics of the medium access control and 78 other lower layer mechanisms, in particular whether retransmission of 79 unacknowledged packets is supported, this may cause at best increased 80 delay, and at worst complete packet loss. In some instances these 81 problems can be solved in these lower layers, but in other instances 82 some help at the network and higher layers is necessary. 84 This document considers the case when that help is required, and 85 provides recommendations for using jitter (randomly varying timing) 86 to provide it. It is possible that the techniques described here 87 could be implemented either by IP protocols designed for wireless 88 networks or in conjunction with lower-layer mechanisms. 90 The problems of simultaneous packet transmissions are amplified if 91 any of the following features are present in a protocol: 93 Regularly scheduled messages - If two nodes generate packets 94 containing regularly scheduled messages of the same type at the 95 same time, and if, as is typical, they are using the same message 96 interval, all further transmissions of these messages will thus 97 also be at the same time. Note that the following mechanisms may 98 make this a likely occurrence. 100 Event-triggered messages - If nodes respond to changes in their 101 circumstances, in particular changes in their neighborhood, with 102 an immediate message generation and transmission, then two nearby 103 nodes which respond to the same change will transmit messages 104 simultaneously. 106 Schedule reset - When a node sends an event-triggered message of a 107 type which is usually regularly scheduled, then there is no 108 apparent reason why it should not restart its corresponding 109 message schedule. This may result in nodes responding to the same 110 change also sending future messages simultaneously. 112 Forwarding - If nodes forward messages they receive from other 113 nodes, then nearby nodes will commonly receive and forward the 114 same message. If forwarding is performed immediately then the 115 resulting packet transmissions may interfere with each other. 117 A possible solution to these problems is to employ jitter, a 118 deliberate random variation in timing. Such jitter is employed in 119 e.g. [2], [3] and [4], in which transmission intervals for regularly 120 scheduled messages are reduced by a small, bounded and random amount 121 in order to desynchronize transmitters and thereby avoid overloading 122 the transmission medium as well as receivers. This document 123 discusses and provides recommendations for applying jitter to control 124 packet transmissions in Mobile Ad hoc NETworks (MANETs), with the 125 purpose of avoiding collisions, with particular reference to the 126 features listed above. 128 2. Terminology 130 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC2119 [1]. 134 Additionally, this document uses the following terminology: 136 Node - A MANET router which implements a message sending protocol. 138 MANET interface - A network device participating in a MANET. A node 139 may have one or more MANET interfaces. 141 Message - An entity carrying protocol information intended for 142 exchange between nodes. Messages are transmitted over MANET 143 interfaces embedded in packets. 145 Packet - An entity embedding zero or more messages for transmission 146 over a MANET interface of the node. 148 Transmission - A packet being sent over a MANET interface of the 149 node. A transmission can be due to either a message being 150 generated or a message being forwarded. 152 Generation - Creation of a new message (rather than a received and 153 forwarded message) for transmission over one or more MANET 154 interfaces of the node. Typically, a node will generate messages 155 based on a message schedule (periodic or otherwise) or as a 156 response to changes in circumstances. 158 Forwarding - Retransmission of a received message (whether modified 159 or unchanged) over one or more MANET interfaces of the node. 161 Collision - A specific instance of interference, where two or more 162 nodes transmit a packet at the same time and within the same 163 signal space (at the same frequency and/or encoding) such that 164 another, closely located, node which should receive and decode 165 these packets instead fails to do so, and loses one or more of the 166 packets. 168 3. Applicability Statement 170 The mechanisms described in this document are applicable to the 171 control messages of any MANET protocol in which simultaneous 172 transmissions by different nodes are undesirable, and which contains 173 mechanisms, such as periodic control message transmission, triggered 174 control message transmission, or control message forwarding, which 175 either make a simultaneous transmission more likely, or cause one to 176 be repeated when it occurs. This particularly applies to protocols 177 using broadcast transmissions in wireless networks, where proactive 178 MANET routing protocols such as [5] employ scheduled messages, where 179 reactive MANET routing protocols such as [6] employ event-triggered 180 messages, and where both employ message forwarding. 182 These mechanisms are intended for application where the underlying 183 medium access control and lower layers do not provide effective 184 mechanisms to avoid such collisions. Where these layers do provide 185 effective mechanisms, the recommendations of this document are not 186 needed. 188 The approach described in this document uses random variations in 189 timing to achieve a reduction in collisions. Alternatives using, for 190 example, pseudo-random variation based on node identity, may be 191 considered, but are not discussed by this document. 193 Any protocol based on [7] and using the message forwarding mechanism 194 facilitated by that structure is a particular candidate for 195 application of at least some of these mechanisms. 197 The document has been generalized from the jitter mechanism used in 198 the proactive MANET routing protocol OLSR (The Optimized Link State 199 Routing Protocol) [5]. 201 4. Protocol Overview and Functioning 203 This document provides recommendations for message transmission (and 204 retransmission) which may be used by MANET routing protocols. It may 205 also be used by other protocols that employ a periodic or triggered 206 message schedule running over wireless interfaces. Using such 207 protocols simultaneous transmissions from two (or more) adjacent 208 nodes may cause delays, packet losses and other problems. Any 209 protocol using jitter as outlined here must specify its precise usage 210 insofar as is necessary for interoperability. 212 5. Jitter 214 In order to prevent nodes in a MANET from simultaneous transmission, 215 whilst retaining the MANET characteristic of maximum node autonomy, a 216 randomization of the transmission time of packets by nodes, known as 217 jitter, SHOULD be employed. Three jitter mechanisms, which target 218 different aspects of this problem, SHOULD be employed, with the aim 219 of reducing the likelihood of simultaneous transmission, and, if it 220 occurs, preventing it from continuing. 222 Three cases exist: 224 o Periodic message generation; 226 o Externally-triggered message generation; 228 o Message forwarding. 230 For the first of these cases, jitter is used to reduce the interval 231 between successive message transmission by a random amount; for the 232 latter two cases, jitter is used to delay a message being generated 233 or forwarded by a random amount. 235 Each of these cases uses a parameter, denoted MAXJITTER, for the 236 maximum timing variation that it introduces. If more than one of 237 these cases is used by a protocol, it MAY use the same or a different 238 value of MAXJITTER for each case. It also MAY use the same or 239 different values of MAXJITTER according to message type, and under 240 different circumstances - in particular if other parameters (such as 241 message interval) vary. 243 Issues relating to the value of MAXJITTER are considered in 244 Section 5.4. 246 5.1. Periodic Message Generation 248 When a node generates a message periodically, two successive messages 249 will be separated by a well-defined interval, denoted 250 MESSAGE_INTERVAL. A node MAY maintain more than one such interval, 251 e.g. for different message types or in different circumstances (such 252 as backing off transmissions to avoid congestion). Jitter SHOULD be 253 applied by reducing this delay by a random amount, so that the delay 254 between consecutive transmissions of messages of the same type is 255 equal to (MESSAGE_INTERVAL - jitter), where jitter is the random 256 value. 258 Subtraction of the random value from the message interval ensures 259 that the message interval never exceeds MESSAGE_INTERVAL, and does 260 not adversely affect timeouts or other mechanisms which may be based 261 on message late arrival or failure to arrive. By basing the message 262 transmission time on the previous transmission time, rather than by 263 jittering a fixed clock, nodes can become completely desynchronized, 264 which minimizes their probability of repeated collisions. This is 265 particularly useful when combined with externally-triggered message 266 generation and rescheduling. 268 The jitter value SHOULD be generated uniformly in an interval between 269 zero and MAXJITTER. 271 Note that a node will know its own MESSAGE_INTERVAL value and can 272 readily ensure that any MAXJITTER value used satisfies the conditions 273 in Section 5.4. 275 5.2. Externally-Triggered Message Generation 277 An internal or external condition or event may trigger message 278 generation by a node. Depending upon the protocol, this condition 279 may trigger generation of a single message (including, but not 280 limited to, an acknowledgement message), initiation of a new periodic 281 message schedule, or rescheduling of existing periodic messaging. 282 Collision between externally-triggered messages is made more likely 283 if more than one node is likely to respond to the same event. To 284 reduce this likelihood, an externally-triggered message SHOULD be 285 jittered by delaying it by a random duration; an internally triggered 286 message MAY also be so jittered if appropriate. This delay SHOULD be 287 generated uniformly in an interval between zero and MAXJITTER. If 288 periodically transmitted messages are rescheduled, then this SHOULD 289 be based on this delayed time, with subsequent messages treated as 290 described in Section 5.1. 292 When messages are triggered, whether or not they are also 293 periodically transmitted, a protocol MAY impose a minimum interval 294 between messages of the same type, denoted MESSAGE_MIN_INTERVAL. In 295 the case that such an interval is not required, MESSAGE_MIN_INTERVAL 296 is considered to be zero. When MESSAGE_MIN_INTERVAL is non-zero, it 297 is however appropriate to also allow this interval to be reduced by 298 jitter. Thus when a message is transmitted the next message is 299 allowed after a time (MESSAGE_MIN_INTERVAL - jitter). This jitter 300 SHOULD be generated uniformly in an interval between zero and 301 MAXJITTER (using a value of MAXJITTER appropriate to periodic message 302 transmission). 304 It might appear counterintuitive to have a defined 305 MESSAGE_MIN_INTERVAL, yet allow this to be reduced by jittering. For 306 periodic messages, setting MESSAGE_INTERVAL, MAXJITTER and 307 MESSAGE_MIN_INTERVAL such that (MESSAGE_INTERVAL-MAXJITTER) > 308 MESSAGE_MIN_INTERVAL would ensure at least MESSAGE_MIN_INTERVAL would 309 elapse between two subsequent message transmissions. In a highly 310 dynamic network with triggered messages, however, external 311 circumstances might be such that external triggers are more frequent 312 than MESSAGE_MIN_INTERVAL, effectively making MESSAGE_MIN_INTERVAL 313 take the role of MESSAGE_INTERVAL as the "default" interval at which 314 messages are transmitted. Thus, in order to avoid synchronization 315 also in this highly dynamic case, jittering SHOULD be applied to 316 MESSAGE_MIN_INTERVAL. This also permits MESSAGE_MIN_INTERVAL to 317 equal MESSAGE_INTERVAL even when jitter is used. 319 When a triggered message is delayed by jitter, the node MAY also 320 postpone generation of the triggered message. If a node is then 321 triggered to generate a message of the same type while waiting, it 322 can generate a single message. If however the node generates a 323 message when it is triggered, and then receives a another trigger 324 while waiting to send that message then the appropriate action to 325 take is protocol specific (typically to discard the earlier message 326 or to transmit both, possibly modifying timing to maintain message 327 order). 329 5.3. Message Forwarding 331 When a node forwards a message, it SHOULD be jittered by delaying it 332 by a random duration. This delay SHOULD be generated uniformly in an 333 interval between zero and MAXJITTER. 335 Unlike the cases of periodically generated and externally-triggered 336 messages, a node is not automatically aware of the message 337 originator's value of MESSAGE_INTERVAL, which is required to select a 338 value of MAXJITTER which is known to be valid. This may require 339 prior agreement as to the value (or minimum value) of 340 MESSAGE_INTERVAL, may be by inclusion in the message of 341 MESSAGE_INTERVAL (the time until the next relevant message, rather 342 than the time since the last message) or be by any other protocol 343 specific mechanism, which may include estimation of the value of 344 MESSAGE_INTERVAL based on received message times. 346 For several possible reasons (differing parameters, message 347 rescheduling, extreme random values) a node may receive a message 348 while still waiting to forward an earlier message of the same type 349 originating from the same node. This is possible without jitter, but 350 may occur more often with it. The appropriate action to take is 351 protocol specific (typically to discard the earlier message or to 352 forward both, possible modifying timing to maintain message order). 354 In many cases, including [5] and protocols using the full 355 functionality of [7], messages are transmitted hop-by-hop in 356 potentially multi-message packets, and some or all of those messages 357 may need to be forwarded. For efficiency this SHOULD be in a single 358 packet, and hence the forwarding jitter of all messages received in a 359 single packet SHOULD be the same. (This also requires that a single 360 value of MAXJITTER is used in this case.) For this to have the 361 intended uniform distribution it is necessary to choose a single 362 random jitter for all messages. It is not appropriate to give each 363 message a random jitter and then to use the smallest of these jitter 364 values, as that produces a jitter with a non-uniform distribution and 365 a reduced mean value. 367 In addition, the protocol MAY permit control messages received in 368 different packets to be combined, possibly also with locally 369 generated control messages (periodically generated or triggered), as 370 supported by [7]. However in this case the purpose of the jitter 371 will be accomplished by choosing any of the independently scheduled 372 times for these events as the single forwarding time; this may have 373 to be the earliest time to achieve all constraints. This is because 374 without combining messages, a transmission was due at this time 375 anyway. 377 5.4. Maximum Jitter Determination 379 In considering how the maximum jitter (one or more instances of 380 parameter MAXJITTER) may be determined, the following points may be 381 noted: 383 o While jitter may resolve the problem of simultaneous 384 transmissions, the timing changes (in particular the delays) it 385 introduces will otherwise typically have a negative impact on a 386 well-designed protocol. Thus MAXJITTER SHOULD always be 387 minimized, subject to acceptably achieving its intent. 389 o When messages are periodically generated, all of the following 390 that are relevant apply to each instance of MAXJITTER: 392 * it MUST NOT be negative; 394 * it MUST NOT be greater than MESSAGE_INTERVAL/2; 396 * it SHOULD NOT be greater than MESSAGE_INTERVAL/4. 398 o If MESSAGE_MIN_INTERVAL > 0, then: 400 * MAXJITTER MUST NOT be greater than MESSAGE_MIN_INTERVAL; 402 * MAXJITTER SHOULD NOT be greater than MESSAGE_MIN_INTERVAL/2. 404 o As well as the decision as to whether to use jitter being 405 dependent on the medium access control and lower layers, the 406 selection of the MAXJITTER parameter SHOULD be appropriate to 407 those mechanisms. For example MAXJITTER should be significantly 408 greater than (e.g. an order of magnitude greater than) any medium 409 access control frame period. 411 o As jitter is intended to reduce collisions, greater jitter, i.e. 412 an increased value of MAXJITTER, is appropriate when the chance of 413 collisions is greater. This is particularly the case with 414 increased node density, which is significant relative to (the 415 square of) the interference range rather than useful signal range. 417 o The choice of MAXJITTER used when forwarding messages MAY also 418 take into account the expected number of times that the message 419 may be sequentially forwarded, up to the network diameter in hops, 420 in order that the maximum accumulated delay is bounded. 422 6. IANA Considerations 424 This document presents no IANA considerations. 426 7. Security Considerations 428 This document provides recommendations for mechanisms to be used in 429 protocols; full security considerations are to be provided by those 430 protocols, rather than in this document. 432 It may however be noted that introduction of random timing by these 433 recommendations may provide some security advantage to such a 434 protocol in that it makes the prediction of transmission times, and 435 thereby intentional interference with a protocol functioning through 436 selectively scheduling jamming transmissions to coincide with 437 protocol message transmissions, more difficult. 439 8. References 441 8.1. Normative References 443 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 444 Levels", RFC 2119, BCP 14, March 1997. 446 8.2. Informative References 448 [2] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. 450 [3] Marlow, D., "Host Group Extensions for CLNP Multicasting", 451 RFC 1768, March 1995. 453 [4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 454 (BGP-4)", RFC 4271, January 2006. 456 [5] Clausen, T. and P. Jacquet, "The Optimized Link State Routing 457 Protocol", RFC 3626, October 2003. 459 [6] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand 460 Distance Vector (AODV) Routing", RFC 3561, July 2003. 462 [7] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized 463 MANET Packet/Message Format", Work In 464 Progress draft-ietf-manet-packetbb-11.txt, November 2007. 466 Appendix A. Acknowledgements 468 The authors would like to acknowledge the MANET working group and the 469 OLSRv2 Design team, in particular Joe Macker and Justin Dean (both 470 NRL), for their contributions and discussions in developing and 471 testing the concepts retained in this document, and Alan Cullen (BAE 472 Systems) for his careful review of this specification. OLSRv1, as 473 specified in [5], introduced the concept of jitter on control 474 traffic, which was tested thoroughly by Gitte Hansen and Lars 475 Christensen (then, both Aalborg University). 477 Authors' Addresses 479 Thomas Heide Clausen 480 LIX, Ecole Polytechnique, France 482 Phone: +33 6 6058 9349 483 Email: T.Clausen@computer.org 484 URI: http://www.ThomasClausen.org/ 486 Christopher Dearlove 487 BAE Systems Advanced Technology Centre 489 Phone: +44 1245 242194 490 Email: chris.dearlove@baesystems.com 491 URI: http://www.baesystems.com/ 493 Brian Adamson 494 U.S. Naval Research Laboratory 496 Phone: +01 202 404 1194 497 Email: adamson@itd.nrl.navy.mil 498 URI: http://www.nrl.navy.mil/ 500 Full Copyright Statement 502 Copyright (C) The IETF Trust (2007). 504 This document is subject to the rights, licenses and restrictions 505 contained in BCP 78, and except as set forth therein, the authors 506 retain all their rights. 508 This document and the information contained herein are provided on an 509 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 510 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 511 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 512 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 513 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 514 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 516 Intellectual Property 518 The IETF takes no position regarding the validity or scope of any 519 Intellectual Property Rights or other rights that might be claimed to 520 pertain to the implementation or use of the technology described in 521 this document or the extent to which any license under such rights 522 might or might not be available; nor does it represent that it has 523 made any independent effort to identify any such rights. Information 524 on the procedures with respect to rights in RFC documents can be 525 found in BCP 78 and BCP 79. 527 Copies of IPR disclosures made to the IETF Secretariat and any 528 assurances of licenses to be made available, or the result of an 529 attempt made to obtain a general license or permission for the use of 530 such proprietary rights by implementers or users of this 531 specification can be obtained from the IETF on-line IPR repository at 532 http://www.ietf.org/ipr. 534 The IETF invites any interested party to bring to its attention any 535 copyrights, patents or patent applications, or other proprietary 536 rights that may cover technology that may be required to implement 537 this standard. Please address the information to the IETF at 538 ietf-ipr@ietf.org. 540 Acknowledgment 542 Funding for the RFC Editor function is provided by the IETF 543 Administrative Support Activity (IASA).