INTERNET DRAFT V. Madisetti Date: May 20, 2002 A. Argyriou Expires: November 20, 2002 Georgia Institute of Technology Voice & Video over mobile IP Networks Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Transmission of voice, video and other real-time multimedia data over IP networks is gaining much importance, and Quality of Service (QoS) issues are further compromised when wireless and mobility issues are also included into the picture. A unified approach, VoMo, to addressing QoS through consideration of appropriate signaling, control and data transmission is presented, that has the additional benefits of compliance with current IP network infrastructure through recently proposed IETF protocols, such as Stream Control Tranmission Protocol (SCTP)[RFC2960] and Session Initiation Protocol (SIP)[RFC2543]. TABLE OF CONTENTS 1. Introduction............................................... 2 1.1 Problem statement...................................... 2 1.2 Current approach: Mobility with SIP.................... 3 2. Requirements............................................... 3 2.1 General requirements................................... 3 2.2 QoS requirements........................................3 Madisetti, Argyriou. [Page 1] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 3. Proposed protocol...........................................4 3.1 Network architecture....................................4 3.2 VoMo protocol...........................................5 3.3 Detailed operation......................................5 3.4 Movement detection scheme...............................7 3.5 Base Station topology...................................7 3.6 An example..............................................7 4. QoS benefits................................................8 4.1 Improvement of the overall delay........................8 4.2 Integrated Services/RSVP considerations.................9 5. Handoff improvement.........................................9 5.1 Subnet handoff..........................................9 5.2 Domain handoff.........................................10 5.3 Technology handoff.....................................10 6. Implementation details.....................................11 6.1 The Stream Control Transmission Protocol (SCTP)........11 6.2 Mapping protocol functionality to SCTP operations......11 6.3 Achieving better scalability...........................12 7. Additional benefits from the use of SCTP...................12 7.1 Unified transport level approach.......................12 7.2 Security benefits......................................12 7.3 Binding updates optimization...........................12 8.Conclusions.................................................13 9.References..................................................13 10.Intellectual property statement............................14 11.Authors's addresses........................................14 1. Introduction 1.1 Problem statement Ensuring toll quality Voice or Video over IP requires strict control over path delay, jitter, packet loss and other other impediments that burden IP networking. Thus, meeting Quality of Service (Qos) guarantees is of paramount importance. These problems are compounded in the case of a wireless network, where new problems arise due to the implied mobility of the users as well as the nature of the current IP protocols that support IP-based mobility, combined with lossy and interrupt-prone nature of the communications channel. Handoff delay, and overheads of Mobile IP's triangular routing, triangular registration, and IP encapsulation are major issues that must be resolved prior to wide spread acceptability of real-time interactive multimedia communications over the wired or wireless IP network. Moreover, the reduced processing requirements and low-power operation of handsets, set additional constraints to a wireless device. We believe that the problem is more amenable to solution through a unified approach that links a number of layers of the network software, from link to application, while ensuring support for traditional networking and telecommunications applications. Madisetti, Argyriou. [Page 2] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 1.2 Current approach: Mobility with SIP Currently, promising approaches that provide service and user level mobility for media data over wireless links are based on SIP (Session Initiation Protocol)[SIPMUL] and Mobile IP standards. SIP relies on the usage of SIP's registration mechanism for providing terminal and user mobility. Every user has a URI, which could be an e-mail address (e.g., burdell@gatech.edu). When the user moves to a new place, it registers its new position with the SIP registrar, so that the the SIP registrar server knows the user's current position. This kind of registration can provide user-level mobility. In order to achieve terminal mobility a SIP mobility implementation could poll the OS in order to find out if handoff took place so that the SIP will register with the new SIP registrar after handoff [SIPMUL]. SIP based mobility, thus, offers attractive benefits when used in mobile multimedia applications. However, there are some inherent problems with this approach that make the adoption of this scheme difficult. For example it cannot handle mid-call subnet changes, since it is an application layer solution. This is where it requires the support of a lower level mobility protocol, e.g., Mobile IP. One other important issue is that of inter-operability with mobile IP. Home Agent and Foreign Agent registrations in mobile IP serve the same purpose with the SIP REGISTER messages. And because as we said before SIP needs the support from Mobile IP, their joint deployment becomes problematic. 2. Requirements In this section we briefly outline the requirements that may realize acceptable performance for IP-based real-time multimedia and wired and wireless applications. 2.1 General requirements A solution targeting the multimedia Internet must be scalable in terms of mobile nodes connected to the network, their respective traffic loads, and associated QoS. For the wireless applications, the solution should also be compliant (with as minimal modifications as possible) with applications relying on Mobile IP. An additional desired requirement is to create a unified mobility framework for, both, reliable and unreliable transfer of multimedia data. 2.2 QoS requirements Providing QoS in multimedia applications over wireless links, is probably one of the most challenging tasks in mobile communications. The delivered QoS is related primarily to the overall network delay, and robustness of the communications medium, both of which are Madisetti, Argyriou. [Page 3] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 considered in this document. For those cases where we assume the usage of mobile IP this delay consists of three components: triangular routing, triangular registration, and IP encapsulation. Total delay is also heavily affected by the handoff delay. Minimizing this part of the total delay is also considered in this document. 3. Proposed protocol This section presents the proposed protocol 3.1 Network architecture In Figure 1, we present the network architecture that we assume a mobile node MN is attached to. Note that we do not require this specific network architecture. This figure just serves as a point of reference throughout the rest of this document, and the technology is easily applicable to GPRS and 3G networks as well. We assume that the Base Station (BS) is attached to a router. A MN could modify its IP address while it is moving from BS to BS inside a subnet, and so it will have to invoke the Mobile IP handoff mechanism. However it could also have just one IP address per subnet, and so it will just have to suffer Link Layer (L2) handoff. But when the MN moves from one subnet to the other it has of course to get a new IP address. +-------INTERNET------+ | | | | __|__ __|__ +-----+ / \ / \--| FA | / \ / \ +-----+ / Router \ / Router \ | \ Subnet1 / \ Subnet2 / | \ / \ / | +--\_____/----+ +--\_____/----+ | | | | +-----+ +-----+ +-----+ +-----+ | BS | | BS | | BS | | BS | +-----+ +-----+ +-----+ +-----+ | | | | | | | | | +-----+ +-----+ +-----+ | MN |=======>| MN | =============>| MN | +-----+ +-----+ +-----+ (1) Intra-domain (2) Inter-domain movement movement Madisetti, Argyriou. [Page 4] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 Figure 1. 3.2 VoMo protocol The VoMo protocol has two distinct phases. The initialization process, performed at each subnet even when no MNs are inside a cell. The connection process which handles all the necessary steps that a MN has to go through in order to connect to the wireless network. Phase 1: Initialization of the network All contiguous cells to the currently active cell, will be automatically included in the neighborhood_list, thus the handoff will be smoother, since we know that we can add and prune cells, based on the movement and it will provide the necessary lag for efficient handoff. This kind of lookahead additions to the neighborhood_list can help QoS, at the cost of additional network traffic. Phase 2: The connection process Step 1: Mobile Node enters a subnet and sends a registration request. Step 2: A central server (e.g. DHCP) provides a list_of_addresses based on the neighborhood_list. Step 3: the MN uses as its _primary Care-of-Address the one of the list_of_addresses that corresponds to its current point of attachment. When the MN moves to another point of attachment (BS) two cases arise: Step 4a:When the MN movement is inside the subnet, it MUST switch to another IP of its list_of_addresses according to movement detection information. Step 4b:When MN is moving to a new subnet, it sends a registration request to the other subnet requesting new list_of_addresses. Step 5: The MN decides when it has changed BS by using movent detection info from either L2 or L3 protocol layers. Step 6: Upon its decision, the MN, and having moved to a new subnet it discards the old list_of_addresses, and starts using a new_primary_address from the newly allocated list_of_addresses. 3.3 Detailed operation The basis of the VoMo is the exploitation of the mobile node's neighborhood of Base Stations (BS). With the term neighborhood we mean all the Base Stations that could possibly be the next point of attachment of the mobile node (MN). A central server/manager of such Madisetti, Argyriou. [Page 5] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 a neighborhood, must operate in such way that it provides the MN with addresses that correspond to different physical paths in the wired network. For example, when a MN is attached to a BS, it obtains addresses form a specific DHCP server, and when it moves to a new BS it gets addresses from another DHCP server. These two cases correspond to different wired paths that reach the BS in each case. However, these paths are not all active at the same time, but they can be activated in the near future if the mobile node moves. The existence of this kind of paths leading to the MN is a crucial requirement for the proposed protocol to work. As we said, a central server in the subnet can be used in order to assign addresses to mobile hosts and keep track of the mapping between assigned addresses and hosts. In the case of mobile IPv4 this server may be the Foreign Agent [RFC2002], and in the case of mobile IPv6 this could be a DHCP server. We believe that in both cases, the distribution of addresses from the server should be intelligent in the way we explained before, and it this requirement is not compromised by the usage of either IPv4 or IPv6. Let us see in more detail how the multiple addresses MUST be used by the MN. Each IP address, will have to correspond to a different path leading to a different BS. Initially the MN is assigned a _primary address that guarantees routing of packets from its current point of attachment. However, as we said, the server must provide the MN with a list_of_addresses that correspond to paths related to the MN's neighbor point of attachment. The MN should utilize, if possible, these addresses for every active connection well as every new connection. A Correspondent Node (CN) requesting communication with the MN, will first try to reach the MN through its home_address. The home network will inform the CN about the current location of the MN. The CN can then directly connect to the MN from its current location. When the MN moves to a new point of attachment, it will use one of the pre-allocated addresses. It is obvious now that this form of allocation saves the MN valuable time of requesting address every time it has to suffer handoff. Now that the MN decided to use a new_primary_address it must notify the CN about the new addresses from which the other endpoint (MN) is reachable now. The new protocol additionally requires from the MN to inform the CN about the list_of_addresses that it has as soon as the MN receives them. This means that the CN must be able to use any of the remote addresses, that correspond to different paths, in order to reach the MN. In this way direct communication takes place directly between the CN and the MN. Triangular routing, the primary overhead of mobile IP, is eliminated in this way. This part of the protocol makes sure that a CN is notified as soon as possible from the MN about the MN's new_primary_address, so that Madisetti, Argyriou. [Page 6] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 direct communication exist at all times. 3.4 Movement detection scheme Movement detection is important, for the protocol to work efficiently. The address changes for a MN are triggered when movement is identified. It is thus important to have information about when a MN moved, and if is about to happen via a network layer or link layer handoff. Let us consider the case where the mobile node moves, and it is heading towards a new point of attachment. The problem that arises now is which address will be the next primary address that will be used by the MN. This decision depends on the direction of the Mobile Node's movement. In draft [MSCTP] they propose the use of two network interface cards. Alternatively, as proposed in [MIP6] lower, link layer information can be used in order to decide a node when to switch to a new BS and a new care-of IP address. Movement detection information can also be used from the network layer (Mobile IP)[RFC]. In our case, if the mobile Node decides to switch, it must update, and change, if possible, for a current connection the address being used. It must also discard most of the previously allocated addresses. 3.5 Base station topology In order for the central server to distribute intelligently IP addresses, according to our approach, it must has precise knowledge of the base station topology. Since this is a rather complicated issue we assume here that this information is already available at the server when it is (re)configured initially. This is not such an important restriction as it may seem. If for example we assume the existence of 6-edge cells, then we know initially which is the mapping of cells to 6 distinct BS. An approach for dynamically acquiring the BS topology is presented in [SCAMOB]. 3.6 An example Now let us go through an example of a Mobile node using VoMo. The usage of Mobile IPv4 and DHCP is also assumed. When IPv4 is used, the MN must obtain a co-located address in order to have an address that is separately routable. As stated previously, key concept in the protocol is that the MN should get more than one (a list of) co-located addresses. This may be a problem in the case when IPv4 is used, due to the limited address space, but it is not the case with IPv6. Now, let us describe the DHCP operation. The MN sends a broadcast message DHCPDISSCOVER to the DHCP server(s). The MN should not select one address but a list of them and send back a DHCPREQUEST to the DHCP server(s) that it has selected and reside in its current subnet. Madisetti, Argyriou. [Page 7] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 Then the DHCP server has to sent a DHCPCK message back to acknowledge the receipt of the addresses. However, if the MN gets IP addresses from different DHCP servers, they will be probably be useless, since each DHCP server just provides addresses, but possibly not the correct one that corresponds to a different path and Base Station. That is why the distribution process MUST be handled centrally by only one server which knows the base station topology. After the MN has acquired an IP address it can add it to its list of addresses and start using it when it needs to. 4. QoS benefits 4.1 Improvement of the overall delay Providing QoS, is very important requirement for real-time multimedia applications. Triangular routing, handoff delay, increased error rate, reduced amount of available resources makes QoS in a wireless network a very tough and challenging issue. The existence of multiple paths in the proposed protocol could provide a mechanism for optimizing the provided QoS to a MN. The most important requirement for a real-time application is to minimize the overall delay between the communication endpoints. By utilizing the above protocol delay and the respective jitter can be minimized even more compared to the case where mobile IP/TCP are used. A mobile node, immediately preceding the handover, based on low level criteria as stated before (link layer information), will try to switch to a new point of attachment by using an already pre-allocated address. The CN will be notified by the MN that the current path is inactive. It will then try to send the data stream to the address that has become primary now. The important point here is that the MN when it actually is hooked up to the new network, with the new IP, it must inform immediately the correspondent Node that it will have to modify the current IP address and change it to the new one. When the MN informs the Correspondent Node about its new address, then communication can exist directly between them and no tunnelling is required. In this way triangular routing delay becomes zero. This is of primary importance for the applications we are interested. Moreover, the fact that the new address was pre-allocated and the MN does not have to reacquire new address at every handoff, reduces the handoff delay. What we actually doing here is just like a resource reservation mechanism, where our resources are IP addresses. However this is a two dimensional problem since we do not only care about the number of IP addresses that a MN acquires but in which access points each of them correspond. It is like reserving a slot in each subnet for the MN, so that it will not go through the process of requesting an IP when it actually reaches this point. This kind of reservation can Madisetti, Argyriou. [Page 8] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 have as we saw, direct impact in the reduction of the overall delay. 4.2 Integrated Services/RSVP considerations Integrated Services model, requires the exchange of information between endpoints about the required QoS of a data flow. RSVP is a protocol that can carry this information and deliver it to all the routers, that will deliver the QoS. More specifically, RSVP offers a mechanism for network resource reservation, just before actual data transfer takes place. An interesting approach would be to use IP-multicast with RSVP in a way similar to [SCAMOB]. A multicast tree could be created, which will have as its leaves IP addresses of a MS's association list. But if the addresses are pre-allocated, in the way that we described earlier, then when then node moves it will be in one address of the multicast tree. This means that reservation process does not have to be invoked throughout the path from the CN to the MN, but it will only be applied locally. The will just subscribe to a multicast address and unsubscribe according to our proposed approach. This approach has the problem of reserving resources in advance even if they are not needed. 5. Handoff improvement Handoff is arguably a primary overhead in wireless IP network performance, since it introduces delay and processing overhead on both the wireless and wired nodes. Low latency handoff is even more important in our case, where we are focusing in VoIP applications. Three kinds of handoff are discussed in the sections that follow. The applicability of the proposed approach under these cases is analyzed and evaluated. 5.1 Subnet handoff Intra-subnet handoff occurs when a MN moves from one base station to another, but both the base stations are connected to the same router. Under this case the IP address of the mN could remain the same or it could possibly change to new address from the same subnet. Let us now describe, operation of the neighborhood-based technology under subnet handoff. The mobile node would normally require registration with a DHCP server again [SIPMUL], which incurs a round-trip delay. The proposed protocol requires the pre-allocation of IP addresses for a mobile node. When the MN moves, to a new point of attachment, it can use directly the IP address that already has. Moreover, if there is a notification from the L2 or MIP layer about imminent handoff, the MN MUST change the primary address in the association and make it be an address that corresponds to the new base station, just before the time of handoff. The important point is that the CN does not have to be re-invited [SIPMUL] or Madisetti, Argyriou. [Page 9] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 re-establish a broken communication with the MN, but it can simply continue communication by just using a different route. The result of this handoff will be just a few lost packets, which in the case of a reliable protocol will be retransmitted again. In the case that we use an unreliable protocol, operation under subnet handoff is greatly optimized. As it is obvious RTT delay does not exist any more. So in the case of voice data that utilize UDP or any other Unreliable protocol, just a few packets will be lost but the communication will continue without significant interruption. 5.2 Domain handoff Operation when we move to a different Domain is nearly the same. The only difference is that the mobile node must have already acquired an IP address from a different domain. This means that an association will have to include addresses from a different domain. The only penalty that a MN would have to suffer in such a case would be the admission control to the new domain, because it would have to be authenticated first. However, inside a domain authentication does not have to happen in every handoff, but only once, during MN startup. 5.3 Technology handoff Using different wireless access technologies from the same terminal must be an important consideration for the future wireless devices. The user must have the flexibility of selecting the technology that he will use according to the provided QoS, cost, availability etc. Two issues arise in the case where multiple access technologies are available. The first issue is the problem of selecting one of all the possible access technologies and second is the handoff between them. Next we briefly describe a scenario where we describe how the proposed protocol could handle the above problems. We consider the case where a mobile node has established a connection with a WLAN and it moves to an area where it also has access to a GPRS service. The mobile node can choose one of the two technologies according to user criteria, as said before. GPRS does nearly the same work with mobile IP. That is, they both offer terminal mobility. They take care of the handoff process when a mobile node moves between cells. However, the proposed protocol could as well be applied in this case where mobile IP will not be used. The only requirement from our protocol is that the device will access the GPRS network using IP. An additional requirement from the user would be the non-interruption of an existing connection now that there has to be technology handoff. So, what we actually want to do is to switch from a mobile IP WLAN network to a GPRS network using IP. According to the proposed protocol, the mobile node MUST have made a pre-registration to another network, which in this case would be a GPRS network. The MN must first perform a GPRS attachment procedure Madisetti, Argyriou. [Page 10] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 [GPRS]. This process has primary to do with authenticating the user and proving an IP address. The provided IP address will be used the same way as before by the protocol. The protocol just needs IP addresses that correspond to different paths and is thus technology unaware. The protocol will treat the two different networks as two different points of attachment 6. Implementation details 6.1 The Stream Control Transmission Protocol (SCTP) SCTP is a new IETF transport level protocol [RFC], that offers a number of advanced features. It introduces the idea of multihoming, where a host has multiple addresses from which it is reachable. An association between two endpoints can exist between any of these addresses. If one of the paths that corresponds to one address fails then an alternative can be used without interrupting the connection between the endpoints. The two endpoints can monitor the status of the paths by sending a special kind of SCTP messages called Heartbeat messages. Primary goal of the above protocol property was error resilience. However, as we will see in the next section this features helped us to implement part of the proposed protocol functionality. 6.2 Mapping protocol functionality to SCTP operations In this section we describe in detail how someone could use SCTP in an implementation of the proposed protocol. Initially, a mobile node creates an SCTP association when it connects with a Correspondent Node. This SCTP association could be the place where we store the address list obtained form the attached network. The MN initially makes use of just one address from the association which is called primary. Since SCTP is multihomed, a MN could possibly use any of the addresses in its association. Our protocol will decide when the MN must start using another address by making it the primary. This can happen only when the mobile node moves to a new point of attachment. By utilizing multiple IP addresses for a single association, SCTP realizes the idea of the existence of multiple paths between the CN-BS-MN. However, as we said we said our protocol uses just one path every time, and all the others exist but they are not active. To monitor the status of the inactive paths, the new protocol uses SCTP HEARTBEAT messages. This messages are send to all the existing addresses in a single association that are not currently used. By utilizing information about the reachability of specific paths, the protocol decides when to switch to a new address. Our protocol can also, initiate the switching to a new address according to predefined criteria. For example even if a MN is still attached in a subnet, but is approaching another one, then the Madisetti, Argyriou. [Page 11] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 protocol could initiate handoff procedure and change the primary address in the SCTP association list. Moreover, the protocol could operate in a way similar to a QoS mapper, which maps specific QoS requirements to SCTP parameters. E.g. high QoS could require large number of SCTP heartbeat messages and increased number of IP's. This SW could be intermediate stage between a QoS aware application and the actual association setup. 6.3 Achieving better scalability In order to achieve better scalability with this architecture, information about movement detection must be used if it is available, so that the number of allocated IP addresses is reduced. Also, when a MN reaches a new point of attachment it should deallocate all the previously allocated addresses from its association, except the last address being used. In this way addresses are released 7. Additional benefits from the use of SCTP 7.1 Unified transport level approach The need for a unified mobility framework is needed for all the classes of applications (reliable/unreliable). We identified previously the problems that can be caused by the simultaneous use of SIP and mobile IP for serving different classes of applications. We propose the usage of the unreliable extension of SCTP (USCTP) found in [USCTP]. The primary advantage of this approach would be the existence of a neighborhood even for unreliable applications. For example, at the time of handoff, USCTP packets will be redirected to the new IP of the MN. This does not require any buffering at the old base station of USCTP packets. or if it requires, the amount of data will be very small. Another important advantage is that this is a transport level solution, totally transparent to the application layer. 7.2 Security benefits We did not tried to address explicitly security issues with the proposed approach. However the adoption of SCTP has on its own some enhanced features that provide better security. The most important of them is the usage of the cookie mechanism in order to avoid blind Denial of Service (DoS) attacks [RFC2960]. More advanced security features, such as IPsec are integrated in the IPv6 protocol as header extensions, whereas Mobile IPv4 could use a separate protocol for registrations. 7.3 Binding updates optimization If there is an existing association transferring data at the time of handover, then the MN will obtain, as previously said a new IP Madisetti, Argyriou. [Page 12] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 address. However the MN does not have to send this IP address instantaneously to the home network in order to make an update. It can continue communication with the exiting association but simply adding the new IP in the association list and making it primary. When then new link is established and works properly, it can send an update to the nome network so that future requests for the MN will know its current Care-of-Address. 8. Conclusions A new protocol, VoMo, for improving performance of voice/video applications over mobile IP-based network is introduced. The idea of exploiting a Mobile Node's neighborhood in wireless network is the basis of the proposed approach. Primary goal of the protocol is the reduction of the overall delay and jitter, since these are the primary factors for the delivered QoS. We also suggested an implementation of the protocol based on the Stream Control Transmission Protocol. 9. References [RFC2960] R. R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960, November 2000. [RFC2543] M. Handley et al.,"SIP: Session Initiation Protocol", RFC 2543, March 1999. [ADDIP] R. R. Stewart, Q. Xie, M. Tuexen, I. Rytina, "SCTP Dynamic Addition of IP Addresses", , January 2002. [SCTPOVER] L. Ong, Y. Yoakum, "An Overview of the SCTP", , January 2002. [USCTP] Q. Xie et al, "SCTP Unreliable Data Mode Extension", , October 2001. [SCTPAPPL] L. Coene et al., "Stream Control Transmission Protocol Applicability Statement", , November 2001. [RFC2002] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. [MIP6] C. Perkins, "Mobility Support in IPv6", , May 2002. [ROUTEOPT] C. Perkins et al., "Route Optimization in Mobile IP", draft-ietf-mobileip-optim-11.txt, September 2001. [SIPMUL] F. Vakil et al, "Supporting Mobility for Multimedia with SIP", , Madisetti, Argyriou. [Page 13] INTERNET-DRAFT Voice & Video over mobile IP Networks Nov 2002 July 2001. [SCAMOB] Seisho Yasukawa et al, "Scalable Mobility and QoS Support Mechanism for IPv6-base Real-time Wireless Internet Traffic", in Proc of GLOBECOM '01. IEEE , 2001. [MSCTP] M. Riegel, "Mobile SCTP", , February 2002. [GPRS] Christian Bettstetter, "GSM Phase 2+ General Packet Radio Service GPRS: Architecture, Protocols, and Air Interface [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. 10. Intellectual property statement Georgia Tech may have patent rights on technology described in this document which employees of Georgia Tech contribute for use in IETF standards discussions. In relation to any IETF standard incorporating any such technology, Georgia Tech hereby agrees to license on fair, reasonable and non-discriminatory terms, based on reciprocity, any patent claims it owns covering such technology, to the extent such technology is essential to comply with such standard. 11. Authors' addresses Vijay K. Madisetti School of Electrical & Computer Engineering Georgia Institute of Technology 30332 Atlanta GA, USA e-mail: vijay.madisetti@ece.gatech.edu Antonios D. Argyriou School of Electrical & Computer Engineering Georgia Institute of Technology 30332 Atlanta GA, USA E-mail: anargyr@ece.gatech.edu This Internet Draft expires November 20, 2002. Madisetti, Argyriou. [Page 14]