From wbell@CS.Cornell.EDU Wed Oct 3 11:34:28 2001 Return-Path: Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f93FYRo05023 for ; Wed, 3 Oct 2001 11:34:27 -0400 (EDT) Received: from [192.168.1.103] (syr-66-24-16-64.twcny.rr.com [66.24.16.64]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA26187 for ; Wed, 3 Oct 2001 11:34:24 -0400 (EDT) Subject: 615 PAPER #23 From: Walter Bell To: egs@CS.Cornell.EDU Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.14.99+cvs.2001.09.29.08.08 (Preview Release) Date: 03 Oct 2001 11:34:11 -0400 Message-Id: <1002123275.1236.5.camel@brute> Mime-Version: 1.0 23) The Core-Assisted Mesh Protocol CAMP is the first multicast routing protocol to use meshes instead of trees; which provides a more efficient way to disseminate data because each source has a shortest path to each destination, which isn't true in tree based methods. CAMP avoids using flooding to do control dissemination and is therefore more scalable than previous methods. In addition, in order to provide higher scalability CAMP uses core nodes to to handle membership functionality and to help keep the mesh stable, although core nodes do not need to be members themselves. CAMP is designed to run above a unicast routing protocol, although they recommend that CAMP be integrated into the unicast routing tables for greater efficiency. Nodes in CAMP maintain data structures regardless of their involvement in multicast groups, because at any time they could be asked to become part of the multicast mesh if a new member joins. Routing information is broadcast via periodic heartbeat messages, in which they make sure that the mesh contains all the reverse shortest paths. Unlike other multicast routing protocols, CAMP requires that senders be part of the multicast group, although they may be simplex members of the group, in which packets can only be sent info the mesh and not outward to the sender node. Because of it's mesh-centric structure, CAMP is resilient to node movement and link failure and has provisions for network partitioning and rejoining of connected components of the network. Their simulation studies seem to show good results, although the fixed network topology casted doubt in my mind as to why a random study was not done. I thought the paper was a bit scattered it was hard to find definitions for some of the terms and information was scattered across the paper. A more coherent discussion of the basic would have been useful, as most of the paper revolved around low level details without adequately motivating where problems arose. From viran@csl.cornell.edu Wed Oct 3 20:19:10 2001 Return-Path: Received: from moore.csl.cornell.edu (moore.csl.cornell.edu [132.236.71.83]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f940J9o09272 for ; Wed, 3 Oct 2001 20:19:09 -0400 (EDT) Received: from localhost (viran@localhost) by moore.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id f940J4X25757 for ; Wed, 3 Oct 2001 20:19:04 -0400 (EDT) (envelope-from viran@moore.csl.cornell.edu) X-Authentication-Warning: moore.csl.cornell.edu: viran owned process doing -bs Date: Wed, 3 Oct 2001 20:19:04 -0400 (EDT) From: "Virantha N. Ekanayake" To: Subject: 615 Paper 23 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The Core-Assisted Mesh Protocol proposes a multicast routing protocol based on graphs (meshes) as opposed to the more traditional tree structure. A multicast mesh is a subset of the network topology that provides at least one path from a source to receivers. This provides a degree of redundancy, and the use of core nodes limits the flooding of the network with topology maintenance information. CAMP has two types of routing nodes -- Duplex (which can send information in both directions) and Simplex (which are used for send-only hosts), which keeps traffic from heading away from receivers (however, the simulation only modelled duplex nodes). It attempts to maintain shortest paths by keeping track of packets that arrive from nodes not on the current reverse shortest path (RSP) to the source (determined by looking at the unicast routing table), and sending a heartbeat message to the source via the RSP. If any node on the RSP is not a member of the mesh then a push join message forces the nodes on the RSP to become members. The paper was a little confusing to read -- it sorely lacked a high level overview, and a summary of the key points of the protocol. It seems like it needs some unicast protocol based on distance vectors (to provide hop counts). However, in its present form it cannot work with on-demand protocols, thus limiting its scalability considerably. From papadp@ece.cornell.edu Thu Oct 4 09:54:30 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94DsUo04447 for ; Thu, 4 Oct 2001 09:54:30 -0400 (EDT) Received: from photon (photon.ee.cornell.edu [128.84.239.166]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id f94DtMR11905; Thu, 4 Oct 2001 09:55:22 -0400 Date: Thu, 4 Oct 2001 10:03:55 -0400 (EDT) From: "Panagiotis (Panos) Papadimitratos" X-Sender: papadp@photon.ee.cornell.edu To: Emin Gun Sirer cc: Panagiotis Papadimitratos Subject: 615 PAPER 23 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Review of : "The Core-Assisted Mesh Protocol," by J.J. Garcia-Luna-Aceves and E.J. Madruga Panagiotis Papadimtratos papadp@ee.cornell.edu The authors present a protocol for multicast routing in ad hoc networks, designed to function in highly dynamic topologies based on building and maintaining a multicast mesh. The mesh is practically a subgraph of the multihop topology that provides at least one path connecting any pair of source and receiver within the multicast group. The use of a mesh for the distribution of data within the group implies that the simplicity of multicasting based on minimum spanning trees is sacrificed. Nevertheless, the mesh structure engulfs, due to its higher connectivity (compared to a tree), the corresponding shortest paths, and at the same time provides resilience and communication efficiency. Although mesh multicasting has been previously used, the core-assisted mesh protocol (CAMP) introduces the use of core nodes in mesh routing, as explained below, and, unless all cores are unreachable, flooding is avoided as a means for the mesh creation. Nodes join and leave one or more groups dynamically and for each group a mesh is created and maintained, including senders, receivers, and possibly nodes acting as simple relays. Among the mesh nodes, some of them are designated as 'cores', which facilitate the nodes' joining the group and limit the control traffic overhead. CAMP differentiates itself by determining multiple cores per group, while not requiring the existence of (i.e., reachability to) any core so that a node joins the group, or that the core has to be part of the group mesh. Apparently, one node may belong at any point in time to several meshes and for each group information has to be retained so that the protocol functions: among others, the core nodes identifiers, the multicast routing table, a unicast routing table and the set of 'anchors', i.e., the 'upstream' nodes on the mesh. It is assumed that a unicast routing protocol, independent of CAMP, exists along with a beaconing/heartbeat protocol and that a mapping between groups and multicast addresses exists. More specifically, m- addresses of cores are disseminated from each core out to the network as part of group membership reports. The node that wishes to join a group issues/broadcasts a request and first, it tries to determine whether any of its neighbors are group members. If not, the request is sent towards a core (using the unicast routing table), and persists in 'announcing' its membership in case the core is not reachable. If all the cores are unreachable, an expanded ring search (ERS) attempts to reach a group member. In terms of the data forwarding, a caching mechanism is used, with duplicates being discarded. It is important though that packets can be received by any of the node's neighbors, in contrast with tree-based schemes that rely on establishing and maintaining a single branch. . Nevertheless, the mesh scheme does require the exchange of heartbeat and push join message in order to ensure that reverse shortest paths, connecting source/receiver pairs, belong to the mesh. The use of redundant paths to any other mesh node renders topology changes less likely to disrupt the flow of multicast data. Consequently, the reconstruction/maintenance of the routing structures that support data forwarding can be less frequent, for example when all such paths fail. In other words, link failures, which can be very common in MANETs, can be successfully masked and on the other hand, the CAMP join mechanisms allow for fast fixes. This is especially true due to the fact that cores are not indispensable in the join process, as explained above. And, many cores per mesh can be used, so that there is no single point of failure. With the mesh merging mechanism taken into consideration as well, one can conclude that CAMP has indeed features that allow it to cope with a dynamic environment. However, it is not clear whether the imposed overhead, on top of that of the unicast protocol, could severely limit the applicability of the relatively complicated scheme. The reason is that the presented comparison is performed over a single topology instance, while increased mobility could result in increased control overhead and performance degradation of the CAMP scheme. Or, from a positive point of view, I would expect that the redundancy of the structure (cores, anchors etc) would be performing better for many sender/receivers. From eyh5@ee.cornell.edu Thu Oct 4 10:35:27 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94EZQo09257 for ; Thu, 4 Oct 2001 10:35:26 -0400 (EDT) Received: from hegel (hegel.ee.cornell.edu [128.84.236.63]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id f94EaIR13058 for ; Thu, 4 Oct 2001 10:36:18 -0400 Date: Thu, 4 Oct 2001 10:35:24 -0400 (EDT) From: Edward Hua To: egs@CS.Cornell.EDU Subject: 615 Paper # 23 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The Core-Assisted Mesh Protocol (CAMP) J.J.Garcia-Luna-Aceves and Ewerton L. Madruga This paper proposes a multicast operation in an ad hoc network, called the Core-Assisted Mesh Protocol (CAMP), that is based on meshes, not multicast trees in many other similar proposals. The advantage of multicast meshes is that it does not requireflooding the control and data packets, as is a common practice in tree-base multicast schemes. By employing CAMP, data packets may be accepted by a mesh router even if they are not originated from within the mesh, wheras in the multicast tree operation, a router may only accept packets from routers with whom a tree branch is established. This added ability gives packet routing expanded freedom to pursue a shortest path between source and destination. A key component of the CAMP scheme is the use of an anchor. Its function is to ensure the routers that are required by their neighbors to forward multicast packets do not leave a multicast group prematurely. Because of the presence of anchor, an established multicast mesh would not easily dissolve and the nodes would not have to reconstruct linkage with their neighbors when the link is severed. In order to accommodate some routers who only wish to send packets to the multicast group, but not receive them from the group, CAMP allows the routers to join the mesh in simplex mode. That is, the flow of the traffic is uni-directional, from these simplex routers to the rest of the network, and no packets may be transmitted to them. It is shown in the paper that simplex mode can reduce delays in the distribution of packets from non-member nodes and cause less congestion at the core routers. One improvement in CAMP is its guard against link failures. In a mesh operation, the network can tolerate a certain degree of link failures without taking any action. This is because the mesh structure itself provides multiple paths to route packets should a link breakage occur. This is superior to a multicast tree, where the link breakage will necessarily invoke reconstruction operation to take place immediately before packet transfer can be resumed. A further reseach topic of interest may be to what degree the network can tolerate such link breakages. From daehyun@csl.cornell.edu Thu Oct 4 10:56:03 2001 Return-Path: Received: from wilkes.csl.cornell.edu (wilkes.csl.cornell.edu [132.236.71.69]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94Eu2o12006 for ; Thu, 4 Oct 2001 10:56:02 -0400 (EDT) Received: (from daehyun@localhost) by wilkes.csl.cornell.edu (8.9.3/8.9.2) id KAA47794 for egs@cs.cornell.edu; Thu, 4 Oct 2001 10:55:57 -0400 (EDT) (envelope-from daehyun) From: Daehyun Kim Message-Id: <200110041455.KAA47794@wilkes.csl.cornell.edu> Subject: 615 PAPER 23 To: egs@CS.Cornell.EDU Date: Thu, 4 Oct 2001 10:55:57 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This paper proposes a multicast routing protocol called Core-Assisted Mesh Protocol (CAMP). The main idea of CAMP is to use multicast mesh instead of multicast tree. Meshes have more connectivity than tree, so it is more suitable for ad-hoc networks where nodes move frequently. the key difference between mesh and tree is that mesh accepts packets from any neighbor, but tree accepts only from the tree-established neighbors. So, tree provides only one path between two nodes, which results in low connectivity in ad hoc network. But, mesh provides multiple paths to solve the problem. And it still avoids loops. Another unique feature of CAMP is that it uses core. CAMP extends the Core-Based Tree (CBT) protocol to create multicast meshes. by using core, CAMP eliminates the need for flooding, which can reduce the control traffic. one or multiple core are defined for a mesh, and a node which want to join send a request to a core. Multiple reply might be received, then one of them is chosen to establish a path to mesh. In my opinion, the main contribution of this paper is that it proposes a multicast routing protocol which does not use a tree structure. By using multicast mesh CAMP can support ad hoc networks much better than other protocols. In addition, it uses core to avoid flooding. From gupta@CS.Cornell.EDU Thu Oct 4 10:56:11 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94EuBo12018 for ; Thu, 4 Oct 2001 10:56:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: 615 PAPER 23 Date: Thu, 4 Oct 2001 10:56:10 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D430202E3E9@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 23 Thread-Index: AcFM5LFnEJmgWbXPEdW1vgCgydyP2Q== From: "Indranil Gupta" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f94EuBo12018 The Core-assisted mesh protocol, Garcia-Luna-Aceves and Madruga. Reviewer: Indranil Gupta This paper suggests using a 'core' - a well connected graph, rather than a tree, among the routers of the multicast group. The idea itself is not unique to the paper (the authors mention that ODMRP and FGMP have similar ideas), but their solutions attempt to restrict core-repair messages to among the core members, rather than use flooding. The multicast tree is maintained on-demand, in response to member joins and leaves, and link failures. Simulation results reveal that the new protocol (CAMP) delivers more packets than a tree -based protocol like WTP. However, this seems to be a piecemeal and partial comparison, essentially a stick to beat tree-based protocols with - eg., when there are few link breakages under low mobility conditions, WTP might be a perfectly good protocol, possibly outperforming CAMP in the network load it imposes per muilticast. The authors just mention that the average packet delays (and the load on the network) in WTP is far lesser than that in CAMP. Given the right mobility conditions, WTP might well be a better protocol than CAMP. Thus, the paper does a bad job of evaluating the core-based algorithm against the tree based algorithm, instead choosing to compare it against yet another core-based protocol ODMRP. From avneesh@csl.cornell.edu Thu Oct 4 11:14:49 2001 Return-Path: Received: from capricorn.ds.csl.cornell.edu (capricorn.csl.cornell.edu [132.236.71.92]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94FEno14367 for ; Thu, 4 Oct 2001 11:14:49 -0400 (EDT) Subject: 615 Paper 23 Date: Thu, 4 Oct 2001 11:15:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <97C142C1212ED545B0023A177F5349C4053ACD@capricorn.ds.csl.cornell.edu> Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 Paper 23 Thread-Index: AcFM51YVqkG3pqigQtaAAM2NvgwUUA== From: "Avneesh Bhatnagar" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f94FEno14367 The Core Assisted Mesh Protocol The CAMP protocol introduces an interesting alternative to multicast trees in order to perform multicast routing. When multiple sources have to transmit information to the same set of destinations, there are two options: a. Shared multicast tree b. separate multicast trees. The shared idea may not be optimal while separate trees cause redundancy. The multicast mesh idea as used in CAMP provides at least one path between source and destination, which in turn also results in higher connectivity between nodes. The degree of fault tolerance is also increased, along with higher communication efficiency. CAMP is different from other mesh based protocols, since it allows the existence of one or more cores within the mesh. There are three kinds of nodes: sender/receiver, receiver and relay. The core nodes, like any other core node has the benefit of handling control traffic. The CAMP protocol uses (like MAODV), a multicast routing table, a unicast routing table and a list of nodes which are upstream to the mesh (called anchors). The unicast routing protocol may not be a part of CAMP and should have some local connectivity maintenance control messaging. In order to join the mesh, a node will try to find out if any of its neighbors are part of a mesh, otherwise a request is then sent to the core (information of which is contained in the unicast routing table). If neither of this works, then an expanding ring search is used. Link breakage is not a big issue in CAMP, because of other paths between source and destination. However push join messages are still used to maintain the consistency of the reverse shortest paths. Another good point is the way a node might want to participate in the routing of packets. It might join in Simplex mode (only send, no receive) or duplex mode. I think that the CAMP protocol due to its redundancy features might perform very well in some adhoc environments. It would have been interesting to see the relative performance of CAMP with other mesh based protocol, especially in the case of higher node mobility. The tree based evaluations help confirming the obvious advantages of CAMP over the tree based approach. From c.tavoularis@utoronto.ca Thu Oct 4 11:42:00 2001 Return-Path: Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94Ffxo18005 for ; Thu, 4 Oct 2001 11:41:59 -0400 (EDT) Received: from webmail1.ns.utoronto.ca ([128.100.132.24] EHLO webmail1.ns.utoronto.ca ident: IDENT-NOT-QUERIED [port 40629]) by bureau6.utcc.utoronto.ca with ESMTP id <238433-536>; Thu, 4 Oct 2001 11:41:53 -0400 Received: by webmail1.ns.utoronto.ca id <126209-22902>; Thu, 4 Oct 2001 11:41:38 -0400 To: COM S 615 Subject: 615 PAPER 23 Message-ID: <1002210096.3bbc833061bae@webmail1.ns.utoronto.ca> Date: Thu, 04 Oct 2001 11:41:36 -0400 (EDT) From: c.tavoularis@utoronto.ca MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 Core-Assisted Mesh Protocol (CAMP) provides multicast routing in ad hoc networks by introducing the idea of core-based trees in multicast meshes. Multicast meshes generalize multicast trees by allowing more than one path between any two nodes in the mesh, where as trees restrict to one path. In fact, nodes can accept packets from any neighbors in the mesh. Cores are used in the creation and maintenance of multicast meshes to limit the control traffic, and limit the need for flooding. CAMP provides multicast routing assuming a unicast protocol is already running. In addition to a routing table, nodes keep track of mapping of cores to multicast groups, multicast tables, anchors (next hop in reverse shortest path to at least one node in each group) and various other information. Any node can choose to join a group in either simplex mode for forwarding packets received from specific neighbors to the group, or duplex mode such that it will forward any multicast packets for the group. This distinction allows mesh members to avoid unnecessary dissemination of data to nodes only interested in sending. A node requesting to join a group relays a message along the shortest path to the core node responsible for the group. Any member along the path can reply with a join acknowledgement. Once an ACK is received, or if the node already has multiple duplex member neighbors, it can safely advertise its membership to the group. A node sends a quit notification when it chooses to leave a group. Core nodes may leave a mesh only if they are not already serving as an anchor. Finally, in the event mesh partition, mesh nodes keep record of all core nodes in the multicast group, and can send a join request if connectivity is lost. When changes occur to node status via update received or local mobility, a node will broadcast a Multicast Routing Update (MRU) with group membership and anchor updates. Anchor information prevents nodes from leaving groups when they are still needed for routing. Multicast updates are assumed to be forwarded with unicast updates. Aside from MRUs, periodic heartbeat and push join messages maintain reverse shortest paths within the mesh. In general CAMP relies on the unicast protocol to detect and repair link failures. A convenience of mesh is that it provides alternate paths in the event of topological changes to provide speedy recovery, and Expanding Ring Search (ERS) can be used to locate the mesh if it’s out of reach. CAMP maintains good properties such as loop freedom and uses shortest paths within the mesh. With respect to simulation of CAMP and an alternative protocol ODMRP, CAMP performed well in terms of packet loss and packet delay. The idea of a core set of nodes, or smaller set of node, performing routing is desirable as it reduces the amount of processing and communication overhead. It reduces the need for flooding which is an unreliable and bandwidth consuming method of routing. From teifel@csl.cornell.edu Thu Oct 4 11:42:09 2001 Return-Path: Received: from disney.csl.cornell.edu (disney.csl.cornell.edu [132.236.71.87]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94Fg8o18028 for ; Thu, 4 Oct 2001 11:42:08 -0400 (EDT) Received: from localhost (teifel@localhost) by disney.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id f94Fg3q61431 for ; Thu, 4 Oct 2001 11:42:03 -0400 (EDT) (envelope-from teifel@disney.csl.cornell.edu) X-Authentication-Warning: disney.csl.cornell.edu: teifel owned process doing -bs Date: Thu, 4 Oct 2001 11:42:03 -0400 (EDT) From: "John R. Teifel" To: Subject: 615 PAPER 23 Message-ID: <20011004111716.H14118-100000@disney.csl.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII garcia-luna-aceves & madruga: This paper discusses Core-Assisted Mesh Protocol (CAMP) which is used for multicast routing. Multicast routing requires maintaining a routing tree for a group of routing nodes. The novel idea this paper introduces is a routing graph, called a multicast mesh, that is more resilient and efficient than a routing tree. CAMP does not require flooding an entire network with control or data packets to set up its routing structure. Simulation section is weak. Not convincing that CAMP is better than previous multicasting protocols. From ranveer@CS.Cornell.EDU Thu Oct 4 11:44:12 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94FiCo18132 for ; Thu, 4 Oct 2001 11:44:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: 615 PAPER 23 Date: Thu, 4 Oct 2001 11:44:11 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D430203EDD2@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 23 Thread-Index: AcFM63hfx6m82bdiEdW5awCQJ59Etw== From: "Ranveer Chandra" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f94FiCo18132 The Core-Assisted Mesh Protocol CAMP extends the idea of CBT of using cores for multicast. However, it deviates from CBT in that scalability is no longer the issue. So CAMP stores much more state than CBT. However, CAMP targets stability of the multicast structure by using a mesh for multicast communication. As opposed to CBT and PIM-SM, CAMP does not necessarily fail on the failure of core nodes. The main contribution of CAMP is the use of a mesh structure for multicast. A mesh is more stable, and if built well, would be more resilient to link and node failures. CAMP also does well in avoiding the cores becoming a hot spot. However, the applicability of CAMP is defeated by its assumtions. It assumes a proactive unicast protocol, that has its own overhead. Besides, it uses buffering to avoid loops. this works well when the bandwidth is 1Mbps. Will it work with 802.11a, when the bandwidth proposed could go as high as 54Mbps? Besides, CAMP has weird MAC assumtions: No MAC ensures a reliable broadcast or even a single successful broadcast to all its neighbors. CAMP also assumes prior global knowledge of group address to core members mapping for all groups. This along with the amount of storage puts a question on the scalability of CAMP. From ramasv@CS.Cornell.EDU Thu Oct 4 12:31:16 2001 Return-Path: Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94GVGo23990 for ; Thu, 4 Oct 2001 12:31:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: cs615 PAPER 23 Date: Thu, 4 Oct 2001 12:31:16 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301E7F276@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cs615 PAPER 23 Thread-Index: AcFM8f04T9cifNQjTPS1godpkNik/g== From: "Venu Ramasubramanian" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id f94GVGo23990 The Core Assisted Mesh Protocol This paper presents a multicast protocol called CAMP that maintains a mesh (multi-connected) rather than a tree to disseminate packets to memebers of a multicast group. The protocol involves identifying a small set of group memebers called core members to assist in member joining operation. The protocol does mesh repair due to link breakages in a kind of proactive manner by making sure every receiver has shortest reverse paths to each source of the multicast group. The joining operation involves talking to a core node (a path to which is provided by the unicast routing protocol.). If no core nodes can be found an broadcast route mechanism with ERS is used to join the multicast mesh. A node could join the mesh as a sender (simplex) or a sender/receiver (duplex.) CAMP involves periodic heartbeat messages and push joins to ensure that at all times each receiver has reverse paths to the source. This ensures that every message sent by a source follows the shortest path to all the receivers. The mesh itself is defined by the set of these shortest reverse paths. Push join messages are sent in order to create reverse paths. The advantages of this protocol include having a mesh based multicast structure that can withstand multiple simultaneous link breakages. Also maintaining shortest paths between senders and receivers ensures that the multicast messages reach the destinaiton faster. The disadvantages of this protocol include having to disseminate core membership information to all the nodes at all the time, added control overhead due to maintanance of multiple paths between several sources and receivers. The protocol also seems to rely on an accurate proactive distance vector based unicast routing protocol. Such unicast routing protocols are known to be very inefficient. The scalability of the protocol is still a big question. Simulations are performed with a single topology and the graphs remain difficult to interpret. From andre@CS.Cornell.EDU Thu Oct 4 12:46:31 2001 Return-Path: Received: from sundown.cs.cornell.edu (sundown.cs.cornell.edu [128.84.96.20]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94GkUo25638; Thu, 4 Oct 2001 12:46:30 -0400 (EDT) Received: from khaffy (mail@cs-annex-1-09.cs.cornell.edu [128.84.96.39]) by sundown.cs.cornell.edu (8.11.3/8.11.3/R-3.6) with ESMTP id f94GkSi15031; Thu, 4 Oct 2001 12:46:29 -0400 (EDT) Received: from andre by khaffy with local (Exim 3.31 #1 (Debian)) id 15p636-0000Ez-00; Thu, 04 Oct 2001 12:48:16 +0200 Date: Thu, 4 Oct 2001 12:48:16 +0200 From: =?iso-8859-1?Q?Andr=E9?= Allavena To: egs@CS.Cornell.EDU Subject: 615 PAPER 23 Message-ID: <20011004124816.A692@khaffy> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.20i Sender: =?iso-8859-1?Q?Andr=E9_Allavena?= The Core Assisted Mesh Protocol. This is a protocol for multicast, on top of a unicast protocol. They say they try to do better than a tree based multicast algorithm, but don't really say how such an algorithm would work. Their difference is to allow node to retransmit a multicast packet even if it not received by the usual parent. The idea is to have many paths in the graph (a mesh), not only one as in a tree. But I really don't understand how they figure out when and how to use them. (What to do when a link fails? If it is only to rely on the underlying unicast protocol to find a new route to the code, the mesh is useless. This multicast protocol assumes that every node know a route to every other node, whereas many unicast protocols are now on demand protocol. This can more or less be overcome, unless maybe when the network partitions (regular attemps to reconnect to a core). Note that in their scheme, if the net partitions, and all the cores on one side change, then they'll never be able to merge again. There could be a lot a overhead saving whith incorporating the unicast and the mutlicast protocols in on demand routing. -- André Allavena (local) 154 A Valentine Place École Centrale Paris (France) Ithaca NY 14850 USA Cornell University (NY) (permanent) 879 Route de Beausoleil PhD in Computer Science 06320 La Turbie FRANCE From samar@ece.cornell.edu Thu Oct 4 14:23:18 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94INHo07862 for ; Thu, 4 Oct 2001 14:23:17 -0400 (EDT) Received: from plato (plato.ece.cornell.edu [128.84.239.28]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id f94IO8R19530 for ; Thu, 4 Oct 2001 14:24:08 -0400 Date: Thu, 4 Oct 2001 14:25:54 -0400 (EDT) From: Prince Samar X-X-Sender: To: Emin Gun Sirer Subject: 615 PAPER 23 In-Reply-To: <200110041810.f94IAG602148@hoho.cs.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 23) The Core-Assisted Mesh Protocol The Core-Assisted Mesh Protocol or CAMP is a multicast algorithm for dynamic Ad hoc networks. CAMP uses core-based meshes which have more connectivity than a multicast tree and thus can be more stable and well connected even in times of high mobility. CAMP guarantees that every receiver of a multicast group has a reverse shortest path to each source of the multicast group in a finite time. CAMP needs a unicast routing protocol running in the network to perform its multicasting. A node may choose to join a group in either simplex mode for forwarding packets received from specific neighbors to the group, or duplex mode such that it will forward any multicast packets for the group. When the status of a node is changed, it broadcasts a Multicast Routing Update (MRU) with group membership and routing update. The main contribution of CAMP is the use of the cores and a mesh to accomplish the multicasting. Failure of some nodes or links would probably not affect the multicasting due to the mesh structure (as opposed to the tree structure). The simulation comparison do not seem adequate. CAMP has been compared to a tree based protocol and under the assumptions taken (eg mobility pattern) CAMP seems to work better. Comparing CAMP to other core-based protocols would have been more insightful. From haom@csl.cornell.edu Thu Oct 4 14:48:53 2001 Return-Path: Received: from mauchly.csl.cornell.edu (mauchly.csl.cornell.edu [132.236.71.68]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f94Imqo10940 for ; Thu, 4 Oct 2001 14:48:52 -0400 (EDT) Received: from localhost (haom@localhost) by mauchly.csl.cornell.edu (8.9.3/8.9.2) with ESMTP id OAA83747 for ; Thu, 4 Oct 2001 14:48:47 -0400 (EDT) (envelope-from haom@mauchly.csl.cornell.edu) X-Authentication-Warning: mauchly.csl.cornell.edu: haom owned process doing -bs Date: Thu, 4 Oct 2001 14:48:47 -0400 (EDT) From: Ming Hao To: Emin Gun Sirer Subject: 615 PAPER 23 In-Reply-To: <200110041810.f94IAG602148@hoho.cs.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII AMRIS: A Multicast Protocol for Ad hoc Wireless Networks by C.W. Wu, Y.C. Tay the paper propsed actually a similar multicast algorithm to the multicast AODV. the head of shared tree is the sender. the shared delivery tree is set up by 2 phases: 1. initialization: sends sends out a NEW_SESSION message which is broadcast through the netework and each node computes a interger number based the distance between itself and sender. interested node joins the tree by sending a REQ to its parent, if the parent is a member already, a ACK will sends back, otherwise, the parent will forwards the REQ till the sender. 2. if link failure happens, the down stream node will try to fix it by selecting one of its parent to join the tree. if it can rejoin the tree in this way, it will broadcast the request with some TTL in order to avoid flooding. some simulations results are showed about the relationship between end-to-end delay, delivery ration,message overhead with respect to node mobility and beacon interval time. summary: the idea is simple and clean. but it doesnot explore all teh aspects of mulricast problems. such as multiple senders, moving of the sender, partitioned tree. it also has the problems that single shared tree suffers such as sensitiveness to link failure, or ineffecient multicasting. -ming Ming Hao PH.D Candidate, EE mh97@cornell.edu Cornell University Office: (607) 255-0817 Ithaca, NY 14853 http://www.ee.cornell.edu/~haom/ From jcb35@cornell.edu Tue Oct 16 11:59:31 2001 Return-Path: Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id f9GFxVo23864 for ; Tue, 16 Oct 2001 11:59:31 -0400 (EDT) Received: from localhost.localdomain (syr-66-66-30-147.twcny.rr.com [66.66.30.147]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA19643 for ; Tue, 16 Oct 2001 11:59:25 -0400 (EDT) Received: from localhost (john@localhost) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f9GG0VS04379 for ; Tue, 16 Oct 2001 12:00:32 -0400 Date: Tue, 16 Oct 2001 12:00:31 -0400 (EDT) From: "John C. Bicket" To: egs@CS.Cornell.EDU Subject: 615 PAPER 23 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This paper discussed the Core-Assisted Mesh Protocol (camp), which supplies a multicast function for ad-hoc networks. Instead of using a tree-based method to form multicast routes, camp uses a "mesh" which is a subset of the nodes that provide at least one path from each source to each receiver in a multicast group. By using the concept of a mesh, camp claims that topology changes are less likely to disrupt the flow of multicast data since a member router of a multicast mesh has redundant paths to any other router in the mesh - this also accounts for shorter paths than tree protocols, since the mesh shouldn't be as deep as the tree. Camp also has mechanisms for nodes joining a multicast group in a "simplex" mode that allows it to send and not receive. This attempts to contain data traffic closer to the receiver in the mesh. Also, camp uses "heartbeat" messages to ensure the mesh contains all the reverse shortest paths. This is done by each node keeping track of the unicast shortest paths it receives and if that path gets out of sync with the mesh route, it will send an message to that node while forcing all the nodes along the path to join the mesh. The paper provides simulation results against wtp (a wireless tree based protocol) and ODMRP, another meshing multicast protocol. comments: I'm not clear why they don't include the data for average packet delays in the paper; they node that the average packet delays for the routers running wtp is based on much fewer data packets. It is clear that camp performs better than odmrp because odmrp uses a sender-initiated for mesh joining (which could result in flooding) rather than camp's receiver-initiated approach. I would have liked to see more complete comparisons between tree based multicast routing - I would think that these multicast meshes could, in the worst case, could have many more nodes than necessary and use more packets per multicast send than a tree based protocol.