Multicasting with Mobile IP & The Session Initiation Protocol

Multicasting with Mobile IP & The Session Initiation Protocol Hamad el Allali and Cristian Hesselman Abstract This report discusses how Mobile IP deals with multicast communications and describes a possible user of Mobile IP s multicasting service, namely the Session Initiation Protocol (SIP). This report also discusses a proposal to extend SIP with functions that support terminal mobility. 1 Overview In this report we describe the results of the literature study that we performed on the topics of multicast communications with Mobile IP and the Session Initiation Protocol (SIP). We kick off with the first topic in Section 2. In this section, we give an overview of how Mobile IP deals with multicast communications and list the options that mobile nodes have at their disposal for sending and receiving multicast packets. In Section 3 we then describe SIP. SIP is an application level signaling protocol that for instance supports personal mobility. In Section 3 we give an overview of SIP and consider a recent proposal to extend SIP to also support terminal mobility. We also relate this proposal to Mobile IP as well as to regular IP and regular SIP. Readers should note that this paper discusses work that has already been published elsewhere. We do not present any new work. 2 Multicasting with Mobile IP 2.1 Overview of Mobile IP The number of mobile Internet users is growing each day. This results in a demand for new services and continuous network coverage to mobile users regardless of their location. Today s Internet only makes use of nodes with fixed network attachment points. To make continuous network coverage for mobile nodes possible, Mobile IP introduces the Home Agent (HA) in the home network of the mobile node, Figure 1 shows this. mobile node foreign agent request reply Figure 1: Mobile IP model [1]. home agent The HA has the function to keep track of the current location of the mobile node and forward the packets which are destined to the mobile node s home address to the foreign network. Mobile IP s operation relies on the mobile node having a permanent home address and an assigned care-of address. The Mobile IP model uses two kinds of care-of addresses, namely co-located care-of address foreign agent care-of address In the case of using a co-located care-of address, the mobile node in the foreign network gets a care-of address e.g. from a DHCP server. When a Foreign Agent (FA) is connected to the foreign network it can assign a foreign agent care-of address to the mobile node. Note that the care-of address is temporarily assigned. The mobile node gets another care-of address when it visits another foreign network. Before the HA can forward the packets to the foreign network it must be notified by the mobile nodes of its care-of address. The mobile nodes takes care of this by sending a registration request to the HA. When the registration has succeeded the HA will intercept all the packets with a destination address equal to the mobile node s home address. The HA forwards these packet to the foreign network by using tunnelling. The FA decapsulates the received packet and forwards it to the mobile node. If an FA is not attached to the foreign link, the mobile node must be capable of decapsulating the packet. 2.2 Mobile IP Broadcast 2.2.1 Introduction In general, IP addresses can be divided into three categories. The first category consists of unicast addresses. Packets with such an address are destined to a single destination. The second category consists of broadcast addresses. Broadcast packets are those that are delivered to all nodes in a certain network. The last category is multicast addresses, which will be discussed in Section 3. In broadcast transmissions we can distinguish two kinds of broadcasts, namely Prefix-specific broadcasts Link-specific broadcasts The destination address in the IP header specifies the broadcast packet. In the case of prefix-specific broadcast, the destination address has the form network prefix.255.255. In the case of link specific broadcast, the destination address has the form 255.255.255.255. The difference between these two forms of broadcast is that the prefix-specific broadcast packets can traverse one or more intermediate routers, while the link-specific broadcast only reaches the nodes in the network where the packet is originated. 2.2.2 Receiving Broadcasts The way broadcasts are transmitted to the mobile node depends on whether the mobile node uses a foreign agent care-of address or a co-located care-of address. If the mobile node uses a co-located care-of address, the mobile node receives broadcast packets in the same way same as it receives unicast packets. This method requires that the mobile node is capable of decapsulating packets. The mobile node informs the HA that it can decapsulate by setting the D

