idnits 2.17.00 (12 Aug 2021) /tmp/idnits31064/draft-xia-ccamp-gmpls-call-application-00.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 518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 491. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (October 24, 2008) is 4950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4974' is mentioned on line 139, but not defined == Outdated reference: draft-ietf-ccamp-gmpls-vcat-lcas has been published as RFC 6344 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network work group Hongmiao Xia 2 Internet Draft Jianhua Gao 3 Intended status: Informational Fatai Zhang 4 Expires: April 2009 Huawei Technologies Co.,Ltd 5 October 24, 2008 7 Call Parameter Negotiation with GMPLS Calls 8 draft-xia-ccamp-gmpls-call-application-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 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-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 April 24, 2009. 35 Abstract 37 This document defines the use of Generalized Multi-Protocol Label 38 Switching (GMPLS) Calls for parameter negotiation in Automatically 39 Switched Optical Networks (ASON) and Wavelength Switched Optical 40 Networks (WSON). The intention of the document is to provide a 41 reference for the authors of future documents to understand the 42 application of GMPLS Calls. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119 [RFC2119]. 50 Table of Contents 52 1. Introduction.................................................2 53 2. Problem Statement............................................3 54 2.1. Connection-Adaptation Negotiation for Ethernet Service..3 55 2.2. Service Parameter Negotiation in WSON...................4 56 3. Process of negotiation.......................................5 57 4. Example of required information for negotiation..............6 58 4.1. CONNECTION_ADAPTER information..........................6 59 4.1.1. FRAMING Sub-object.................................6 60 4.1.2. VCAT Sub-object....................................7 61 4.2. SERVICE_ATTRIBUTE information...........................7 62 4.2.1. CODE Sub-object....................................8 63 4.2.2. FEC Sub-object.....................................9 64 5. Security Considerations......................................9 65 6. Manageability Considerations................................10 66 7. IANA Considerations.........................................10 67 8. References..................................................10 68 9. Authors' Addresses..........................................11 69 Intellectual Property Statement................................11 70 Disclaimer of Validity.........................................12 71 Full Copyright Statement.......................................12 72 Acknowledgment.................................................12 74 1. Introduction 76 The concept of a Generalized Multi-Protocol Label Switching (GMPLS) 77 Call is introduced in [RFC 4974]. A Call is an agreement between 78 endpoints possibly in cooperation with the nodes that provide access 79 to the network. It is used to facilitate and manage a set of 80 Connections (that is, Label Switching Paths - LSPs) that provide end- 81 to-end data services. It may be established and maintained 82 independently of the Connections that it supports. Call setup may 83 include capability exchange, policy, authorization, and security. 84 This document defines the use of Call for parameter negotiation with 85 specific reference to its use in Automatically Switched Optical 86 Networks (ASON) and Wavelength Switched Optical Networks (WSON). The 87 intention of the document is to provide a reference for the authors 88 of future documents to understand the application of GMPLS Calls. 90 2. Problem Statement 92 A Call is an agreement between endpoints possibly in cooperation with 93 the nodes that provide access to the network. Call setup may include 94 capability exchange, policy, authorization, and security. In this 95 document, we will describe the use of GMPLS Call in parameter 96 negotiation. 98 In some scenarios, service attributes have an effect on connection 99 setup. Because equipment from different vendors may have different 100 capabilities, a connection SHOULD only transit the nodes that all 101 support the attributes required by a connection. IGP extension could 102 solve this problem by advertising the attributes and capabilities of 103 all network nodes, but this would increase the burden on the control 104 plane. It is a good choice to introduce the function of parameter 105 negotiation into GMPLS Calls to deal with this kind of problem. In 106 the following subsection, two scenarios are presented. 108 2.1. Connection-Adaptation Negotiation for Ethernet Service 110 For Ethernet services over a transport network there is a key step to 111 adapt Ethernet frames into transport channels. This must be done 112 between the server edge nodes. The adaptation policy between ingress 113 and egress edge nodes must be consistent. These adaptation policies 114 include: 116 1) Encapsulation protocol at the edge node. This is responsible for 117 packet encapsulation, framing and rate adaptation. Examples 118 include GFP (Generic Framing Procedure), LAPS (Link Access 119 Procedure for SDH), HDLC (High Level Data Link Control protocol), 120 etc. 122 2) Connection type and connection number used by the edge node. 123 There are standard Contiguous Concatenation and Virtual 124 Concatenation (VCAT) schemes in SDH networks. The maximum 125 connection number of concatenation is different for different 126 devices and different signals when VCAT is used. So it is 127 necessary to negotiate the parameters of VCAT. This is described 128 in [VCAT-LCAS]. 130 3) Flow control. When traffic increases in a burst, flow control can 131 be enabled. The ingress edge node can negotiate with the egress 132 edge node whether to start flow control in this case, and how to 133 apply the necessary control. 135 All of these adaptation policies can be configured through the 136 Management Plane. However, in the case of a large number of services, 137 it is hard to perform fault localization when a configuration error 138 has occurred. So it is more flexible to introduce dynamic parameter 139 negotiation into this service. [RFC 4974] allows the Call and 140 Connection to be isolated so that the Connection can be established 141 with the correct connection-adaptation parameters according to the 142 result of parameter negotiation on the Call. 144 For example, see the following figure, Figure 1. R1 and R2 are client 145 nodes connected to the ASON via Ethernet interfaces. N1 and N6 are 146 service access points. When R1 sends a Call request to N1 for 147 Ethernet service, N1 includes the local capabilities for connection- 148 adaptation to the Call as request parameters. For example, supporting 149 GFP/LAPS, supporting VC-4-xc (x=1/4/16), supporting VCAT/LCAS, 150 supporting VC-4-xv(x=1-7) and the relevant connecting address. When 151 N6 receives the Call containing the connection-adaptation parameters, 152 it checks local capabilities and applies local policies. In the Call 153 response message, N6 will put the mapped capability as connection- 154 adaptation parameters. If no mapped capability can be found, then N6 155 will reject the Call and return corresponding reason. 157 +----+ +----+ 158 +-| N2 |---| N3 |-+ 159 / +----+ +----+ \ 160 / \ 161 +----+ +----+ +----+ +----+ 162 | R1 |--| N1 | | N6 |--| R2 | 163 +----+ +----+ +----+ +----+ 164 \ / 165 \ +----+ +----+ / 166 +-| N4 |---| N5 |-+ 167 +----+ +----+ 169 Figure 1: A Simple ASON Network 171 2.2. Service Parameter Negotiation in WSON 173 OTU is an important technology used to perform standard lambda 174 conversion in WDM systems. It exists in OTM and REG. 176 Coded Modulation is a key technique in long distance and high speed 177 Optical Transmission Systems. As different codes have distinct 178 capabilities against noise, dispersion and non-linear distortion, the 179 maximum transmission distance will be extended without redundant 180 devices if an appropriate code is selected. Currently, OOK (On-Off 181 Keying Modulation), PSK (Phase Shift Keying Modulation) and PoISK 182 (Polarization-shift keying Modulation) are the most common modulation 183 techniques. In the establishment of a light path, it is necessary to 184 ensure that the Coded Modulation is consistent at each OTU. 186 FEC is a technique to improve the system performance and reduce the 187 cost of the system and extend the transmission distance by adding 188 redundant error-correcting code to transmission code-sequence and 189 thus reduce the SNR (Signal Noise Ratio) demand at receiver. In-band 190 FEC and simple out-band FEC are used in general WDM systems. In ULH 191 (Ultra-Long Haul) system, EFEC (Enhanced FEC) and SuperFEC are used 192 to achieve higher coding-gain. OTU with different FECs can not 193 understand each other. In-band FEC and simple out-band FEC have now 194 been standardized. Vendors MAY have different code in EFEC and 195 SuperFEC. Only the same code used in OTU can the service be 196 established. 198 For the reasons stated above, it is necessary to verify and negotiate 199 the attributes of Coded Modulation, FEC mode and code. Otherwise a 200 connection can be established with enough resource, but be unable to 201 bear service. 203 Some of these service attributes in OTU can be modified by 204 configuration. For example, the port can be configured to disable FEC, 205 or enable standard FEC, or EFEC. Generally, the light path is 206 computed by the control plane in WSON, and it is not suitable to do 207 the configuration manually. So it is necessary to add a key step 208 during path establishment in WSON to negotiate and configure the 209 service attributes. 211 3. Process of negotiation 213 The process for Call parameter negotiation SHOULD comply with the 214 Call procedures which are described in [RFC4974]. The node that 215 initiates the call puts the parameters that need to be negotiated in 216 a CALL_Attributes object [MLN-EXT] in the Notify message that signals 217 the Call request. It also lists all parameters and corresponding 218 value that it supports. 220 Some parameters are negotiated between ingress and egress, while 221 others should be negotiated among all domain border nodes in the path. 222 Which kind of negotiation is selected is out of scope in the document. 224 When a node receives a call request Notify message including a 225 CALL_Attributes object with a parameter that needs to be negotiated, 226 it checks whether any of the values listed are supported. 228 o If none of the values is supported, then the receiver MUST reject 229 the call and generate a Notify message in response. 231 o If only parts of the values are not supported, then the receiver 232 can accept the call and modify the parameter by deleting the 233 values not supported. The remaining values are returned in the 234 Notify message that accepts the call. 236 o If all the values are supported, then the parameters are not 237 modified and are returned in the Notify message that accepts the 238 call. 240 When the call setup is complete, the ingress node will receive the 241 parameters that are supported by all nodes that participate in call 242 setup. It can select the preferred values with which to setup the LSP. 244 4. Example of required information for negotiation 246 This section describes the required information for parameter 247 negotiation for the problem presented above. 249 4.1. CONNECTION_ADAPTER information 251 The CONNECTION_ADAPTER information, which is suggested to be a sub- 252 object of CALL_Attributes object, is introduced to support 253 negotiation for Ethernet connection and adaptation during Call setup. 254 It MAY be included in a Notify message used for Call setup. This 255 optional information includes the link-local preference of connection 256 and adaptation for Ethernet service. The Call-initiating node MAY add 257 this information to a Notify message presenting the transport 258 parameter. Receiving this message, the Call-terminating node checks 259 the CONNECTION_ADAPTER information and match with local policy then 260 return its choice also in the CONNECTION_ADAPTER information. 262 The contents of the CONNECTION_ADAPTER information is defined as a 263 series of variable-length data items called sub-objects. The sub- 264 object format is defined as follows: 266 4.1.1. FRAMING Sub-object 268 FRAMING Sub-object indicates the encapsulation protocol that the 269 Call-initiating node (or Call-terminating node) preferred. 271 This Sub-object has the following format: 273 Type = TBD, Length = 4 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Flags |L|G| 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 The following flags are currently defined. All other values are 284 reserved. 286 G (GFP - 1bit): When this flag is set, it means that the node 287 supports GFP encapsulation. 289 L (LAPS - 1bit): When this flag is set, it means that the node 290 support LAPS encapsulation. 292 Other flags are reserved and MUST be set to zero. 294 4.1.2. VCAT Sub-object 296 The information related to VCAT is already defined in VCAT TLV object 297 in [VCAT-LCAS] and the VCAT TLV object included in the 298 CALL_Attributes object implies that the initiating node supports VCAT 299 capability. 301 4.2. SERVICE_ATTRIBUTE information 303 The SERVICE_ATTRIBUTE information, which is suggested to be a sub- 304 object of CALL_Attributes object, is introduced to support 305 negotiation for the service attributes of OTU during Call setup such 306 attributes include service type, Coded Modulation, FEC mode and code. 307 It MAY be included in a Notify message used for Call setup. This 308 optional information includes the preference attribute of local OTU. 309 Call-initiating node MAY add this information to a Notify message 310 presenting the transport parameter of the OTU on OTM. Receiving this 311 message, OTU on REG and OTM checks the SERVICE_ATTRIBUTE information 312 and match with local policy then modify the information according to 313 its choice. If the last OTU has matched service attribute, then 314 returned Call message presents the negotiated parameter. If one of 315 the OTU has some service attribute no matched, then return failed 316 message. 318 The contents of the SERVICE_ATTRIBUTE information is defined as a 319 series of variable-length data items called sub-objects. The sub- 320 object format is defined as follows: 322 4.2.1. CODE Sub-object 324 This Sub-object has the following format: 326 Type = TBD, Length = 4 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | OOK mode |N|R| PSK mode|E|Q|D| PoISK mode |D| Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 OOK mode (On-Off Keying): 8it. The following flags for OOK are 337 currently defined. All other values are reserved. 339 N - NRZ, Non Return to Zero Modulation 341 R - RZ, Return to Zero Modulation 343 PSK mode (Phase Shift Keying): 8it. The following flags for PSK are 344 currently defined. All other values are reserved. 346 E - 8-DPSK, Differential 8-level Phase Shift Keying Modulation 348 Q - DQPSK, Differential Quadrature Phase Shift Keying Modulation 350 D - DPSK, Differential Phase Shift Keying Modulation 352 PoISK mode (Polarization-shift keying Modulation): 8it. The following 353 flag for PoISK is currently defined. All other values are reserved. 355 D - DpolSK, Duobinary Polarization-shift keying 357 The code Sub-object is the Coded Modulation method that supported by 358 OTU. The head OTU node initiates a call and set all code it supported. 359 The following OTU node along the path check the code, if some code 360 can not be support, then the corresponding bit will be cleared in the 361 Sub-object. If no one bit is set, it means the call failed. 363 4.2.2. FEC Sub-object 365 This Sub-object has the following format: 367 Type = TBD, Length = 8 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Standard |I|O| EFEC |E| 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | SuperFEC |S| Reserved | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Standard (16 bits): The following flags are currently defined. All 380 other values are reserved. 382 I - In-band FEC supported 384 O - Out-band FEC supported 386 EFEC (16 bits): The following flag is currently defined. All other 387 values are reserved. 389 E - Extended FEC supported. Now there is one Extended FEC method. 391 SuperFEC (16 bits): The following flag is currently defined. All 392 other values are reserved. 394 S - Super FEC supported. Now there is one Super FEC method. 396 This Sub-object is the FEC method that supported by OTU. The head OTU 397 node initiates a call and set all FEC it supported and needed in the 398 connection. The following OTU node along the path check the FEC, if 399 some FEC can not be supported, then the corresponding bit will be 400 cleared in the Sub-object. If no one bit is set, it means the call 401 failed. 403 5. Security Considerations 405 This document describes some applications for GMPLS Calls whose 406 mechanisms are described in [RFC4974]. It just introduces some new 407 Sub-objects for CALL_Attributes object which is described in [MLN-EXT] 408 and it does not introduce any new signaling messages. So this 409 document does not introduce any additional security considerations. 411 6. Manageability Considerations 413 TBD. 415 7. IANA Considerations 417 TBD. 419 8. References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC4974] D. Papadimitriou, A. Farrel, "Generalized MPLS (GMPLS) 425 RSVP-TE Signaling Extensions in Support of Calls ", RFC 426 4974, August 2007. 428 [VCAT-LCAS] G. Bernstein, D. Caviglia, R. Rabbat, H. van Helvoort, '' 429 Operating Virtual Concatenation (VCAT) and the Link 430 Capacity Adjustment Scheme (LCAS) with Generalized Multi- 431 Protocol Label Switching (GMPLS)'', draft-ietf-ccamp-gmpls- 432 vcat-lcas-05.txt, Work in Progress, July 2008. 434 [MLN-EXT] Dimitri Papadimitriou et al.,''Generalized Multi-Protocol 435 Label Switching (GMPLS) Protocol Extensions for Multi-Layer 436 and Multi-Region Networks (MLN/MRN) Generalized Multi- 437 Protocol Label Switching (GMPLS) Protocol'', Work in 438 Progress, ''draft-ietf-ccamp-gmpls-mln-extensions-02.txt'' 440 9. Authors' Addresses 442 Hongmiao Xia 443 Huawei Technologies 444 F3-5-B R&D Center, Huawei Base 445 Bantian Longgang District 446 Shenzhen 518129 P.R.China 448 Phone: +86-755-28971048 449 Email: xiahongmiao@huawei.com 451 Jianhua Gao 452 Huawei Technologies 453 F3-5-B R&D Center, Huawei Base 454 Bantian Longgang District 455 Shenzhen 518129 P.R.China 457 Phone: +86-755-28972912 458 Email: gjhhit@huawei.com 460 Fatai Zhang 461 Huawei Technologies 462 F3-5-B R&D Center, Huawei Base 463 Bantian Longgang District 464 Shenzhen 518129 P.R.China 466 Phone: +86-755-28972912 467 Email: zhangfatai@huawei.com 469 Intellectual Property Statement 471 The IETF takes no position regarding the validity or scope of any 472 Intellectual Property Rights or other rights that might be claimed to 473 pertain to the implementation or use of the technology described in 474 this document or the extent to which any license under such rights 475 might or might not be available; nor does it represent that it has 476 made any independent effort to identify any such rights. Information 477 on the procedures with respect to rights in RFC documents can be 478 found in BCP 78 and BCP 79. 480 Copies of IPR disclosures made to the IETF Secretariat and any 481 assurances of licenses to be made available, or the result of an 482 attempt made to obtain a general license or permission for the use of 483 such proprietary rights by implementers or users of this 484 specification can be obtained from the IETF on-line IPR repository at 485 http://www.ietf.org/ipr. 487 The IETF invites any interested party to bring to its attention any 488 copyrights, patents or patent applications, or other proprietary 489 rights that may cover technology that may be required to implement 490 this standard. Please address the information to the IETF at 491 ietf-ipr@ietf.org. 493 Disclaimer of Validity 495 This document and the information contained herein are provided on an 496 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 497 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 498 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 499 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 500 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 501 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 503 Full Copyright Statement 505 Copyright (C) The IETF Trust (2008). 507 This document is subject to the rights, licenses and restrictions 508 contained in BCP 78, and except as set forth therein, the authors 509 retain all their rights. 511 This document and the information contained herein are provided on 512 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 513 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 514 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 515 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 516 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 517 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 518 FOR A PARTICULAR PURPOSE. 520 Acknowledgment 522 Funding for the RFC Editor function is currently provided by the 523 Internet Society.