Self-configuring Lightweight Internet Multicast Protocol ... - CiteSeerX

3 downloads 1334 Views 114KB Size Report
over the Internet offers cost-effective distribution over a ... whether network layer as the MBONE or via application layer overlays. It is observed .... certificates. The option .... MAC layer multicast address apply for SLIM regardless of the choice of ...

Self-configuring Lightweight Internet Multicast Protocol specification Gísli Hjálmtýsson, Björn Brynjúlfsson and Ólafur R. Helgason Networking Systems and Services Laboratory, Department of Computer Science, Reykjavík University, Reykjavík, Iceland {gisli,bjorninn,olafurr} Abstract – Some of the greatest benefits of the Internet come from its simple service model and the avoidance of regulatory and contractual legacy of the telecom industry. Successful integration of multicast into the global Internet promises to bring similar benefits to group communications. In spite of this promise and massive research and experimentation with IP multicast, efforts to realize multicast services on the Internet have so far failed. A key element to facilitate IP multicast is to reduce the amount of infrastructure and network support specifically introduced for multicast. We have defined, implemented and experimented with a lightweight single source multicast paradigm for the Internet that self-configures over the unicast infrastructure using only commonly available router functions. Our protocol avoids multicast specific control infrastructure. The only multicast specific functions are the control plane topology management, which operates out of data-path and manipulates router classifiers (forwarding table) and tunnel facilities. Keywords: Multicast, protocol design, protocol implementation, active and programmable networking

1 Introduction As the Internet matures as a commercial infrastructure there is an increasing interest in multicast over the Internet. While traditional broadcasting methods remain viable for highly popular and limited scope distributions, multicast over the Internet offers cost-effective distribution over a geographically wide area without requiring dense concentration of receivers. In spite of this promise and massive research and experimentation with IP multicast, efforts to realize multicast services on the Internet have so far failed. This is in spite of the fact that most commercial routers have multicast capable forwarding engines. With very few Internet service providers offering multicast services, This work was in part supported by a grant from the Icelandic Research Council 0-7803-8566-7/04/$20.00 © 2004 IEEE

multicast on the public Internet remains relegated to the MBONE. However, after more than a decade of the MBONE and efforts to converge on a family of standardized protocols to support multicast, the MBONE is still a specialty network used only by a small fraction of Internet users, and shows little evidence of becoming an integral part of the Internet [1]. On the contrary, the existence of the MBONE has fostered an evolution of multicast as a service unrelated and independent of the unicast services. Recently, however, there has been a renewal in the efforts to realize multicast services on the Internet. Research on active and programmable networking has sparked significant interest in multicast services [2,3,4]. Similarly, application level and overlay multicast [5,6,7] are attempts to realize multicast services above the networking layer. In addition there is a renewed effort at the IETF to complete the standardization of multicast and multicast supporting protocols and infrastructure [8,9,10]. However, these multicast proposals in general and the MBONE in particular define a new and separate control infrastructure that replicates the corresponding functionality of the unicast infrastructure, culminating in the current efforts within the IETF to complete this replication. These ideas are worrisome because the primary cost of all production networks is the cost of network management. This cost in turn is primarily dictated by the complexity of configuration, control protocols and the control infrastructure. Constructing and configuring a global multicast specific control infrastructure would result in complexity and cost comparable to that of unicast services. Meanwhile data from the phone network and the MBONE suggest that multicast services over the Internet will remain a small fraction of the unicast traffic. We contend that the key to the successful integration of multicast to the Internet is to nullify the management complexity of multicast, by minimizing the amount of multicast specific functions and instead leveraging more general router functions of the unicast infrastructure. We reject multicast specific address allocation protocols and/or infrastructure, multicast specific routing infrastructure, and the construction of a multicast specific virtual network,