(decapsulation) bit in the broadcast preference extension (see Figure 2). A problem arises when the mobile node uses a foreign agent care-of address in order to receive broadcasts from the HA. When the tunnelled packet arrives at the FA, the FA can t forward the packet to the mobile node because the FA is not able to determine the address of the mobile node from the broadcast address. This problem can be solved by using nested encapsulation. The nested encapsulated packet is a compilation of an inner packet header with a destination address equal to the mobile node s home address and an outer header with a destination address equal to a care-of address. Given this, mobile nodes with a foreign agent care-of address receive broadcast packets as follows. Firstly, the HA encapsulates the intercepted broadcast packet and will forward the packet to the FA using nested tunnelling. When the FA receives the tunnelled packet, it detunnels it by removing the outer header. It then looks at the destination address of the inner packet and sees an address equal to the mobile node s home address. The FA forwards the packet to the mobile node in the foreign network. The mobile node, in turn, decapsulates the inner packet by stripping off the inner header. The result is a broadcast packet that it passes to the higher layer. In order to notify the HA to use nested encapsulation, the mobile node must set the D bit to 0 in its registration request. 2.2.3 Sending Broadcasts The way of sending broadcast packets by the mobile node depends on the kind of broadcast. This can be done as follows: Sending a link-specific broadcast to a mobile node s home network. A mobile node on a foreign network tunnels a broadcast packet to the HA. after having decapsulated the packet, the HA will forward the broadcast to all the nodes on the home network. Sending a link-specific broadcast to a mobile node s foreign network. The mobile node transmits the broadcast on the foreign network, all the nodes in the foreign network will receive the broadcast. Sending a prefix-specific broadcast. There are two possibilities to transmit this kind of broadcast. Firstly, by using tunnelling to the HA. Secondly, the mobile node can send the broadcast on the foreign network. The intermediate routers can forward the broadcast to a specific network. Note that there s no need to make a distinction between foreign-agent care-of addresses and co-located care-of addresses. 2.2.4 Broadcast Preference Extension The mobile node is able to notify the HA of the broadcasts it wishes to receive by including a broadcast preference extensions in the registration request [1]. 8 bits 8 bits 4 bits 4 bits 8 bits type port length C P A X rsvd Protocol Type 40 Rsvd 0 Length 4 A include this preference X exclude the preference C eliminate any retained specifications P keep broadcast specification active Protocol protocol type Port port number Figure 2: Proposed broadcast preference extension [2]. Thus when we notify the HA of the assigned care-of address we can configure the HA at the same time. Note that the B and D bit are not included in the proposal of Patel and Perkins. 2.3 Mobile IP Multicast Multicast packets are destined to a group of nodes. The address of a multicast group has the form 1110.multicast-group. 2.3.1 Receiving Multicasts Mobile nodes do not have to be a member of the group to send packets to the multicast group. On the other hand, when the mobile node wants to receive multicasts from a certain group, it s required to join the multicast group. This can be achieved by sending an IGMP Host Membership Report (Internet Group Management Protocol) to a multicast router on the link to which the mobile node is currently attached. The multicast routers will add the mobile node to the delivery tree. The mobile node can receive multicasts on the foreign network by tunnelling the IGMP Host Membership Report packet to its HA. The HA will intercept the multicast packets and tunnel them to the mobile node, in exactly the same way as specified for broadcast packets. The other option is to send the IGMP Host Membership Report packet to a multicast router on the foreign network. After adding the mobile node to the tree, the router will compute the delivery tree and route the multicasts to the group members. 2.3.2 Sending Multicasts The mobile node can send multicast packets on a foreign network in two different ways: The mobile node can send multicasts by tunnelling them to its HA.. It is required that the HA is a multicast router. The mobile node can use the co-located care-of address as the IP source address and send the multicast packets on the foreign network. The requirement for this method is that in the foreign network a multicast router must be present. Before the multicast packets can be forwarded to the members of the group, the delivery path must be computed. This can be done for instance with the DVMRP [2] (Distance Vector Multicast Routing Protocol). For clarity, unicast packets are routed solely on their destination address, but multicast routing protocols also consider a packet s source address. Specifically, the source address of the packet must indicate that the packet comes from the right direction. This means that to route the multicasts, the network prefix of the source address must be equal to the network-prefix of the

