idnits 2.17.1 draft-asveren-dime-cong-02.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 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 584. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (June 15, 2007) is 6159 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) == Unused Reference: '1' is defined on line 522, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (ref. '1') (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Asveren 3 Internet-Draft Sonus Networks 4 Expires: December 17, 2007 V. Fajardo 5 Toshiba America Research Inc. 6 June 15, 2007 8 Diameter Congestion Signaling 9 draft-asveren-dime-cong-02.txt 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 December 17, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Diameter base protocol defines the network layer functionality to be 43 used by applications. This document adds hop-to-hop congestion 44 notification mechanism to that functionality. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.1. Congestion of Intermediaries . . . . . . . . . . . . . . . 4 52 3.2. Multiple Applications On the Same Node . . . . . . . . . . 4 53 3.3. Congestion Detection Time . . . . . . . . . . . . . . . . 4 54 3.4. Notification of Congestion Abatement . . . . . . . . . . . 5 55 3.5. Multiple Congestion Levels . . . . . . . . . . . . . . . . 5 56 3.6. Shortcomings of Transport Layer Congestion Indications . . 5 57 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Hop-To-Hop Congestion Notification Mechanism . . . . . . . . . 6 59 5.1. Congestion Level Signaling Procedures . . . . . . . . . . 6 60 5.1.1. Sending Congestion Information . . . . . . . . . . . . 6 61 5.1.2. Receiving Congestion Information . . . . . . . . . . . 7 62 5.1.3. Local Congestion Level Determination Guidelines . . . 7 63 5.1.4. Preventing Unnecessary Retransmission . . . . . . . . 8 64 5.2. Congestion-Level AVP . . . . . . . . . . . . . . . . . . . 9 65 5.3. Error Answers . . . . . . . . . . . . . . . . . . . . . . 10 66 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 6.1. Providing Hysteresis for Local Congestion Level 68 Decision . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.2. Congestion Level Used For Loadsharing . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 75 Intellectual Property and Copyright Statements . . . . . . . . . . 14 77 1. Introduction 79 Diameter base protocol defines the network layer functionality to be 80 used by applications. Requests are routed based on Destination-Host 81 AVP, Destination-Realm AVP, Application-Id values and the status of 82 Diameter connections to neighboring peers. 84 This document defines a new AVP to be used by peers to notify their 85 neighbors about their congestion status, so that this information can 86 be used while routing requests. It is left up to the implementation 87 to decide for local congestion levels but some guidelines are 88 provided to prevent undesirable situations like oscilliation. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [2]. 96 The following terms defines the functionality used in describing 97 entities in this document. 99 Congestion 101 The situation on a Diameter node, where the current load is above 102 the normal operational limits and effects processing of messages. 103 A node which suffers from congestion should not be sent certain 104 messages depending on the severity of congestion to prevent it to 105 be overloaded further. 107 Congestion level 109 A numeric value used to quantify the severity of congestion on a 110 Diameter node. This value is generalized in this document and not 111 meant to be an exhaustive indicator of all possible variables that 112 can define congestion. The possible numeric values for congestion 113 level is defined in Section 5.2. 115 Congestion state 117 Congestion state pertains to the congestion level and other 118 relevant information that a Diameter node keeps about each of its 119 neighboring peers. 121 3. Motivation 123 When routing Diameter messages, it is preferable to consider the 124 congestion status of peers to increase the response time of answers 125 and to prevent overloading of nodes. A method of signaling the 126 congestion state among adjacent peers independent of any applications 127 will allow for a more real-time, self correcting method of reducing 128 and or distributing load among Diameter neighbors. 130 There are several scenarios where relying on an application level 131 result code is not efficient to notify peers about congestion status 132 changes. The succeeding sections provides applicability scenarios 133 for requiring per hop congestion status signaling. 135 3.1. Congestion of Intermediaries 137 In a Diameter network, intermediate nodes such as relay agents, 138 proxies, may be present. Such nodes may get congested and it is 139 desirable to consider their congestion status when selecting the next 140 hop node. 142 Intermediate nodes do not host the application logic to process a 143 request completely and do not generate answers except routing 144 failures for the requests they receive. Generating a result code of 145 "TOO_BUSY_HERE" to notify about intermediate congestion is not 146 appropriate because it indicates congestion of the server specified 147 in the Destination-Host AVP or in general the logical application 148 service identified by Destination-Realm AVP and Application-Id. It 149 is therefore limited to Diameter application end-points and does not 150 consider the congestion state of intermediaries and other application 151 traffic routed through them. 153 3.2. Multiple Applications On the Same Node 155 A Diameter node may host multiple applications simultaneously. 156 Although it is possible to aggregate congestion status of the node on 157 application logic level, it may be preferable to do this on a 158 centralized logical entity like the Diameter base protocol in a 159 layered architecture. A hop-to-hop message generated and consumed by 160 base protocol layer would be more suitable for such a task split 161 between different layers. 163 3.3. Congestion Detection Time 165 Relying on congestion notification via application level result code 166 is inherently a reactive mechanism. This requires that an 167 application level request needs to be received for congestion 168 notification to be sent on the answer. 170 This problem can be aggravated in configurations such as Diameter 171 servers which are communicating with multiple peers. A highly 172 congested server can signal its congestion state to other peers only 173 when those peers send a request to the server. 175 3.4. Notification of Congestion Abatement 177 Currently, there is no existing method of to signal end of 178 congestion. Peers may probe the congested node periodically with new 179 requests and can decide based on the result code of the corresponding 180 answer whether congestion has abated. However, such method is not 181 effective if peers have no application level request to send and 182 therefore suffers the same drawbacks as Section 3.3. A hop-to-hop 183 congestion indication message could provide notification of 184 congestion abatement immediately. 186 3.5. Multiple Congestion Levels 188 A congestion result code provides only a single congestion level of 189 "congested." For certain configurations it may be desirable to 190 provide multiple congestion levels. Especially for the cases where 191 load information is to be used for loadsharing purposes, multiple 192 levels are desirable. 194 3.6. Shortcomings of Transport Layer Congestion Indications 196 Diameter uses TCP and SCTP as transport protocols between adjacent 197 entities. Although the concept of receiver congestion is present in 198 those protocols there are some reasons, which make their use 199 unsuitable for Diameter congestion detection purposes: 201 o It is not straightforward to learn the current status of receiver 202 windows with sockets API, which is the defacto standard for 203 applications to access services of TCP and SCTP in common 204 operating systems. For TCP, applications can be aware of 205 congestion only when the receiver window is full. For SCTP, 206 application need to poll the status of receiver window, there is 207 no trigger mechanism present. 209 o Propogation of congestion may take longer than desired. 210 Congestion will be visible on sender side only after it propogated 211 to transport protocol layer, which may require multiple queues to 212 be filled first on receiver side. 214 o When congested node has multiple connections, the receiver window 215 for each connection needs to be full, i.e. if a node does not send 216 messages to the congested node, it won't be able to learn about 217 its congestion status or not before sending enough messages to 218 fill the receiver window. 220 4. Scope 222 This document defines mechanisms to communicate congestion 223 information in a hop-by-hop fashion. This information can be used to 224 protect overloaded nodes against further traffic being sent to them 225 and to loadshare requests among multiple endpoints. Although the 226 strategy mainly relies on hop-by-hop communication, it also defines 227 new result codes to be used in an end-to-end fashion to prevent 228 unnecessary request retransmission on base protocol level in case of 229 congested nodes/services. 231 5. Hop-To-Hop Congestion Notification Mechanism 233 5.1. Congestion Level Signaling Procedures 235 5.1.1. Sending Congestion Information 237 A Diameter node sends a Congestion-Level AVP in a Device Watchdog 238 Request message to its adjacent neighbors to indicate its current 239 congestion level. 241 A node's congestion level SHOULD fall into one of the congestion 242 levels defined in Section 5.2. A Diameter node SHOULD send a DWR to 243 its neighboring peers as soon as it determines that its congestion 244 level changes. Sending the DWR message with Congestion-Level AVP as 245 soon as congestion level changes is important so that adjacent nodes 246 can stop sending new requests to the congested node to prevent it to 247 get further overloaded. 249 In the case where a new peer attempts to connect to an existing node 250 supporting congestion control signaling, the Congestion-Level AVP 251 Section 5.2 may also be sent by the node in the CEA message to 252 immediately indicate to the new peer of the nodes congestion state. 253 This is in the case where the existing peer is already experiencing 254 high levels of congestion and would want to notify any new peer 255 immediately rather than sending a DWR which has an inherent latency. 257 When a node receives a request and the node already notified its 258 neighbors that it is unable to handle new requests, the node MAY 259 silently drop the request or MAY send back an error answer with 260 result code DIAMETER_CONGESTED. 262 5.1.2. Receiving Congestion Information 264 A peer receiving a Congestion-Level AVP in a DWR SHOULD create and 265 maintain congestion state for the sender of the DWR if it has not 266 already done so. The congestion state should at least contain the 267 currently advertised congestion state of the peer. 269 The receiver of the DWR should react according to the congestion 270 level information provided by the Congestion-Level AVP, i.e. it 271 SHOULD NOT send messages which are not allowed by the corresponding 272 congestion level. 274 It SHOULD be expected that Nodes MAY advertise congestion levels non- 275 sequentially, e.g. a node may first advertise CONGESTION_LEVEL_1 and 276 then CONGESTION_LEVEL_3. 278 In the case where a peer does not support congestion level based 279 request routing, it SHOULD ignore the presence of Congestion-Level 280 AVP in DWR, CER and CEA messages. Considering that M-bit is not set 281 for Congestion-Level AVP, this behavior is guaranteed by nodes 282 compliant to Diameter Base Protocol. 284 5.1.3. Local Congestion Level Determination Guidelines 286 Considering the vast amount of criteria which may be used as metrics 287 when determining congestion levels and different architectures, this 288 document does not mandate a mechanism to decide for different 289 congestion levels. 291 For sender of the Congestion-Level AVP, it is left up to the 292 implementation on determining the current congestion level of a 293 Diameter node. The implementation may rely on the traffic rate, 294 processing load, backend call latency, storage/resource availability 295 etc. or any such combinations to determine the appropriate congestion 296 level. Deciding when congestion level changes on a node is also 297 implementation dependent but nodes SHOULD provide hysteresis between 298 onset and abatement values of the congestion levels. Note that 299 schemes to determine congestion level changes should not be very 300 sensitive so as not to trigger sending many DWR message causing 301 congestion control flapping among neighboring peers. 303 It is recommended that triggering of onset and abatement levels 304 should be deterministic. It should be noted that nodes MAY also 305 choose to use only a subset of the defined congestion level values, 306 e.g. a node MAY use only CONGESTION_LEVEL_0 and CONGESTION_LEVEL_3 307 values to indicate a binary state of congested or not congested. 309 Diameter nodes SHOULD NOT send DWR messages with Congestion-Level AVP 310 very frequently, for example more than once a second. Frequent DWR 311 transmissions has the adverse side effect of triggering false 312 disconnection indication if the receiver is highly congested and 313 cannot send a DWA within the appropriate time. In the case that a 314 disconnection indication does occur due to failed DWR/DWA exchanges 315 even if the DWR transmissions are set to an acceptable frequency, 316 then the peers should follow the normal disconnection process 317 specified in RFC3588. 319 It is RECOMMENDED that nodes change their congestion state and notify 320 their neighbors before congestion gets severe enough to cause 321 significant problems for the processing of pending and on the flight 322 requests. 324 5.1.4. Preventing Unnecessary Retransmission 326 If an adjacent node to an endpoint, e.g. a relay agent or a proxy, is 327 notified that the endpoint is unable to handle new requests, there is 328 no need that the same request is retransmited via an alternate route 329 as shown in Figure 1. In such a situation, the adjacent node SHOULD 330 reply back with an error answer with result code 331 DIAMETER_ENDPOINT_CONGESTED. The Origin-Host AVP MUST be populated 332 with the identity of the congested endpoint and Error-Reporting-Host 333 AVP MUST contain the identity of the error reporting host. 335 (3)----REQ1-----> 337 (4)<-ANS1(UNABLE)- 338 TO DELIVER) 339 +--------+(1) <--DWR(Level2)- 340 | | 341 +--------+ +-------+ Relay +-----+ 342 | +--+ | Agent 1| | +--------+ 343 | Client | +--------+ | | | 344 | +--+ +--------+ +-----+ Server | 345 +--------+ | | | +-----+ | 346 +-------+ Relay | | +--------+ 347 | Agent 2+-----+ 348 (5)----REQ1-----> +--------+(2) <--DWR(Level2)- 350 (6)<-ANS1(UNABLE)- 351 TO DELIVER) 353 Figure 1: Unnecessary message retransmission during congestion 355 Similarly if a node adjacent to all endpoints providing service for a 356 specific application in a realm has received congestion level updates 357 from all of them indicating that they are unable to handle new 358 requests, the node SHOULD reply back with an 359 DIAMETER_SERVICE_CONGESTED error answer, if it receives a request 360 without Destination-Host AVP. The Origin-Host AVP MUST be populated 361 with the identity of the error reporting host. It should be noted 362 that nodes should generate this error answer if and only if they are 363 sure that they have a connection to all of the endpoints providing 364 the service for the corresponding realm. Otherwise an error answer 365 with result code "UNABLE_TO_DELIVER" SHOULD be returned. 367 5.2. Congestion-Level AVP 369 Congestion-Level AVP is of type Enumerated and indicates the 370 congestion level of a node. The following values are defined for 371 Congestion-Level AVP: 373 CONGESTION_LEVEL_0 0 375 This value indicates that the load on the sender node is below the 376 manageable limit and the node is ready to handle new messages. 378 CONGESTION_LEVEL_1 1 380 This value indicates that the load on the sender node is below the 381 manageable limit but requests for new sessions SHOULD be sent 382 preferrably to other nodes. 384 CONGESTION_LEVEL_2 2 386 This value indicates that no requests for new sessions SHOULD be 387 sent to the node. A node in this state MAY drop request messages 388 for new sessions. However, requests for existing sessions and 389 answer messages still SHOULD be sent to the node. 391 CONGESTION_LEVEL_3 3 393 This value indicates that no new requests SHOULD be sent to the 394 node even if they are requests for existing sessions. A node in 395 this state MAY drop received request messages. 397 CONGESTION_LEVEL_4 4 399 This value indicates that no new messages (neither requests nor 400 answers) SHOULD be sent to the node. A node in this state MAY 401 drop any received message. 403 5.3. Error Answers 405 This document defines a new result code of protocol error class: 407 DIAMETER_CONGESTED 3011 A request has been received and the 408 congestion state of the receiver node is not suitable to process 409 the request. 411 DIAMETER_ENDPOINT_CONGESTED 3012 A request with a Destination-Host 412 AVP is received, the destination of the request is an adjacent 413 node and already declared that it is unable to handle new 414 requests. 416 DIAMETER_APPLICATION_CONGESTED 3013 A request without a Destination- 417 Host AVP is received, it is known that all potential endpoints for 418 the request declared that they are unable to handle a new request. 420 6. Examples 422 6.1. Providing Hysteresis for Local Congestion Level Decision 424 This example assumes a local congestion level decision policy based 425 on the number of messages in an incoming queue. The node decides for 426 a maximum number of 1024 pending requests. This number could be 427 based on the processing power of the node, the nature of the 428 application and the expected message rate. The following figure 429 displays possible onset/abatement values for different congestion 430 levels. 432 +----+ 1023 433 |----| 434 |----| 435 |----| 436 |----|768 <--- Congestion Level4 Onset 437 |----| 438 |----|640 <--- Congestion Level4 Abatement 439 |----|576 <--- Congestion Level3 Onset 440 |----| 441 |----|448 <--- Congestion Level3 Abatement 442 |----|384 <--- Congestion Level2 Onset 443 |----| 444 |----|256 <--- Congestion Level2 Abatement 445 |----|192 <--- Congestion Level1 Onset 446 |----| 447 |----| 64 <--- Congestion Level1 Abatement 448 +----+ 0 449 Figure 2: Congestion Onset/Abatement Levels 451 The difference between onset and abatement levels for the same 452 congestion level is necessary to provide hysteresis so that 453 congestion level does not change frequently between two levels. 455 6.2. Congestion Level Used For Loadsharing 457 The following scenario assumes a configration, where a relay agent is 458 distributing traffic to two servers. It is assumed that the service 459 consists of a single transaction, i.e. all requests belong to 460 different sessions. 462 After Server2 declares that if there is some other server present, it 463 should be preferred for new requests, relay agent stops loadsharing 464 new requests among Server1 and Server2 and sends all new requests to 465 Server1. When congestion state on Server2 is back to normal, Relay 466 Agent continues to loadshare new requests among both servers. 468 Relay 469 Agent Server1 Server2 470 | | | 471 | | | 472 |------REQ1------>| | 473 | | | 474 |<-----ANS1-------| | 475 | | | 476 |------------REQ2------------->| 477 | | | 478 |<-----------ANS2--------------| 479 | | | 480 |<-----DWR(Cong. Level 1)------| 481 | | | 482 |-----------DWA--------------->| 483 | | | 484 |-----REQ3------->| | 485 | | | 486 |<----ANS3--------| | 487 | | | 488 |-----REQ4------->| | 489 | | | 490 |<----ANS4--------| | 491 | | | 492 |<----DWR(Cong. Level 0)-------| 493 | | | 494 |----------DWA---------------->| 495 | | | 496 |-----------REQ5-------------->| 497 | | | 498 |<----------ANS5---------------| 499 | | | 500 | | | 502 Figure 3: Congestion Level 1 Being Used in Loadsharing 504 7. IANA Considerations 506 IANA is to assign new AVP codes for Congestion-Level AVP defined in 507 Section 5.2. 509 8. Security Considerations 511 This document does not contain a security protocol; it describes 512 extensions to the existing Diameter protocol. All security issues of 513 DIAMETER protocol must be considered in implementing this 514 specification. This extension does not add any unique concerns. 516 9. Acknowledgments 518 The authors wish to thank Bernard Aboba for his invaluable comments. 520 10. Normative References 522 [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 523 "Diameter Base Protocol", RFC 3588, September 2003. 525 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 526 Levels", BCP 14, RFC 2119, March 1997. 528 Authors' Addresses 530 Tolga Asveren 531 Sonus Networks 532 4400 Route 9 South 533 Freehold, NJ, 07728 534 USA 536 Email: tasveren@sonusnet.com 538 Victor Fajardo 539 Toshiba America Research Inc. 540 One Telcordia Drive 541 Piscataway, NJ 08854 542 USA 544 Email: vfajardo@tari.toshiba.com 546 Full Copyright Statement 548 Copyright (C) The IETF Trust (2007). 550 This document is subject to the rights, licenses and restrictions 551 contained in BCP 78, and except as set forth therein, the authors 552 retain all their rights. 554 This document and the information contained herein are provided on an 555 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 556 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 557 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 558 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 559 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Intellectual Property 564 The IETF takes no position regarding the validity or scope of any 565 Intellectual Property Rights or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; nor does it represent that it has 569 made any independent effort to identify any such rights. Information 570 on the procedures with respect to rights in RFC documents can be 571 found in BCP 78 and BCP 79. 573 Copies of IPR disclosures made to the IETF Secretariat and any 574 assurances of licenses to be made available, or the result of an 575 attempt made to obtain a general license or permission for the use of 576 such proprietary rights by implementers or users of this 577 specification can be obtained from the IETF on-line IPR repository at 578 http://www.ietf.org/ipr. 580 The IETF invites any interested party to bring to its attention any 581 copyrights, patents or patent applications, or other proprietary 582 rights that may cover technology that may be required to implement 583 this standard. Please address the information to the IETF at 584 ietf-ipr@ietf.org. 586 Acknowledgment 588 Funding for the RFC Editor function is provided by the IETF 589 Administrative Support Activity (IASA).