whether network layer as the MBONE or via application layer overlays. It is observed in [1] that introducing multicast is inherently difficult because several difficult problems need to be solved and so many systems – routers, servers and end-systems – need to be changed. We contend that most of these problems do not need to be solved – they need to be avoided. Similarly, while any new multicast protocol must be implemented on multicast routers we contend that other changes should be avoided. We have defined, implemented and experimented with a lightweight single source multicast paradigm for the Internet that self-configures over the unicast infrastructure. Moreover, beyond a multicast capable forwarding engine, our new multicast requires only router functions that are increasingly common – namely flow classification and dynamic tunneling – and that are being introduced into routers for reasons independent of multicast. Treating the (source, destination) pair as a flow descriptor independent of the destination address value, multicast address allocation becomes local to the source. These are characteristics shared with SSM [11,12]. However, while [11] constitutes a significant and important departure from prior thinking on IP multicast, numerous obstacles and complexities remain. The primary contribution of this paper is a complete specification of a new single source Self-configuring Lightweight IP Multicast protocol (SLIM) that selfconfigures over the unchanged Internet exploiting the existing unicast infrastructure. Avoiding multicast specific infrastructure, avoiding assumptions about universal deployment and specifically addressing deployment issues our experimentation shows that SLIM has the characteristics needed to facilitate the organic growth of multicast use, thus providing a driver for multicast deployment that is badly missing today. While pushing the envelope beyond existing SSM proposals, we see our work as a contribution supporting the arguments for single source multicast and supportive of efforts to standardize SSM as an independent protocol by reducing standardization requirements down to topology management and by demonstrating through experimentation the viability and usefulness of single source multicast. The rest of the paper is organized as follows. In Section 2 we cover related work and further position our contribution with respect to prior and on-going work. Section 3 gives an overview of the protocol and assumed router functionality, with Section 4 detailing the specifics of the protocol. In Section 5 we discuss experimentation followed by conclusion in Section 6.

2 Related work SLIM is a network layer single source multicast. As such it is most strongly related other single source multicast, particularly Express [11,12]. We share the author’s view that single source network layer multicast is the adequate and appropriate elementary multicast service and sufficient for more elaborate group communication sessions to be built upon. In fact, just as in PIM-SM [8] and [11] a multi-sender sessions may have senders tunnel data packets to a single rendezvous point, which terminates the tunnel and relays the packets onto a shared distribution tree. Moreover, as observed by the authors of PIM-SM, the presence of a few dominant sources may warrant the construction of source-specific distribution trees for these dominant sources. However, unlike PIM-SM which includes these concerns as an integral part of the protocol, SLIM leaves such issues to session management and out of our network layer protocol. To our significant concern, the Express proposal in [12] has now been folded into the latest versions of PIMSM [8]. Topology management of [11] and [8] is essentially the same, and also essentially the same as for SLIM apart from SLIM including tunnel management. However, [8] includes protocol complexities and basic design assumptions that contradict the arguments for single source multicast, and require substantial amount of multicast specific infrastructure and standardization. In our view, these complexities are in large part responsible for the limited adoption of IP multicast. In contrast, SLIM avoids all multicast specific support infrastructure, limits router changes to topology management, and limits the standardization required to consensus on the format and the content of the one essential SLIM message, the JOIN message (see Section 4.2). Significant relevant prior work on multicast exists in the connection oriented community most notably [13] and [14]. In particular, while ATM based, UNITE [13] incorporates a global scale multicast protocol without any multicast specific infrastructure beyond topology management. SLIM can be viewed as a simplified version of [13] adapted for IP networks. Borrowing from connection oriented networks REUNITE [15] uses header swapping at each multicast capable node to build a single source multicast service by unicasting data between multicast nodes. However REUNITE introduces a rather complex “tree” mechanism having the undesirable effect that the departure of a single receiver effectively results in the destruction of the sub-tree rooted at the node containing the forwarding state for the departing receiver, and a rebuild of new distribution tree(s) for all receivers still active in that sub-tree. This may break protocols (or cause constant fluttering) such as layered multicast [16,17] and QoS enhanced multicast. In contrast

