Administratively Scoped IP Multicast
RFC 2365
Document | Type |
RFC - Best Current Practice
(July 1998; No errata)
Also known as BCP 23
|
|
---|---|---|---|
Author | David Meyer | ||
Last updated | 2013-03-02 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2365 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group D. Meyer Request for Comments: 2365 University of Oregon BCP: 23 July 1998 Category: Best Current Practice Administratively Scoped IP Multicast Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. 1. Abstract This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author. 2. Acknowledgments Much of this memo is taken from "Administratively Scoped IP Multicast", Van Jacobson and Steve Deering, presented at the 30th IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and Dave Thaler have also provided insightful comments on earlier versions of this document. 3. Introduction Most current IP multicast implementations achieve some level of scoping by using the TTL field in the IP header. Typical MBONE (Multicast Backbone) usage has been to engineer TTL thresholds that confine traffic to some administratively defined topological region. The basic forwarding rule for interfaces with configured TTL thresholds is that a packet is not forwarded across the interface unless its remaining TTL is greater than the threshold. Meyer Best Current Practice [Page 1] RFC 2365 Administratively Scoped IP Multicast July 1998 TTL scoping has been used to control the distribution of multicast traffic with the objective of easing stress on scarce resources (e.g., bandwidth), or to achieve some kind of improved privacy or scaling properties. In addition, the TTL is also used in its traditional role to limit datagram lifetime. Given these often conflicting roles, TTL scoping has proven difficult to implement reliably, and the resulting schemes have often been complex and difficult to understand. A more serious architectural problem concerns the interaction of TTL scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The particular problem is that in many common cases, TTL scoping can prevent pruning from being effective. Consider the case in which a packet has either had its TTL expire or failed a TTL threshold. The router which discards the packet will not be capable of pruning any upstream sources, and thus will sink all multicast traffic (whether or not there are downstream receivers). Note that while it might seem possible to send prunes upstream from the point at which a packet is discarded, this strategy can result in legitimate traffic being discarded, since subsequent packets could take a different path and arrive at the same point with a larger TTL. On the other hand, administratively scoped IP multicast can provide clear and simple semantics for scoped IP multicast. The key properties of administratively scoped IP multicast are that (i). packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries, and (ii). administratively scoped multicast addresses are locally assigned, and hence are not required to be unique across administrative boundaries. 4. Definition of the Administratively Scoped IPv4 Multicast Space The administratively scoped IPv4 multicast address space is defined to be the range 239.0.0.0 to 239.255.255.255. 5. Discussion In order to support administratively scoped IP multicast, a router should support the configuration of per-interface scoped IP multicast boundaries. Such a router, called a boundary router, does not forward packets matching an interface's boundary definition in either direction (the bi-directional check prevents problems with multi- access networks). In addition, a boundary router always prunes the boundary for dense-mode groups [PIMDM], and doesn't accept joins for sparse-mode groups [PIMSM] in the administratively scoped range. Meyer Best Current Practice [Page 2] RFC 2365 Administratively Scoped IP Multicast July 1998 6. The Structure of the Administratively Scoped Multicast Space The structure of the IP version 4 administratively scoped multicastShow full document text