network where the multicasts are originated. This makes mobile IP more complicated because the mobile node is not always connected to its home network. That is, the mobile node s source address may be such that a multicast routing protocol interprets it as coming from the wrong direction. Note that by using a co-located care-of address as source address in the IP header the members of the group can follow the mobility of the mobile node. This will not be a problem if the multicast router does not make use of the IP source address as the identity of the mobile node. 2.3.3 Multicast Preference Extension In multicasting it is also relevant that the mobile node notifies the HA of how it wants to send and receive multicast packets. This can be achieved by including a multicast preference extension in the registration request. Figure 3 illustrates the proposed multicast preference extension. The extension specifies the following options: 8 bits 8 bits 7 bits 9 bits type length C P A XH XF RH RF rsvd Multicast IP address Type 41 Length 6 Rsvd 0 A include this preference XH wishes to transmit from home network C eliminate any retained specifications XF wishes to transmit from foreign network RH wishes to receive from home network P keep broadcast specification active RF wishes to receive from foreign network Protocol protocol type Port port number Figure 3: Proposed multicast preference extension [2]. 2.4 Comparison of Unicast, Broadcast and Multicast We can make a comparison between the three different transmission methods. From Table 1 it can be seen that the unicast transmission is simpler to implement in the mobile IP model than the other two methods. Nevertheless, broadcast and multicast can be used in mobile IP by using tunnelling and registration techniques. The hard part, though, is that the routers must be configured correctly and be capable of handling multicast transmissions. Destination address Unicast Broadcast Multicast prefix-specific: 110.multicastgroup networkprefix.11 11 link-specific 255.255.255.255 Routing destination destination address destination- and address source address Destination single node all nodes group of nodes Encapsulation single nested encapsulation nested encapsulation encapsulation Registration none bit B and D IGMP packets Requirement none no broadcast filtering multicast router trough routers in network Table 1 : Comparison of the three different kinds of transmissions. 3 The Session Initiation Protocol In this section we give an overview of the Session Initiation Protocol [3, 4, 5] (SIP, Section 3.1) and discuss a recent proposal that suggests how to use SIP to support terminal mobility [6] (Section 3.2). For convenience, we refer to this version of SIP as Mobile SIP. We then relate Mobile SIP to IP and Mobile IP (Section 3.3) and discus some problems that we foresee with Mobile SIP (Section 3.4). We close with an overview of SIP s implementation status and pointers to the literature for readers who want to know more about SIP (Section 3.5). 3.1 Overview SIP is a proposed Internet standard that was published as RFC 2543 [3] in March 1999. It is an application level signaling protocol that can be used to establish, change and tear down sessions. These sessions may interconnect one or more users (multiparty sessions) and may carry one or more types of media (multimedia sessions), notably audio and video. In addition to being able to set up, change and release sessions, SIP can also be used to build advanced telephony services like call waiting, call forwarding, and so on. We will however not consider these supplementary services in this report. We refer the reader to [4] for some examples of such services. SIP is usually referred to in an IP telephony setting where it makes use of and cooperates with other Internet protocols (see later on in this section). SIP may however also be used in other environments. It can for example operate in an X.25 environment, in an AAL5/ATM environment, and so on. The only requirement for all these environments is that SIP messages (also to be discussed later on) are delivered in full or not at all. For this discussion, though, we will limit ourselves to an Internet setting. SIP is a client-server protocol. This means that its components consist of client parts that submit requests, and of server parts that process these requests and optionally respond with a result. Since SIP is an application level protocol, the user (i.e. client or server) is either a human enduser or a robot (a computer process). Similar to other application level protocols such as HTTP and SMTP, SIP is a textual protocol. This means that SIP messages are readable strings rather than arrays of bytes. Textual protocols generally have the advantage that their messages can be parsed (cf. a compiler), that the fields of protocol messages do not have to maintain a specific order, that debugging becomes easier and that additional fields can be added easily. The disadvantage is that textual protocol messages are generally longer than byteoriented ones. This may be a problem in settings were bandwidth is extremely scarce, for instance in a mobile environment. SIP has four primary functions [4, 5]. The most important one is name translation and user location. This basically means that SIP is responsible for finding the machine that a user is currently logged onto based on the high level name of that user (user location). SIP then needs to resolve the name of the machine to an IP address to contact the user (name translation). These two tasks are particularly required to allow one user to invite another to a session. We will see later on that the first task (locating a user) may involve intermediate name translations. The other three primary functions of SIP are feature negotiation (which allows the participants of a session to agree upon the set of media to use as well as on their characteristics), call participation management (allows users to invite, remove or otherwise manipulate the status of

user participation in a session) and call feature changing (allows the set of media in session to be changed or reconfigured). In the rest of this report we will focus on name translation and user location. SIP is part of a suite of Internet conference protocols [7]. Related protocols include the Session Description Protocol (SDP) for describing the properties of sessions (e.g. multicast address, bandwidth, media, coding, etc.); the Session Announcement Protocol (SAP) for the periodic and scoped announcement of sessions; the Real-Time Protocol (RTP) for data transfer; and RTP s counterpart the Real-Time Control Protocol (RTCP) for the feedback on QoS aspects of RTP data transfer. SIP furthermore makes use of TCP or UDP to convey its messages. SIP may use UDP in multicast mode or in unicast mode. Figure 4 summarizes the protocols related to SIP. Session Management Session Setup and Discovery TCP SIP SDP SAP UDP IP/ICMP and IP Multicast/IGMP Media Agents Audio & Video RTP/RTCP Figure 4: SIP and related Internet protocols. Addressing SIP typically identifies users by means of email addresses. These addresses are of the form user@domain. The idea behind using this form of addressing is that users will generally not know the exact location of other users. They therefore require a form of location independent addressing, which is something that email addresses inherently provide. Network servers are identified as usual, i.e. as machine.domain. SIP uses both user names as well as server names as part of URLs. These URLs consist of the prefix sip: followed by an email address or a server name. A URL that identifies a user thus looks like sip:user@domain; a URL that identifies a server reads sip:machine.domain. Entities SIP entities run s and on nodes in the network, typically a LAN. SIP entities that run s are called Agents (UAs). UAs come in two flavors: Agent Client (UAC) and Agent Server (UAS). A UAC allows a user to issue a SIP request. A UAS receives such requests, processes them and passes them up to the user. A UAS allows its user to optionally send back a response to the UAC that issued the request. Hosts are usually equipped with both a UAC and a UAS, thus allowing them to both send and receive SIP requests. The SIP entities that run on nodes in a network are referred to as network servers. They form an application level network infrastructure whose primary task is to translate names to IP addresses and to locate users. SIP defines four kinds of network servers: proxy servers, redirect servers, registration servers and location servers. Proxy servers accept SIP requests from UACs and forward them to the UAS or to an intermediate network server on the path to the UAS. Proxy servers record the path that a request takes to get to the UAS in the request itself, thus allowing the UAS to send a response back to the UAC over the same path as that of the request. Redirect servers, on the other hand, accept requests from UACs and respond to the UAC directly. The response contains the name of the UAS or the name of a next hop server on the path to the UAS that the UAC should contact next. The types of servers used to process a UAC s request may consist of a combination of proxy and redirect servers. Observe that the UAC will not be aware of the UAS actual location nor of any intermediate servers when a request is processed by proxy servers only. Also observe that a chain of proxy servers acts like a DNS recursive lookup. Likewise, a sequence of interactions with redirect servers is similar to a DNS iterative lookup. The registration and location servers support the proxy and redirect servers. Registration servers accept registration requests from UACs specifying a user s current location. Registration servers are typically collocated with proxy or redirect servers (and we ll assume this from now on). A location sever may be anything that stores information as long as it allows the proxy and redirect servers to figure out the next hop server to a user s current location. It may be a proprietary corporate database, the DNS, a finger database, etc. Location servers may be collocated with a proxy or a redirect server. They are outside the scope of SIP and we won t explicitly consider this type of SIP server from now on either. UACs and network servers may decide to forward multiple copies of a single incoming request to multiple destinations. This procedure is known as forking. It may for instance be used by the last hop server to send a request to several UASs simultaneously so as to speed up the process of contacting the end-user (also see Messages). The server may use multicast to perform the fork. Messages SIP messages are textual. The header of a SIP message specifies the type of the message, the protocol version, the source address, the destination address, etc. SIP defines 6 types of messages, the most important of which are the REGISTER and INVITE messages. The payload of a SIP message typically consists of an SDP specification. A UAC uses a REGISTER request message to convey the current location of a user to a server. This may for instance be necessary when the user has moved to another machine and wants to receive invitations to join sessions on the new machine. When the server has processed the request, it returns a REGISTER response message to the UAC specifying whether or not the registration succeeded. A UAC sends an INVITE request message on behalf of its user to invite another user to a session. The UAS that the user has registered as being his current location receives the INVITE request. The UAS passes the request to the user and sends back a response when the invited user reacts to the invitation (by rejecting or accepting it). Observe that a user may register at multiple machines at the same time and that, as a consequence, several UASs may simultaneously receive the same INVITE request. This scenario can be useful in various situations, for example when trying to contact any user out of a group (e.g. sales@domain) or when trying to contact a user as soon as possible ( page a user). This scenario also indicates a typical situation in which SIP would use UDP in multicast mode rather then unicast mode. As an example, assume that user logs onto machine pc.telin.nl. The REGISTER request message that the UAC sends to the local SIP server proxy.telin.nl would then read: REGISTER sip:proxy.telin.nl SIP/2.0 Via: SIP/2.0/UDP pc.telin.nl