in SLIM join and leave are strictly local, and does not suffer from this type of path fluttering. Motivated by the desire to spark organic growth of multicast use, and frustrated by the lack of widely available network layer multicast, several researchers have concluded that multicast should first be realized using application layer overlays [5,6,7,18]. Host Multicast [19] takes a step further exploiting IP multicast where available but otherwise using UDP overlays. While we empathize with the frustration we believe that a simple light weight network layer multicast such as SLIM reduces the overall complexity of the multicast service, and provides sufficient capabilities to facilitate organic growth of the multicast community.

3 The SLIM protocol The seminal characteristic of our Self-configuring Lightweight Internet Multicast (SLIM) is that it avoids all multicast specific infrastructure other than topology management. SLIM is a single source multicast where a multicast channel is uniquely identified by the pair S,C with S the IP address of the sender and C is the source specific channel identifier. This avoids the address allocation problem of older IP multicast. Receivers interested in a given multicast channel obtain a session description containing both S and C, and send their control messages addressed to S using normal unicast thus avoiding the need for multicast routing. Control messages, join and leave, are sent towards S and processed by the SLIM topology management daemon running on SLIM routers. The daemon maintains no nonlocal information beyond what is conveyed by the join and leave control messages. Like other sparse-mode multicast protocols SLIM only forwards control messages if needed. In particular joins are suppressed at the first router already receiving the requested channel. All SLIM state is soft. While SLIM can work with traditional multicast specific data-paths, it is designed to exploit general purpose classifiers to trigger stateful flow based forwarding. Consequently, the protocol is indifferent to the type of address used for the channel identifier C allowing it to be any legal IP address. SLIM incorporates support for incremental deployment and constructs IP tunnels through noncooperating routers on demand, as needed, avoiding the need for and the management overhead of multicast specific virtual network. Although herein (and in our implementation) we discuss only realization in IPv4, the protocol is equally well suited for IPv6 with obvious changes. SLIM is designed to offer only the minimal set of functionality to construct and manage the topology of a

singly rooted multicast distribution tree, and to minimize the need for multicast specific functions in the network. In addition, SLIM is designed to separate the control plane functions from the data-path classification and forwarding, by defining a small set of primitives (API) through which the protocol deamon interacts with the data-path facilities. The clearly defined interface of SLIM facilitates additional advanced group management features, such as authentication, charging and security management. The design of SLIM assumes increasing availability of three data-path facilities, a multicast capable forwarding engine, a general purpose classifier, and dynamic tunneling. The first is already true and is necessary for any network layer multicast and hence not a specific requirement for SLIM. The second is already valid for a large proportion of routers and the last increasingly so, the latter two driven by needs other than that of multicast.

4 Details of protocol The SLIM protocol consists of two types of control messages and their associated semantics which are implemented at SLIM routers. The two messages defined are JOIN, used to request to receive the multicast channel, and LEAVE expressing that receiving the channel is no longer desired. The SLIM protocol is designed to exchange the minimum amount of information required to successfully construct a multicast distribution tree for the desired multicast channel from the single source (root) to all interested receivers. The protocol is limited only to this task. All other concerns are exterior to the protocol and are addressed by session management or applications. The protocol permits additional data to be carried in the control messages allowing the functionality of the daemon to be extended. An option field in the protocol message header allows designation of additional information. We have defined two option values that have proven valuable in reaching end-systems not directly connected to a multicast router (see Section 4.8). Other additional data of interest include authentication certificates. The option field does not change the semantics of the two protocol messages and thus does not alter the complexity of the protocol. All state associated with SLIM is soft. As a consequence only the JOIN message and its correct interpretation is necessary for protocol correctness. We claim that only the JOIN message and its semantics need to be standardized to facilitate global adoption of the SLIM protocol. The LEAVE message is used to accelerate resource reclaim, which is important for protocols such as layered multicast for congestion adaptation [16]. The control messages are sent as IP packets with a new SLIM protocol number and the Router Alert option, and carry the common SLIM protocol header. All control messages are sent best effort.

[email protected]: TTL value of the IP header on the last branch point. When a SLIM enabled router updates the last-branch-point it copies the TTL value in the IP header into this value before JOIN messages are forwarded. (This field is really 32 bits, although it can only take an 8 bit value as the IPv4 TTL is only 8 bits) Option: Option identifier. If present, indicated by a value not equal to null, the protocol message header is followed by an option value. An example option is the “receive as” option, designed to cope with firewalls and NAT’s for multicast end user support.

Figure 1 The SLIM protocol message header Each distribution tree has one designated source. Similar to a number of other sparse mode protocols distribution trees are built bottom-up from the leaves towards the root, resulting in scalable construction and control of the multicast channel topology.

4.1 Soft state All multicast state on routers is soft and therefore only valid for a certain period of time. Thus every multicast router and receiver periodically send JOIN messages to refresh the corresponding soft state, frequently enough to avoid unwanted loss of state due to random losses of join messages. The primary benefit of soft state is simplification of exception handling. Specifically the use of soft state affords us to send the LEAVE message unreliably as the allocated forwarding state is eventually removed after timer expiration. To reduce the message overhead of maintaining the soft state we let the refresh interval grow exponentially (to a certain limit) as the forwarding state becomes older.

4.2 JOIN JOIN messages are used to create new branches in the multicast distribution tree and to refresh the forwarding state timer. The protocol header for SLIM messages is shown in Figure 1. It contains the following fields: Control: Containing control fields, such as protocol version etc, and an 8 bit message type set to the value JOIN or LEAVE (detailed content of the other 24 bits TBD via consensus at IETF). Source Address (S): The IP address of the sender. Channel Address (C): An IP address chosen so that the pair S,C is globally unique. Last-Branch-Point: The IP address of the next downstream multicast enabled router (or the next branchpoint) in the distribution tree, or the receiver.

A join from a receiver interested in receiving the multicast channel S,C progresses from the receiver towards the source as follows. The receiver sends a JOIN message with destination address S, and stamps it’s own IP address as the last branch point. A router between the receiver and S receives and intercepts the JOIN message and sets up a forwarding state in the classifier for the multicast flow identified by S,C . If the router is already a part of the distribution tree for S,C it adds a new branch to the flow and suppresses the JOIN message; otherwise it creates a new flow entry, and forwards the JOIN message onward towards S. If the join message is not received from an immediate neighbor the router creates a tunnel to the last-branch-point. Comparison between the TTL in the IP header of the received message and the value of the [email protected] carried in the message indicates whether the last branch point is an immediate neighbor or not. Periodically – on expiration of the soft state refresh timer – a SLIM router refreshes the upstream state, by sending a join message for each flow associated with the expired timer. The router prepares a JOIN message for the channel S,C as if it were an ordinary receiver.

4.3 Using tunnels to reduce forwarding state Tunnels are necessary for SLIM to reach through noncooperating routers. However, since tunnel support is an integral part of the SLIM protocol it affords additional flexibility at intermediate routers allowing individual router policy to optimize (locally) the tradeoff between tunneling and forwarding state. There are two primary reasons to exploit tunnels due to policy rather than necessity; a) to limit the number of entries in the forwarding table used for SLIM multicast channels, and b) to limit the fan-out of each entry and the associated work due to tunneling. The local optimization is based on the observation that a SLIM router can choose to participate in a particular multicast channel on a per receiver (or JOIN) basis. When receiving a JOIN from a new downstream receiver, based on a local policy a SLIM router may simply act as if it were a non-SLIM router and forward the message upstream towards the

receiver. This is sufficient to address both a) and b). The policies for when to do so are outside of the protocol.

4.4 LEAVE The only other message of the protocol is a leave message, sent from a downstream node expressing that interest in the multicast stream has ended. A receiver system sends a leave when the (last) application closes the channel. An intermediate router issues a leave when the last outgoing branch either leaves or expires. The message has the same format as the join message, with the message type set to leave. While not necessary for the correctness of the protocol (due to the soft state) the leave adds minimal complexity and expedites resource release.

