idnits 2.17.1 draft-asveren-dime-cong-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 582. ** 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 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 RFC 3978 Section 5.4 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 (January 10, 2007) is 6315 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 521, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (ref. '1') (Obsoleted by RFC 6733) Summary: 4 errors (**), 0 flaws (~~), 2 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 Ulticom Inc. 4 Intended status: Informational V. Fajardo 5 Expires: July 14, 2007 January 10, 2007 7 Diameter Congestion Signaling 8 draft-asveren-dime-cong-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work 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 This Internet-Draft will expire on July 14, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2007). 39 Abstract 41 Diameter base protocol defines the network layer functionality to be 42 used by applications. This document adds hop-to-hop congestion 43 notification mechanism to that functionality. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3.1. Congestion of Intermediaries . . . . . . . . . . . . . . . 4 51 3.2. Multiple Applications On the Same Node . . . . . . . . . . 4 52 3.3. Congestion Detection Time . . . . . . . . . . . . . . . . 4 53 3.4. Notification of Congestion Abatement . . . . . . . . . . . 5 54 3.5. Multiple Congestion Levels . . . . . . . . . . . . . . . . 5 55 3.6. Shortcomings of Transport Layer Congestion Indications . . 5 56 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Hop-To-Hop Congestion Notification Mechanism . . . . . . . . . 6 58 5.1. Congestion Level Signaling Procedures . . . . . . . . . . 6 59 5.1.1. Sending Congestion Information . . . . . . . . . . . . 6 60 5.1.2. Receiving Congestion Information . . . . . . . . . . . 7 61 5.1.3. Local Congestion Level Determination Guidelines . . . 7 62 5.1.4. Preventing Unnecessary Retransmission . . . . . . . . 8 63 5.2. Congestion-Level AVP . . . . . . . . . . . . . . . . . . . 9 64 5.3. Error Answers . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. Providing Hysteresis for Local Congestion Level 67 Decision . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.2. Congestion Level 1 . . . . . . . . . . . . . . . . . . . . 11 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 72 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Introduction 78 Diameter base protocol defines the network layer functionality to be 79 used by applications. Requests are routed based on Destination-Host 80 AVP, Destination-Realm AVP, Application-Id values and the status of 81 Diameter connections to neighboring peers. 83 This document defines a new AVP to be used by peers to notify their 84 neighbors about their congestion status, so that this information can 85 be used while routing requests. It is left up to the implementation 86 to decide for local congestion levels but some guidelines are 87 provided to prevent undesirable situations like oscilliation. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [2]. 95 The following terms defines the functionality used in describing 96 entities in this document. 98 Congestion 100 The situation on a Diameter node, where the current load is above 101 the normal operational limits and effects processing of messages. 102 A node which suffers from congestion should not be sent certain 103 messages depending on the severity of congestion to prevent it to 104 be overloaded further. 106 Congestion level 108 A numeric value used to quantify the severity of congestion o a 109 Diameter node. This value is generalized in this document and not 110 meant to be an exhaustive indicator of all possible variables that 111 can define congestion. The possible numeric values for congestion 112 level is defined in Section 5.2. 114 Congestion state 116 Congestion state pertains to the congestion level and other 117 relevant information that a diameter node keeps about each of its 118 neighboring peers. 120 3. Motivation 122 When routing Diameter messages, it is preferable to consider the 123 congestion status of peers to increase the response time of answers 124 and to prevent overloading of nodes. A method of signaling the 125 congestion state among adjacent peers independent of any applications 126 will allow for a more real-time, self correcting method of reducing 127 and or distributing load among diameter neighbors. 129 There are several scenarios where relying on an application level 130 result code is not efficient to notify peers about congestion status 131 changes. The succeeding sections provides applicability scenarios 132 for requiring per hop congestion status signaling. 134 3.1. Congestion of Intermediaries 136 In a Diameter network, intermediate nodes such as relay agents, 137 proxies, may be present. Such nodes may get congested and it is 138 desirable to consider their congestion status when selecting the next 139 hop node. 141 Intermediate nodes do not host the application logic to process a 142 request completely and do not generate answers except routing 143 failures for the requests they receive. Generating a result code of 144 "TOO_BUSY_HERE" to notify about intermediate congestion is not 145 appropriate because it indicates congestion of the server specified 146 in the Destination-Host AVP or in general the logical application 147 service identified by Destination-Realm AVP and Application-Id. It 148 is therefore limited to diameter application end-points and does not 149 consider the congestion state of intermediaries and other application 150 traffic routed through them. 152 3.2. Multiple Applications On the Same Node 154 A Diameter node may host multiple applications simultaneously. 155 Although it is possible to aggregate congestion status of the node on 156 application logic level, it may be preferable to do this on a 157 centralized logical entity like the Diameter base protocol in a 158 layered architecture. A hop-to-hop message generated and consumed by 159 base protocol layer would be more suitable for such a task split 160 between different layers. 162 3.3. Congestion Detection Time 164 Relying on congestion notification via application level result code 165 is inherently a reactive mechanism. This requires that an 166 application level request needs to be received for congestion 167 notification to be sent on the answer. 169 This problem can be aggravated in configurations such as diameter 170 servers which are communicating with multiple peers. A highly 171 congested server can signal its congestion state to other peers only 172 when those peers send a request to the server. 174 3.4. Notification of Congestion Abatement 176 Currently, there is no existing method of signaling an end of 177 congestion. Peers may probe the congested node periodically with new 178 requests and can decide based on the result code of the corresponding 179 answer whether congestion has abated. However, such method is not 180 effective if peers have no application level request to send and 181 therefore suffers the same drawbacks as Section 3.3. A hop-to-hop 182 congestion indication message could provide notification of 183 congestion abatement immediately. 185 3.5. Multiple Congestion Levels 187 A congestion result code provides only a single congestion level of 188 "congested." For certain configurations it may be desirable to 189 provide multiple congestion levels. Especially for the cases where 190 load information is to be used for loadsharing purposes, multiple 191 levels are desirable. 193 3.6. Shortcomings of Transport Layer Congestion Indications 195 Diameter uses TCP and SCTP as transport protocols between adjacent 196 entities. Although the concept of receiver congestion is present in 197 those protocols there are some reasons, which make their use 198 unsuitable for Diameter congestion detection purposes: 200 o It is not straightforward to learn the current status of receiver 201 windows with sockets API, which is the defacto standard for 202 applications to access services of TCP and SCTP in common 203 operating systems. For TCP, applications can be aware of 204 congestion only when the receiver window is full. For SCTP, 205 application need to poll the status of receiver window, there is 206 no trigger mechanism present. 208 o Propogation of congestion may take longer than desired. 209 Congestion will be visible on sender side only after it propogated 210 to transport protocol layer, which may require multiple queues to 211 be filled first on receiver side. 213 o When congested node has multiple connections, the receiver window 214 for each connection needs to be full, i.e. if a node does not send 215 messages to the congested node, it won't be able to learn about 216 its congestion status or not before sending enough messages to 217 fill the receiver window. 219 4. Scope 221 This document defines mechanisms to communicate congestion 222 information in a hop-by-hop fashion. This information can be used to 223 protect overloaded nodes against further traffic being sent to them 224 and to loadshare requests among multiple endpoints. Although the 225 strategy mainly relies on hop-by-hop communication, it also defines 226 new result codes to be used in an end-to-end fashion to prevent 227 unnecessary request retransmission on base protocol level in case of 228 congested nodes/services. 230 5. Hop-To-Hop Congestion Notification Mechanism 232 5.1. Congestion Level Signaling Procedures 234 5.1.1. Sending Congestion Information 236 A Diameter node sends a Congestion-Level AVP in a Device Watchdog 237 Request message to its adjacent neighbors to indicate its current 238 congestion level. 240 A node's congestion level SHOULD fall into one of the congestion 241 levels defined in Section 5.2. A diameter node SHOULD send a DWR to 242 its neighboring peers as soon as it determines that its congestion 243 level changes. Sending the DWR message with Congestion-Level AVP as 244 soon as congestion level changes is important so that adjacent nodes 245 can stop sending new requests to the congested node to prevent it to 246 get further overloaded. 248 In the case where a new peer attempts to connect to an existing node 249 supporting congestion control signaling, the Congestion-Level AVP 250 Section 5.2 may also be sent by the node in the CEA message to 251 immediately indicate to the new peer of the nodes congestion state. 252 This is in the case where the existing peer is already experiencing 253 high levels of congestion and would want to notify any new peer 254 immediately rather than sending a DWR which has an inherent latency. 256 When a node receives a request and the node already notified its 257 neighbors that it is unable to handle new requests, the node MAY 258 silently drop the request or MAY send back an error answer with 259 result code DIAMETER_CONGESTED. 261 5.1.2. Receiving Congestion Information 263 A peer receiving a Congestion-Level AVP in a DWR SHOULD create and 264 maintain congestion state for the sender of the DWR if it has not 265 already done so. The congestion state should at least contain the 266 currently advertised congestion state of the peer. 268 The receiver of the DWR should react according to the congestion 269 level information provided by the Congestion-Level AVP, i.e. it 270 SHOULD NOT send messages which are not allowed by the corresponding 271 congestion level. 273 It SHOULD be expected that Nodes MAY advertise congestion levels non- 274 sequentially, e.g. a node may first advertise CONGESTION_LEVEL_1 and 275 then CONGESTION_LEVEL_3. 277 In the case where a peer does not support congestion level based 278 request routing, it SHOULD ignore the presence of Congestion-Level 279 AVP in DWR, CER and CEA messages. Considering that M-bit is not set 280 for Congestion-Level AVP, this behavior is guaranteed by nodes 281 compliant to Diameter Base Protocol. 283 5.1.3. Local Congestion Level Determination Guidelines 285 Considering the vast amount of criteria which may be used as metrics 286 when determining congestion levels and different architectures, this 287 document does not mandate a mechanism to decide for different 288 congestion levels. 290 For sender of the Congestion-Level AVP, it is left up to the 291 implementation on determining the current congestion level of a 292 diameter node. The implementation may rely on the traffic rate, 293 processing load, backend call latency, storage/resource availability 294 etc. or any such combinations to determine the appropriate congestion 295 level. Deciding when congestion level changes on a node is also 296 implementation dependent but nodes SHOULD provide hysteresis between 297 onset and abatement values of the congestion levels. Note that 298 schemes to determine congestion level changes should not be very 299 sensitive so as not to trigger sending many DWR message causing 300 congestion control flapping among neighboring peers. 302 It is recommended that triggering of onset and abatement levels 303 should be deterministic. It should be noted that nodes MAY also 304 choose to use only a subset of the defined congestion level values, 305 e.g. a node MAY use only CONGESTION_LEVEL_0 and CONGESTION_LEVEL_3 306 values to indicate a binary state of congested or not congested. 308 Diameter nodes SHOULD NOT send DWR messages with Congestion-Level AVP 309 very frequently, for example more than once a second. Frequent DWR 310 transmissions has the adverse side effect of triggering false 311 disconnection indication if the receiver is highly congested and 312 cannot send a DWA within the appropriate time. In the case that a 313 disconnection indication does occur due to failed DWR/DWA exchanges 314 even if the DWR transmissions are set to an acceptable frequency, 315 then the peers should follow the normal disconnection process 316 specified in RFC3588. 318 It is RECOMMENDED that nodes change their congestion state and notify 319 their neighbors before congestion gets severe enough to cause 320 significant problems for the processing of pending and on the flight 321 requests. 323 5.1.4. Preventing Unnecessary Retransmission 325 If an adjacent node to an endpoint, e.g. a relay agent or a proxy, is 326 notified that the endpoint is unable to handle new requests, there is 327 no need that the same request is retransmited via an alternate route 328 as shown in Figure 1. In such a situation, the adjacent node SHOULD 329 reply back with an error answer with result code 330 DIAMETER_ENDPOINT_CONGESTED. The Origin-Host AVP MUST be populated 331 with the identity of the congested endpoint and Error-Reporting-Host 332 AVP MUST contain the identity of the error reporting host. 334 (3)----REQ1-----> 336 (4)<-ANS1(UNABLE)- 337 TO DELIVER) 338 +--------+(1) <--DWR(Level2)- 339 | | 340 +--------+ +-------+ Relay +-----+ 341 | +--+ | Agent 1| | +--------+ 342 | Client | +--------+ | | | 343 | +--+ +--------+ +-----+ Server | 344 +--------+ | | | +-----+ | 345 +-------+ Relay | | +--------+ 346 | Agent 2+-----+ 347 (5)----REQ1-----> +--------+(2) <--DWR(Level2)- 349 (6)<-ANS1(UNABLE)- 350 TO DELIVER) 352 Figure 1: Unnecessary message retransmission during congestion 354 Similarly if a node adjacent to all endpoints providing service for a 355 specific application in a realm has received congestion level updates 356 from all of them indicating that they are unable to handle new 357 requests, the node SHOULD reply back with an 358 DIAMETER_SERVICE_CONGESTED error answer, if it receives a request 359 without Destination-Host AVP. The Origin-Host AVP MUST be populated 360 with the identity of the error reporting host. It should be noted 361 that nodes should generate this error answer if and only if they are 362 sure that they have a connection to all of the endpoints providing 363 the service for the corresponding realm. Otherwise an error answer 364 with result code "UNABLE_TO_DELIVER" SHOULD be returned. 366 5.2. Congestion-Level AVP 368 Congestion-Level AVP is of type Enumerated and indicates the 369 congestion level of a node. The following values are defined for 370 Congestion-Level AVP: 372 CONGESTION_LEVEL_0 0 374 This value indicates that the load on the sender node is below the 375 manageable limit and the node is ready to handle new messages. 377 CONGESTION_LEVEL_1 1 379 This value indicates that the load on the sender node is below the 380 manageable limit but requests for new sessions SHOULD be sent 381 preferrably to other nodes. 383 CONGESTION_LEVEL_2 2 385 This value indicates that no requests for new sessions SHOULD be 386 sent to the node. A node in this state MAY drop request messages 387 for new sessions. However, requests for existing sessions and 388 answer messages still SHOULD be sent to the node. 390 CONGESTION_LEVEL_3 3 392 This value indicates that no new requests SHOULD be sent to the 393 node even if they are requests for existing sessions. A node in 394 this state MAY drop received request messages. 396 CONGESTION_LEVEL_4 4 398 This value indicates that no new messages (neither requests nor 399 answers) SHOULD be sent to the node. A node in this state MAY 400 drop any received message. 402 5.3. Error Answers 404 This document defines a new result code of protocol error class: 406 DIAMETER_CONGESTED 3011 A request has been received and the 407 congestion state of the receiver node is not suitable to process 408 the request. 410 DIAMETER_ENDPOINT_CONGESTED 3012 A request with a Destination-Host 411 AVP is received, the destination of the request is an adjacent 412 node and already declared that it is unable to handle new 413 requests. 415 DIAMETER_APPLICATION_CONGESTED 3013 A request without a Destination- 416 Host AVP is received, it is known that all potential endpoints for 417 the request declared that they are unable to handle a new request. 419 6. Examples 421 6.1. Providing Hysteresis for Local Congestion Level Decision 423 This example assumes a local congestion level decision policy based 424 on the number of messages in an incoming queue. The node decides for 425 a maximum number of 1024 pending requests. This number could be 426 based on the processing power of the node, the nature of the 427 application and the expected message rate. The following figure 428 displays possible onset/abatement values for different congestion 429 levels. 431 +----+ 1023 432 |----| 433 |----| 434 |----| 435 |----|768 <--- Congestion Level4 Onset 436 |----| 437 |----|640 <--- Congestion Level4 Abatement 438 |----|576 <--- Congestion Level3 Onset 439 |----| 440 |----|448 <--- Congestion Level3 Abatement 441 |----|384 <--- Congestion Level2 Onset 442 |----| 443 |----|256 <--- Congestion Level2 Abatement 444 |----|192 <--- Congestion Level1 Onset 445 |----| 446 |----| 64 <--- Congestion Level1 Abatement 447 +----+ 0 448 Figure 2: Congestion Onset/Abatement Levels 450 The difference between onset and abatement levels for the same 451 congestion level is necessary to provide hysteresis so that 452 congestion level does not change frequently between two levels. 454 6.2. Congestion Level 1 456 The following scenario assumes a configration, where a relay agent is 457 distributing traffic to two servers. It is assumed that the service 458 consists of a single transaction, i.e. all requests belong to 459 different sessions. 461 After Server2 declares that if there is some other server present, it 462 should be preferred for new requests, relay agent stops loadsharing 463 new requests among Server1 and Server2 and sends all new requests to 464 Server1. When congestion state on Server2 is back to normal, Relay 465 Agent continues to loadshare new requests among both servers. 467 Relay 468 Agent Server1 Server2 469 | | | 470 | | | 471 |------REQ1------>| | 472 | | | 473 |<-----ANS1-------| | 474 | | | 475 |------------REQ2------------->| 476 | | | 477 |<-----------ANS2--------------| 478 | | | 479 |<-----DWR(Cong. Level 1)------| 480 | | | 481 |-----------DWA--------------->| 482 | | | 483 |-----REQ3------->| | 484 | | | 485 |<----ANS3--------| | 486 | | | 487 |-----REQ4------->| | 488 | | | 489 |<----ANS4--------| | 490 | | | 491 |<----DWR(Cong. Level 0)-------| 492 | | | 493 |----------DWA---------------->| 494 | | | 495 |-----------REQ5-------------->| 496 | | | 497 |<----------ANS5---------------| 498 | | | 499 | | | 501 Figure 3: Congestion Level 1 Being Used in Loadsharing 503 7. IANA Considerations 505 IANA is to assign new AVP codes for Congestion-Level AVP defined in 506 Section 5.2. 508 8. Security Considerations 510 This document does not contain a security protocol; it describes 511 extensions to the existing Diameter protocol. All security issues of 512 DIAMETER protocol must be considered in implementing this 513 specification. This extension does not add any unique concerns. 515 9. Acknowledgments 517 The authors wish to thank Bernard Aboba for his invaluable comments. 519 10. Normative References 521 [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 522 "Diameter Base Protocol", RFC 3588, September 2003. 524 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 525 Levels", BCP 14, RFC 2119, March 1997. 527 Authors' Addresses 529 Tolga Asveren 530 Ulticom Inc. 531 1020 Briggs Road 532 Mount Laurel, NJ, 08054 533 USA 535 Email: asveren@ulticom.com 537 Victor Fajardo 538 One Telcordia Drive 539 Piscataway, NJ 08854 540 USA 542 Email: vfajardo@tari.toshiba.com 544 Full Copyright Statement 546 Copyright (C) The Internet Society (2007). 548 This document is subject to the rights, licenses and restrictions 549 contained in BCP 78, and except as set forth therein, the authors 550 retain all their rights. 552 This document and the information contained herein are provided on an 553 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 554 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 555 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 556 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 557 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 558 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 560 Intellectual Property 562 The IETF takes no position regarding the validity or scope of any 563 Intellectual Property Rights or other rights that might be claimed to 564 pertain to the implementation or use of the technology described in 565 this document or the extent to which any license under such rights 566 might or might not be available; nor does it represent that it has 567 made any independent effort to identify any such rights. Information 568 on the procedures with respect to rights in RFC documents can be 569 found in BCP 78 and BCP 79. 571 Copies of IPR disclosures made to the IETF Secretariat and any 572 assurances of licenses to be made available, or the result of an 573 attempt made to obtain a general license or permission for the use of 574 such proprietary rights by implementers or users of this 575 specification can be obtained from the IETF on-line IPR repository at 576 http://www.ietf.org/ipr. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights that may cover technology that may be required to implement 581 this standard. Please address the information to the IETF at 582 ietf-ipr@ietf.org. 584 Acknowledgment 586 Funding for the RFC Editor function is provided by the IETF 587 Administrative Support Activity (IASA).