From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3569.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc3569.txt (limited to 'doc/rfc/rfc3569.txt') diff --git a/doc/rfc/rfc3569.txt b/doc/rfc/rfc3569.txt new file mode 100644 index 0000000..346326b --- /dev/null +++ b/doc/rfc/rfc3569.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group S. Bhattacharyya, Ed. +Request for Comments: 3569 Sprint +Category: Informational July 2003 + + + An Overview of Source-Specific Multicast (SSM) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The purpose of this document is to provide an overview of + Source-Specific Multicast (SSM) and issues related to its deployment. + It discusses how the SSM service model addresses the challenges faced + in inter-domain multicast deployment, changes needed to routing + protocols and applications to deploy SSM and interoperability issues + with current multicast service models. + +1. Introduction + + This document provides an overview of the Source-Specific Multicast + (SSM) service and its deployment using the PIM-SM and IGMP/MLD + protocols. The network layer service provided by SSM is a "channel", + identified by an SSM destination IP address (G) and a source IP + address S. An IPv4 address range has been reserved by IANA for use + by the SSM service. An SSM destination address range already exists + for IPv6. A source S transmits IP datagrams to an SSM destination + address G. A receiver can receive these datagrams by subscribing to + the channel (Source, Group) or (S,G). Channel subscription is + supported by version 3 of the IGMP protocol for IPv4 and version2 of + the MLD protocol for IPv6. The interdomain tree for forwarding IP + multicast datagrams is rooted at the source S, and is constructed + using the PIM Sparse Mode [9] protocol. + + This document is not intended to be a standard for Source-Specific + Multicast (SSM). Instead, its goal is to serve as an introduction to + SSM and its benefits for anyone interested in deploying SSM services. + It provides an overview of SSM and how it solves a number of problems + faced in the deployment of inter-domain multicast. It outlines + changes to protocols and applications both at end-hosts and routers + + + +Bhattacharyya Informational [Page 1] + +RFC 3569 An Overview of SSM July 2003 + + + for supporting SSM, with pointers to more detailed documents where + appropriate. Issues of interoperability with the multicast service + model defined by RFC 1112 are also discussed. + + This memo is a product of the Source-Specific Multicast (SSM) Working + Group of the Internet Engineering Task Force. + + The keywords "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as defined in BCP 14, RFC 2119 [28]. + +2. Terminology + + This section defines some terms that are used in the rest of this + document: + + Any-Source Multicast (ASM): This is the IP multicast service model + defined in RFC 1112 [25]. An IP datagram is transmitted to a + "host group", a set of zero or more end-hosts (or routers) + identified by a single IP destination address (224.0.0.0 through + 239.255.255.255 for IPv4). End-hosts may join and leave the group + any time, and there is no restriction on their location or number. + Moreover, this model supports multicast groups with arbitrarily + many senders - any end-host (or router) may transmit to a host + group, even if it is not a member of that group. + + Source-Specific Multicast (SSM): This is the multicast service + model defined in [5]. An IP datagram is transmitted by a source S + to an SSM destination address G, and receivers can receive this + datagram by subscribing to channel (S,G). SSM provides host + applications with a "channel" abstraction, in which each channel + has exactly one source and any number of receivers. SSM is + derived from earlier work in EXPRESS [1]. The address range 232/8 + has been assigned by IANA for SSM service in IPv4. For IPv6, the + range FF3x::/96 is defined for SSM services [21]. + + Source-Filtered Multicast (SFM): This is a variant of the ASM + service model, and uses the same address range as ASM + (224.0.0.0-239.255.255.255). It extends the ASM service model as + follows. Each "upper layer protocol module" can now request data + sent to a host group G by only a specific set of sources, or can + request data sent to host group G from all BUT a specific set of + sources. Support for source filtering is provided by version 3 of + the Internet Group Management Protocol (or IGMPv3) [3] for IPv4, + and version 2 of the Multicast Listener Discovery (or MLDv2) [22] + protocol for IPv6. We shall henceforth refer to these two + protocols as "SFM-capable". Earlier versions of these + protocols - IGMPv1/IGMPv2 and MLDv1 - do not provide support for + + + +Bhattacharyya Informational [Page 2] + +RFC 3569 An Overview of SSM July 2003 + + + source-filtering, and are referred to as "non-SFM-capable". Note + that while SFM is a different model than ASM from a receiver + standpoint, there is no distinction between the two for a sender. + + For the purpose of this document, we treat the scoped multicast model + of [12] to be a variant of ASM since it does not explicitly restrict + the number of sources, but only requires that they be located within + the scope zone of the group. + +3. The IGMP/PIM-SM/MSDP/MBGP Protocol Suite for ASM + + As of this writing, all multicast-capable networks support the ASM + service model. One of the most common multicast protocol suites for + supporting ASM consists of IGMP version 2 [2], PIM-SM [8,9], MSDP + [13] and MBGP [26]. IGMPv2 is the most commonly used protocol for + hosts to specify membership in a multicast group, and nearly all + multicast routers support (at least) IGMPv2. In case of IPv6, MLDv1 + [21] is the commonly used protocol. + + Although a number of protocols such as PIM-DM [10], CBT [24,11], + DVMRP [6], etc. exist for building multicast tree among all receivers + and sources in the same administrative domain, PIM-SM [8,9] is the + most widely used protocol. PIM-SM builds a spanning multicast tree + rooted at a core rendezvous point or RP for all group members within + a single administrative domain. A 'first-hop' router adjacent to a + multicast source sends the source's traffic to the RP for its domain. + The RP forwards the data down the shared spanning tree to all + interested receivers within the domain. PIM-SM also allows receivers + to switch to a source-based shortest path tree. + + As of this writing, multicast end-hosts with SFM capabilities are not + widely available. Hence a client can only specify interest in an + entire host group and receives data sent from any source to this + group. + + Inter-domain multicast service (i.e., where sources and receivers are + located in different domains) requires additional protocols - MSDP + [13] and MBGP [26] are the most commonly used ones. An RP uses the + MSDP protocol to announce multicast sources to RPs in other domains. + When an RP discovers a source in a different domain transmitting data + to a multicast group for which there are interested receivers in its + own domain, it joins the shortest-path source based tree rooted at + that source. It then redistributes the data received to all + interested receivers via the intra-domain shared tree rooted at + itself. + + + + + + +Bhattacharyya Informational [Page 3] + +RFC 3569 An Overview of SSM July 2003 + + + MBGP defines extensions to the BGP protocol to support the + advertisement of reachability information for multicast routes. This + allows an autonomous system (AS) to support incongruent unicast and + multicast routing topologies, and thus implement separate routing + policies for each. + + However, the last-hop routers of interested receivers may eventually + switch to a shortest-path tree rooted at the source that is + transmitting the data. + +4. Problems with Current Architecture + + There are several deployment problems associated with current + multicast architecture: + + A) Address Allocation: + + Address allocation is one of core deployment challenges posed + by the ASM service model. The current multicast architecture + does not provide a deployable solution to prevent address + collisions among multiple applications. The problem is much + less serious for IPv6 than for IPv4 since the size of the + multicast address space is much larger. A static address + allocation scheme, GLOP [17] has been proposed as an interim + solution for IPv4; however, GLOP addresses are allocated per + registered AS, which is inadequate in cases where the number of + sources exceeds the AS numbers available for mapping. RFC 3138 + expands on RFC 2770 to allow routing registries to assign + multicast addresses from the GLOP space corresponding to the + RFC 1930 private AS space [27]. This space is referred to as + the EGLOP (Extended GLOP) address space. Proposed longer-term + solutions such as the Multicast Address Allocation Architecture + [14] are generally perceived as being too complex (with respect + to the dynamic nature of multicast address allocation) for + widespread deployment. + + B) Lack of Access control: + + In the ASM service model, a receiver cannot specify which + specific sources it would like to receive when it joins a given + group. A receiver will be forwarded data sent to a host group + by any source. Moreover, even when a source is allocated a + multicast group address to transmit on, it has no way of + enforcing that no other source will use the same address. This + is true even in the case of IPv6, where address collisions are + less likely due to the much larger size of the address space. + + + + + +Bhattacharyya Informational [Page 4] + +RFC 3569 An Overview of SSM July 2003 + + + C) Inefficient handling of well-known sources: + + In cases where the address of the source is well known in + advance of the receiver joining the group, and when the + shortest forwarding path is the preferred forwarding mode, then + shared tree mechanisms are not necessary. + +5. Source Specific Multicast (SSM): Benefits and Requirements + + As mentioned before, the Source Specific Multicast (SSM) service + model defines a "channel" identified by an (S,G) pair, where S is a + source address and G is an SSM destination address. Channel + subscriptions are described using an SFM-capable group management + protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees + are needed to implement this model. + + The SSM service model alleviates all of the deployment problems + described earlier: + + A) Address Allocation: SSM defines channels on a per-source basis, + i.e., the channel (S1,G) is distinct from the channel (S2,G), + where S1 and S2 are source addresses, and G is an SSM + destination address. This averts the problem of global + allocation of SSM destination addresses, and makes each source + independently responsible for resolving address collisions for + the various channels that it creates. + + B) Access Control: SSM lends itself to an elegant solution to the + access control problem. When a receiver subscribes to an (S,G) + channel, it receives data sent only by the source S. In + contrast, any host can transmit to an ASM host group. At the + same time, when a sender picks a channel (S,G) to transmit on, + it is automatically ensured that no other sender will be + transmitting on the same channel (except in the case of + malicious acts such as address spoofing). This makes it much + harder to "spam" an SSM channel than an ASM multicast group. + + C) Handling of well-known sources: SSM requires only + source-based forwarding trees; this eliminates the need for a + shared tree infrastructure. This implies that neither the + RP-based shared tree infrastructure of PIM-SM nor the MSDP + protocol is required. Thus the complexity of the multicast + routing infrastructure for SSM is low, making it viable for + immediate deployment. Note that there is no difference in how + MBGP is used for ASM and SSM. + + + + + + +Bhattacharyya Informational [Page 5] + +RFC 3569 An Overview of SSM July 2003 + + +6. SSM Framework + + Figure 1 illustrates the elements in an end-to-end implementation + framework for SSM: + + -------------------------------------------------------------- + IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION + FF3x::/96 for IPv6 + -------------------------------------------------------------- + | + v + +--------------+ session directory/web page + | source,group | SESSION DESCRIPTION + -------------------------------------------------------------- + ^ | + Query | | (S,G) + | v + +-----------------+ host + | SSM-aware app | CHANNEL DISCOVERY + -------------------------------------------------------------- + | SSM-aware app | SSM-AWARE APPLICATION + -------------------------------------------------------------- + | IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING + +-----------------+ + |(source specific host report) + -------------------------------------------------------------- + v + +-----------------+ Querier Router + | IGMPv3/MLDv2 | QUERIER + -------------------------------------------------------------- + | PIM-SSM | PIM-SSM ROUTING + +------------+ Designated Router + | + | (S,G) Join only + v + +-----------+ Backbone Router + | PIM-SSM | + +-----------+ + | + | (S,G) Join only + V + + Figure 1: SSM Framework: elements in end-to-end model + + + + + + + + +Bhattacharyya Informational [Page 6] + +RFC 3569 An Overview of SSM July 2003 + + + We now discuss the framework elements in detail: + +6.1. Address Allocation + + For IPv4, the address range of 232/8 has been assigned by IANA for + SSM. To ensure global SSM functionality in 232/8, including in + networks where routers run non-SFM-capable protocols, operational + policies are being proposed [9] which recommend that routers should + not send SSM traffic to parts of the network that do not have channel + subscribers. + + Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8 + range. However, SSM service, as defined in [5], is available only in + this address range for IPv4. + + In case of IPv6, [23] has defined an extension to the addressing + architecture to allow for unicast prefix-based multicast addresses. + See RFC 3306 for details. + +6.2. Session Description and Channel Discovery + + An SSM receiver application must know both the SSM destination + address G and the source address S before subscribing to a channel. + Channel discovery is the responsibility of applications. This + information can be made available in a number of ways, including via + web pages, sessions announcement applications, etc. This is similar + to what is used for ASM applications where a multicast session needs + to be announced so that potential subscribers can know of the + multicast group address, encoding schemes used, etc. In fact, the + only additional piece of information that needs to be announced is + the source address for the channel being advertised. However, the + exact mechanisms for doing this is outside the scope of this + framework document. + +6.3. SSM-Aware Applications + + There are two main issues in making multicast applications + "SSM-aware": + + - An application that wants to receive an SSM session must first + discover the channel address in use. + + - A receiving application must be able to specify both a source + address and a destination address to the network layer protocol + module on the end-host. + + + + + + +Bhattacharyya Informational [Page 7] + +RFC 3569 An Overview of SSM July 2003 + + + Specific API requirements are identified in [16]. [16] describes + a recommended application programming interface for a host + operating system to support the SFM service model. Although it is + intended for SFM, a subset of this interface is sufficient for + supporting SSM. + +6.4. IGMPv3/MLDv2 Host Reporting and Querier + + In order to use SSM service, an end-host must be able to specify a + channel address, consisting of a source's unicast address and an SSM + destination address. IGMP version 2 [3] and MLD version 1 [19] + allows an end-host to specify only a destination multicast address. + The ability to specify an SSM channel address c is provided by IGMP + version 3 [3] and MLD version 2 [20]. These protocols support + "source filtering", i.e., the ability of an end-system to express + interest in receiving data packets sent only by SPECIFIC sources, or + from ALL BUT some specific sources. In fact, IGMPv3 provides a + superset of the capabilities required to realize the SSM service + model. + + A detailed discussion of the use of IGMPv3 in the SSM destination + address range is provided in [4]. + + The Multicast Listener Discovery (MLD) protocol used by an IPv6 + router to discover the presence of multicast listeners on its + directly attached links, and to discover the multicast addresses that + are of interest to those neighboring nodes. MLD version 1 is derived + from IGMPv2 and does not provide the source filtering capability + required for the SSM service model. MLD version 2 is derived from, + and provides the same support for source-filtering as, IGMPv3. Thus + IGMPv3 (or MLDv2 for IPv6) provides a host with the ability to + request the network for an SSM channel subscription. + +6.5. PIM-SSM Routing + + [9] provides guidelines for how a PIM-SM implementation should handle + source-specific host reports as required by SSM. Earlier versions of + the PIM protocol specifications did not describe how to do this. + + The router requirements for operation in the SSM range are detailed + in [5]. These rules are primarily concerned with preventing + ASM-style behaviour in the SSM address range. In order to comply + with [5] several changes to the PIM-SM protocol are required, as + described in [9]. The most important changes in PIM-SM required for + compliance with [5] are: + + + + + + +Bhattacharyya Informational [Page 8] + +RFC 3569 An Overview of SSM July 2003 + + + - When a DR receives an (S,G) join request with the address G in the + SSM address range, it MUST initiate a (S,G) join, and NEVER a + (*,G) join. + + - Backbone routers (i.e., routers that do not have directly attached + hosts) MUST NOT propagate (*,G) joins for group addresses in the + SSM address range. + + - Rendezvous Points (RPs) MUST NOT accept PIM Register messages or + (*,G) Join messages in the SSM address range. + + Note that only a small subset of the full PIM-SM protocol + functionality is needed to support the SSM service model. This + subset is explicitly documented in [9]. + +7. Interoperability with Existing Multicast Service Models + + Interoperability with ASM is one of the most important issues in + moving to SSM deployment, since both models are expected to be used + at least in the foreseeable future. SSM is the ONLY service model + for the SSM address range - the correct protocol behaviour for this + range is specified in [5]. The ASM service model will be offered for + the non-SSM address range, where receivers can issue (*,G) join + requests to receive multicast data. A receiver is also allowed to + issue an (S,G) join request in the non-SSM address range; however, in + that case there is no guarantee that it will receive service + according to the SSM model. + + Another interoperability issue concerns the MSDP protocol, which is + used between PIM-SM rendezvous points (RPs) to discover multicast + sources across multiple domains. MSDP is not needed for SSM, but is + needed if ASM is supported. [9] specifies operational + recommendations to help ensure that MSDP does not interfere with the + ability of a network to support the SSM service model. Specifically, + [9] states that RPs must not accept, originate or forward MSDP SA + messages for the SSM address range. + +8. Security Considerations + + SSM does not introduce new security considerations for IP multicast. + It can help in preventing denial-of-service attacks resulting from + unwanted sources transmitting data to a multicast channel (S, G). + However no guarantee is provided. + + + + + + + + +Bhattacharyya Informational [Page 9] + +RFC 3569 An Overview of SSM July 2003 + + +9. Acknowledgments + + We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Timothy + Roscoe, Hugh Holbrook, Isidor Kouvelas, Tony Speakman and Nidhi + Bhaskar for participating in lengthy discussions and design work on + SSM, and providing feedback on this document. Thanks are also due to + Mujahid Khan, Ted Seely, Tom Pusateri, Bill Fenner, Kevin Almeroth, + Brian Levine, Brad Cain, Hugh LaMaster and Pekka Savola for their + valuable insights and continuing support. + +10. References + +10.1. Informative References + + [1] Holbrook, H. and D.R. Cheriton, "IP Multicast Channels: EXPRESS + Support for Large-scale Single-Source Applications", In + Proceedings of SIGCOMM 1999. + + [2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC + 2236, November 1997. + + [3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan, + "Internet Group Management Protocol, Version 3.", RFC 3376, + October 2002. + + [4] Holbrook, H. and B. Cain, "Using IGMPv3 and MLDv2 for + Source-Specific Multicast", Work In Progress. + + [5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", + Work in Progress. + + [6] Deering, S. and D. Cheriton,"Multicast Routing in Datagram + Networks and Extended LANs", ACM Transactions on Computer + Systems, 8(2):85-110, May 1990. + + [7] Deering, S. et al., "PIM Architecture for Wide-Area Multicast + Routing", IEEE/ACM Transaction on Networking, pages 153-162, + April 1996. + + [8] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., + Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol + Specification", RFC 2362, June 1998. + + [9] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol + Independent Multicast - Sparse Mode (PIM-SM): Protocol + Specification (Revised)", Work In Progress. + + + + +Bhattacharyya Informational [Page 10] + +RFC 3569 An Overview of SSM July 2003 + + + [10] Adams, A., Nicholas, J. and W. Siadek, "Protocol Independent + Multicast - Dense Mode (PIM-DM): Protocol Specification + (Revised)", Work In Progress. + + [11] Ballardie, A., "Core-Based Trees (CBT) Multicast Routing + Architecture", RFC 2201, September 1997. + + [12] Meyer, D., "Adminstratively Scoped IP Multicast", BCP 23, RFC + 2365, July 1998. + + [13] Farinacci, D. et al., "Multicast Source Discovery Protocol", + Work In Progress. + + [14] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast + Address Allocation Architecture", RFC 2908, September 2000. + + [15] Diot, C., Levine, B., Lyles, B., Kassem, H. and D. Balensiefen, + "Deployment Issues for the IP Multicast Service and + Architecture", In IEEE Networks Magazine's Special Issue on + Multicast, January, 2000. + + [16] Thaler, D., Fenner B. and B. Quinn, "Socket Interface Extensions + for Multicast Source Filters", Work in Progress. + + [17] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, + RFC 3180, September 2001. + + [18] Levine, B. et al., "Consideration of Receiver Interest for IP + Multicast Delivery", In Proceedings of IEEE Infocom, March 2000. + + [19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener + Discovery for IPv6", RFC 2710, October 1999. + + [20] Vida, R. et. al., "Multicast Listener Discovery Version 2(MLDv2) + for IPv6", Work In Progress. + + [21] Haberman, B. and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast + Addresses", RFC 3306, August 1992. + + [22] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [23] Haberman, B., "Allocation Guidelines for IPv6 Multicast + Addresses", RFC 3307, August 2002. + + + + + + + +Bhattacharyya Informational [Page 11] + +RFC 3569 An Overview of SSM July 2003 + + + [24] Ballardie, A., "Core-Based Trees (CBT Version 2) Multicast + Routing -- Protocol Specification", RFC 2189, September 2001. + + [25] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC + 1112, August 1989. + + [26] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol + Extensions for BGP-4", RFC 2858, June 2000. + + [27] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001. + +10.2. Normative References + + [28] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +11. Contributors + + Christophe Diot + Intel + EMail: christophe.diot@intel.com + + Leonard Giuliano + Juniper Networks + EMail: lenny@juniper.net + + Greg Shepherd + Procket Networks + EMail: shep@procket.com + + Robert Rockell + Sprint + EMail: rrockell@sprint.net + + David Meyer + Sprint + EMail: dmm@1-4-5.net + + John Meylor + Cisco Systems + EMail: jmeylor@cisco.com + + Brian Haberman + Caspian Networks + EMail: bkhabs@nc.rr.com + + + + + + +Bhattacharyya Informational [Page 12] + +RFC 3569 An Overview of SSM July 2003 + + +12. Editor's Address + + Supratik Bhattacharyya + Sprint + + EMail: supratik@sprintlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bhattacharyya Informational [Page 13] + +RFC 3569 An Overview of SSM July 2003 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Bhattacharyya Informational [Page 14] + -- cgit v1.2.3