4.5 Address allocation A key benefit of identifying the multicast channel with the pair S,C is that it allows the address C to be allocated locally. Unlike [11] however our scheme does not require the use of distinguished multicast addresses but merely that the channel identifier C be a valid IP address. The channel scheme is thus outside of the protocol and can either be done by convention or determined as part of session management. While not requiring the use of class D addresses, our scheme does not preclude it. We have indeed found value in supporting arbitrary IP addresses as channel identifiers, in particular for sessions that start out as a single point-to-point connection and later evolve into multicast (e.g. three way calling). Existing proposals for mapping a channel address to a MAC layer multicast address apply for SLIM regardless of the choice of addresses used for the channel identifier, as long as the last 24 bits are not zero.

4.6 Multiple senders Using the same techniques as with other single source multicast, a SLIM multi-sender session can be implemented using SLIM as a building-block in a number of ways. One approach is to build a distribution tree per sender. Participants in the multicast session then JOIN to as many channels as there are senders. Another approach is to use session relay similar to what is done in PIM-SM, where senders tunnel to the rendezvous point R, with all participants joining the multicast channel R,G . Deciding which approach to use and information about the respective addresses of senders/rendezvous point is part of session management. We have successfully employed both approaches in our experimentation with interactive multimedia teleconferencing.

4.7 Arbitrary sender To allow an arbitrary end-system that is not directly connected to a multicast router to become a multicast

source we have implemented a multicast relay service. An interested sender obtains a unique channel identifier from a multicast relay service. Subsequently, the sender sends a point-to-point unicast UDP stream to the relay service which relays the stream onto the multicast channel.

4.8 Last-hop problems in multicast Reaching end-systems from the multicast infrastructure constitutes a significant barrier in deploying any network layer multicast protocol. A basic problem arises from the fact that current IP multicast protocols have been designed assuming universal deployment thereby preventing end-systems that are more than one router hop away from a multicast capable router to participate in multicast. This problem is further aggravated by the declining transparency of the maturing Internet due to firewalls and NATs and more. In the design of our protocol we have taken measures to overcome most of these problems as discussed in [20].

5 Experimentation We have experimented extensively with SLIM in our laboratories, on production LANs and over the open Internet for over three years. Our experimentations with SLIM based multicast services have included interactive conferencing for distance learning, teleconferencing, Internet radio and a high quality live TV services. In our live service we have sent and received multicast in a variety of setups; in particular, where a sender or receiver or both are behind (different) firewalls and/or NATs that were not under our control. We now offer multicast streaming services to students at Reykjavik University and other universities in Iceland whether on campus or accessing our services from home through their respective local ISP’s firewalls and NATs. Our experimentation validates the workings of SLIM over the open Internet without multicast specific support beyond the SLIM daemon, and has shown SLIM to be robust in a wide range of environments.

6 Conclusion In this paper we have described SLIM a new lightweight single source multicast protocol for the Internet that self-configures over the unicast infrastructure using only commonly available router functions. The protocol avoids the major obstacles that have prevented the organic growth of multicast support and services. Specifically SLIM avoids the multicast address allocation problem, avoids the need for multicast specific Internet infrastructure and supports incremental deployment. SLIM provides only the essential facilities to construct and maintain a single source multicast distribution tree. All other service concerns, e.g. accounting, multiple senders,

are outside of the protocol. The only message necessary for protocol correctness is the JOIN message; no other nonlocal state information needs to be exchanged. Using SLIM we have successfully performed substantial amount of experimentation with multicast services over the open Internet.