From: sip: To: sip: Contact: sip:harry@pc.telin.nl <Other SIP headers> Similarly, if user invites user tom@ctit.utwente.nl to join a session, then the UAC of the calling user would send the following INVITE request to its local SIP server proxy.telin.nl: INVITE sip:proxy.telin.nl SIP/2.0 Via: SIP/2.0/UDP pc.telin.nl From: sip: To: sip:tom@ctit.utwente.nl <Other SIP headers> <SDP payload> The Via: field lists the SIP entities that the message has visited, at this stage this is only the UAC of the caller. Other message types are ACK (confirms the receipt of an INVITE response), CANCEL (cancels a pending request), BYE (warns that a user will leave a session) and OPTIONS (queries a SIP server for its capabilities). Except for the ACK message, all of these messages consist of request-response pairs. We will not consider these messages any further in the rest of this document. Behavior Figure 5 shows a typical example of SIP s behavior when the server infrastructure consists of proxy servers. The figure shows two domains (telin.nl and ctit.utwente.nl) that each use a proxy server to process SIP messages coming in to or going out of the domain. The proxy servers are named proxy.telin.nl and proxy.ctit.utwente.nl. The figure also shows the message flow when user invites user tom@ctit.utwente.nl to a session. first of all sends an INVITE request (see section Messages for message content) to its local SIP server, proxy.telin.nl (1). Server proxy.telin.nl checks the domain name of the callee (ctit.utwente.nl) and determines the IP address of the SIP server of that domain, typically using the DNS. Server proxy.telin.nl then forwards the request to the SIP server of CTIT (2). This server analyzes the user portion of the callee s address and determines that the user is currently logged onto host ws.ctit.utwente.nl within the CTIT domain (recall that users have to register their current location with a SIP server to be reachable). The server proceeds to determine the IP address of the host and sends the INVITE request to it (3). The UAS on the receiving host processes the request and passes it up to the end-user. Assuming that the end-user accepts the invitation, the UAS sends back an INVITE response indicating that the user is OK with the invitation (4). The INVITE response follows the same path as the corresponding INVITE request (5, 6) and eventually arrives at the UAC of the caller. The UAC then acknowledges the receipt of the INVITE response by sending an ACK message to the UAS of the callee (7, 8, 9). After this, the caller and the callee can exchange subsequent SIP messages or any other data directly (10). proxy.telin.nl telin.nl 6 1 8 7 2 10 Internet Backbone 5 pc.telin.nl 9 4 proxy.ctit.utwente.nl 3 ctit.utwente.nl tom@ctit.utwente.nl ws.ctit.utwente.nl Figure 5: SIP behavior using proxy servers. If the servers of domains telin.nl and ctit.utwente.nl are redirect servers, the UAC on pc.telin.nl receives the address of the redirect server at ctit.utwente.nl from its local redirect server. Upon receiving this address, the UAC sends the INVITE request to that server. The redirect server at ctit.utwente.nl then returns the address of host ws.ctit.utwente.nl to the UAC on pc.telin.nl. As a last step, the UAC sends the INVITE request to ws.ctit.utwente.nl directly. If user tom@ctit.utwente.nl accepts the invitation, the UAS of his machine returns an INVITE response to the UAC on pc.telin.nl. The UAC confirms the receipt of the INVITE response by sending back an ACK. The two hosts can communicate directly from that moment on. Figure 6 shows an example of how SIP supports personal mobility. The mobile user in this example is. He moves from a host on his home network (pc.telin.nl) to a host on a foreign network (ws.ctit.utwente.nl) where he wants to receive INVITE requests once he has logged on. To realize this, the UAC on pc.telin.nl sends a REGISTER request to its local SIP server on behalf of (1). The request indicates that will be away from his home network and that the SIP server can reach him at his CTITaddress (say harry@ctit.utwente.nl). The SIP server responds with a REGISTER response. We will assume that it indicates success. then moves to the foreign network and logs onto host ws.ctit.utwente.nl. The UAC on that machine sends a REGISTER request message to its local SIP server indicating that harry@ctit.utwente.nl has just logged onto host ws.ctit.uwtente.nl (3). As before, the server responds with the result of the registration. We will assume that this second registration has succeeded as well. After has registered, another user located somewhere else on the Internet sends an INVITE request to. The request gets routed to proxy.telin.nl (5). This server detects that is away to ctit.utwente.nl, and forwards the INVITE request to proxy.ctit.utwente.nl (6). This server knows the host on which is currently logged on, looks up that host s IP address and sends the request to it (7). The UAS on the host receives the request and finally alerts user.

