CONGRESS: CONnection-oriented Group address RESolution. Service. Tal Anker, David Breitgand, Danny Dolev and Zohar Levy

Transcription

1 CONGRESS: CONnection-oriented Group address RESolution Service Tal Anker, David Breitgand, Danny Dolev and Zohar Levy Institute of Computer Science The Hebrew University of Jerusalem Jerusalem, Israel Abstract This paper presents congress: a CONnection-oriented Group-address RESolution Service, and its applications. Congress is an ecient native ATM protocol for resolution and management of multicast group addresses in an ATM WAN. It complements the native ATM multicast mechanisms. Congress resolves multicast group addresses and maintains their membership for applications. It is not designed to handle the applications' data-exchange. Applications can use the resolved addresses returned by congress, in order to implement a many-to-many communication model. congress employs hierarchically organized servers in order to be scalable. congress' hierarchy is naturally mapped onto the ATM Private Network to Network Interface peer group hierarchy. congress communication overhead for management of a single multicast group is linear in the size of the group. Apart from facilitating native ATM multicast applications, congress can be used for the implementation of an IP multicast \cut-through" routing over ATM. The cut-through routing paradigm is conceived as one of the most promising techniques for enabling the traditional IP-based communication with QoS. Unfortunately, due to a variety of reasons, the building of scalable IP multicast cut-through protocols is non-trivial. We claim that a multicast address resolution and maintenance service like congress, can greatly contribute to the development of scalable IP cut-through routing services. A conceptual cut-through routing solution, IP multicast SErvice for Non-broadcast Access networking TEchnology (ip-senate), built on top of congress and scalable to a large ATM cloud is sketched. Keywords: multicast, multicast address resolution, ATM cloud, group membership, IP multicast over ATM 1. INTRODUCTION ATM is a connection-oriented network that provides important benets over existing networking technologies. Among the benets are high bandwidths, Quality of Service (QoS) guarantees and low error rate. These features of ATM boost new classes of applications such as video-conferencing, distance-learning, and Computer Supported Cooperative Work (CSCW) applications. In such multi-process applications, the many-to-many communication model is natural and highly ecient. This model is abstracted by the multicast group concept. In order to implement a multicast group most eciently and not to compromise the ATM QoS, native ATM multicast facilities should be exploited. Further author information: Anker,Breitgand,Dolev,Levy: fanker,davb,dolev,zoharg@cs.huji.ac.il Telephone: ; Fax: ; Supported by the Ministry of Science of Israel, grant number

2 ATM facilitates multicast communication by providing a point-to-multipoint (ptmpt) connection type. 4,5 This type of connection unidirectionally connects a single source ATM end-point (termed the root) to multiple destination ATM end-points (termed leaves). A multicast group can be implemented using either a mesh of ptmpt connections or a multicast server. In the former mechanism, each member of a multicast group is the root of a ptmpt connection in which all the other end-points are leaves. In the multicast server method, all end-points wishing to transmit to a multicast group, set up a point-to-point connection to a multicast server. The multicast server, in turn, is the root of a ptmpt connection that connects it to all the end-points that are members of a multicast group. In both of these techniques, it is necessary to know the identities of the end-points participating in the connections. This information (to which we refer in the rest of the paper as group membership information) is needed at connections set-up time. In the ATM Forum specication of UNI the question of how to obtain the identities of the ptmpt connection participants is left open, and the existence of some external directory service or other mechanism is assumed. It should be noted, however, that providing such a service in the WAN environment is not a trivial task. This is especially true, if a membership of the multicast groups may change dynamically and the multicast groups themselves may be created and disposed on-demand. This paper presents a novel protocol, congress, for maintaining multicast group membership information, and its application. congress operates directly over native ATM and is scalable to WAN. congress functionality focuses on the following two issues concerning multicast group membership: Resolution of an application-dened multicast group address into a set of identiers of the ATM end-points comprising the multicast group. Management of the group membership by providing dynamic updates reecting ongoing membership changes, such as joining and leaving of the end-points. It should be noted that congress is not designed to deal with the actual application data transfer within a multicast group. congress separates the multicast group management from the data transfer issues. Thus, maintenance of multicast group membership does not aect the QoS provided by the network. congress' design is based on the following principles: No ooding: congress does not ood the WAN on every group membership change. This is achieved through careful maintenance of a distributed spanning tree for each of the multicast groups. One membership change in a multicast group G incurs O(jGj) protocol messages. Hierarchical design: congress services are provided to applications by hierarchically organized servers. The hierarchical design minimizes the data structures maintained by each server. congress denes scopes within which group membership information should be propagated in order to conserve network resources. Robustness: congress is designed to operate in WAN. There is a greater possibility in WAN that due to network failures or network reconguration and re-planning some congress servers may temporarily disconnect and later reconnect. congress withstands such transient errors by providing a best-eort service. Applications continue to receive the congress services from the servers that they remain connected to. The small amount of data maintained by the servers allows simple recovery. Scalable multicast group membership service is very important for native ATM applications that require high QoS. congress provides for decentralization, load sharing, and fault tolerance. In Section 5.1 we provide the examples of various application that immediately benet from the deployment of congress. Among these applications are scalable and fault-tolerant Video-on-Demand service (VoD), video-conferencing and Pay TV applications. The usage of congress is not limited to the native ATM applications, however. We propose to use congress for ecient implementation of IP multicast cut-through routing paradigm. Due to the fundamental dierences between the connection oriented and connectionless technology, a straightforward implementation of IP over ATM results in

