idnits 2.17.1 draft-ietf-ipoib-connected-mode-03.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 579. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 541), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 12) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 53 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (March 2006) is 6611 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) == Missing Reference: 'IPoIB-UD' is mentioned on line 116, but not defined -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT V. Kashyap 3 IBM 4 Expiration Date: September 2006 March 2006 6 IP over InfiniBand: Connected Mode 8 Status of this memo 10 By submitting this Internet-Draft, each author represents that 11 any applicable patent or other IPR claims of which he or she is 12 aware have been or will be disclosed, and any of which he or she 13 becomes aware will be disclosed, in accordance with Section 6 of 14 BCP 79. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as "work 25 in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). All Rights Reserved. 37 Abstract 39 This document specifies transmission of IPv4/IPv6 packets and 40 address resolution over the connected modes of InfiniBand. 42 Table of Contents 44 1.0 Introduction 45 2.0 IPoIB-connected mode 46 2.1 Multicasting 47 2.2 Outline of Address Resolution 48 2.3 Outline of Connection Setup 49 3.0 Address Resolution 50 3.1 Link-layer Address 51 3.2 IB Connection Setup 52 3.3 Simultaneous IB Connections 53 3.4 IPoIB-CM IB Connection Teardown 54 3.5 Service-ID 55 4.0 Frame Format 56 5.0 Maximum Transmission Unit 57 5.1 Per-Connection MTU 58 6.0 Private-Data Format 59 7.0 IPoIB-CM Considerations 60 7.1 A Cautionary Note on IPoIB-RC 61 7.2 IPoIB-CM Per-Destination MTU 62 8.0 Security Considerations 63 9.0 IANA Considerations 64 10.0 Acknowledgements 65 11.0 References 66 12.0 Author's Address 68 1.0 Introduction 70 The InfiniBand specification [IB_ARCH] can be found at 71 www.infinibandta.org. The document [IPoIB_ARCH] provides a 72 short overview of InfiniBand architecture along with 73 consideration for specifying IP over InfiniBand networks. 75 The InfiniBand architecture (IBA) defines multiple modes of 76 transports. Of these the unreliable datagram (UD) transport 77 method best matches the needs of IP. IP over InfiniBand (IPoIB) 78 over UD is described in [IPoIB_UD]. This document describes IP 79 transmission over the connected modes of IBA. 81 IBA defines two connected modes: 83 1. Reliable Connected (RC) 84 2. Unreliable Connected (UC) 86 As is evident from the nomenclature, the two modes differ mainly 87 in providing reliability of data delivery across the connection. 88 This document applies equally to both the connected modes. 89 IPoIB over these two modes is referred to as IPoIB-CM (connected 90 mode) in this document. For clarity, IPoIB over the unreliable 91 datagram mode as described in [IPoIB_UD], is referred to as 92 IPoIB-UD. 94 IBA requires that all Host Channel Adapters (HCAs) support the 95 reliable and unreliable connected modes [IB_ARCH]. It is 96 optional for Target Channel Adapters (TCAs) to support the 97 connected modes. 99 The connected modes offer link MTUs of up to 2^31 octets in 100 length. Thus, the use of connected modes can offer significant 101 benefits by supporting reasonably large MTUs. The datagram modes 102 of InfiniBand Architecture (IBA) are limited to 4096 octets. 104 Reliability is also enhanced if the underlying feature of 105 "automatic path migration" supported by the connected modes is 106 utilized. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 109 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described 111 in RFC 2119 [RFC2119]. 113 2.0 IPoIB-connected mode 115 IPoIB over connected mode is an OPTIONAL extension to IPoIB-UD. 116 Every IPoIB implementation MUST support [IPoIB-UD] and MAY 117 support the extensions described in this document. 119 Therefore, IP encapsulation, default MTU, link layer address 120 format and the IPv6 stateless autoconfiguration mechanism apply 121 to IPoIB-CM exactly as described in [IPoIB_UD]. 123 2.1 Multicasting 125 The connected modes of IBA define a non-broadcast, multiple 126 access network. The connected modes of IBA do not support 127 multicasting though every node can communicate with every other 128 node if desired. 130 This requires that multicasting be emulated in some form by the 131 network. However, in the case of an InfiniBand network, instead 132 of an emulation, an unreliable datagram (UD) queue pair (QP) 133 can be used to support multicasting while the connected mode QP 134 is used for unicast traffic. Since every IPoIB implementation 135 is required to support the UD mode, every implementation 136 supporting IPoIB-CM will be able to utilize the pre-existing 137 IPoIB-UD QP for all broadcast/multicast communications. 139 Multicast mapping, transmission and reception of multicast 140 packets and multicast routing MUST use the UD QP associated with 141 the IPoIB interface. 143 2.2 Outline of Address Resolution 145 Every IPoIB-CM interface MUST have two sets of QPs associated 146 with it: 148 1) One unreliable datagram QP 149 2) One or more connected mode QPs 151 [IPoIB_UD] describes the address resolution method to determine 152 the link address of the peer. This response is received on the 153 UD QP associated with the IPoIB interface. 155 2.3 Outline of Connection setup 157 Once the link address of the remote node is known, an IB 158 connection must be setup between the nodes before any IP 159 communication may occur. 161 To make a connection, the sender must know the service-ID to use 162 in the request to make a connection [IB_ARCH]. It must also 163 supply the "connection mode" queue pair to the remote node. The 164 peer replies with its queue pair. Each IB connection is peer to 165 peer and uses one connected mode QP at each end. 167 Though the address resolution occurs at an individual IP address 168 level, the connection between the nodes is at the IB layer. 169 Therefore, every individual address resolution does not imply a 170 new connection between the peers. 172 3.0 Address Resolution 174 Address resolution queries are sent out on the "broadcast-GID" 175 over the UD QP associated with the IPoIB interface. A unicast 176 reply is received on the UD QP. 178 3.1 Link-layer Address 180 IPoIB encapsulation [IPoIB_UD] describes the link-layer address 181 as follows: 183 <1 octet reserved>:QP: GID 185 This document extends the link-layer address as follows: 187 :QPN:GID 189 Flags: 191 This is a single octet field. The bits indicate the 192 connected modes supported by the interface. 194 Bit 0 specifies the support for the "reliable connected" 195 (RC) mode. Bit 1 indicates the support for the 196 "unreliable connected" (UC) mode. All other bits in the 197 octet are reserved and MUST be set to 0 on transmits and 198 ignored on receives. The format of the flags is: 200 +--+--+--+--+--+--+--+--+ 201 |RC|UC| 0| 0| 0| 0| 0| 0| 202 +--+--+--+--+--+--+--+--+ 204 Both the RC and UC MAY be set at the same time if the 205 interface supports both the modes. Since the IPoIB-UD 206 mode is always supported there are no flags to indicate 207 IPoIB-UD support. 209 If IPoIB-CM is not supported i.e. if the implementation 210 only supports IPoIB-UD, then the implementation MUST 211 ignore the on reception. It MUST set the 212 octet to all zeroes on transmission as specified in 213 [IPoIB_UD]. 215 QPN: 217 The queue-pair number (QPN) on which the unicast address 218 resolution reply will be received [IPoIB_UD]. An IPoIB 219 interface has only one UD QP associated with it whether 220 it supports this extension or not. 222 The QPN also serves another purpose. It is used to form 223 the Service-ID that is used to setup the IB connection. 225 On receiving the multicast/broadcast address resolution request, 226 the receiver replies with its own link-address, including the 227 associated UD QPN and the appropriate flags. 229 The receiver's reply is unicast back to the sender after the 230 receiver has, as in the case of IPoIB-UD, resolved the GID to 231 the LID, and determined other required parameters [IPoIB_UD]. 233 Once the address resolution is completed the underlying IB 234 connection on the supported connection modes can be set up. An 235 implementation is NOT REQUIRED to setup a connection merely 236 because the peer indicates the capability. The decision to make 237 such a connection is left to the implementation. 239 3.2 IB Connection Setup 241 Once the address resolution is complete the IB connection can be 242 setup by either of the peers. To setup a connection IB 243 Management Datagrams (MADs) are directed to the peer's 244 communication manager (CM). The connection request always 245 contains a Service-ID for the peer to associate the request with 246 the appropriate service. If the request is accepted, the peer 247 returns the relevant connected mode QPN in the response MAD. The 248 format of the CM connection messages and the IB connection setup 249 process is described in [IB_ARCH]. The overall handshake is of 250 the form: 252 REQ ----> 253 <---- REP [or REJ(reject)] 254 RTA ----> 255 [or REJ(reject)] 257 The CM messages include, among other parameters, the Service-ID, 258 Local connection-mode QPN, and the payload size to use over the 259 connection. 261 Note: 262 The IB connection is setup using the Service-ID as defined 263 in section 3.5 below. The node MUST keep a record of IB 264 connections it is participating in. The node MAY attempt 265 another connection to the remote peer using the same 266 Service-ID as used for an existing IB connection. 267 Similarly, the receiver of such a connection MAY drop the 268 request with a suitable error indication in the CM 269 response. The decision to accept or initiate multiple 270 connections from or to an IPoIB interface is left to the 271 implementation. 273 The node that initiated the connection is aware of the target 274 node's IP address as described above. The node receiving the IB 275 connection request, however cannot determine the initiating 276 node's link address. To enable this determination, every CM 277 message exchanged in setting up the IB connection, MUST include 278 the sender's IPoIB-UD QPN in the "private data" [IB_ARCH] field. 279 The IPoIB-UD QPN MUST be included in all "REJ" [IB_ARCH] 280 messages too. 282 3.3 Simultaneous IB Connections 284 To ensure that two IB connections are not setup between the 285 peers due to REQ crossing, the following rules MUST be followed: 287 The receiver forms the remote node's link-layer address 288 using the UD QPN received in the "private data" field of the 289 "REQ" message and the GID of the sender included in the 290 "REQ" message. The link-layer address is used to determine 291 if there is already an outstanding connection request "REQ" 292 sent by the local interface to the given received link-layer 293 address. If such an outstanding request is determined, then 294 the two link-layer addresses (local and remote) are 295 numerically compared. If the local link-layer address is 296 numerically smaller, then the connection is accepted, 297 otherwise rejected. The error code in "REJ" MAD is set to 298 "Consumer Reject" [IB_ARCH]. 300 Note: 301 The link-layer addresses formed for comparison zero out 302 the connection mode flags specified in section 3.1. The 303 comparison is performed from the most significant octet 304 to the least significant octet of the link-layer 305 address. 307 The above holds even if the receiver supports multiple IB 308 connections from the same peer. This is to ensure that only 309 one more connection is setup when the "REQ" messages cross. 311 3.4 IPoIB-CM IB Connection Teardown 313 IB connections created through IPoIB-CM are considered part of 314 an IPoIB interface. As such, they SHOULD be torn down when the 315 IPoIB interfaces they are associated with is torn down. 317 Furthermore, the IB connection between two peers MAY be torn 318 down by either peer whenever the address resolution entry 319 expires. An implementation is free to implement alternative 320 policies for tearing down of IB connections between peers. 322 3.5 Service-ID 324 The InfiniBand specification defines a block of service IDs for 325 IETF use. The InfiniBand specification has left the definition 326 and management of this block to the IETF [IB_ARCH]. The 64-bit 327 block is: 329 +--------+--------+--------+--------+-------+--------+--------+------+ 330 |00000001|<-------------------IETF use------------------------------>| 331 +--------+--------+--------+--------+-------+--------+--------+------+ 333 The Service-IDs used by IPoIB will be in the format: 335 +--------+--------+--------+--------+-------+-------+--------+-------+ 336 |00000001| Type | Reserved | QPN | 337 +--------+--------+--------+--------+-------+-------+--------+-------+ 339 The "Type" field MUST be set to 0. 341 The "Reserved" field MUST be set to zeroes. 343 The QPN MUST be the UD QP exchanged during address resolution. 345 4.0 Frame Format 347 All IP datagrams transported over InfiniBand are prefixed by a 348 4-octet encapsulation header as described in [IPoIB_UD]. 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | | 354 | Type | Reserved | 355 | | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 The type field SHALL indicate the encapsulated protocol as per 359 the following table. 361 +----------+-------------+ 362 | Type | Protocol | 363 |------------------------| 364 | 0x800 | IPv4 | 365 |------------------------| 366 | 0x86DD | IPv6 | 367 +------------------------+ 369 These values are taken from the "ETHER TYPE" numbers assigned by 370 Internet Assigned Numbers Authority (IANA). Other network 371 protocols, identified by different values of "ETHER TYPE", may 372 use the encapsulation format defined herein, but such use is 373 outside of the scope of this document. 375 5.0 Maximum Transmission Unit 377 The IB connection setup might be used for both IPv4 and IPv6 or 378 it could be used for only one of them while a different 379 connection is used for the other. The link MTU MUST be able to 380 support the minimum MTU required by the protocols. 382 The default MTU of the IPoIB-CM interface is 2044 octets i.e. 383 2048 octet IPoIB-link MTU minus the 4 octet encapsulation 384 header. 386 However, connected modes of InfiniBand allow message sizes up to 387 2^31 octets. Therefore, IPoIB-CM can use a much larger MTU for 388 unicast communication between any two endpoints. The maximum 389 and/or optimal payload that can be received or sent over an 390 InfiniBand connection is dependent on the implementation, HCA 391 and the resources configured. 393 An implementation MAY utilise the following mechanism to 394 exchange the optimal message size across the IB connection. 396 5.1 Per-Connection MTU 398 Every IB connection setup message includes a "private data" 399 field [IB_ARCH]. The "private data" field in the connection 400 setup message (CM REQ) MUST include the "Receive MTU". This 401 indicates the maximum packet size the requester can accept. The 402 requester MUST be able to accept smaller MTU sizes as well. 404 It is up to the implementation to utilize this mechanism for 405 setting the per IB connection MTU. To calculate the resultant 406 IPoIB MTU over the connection the smaller of the two IB "Receive 407 MTU" values is used by both the peers. The IPoIB interface must 408 also account for the 4-octet encapsulation header and so the 409 IPoIB MTU over the connection will be further reduced by that 410 amount. 412 6.0 Private-Data Format 414 The "private data" field in every CM message for connection 415 establishment must include the following values: 417 1. UD QPN of the sender 418 2. Receive MTU supported by the sender 420 The format of "private data" field MUST be: 422 0 7 15 23 31 423 +--------+--------+--------+--------+ 424 |Reserved| UD QPN | 425 +--------+--------+--------+--------+ 426 | Receive MTU | 427 +--------+--------+--------+--------+ 429 The Reserved value MUST be set to zero on transmit and ignored 430 on receive. 432 7.0 IPoIB-CM Considerations 434 Every IPoIB interface supports IPoIB-UD. It may additionally 435 support one or both of IPoIB-CM modes. Therefore, there can be 436 multiple methods of communicating between any two peers. This 437 implies that an interface MAY transmit/receive a packet over any 438 of the RC, UC or UD modes depending on the modes supported 439 between it and the peer. It further follows that every IPoIB 440 implementation compliant with this document MUST accept all IP 441 unicast transmissions over any of the IPoIB modes it supports. 442 Multicast and broadcast packets by their nature will always be 443 transmitted and received over the IPoIB-UD QP. Additionally, all 444 address resolution responses (ARP or Neighbor Discovery) MUST 445 always be encapsulated in a UD mode packet. 447 7.1 A Cautionary Note on IPoIB-RC 449 The RC mode of InfiniBand guarantees in-order delivery of 450 packets. Every message transmitted over the RC connection is 451 broken into physical MTU sized packets by the RC connection. If 452 any packet is lost, it is retransmitted until the complete 453 message is exchanged. Therefore, there is a possibility of an 454 upper transport layer experiencing a timeout, while the RC layer 455 is still in the process of transferring the complete message. 456 TCP will view the timeout as an indicator of congestion and 457 enter slow-start thereby affecting throughput drastically 458 [RFC2581]. Other upper layer protocols might insert 459 retransmissions into the fabric adding to the already existing 460 congestion. 462 The applicability of Infiniband reliability is on a fabric with 463 short latencies (not wide area). Therefore, the RC timer values 464 should be short compared with the starting minimum time values 465 used by the upper end-to-end transports. In addition, because 466 the RC mode does not have measurement based reliable 467 transmission, its use over fabrics with long latency or very 468 dynamic latency may be a concern for congestion- aware traffic 469 traversing those fabrics. 471 7.2 IPoIB-CM Per-Destination MTU 473 As described above, interfaces on the same subnet may support 474 different link MTUs based on the negotiated value or due to the 475 link type (UD or connected mode). Therefore, an implementation 476 might choose to define a large IP MTU which is reduced based on 477 the MTU to the destination. The relevant MTU may be stored in a 478 suitable per-destination object, such as a route cache or a 479 neighbour cache. The per-destination MTU is known to the IPoIB- 480 CM interface as described in section 5.0. 482 Implementations might choose not to support differing MTU values 483 and always support an MTU equal to the IPoIB-UD MTU determined 484 from the broadcast GID. 486 8.0 Security Considerations 488 A node may be returned a false set of flags by an impostor. This 489 may cause unnecessary attempts and some delay/disruption in 490 IPoIB communication. The same is the case if wrong/spurious QPN 491 values are provided during address resolution 492 broadcast/multicast. 494 9.0 IANA Considerations 496 Future uses of the reserved bits and octets in the link-layer 497 address (section 3.1), Service-ID (section 3.5), and "Private- 498 Data Format" (section 6.0), MUST be published as RFCs. This 499 document requires that the reserved bits be set to zero on 500 sends. 502 10.0 Acknowledgements 504 The author thanks the IPoIB WG for the various comments and 505 suggestions. A special thanks to Bernie King-Smith and Dror 506 Goldenberg for the detailed review and suggestions. 508 11.0 References 510 Normative 512 [IB_ARCH] InfiniBand Architecture Specification, version 1.2 513 www.infinibandta.org 515 [IPoIB_ARCH] draft-ietf-ipoib-architecture-04.txt, V. Kashyap 517 [IPoIB_UD] draft-ietf-ipoib-ip-over-infiniband-9.txt, 518 H.K. Jerry Chu, V. Kashyap 520 [RFC2119] RFC 2119, "Key words for use in RFCs to Indicate 521 Requirement Levels", S. Bradner 523 Informative 525 [RFC2581] RFC 2581, "TCP Congestion control", M. Allman, V. Paxson, 526 W. Stevens 528 12.0 Author's Address 530 Vivek Kashyap 532 15350, SW Koll Parkway 533 Beaverton 534 OR 97006 536 Phone: +1 503 578 3422 537 Email: vivk@us.ibm.com 539 Full Copyright Statement 541 Copyright (C) The Internet Society (2006). 543 This document is subject to the rights, licenses and 544 restrictions contained in BCP 78, and except as set forth 545 therein, the authors retain all their rights. 547 This document and the information contained herein are provided 548 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 549 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 550 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 551 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 552 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 553 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 554 FOR A PARTICULAR PURPOSE. 556 Intellectual Property Statement 558 The IETF takes no position regarding the validity or scope of 559 any Intellectual Property Rights or other rights that might be 560 claimed to pertain to the implementation or use of the 561 technology described in this document or the extent to which any 562 license under such rights might or might not be available; nor 563 does it represent that it has made any independent effort to 564 identify any such rights. Information on the procedures with 565 respect to rights in RFC documents can be found in BCP 78 and 566 BCP 79. 568 Copies of IPR disclosures made to the IETF Secretariat and any 569 assurances of licenses to be made available, or the result of an 570 attempt made to obtain a general license or permission for the 571 use of such proprietary rights by implementers or users of this 572 specification can be obtained from the IETF on-line IPR 573 repository at http://www.ietf.org/ipr. 575 The IETF invites any interested party to bring to its attention 576 any copyrights, patents or patent applications, or other 577 proprietary rights that may cover technology that may be 578 required to implement this standard. Please address the 579 information to the IETF at ietf-ipr@ietf.org. 581 Acknowledgement 583 Funding for the RFC Editor function is currently provided by the 584 Internet Society.