proxy.telin.nl telin.nl 5 1 2 6 Internet Backbone pc.telin.nl 3 4 proxy.ctit.utwente.nl 7 ctit.utwente.nl ws.ctit.utwente.nl Figure 6: Personal mobility with SIP. 3.2 Terminal Mobility with SIP ( Mobile SIP ) Figure 7 shows that SIP supports personal mobility by allowing users to register at different locations over time. [6] has proposed to extend SIP with functions that would support terminal mobility as well. We will see later on that the difference between support for personal mobility and terminal mobility is merely the frequency with which users reregister at different locations. For convenience, we refer to the SIP version that supports terminal mobility as Mobile SIP. Observe that Mobile SIP currently only covers unicast communications. [6] motivates the development of Mobile SIP from the shortcomings of Mobile IP. These include the additional delay that triangular routing may introduce (which may be unacceptable to delay sensitive traffic such as audio); the relatively large header overhead that tunneling introduces for small packets (e.g. audio samples); the fact that home and foreign agents are potential bottlenecks if they have to deal with large amounts of traffic and large amounts of users; the waste of IPv4 addresses if mobile nodes use a collocated careof address; and the drawbacks of route optimization (e.g. the inability to authenticate a mobile node with the correspondent node in a scalable manner, high handoff latencies, the fact that the protocol stack of the correspondent node needs to be changed to support tunneling, etc.). To overcome these problems, Mobile SIP first of all drops Mobile IP s requirement that mobile nodes should have a permanent home address. Instead, mobile nodes get a new IP address whenever they change from one link to the other (e.g. using DHCP [8]). This is similar to the collocated care-of address of Mobile IP, but with Mobile SIP there is no permanent home address. Observe that the consequence of this approach is that TCP connections are broken when a mobile node changes links. In Section 3.3 we will see that Mobile SIP deals with such an event in a pragmatic manner. Mobile SIP furthermore operates in optimized routing mode as follows. On start up, a mobile node obtains an IP address on its current link (home or foreign) and registers it with a SIP server on its home link. For the sake of this discussion, we will assume that the mobile node is on a foreign link when it starts up. We will furthermore follow the notational convention of [6] and refer to an IP address by means of its high level name of the form machine.domain. Once the mobile node has registered, correspondent nodes can contact it. A correspondent node simply sends an INVITE request, which the SIP server infrastructure then routes to the SIP server of the mobile node s home link following standard SIP procedures. Assuming that the SIP server on the home link is a redirect server, it returns the address that the mobile node has registered with. The correspondent node then redirects the INVITE request to the mobile node directly. If the mobile node accepts the invitation, it exchanges further SIP messages as well as any other data directly with the correspondent node from that moment on. Note the similarity with Mobile IP in optimized routing mode. Figure 7 shows an example of the above scenario. When the mobile node roams to another link (1), it first of all gets a new IP address. Assume that in this example this new address is laptop.cs.utwente.nl (recall that we refer to IP addresses by means of their high level names). In order to continue communications between the mobile node and the correspondent node, the signaling association as well as the data transfer association (2) between the two nodes need to be handed off to the mobile node s new IP address. Mobile SIP deals with this situation by having the mobile node send an INVITE request message to the correspondent node (3). The message contains the mobile node s new IP address in the INVITE message s Contact: field to tell the correspondent node where the mobile node wants to receive future SIP messages. This effectively hands off the SIP signaling association between the mobile node and the correspondent node. To also hand off the data transfer association, the mobile node includes its new IP address in the SDP payload of the INVITE messages. Specifically, the mobile node places its new address in the c(onnection)-field of the SDP description. If the correspondent node is OK with both handoffs, it returns an INVITE response indicating this (4). The mobile node, in turn, then responds with an ACK to complete the handoff (5). From that moment on all SIP signaling messages as well as all other traffic again directly flow from the correspondent node to the mobile node and vice versa (6). The mobile node completes the handoff by reregistering its new location (laptop.cs.utwente.nl) with the SIP server on its home link (7). dick@telin.nl pc2.telin.nl telin.nl ctit.utwente.nl 2 4 6 laptop.ctit.utwente.nl proxy.telin.nl Figure 7: Terminal mobility with SIP. 1 3 5 7 cs.utwente.nl laptop.cs.utwente.nl The INVITE request message that the mobile node sends to the correspondent node looks like this: INVITE sip:dick@telin.nl SIP/2.0 Via: SIP/2.0/UDP laptop.cs.utwente.nl From: sip: To: sip:dick@telin.nl Contact: sip:harry@laptop.cs.utwente.nl <end SIP header, begin SDP payload> c=in IPv4 laptop.cs.utwente.nl <end SDP payload>

Observe that the load on a SIP server that supports terminal mobility will generally be higher than the load on a server that does not support this feature. This is because the first kind of server will generally receive more reregistration requests than a server of the second type. 3.3 Mobile SIP with IP and Mobile IP Mobile SIP may be combined with TCP/UDP/IP or with TCP/UDP/Mobile IP. Mobile SIP takes care of the signaling functions in these configurations, whereas TCP/UDP/(Mobile) IP provides the data transfer functions (which Mobile SIP obviously requires as well). The previous section discussed the combination of Mobile SIP and IP. The disadvantage of this configuration is that terminal mobility breaks the TCP connections that are in use by applications on the mobile terminal (e.g. an FTP or HTTP application). For applications that use short-lived TCP connections this is not much of a problem. They can reestablish the connection at relatively low cost. A Web application that uses HTTP 1.0, for instance, will not suffer a whole lot when one or more of its TCP connections break. However, applications that make use of long-lived TCP connections do suffer from connection breakdowns. They cannot reestablish a connection at low cost unless there exists some sort of synchronization mechanism that tells the application at which point during the data transfer the connection got released. In the absence of such a mechanism, the application will have to start the data transfer all over again. An example of an application that belongs to this category is an FTP-based file transfer application. Mobile SIP in combination with Mobile IP does not suffer from the TCP connection problem because Mobile IP supports transparent terminal mobility. However, this combination is inefficient. For instance, both Mobile IP s home agent and the SIP server on the mobile node s home link keep track of the mobile node s current location. This problem could however be solved by collocating the home agent and the SIP server or by allowing the SIP server to query the home agent. In addition to the overhead created by keeping track of mobile terminals at two levels, the combination of Mobile SIP and Mobile IP also wasted IPv4 address space. Actually, this combination reduces Mobile SIP to standard SIP and suffers from all the drawbacks that led to the development of Mobile SIP in the first place. [6] suggests using a configuration that exploits the best of both combinations. That is, they suggest to use Mobile SIP in combination with UDP/IP for delay sensitive applications; Mobile SIP and TCP/IP for applications that use short-lived TCP connections; and TCP/Mobile IP for applications that rely on long-lived TCP connections. Finally observe that Mobile SIP will be easier to deploy than Mobile IP with route optimization. This is because the second requires changes to the operating system (which is where the IP protocol stack typically resides) of correspondent nodes to be able to tunnel packets to the mobile node. Mobile SIP is an application level protocol and does therefore not require such changes. Table 1 lists the main differences between Mobile IPv4 and Mobile SIP. Mobile IPv4 Mobile SIP Mobility type Transparent Non-transparent Signaling level Network Application Messages Byte-oriented Textual Data transfer types Unicast, multicast, and Unicast only broadcast Addresses Fixed home address plus variable care-of address Variable care-of address Routing entities Home agent, foreign agent (optional) and standard IP routers Standard IP routers Routing type Triangular, tunneled Optimized, nontunneled Address updates To home agent To correspondent node and to SIP server on home network Table 2 : Main differences between een Mobile IPv4 and Mobile SIP. 3.4 Observed Open Issues In Section 3.2 we already mentioned that the current version of Mobile SIP only supports handoffs for unicast communications. This section identifies a couple of problems that we foresee with handoffs for multicast communications. Consider the scenario outlined in Figure 7 of Section 3.2, but assume that the mobile and the correspondent node communicate via an IP multicast group of which both nodes are a member. When the mobile node roams to another link, it will get a new IP address. This means that it will have to leave the multicast group with its old address and join the group with its new address. However, when the mobile node detects that it has moved to another link using router advertisements [1], it will have no way of contacting its old multicast router and deliver the IGMP unsubscribe message to it. This means that the multicast router on the mobile node s old link will keep on broadcasting or multicasting messages destined for the mobile node on the node s old link. This is not much of a problem when there are other nodes on that link that happen to be a member of the same multicast group. However, when the mobile node was the last node on the old link that was receiving messages from the multicast group, the multicast router on the old link will keep on sending messages on the old link while there are no hosts that want to receive them. This is a waste of bandwidth, especially on a wireless link. This situation persists until the multicast router on the old link finds out that there are no nodes on the link that are interested in receiving packets from the multicast group. To solve the above problem, the mobile node should be able to send the IGMP unsubscribe message for its old IP address to the old multicast router. This requires the mobile node to record its old IP address as well as the IP address of the old multicast router. The mobile node and the old multicast router should furthermore be able to communicate through a tunnel because IGMP messages only carry an IP multicast address (i.e., 224.x.y.z) and can therefore not be sent to routers directly. Finally, the old multicast router needs to be capable of acting as a representative (i.e., as an agent) of the mobile node. That is, it should be able take unsubscribe messages from the tunnel and transmit them onto the mobile link on behalf of the mobile node. Notice the similarity with sending link-local broadcast packets and multicast packets in Mobile IP. While it is problematic to gracefully leave a multicast group on the old link, it is easy to accomplish the handoff toward the new link. All the mobile node has to do is to join the same multicast group on its new link (provided, of course, the router of the new link is a multicast router). Unlike the unicast

