idnits 2.17.1 draft-dunbar-l4-l7-sc-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 11, 2013) is 3934 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Application-SDN' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'SC-Use-Case' is defined on line 571, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-liu-service-chaining-use-cases-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Nework working group L. Dunbar 2 Internet Draft D. Eastlake 3 Intended status: Informational Huawei 4 Expires: January 2014 6 July 11, 2013 8 Layer 4-7 Service Chain problem statement 9 draft-dunbar-l4-l7-sc-problem-statement-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 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) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 46 Internet-Draft Layer 4-7 Service Chain Problem Statement 48 Section 4.e of the Trust Legal Provisions and are provided 49 without warranty as described in the Simplified BSD License. 51 Abstract 53 This draft analyzes the taxonomy of Layer 4-7 Services and gives 54 two examples of Layer 4-7 service chain, one from a traffic 55 steering perspective and another one from a Layer 7 perspective. 56 The intent is to emphasize their unique issues and challenges. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 61 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 62 "OPTIONAL" in this document are to be interpreted as described in 63 RFC-2119 0. 65 The term "traffic steering" and "traffic forwarding" are used 66 interchangeably in this draft. 68 Table of Contents 70 1. Introduction ................................................. 3 71 2. Terminology .................................................. 3 72 3. Taxonomy of Layer 4-7 Services ............................... 3 73 3.1. Layer 4-7 Traffic Steering (or Forwarding)............... 4 74 3.2. Layer 4-7 Service Function .............................. 4 75 3.3. Service Module connection to Service Chain Steering 76 Points ....................................................... 5 77 4. Challenges of Service Chain from Traffic Steering Perspective .7 78 4.1. Challenges of Layer 4-7 traffic Steering................. 9 79 4.2. Challenge of traffic steering along service chain ....... 9 80 4.3. Challenges of Flow Marking for Service Chain ........... 10 81 4.4. Ways to Minimize Impact to Existing Network............. 10 82 5. Challenge of Service Chain from the Layer 7 Perspective ..... 13 83 6. Conclusion and Recommendation ............................... 13 84 7. Manageability Considerations ................................ 14 85 8. Security Considerations ..................................... 14 86 9. IANA Considerations ......................................... 14 87 10. Acknowledgments ............................................ 14 88 11. References ................................................. 14 89 Authors' Addresses ............................................. 15 90 Intellectual Property Statement ................................ 15 91 Disclaimer of Liability ........................................ 15 93 Internet-Draft Layer 4-7 Service Chain Problem Statement 95 1. Introduction 97 This draft analyzes the taxonomy of Layer 4-7 Services and gives 98 two examples of Layer 4-7 service chain, one from a traffic 99 steering perspective and another one from a Layer 7 perspective. 100 The intent is to emphasize their unique issues and challenges. 102 Layer 4-7 services and service chains have been discussed in many 103 forums, such as ETSI NFV, ONF, and IETF I2RS Interim meetings. 104 However, people from different background frequently have 105 different interpretations of Layer 4-7 services and service 106 chains. For example, network vendors tend to view "Layer 4-7 107 Service Chains" as forwarding (or steering) traffic to a sequence 108 of service modules based on Layer 4-7 fields, whereas Layer 4-7 109 vendors may view "service chains" as reassembling whole HTTP 110 messages (which could be in multiple data frames) and applying 111 the needed functions (e.g. Content Optimization or App Security) 112 based on some logics formulated from the message content. This 113 draft starts with analyzing the taxonomy Layer 4-7 services and 114 service chains. 116 2. Terminology 118 DPI Deep Packet Inspection 119 FW Firewall 121 3. Taxonomy of Layer 4-7 Services 123 Layer 4-7 Services can be broadly broken into two categories: 125 1) Layer 4-7 Traffic Steering: a functional module in a device 126 that forwards data packets received from one port to another port 127 based on Layer 4 to Layer 7 fields in the data packets. 129 2) Layer 4-7 Service Function: a functional module that performs 130 Layer 4 to 7 functions, such as Firewall, DPI, TCP accelerator, 131 NAT, etc. When Layer 4-7 service function is instantiated on a 132 standalone physical or virtual device, it is called Layer 4-7 133 Service module throughout this draft. Layer 4-7 functions can 135 Internet-Draft Layer 4-7 Service Chain Problem Statement 137 also be embedded in another device, such as router/switch or 138 other devices. 140 3.1. Layer 4-7 Traffic Steering (or Forwarding) 142 Layer 4-7 Traffic Steering (or forwarding) basically forwards 143 data packets received from one port to another port based on some 144 higher layer fields in the data packets. 146 There are multiple types of traffic steering: 148 - Fixed header based forwarding: traffic steering based on 149 header fields that have fixed position in the data 150 packets: 152 - Forwarding based on Layer 2-3 header fields, such as 153 MAC or IP Destination Address, MPLS label, or VLAN 154 ID. 156 - Forwarding based on Layer 4 header (TCP or UDP). 158 - QoS header based forwarding. 160 - Layer 7 based forwarding: traffic steering (or forwarding) 161 based on the payload (L7) of data packets. 163 Multiple data packets may carry some meaningful data, like 164 one HTTP message. Under this scenario, multiple data 165 packets have to be examined before meaningful data can be 166 extracted for making Layer 7 based forwarding decision. 168 Since routers/switches all forward data packets based Layer 2 or 169 3 header, for ease of description "Service Chain Steering Point 170 (or Node)" is used throughout this draft to refer to the entities 171 that steer traffic to a sequence of service modules. 173 Note: the Layer 4-7 traffic steering could also steer packets to 174 a service module that applies non-Layer4-7 functions. 176 3.2. Layer 4-7 Service Function 178 A Layer 4-7 Service Function, or service module if it is in a 179 standalone device or virtual device, performs a Layer 4 to 7 180 function based on packets received. One service module can 181 contain multiple service functions. Examples are: Firewall, DPI, 183 Internet-Draft Layer 4-7 Service Chain Problem Statement 185 TCP accelerator, NAT, etc. Service Module could be Proxy based or 186 Packet Based. Note the criteria to apply Layer 4-7 functions can 187 be based on Layer 2 or 3 fields of the data packets received. On 188 traditional routers/switches, there are Layer 2 or 3 service 189 functions, such as frame fragmentation and reassembly. Layer 2 or 190 3 service functions are out of the scope of this draft. 192 A Layer 7 service function can be very different from a Layer 4 193 service function. It is necessary to differentiate them. To be 194 specific, there are 196 - Layer 4 service function 197 - Layer 7 service function 198 - Layer 4 service function with some Layer 7 intelligence. 200 The service modules can be further distinguished by 202 - Proxy based service functions: these service functions 203 terminate original packets, may reassemble multiple packets, 204 reopen a new connection, or formulate new packets based on 205 the received packets. 207 - Packet based service functions: these service modules 208 maintain original packets, i.e. they don't make changes to 209 packets traversed through except possibly to metadata such as 210 VLAN tags. 212 An entity (physical or virtual device) that can forward packets 213 after one service module to another service module is considered 214 as having two functions: a Service Function integrated with a 215 Traffic Steering function. 217 3.3. Service Module connection to Service Chain Steering Points 219 Service modules can be connected to Service Chain steering points 220 (such as routers/switches) in various ways: 222 - A service module can be embedded in a traffic steering node 223 (i.e. embedded in a router or a switch). 225 Internet-Draft Layer 4-7 Service Chain Problem Statement 227 In this case, the service module doesn't need an address to 228 receive data packets. The forwarding entity can send packets 229 that meet the steering criteria directly to the service 230 module regardless of the destination addresses in the 231 packets. The Service module always sends the processed 232 packets back to the forwarding entity regardless of the 233 destination addresses in the packets. 235 - A service module can be one hop away from a traffic steering 236 node 238 The one hop between the Service Chain Steering node and the 239 service module can be a physical link (e.g. Ethernet link) or 240 one virtual tunnel (e.g. VxLAN). 242 If the one hop is a physical Ethernet link, there would be a 243 Link Header, i.e. an outer MAC header, added to the data 244 packets that meet the steering criteria, with MAC Source 245 Address being the Service Chain Steering Node and MAC 246 Destination Address being the Service module for packets from 247 the Service Chain Steering node to the service module. 249 For the reverse direction over this link, i.e. after the 250 service module process the packets, the MAC Source Address is 251 the Service Module and the MAC Destination Address is the 252 Service Chain Steering node. 254 The one hop link can be a transparent link, i.e. no link 255 address is added to the data packets on the link between the 256 Service Chain Steering node and Service Module. This scenario 257 is considered the same as a service module being embedded in 258 the Service Chain Steering node. 260 The one hop between the Service Steering node and a service 261 module can also be a tunnel, like a VxLAN tunnel. Under this 262 case, the tunnel header has to be added to the data packets 263 that meet the steering criteria for those packets to be sent 264 to the service modules. After the service module processes 265 the data packets, the Tunnel header has to be added to the 266 packets for them to be sent back to the Service Chain 267 Steering node. 269 Internet-Draft Layer 4-7 Service Chain Problem Statement 271 - A service module can be multiple hops away from a Service 272 Chain Steering node 274 4. Challenges of Service Chain from Traffic Steering Perspective 276 From user's perspective, the service chain is a sequence of 277 service functions, such as Chain#1 {s1, s4, s6}, Chain#2{s4, s7} 278 applied to a flow. A flow is loosely used in this document to 279 refer to a selective of packets that meet certain criteria. Some 280 users might not care at which points in the network the selected 281 flow is steered to those service modules as long as the sequence 282 of the service modules is correct. 284 From the traffic steering perspective, a Service Chain guarantees 285 that specific data flows go through a specific sequence of 286 service modules at designated points along the flow paths in the 287 network, as shown in the figure below. The service modules 288 perform some functions on the data packets in the flows, such as 289 Firewall, NAT, QoS insertion, etc. 291 Internet-Draft Layer 4-7 Service Chain Problem Statement 293 . @ 294 . @ 295 +--------------+ V V 296 | ..+<.......... +----+-------+-------+ 297 | Service 1 . | . | . @ | 298 | ..+....... .........+.... @@@@ | 299 +--------------+ . | @ | 300 ............>+... @ | 301 | . @ | 302 @@@@@@@@@@@@@+@@+@@@@ Traffic | 303 +--------------+ @ | . Steering | 304 | @@+<@@@@@@ @@@@@@@@@>+@@+@@@ Point | 305 | Service 2 @ | @ | . @ | 306 | @@+@@@@@@@@@@ +--+---+-------------+ 307 +--------------+ . @ 308 . @ 309 . @ 310 +----------------+ V V 311 | ..+<........... +--+---+-------------+ 312 | . | . | . @ | 313 | @@+@+<@@@@@@@ ......+.. @ | 314 | Service 3 @ . | @ | @ | 315 | @ ..+...... @@@@@@@@@@+@@@@@@ | 316 | @ | . | Traffic | 317 | @@@@+@@@ ...........>+... Steering | 318 +----------------+ @ | . Point | 319 @@@@@@@@@@@@@@>+@@+@@@ | 320 | . @ | 321 ............+... @@@@@ | 322 +--------------+ . | @ | 323 | ..+<....... .......>+.... @ | 324 | Service 4 . | . | . @ | 325 | ..+............ +----+-------+-------+ 326 +--------------+ . @ 327 . @ 328 V V 330 Figure 1: Simple Service Chain from Traffic Steering Point of 331 View 333 Internet-Draft Layer 4-7 Service Chain Problem Statement 335 4.1. Challenges of Layer 4-7 traffic Steering 337 Very often the criteria for steering flows to service modules are 338 based on higher layer headers, such as TCP header, HTTP header, 339 etc. 341 Most of deployed switches/routers are very efficient in 342 forwarding packets based on Layer 2 or Layer 3 headers, such as 343 MAC/IP destination addresses, or VLAN/MPLS labels but have 344 limited capacity for forwarding data packets based on higher 345 layer header. As of today, differentiating data packets based on 346 higher layer headers depends on ACLs (Access Control List field 347 matching) or DPI, both of which are relatively expensive and 348 extensive use of such facilities may limit the bandwidth of 349 switches/routers. 351 4.2. Challenge of traffic steering along service chain 353 From traffic steering point of view, one service chain consists 354 of: 356 - Identifier 357 - {Steering point List} 358 - Steering Point #1, {list of Service Modules} 359 - Steering Point #2, {list of Service Modules} 360 - ? 362 Two service chains with the same sequence of service modules but 363 different steering points should be considered as two different 364 service chains from traffic steering point of view. 366 Some service modules change values in data packets, such as NAT 367 changing the address fields. If any of those fields are used in 368 traffic steering along the service chain, the criteria can be 369 different before and after those the service modules. 371 Even though it is out of the scope of this draft, it is assumed 372 that the Service Chain Orchestration System can create service 373 chains in a way that allows each service chain to be shared by 374 many flows while maintaining optimized utilization of network 375 resources. 377 Internet-Draft Layer 4-7 Service Chain Problem Statement 379 4.3. Challenges of Flow Marking for Service Chain 381 The policy for associating flows with their service chains can be 382 complicated and could be dynamic. Sometimes it might not be 383 possible to predict what traffic is traversed through and which 384 paths traversed by. 386 The entity that is responsible for associating flows with their 387 specific service Chains is called Service Chain Marking 388 Functional Module in this document. The Service Chain Marking 389 Functional Module can encounter flows that don't match with any 390 policies. External entity (or controller) might be needed for a 391 Service Chain Marking Functional Module to make appropriate 392 decision. 394 Multiple flows can share one service chain. The criteria to 395 select flows to be associated with their service chain could be 396 different. For example, for one service chain "A" shared by Flow 397 X, Y, Z: 399 - Criteria for Flow X to the Service Chain "A" are TCP port 400 - Criteria for Flow Y to the Service Chain "A" are Destination 401 Address 402 - Criteria for Flow Z to the Service Chain "A" are MPLS label. 404 4.4. Ways to Minimize Impact to Existing Network 406 To minimize impact to deployed network elements 407 (switches/routers), traffic flows can be classified or marked 408 based on service chain requirement at network ingress edges, as 409 shown in the diagram below. 411 Internet-Draft Layer 4-7 Service Chain Problem Statement 413 \ \ \ / / / / 415 \ \ \ | / / / 416 \ \ | | | / / 417 +------------+ \ | | | | | / 418 | Controller |------\ +--+--+--+--+--+--+ 419 +------------+ \ | | 420 \----------->| SC Marking | 421 | . @ | 422 +----+-------+----+ 423 . @ 424 . @ 425 +--------------+ V V 426 | ..+<.......... +----+-------+-------+ 427 | Service 1 . | . | . @ | 428 | ..+....... .........+.... @@@@ | 429 +--------------+ . | @ | 430 ............>+... @ | 431 | . @ Service | 432 @@@@@@@@@@@@@+@@+@@@@ Chain | 433 +--------------+ @ | . Steering | 434 | @@+<@@@@@@ @@@@@@@@@>+@@+@@@ Point#1 | 435 | Service 2 @ | @ | . @ | 436 | @@+@@@@@@@@@@ +--+---+-------------+ 437 +--------------+ . @ 438 . @ 439 . @ 440 +----------------+ V V 441 | ..+<........... +--+---+-------------+ 442 | . | . | . @ | 443 | @@+@+<@@@@@@@ ......+.. @ | 444 | Service 3 @ . | @ | @ | 445 | @ ..+...... @@@@@@@@@@+@@@@@@ Service | 446 | @ | . | Chain | 447 | @@@@+@@@ ...........>+... Steering | 448 +----------------+ @ | . Point #2 | 449 @@@@@@@@@@@@@@>+@@+@@@ | 450 | . @ | 451 ............+... @@@@@ | 452 +--------------+ . | @ | 453 | ..+<....... .......>+.... @ | 454 | Service 4 . | . | . @ | 455 | ..+............ +----+-------+-------+ 456 +--------------+ . @ 457 . @ 458 V V 460 Figure 2: Service Chain Marking At Ingress 462 Internet-Draft Layer 4-7 Service Chain Problem Statement 464 The purpose of a Service Chain Marking Functional Module is to 465 add a unique Service Chain Label (e.g. Layer 2 or 3 Label) to the 466 packets in the flow. Such a Layer 2 or 3 Label makes it easier 467 for subsequent nodes along the flow path to steer the flow to the 468 service modules specified by the flow's service chain. The 469 network elements that have the Service Chain Marking Function are 470 most likely network ingress edge nodes, such as Broadband Network 471 Gateways, Cell Site Gateways, etc. 473 For example, the Service Chain Marking Functional Module can mark 474 packets in a flow with a VLAN or MPLS label, based on the flow's 475 service chain requirement. 477 In some situations, like service chain for wireless subscribers, 478 many flows (i.e. subscribers) have common service chain 479 requirements. Under those situations, the Service Chain Marking 480 Functional Module can mark multiple flows with the same service 481 chain requirement using the same Layer 2 or 3 Label, which 482 effectively aggregates those flows into one service chain. 484 To minimize changes to deployed network elements, a small number 485 of nodes in network can be designated to have the responsibility 486 of steering traffic to the designated service modules. For ease 487 of description, those nodes are called Service Chain Steering 488 Points in this draft. 490 Overlay tunnels, such as VxLAN, can be used to force flows to 491 traverse their designated Service Chain Steering Points. By using 492 overlay tunnels, the existing network elements don't need to 493 change any forwarding behavior. 495 For service chains that are shared by a great number of flows, 496 they can be pre-provisioned. For example, if VLAN ID=10 is the 497 service chain that need to traverse "Service-1" at Steering Point 498 #1 and "Service-3" at Steering Point #2, the forwarding rule for 499 VLAN ID=10 can be pre-configured at Steering Point #1 and 500 Steering Point #2. 502 Internet-Draft Layer 4-7 Service Chain Problem Statement 504 5. Challenge of Service Chain from the Layer 7 Perspective 506 From the Layer 7 perspective, the service chain can be much more 507 complex. As shown in the figure below, the service modules to be 508 chained can depend on the HTTP message request and reply. The 509 service chain steering point may have to examine the whole HTTP 510 message to determine the specific sequence of service modules for 511 packets to traverse through. The HTTP message might have to be 512 extracted from multiple data packets. Sometimes, the logic to 513 steer traffic to chain of service modules might depend on the 514 data retrieved from a database based on messages constructed from 515 packets. 517 +----------+ 518 Client --------->( Layer 7 )---------> Internet 519 <---------( Message )<--------- 520 ( Handler ) 521 _______( )________ 522 / +----------+ \ 523 / / \ \ 524 |1 |2 |3 |4 525 +---+---+ +---+---+ +-+---+ +--+-----+ 526 | Ad | |Content| |Video| |Security| 527 |Insert | | Opt | | Opt | | App | 528 +---+---+ +---+---+ +--+--+ +--+--+--+ 529 : : : : : 530 : : : : : 532 Figure 3: Layer 7 Service Chain Complexity 534 6. Conclusion and Recommendation 536 Service Chain touches upon Layer 2 to Layer 7. Challenges for 537 Layer 4-7 service chain can be different from Layer 2-3. 539 This document provides common baseline for Layer 4-7 services 540 and service chain and addresses their unique challenges. 542 Internet-Draft Layer 4-7 Service Chain Problem Statement 544 7. Manageability Considerations 546 TBD. 548 8. Security Considerations 550 TBD. 552 9. IANA Considerations 554 This document requires no IANA actions. RFC Editor: Please remove 555 this section before publication. 557 10. Acknowledgments 559 This draft has taken input from "Application Layer SDN" 560 presentation given by John Giacomoni of F5 at Layer 123 561 conference. Thanks to Huang Shi Bi and Li Hong Yu for the 562 valuable comments and suggestions. 564 This document was prepared using 2-Word-v2.0.template.dot. 566 11. References 568 [Application-SDN] J. Giacomonni, "Application Layer SDN", Layer 569 123 ONF Presentation, Singapore, June 2013 571 [SC-Use-Case] Liu, et, al., "Service Chaining Use Cases", < 572 draft-liu-service-chaining-use-cases-00>, July, 2013 574 Internet-Draft Layer 4-7 Service Chain Problem Statement 576 Authors' Addresses 578 Linda Dunbar 579 Huawei Technologies 580 1700 Alma Drive, Suite 500 581 Plano, TX 75075, USA 582 Phone: (972) 543 5849 583 Email: ldunbar@huawei.com 585 Donald Eastlake 586 Huawei Technologies 587 155 Beaver Street 588 Milford, MA 01757 USA 589 Phone: 1-508-333-2270 590 Email: d3e3e3@gmail.com 592 Intellectual Property Statement 594 The IETF Trust takes no position regarding the validity or scope 595 of any Intellectual Property Rights or other rights that might be 596 claimed to pertain to the implementation or use of the technology 597 described in any IETF Document or the extent to which any license 598 under such rights might or might not be available; nor does it 599 represent that it has made any independent effort to identify any 600 such rights. 602 Copies of Intellectual Property disclosures made to the IETF 603 Secretariat and any assurances of licenses to be made available, 604 or the result of an attempt made to obtain a general license or 605 permission for the use of such proprietary rights by implementers 606 or users of this specification can be obtained from the IETF on- 607 line IPR repository at http://www.ietf.org/ipr 609 The IETF invites any interested party to bring to its attention 610 any copyrights, patents or patent applications, or other 611 proprietary rights that may cover technology that may be required 612 to implement any standard or specification contained in an IETF 613 Document. Please address the information to the IETF at ietf- 614 ipr@ietf.org. 616 Disclaimer of Liability 618 All IETF Documents and the information contained therein are 619 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 621 Internet-Draft Layer 4-7 Service Chain Problem Statement 623 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 624 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING 625 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 626 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 627 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 628 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 630 Acknowledgment 632 Funding for the RFC Editor function is currently provided by the 633 Internet Society.