scalable mobile multimedia group conferencing based on sip ... filescalable mobile multimedia group...
TRANSCRIPT
Scalable Mobile Multimedia Group Conferencing based on
SIP Initiated SSM∗
Thomas C. Schmidt
HAW Hamburg, Dep. Informatik
Berliner Tor 7
D�20099 Hamburg, Germany
Matthias Wählisch
HAW Hamburg, Dep. Informatik
Berliner Tor 7
D�20099 Hamburg, Germany
Hans L. Cycon
FHTW Berlin, FB I
Allee der Kosmonauten 20�22,
D�10315 Berlin, Germany
Mark Palkow
daViKo GmbH
Am Borsigturm 40,
D-13507 Berlin, Germany
Abstract
Multimedia group communication emerges to focalinterest at mobile devices, enriching voice or videoconferencing and complex collaborative environments.The Internet uniquely provides the bene�t of scalable,dynamic group communication services, vitally aidingcommonly limited mobile terminals. The traditional In-ternet approach of Any Source Multicast (ASM) rout-ing, though, remains hesitant to spread beyond limited,controlled environments. It is widely believed that sim-pler and more selective mechanisms for group distri-bution in Source Speci�c Multicast (SSM) will globallydisseminate to many users of multicast infrastructureand services. Mobility management for the recent SSMstandard is under debate � SSM group session initia-tion up until now remains unsupported by the SessionInitiation Protocol (SIP).
In this paper we present straightforward extensionsto SIP for negotiating SSM sessions. SIP protocol spec-i�cations and semantic are compatibly extended withoutadding new SIP methods. We will introduce a multime-dia communication software with distributed architec-ture as implementation reference. Furthermore mobil-ity management of the underlying routing layer is dis-cussed and evaluated on grounds of real-world Internettopologies.
∗This ongoing work is supported by the German Bun-desministerium für Bildung und Forschung within the ProjectMoviecast.
Keywords: Multimedia Group Session, Fully Dis-tributed Multiparty Conferences, SIP-based Peer-to-Peer, Source Speci�c Multicast, SSM Source Mobility,VCoIP
1. Introduction
Mobile multimedia communication becomes moreand more a day-to-day companion. Audio�visual de-vices performing synchronous communication such asvoice or video conferencing over IP (VoIP/VCoIP) arenow almost ubiquitous. This trend is also re�ectedin teaching and learning scenarios, as there is a risingnumber of Internet/ Intranet-backed courses at univer-sities or private companies. Real�time communicationand infotainment raise new challenges to the Internetinfrastructure, and so do mobile conference users. Theavailability of a new, truly mobile IP enabled networklayer [11] not only o�ers connectivity to nomadic usersat roaming devices, while preserving communicationsessions beyond IP subnet changes, but re-raises ques-tions concerning the quality of IP services: The con-stant bit rate scenarios of voice and video conferencingwill appear signi�cantly disturbed by packet loss inter-vals, delays or jitter exceeding 50�100 ms. IP multicas-ting will be of particular importance to mobile environ-ments, where users commonly share frequency bandsof limited capacities [12]. Thus, when heading towardsVoIP/VCoIP as a standard Internet service, importantsteps for global usability have to be taken with a focuson ease and quality.
In the present paper we address the issue of mo-bile multimedia group conferencing, exemplarily tak-ing perspective on a VCoIP (Video Conferencing overIP) software with a distributed, peer�to�peer architec-ture and its applications [17]. Such lightweight solutionshould receive support from network layer multicast,restricting service to Source Speci�c Multicast commu-nication for the sake of deployment simplicity. SourceSpeci�c Multicast (SSM) [2, 9], just released as an ini-tial standard, is considered a promising improvementof group distribution techniques. In contrast to AnySource Multicast (ASM) [5], optimal (S,G) multicastsource trees are constructed immediately from (S,G)subscriptions at the client side, without utilizing net-work �ooding or RendezVous Points. Source addressesare to be acquired by out of band channels, which a SIP[22] session initiation in conferencing scenarios shouldfaciliate.
However, up until now SIP is not prepared to ne-gotiate SSM group sessions. We therefore present asimple and straight forward extension of session ini-tiation handshakes, suitable to establish SSM confer-encing within an uncoordinated peer�to�peer model.Compliant with standard unicast and ASM transac-tions, we propose to solely add on protocol semanticswithout introducing new SIP methods. Our video con-ferencing system serves as a platform for reference im-plementation.
We further on discuss session mobility with the spe-cial focus on real-time multicast group communication.Conferencing parties request seamless real�time perfor-mance of a mobility aware group communication ser-vice, thereby attaining the simultaneous roles of mo-bile multicast listener and source. Intricate multicastrouting procedures, though, are not easily extensibleto comply with mobility requirements. Signi�cant ef-fort has been already invested in protocol designs formobile multicast receivers. Only limited work has beendedicated to multicast source mobility, which poses themore delicate problem [19, 26].
Addresses in Internet mobility carry the dual mean-ing of logical and topological identi�ers. While MIPv6operates dual addresses transparently at end points,SSM routing needs to account for logical subscriptionand topological forwarding. We present and analyzeapproaches to SSM routing, which adapt to source mo-bility.
In this paper we �rst discuss the mobile multime-dia group conferencing problem and related work. Insection 3 we present our SIP signaling scheme for SSMgroup initiation. Multicast mobility is discussed andanalyzed in section 4. Finally, section 5 is dedicated toa conclusion and an outlook.
2. The Mobile Multimedia Group Con-
ferencing Problem and Related Work
2.1. Group Conference Sessions
Multimedia session�based communication requires anumber of initial negotiations to be accomplished. At�rst, a caller requesting contact to one or several part-ners will expect to address a personal identi�er, butestablish the corresponding conference session with thedevices currently in use by the callees. Unlike in mo-bile telephony, the Internet architecture is required tolocate users and mask the user-device mapping, follow-ing the paradigm of location transparency like in emailservices. At second, media and service data need to beidenti�ed as to meet capabilities of all session members.Once established, sessions need to persist, while mobiledevices roam. Intermediate handovers thereby shouldunnoticeably comply with quality of service measuresfor real-time communication.
A �exible, fairly general Internet signaling solutionhas been presented with the Session Initialization Pro-tocol (SIP) [22]. SIP session participants commonlyregister at some SIP proxy server, which thereby gainsawareness of the user's current device. Locating a no-madic user therefore can be considered equivalent toidentifying its SIP server or session directory. To enableseamless virtual session naming services, Rosenberg &Schulzrinne [21] proposed to rely on DNS extensions,the SRV and NAPTR records, which are capable ofencoding a service�to�server name mapping. Besideuser localization, SIP covers negotiations about usercapabilities, user availability, the call set�up by SessionDescription Protocol (SDP) data and the handling ofthe calls itself. SIP introduces its own infrastructure ofproxy servers, which actively perform a proxy-to-proxyrouting by using SIP�URLs. SIP is based on an exten-sible method framework and open to store persistentdata.
SIP forms a multi�layered application protocol thatinteracts between components in a transactional way.Each (asynchronous) request initiates an open trans-action state and requires completion by at least oneresponse. SIP operations in unicast managment areexemplarily shown in �gure 1 for session inivitation.Media session parameters are included as SDP pa-rameters within the INVITE transaction, which subse-quently leads to a media session establishment in sep-arate streams.
Group communication complicates this process sig-ni�cantly. A newly joining member needs to contactan entire group, which requires appropriate addressingand transactional state management. Negotiations on
Snew S
INVITE[SDPSnew]
OK[SDPS]
ACK
Media Stream
Figure 1. SIP Simple Unicast Flow Setup
media parameters grow complex as common parameterintersections may have to be evaluated for many mem-bers. While Any Source Multicast accounts for easycommon addressing, Source Speci�c Multicast presup-poses source speci�c subscriptions. Hence, the use ofSSM requires a dedicated distribution of newly joiningsession member's addresses, which otherwise remainunnoticable in previously established SSM groups.
Group conferencing must be considered a genericterm for a wide variety of meanings in di�erent con-texts [20]. There are essentially three relevant types ofmultiparty conferences: In loosely coupled conferences,no signalling relationship is maintained by conferenceparties, while meta information are pre�shared out ofband or gradually learned by RTCP control streams.Thightly coupled conferences rely on a central manag-ing instance, granting a signalling relationship to allparticipants. Finally, the fully distributed multipartymodel is built upon peer�to-peer signalling relation-ships between conference members and allows for in-frastructureless, instantaneous establishment and op-eration. Its scalability can be largely enhanced by theuse of multicast packet distribution. Our further dis-cussion will concentrate on this fully distributed ap-proach and its enhancing inclusion of Source Speci�cMulticast communication at the signalling and the me-dia �ow level.
The SIP protocol architecture comprises proxyservers as optional components and thus draws near thegeneral peer�to�peer model. Only recently the IETFhas started work on extending the SIP framework toinclude fully distributed infrastructureless approaches,focussing on potentials to evolve in highly scalable over-lay networks, which incorporate Distributed Hash Ta-
bles for look�up purposes [1].
On the occasion of mobile users, SIP provides somemobility support for sessions [30], which requires im-plementation at the application layer. Employing theregional SIP server as an application speci�c homeagent, hando� noti�cations are traded via regular SIPmessages to the home server (register) and the cor-respondent node (re-invite). As SIP mobility operatesabove the transport layer, it remains self-consistent andtransparent to the Internet infrastructure, but inheritsall underlying delays in addition to its own signaling ef-forts. SIP application layer handovers have been foundin [13] to signi�cantly fall behind Mobile IPv4 perfor-mance, which itself is largely outperformed by MobileIPv6. Only MIPv6 � enhanced by correspondent ac-celerating protocols � does arrive at real-time compli-ant handover performance [24]. Consequently we willconcentrate on IP�layer mobility and we will discussextensions to SSM in the following section.
2.2. Mobile Source Specific Multicast
Multicast mobility management has to accomplishtwo distinct tasks, handover operations for mobile lis-teners and senders. While many solutions exist forroaming receivers [19], very few schemes have been de-tailed out for mobile multicast sources. Following ahandover, multicast data reception can be fairly easilyregained by a remote subscription approach in MIPv6[11], possibly expedited by agent�based proxy schemes.In contrast, a multicast sender must not change sourceaddress while reassociating in a di�erent network, sinceaddresses are associated with media streams via theSIP initiation dialog. Source Speci�c Multicast on theIP�layer, though, requires active subscription to con-tributing sources, thereby relying on topologically cor-rect addresses. Recalling the address duality problem,modi�ed multicast routing protocols must be foreseen,as routing at the occurrence of source movement is re-quired to transform any (S, G) state into (S′, G), whilelistening applications continue to receive multicast datastreams admitting a persistent source address. Henceany simple mobility solution such as the remote sub-scription approach loses its receivers and will no longerfunction in our context.
With SSM an additional address problem needs con-sideration: A multicast listener, willing to subscribeto an (S, G) state, needs to report for the current lo-cation of the mobile source. Concurrently a generalintricacy derives from the principle decoupling of mul-ticast source and receivers: A multicast source submitsdata to a group of unknown receivers and thus oper-ates without feedback channel. Address updates on
handovers of an SSM source have to proceed withoutmeans of the mobile source to inquire on propertiesof the delivery tree or the receivers. As the nature ofmulticast routing is receiver initiated, whereas sourcemovement is only detectable at the sender side, thisleads to a somewhat obstructive interplay. Accord-ing to common routing procedures, a mobile multicastsource on handover should trigger its receivers to re�subscribe to its new address, but remains sightless of anactual ful�llment. All of the above severely add com-plexity to a robust multicast mobility solution, whichshould converge to optimal routes and, for the sake ofe�ciency, should avoid data encapsulation.
Finally, Source Speci�c Multicast has been designedas a light-weight approach to group communication.Routing complexity remains a major deployment is-sue. In adding mobility management, it is desirable topreserve the principal leanness of SSM by minimizingadditional signaling overheads.
Three principal approaches to SSM source mobilityare presently around.
Statically Rooted Distribution Trees: TheMIPv6 standard proposes bi-directional tunnelingthrough the home agent as a minimal multicast supportfor mobile senders and listeners as introduced by [31].In this approach, the mobile multicast source (MS) al-ways uses its Home Address (HoA) for multicast op-erations. Since home agents remain �xed, mobility iscompletely hidden from multicast routing at the priceof triangular paths and extensive encapsulation.
Following a shared tree approach, [18] propose toemploy Rendezvous Points of PIM-SM [6] as mobil-ity anchors. Mobile senders tunnel their data to these"Mobility-aware Rendezvous Points" (MRPs), whencein restriction to a single domain this scheme is equiva-lent to the bi-directional tunneling. Focusing on inter-domain mobile multicast the authors design a tunnel�or SSM�based backbone distribution of packets be-tween MRPs.
Reconstruction of Distribution Trees: Severalauthors propose to construct a completely new distri-bution tree after the movement of a mobile source.These schemes have to rely on client noti�cation forinitiating new router state establishment. At the sametime they need to preserve address transparency to theclient.
To account for the latter, Thaler [28] proposes toemploy binding caches and to obtain source addresstransparency analogous to MIPv6 unicast communi-cation. Initial session announcements and changes ofsource addresses are to be distributed periodically toclients via an additional multicast control tree basedat the home agent. Source�tree handovers are then
activated on listener requests.
[10] suggest handover improvements by employinganchor points within the source network, support-ing a continuous data reception during client�initiatedhandovers. Receiver oriented tree construction inSSM thereby remains unsynchronized with source han-dovers and thus will lead to an unforeseeable temporalprogress. The authors henceforth are leaving the sourcein case of its rapid movement with an unlimited num-ber of 'historic' delivery trees to be fed simultaneously.
Tree Modi�cation Schemes: Very little atten-tion has been given to procedures, which modify ex-isting distribution trees to continuously serve for datatransmission of mobile sources. In the case of DVMRProuting, [3] propose an algorithm to extend the root ofa given delivery tree to incorporate a new source lo-cation in ASM. To �x DVMRP forwarding states andheal reverse path forwarding (RPF) check failures, theauthors rely on a complex additional signaling proto-col.
O'Neill [15] suggests a scheme to overcome RPF�check failures originating from multicast source addresschanges, by introducing an extended routing informa-tion, which accompanies data in a Hop-by-Hop optionheader.
An extended routing protocol adaptive to SSMsource mobility, visualized in �gure 2, has been in-troduced by the authors in [23]. A mobile multicastsource (MS) away from home will transmit unencapsu-lated data to a group, using its HoA on the applicationlayer and its current CoA on the Internet layer, justas unicast packets are transmitted by MIPv6. In ex-tension to unicast routing, though, the entire Internetlayer, i.e. routers included, will be aware of the perma-nent HoA. Maintaining address pairs in router stateslike in binding caches will enable all nodes to simul-taneously identify (HoA, G)�based group membershipand (CoA,G)�based tree topology. When moving to anew point of attachment, the MS will alter its addressfrom previous CoA (pCoA) to new CoA (nCoA) andeventually change from its previous Designated multi-cast Router (pDR) to a next Designated Router (nDR).Subsequent to handover it will immediately continue todeliver data along an extension of its previous sourcetree. Delivery is done by elongating the root of the pre-vious tree from pDR to nDR (s. �g. 2(b)). All routersalong the path, located at root elongation or previousdelivery tree, thereby will learn MS's new CoA andimplement appropriate forwarding states.
Routers on this extended tree will use RPF checksto discover potential short cuts. Registering nCoA assource address, those routers, which receive the stateupdate via the topologically incorrect interface, will
(a) Initial Distribution Tree (b) Tree Elongation Phase
(c) Intermediate Morphing Phase (d) Converged Distribution Tree
Figure 2. Tree Morphing States
submit a join in the direction of a new shortest pathtree and prune the old tree membership, as soon asdata arrives at the correct interface. All other routerswill re-use those parts of the previous delivery tree,which coincide with the new shortest path tree. Onlybranches of the new shortest path tree, which have notpreviously been established, need to be constructed. Inthis way, the previous shortest path tree will be mor-phed into a next shortest path tree as shown in �gure2(c). This algorithm does not require data encapsula-tion at any stage.
Recently [14] introduced a state update mechanismfor re�using major parts of established multicast trees,as well. The authors start from initially establisheddistribution states centered at the MS's home agent.A mobile leaving its home network will signal a multi-cast forwarding state update on the path to its homeagent, similar to the �rst elongation phase of Tree Mor-phing [23]. Subsequently, distribution states accordingto the MS's new CoA are implemented along the previ-ous distribution tree using multicast forwarding. Mul-ticast data then is intended to natively �ow in triangu-lar routes via the elongation and updated tree centered
at the home agent. Consequently this mechanism re-frains from using shortest path trees. Unfortunatelythe authors do not address the problem of RPF-checkfailures in their paper nor do they present delay esti-mates based on measurements or simulations.
2.3. The Video Conferencing System
In this section we brie�y introduce our reference im-plementation, a digital audio-visual conferencing sys-tem, realised as a server-less multipoint video confer-encing software without MCU developed by the au-thors [17]. It has been designed in a peer-to-peermodel as a lightweight Internet conferencing tool aimedat email-like friendliness of use. The system is builtupon a fast H.264/MPEG-4 AVC standard conformalvideo codec implementation [16]. It is a Baseline pro-�le implementation, optimized for real-time decodingand encoding by several accelerating measures like dia-mond shape motion search, MMX enhanced SAD mo-tion estimation, fast mode selection and a fast subpelsearch strategy. There is also application-tailored fastwavelet-based video codec [4] used for higher availabledata rate. By controlling the coding parameters appro-
priately, the software permits scaling in bit rate from 24to 1440 kbit/s on the �y. All streams can be transmit-ted by unicast as well as by multicast protocol. Audiostreams are prioritized above video since audio com-munication is more sensitive to distortions in erroneousnetworks.
An application-sharing facility is included for col-laboration and teleteaching. It enables participants toshare or broadcast not only static documents, but alsoany selected dynamic PC actions like animations in-cluding mouse pointer movements. All audio/video(A/V) - streams including dynamic application shar-ing actions can be recorded on any site. This system isequally well suited to intranet and wireless video con-ferencing on a best e�ort basis, since the audio/videoquality can be controlled to adapt the data stream tothe available bandwidth.
The joined use of high bandwidth UDP tra�c withTCP updates bound to real-time demands is known tosu�er from distortions due to TCP tra�c suppression.Application sharing in conferencing applications thusis endangered to encounter disruptions in the eventof network congestion. For a service enhanced syn-chronous use of UDP media sessions and applicationsharing with reliable data transport requirements, weimplemented end-to-end load balancing employing pro-prietary extensions to UDP, reliable (RUDP), we workon its packet identi�ers to control application shar-ing data �ows. On the occasion of a signi�cant num-ber (e.g., 5) of unacknowledged packets, we slow downvideo packet transmission to reserve required resourcesfor real-time application updates. Audio communica-tion remains undisturbed of load-balancing actions.
As in practice, the allocation of DNS SRV recordsis very rarely seen, the SIP approach to user locationsu�ers from a limited pervasiveness. To overcome theseobstacles, our system restricts call�names to email ad-dresses and takes advantage of the globally establishedMX server record infrastructure by applying a nameconvention to session servers as proposed in [27]. Thisallows for a rollout of session server infrastructure inconcordance with email services. In proceeding alongthis line, session oriented service support for nomadicusers can be easily established, while Internet infras-tructure remains unchanged.
3. SIP Initiated SSM Group Conferences
3.1. Multicast Capabilities of SIP
The original development of SIP has been inspiredby connection oriented telephone services, whence itsnature derives from a point�to�point model. Exten-
Figure 3. SIP initiating ASM – a callee nego-tiates its call with a previously defined multi-cast group
sions to include scalable group communication are noteasy to achieve, as was discussed in section 2. Conse-quently, the basic SIP RFC only de�nes a minimal mes-sage exchange using IP layer multicast: A client wish-ing to initiate or join into a multiparty conference sendsits INVITE request to a multicast group by employingthe maddr attribute in the SIP VIA header. Groupmembers subsequently indicate their presence by re-sponding to the same group (cf. �gure 3). The trans-actional nature of SIP dialogs is preserved in the sensethat the inviting party interpretes the �rst arrivingOK as the regular completion, while interpreting fur-ther messages as irrelevant iterates. Suitable for large,loosely coupled and mutually unknown parties, thissimple scheme only operates through Any Source Mul-ticast (ASM) and restrains management from support-ing instantaneous peer�to�peer group organisation, aswill be subject of the following section.
Additional work is needed to develop peer�to�peergroup support within a SIP control plane. Keepingin mind the routing complexity inherent to ASM, it isdesirable to rigorously restrict all signalling to Unicastor Source Speci�c Multicast communication.
3.2. SIP Extensions for SSM
Instantaneous establishment of a fully distributedpeer�to�peer conference commonly follows an incre-mental setup: Some party will initiate a conference bycontacting one or several peers via unicast addressesas aquired by a user location scheme like referred to insection 2. Following an initial contact, signalling willthen be turned to scalable multicast group communi-cation. Further on new parties will join the conferenceby either calling or being called by an existing member.
Such group conference initiation scheme is neithercovered by the current status of SIP, nor is the employ-ment of Source Speci�c Multicast for group signalling.
In order to enable SSM, all dialogs must carefully provi-sion addresses of newly arriving senders to all currentgroup members, which need to adapt source speci�csubscriptions appropriately.
In detail protocol operations of the suggested exten-sions proceed as follows. A caller, wishing to establishan SSM signalling session with a single peer, will initi-ate a regular INVITE request to callee's previously in-quired unicast address. Eventually, after the call setuphas completed, either party will decide to transfer theestablished session to group communication. Headingfor SSM, it will submit a re�INVITE, i.e., an INVITEcarrying the previously established session identi�er,announcing its desired multicast group address in theCONTACT �eld of the SIP header. Concomitantly, theSIP protocol stack will submit a multicast source spe-ci�c JOIN to its underlying IGMP/MLD stack, therebysubscribing to the group and peer's source address,which it had both learned from the previous SIP mes-sage exchange. Any peer will identify the multicastaddress in the CONTACT �eld, designed to specifycontacts for subsequent requests, and proceed alongthe new protocol semantic for SSM. As ASM multi-cast address announcement will distinctively appear ina separate VIA header, it will identify the presenceof SSM, answer with a regular unicast reply, but willsubmit a multicast JOIN to the announced group andcaller's source address.
This two�step process purposefully decouples appli-cation layer session establishment and underlying mul-ticast routing operations. Temporal progress in IP�layer multicast routing and SIP transactional timersthereby remain independent for the sake of robustlylayered protocol operations. Appropriate media sessiondescriptions for source speci�c multicast distribution ofmedia streams may or may not be submitted along there�INVITE request.
In multiparty environments, the straight forwardgeneralization for switching a previously establishedunicast conference into SSM group communication isshown in �gure 4. A newly arriving party will con-tact some member of the established session via regu-lar unicast INVITE. The callee might decide to acceptthis request and forward it to its partner, thereby ini-tiating unicast sessions among the three. Eventuallythe callee will decide to select multicast for the con-ference signalling and will submit the correspondingre�INVITE procedure.
If a new source Snew contacts an established SSMgroup conference, it will do so by inviting some memberS. If S decides to accept the caller, it will redistributeits INVITE to the SSM group and acknowledge theinitial call by placing the group address in the CON-
Snew S1 S2
INVITE[SDPSnew ]INVITE[SDPSnew ]
OK[SDPSi]
ACK
OK[SDPS]
INVITE
OK
Initiatere-INVITE
INVITE
OK
ACK ACK
ACKJoin(Snew, G)Join(S1, G)
Join(S1, G)Join(S2, G)
Join(Snew, G)Join(S2, G)
CONTACT: G CONTACT: G
Figure 4. Switching Unicast to SSM: re–INVITE
Snew S Si
INVITE[SDPSnew ]INVITE[SDPSnew ]
OK[SDPSi]
Join(S, G)
Join(Si, G)
Join(Snew, G)Join(Snew, G)
ACK
OK[SDPS]
Contact: G
Figure 5. SIP initiating SSM: Extending es-tablished group sessions to a newly arrivedparty
TACT header �eld. As displayed in �gure 5, all groupmembers will immediately add Snew to their sourcespeci�c multicast �lters. Snew subsequently will learnabout all group members from (unicast) OK�messagesas needed for its own multicast subscriptions. Notethat call redistribution will remain a point�to�pointrequest of Snew at the application layer, but a trans-mission of source S at the network layer and thereforecompliant with previous SSM group establishment.
Proceeding along this incremental way, a callee willnever be required to redistribute messages to more thanone party or group. This scheme thus remains fullyscalable and fairly transparent to group sizes. Multi-cast initiation of media sessions may be led correspond-ingly.
4. Evaluation of Adaptive Routing for
Mobile SSM Sources
Mobility initiated handovers may in general lead topacket loss and delay. Disturbances will derive fromthe subnetwork and the network layer. The tree mor-phing multicast routing scheme described in section 2.2will not produce any packet loss in addition to mobileIP handovers, as can be easily concluded from primarypacket forwarding relying on unicast source routes. Fora brief evaluation measure we will therefore concen-trate on protocol overhead and convergence. Based onreal-world Internet topologies we simulate the packetdistribution and compare our results to an idealizedhandover scheme with HA�based control tree as intro-duced by Thaler (cf. section 2.2).
We performed a stochastic discrete event simulationbased on the network simulator platform OMNeT++3.1 [29] and several real�world topologies of di�erentdimensions. The selection of network data in our sim-ulation must be considered critical, as key characteris-tics of multicast routing only make an impact in largenetworks, and as topological setup �xes a dominantpart of the degrees of freedom in routing simulations.We chose the ATT core network [8] as a large (154 corenodes), densely meshed single provider example. Forinter�provider data we extracted sub-samples of vary-ing sizes from the "SCAN + Lucent" map [7]. Samplesizes, 154, 1.540 and 15.400 core nodes, vary by twoorders of magnitude.
Mean values for the convergence of the routing pro-tocol to optimal packet forwarding have been calcu-lated for these sample networks. Convergence time isevaluated per tree in units of router hops under the as-sumption of homogeneous link delays. Comparison isdrawn to an expedited, idealized HA�Handover schemederived from [28]: As the work of Thaler has not beendetailed out, we disregard any messaging overhead tobe de�ned therein and assume that the mobile nodesubsequent to handover will immediately signal its newaddress to its receivers down its permanent HA�basedtree. On the reception of updates, multicast listenersare then expected to immediately join the tree towardsthe new source location, such that optimal packet �owis reached with shortest path tree's routing comple-tion. Following this idealized setting we calculate alower bound for the time to optimal packet forwardingof the handover procedure proposed in [28].
Figure 6 compares the convergence times of the treemorphing protocol at a designated router distance of5 with the corresponding results of the idealized HAscheme derived from [28] as functions of receiver mul-tiplicities. In general, both schemes nicely reproduce
their multicast nature by showing very little depen-dence on receiver numbers. For TM this approvesthe previously assumed parallel processing of shortcuts. While results for the single provider ATT net-work remain close, TM signi�cantly outperforms theHA scheme for multiprovider Internet topologies of allsizes. This basically re�ects its ability to re-use in-creasing parts of the wider branched trees, whereas theinter�tree handover approach always requires the re-creation of all routing states.
For the same reasons overheads therefore can beexpected to reliably remain below costs of the recon-struction of a distribution tree. In general signalingoverhead and suboptimal packet distribution remainlow in case of local movement. However, they mayincrease with the number of temporary short cuts inuse, even though the rapid algorithmic convergence asshown above will keep intermediate distribution peri-ods short.
To evaluate the routing cost of the tree morphingscheme, we calculated the mean number of newly es-tablished multicast states per handover, including alltemporary short cuts needed during convergence. Pre-viously established forwarding states, which are re�used by immediate modi�cations from TM state up-dates without involvement of regular multicast stateestablishment, are disregarded. Results are again com-pared to the idealized Thaler scheme, which is costequivalent to any tree reconstruction scheme.
Results from stochastic simulations as describedabove are displayed in �gure 7. The tree morph-ing protocol signi�cantly outperforms the HA�basedscheme, which, according to its full construction of anew distribution tree, admits almost linear cost in-crease. While the latter results from a minimal treeextension by one new edge router per receiver1, TMstrongly demonstrates its ability to decouple from re-ceiver network topology. Almost all newly establishedforwarding states remain in the vicinity of the desig-nated routers. Temporary short cuts do not seem tohave remarkable impact, as on average only very few(partial) branches are constructed as impermanent for-warding paths. For state maintenance cost as well asfor protocol convergence the adaptive tree morphingthus proved its e�ecient source mobility managementby re�using the global and changing only local partsof the distribution tree. For further evaluations and athorough discussion we refer the reader to [25].
1From the networking perspective we omit to sample multiplereceivers per edge node, as they remain e�ectless for both routingschemes.
0 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 002468
1 01 21 41 61 82 02 22 42 62 83 03 23 4
<Con
verge
nce T
ime>
[Hop
s]
R e c e i v e r s [ # ]
I n t e r n e t 1 5 4 0 0 N o d e s I n t e r n e t 1 5 4 0 N o d e s I n t e r n e t 1 5 4 N o d e s A T T N e t w o r k
(a) Expedited HA Scheme
0 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 002468
1 01 21 41 61 82 02 22 42 62 83 03 23 4
<Con
verge
nce T
ime>
[Hop
s]
R e c e i v e r s [ # ]
I n t e r n e t 1 5 4 0 0 N o d e s I n t e r n e t 1 5 4 0 N o d e s I n t e r n e t 1 5 4 N o d e s A T T N e t w o r k
(b) Tree Morphing at pDR-to-nDR distance 5
Figure 6. Mean Convergence Time to Optimal Packet Forwarding: Comparison of an Idealized HA–based Handover Scheme and TM as Functions of Receiver Multiplicity
0 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 00
1 02 03 04 05 06 07 08 09 0
1 0 01 1 01 2 01 3 01 4 0
<Cos
ts> [#
of Fo
rward
ing St
ates]
R e c e i v e r s [ # ]
I n t e r n e t 1 5 4 0 0 N o d e s I n t e r n e t 1 5 4 0 N o d e s I n t e r n e t 1 5 4 N o d e s A T T N e t w o r k
(a) Expedited HA Scheme
0 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 00
1 02 03 04 05 06 07 08 09 0
1 0 01 1 01 2 01 3 01 4 0
<Cos
ts> [#
of Fo
rward
ing St
ates]
R e c e i v e r s [ # ]
I n t e r n e t 1 5 4 0 0 N o d e s I n t e r n e t 1 5 4 0 N o d e s I n t e r n e t 1 5 4 N o d e s A T T N e t w o r k
(b) Tree Morphing at pDR-to-nDR distance 5
Figure 7. Routing Cost per Handover: The Number of Newly Established Forwarding States for theIdealized HA–based Handover Scheme and TM as Functions of Receiver Multiplicity
5. Conclusions & Outlook
In this paper we addressed the essential issues ofscalable multimedia group conferences, negotiated bythe Session Initiation Protocol and relying on SourceSpeci�c Multicast distribution among equal peers. Weintroduced, discussed and analyzed signalling exten-sions of SIP and routing methods to adapt SSM tosource mobility. Protocol operations could be shownto proceed in a fully scalable, e�cient way, preservingutmost �exibility at communicating parties.
Within this ongoing project work, we will head fur-ther for optimizations and empirical testing of our so-lution in large�scale, realistically perturbed networks.We intend to achieve this goal by deploying a videoconferencing test client onto the planetlab platform.
References
[1] S. Baset, H. Schulzrinne, E. Shim, and K. Dhara. Re-quirements for SIP�based Peer-to-Peer Internet Tele-phony. Internet Draft - work in progress 00, IETF,March 2006.
[2] S. Bhattacharyya. An Overview of Source-Speci�cMulticast (SSM). RFC 3569, IETF, July 2003.
[3] R.-S. Chang and Y.-S. Yen. A Multicast Routing Pro-tocol with Dynamic Tree Adjustment for Mobile IPv6.Journ. Information Science and Engineering, 20:1109�1124, 2004.
[4] H. L. Cycon, M. Palkow, T. C. Schmidt, M. Wäh-lisch, and D. Marpe. A fast wavelet-based video codecand its application in an IP version 6-ready server-less videoconferencing system. International Journal
of Wavelets, Multiresolution and Information Process-ing, 2(2):165�171, June 2004.
[5] S. E. Deering. Host Extensions for IP Multicasting.RFC 1112, IETF, Aug. 1989.
[6] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas.Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Speci�cation (Revised). RFC 4601,IETF, August 2006.
[7] R. Govindan and H. Tangmunarunkit. Heuristics forinternet map discovery. In Proceedings IEEE INFO-COM 2000, volume 3, pages 1371�1380, Tel Aviv, Is-rael, March 2000. IEEE Computer Society.
[8] O. Heckmann, M. Piringer, J. Schmitt, and R. Stein-metz. On Realistic Network Topologies for Simula-tion. In MoMeTools '03: Proceedings of the ACMSIGCOMM workshop on Models, methods and toolsfor reproducible network research, pages 28�32, NewYork, NY, USA, August 2003. ACM Press.
[9] H. Holbrook and B. Cain. Source-Speci�c Multicastfor IP. RFC 4607, IETF, August 2006.
[10] C. Jelger and T. Noel. Supporting Mobile SSMsources for IPv6 (MSSMSv6). Internet Draft � workin progress (expired) 00, individual, January 2002.
[11] D. B. Johnson, C. Perkins, and J. Arkko. MobilitySupport in IPv6. RFC 3775, IETF, June 2004.
[12] G. Kurup and Y. A. Sekercioglu. Source Speci�c Mul-ticast (SSM) for MIPv6: A Survey of Current Stateof Standardisation and Research. In Proceedings ofAustralian Telecommunications, Networks and Appli-cations Conference (ATNAC 2003), Melbourne, De-cember 2003.
[13] T. T. Kwon, M. Gerla, S. Das, and S. Das. Mobil-ity Management for VoIP Service: Mobile IP vs. SIP.IEEE Wireless Communications, 9(5):66�75, October2002.
[14] H. Lee, S. Han, and J. Hong. E�cient Mechanismfor Source Mobility in Source Speci�c Multicast. InK. Kawahara and I. Chong, editors, Proceedings ofICOIN2006, volume 3961 of LNCS, Berlin, Heidelberg,2006. Springer�Verlag. (in press).
[15] A. O'Neill. Mobility Management and IP Multicast.Internet Draft � work in progress (expired) 01, IETF,July 2002.
[16] J. Ostermann, J. Bormans, P. List, D. Marpe, N. Nar-roschke, F. Pereira, T. Stockhammer, and T. Wedi.Video Coding with H.264/AVC: Tools, Performanceand Complexity. IEEE Circuits and Systems Maga-zine, 4(1):7�28, April 2004.
[17] M. Palkow. The daViKo homepage, 2006.http://www.daviko.com.
[18] I. Romdhani, H. Bettahar, and A. Bouabdallah.Transparent handover for mobile multicast sources. InP. Lorenz and P. Dini, editors, Proceedings of the IEEEICN'06. IEEE Press, April 2006.
[19] I. Romdhani, M. Kellil, H.-Y. Lach, A. Bouabdallah,and H. Bettahar. IP Mobile Multicast: Challenges andSolutions. IEEE Comm. Surveys & Tutorials, 6(1):18�41, 2004.
[20] J. Rosenberg. A Framework for Conferencing with theSession Initiation Protocol (SIP). RFC 4353, IETF,February 2006.
[21] J. Rosenberg and H. Schulzrinne. Session InitiationProtocol (SIP): Locating SIP Servers. RFC 3263,IETF, June 2002.
[22] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. John-ston, J. Peterson, R. Sparks, M. Handley, andE. Schooler. SIP: Session Initiation Protocol. RFC3261, IETF, June 2002.
[23] T. C. Schmidt and M. Wählisch. Extending SSMto MIPv6 � Problems, Solutions and Improvements.Computational Methods in Science and Technology,11(2):147�152, November 2005. Selected Papers fromTERENA Networking Conference, Pozna«, May 2005.
[24] T. C. Schmidt and M. Wählisch. Predictive ver-sus Reactive � Analysis of Handover Performanceand Its Implications on IPv6 and Multicast Mobil-ity. Telecommunication Systems, 30(1�3):123�142,November 2005.
[25] T. C. Schmidt and M. Wählisch. Morphing Distribu-tion Trees � On the Evolution of Multicast States un-der Mobility and an Adaptive Routing Scheme for Mo-bile SSM Sources. Telecommunication Systems, Octo-ber 2006. in print, appeared online.
[26] T. C. Schmidt and M. Wählisch. Multicast Mobilityin MIPv6: Problem Statement. IRTF Internet Draft� work in progress 01, MobOpts, October 2006.
[27] T. C. Schmidt, M. Wählisch, H. L. Cycon, andM. Palkow. Global serverless videoconferencing overIP. Future Generation Computer Systems, 19(2):219�227, February 2003.
[28] D. Thaler. Supporting Mobile SSM Sources for IPv6.Proceedings of ietf meeting, individual, December2001.
[29] A. Varga et al. The OMNeT++ discrete event simu-lation system. http://www.omnetpp.org, 2005.
[30] E. Wendlund and H. Schulzrinne. Mobility Supportusing SIP. In Proc. of the 2nd ACM Intern. Workshopon Wireless Mobile Multimedia, pages 76�82, NewYork, NY, USA, 1999. ACM Press.
[31] G. Xylomenos and G. C. Polyzos. IP Multicast forMobile Hosts. IEEE Comm. Mag., 35(1):54�58, 1997.