situation, the mobile node does not need to send an INVITE message to the correspondent node at the transport level the correspondent node is not aware of the identity of the nodes that it is communicating with anyway. The problem of not being able to gracefully leave a multicast group can be alleviated if the mobile node gets assistance from the link layer technology on its old link. For example, if that link layer technology would be able to notify the mobile node that a handoff was imminent, the mobile node would probably be able to gracefully leave the multicast group on its old link. Observe that the assistance that a mobile node gets from its link layer is part of an overall mobility solution as already suggested by [1] on page 50. 3.5 Implementation Status and Further Reading An overview of SIP implementations (completed ones as well as implementations in progress) can be found at http://www.cs.columbia.edu/~hgs/sip/implemen tations.html. Mobile SIP was being implemented when [6] appeared. This was in August 1999. We advise interested readers to first go to http://www.cs.columbia.edu/~hgs/sip/papers.h tml. This Web page contains a long list of SIP papers that are far more easier to understand than the RFC, especially at first. Most of the references mentioned below can also be found there. References [1] J. Solomon, Mobile IP The Internet Unplugged, Prentice Hall, 1998 [2] Charles E.Perkins, Mobile IP - Design Principles [3] M. Handly, H. Schulzrinne, E. Schooler, J. Rosenberg, SIP: Session Initiation Protocol, RFC 2543, March 1999 [4] H. Schulzrinne, J. Rosenber, The Session Initiation Protocol: Providing Advanced Telephony Services Across the Internet, Bell Labs Technical Journal, Oct-Dec 1998, p. 144-160 [5] H. Schulzrinne, J. Rosenberg, Internet Telephony: Architecture and Protocols An IETF Perspective, Computer Networks and ISDN Systems, Volume 31, Issue 3, p. 237-256, 1999 [6] E. Wedlund, H. Schulzrinne, Mobility Support using SIP, Second ACM/IEEE International Conference on Wireless and Mobile Multimedia (WoWMoM'99), Seattle, Washington, August, 1999 [7] M. Handly, J. Crowcroft, C. Bormann, J. Ott, Very Large Conferences on the Internet: the Internet Multimedia Conferencing Architecture, Computer Networks and ISDN Systems, Volume 31, Issue 3, p. 191-204,, 1999 [8] R. Droms, Automated Configuration of TCP/IP with DHCP, IEEE Internet Computing, July-August 1999, p. 45-53