References [1] Prashant Rajvaidya and Kevin C. Almeroth, “Analysis of Routing Characteristics in the Multicast Infrastructure” in Proceedings of Infocom, San Francisco, April 2003. [2] M. Sanders, M. Keaton, S. Bhattacharjee, K. Calvert, S. Zabele and E. Zegura, “Active Reliable Multicast on CANEs: A Case Study.” In Proceedings of IEEE OpenArch 2001, Anchorage, Alaska, April 2001. [3] Gísli Hjálmtýsson and Samrat Bhattacharjee, "Control on Demand - An Efficient Approach to Router Programmability," in IEEE JSAC, Vol. 17, No. 9, September 1999, pp. 1549-1562. [4] Sneha K. Kasera, Gísli Hjálmtýsson, Don Towsley and Jim Kuroso, "Scalable Reliable Multicast using Multiple Multicast Channels," IEEE/ACM Transactions on Networking, Vol. 8, No. 3, June 2000. [5] M. Castro, P. Druschel, A.-M. Kermarrec, and A. Rowstron, “Scribe: A large-scale and decentralized application-level multicast infrastructure,” IEEE JSAC, vol. 20, no. 8, October 2002. [6] S. Banerjee, B. Bhattacharjee and C. Kommareddy “Scalable Application Layer Multicast,” in Proceedings of ACM Sigcomm 2002, Pittsburgh, Pennsylvania, August 2002. [7] J. Jannotti, D. K. Gifford, K. L. Johnson, F. Kaashoek, and J. W. O’Toole, “Overcast: Reliable Multicasting with an Overlay Network,” in Proc. of OSDI, October 2000, pp. 197–212. [8] B. Fenner, M. Handley, H. Holbrook and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)”, IETF Internet Draft, work in progress, March 2003, draft-ietf-pim-sm-v2-new07.txt [9] D. Meyer and B. Fenner, “Multicast source discovery protocol (MSDP),” Internet Engineering Task Force (IETF), draft-ietf-msdp-spec-*.txt, November 2001 [10] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, “Multiprotocol extensions for BGP-4,” Internet Engineering Task Force (IETF), RFC 2283, February 1998.

[11] H. Holbrook og D. Cheriton, “IP Multicast Channels : EXPRESS Support for Large-scale Single-Source Applications,” In Proceedings of SIGCOMM 1999, 1999. [12] H. Holbrook og B. Cain, “Source Specific Multicast for IP,” IETF Internet Draft, work in progress, March 2003. draft-ietf-ssm-arch-02.txt. [13] Gísli Hjálmtýsson og K. K. Ramakrishnan, “UNITE An Architecture for Lightweight Signaling in ATM Networks,” DIMACS, Networks in Distributed Computing, October 1997. [14] Matthias Grossglauser and K.K. Ramakrishnan "SEAM: Scalable and Efficient ATM Multicast," in Proceedings of INFOCOM, April 1997 [15] Ion Stoica, T. S. Eugene Ng, Hui Zhang, "REUNITE: A Recursive Unicast Approach to Multicast", INFOCOM 2000, Tel-Aviv, Israel, March 2000. [16] V. Jacobson, S. McCanne and M. Vetterli. “Receiverdriven layered multicast.” In Proc. of ACM SIGCOMM' 96, Stanford, CA, August 1996. [17] R. Gopalakrishnan, James Griffioen, Gísli Hjálmtýsson, Cormac Sreenan and Su Wen. "A Simple Loss Differentiation Approach to Layered Multicast," In the proceedings of Infocom2000 Tel Aviv, Israel, March 2000. [18] Y.-H. Chu, S. G. Rao, and H. Zhang. “A case for end system multicast,” in Proceedings of ACM Sigmetrics, June 2000, pp. 1–12. [19] B. Zhang, S. Jamin, L. Zhang, "Host Multicast: A Framework for Delivering Multicast to End Users," IEEE INFOCOM, New York City, NY, 2002. [20] Gísli Hjálmtýsson, Björn Brynjúlfsson and Ólafur Ragnar Helgason. “Overcoming last-hop/first-hop problems in IP multicast,” in proceedings of NGC 2003, September 2003.

Suggest Documents