IP Multicast Extensions for Mobile Internetworking
Arup ACHARYA,Ajay BAKRE and B.R.BADRINATH
Department of Computer Science,Rutgers University,New Brunswick,NJ08903,USA
{acharya/bakre/badri}@https://www.doczj.com/doc/d99625976.html,}
This paper deals with multicasting in an internetwork with mobile hosts,particularly with regard to Mobile-IP[11]and Distance V ector Multicast Routing(DVMRP)[10,9]protocols.When the source of a multicast datagram is a mobile host (MH),the datagram may not reach all group members to which the datagram is addressed,including other mobile hosts.When the source is a static host and the multicast group includes mobile hosts,a mobile group member may receive datagrams in one cell but not in another.Further,when a MH enters a cell which contains no other member of the same group,the MH will experience a delay before it starts receiving datagrams addressed to that group.Mobility between campuses,which result in a MH acquiring an additional unicast address,also has an effect on multicast routing.We propose enhancements to DVMRP executed at the Mobility Support Routers(MSR)that ensure correct forwarding of multicast datagrams to and from mobile hosts.Our solutions do not require any change at hosts and routers unaware of mobility,i.e.the modi?cations are limited to MSRs and MHs.We also describe an implementation incorporating a subset of our https://www.doczj.com/doc/d99625976.html,stly,we show that alternate styles of multicasting or mobile networking,viz.link-state(MOSPF[14])and IETF proposal[1],will face similar problems and our proposed solutions are still valid in their context.
1Introduction
This paper explores the interaction between IP-multicasting and host mobility.Multicasting at the net-work layer is an ef?cient mechanism for delivering copies of the same datagram to multiple destinations.Presently, multicast routing in the Internet is primarily implemented using the Distance V ector Multicast Routing Protocol (DVMRP)[9,10]and forms the basis of MBONE.MO-SPF[14]is another multicasting protocol based on link-state unicast routing.An active area of study is Protocol Independent Multicasting(PIM)[8]which aims to re-move dependence of multicast routing on underlying uni-cast routing protocols.We will discuss IP-multicasting in this paper primarily in the context of DVMRP given its popularity and a freely available implementation,viz. mrouted[16].
The emergence of portable computers coupled with wireless networking has motivated the need for protocols [4,5,11,13,15,17]that allow mobile hosts to interoper-ate within existing networks.Out of the proposed proto-cols,arguably the most widely used scheme is Mobile-IP from Columbia University[11,12]and the only one for which,a publicly available implementation exists.This scheme has also been used as a testbed for studying the impact of mobility on transport-layer protocols[3,6]. This paper will therefore focus on extending multicast protocols to mobile hosts assuming the addressing and (unicast)routing mechanisms of Columbia’s Mobile-IP.
Multicasting in an internetwork with mobile hosts leads to the following problems:
?when the source of a multicast datagram is a mobile host,then a copy of the datagram may not reach all hosts(static or mobile)that are members of the multicast group
?a MH may experience a delay in receiving multicast datagrams when it enters a cell that has no other group member located in the same cell
?datagrams multicast from a static source may not reach some cells depending on the TTL value used with the multicast datagram:thus,the same mobile host(MH) may receive datagrams from that source in some cells but not in others.
The root cause of these problems is that while DVMRP implicitly assumes that all hosts(interfaces)with a com-mon subnet address have link-layer connectivity,i.e.con-nected by a physical wire,this assumption is no longer true in the presence of mobile hosts.
Our solution to the above problem consists of“heal-ing the partition”amongst the MSRs using a pre-de?ned multicast tunnel.This multicast tunnel is used to simulate the necessary link-layer connectivity amongst the MSRs. This abstraction,along with appropriate modi?cations to the Internet Group Membership Protocol(IGMP)[7],is adequate to ensure correct routing of multicast datagrams from mobile hosts to all group members,and also to en-sure that a MH experiences no delay in receiving data-
grams regardless of its mobility within the campus.This solution has been implemented for DVMRP/mrouted ex-ecuted by the MSRs.We also propose enhancements to ensure all or none semantics,i.e.a multicast datagram is either received in all cells within a campus or in none. Lastly,we extend our solution to handle inter-campus moves.
Though our discussion of multicasting to/from mo-bile hosts is based on DVMRP and Mobile-IP,the prob-lems and our proposed solution therein are also applicable to other styles of multicasting,viz.MOSPF or PIM,and mobile networking,viz.the IETF proposal[1].
The problem of reliably delivering multicast mes-sages to mobile hosts at the application-layer is discussed in[2].This work is not concerned with routing multicast messages to mobile hosts,but instead uses application-layer protocols to determine the set of MSRs that support members of a multicast group and to ensure that a mobile host does not receive multiple copies of the same mes-sage from different cells.Besides this,we are not aware of any related work in this area,speci?cally on routing multicast messages to/from mobile hosts.
The rest of the paper is organized as follows.In the next section,we brie?y describe the aspects of IP-Multicasting/DVMRP and Mobile-IP that affect each other.Section3presents the problems associated with multicasting to/from mobile hosts.Sections4and5 present our solution to these problems and the imple-mentation thereof.We then discuss the special consid-erations for multicasting in wireless cells,given the low-bandwidth of wireless medium and the possibility of overlapping cells.Next,we evaluate the applicability of our approach in the context of MOSPF,PIM and the IETF proposal for host mobility.
2System Model
2.1Mobile-IP
The static network is augmented with Mobility Sup-port Routers,each of which functions as a access point for mobile hosts to connect to the rest of the network. The coverage area under a MSR is called a cell,and communication within a cell is via a wireless medium. Link-layer multicast is supported within each cell.
A mobile host is assigned a home network address that remains unchanged regardless of its location in the internetwork.A single virtual subnet is reserved for assigning addresses exclusively to mobile hosts1and the set of MSRs responsible for supporting such a virtual 1and possibly,wireless interfaces of MSRs subnet is de?ned to be a campus2.When a MH visits a foreign campus,it is assigned a transient nonce address from the mobile subnet of the foreign campus.A mobile host in a foreign campus is thus associated with two addresses,its home address and the nonce address.It has a choice of using either address in the source?eld in the packets that it sends while located in the foreign campus; Mobile-IP tunnels datagrams that contain the MH’s home address in the source?eld,to the MH’s home campus.
Within a campus,each MSR individually advertises reachability to the mobile subnet via the intra-domain routing protocol in use.As a result,each non-MSR router within a campus points to some MSR as the shortest path to the mobile subnet.However,the shortest path from two non-MSR routers to the mobile-subnet will not necessarily point to the same MSR.So,when a MH moves between two cells,the path from the MH to an intermediate router will not necessarily be the same as the reverse path from the router to the MH,i.e.the forward and reverse paths are asymmetric.Additionally,since the wireless(mobile)interface of each MSR is directly attached to the mobile subnet,the route entry for the mobile subnet at a MSR,as seen by a protocol external to Mobile-IP,points to the wireless interface.
Consider a campus network shown in https://www.doczj.com/doc/d99625976.html,4 is a mobile subnet split amongst three cells supported by MSR1,MSR2and MSR3.Routers R1and R2point to MSR1and MSR2as their respective shortest paths to Net4.At MSR1,its wireless interface is directly connected to Net4,and therefore its shortest path to Net4 points to its wireless interface.Similarly,for MSR2and MSR3,the shortest path to Net4points to their respective wireless interfaces.
The reader is referred to[11,12]for detailed expla-nation of this scheme.
Fig.1An example of mobile internetworking
2It is also possible to support multiple virtual subnets within the same campus.
2.2IP-Multicast
In the IP-multicast model,a common multicast ad-dress is assigned to all hosts that wish to receive data-grams addressed to the group.Senders use this address in the destination?eld of multicast datagrams,while the source?eld contains the address of the sender.In distance-vector routing,the source address of a multicast datagram plays a crucial role at an intermediate router:if the datagram did not arrive on the shortest reverse path (from the router)to the source,the datagram is not routed further and is silently discarded.Typically,this decision is based not on the host address of the source,but rather the subnet address to which the source belongs.
In conjunction with link thresholds,the TTL value of a multicast datagram determines how far the datagram propagates from the source.The TTL value of a multicast datagram is decremented at each router it transits;after decrementing the TTL value,a copy of the datagram is propagated to a child link(determined by the routing portion of the multicast protocol)only if the TTL value is greater than the link threshold at the router.
3IP-Multicast in the presence
of Mobile Hosts
The basic con?ict in combining IP-multicast with Mobile-IP is as follows:Mobile-IP splits the virtual mo-bile subnet across multiple cells supported by MSRs with link-layer connectivity only between a MSR and MHs lo-cal to its cell.IP-multicast,on the other hand,implicitly assumes that if there are multiple routers connected to a subnet,then a link-layer transmission from any host on the subnet reaches all routers and hosts on that subnet. This implicit assumption breaks in the presence of a logi-cal(mobile)subnet physically partitioned amongst multi-ple MSRs.A multicast transmission from a MH reaches only its local MSR and other MSRs do not receive the link-layer transmission directly from the MH(since the MH is not local to their cells)3.Below,we describe how this affects multicast routing to/from mobile hosts.
3.1MH as a multicast source
The?rst problem in extending IP-multicast to handle mobile hosts arises when the source of a multicast is a mobile host.Assume that the static hosts H1and H2, and mobile hosts MH1,MH2and MH3have joined a multicast group G.At the router R1,the shortest path to the mobile subnet points to MSR1.So when MH h2 under MSR2sends a multicast datagram to G,MSR2will forward a copy on Net5.R2will then forward it onto 3The case of overlapped cells is discussed https://www.doczj.com/doc/d99625976.html,2,since the datagram arrives on the correct interface at R2.However,R1will not forward a copy(received on its Net2interface)since it did not arrive on its reverse forward path to the source(subnet),https://www.doczj.com/doc/d99625976.html,4.Note also that R1cannot receive a copy on its Net3interface.As a result,the static host H1and mobile host MH1will not receive a copy.
The essence of the problem is that R1points to its Net3interface as the correct path to the mobile subnet, but receives a copy of a datagram on another interface (N2).An intermediate router forwards a multicast data-gram only if it arrives on the shortest(reverse)path to the source.With a partitioned subnet,an intermediate router is no longer guaranteed to receive a multicast datagram on its shortest path to the source subnet.
The above problem is also observed at any MSR which is routed a copy of a multicast datagram from the wired network,but is not local to the MH sending the multicast.Such an MSR will discard the datagram,be-cause the datagram is received on an interface other than its wireless(mobile)interface.For example,MSR3will discard the datagram after receiving it on its Net5inter-face;the datagram is thus not forwarded to its wireless cell and therefore,MH3does not receive a copy.
3.2MH sending from a foreign campus
In a foreign campus,an MH can potentially use either its home address or the nonce address in the source ?eld of multicast datagrams that it transmits.However, routers in the foreign campus will very likely discard a datagram with the MH’s home address as the source, since it will arrive at those routers on the non-shortest path to the MH’s home subnet.This leaves the MH with only one choice,https://www.doczj.com/doc/d99625976.html,e its nonce address as the source. This has two disadvantages:1)for applications that rely on source addresses to identify streams from different senders,e.g.video/teleconferencing,recipients cannot infer that although two successive multicast datagrams contain different source addresses,they originated from the same mobile sender which moved across campuses while transmitting the stream,and2)if there are no other senders in the same cell,then intermediate routers in the foreign campus may need to set-up new forwarding paths4 for this source.(This is over and above the problems mentioned when MH is a multicast source.)
3.3MH as a multicast recipient
When an MH that belongs to G moves to a cell with no other member,the local MSR discovers G’s presence 4In DVMRP,this amounts to adding(source,group)entries to the multicast forwarding cache at the routers,while in MOSPF,intermedi-ate routers may need to recompute the source-rooted spanning trees.
only in the next IGMP membership query cycle(join delay).The local MSR will subsequently need to graft a path to multicast trees for G with respect to all active sources(graft delay).Thus,the mobile host will not receive datagrams sent to G(from non-local sources)for the sum of join and graft delays,even though it had already joined G(in a previous cell).
As an example,let MH2and MH3,but not MH1be members of group G,and also that there are no members on Net2.If MH2moves to MSR3’s cell,it will incur no delay in receiving datagrams addressed to G(say,from source H2).However,if it moves to MSR1’s cell,there will be a join delay before MSR1discovers presence of G in its cell,i.e.until MSR1transmits a membership query and then receives a membership report(G)from MH2.MH2will incur a further delay before it starts to receive datagrams from a source such as H2,viz.till R1 receives a graft(H2,G)message from MSR1.
Due to a combination of1)the TTL value used by the source to send a datagram,and2)thresholds of links in the multicast tree,it is also possible that two MHs, though part of the same subnet,are at different“dis-tances”from a common source.For example,consider host H1multicasting to a group G with a TTL value3 and assume that all link thresholds have a value1.In this case,MH1receives the multicast via R1and MSR1. But,the multicast does not reach MH2and MH3,since the TTL value used by the source H1is not suf?cient for it to be forwarded by MSR2and MSR3in their respec-tive cells.In general,the TTL value used by the source and the threshold values on the transit interfaces,deter-mine which cells receive a copy of the multicast.While it can be argued that the problem with inadequate TTL values may occur for static group members as well,the difference here is that a mobile host can switch cells and may receive a copy of the datagram in some cells and not receive it in others,i.e.in contrast to a static recipient,a mobile host observes different semantics with regard to multicast reception depending on its mobility.
4Our Approach
The crux of the problem in multicasting to/from mo-bile hosts is that though all MHs and wireless interfaces of MSRs within a campus share a common subnet ad-dress,link-layer connectivity amongst MHs and a MSR is present only within a single cell.Thus,for correct routing of multicast datagrams,we need to provide an abstraction of link-layer connectivity amongst all MSRs and MHs within a campus,i.e.a multicast transmission from any MH should reach all MHs regardless of their location within the campus,and wireless interfaces of all MSRs.This abstraction should thus simulate a physi-cal link amongst all hosts and MSRs whose addresses belong to the mobile subnet.
4.1Multicast Tunnel for MSRs
Both Mobile IP and IP multicast use unicast tun-nels to encapsulate and send IP datagrams over the Inter-net.This is necessary to hide the encapsulated datagram from the intermediate(and possibly non-cooperating)IP routers so that specialized routing policies can be imple-mented.
We extend the concept of unicast tunnels to form a multicast tunnel or MTUNNEL that links all the MSRs within a campus.The MTUNNEL provides an abstrac-tion of link layer connectivity among the MSRs.The MTUNNEL uses a reserved multicast address5for the all-MSR group and is used to forward multicast datagrams and IGMP messages from one MSR to all the other MSRs using IP within IP(protocol4)encapsulation.The encap-sulating IP header for a packet sent on the MTUNNEL contains the all-MSR address in its destination?eld and the forwarding MSR in its source?eld.
The need to communicate with MSRs as a group also arises in Mobile-IP[11,12]when a MSR receives a packet addressed to a MH not local to its cell.The MSR must determine the MH’s current location within the cam-pus before the packet can be forwarded to the appropri-ate cell.Instead of multiple unicasts,the MTUNNEL can be used for this purpose as well.Below,we show how the MTUNNEL ensures correct routing of multicast datagrams to/from mobile hosts.
4.2MH as a multicast source
It was pointed out in the previous section that when a mobile host sends a multicast IP datagram,a copy of the datagram may not reach all group members.To elim-inate this problem,when a datagram is multicast from a mobile host,its local MSR encapsulates the datagram and sends it via the MTUNNEL to all MSRs within the campus in addition to forwarding the original datagram to its wireline interfaces as dictated by DVMRP.When other MSRs receive an encapsulated datagram from the MTUNNEL,they decapsulate and forward this datagram to their respective wireless interfaces and also,as dic-tated by DVMRP,to their wireline interfaces.This has the same effect as a mobile host sending a multicast trans-mission on a physical wire connecting all mobile hosts and MSRs:each MSR would receive the transmission on the reverse forward path to the mobile subnet,namely 5The reserved address for the all-MSR group can be assigned from the set of administrative addresses(239.x.x.x)and can be appropriately scoped at the boundary routers in a campus so that the datagrams addressed to this group do not propagate outside the campus.
its directly connected wireless interface,and therefore, forward it on its other interfaces according to DVMRP.
Consider the example network shown in?g.1.As-sume that H1and MH3have joined a multicast group G.
A datagram sent from MH2to group G is received by MSR2on its wireless interface.MSR2encapsulates and sends this datagram over the MTUNNEL to reach MSR3 and MSR1.MSR3decapsulates and forwards the data-gram on its wireless interface(thereby reaching MH3). Also,MSR1decapsulates and forwards the datagram on its wireline interface,namely Net3.R1now correctly receives the datagram on its shortest(reverse)path to the mobile subnet,and therefore forwards it to Net1thereby reaching H1.
4.3MH sending from a foreign campus
The multicast tunnel between MSRs within a cam-pus ensures that no matter where a MH is located within a campus,multicast datagrams transmitted by it will be correctly routed to the rest of the internetwork.However, consider the case when a MH moves to a foreign campus. If it uses its foreign address(which belongs to the mobile subnet of the foreign campus)as the source address,the multicast datagram will be tunneled to all MSRs within that campus and correctly forwarded thereon.As pointed out earlier,it may be preferable to use the MH’s home address as the source for some applications.To handle this case,we propose that the datagram be tunneled from the MH to any of its MSRs in its home campus using standard unicast routing.The home MSR at the tunnel endpoint processes the(decapsulated)multicast datagram as if it originated from its local wireless cell.
The two enhancements proposed above ensure that when the source of a multicast datagram is a mobile host, it will be correctly routed to static and mobile receivers, regardless of inter-campus or intra-campus moves.
4.4MH as a multicast recipient
When a MH that moves to a cell where it is the sole member,it will incur a delay before it begins to receive datagrams sent to the group.We solve this problem by modifying the Internet Group Membership Protocol [7,10](IGMP)for the mobile subnet as follows:each MSR sends a separate membership query to its local cell, but the group-speci?c membership reports received in response from local MHs are sent to all other MSRs via the multicast tunnel.Thus,even if none of its local MHs belong to a group G,a MSR will not prune itself from the multicast tree for G(for all sources)as long as any MH within the campus has joined G.As a result,a MH that has joined G,will receive datagrams addressed to G as soon as it enters any cell within the campus.On the?ip side,this implies a MSR will forward datagrams addressed to G within its cell even if there are no local MHs that are members of G.This drawback is addressed in section6.1.
In the network shown in?g.1,consider the case where MH2and MH3are members of a group G,but not MH1.With IGMP modi?ed as above,MSR1will not prune itself from the multicast tree for G for all sources, as long as either MH2or MH3is a member of G.So, when MH2enters its cell,there will be no delay incurred by MH2in receiving datagrams addressed to G.
Depending on the initial TTL value of a multicast datagram and link thresholds,a mobile receiver may re-ceive datagrams in some cells but not in others.The solution to this problem is to provide a all-or-none se-mantics for mobile recipients within a campus,i.e.either a multicast datagram should be delivered in all cells or in no cell within a campus6.Such a solution is more dif?cult to implement since it requires MSRs to com-pute a“dominant router”7for the mobile subnet for each source.The multicast tunnel can once again be used as follows:a MSR on receiving a multicast datagram on its wireline interface addressed to a group G,forwards it on the multicast tunnel if:1)if any MH has joined G
2)it is the dominant router for the mobile subnet,and
3)the TTL value of the datagram exceeds the threshold of the wireless interface.Each MSR at the tunnel end-points then forwards it only to its respective wireless cell (i.e.,they do not forward it to their wireline interfaces using DVMRP)8.The dominant router can be computed by each MSR sending its routes to all other MSRs on the multicast tunnel.However,these routes should be used only to compute the dominant router for each source,and not to update routes at the individual MSRs9,e.g.by as-sociating a link metric of in?nity with their respective virtual interfaces for the multicast tunnel.Secondly,all MSRs must now use a common threshold value on their wireless links;otherwise,even though we ensure that a 6This is motivated by multicast delivery for static hosts:a multicast transmission either reaches all(static)group members with a common subnet address(and therefore on the same wire/link),or it reaches no one on the link.Since all mobile hosts within a campus share the same subnet address,the intent is to provide an abstraction of a common “wire”connecting all mobile hosts thereby,damping out the effect of a receiver’s varying location on multicast delivery.An alternative viewpoint is that host mobility should be made apparent to senders, e.g.a sender may only wish to contact“nearby”mobile receivers by controlling TTL values of multicast packets.
7When multiple routers are connected to the same link,only one of them,the dominant router,should forward a copy of a datagram onto that link.
8Note that there is a difference in how tunnel endpoints forward multicast datagrams,depending on whether the source?eld of the datagram speci?es a host from the mobile subnet or some other subnet. 9Otherwise,the multicast tunnel will provide a“short circuit”path between MSRs for multicast datagrams addressed to groups which have no members on the mobile subnet
datagram from a static host is forwarded to all MSRs,in-dividual MSRs may forgo forwarding it on their wireless interface because the interface’s threshold may exceed the TTL value,thereby thwarting all-or-none semantics. Overall,providing all-or-none semantics did not seem to justify the additional control traf?c over the multicast tun-nel and therefore was not included in our implementation described in the next section.
When an MH makes an inter-campus move,it will incur a delay in receiving datagrams in the foreign cam-pus that are addressed to G,only if no MHs in any cell in the foreign campus are members of G.This is because the MTUNNEL within the foreign campus ensures delivery of datagrams addressed to G anywhere within that cam-pus.However,if there are no existing members in any cell,the visiting MH will incur a delay only in the?rst cell it visits in the foreign campus,and subsequent moves in the same campus will not affect receiving datagrams.
In section6(Wireless Considerations),we extend our solution to handle the following cases:1)avoiding reception of multiple multicast packets in case of over-lapping cells,and2)delivering multicast packets for a group G to only those cells in a campus that have mem-bers of G(instead of automatically delivering a copy in each cell within a campus regardless of group presence). 5Implementation
We have implemented our solution for IP multicast in a mobile wireless environment based on Columbia Mobile IP[11,12].We begin with a brief description of IP multicast release3.3which is followed by the modi?cations needed in the IP multicast routing code for our solution.
5.1IP Multicast Release3.3
Release3.3of IP multicast extensions for BSD de-rived Unix systems consists of multicast routing support in the Unix kernel and a user level mrouted daemon.The mrouted daemon maintains information about all multi-cast capable physical interfaces and point to point tunnels in a virtual interface(VIF)structure.It regularly sends probe messages on each VIF to determine neighboring multicast routers.Multiple multicast routers connected to the same physical link cooperate by exchanging routing information about reachable subnets.They also elect one multicast router to be the querier for the common physi-cal link.The mrouted daemon periodically sends IGMP membership queries on each attached subnet for which it is the querier.Similarly,exactly one multicast router is responsible for forwarding multicast packets originat-ing from a given external source on a physical link with multiple routers and is called the dominant router for that link with respect to the source.
Unicast tunnels are supported in release3.3to inter-connect islands of multicast capable networks.Multicast packets forwarded on such tunnels are encapsulated using IP within IP protocol(protocol4).DVMRP messages are exchanged between routers at the two ends of the tunnel. The encapsulation(decapsulation)of data packets sent (received)on a unicast tunnel is performed in the kernel forwarding code which treats the tunnel as just another multicast capable interface.
The mrouted daemon and the multicast forwarding code in the kernel cooperate as follows.None of the multicast datagrams received from any physical interface or tunnel are sent to the user level by the kernel10.All the received datagrams are forwarded on outgoing mul-ticast capable interfaces and tunnels after consulting the multicast forwarding cache(MFC)entry for the
Below we describe the modi?cations needed to the multicast routing code in the Unix kernel and to the mrouted daemon running at each MSR to support the MTUNNEL and IP multicast forwarding rules for the mobile subnet.
5.2Modi?cations to mrouted
The mrouted daemon con?gures physical interfaces which are multicast capable and unicast tunnels as spec-i?ed in a con?guration?le.To facilitate routing poli-cies for mobile hosts and for the special all-MSR mul-ticast group(also known as MTUNNEL hereafter),we extended mrouted to accept the following additional di-rectives in its con?guration?le:
1.A keyword mobile can appear in the phyint directive
which marks the named physical interface as a mobile wireless interface.Only one such interface is allowed currently.
2.A new directive is accepted by mrouted for the
MTUNNEL in the con?guration?le as follows-
mtunnel
where
—
the multicast packets addressed to the MTUNNEL.
This is also the interface on which the MSR joins
the MTUNNEL multicast group so it can receive
the packets sent on MTUNNEL by other MSRs.
Note that the existence of one such interface does
not prevent the MSR from receiving packets ad-
dressed to the MTUNNEL from other interfaces
nor does it inhibit forwarding of such packets on
other interfaces.
—
the MSRs in the mobile subnet or campus.
—ttl
which is useful in limiting the scope of the mul-
ticast address used for MTUNNEL.The default
value used is32.
—the other keywords serve the same function as in phyint and tunnel directives although currently
they are not utilized in any way.
Currently only one mtunnel directive can appear in the mrouted con?guration?le,and it should appear after all the phyint directives.
We added a?ag VIFF_MOBILE to the VIF structure in mrouted(and also in the kernel multicast code),to mark an interface as mobile.In the VIF structure,the MTUNNEL appears as an encapsulating tunnel with the VIFF_MOBILE?ag set and a multicast address as the remote end point as opposed to a unicast address in case of a unicast encapsulating tunnel.On seeing the mtunnel directive,mrouted makes sure that a physical interface has previously been marked mobile(with a phyint directive)and takes the following actions—a)It establishes an encapsulating multicast tunnel
(MTUNNEL)with the given interface address(MSR ?xed address)as the local endpoint and the
b)It disables DVMRP probes and route updates on the
mobile interface and on the MTUNNEL11.This is also helpful in an overlapped cell con?guration as described in section6.
c)It directs the kernel multicast routing code to set up
forwarding for the mobile interface and MTUNNEL as described in the next subsection.
There is an implicit association between the MTUN-NEL and the mobile physical interface which together provide an abstraction of the mobile virtual subnet.After the initial setup as described above,the mrouted daemon performs the following additional functions with regard 11A more complete solution with all-or-none semantics will require DVMRP messages to be exchanged between MSRs.to sending membership queries and collecting member-ship reports for the mobile interface:
a)If an IGMP host membership report is received from
an interface that is marked mobile,this report is en-capsulated and sent over the MTUNNEL in addition to taking any action locally as dictated by IGMP[7,9].
An encapsulated report is identi?ed a nonzero value in the IGMP code?eld(which is unused in the current layout of IGMP membership report)so that the receiv-ing mrouted daemon can distinguish it from a regular IGMP report received from a physical interface.
b)If an IGMP host membership report is received
from the MTUNNEL(i.e.from another MSR),the mrouted daemon takes any necessary action as dic-tated by IGMP pretending as if the report arrived from the physical interface marked mobile.Such a report is not sent back on the MTUNNEL.
With a con?guration of MSRs in a campus as de-scribed above,if an MH in some wireless cell joins a particular multicast group,the corresponding member-ship report is received by all the MSRs.This causes all MSRs to become part of the multicast tree for that par-ticular group with respect to any active source.It also causes the datagrams addressed to this group to be mul-ticast in all the wireless cells12and thus the MH who has joined the multicast group can potentially roam in any cell within the campus and can still keep receiving the multicast packets addressed to the group without incur-ring any join or graft delay.
5.3Modi?cations to Multicast Routing in Unix
In IP Multicast release3.3,an entry for a given
a)Any datagram that arrives on the mobile physical in-
terface of an MSR with a multicast address that is not local-only(local addresses fall in the range224.0.0.1 to224.0.0.255)is encapsulated and forwarded on the 12Possible optimizations are described in section6.1.
MTUNNEL only if the source is a MH local to the MSR13.
b)Any encapsulated datagram arriving on the MTUN-
NEL is decapsulated and put back on the IP interrupt queue with the interface pointer(ifp)pointing to a pseudo interface structure similar to the one used for unicast tunnels.An encapsulated IGMP membership report arriving on the MTUNNEL is sent to the user level mrouted daemon after decapsulation by the nor-mal multicast handling code.To mrouted it looks like a regular membership report but with a non-zero value in the IGMP code?eld indicating that the report arrived from a remote MH via the MTUNNEL.
c)When a datagram(which is not an IGMP membership
report)decapsulated in b)above reaches the IP multi-cast forwarding code(matching the interface pointer with the VIF table should indicate that the datagram arrived via the MTUNNEL),a copy of the datagram is forwarded on the physical interface marked mobile
i.e.in the local wireless cell.In addition,the inter-
face pointer is changed to point to the mobile physical interface so that the remaining multicast forwarding code treats the datagram as if it originated from the mobile subnet(it actually originated from the part of mobile subnet that is managed by another MSR). d)Datagrams arriving at both the mobile interface and
the MTUNNEL are forwarded according to DVMRP on other(?xed)interfaces after consulting the MFC for the
e)When a datagram is encapsulated and forwarded on
the MTUNNEL,its TTL value is not decremented.
The above rules thus give us the following semantics for different TTL values when the source of a multicast is an MH:
i)Datagrams with a TTL value of1and those addressed
to local-only addresses reach only the cell containing the MH.
ii)Datagrams with a TTL value of2will reach all the wireless cells in a campus(i.e.all the MHs on the mobile subnet that are currently within the campus), and all the?xed hosts that are one hop away from any of the MSRs(unless of course some?xed interface at one of the MSRs has a threshold TTL value greater than1).Note that all MHs within campus semantics are provided for a TTL value of2regardless of the TTL threshold values on the mobile interfaces at individual MSRs,if the source is an MH.Such threshold values however,will apply to datagrams that originate outside the mobile subnet.
13Refer to section6.2for justi?cation of this check.iii)Datagrams with a TTL value of n>2will reach all the MHs within the campus and the?xed hosts (possibly some mobile hosts in other campuses as well)that are n-1hops away from any of the MSRs, provided that the metric and threshold values for all the links in the network are1.
6Wireless Considerations
The solution presented in the previous sections pro-vides for a protective cushion against mobility.In partic-ular,if an MH that has joined a multicast groups moves to a cell within the campus that has no group members, it continues to receive the multicast datagrams addressed to the group in its new cell without any delay.This cush-ion however,comes at the expense of wasted bandwidth due to transmission of multicast datagrams in those cells which have no group members.In wireless environments where bandwidth is scarce,such a solution is undesirable. Another factor to consider with wireless communication is the existence of overlapped cells.Partial overlapping is desirable to support soft handoffs,but it may lead to certain problems if two MSRs can hear each other over the wireless link or if an MH lies in the overlap area un-der multiple cells.Below we address the problems that may affect our solution in a wireless environment and possible remedies for such problems.
6.1Optimizations for Low
Bandwidth Wireless Cells
Our solution for multicasting in a mobile environ-ment can be extended in the following manner to reduce wastage of bandwidth due to transmission of multicast datagrams in all wireless cells even if only a subset of such cells have any group members.An additional?ag can be maintained at the mrouted daemon and in the kernel forwarding code for each multicast group that in-dicates whether an IGMP report for that group was re-ceived from a locally registered MH or it came from a remote MH via the MTUNNEL.If a local MH has joined the multicast group,then the datagrams addressed to such a group are forwarded in the local cell and the MSR takes the necessary action to remain in the multicast forward-ing tree rooted at some external source.On the other hand,if a remote MH(in another cell within the cam-pus)has joined a group but no local MH is a member of the same group,then the MSR does not forward data-grams addressed to this group in its cell.The MSR keeps itself on the multicast forwarding tree for such a group however,to minimize the graft delay in case a group member moves in its cell.
The join delay for the scheme described above can be reduced using either of the following two methods
which depend on Mobile IP handoff for information about cell changes by mobile hosts.
a)Gratuitous Membership Report by MH-Whenever an
MH changes cells,it can send a gratuitous member-ship report in the new cell for each multicast group of which it is a member.The MSR can start sending the multicast packets addressed to the corresponding groups as soon as it sees the membership reports(if it was not doing so already for other local members).
b)Querying by MSR-When a MSR detects entry of an
MH to its cell,the mrouted daemon can immediately send a membership query on the mobile interface,and receive membership reports from one member of each group present in the cell.To reduce wireless traf?c caused by a premature membership query cycle,the IGMP protocol can be extended as follows:
A membership list is sent by the MSR in its wire-
less cell when an MH enters the cell.This list
consists of groups that have members local to the
cell.The MH responds with a list of groups to
which it belongs but are missing from the MSR’s
membership list.
6.2Overlapped Wireless Cells
With Mobile IP,an MH can be registered with only one MSR at a given time(except during handoffs).Only the MSR with which the MH is currently registered,may forward IP unicast packets to and from an MH.However, it is possible for an MH to receive multicast packets from multiple MSRs if it is within an overlap area under mul-tiple cells.This may result in the MH getting multiple copies of the same multicast datagram when it is sent in different wireless cells by different MSRs.Our solution does not provide any means to avoid such a problem.A link layer?ltering scheme that accepts multicast packets only from the current MSR’s link address can provide adequate protection against duplicate packets.A simi-lar problem can occur when multiple MSRs pick up a multicast datagram originating from an MH in the over-lap area.The multicast forwarding rules described above ensure that only the MSR which is local to the MH for-wards such a datagram—all other MSRs will silently discard it.
We do not allow two MSRs to communicate with each other on the wireless medium using DVMRP mes-sages.This restriction is essential because otherwise, if an MSR is able to hear another MSR over its wire-less interface,only one of them would be elected as the querier for both the wireless cells.In addition,the two MSRs would also cooperate so that only one of them for-wards multicast packets for a given
7Alternate Routing Proposals
In this section we describe how alternate proposals for IP multicast routing and mobile IP affect the solution presented in this paper for IP multicasting in a mobile environment.
7.1Link State Multicast Routing(MOSPF)
If a link state multicast routing protocol such as MOSPF[14]is used in an administrative domain with one or more Mobile IP campus(es),the problems with sending and receiving multicast datagrams at the mobile hosts remain the same.Our solutions are also equally applicable to a link state multicast routing protocol.The MOSPF speci?cation does not provide for any unicast tunnels connecting multicast capable islands as provided in the current implementations of DVMRP/mrouted.For this reason,encapsulation support for the MTUNNEL needs to be added to a MOSPF implementation that incorporates our solution for multicasting to a mobile subnet.At each MSR,the mobile subnet can be treated as a stub network for routing purposes and the MSR can generate group-membership link state advertisements for their respective cells onto their?xed interfaces.
7.2Protocol Independent Multicasting(PIM)
DVMRP and MOSPF were developed to extend the unicast routing protocols based on distance vectors and link state respectively for multicasting.Protocol Independent Multicasting(PIM)protocol[8]is designed to be independent of the unicast routing protocol used, and allows operation in two modes:dense and sparse.
PIM Dense Mode,which is very similar to DVMRP, forwards a multicast packet only if arrives on the cor-rect reverse path to the source—thus,as in the case of DVMRP,all group members will not receive a multicast packet sent from a mobile source.The problems associ-ated with receiving a multicast packet at a mobile host, will arise here as well(since they are a consequence of mobility,rather than of the multicast routing protocol in use).
PIM Sparse Mode allows for two types of multi-cast forwarding trees—shared and source-spec?c.It is not clear whether a source-speci?c tree can be created when the source(mobile)subnet is physically partitioned amongst multiple routers(MSRs).For example,when
switching to a source-speci?c tree,a router R on a re-ceiver’s link sends a PIM—Join message to the source, with the intent of setting up a optimal path from the source to the receiver(instead of using a suboptimal de-livery path from the“core”of the shared tree).Since, the route to the mobile subnet from R can point to any MSR,it is not guaranteed that the PIM-Join message will in fact reach the router(MSR)where the mobile source is located.
7.3IETF Mobility Proposal
Although we identi?ed the problems multicasting to/from mobile hosts in the context of Columbia’s Mobile IP proposal,the same problems will arise in nay Mobile-IP scheme which allows for asymmetric routes to and from a mobile host(thus leading to multicast packets being discarded due to reverse-path-forwarding check).
The IETF Mobile IP proposal[1]is not constrained to use a reserved subnet for mobile hosts.The IETF model allows a mobile host to directly make a link-layer connection to a wired subnet(without any intermediary “foreign agent”),and acquire a transient address belong-ing to that subnet.A second mechanism for supporting mobility is through Foreign Agents.A Foreign Agent makes an interface available for mobile clients;the ad-dress of the FA is used as the“care-of-address”for any mobile clients registered with the FA.The IETF scheme assumes that routing of unicast packets are not affected by the packet’s source address,and therefore a MH can use its home-address to send packets regardless of its cur-rent point-of-attachment.However,the source address is used for routing multicast packets,and in effect,the IETF’s Mobile-IP proposal has the same impact on mul-ticast routing as that of inter-campus moves in Colum-bia’s scheme.Our proposed solution for inter-campus moves using Columbia’s scheme is equally applicable to the IETF scheme,viz.if a MH needs to use its home-address as the source of a multicast packet,then the mul-ticast packet must?rst be tunnelled to its home agent as a unicast packet.However,if it uses its care-of-address in the source?eld and the care-of-address identi?es a foreign agent,then the foreign agent can forward the multicast packets on its behalf(which will require mi-nor modi?cations to the multicast routing protocol at the foreign agent).
For receiving multicast packets,a MH must re-join a mutlicast group whenever its point-of-attachment changes.We believe that it is a bad idea for a home agent to forward multicast packets to individual mobile hosts registered with the agent,since multicast forwarding then degenerates to multiple unicasts.8Conclusions
In this paper we have shown that IP multicasting in a mobile environment can give rise to problems that do not occur in a network consisting solely of static hosts.We have described a solution based on a multicast tunnel and its implementation in the context of Columbia Mobile IP and DVMRP,which helps to alleviate the problems in multicasting to/from mobile hosts.We have also discussed how our solution can be tailored for low bandwidth wireless medium.Finally,we show that our approach to IP multicasting in a mobile environment is also applicable to alternate routing proposals for mobile IP and IP multicast.
9Acknowledgments
We thank John Ioannidis for providing us with the implementation of Columbia Mobile IP system.Discus-sions with Girish Welling,Peter McIlroy and Karen Paf-fendorf were helpful in the design and implementation of our solution.
References
[1]Ip mobility support.In C.Perkins,editor,Internet
Draft.Work in Progress,1994.
[2]Arup Acharya and B.R.Badrinath.Delivering
multicast messages in networks with mobile hosts.
In Proc.of the13th Intl.Conf.on Distributed Computing Systems,May1993.
[3]Ajay Bakre and B.R.Badrinath.I-TCP:Indirect
TCP for mobile hosts.Technical report,WINLAB TR-89,Rutgers University,October,1994.
[4]P.Bhagwat and Charles E.Perkins.A mobile
networking system based on Internet Protocol(IP).
In USENIX Symposium on Mobile and Location-Independent Computing,Aug.1993.
[5]Trevor Blackwell et.al.Secure short-cut routing
for Mobile IP.In USENIX Summer1994Technical Conference,June1994.
[6]R.Caceres and L.Iftode.The effects of mobility on
reliable transport protocols.In Proc.of the14th Intl.
Conf.on Distributed Computing Systems,May1994.
[7]S.Deering.Host extensions for ip multicasting.RFC
1112.
[8]S.Deering.Protocol independent multicast(pim):
Motivation and architecture.Internet Draft.Work in Progress.
[9]S.Deering,C.Partridge,and D.Waitzman.Distance
vector multicast routing protocol.RFC1075. [10]S.E.Deering and D.R.Cheriton.Multicast routing
in datagram internetworks and extended lans.ACM https://www.doczj.com/doc/d99625976.html,puters,May,1990.
[11]J.Ioannidis,D.Duchamp,and G.Q.Maguire.IP-
based protocols for mobile internetworking.In Proc.
of ACM SIGCOMM Symposium on Communica-tion,Architectures and Protocols,pages235–245, September1991.
[12]John Ioannidis and Gerald Q.Maguire Jr.The design
and implementation of a mobile internetworking architecture.In1992Winter Usenix,Jan.1993. [13]David B.Johnson.Scalable and robust internetwork
routing for mobile hosts.In Proc.of the14th Intl.
Conf.on Distributed Computing Systems,June1994.
[14]J.Moy.Multicast extensions to ospf.RFC1584.
[15]Fumio Teraoka,Yasuhiko Yokote,and Mario Tokoro.
A network architecture providing host migration
transparency.Proc.of ACM SIGCOMM’91,Septem-ber,1991.
[16]A.Thyagarajan and S.Deering.IP multicast ex-
tensions for BSD-derived Unix systems.Documen-tation for release3.3available via ftp from https://www.doczj.com/doc/d99625976.html,,August1994.
[17]Hiromi Wada,Takashi Yozawa,Tatsuya Ohnishi,
and Yasunori Tanaka.Mobile computing environ-ment based on internet packet forwarding.In1992 Winter Usenix,Jan.1993.