summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3569.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3569.txt')
-rw-r--r--doc/rfc/rfc3569.txt787
1 files changed, 787 insertions, 0 deletions
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]
+