3 suboptimal solutions. Since IP routing protocols are orthogonal to the underlying ATM network, extra routing hops may be introduced. These extra hops complicate full utilization of QoS and impose an undesirable segmentation and reassembly overhead, because every IP datagram should be reassembled at every intermediate router prior to the routing decision. The cut-through (or short-cut) routing paradigm aims to circumvent the mismatch between the \logical network" (IP) and the \physical network" (ATM) by bypassing the extra IP routing hops. In Section 5.2 we present a highlevel overview of a generic best-eort IP multicast cut-through routing protocol built on top of congress and called ip-senate (IP multicast SErvice for Non-broadcast Access networking TEchnology). ip-senate tries to bypass the unnecessary IP routers and to exploit native ATM connectivity wherever possible, enabling usage of the guaranteed ATM QoS. Ip-senate organizes IP multicast routers into logical groups, where each group corresponds to some class D IP address and contains routers that have members of this IP multicast group or senders to it in their domain. The resolution and management of these multicast router groups is performed through congress. An ip-senate extension at a multicast router uses the group membership information that it receives from congress, in order to open ATM connections that bypass (\cut-through") the IP routing mechanism. These connections either directly fan out to other multicast routers, or go through some intermediate multicast servers in order to overcome the hardware limitation on a number of simultaneously open VCs. Ip-senate is an inter-router protocol. It provides an extension to IP multicast routers' software and optionally extends the hosts' IP multicast software. Intra-domain communication may be based on either Multicast Address Resolution Service (MARS) 3 or congress. In non-atm networks that are connected to an ATM backbone, Ipsenate may be used in conjunction with the traditional Internet Group Management Protocol (IGMP). 2. OVERVIEW OF CONGRESS congress is a multicast group address resolution and maintenance protocol operating in a native ATM environment. congress services are provided to end-point applications through a library that implements the congress API (see Subsection 3.2). The location of the congress library in the ATM reference model 7 is shown in Figure 1. An endpoint application (or simply, end-point), which may be either a transport-layer entity or a user application running on an ATM based host, can resolve a multicast group name into a list of the ATM addresses of the multicast group members. An end-point may also request to receive on-line Incremental Membership Notications (IMNs). Each time that the multicast group membership changes, the current membership of a multicast group may be derived from IMNs. An end-point may become a group member by joining a group or cease its membership by leaving a group through the congress API. Each join or leave request of an end-point leads to a generation of an IMN w.r.t. a specic group. IMNs may be also triggered by various asynchronous network events, i.e., host or communication link crash/recovery. congress services are provided by a set of servers. There are two kinds of congress servers: Local Membership Servers (lmss) and Global Membership Servers (gmss). An lms resides in each host and is a congress front-end for the end-points on that host. gmss are organized in a hierarchical structure throughout the network, and may run on either dedicated machines or in switches. gmss maintain data structures that eciently aggregate the global membership information. A congress server operates in conjunction with two modules: R-fo and fault detector. R-fo is a transport protocol that supports reliable FIFO message passing between the neighbouring congress servers. Examples of such transport protocols may be found in. 10,9,20 In 11 the theoretical aspects of fault detection are covered. In 24 a framework for implementing a fault detector in a WAN is provided. This paper deals with the implementation of a congress server entity and assumes the existence of the appropriate fault detector and R-fo transport layer. Their use will be claried later in Subsection 4.5. congress views the network as a hierarchy of domains, where each domain is serviced by a congress server y. At the lowest level, a domain consists of a set of the end-point applications running on some host. Such a domain is called a host domain and is serviced by the lms of the host. The lms is called a representative of a host domain. Higher level domains consist of a set of the lower level domain representatives. Thus, a single gms may serve a The full reference model for native ATM services (Native ATM SAP) is given in. 7 y The congress hierarchy can be readily mapped onto a peer group hierarchy provided by the native ATM network layer, PNNI. 8

4 Applications Native ATM API Existing Transport API(S) CONGRESS Library Native ATM Library Other API libraries Traditional transport & network protocols Native ATM SAP Other services Connection and Data Distribution UNI Services Figure 1. Position of the congress library in the reference model model for native ATM Process (end point) using CONGRESS Process (end point) using CONGRESS Figure 2. The congress' Hierarchy Structure

5 domain that consists of either several lmss, or several gmss that are representatives of their respective lower level domains. A congress domain identier is the longest common address prex of the domains it is built of. An example is shown in Figure 2. One can see a sample domain 1:1 that is comprised of two domains: 1:1:1 and 1:1:2. The domain 1:1:2 is comprised of three host-domains 1:1:2:1, 1:1:2:3 and 1:1:2:4. The domain identier of a host-domain is the full address of the lms' host z. 3. CONGRESS SERVICES 3.1. Support for Multicast Groups congress denes a multicast group G as a pair: G < N; S >, where N is a group name, specied as an arbitrary user-dened character string, and S is a scope of G specied as a domain prex. A group G will be known in all congress domains having the prex S specied by its scope. Two groups G 1 < N 1 ; S 1 > and G 2 < N 2 ; S 2 > are considered the same i N 1 = N 2 V S1 = S 2. multicast groups supported by congress can be either permanent or spontaneous. Permanent groups are used to implement well known services. These groups are created/disposed through administrative measures that are out of the scope of this paper. Spontaneous groups, in contrast, are intended for public usage. A spontaneous group is created when the rst end-point joins it, and is disposed when its last member leaves it. Although join requests may be concurrent, congress will always create only a single multicast group with a specic name and scope. Our exible naming scheme allows application designer to give meaningful names to the groups that they utilize. The scoping mechanism permits the multicast groups with the same names and dierent scopes to coexist. This minimizes the chance of collision between group names chosen by dierent applications. The scoping mechanism also restricts congress message propagation w.r.t. a specic multicast group, to the scope of this multicast group. Thus, scoping conserves bandwidth and improves scalability User API The congress library provides the following functions: join(g, type): Makes the invoking end-point a registered member of group G. G may be either spontaneous, or permanent as specied by the type parameter. leave(g): Unregister the invoking end-point from G. resolve(g): A multicast group name G:N with the scope G:S is resolved into a set of the ATM end-point identiers. This set includes all the end-points who joined G and have not disconnected due to a network failure or a host crash. set ag(g, online flag): Enables or disables the reception of the IMNs w.r.t. G, by the invoking end-point Data Structures 4. CONGRESS PROTOCOL In this subsection we summarize the main data structures used by both lms and gms types of congress servers. Each lms maintains a Local Members Table in which it maintains for each multicast group the list of local end-points that are members of the multicast group. Multicast groups that have no members in the local machine are not listed. In order to avoid constant ooding of the network with excess messages, the gmss maintain for each group G a distributed group control tree, T (G), that is a sub-tree of the congress hierarchy tree. Vertices of T (G) are lmss z There is no relation between the addresses in Figure 2 and the IP addresses whatsoever. illustrate the hierarchy idea in the most simple way. The IP-like addresses were chosen to

6 and gmss (where lmss are the leafs of T (G)) that have the members of G in their respective domains. All congress protocol messages concerning G are conned to T (G). Each maintains only a local part of T (G) for each multicast group G in a vector GT (G). GT (G) holds an entry for each neighbour (i.e., parent, sibling or child) of the in T (G). A value of an entry in this vector can be either resolve, or all. If the entry value is resolve, only resolve requests are forwarded to the corresponding neighbour (because no member of G in the neighbour's domain have set the on-line ag). A value of all means that all congress protocol messages concerning G should be forwarded to that neighbour. When a gms rst creates a vector for a group, all its entries are initialized to all for each of the gms's neighbours. Each gms also keeps track of the liveliness of its neighbours through updates supplied by its fault-detector module End-Point Joining/Leaving a Group When an end-point wishes to join a multicast group G, it issues a join request to its lms, l, using local IPC mechanisms. Next, l informs its gms about the new member in its domain by forwarding a join message. Now, the gms must propagate the join message to all the end-points of G that requested IMNs. In addition, all gmss which have the joining end-point in their domain must record that G now has members in their domain, if it was not already so before. Thus, the message is propagated as described next. If a gms receives the join notication from one of its children c, and GT (G) does not exist (i.e., the new member of G is the rst one in the gms's domain), then the gms initializes GT (G), and forwards the join notication to all its live siblings. If the scope of G is a prex of the gms' parent domain identier, then the notication will be forwarded to the parent as well. If GT (G) exists, the gms sets GT (G; c) to all and forwards the notication to all its live siblings (and parent, if G is included in its scope) that have all in their corresponding entries of GT (G). As a special case, upon the reception of the join notication directly from an lms, a gms forwards it also to all of its children (i.e., lmss) that are alive and have all in their corresponding entries of GT (G), excluding the originator. If a join notication w.r.t. G was received by a gms from its parent or a sibling, x, and GT (G) does not exist, the notication is ignored. Otherwise, the entry GT (G; x) is set to all and the gms forwards the notication to all its live children that have all in the corresponding entries of GT (G). Upon the reception of the notication about a new member joining G from its gms, an lms delivers a corresponding IMN to all the local end-points that are members of G and have their on-line ag set to true. In order to maintain a T (G) accurately, gmss should prune all their neighbours that do not have members of G in their respective domains, from their GT (G) entries. This will allow to keep the message overhead linear in the size of G. Immediately after the registration of a new end-point, the local lms issues a resolve request w.r.t. G, on its behalf. This request is handled as described in Subsection 4.4. The congress servers that reply with an empty lists of members are removed from GT (G) by the gmss throughout the hierarchy. Note that if a parent gms reply with an empty list to its child, the child does not remove the corresponding entry of the parent from its GT (G), since the parent provide the connectivity to the rest of the hierarchy. An end-point leaves a multicast group through issuing a leave request to its lms. The propagation of the leave notication corresponding to this request is exactly the same as that of the join notication described above. In addition, if a gms s discovers that there are no more members of a group G in its domain, it deletes the GT (G) vector from its GT. After that, s informs all its neighbours to which it forwarded the corresponding leave notication that they should remove GT (G; s) entry from their GT s x. Note that an lms knows that a group should be deleted by directly monitoring the membership of its local end-points. A gms knows that a group should be deleted when all of its children have reported that there are no more members of a group G in its domain Reception of Incremental Membership Notications Whenever an end-point wishes to start or stop receiving IMNs (Incremental Membership Notications) w.r.t. a group G of which it is a member, all the gmss that have members of G in their domain must know this. This is necessary for accurate propagation of future membership changes of G occurring in their domain. However, a notication of this request is not necessary to be received by gmss if the requesting end-point is not the rst inside (or outside) the x The set of these neighbours does not include neighbouring lmss

7 gms's domain to request IMNs. The same is true if the last end-point inside (or outside) their domain, requests to stop receiving IMNs. Let G 0 be the set of members of G that requested to receive IMNs. When an end-point ep desires to receive IMNs w.r.t. a multicast group G, it issues a set ag request with the online flag parameter set to true to its lms. If ep is the rst member of G 0 in the lms's domain, the lms forwards the set ag request message m to its gms. Similarly, when ep desires to stop receiving IM Ns, it issues a set ag request with the online flag parameter set to false to its lms. If ep was the last end-point of G 0 in the lms's domain, the lms forwards the message to its gms. When a gms receives m from a neighbour, it sets the entry of this neighbour in GT (G) to all if online flag is true, and to resolve otherwise. If ep is the rst member of G 0 in the gmss domain or G 0 has no more members in this domain, m is forwarded to all the siblings that are listed in GT (G), and, possibly, to the parent (depending on the scope of G). If ep is the rst member of G 0 outside the gmss domain or G 0 has no more members outside this domain, then m is forwarded to all the children of the gms that are listed in GT (G). It should be noted, that each congress server always has a value of all for his parent for all the multicast groups listed in its GT Resolution of a Group Name An end-point that is a member of a multicast group G, can resolve G's name into a list of the live registered members by issuing an appropriate resolve request to its lms. The lms then generates an appropriate message m from it, and forwards m to its gms. When a gms receives m from one of its children, it forwards m to all the live siblings and, possibly, the parent that are listed in GT (G) {. As a special case, if m was received from an lms, the gms also forwards m to the live lmss that are listed in GT (G). If m was received by the gms from either its parent or a sibling, it forwards it to all the live children that are listed in GT (G). The gms then collects the responses to m until all the neighbours have responded or became disconnected. Then the gms sends the aggregated response to the neighbour from which the request was received. When an lms receives a resolve reply message m, it responds with the list of all the local end-points that are members of G. If there are no such end-points, the lms responds with an empty list. This way, the resolve request is propagated to the relevant lmss that are leaves of the T (G). The responses of these lmss are aggregated by the gmss, the intermediate nodes of T (G). The nal response will be received by the lms that originated the resolve request from its gms and will be delivered to the end-point k Handling of Failures We assume that omission, reordering and duplication faults are handled by an underlying reliable transport protocol as mentioned above. We also assume that messages are not corrupted by the network. The congress handling of failures focuses on asynchronous host crash/recoveries, and communication links failures/recoveries. In order to handle these failures, each congress server interacts with a local fault detector entity that monitors the liveliness of this congress server neighbours. All the messages that are sent/received by a congress server via the reliable transport layer, pass through the fault detector in the rst place. Thus, a message received from a congress server is interpreted by the fault detector as the evidence of the sender's liveliness. If a server's neighbour was suspected by the fault detector of this server, and later a message from the presumably failed neighbour was received, the fault detector delivers the notication about the neighbour's liveliness before the delivery of its message End-point Failure When an end-point fails, a local lms discovers this using internal IPC mechanisms. This event is handled by the lms as if the failed end-point had issued a leave request w.r.t. to all the groups of which it was a member. { The parent is included only if it is in the scope of G. k If there are multiple end-points on the same host that have issued a resolve request to the same group G, then protocol may be optimized to initiate a single resolve request

8 Domain Failure When a congress server disconnects from the rest of the hierarchy due to a communication link failure or a host crash, this event is interpreted by its neighbours as if all the end-points that reside in its domain have left their respective groups. Instead of sending multiple leave notications, each gms that detects a failure of a neighbouring congress server, generates a domain leave notication message that contains the domain identier of the failed domain and a list of all the multicast groups that had members in this domain. The latter is obtained from the local GT table. The domain leave notication is propagated and processed throughout the congress hierarchy in the same way as a join/leave notication. An end-point outside the failed domain can compute a new membership of a multicast group from the domain leave notication, by discarding all the end-points that have the same address prex as the failed domain identier. Similarly, an end-point within the failed domain discards all the end-points that have the address prex dierent from that of the failed domain Domain Recovery A gms and its respective domain are considered recovered whenever the gms re-connects or re-starts execution. For each group G in the recovered domain, group membership information must be updated throughout the re-merged T (G). A previously crashed gms initializes its data structures as described in 4.1. When a gms detects (through the fault detector) a recovery of one of its siblings in the congress hierarchy, it resolves all the multicast groups that are present in its GT by issuing resolve requests to its children. The aggregated replies of these resolve requests are sent as ordinary join notications to the recovered sibling. When a gms detects a recovery of one of its children, it does not perform any actions except marking this server as alive. The necessary actions will be initiated by the recovered child as described below. When a congress server detects a recovery of its parent, it generates resolve requests to its children w.r.t. all the multicast groups whose scope includes the recovered parent. The aggregated results are sent to the parent as special join notications. These notications are forwarded as ordinary join notications, but are also marked with a special ag. When such a message w.r.t. a multicast group G is received by some gms from its sibling, the gms resolves the membership of G within its domain and sends back the aggregated result as an ordinary join notication. 5. APPLICATIONS OF CONGRESS In this section we give examples of the application that will benet greatly from the use of a low-level native ATM protocol like congress for maintaining dynamic multicast group membership Native ATM Applications Pay TV Application Consider a world-wide television broadcasting service in which a group of servers receives broadcast signals from a geo-stationary satellite. The servers propagate it to the clients at home through the ATM network with high QoS using point-to-multipoint connections. Many dierent services can be provided at any time, e.g. several simultaneous programs. For the purpose of load-balancing, each service is supplied only by some of the servers. In addition, each client can receive the service only from those servers to which there is connectivity through the network. And nally, to save bandwidth, only clients that have their televisions open and tuned to a specic service should receive signals for that service. This scenario raises three issues: the clients need to notify some server providing the service about its desire to receive the service; the servers need to maintain high bandwidth point-to-multipoint connections to dynamically changing groups of clients; the servers need a mechanism for load balancing. Note that the scope of the multicast groups listed in this GT include the gms's siblings by denition.

9 The rst two problems may be resolved in framework of an ATM anycast service provided by UNI However, ATM anycast service provides its user with point-to-point connections only. In order to achieve eciency, native ATM multicast connections should be used. Additional steps that are beyond the ATM anycast service should be taken in order to add a client as a leaf in the server-rooted multicast tree. Another limitation is the impossibility to provide a load-balancing algorithm among the servers. Usage of the ATM anycast will override such an algorithm, and the network will choose a server based on its own considerations. These limitations make the ATM anycast service inconvenient for development of the Pay TV application. congress provides a dynamic multicast group abstraction that facilitates the solution of the three problems stated above. In the above example, the broadcasting service could be represented by a logical group name called \PayTV", for example, which a client can join to receive the service without knowing which and where the active servers are. An active server would resolve the clients' addresses through the group name \PayTV" in order to establish a point-to-multipoint connection to the clients. The explicit knowledge of the group membership would help to design a load balancing algorithm. Video Chat Application As a second example, consider a video chat application, like CU-SeeMe, 12 implemented over native ATM. The most natural mechanism for the data transfer in such application would be multicast. The problem, however, is that the membership of a group of participants is not known in advance. It is impossible to open a point-to-multipoint connection in ATM, if the ATM addresses of the participants are not known. Note also that this information is dynamic, because participants may join and leave the chat sessions arbitrarily (like in the IRC application or the Netscape Chat). Working with congress an end-point that wants to join an arbitrary video-chat group can request upon joining, the ATM addresses of the other end-points participating in the chat. Using the received address list, the new member can form connections to the other members with any desired QoS and start gossiping. At the same time, the other members of the group will receive a notication about the new member and add him to their own connections so he can hear their own gossip IP over ATM Multicast Short-Cut Routing In this section we present ip-senate, a conceptual solution for IP over ATM multicast short-cut routing, built on top of congress. The classical IP network over an ATM cloud consists of multiple Logical IP Subnets (LISs) interconnected by IP routers. 17 In the classical LIS model, LIS has the following properties: All members of a LIS have the same IP network/subnet number and address mask; All members of a LIS are directly connected to the same NBMA subnetwork; All hosts and routers outside the LIS are accessed via a router; All members of a LIS access each other directly (without routers). As explained in, 19 the classical LIS model may be too restrictive for networks based on switched virtual circuit technology, e.g., ATM. Obviously, if LISs share the same physical ATM network (ATM cloud), the LIS internetworking model may introduce extra routing hops. This mismatch between the IP and ATM topologies may preclude full utilization of the capabilities provided by the ATM network (e.g., QoS). In addition, the extra routing hops impose an unnecessary segmentation and reassembly overhead, because every IP datagram should be reassembled at every router in order that it could take routing decisions. IP \cut-through" routing 2,18,21 is intended to overcome the limitations of the classical IP routing emulated on top of ATM. The development of NHRP, 18 a protocol for discovering and managing IP unicast forwarding paths over ATM that bypass IP routers, lead many people to seek for a multicast equivalent. Unfortunately, providing an NHRP equivalent for multicast is not a trivial task, as was shown in. 2 To the best of our knowledge, currently there is no proposal for IP multicast cut-through mechanism that is scalable to an ATM WAN. congress can be used to implement such a mechanism, as will be explained.

10 A designer of a short-cut routing multicast solution is opposed with a scalability problem. If hosts are allowed to communicate directly with other hosts (as in 2 ), bypassing the multicast routers, then each host must maintain membership information about all other hosts scattered all over the internet and belonging to the same IP multicast group.this scheme does not scale well because hosts must maintain large amounts of data that should be kept consistent and updated and because the number of connections each NIC can support simultaneously is limited. To mitigate this problem, ip-senate performs cut-through routing only among the multicast routers. We can summarize the ip-senate features as follows: ip-senate is a best eort service. ip-senate does not guarantee that short-cut is always possible, but it attempts to perform the short-cut wherever possible. ip-senate facilitates (a) a full mesh of ptmpt connections based communication, (b) multicast servers based communication and (c) a hybrid form of communication based on the previous two. ip-senate facilitates migration from a mesh of ptmpt connections to multicast service-based connections and for load-balancing among the multicast servers without a need for global reconguration. ip-senate is an inter-lis protocol. It extends only the multicast routers. Host interface to IP multicast services 14 is not changed. ip-senate relies on some standard intra-lis IP over ATM multicast solution, like 3 to facilitate all the intra-lis IP multicast trac. ip-senate facilitates a straightforward interface to the ATM QoS for the cut-through connections established among the multicast routers. The full utilization of this feature, obviously, requires native ATM connections between the multicast routers and the hosts and that non-atm components of the internet support QoS that can be mapped onto ATM QoS (as in 25,23 ). ip-senate organizes IP multicast routers into logical groups, where each group corresponds to some class D IP address and contains routers that have members of this IP multicast group or senders to it in their domain. These groups are termed D-groups. ip-senate uses congress services in order to manage D-groups and to resolve D-group addresses into the addresses of the IP multicast routers. IP class D addresses are treated by congress as logical multicast group names. The multicast routers that connect IP networks to an ATM cloud are augmented with the s that provide an interface to the congress services. These augmented routers are termed ip-senate routers. Upon the reception of an IP multicast packet, an IP multicast router uses congress services in order to obtain the list of the ATM addresses of the corresponding D-group members. Then it can use native ATM multicast connections in order to multicast this packet to the relevant multicast routers bypassing the IP routing mechanisms. In the classical IP multicast model, 14 a host does not have to become a registered member of a multicast group in order to send datagrams to this group. ip-senate provides the hosts with the same interface for IP multicast service as in the classical model. An ip-senate router, however, should know about all other ip-senate routers that should receive the trac targeted to a specic class D address, i.e., about all other members of the relevant D-group. In order to obtain the membership of a D-group, an ip-senate router joins this group via CONGRESS. It may seem that an ip-senate router that does not have any downstream receivers (neither routers, nor hosts) does not need to be a member of a D-group because it does not need to receive any trac. Such a router could have used the CONGRESS resolve operation each time it needs to learn about the membership of the corresponding D-group (for example, when it needs to send a datagram originated by a sender in its domain). In this scheme, however, CONGRESS would have been heavily used and unnecessary overhead on the network would be imposed. In our approach, an ip-senate router joins the relevant D-group even if it does not have to receive the multicast trac. In this case, it will receive IMNs concerning the D-group. These scheme is less costly. In order to prevent such a router, from being added as a leaf to the cut-through connections within the D-group, special sub-identiers are added to the ip-senate router's identier. As mentioned earlier, the fact that ip-senate performs cut-through routing only among routers, reduces the number of connections among a multicast group's members. However there may be cases where the number of

11 ,3$70&ORXG,3,3,3,3,3,36(1$7(5RXWHU&OLHQW,36(1$7(5RXWHU6HUYHU Figure 3. General layout of a D-group multicast routers that are members of a certain D-group is large, and then the number of active connections among these routers is higher than what can be supported by contemporary NIC. In order to overcome this limitation, some ip-senate routers also function as multicast servers for other routers that are termed clients. Although the multicast server idea is not new, currently there is no generic solution for dynamic deployment of multicast servers in the WAN environment. An ip-senate router locally decides whether it will assume a client or a server role upon joining the relevant D-group. The decision depends on a number of connections that are already supported by the ip-senate router's NIC and the number of additional connections that need to be supported, if the router decides to assume a specic operational role. A general layout of a D-Group consisting of several multicast routers operating as clients or servers, is depicted in Figure 3 When an ip-senate router joins a D-group, assuming the client operational role, it expects that some server will take care of it. During the period of time when no server takes care of this client, the client may use another IDMR (Inter-Domain Multicast Routing) protocol (e.g., DVMRP 13,22 or PIM 15,16 ) for the forwarding of IP multicast trac. The ip-senate routers that act as servers, learn through the CONGRESS' IMNs about the new client. Based on the load of the server's NICs and CPU, physical distance, administrative policies etc., each server locally decides whether to take care of the new client. If a server decides to serve a client, it tries to open a native ATM VC to this client (or to add this client as a leaf to an already opened ptmpt connection). If the client has already accepted some other server's connection set-up request, it may either refuse to accept the new connection, or tear down the previous connection and to switch to the new one. In both cases this is a local decision of the client. In case of some server's failure, all its clients should re-join the relevant D-group. This will once again trigger the procedure described above. Cut-through mechanisms may have a negative impact on the conventional IDMR protocols. The problems of interoperability of the short-cut routing with the IDMR protocols are left out of the scope of this paper. An interested reader is referred to 1 that provides a discussion of the interoperability issues. 6. CONCLUSIONS AND FUTURE DIRECTIONS We presented a novel protocol for resolution and management of multicast groups, scalable to WAN and being a complementary to the native ATM multicast mechanisms. Our protocol may be used either for the native ATM applications (CSCW, Pay TV, Video on Demand etc.), or for improvement of the traditional networking protocols such as IP multicast. A prototype of congress is currently under construction using the OPNET network simulator. A full prototype implementation is expected by fall Currently, the protocol is not fully fault tolerant. If a congress server fails, its domain becomes disconnected from the congress services outside the domain. One of the future directions in development of congress, is devising of consistent replication scheme for the gmss. REFERENCES 1. T. Anker, D. Breitgand, D. Dolev, and Z. Levy. IMSS: IP Multicast Shortcut Service. Jerusalem Israel. Internet Engineering Task Force, Internet Draft, July 1997.

12 2. G. Armitage. VENUS - Very Extensive Non-Unicast Service. Internet Engineering Task Force, Internetworking over NBMA (ION) Working Group, February 18th, Internet Draft expires August 18th, G. Armitage. Support for Multicast over UNI 3.0/3.1 based ATM Networks, RFC Bellcore, November ATM Forum. ATM User Network Interface (UNI) Specication Version 3.1. Prentice Hall, Englewood Clis, NJ, June ISBN X. 5. The ATM Forum Technical Committee. ATM User-Network Interface (UNI) Signalling Specication Version 4.0, af-sig , July The ATM Forum Technical Committee. ATM User-Network Interface (UNI) Signalling Specication Version 4.0, af-sig , July Section 7, pages The ATM Forum Technical Committee. Native ATM services: Semantic Descrption Version 1.0, af-saa , February The ATM Forum Technical Committee. Private Network-Network Interface Specication Version 1.0 (PNNI 1.0), af-pnni , March G. Carle. Reliable Group Communication in ATM Networks. In Proceedings of the Twelve Annual Conference on European Fibre Optic Communications and Networks EFOC&N'94, June G. Carle and S. Dresler. Adaptable error control for Ecient Provision of Reliable Services in ATM Networks, December First Workshop on ATM Trac Management WATM'95, IFIP, WG.6.2 Broadband Communication, Paris, December T. D. Chandra and S. Toueg. Unreliable Failure Detectors for Reliable Distributed Systems. J. ACM, 43(2):225{ 267, March Cornell University. The CU-SeeMe Home Page, URL: D. Waitzman, C. Partridge, and S. Deering. Distance Vector Multicast Routing Protocol. IETF, November S. Deering. Host Extensions for IP Multicasting, RFC Stanford University, August Estrin D. et. al. Protocol Independent Multicast Dense Mode (PIM-DM): Protocol Specication. Internet Engineering Task Force, Inter Domain Multicast Routing (IDMR) Working Group, September, Internet Draft. 16. Estrin D. et. al. Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specication. Internet Engineering Task Force, Inter Domain Multicast Routing (IDMR) Working Group, October Internet Draft. 17. M. Laubach. Classical IP and ARP over ATM, RFC Hewlett-Packard Laboratories, December J. V. Luciani, D. Katz, D. Piscitello, B. Cole, and C. Topolcic. NBMA Next Hop Resolution Protocol (NHRP). Internet Engineering Task Force, Routing over Large Clouds Working Group, March Internet Draft expires September Y. Rekhter and D. Kandlur. "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, RFC 1937, May Internet Engineering Task Force, Network Working Group. 20. Romanow A. and Floyd S. Dynamics of TCP Trac over ATM Networks. IEEE JSAC, 13(4):633{641, May M. Smirnov. EARTH - Easy IP multicast THrough ATM clouds. Internet Engineering Task Force, Internetworking over NBMA Working Group (ION), November Internet Draft expires May 25th T. Pusateri. Distance Vector Multicast Routing Protocol. Internet Engineering Task Force, Inter Domain Multicast Routing (IDMR) Working Group, September Internet Draft. 23. C. Topolcic. Experimental Internet Stream Protocol: Version 2 (ST-II), October Internet RFC W. Vogels. World Wide Failures. In Proceedings of the ACM SIGOPS 1996 European Workshop, Connemaran, Ireland, September L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala. RSVP: A New Resource ReSerVation Protocol. In IEEE Network, September The RSVP Project home page: