Internet Engineering Task Force C. Li Internet-Draft UCLA Intended status: Informational B. Li Expires: May 9, 2013 C. Peng W. Zhang Huawei S. Lu UCLA November 5, 2012 A Multimedia Service Migration Protocol for Single User multiple Devices draft-li-avtext-service-migration-00 Abstract This document describes a new service migration protocol, which supports multimedia transfer in single-user, multiple-device scenarios. The protocol retains operations in the current client and server protocol but places new functionalities at the proxy. It also proposes novel naming and control/data plane design. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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 to cite them other than as "work in progress." This Internet-Draft will expire on May 9, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Li, et al. Expires May 9, 2013 [Page 1] Internet-Draft Multimedia Service Migration for SUMD November 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Single User Multiple Devices . . . . . . . . . . . . . . . . . 5 3.1. An Example Scenario . . . . . . . . . . . . . . . . . . . 5 3.2. System Requirements . . . . . . . . . . . . . . . . . . . 5 3.2.1. Service Delivery and Migration . . . . . . . . . . . . 6 3.2.2. namespace . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3. Backward Compatibility . . . . . . . . . . . . . . . . 6 3.3. Applications . . . . . . . . . . . . . . . . . . . . . . . 6 4. Service Migration Protocol Architecture . . . . . . . . . . . 7 4.1. SMPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. SMPA . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. SMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Control Plane . . . . . . . . . . . . . . . . . . . . 8 4.3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . 9 5. Service Migration Protocol for Video Service . . . . . . . . . 9 5.1. Best Delivery of Service . . . . . . . . . . . . . . . . . 10 5.2. Service Migration Triggers . . . . . . . . . . . . . . . . 10 5.3. How to Migrate an Ongoing Session? . . . . . . . . . . . . 10 5.4. When to Switch Service? . . . . . . . . . . . . . . . . . 11 5.5. SMP Service Procedure . . . . . . . . . . . . . . . . . . 11 5.5.1. Best Delivery of Service . . . . . . . . . . . . . . . 11 5.5.2. User-triggered Service Migration . . . . . . . . . . . 12 6. Naming and Namespace Management . . . . . . . . . . . . . . . 13 6.1. Naming Principles . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Name/ID/Locator . . . . . . . . . . . . . . . . . . . 13 6.1.2. 2D Name Mapping . . . . . . . . . . . . . . . . . . . 13 6.2. Namespace Management . . . . . . . . . . . . . . . . . . . 14 6.2.1. Service Registration . . . . . . . . . . . . . . . . . 14 6.2.2. User and Device Introduction . . . . . . . . . . . . . 14 6.2.3. Namespace State Synchronization . . . . . . . . . . . 15 6.2.4. Mobility Management . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Li, et al. Expires May 9, 2013 [Page 2] Internet-Draft Multimedia Service Migration for SUMD November 2012 1. Introduction In recent years, it has become the norm rather than exception that an individual user has multiple devices with networking capabilities. In an example scenario, a user owns a laptop in the office, a desktop at home, while carrying an iPhone or iPad wherever (s)he goes. This emerging single-user, multi-device setting opens new venue for networking protocol design and operations. There are two main challenges for associated network design. First, the protocol operations should support new data communication patterns for multiple devices of the same user. Data sessions should seamlessly migrate among the devices owned by the same user, or simultaneously multicast to these devices. For example, as friends of the given user want to share video clips with him, he can directly use his office desktop when still in office. However, as he walks out for lunch, he may proceed the ongoing video session via his iPhone or iPad. Second, users should continue to run legacy networking protocols (particularly those at the transport layer or above) and applications with minimal changes while supporting the notion of single-user, multi-device during data communication. This will enable reuse of most current Internet applications. Many existing protocols can achieve one of these two goals, but not both. In this document, we describe a novel solution, called Service Migration Protocol (SMP), which supports "single-user, multi-device" multimedia communications. Data sessions are grouped by the user and can seamlessly migrate among devices belonging to the same user. A key innovation in SMP is the proxy that bridges the client and the server in the current client-server communication paradigm. The proxy offers two critical services of naming and session/data transfer. By carefully designing the functions of the proxy, SMP is able to reuse existing protocol operations at both the client and the server without modifications. 2. Terminology This document uses the following terms to refer to the entities or functions that are required in service migration protocol. User Name (UN): A name that can be used to identify a user at the application layer. Device Name (DN): A name that can be used to identify a device at the application layer. Li, et al. Expires May 9, 2013 [Page 3] Internet-Draft Multimedia Service Migration for SUMD November 2012 User Identifier (UID): A stable value that can be used to identify a user. Any unique value can be used as an identifier as long as it is device independent, i.e., unchanged among all devices owned by the user. Device Identifier (DID): A stable value that can be used to identify a mobile device. Any unique value can be used as an identifier as long as it is topologically and geographically independent, i.e., remains unchanged when the mobile device roams around. Locator: The IP address that indicates the mobile device's current attachment point to the Internet. It could be the IP address of the mobile device itself or the IP address of the network entity that is currently serving the mobile device. Mapping: In this document, mapping specifically means the mapping between a name and an identifier, a user identifier and a device identifier(s), or a device identifier and its Locator. Namespace: In this document, namespace specifically means the set that includes names, IDs, Locators and mappings, as well as the information of users and devices. Service Identifier (SID): A value that can be used to identify an ongoing service. Service Migration Protocol (SMP): A protocol that can be used to migrate an ongoing service from one device to another. Both belong to the same owner. Service Migration Protocol Server (SMPS): A system that maintains a global namespace, thus performing namespace management and namespace resolution. Service Migration Protocol Proxy (SMPP): A system that is interposed between the server and the client to support SMP by coordinating control signaling and data forwarding. Service Migration Protocol Application (SMPA): An application that is installed on each SMP-enabled device. Migration From Request (MFR): A control message that is used to issue the request of service migration by the originator device. Migration To Request (MTR): A control message that is used to inform the target device regarding the request of service migration. Li, et al. Expires May 9, 2013 [Page 4] Internet-Draft Multimedia Service Migration for SUMD November 2012 Video Sharing Request (VSR): A control message that is used to share a video clip with a user or a device by the originator user. 3. Single User Multiple Devices This section describes an example scenario of single-user, multi- device, the requirements for our design, and the applications to which our protocol can be applicable. 3.1. An Example Scenario Alice wants to share a video clip in real time with her friend Bob over the network, after taking a video clip by herself or having found an interesting one on YouTube. Bob has multiple devices including a smartphone, an office laptop, and a home desktop. Alice clicks the "Share video" button and selects Bob's name from her contact list. The request message of sharing video is sent over the network. The video is then delivered to the most appropriate device of Bob's at the time. Initially, the video is sent to the office laptop while Bob is in the office. Upon receiving the Alice's request, Bob clicks the "Accept" button to receive the video. As Bob heads to home 10 minutes later, the video is delivered to his Smartphone. After arriving at home, Bob decides to switch the video sharing to his home desktop. The video service is smoothly switched from one device to another so that Bob can watch uninterrupted video among his multiple devices, each of which is the most appropriate one for each different scenario. 3.2. System Requirements In the above scenario, we need to address the following three technical issues. o How to deliver the shared video content to the most appropriate device of the given user? o How to migrate an ongoing session from one device to another? o How should the namespace be designed so that our protocol can support the single-user, multi-device scenario, and each user can manage his/her multiple devices and social network to his/her convenience? The requirements of our design are described in three aspects. The first two aspects are to address the above issues, whereas the last one is considered for easy deployment. Li, et al. Expires May 9, 2013 [Page 5] Internet-Draft Multimedia Service Migration for SUMD November 2012 3.2.1. Service Delivery and Migration To find and locate one's most appropriate device for a given situation and then deliver video content to it, the system needs to retain the ranking of preferred device(s) by each user, as well as the status and the locator of each device. Moreover, devices belonging to one user may access the network and be online once at a time or simultaneously. Therefore, in addition to unicast communication, anycast, multicast, and broadcast also need to be supported. The anycast mode allows service to be sent to the nearest one or the best one among devices of the user's, whereas multicast and broadcast modes enable the system to deliver service to a subset and all devices of the user's, respectively. It should also consider both the control plane and the data plane. The former defines all signaling functions including migration triggers, the discovery of one's best device and the device to which service is migrated, and service transfer. The latter handles migration delay and possible transient loss during service migration. 3.2.2. namespace The namespace should consider the identities of both the user and the devices, and provide mapping service that maps one user to multiple devices and associates each device to its locator. Although the IP address acts as both identity and locator, these two roles should be decoupled in order to prevent long-term usage identity from changing with transient locator. Therefore, the namespace design should be based on the Identity/Locator split approach. In addition to the identities, the namespace also needs to provide human-readable names for both user and device entities so that each user can conveniently manage his/her devices and contact lists. 3.2.3. Backward Compatibility For easy deployment, our design should avoid modifying existing protocols and applications as much as possible. 3.3. Applications Our design is applicable to various multimedia applications, which provide either open-source support or developer API and are able to run on multiple platforms. One such an application is VLC [VLC], which is an open-source cross-platform multimedia framework and supports most platforms. It allows for users to share video clips with each other. The VLC media player is a complete video solution, which is a player, a live transcoder and a streamer. It thus allows for users to readily share video clips with each other. Li, et al. Expires May 9, 2013 [Page 6] Internet-Draft Multimedia Service Migration for SUMD November 2012 Two other applications are Qik [Qik] and YouTube [YouTube]. Qik, which supports live video sharing and two-way live video chats, enables developers to integrate it with its API. YouTube, a popular video-sharing application, offers plenty of APIs and allows for developers to incorporate its functionality into their applications. 4. Service Migration Protocol Architecture +------------------------+ +------------------------------+ | SMP Server | | SMP-enable Device | | +--------------------+ | | +--------------------------+ | | | DataBase | | | | SMP Application | | | | (Global Namespace) | | | | +----------------------+ | | | +--------------------+ | | | | User Interface | | | | | | +--------------+ | | | | (Namespace Group) | | | | | | | Namespace |-+---+ | | +----------------------+ | | | | |--| Management | | | | | +-----------------+ | | | | | +--------------+ | +---+-+-| Namespace Sync | | | | | | +---------------+ | | | | Module |---| | | | | | Resolution | | | | +-----------------+ | | | | | | Service Module| | | | +-----------------+ | | | | | | +-----------+ | | | | | SMP Service | | | | | |-----| ID/Locator| |-+--+ +--+-+-| Module |---| | | | | | +-----------+ | | | | | | +--------+--------+ | | | | | +-----------+ | | | | | +----------|---------------+ | | |-----| User | | | | | | | | | | | Preference| | | | | | +----------+---------------+ | | | +-----------+ | | | | | | Video Application | | | +---------------+ | | | | +----------+---------------+ | +------------------------+ | | +------------+-----------------+ | | | +-------------------+-+---------------+---------+ | SMP +----------+-+--+ +--------+-------+ | | Proxy | Control Plane |---| Data Plane | | | +---------------+ +----------------+ | +-----------------------------------------------+ Figure 1: SMP Architecture. We devise a proxy-based solution, in which a proxy mediates video service between two ends, to achieve best service delivery and service migration without modification of existing protocols and applications. As shown in Figure 1, the architecture of service migration protocol (SMP) consists of three major components: SMP Li, et al. Expires May 9, 2013 [Page 7] Internet-Draft Multimedia Service Migration for SUMD November 2012 Server (SMPS), SMP Application (SMPA), and SMP Proxy (SMPP). SMPS performs namespace management and resolution service by maintaining a global namespace database. SMPA is installed on each SMP-enabled device with two modules, namespace sync and SMP service modules, to manage the owner's namespace group and enable SMP service. SMPP, which is interposed between the video server and the client application, bridges video service and manages service delivery and migration. 4.1. SMPS SMPS maintains a database of the global namespace with the namespace management module, which manages user registration, user and device introduction, and namespace synchronization. The first two functions are used by a user to construct his/her namespace group, which includes his/her own devices, friends and friends' devices. The last function keeps the global namespace and each namespace group synchronized. Based on the database, SMPS provides two resolution services, ID/Locator and user preference, which can resolve a device's locator and the most appropriate device(s) of a user. 4.2. SMPA SMPA, which should be installed on each SMP-enabled device, provides users an interface with a contact list and functions of the SMP service. The contact list enables the owner to manage his/her namespace group and to select a friend or a device to use the SMP service. The namespace group is maintained by the namespace sync module, which collaborates with the namespace management module at SMPS. The SMP functions are done in the SMP service module, which issues and accepts the requests for the SMP service through SMPP and interacts with the video application. 4.3. SMPP SMPP consists of two planes, the control plane and the data plane. The former manages signaling of video sharing and service migration, whereas the latter bridges video sessions and keeps sessions uninterrupted during service migration. 4.3.1. Control Plane It completes the signaling of video sharing and coordinates the operation of service migration. Upon receiving each request, it finds and locates the target device using the SMPS resolution service. For video sharing, it then informs the device's SMPA of the sharing request through its SMP service module. For service migration, it then asks the SMPA to prepare for the migrated service Li, et al. Expires May 9, 2013 [Page 8] Internet-Draft Multimedia Service Migration for SUMD November 2012 through the same module, and regulates the behavior of the data plane through its update module to switch the service to the target. 4.3.2. Data Plane It acts as the bridge between two ends of each session by relaying packets from one end to the other based on the forwarding table. When the video application requests a video service through SMPP, it will receive the service on behalf of the application. Once a video session is set up, a new entry will be created for the session on the forwarding table. Each forwarding entry includes the video information and the related addresses of the server, SMPP and the client, so that it can bridge the corresponding session by modifying the addresses of its packets and forwarding them. To support service migration, the update module is provided to update a session's forwarding entry while it is ongoing. 5. Service Migration Protocol for Video Service SMP seeks to deliver service to one's most appropriate device(s) during service initialization and perform service migration among devices. To this end, we need to address the following four issues. o How can one's most appropriate device(s) be enabled to receive the shared video? o When and how will service migration be triggered? o How can an ongoing session be migrated? o What is the timing for switching service from the old device to the new one? Before addressing these issues, we introduce four control messages, which are sent via HTTP or directly over TCP connections: Video Sharing Request (VSR), SMP Resolution Request (SRR), Migration From Request (MFR) and Migration To Request (MTR). VSR is used by the SMP service module when a user intends to share a video clip with another, so it should include a video URL and a sharing target, which can be either the user identity (UID) or the device identity (DID). We will elaborate on the namespace design in the next section. The SMPP control plane uses SRR to resolve a device's locator or a user's preferred device(s) through the SMPS resolution service by attaching either a DID or a UID. The SMP service module employs MFR to request the migration of one of its ongoing sessions, whereas the SMPP control plane uses MTR to request for the target device's SMPA to prepare for receiving a migrated session. Both MFR and MTR contain Li, et al. Expires May 9, 2013 [Page 9] Internet-Draft Multimedia Service Migration for SUMD November 2012 the information of the migrated service and the target device. 5.1. Best Delivery of Service Upon receiving a VSR message, the SMPP control plane finds and locates the target devices using SRR messages through the SMPS resolution service, and then forwards the VSR to them. If a DID is provided in the VSR, the control plane will resolve the device's Locator. If only a UID is attached, it obtains a list of the user's preferred devices, and then resolves their CoAs. After locating all target devices, it forwards the VSR to them. For each device where the request is accepted, the SMP service module at its SMPA invokes the video application to connect to SMPP with the input of a service identity (SID), which is the concatenation of the device's DID and the shared video URL. Each SID, which is globally unique, is used to identify an ongoing service. The SMPP data plane subsequently obtains the video URL from the SID and requests the video service on behalf of the application. 5.2. Service Migration Triggers Service migration can be triggered by either the user or the network. For the user-triggered mode, each user requests service migration through issuing a command on the SMPA user interface. The command requires the user to select an ongoing service and the target device to which the service is migrated. The SMP service module then sends a MFR message to SMPP to trigger migration. For the network- triggered mode, the SMPP data plane monitors the reception quality feedback of each session, and triggers service migration if a specified threshold is reached. We here consider the video service delivered within RTP sessions, so it continually examines the receiver reports carried in each session's RTCP packets to see whether the fraction of the lost RTP packets exceeds the threshold. Whenever detected, its service migration is triggered on the control plane, the corresponding device will be notified, and its SMPA will then send a MFR to SMPP after its owner's confirmation. 5.3. How to Migrate an Ongoing Session? After a migration is triggered by the user or the network, the control plane asks the new device to prepare for service reception, and then switches the service from the old device to the new one. With the DID in MFR, it uses a SRR to resolves the new device's Locator, and sends a MTR with the migrated session's SID to its SMPA. The SMP service module then invokes the device's video application with a temporary SID, which is the concatenation of the old SID and the device's DID, to connect to SMPP. This indicates that the application needs to obtain the session description to set up a Li, et al. Expires May 9, 2013 [Page 10] Internet-Draft Multimedia Service Migration for SUMD November 2012 session. SMPP always caches the session description of each ongoing session so that it can respond a new version description with some necessary changes to it. Based on the temporary SID, the data plane updates the migration information, which includes a new SID and the new device's DID and address, to its update module. The new SID can be generated by excluding the old device's DID from the temporary SID. At the end, the update module commits this update into the forwarding table based on the rules on when to switch service. 5.4. When to Switch Service? The timing for switching a service to the new device by committing the update information into its forwarding entry depends on the service type. We consider only the MPEG4-encoded video services in this work, but the design can be easily applied to other video formats in the same manner. Based on the characteristics of MPEG4 video, a large portion of packets cannot be successfully decoded without their adjacent packets. Its video content is partitioned into multiple groups, each of which is a Group of Pictures (GOP) and can be decoded individually. Each GOP has three types of frame: I-frame, P-frame and B-frame. Each frame is composed of multiple packets. An I-frame starts a GOP and does not depend on any frame, whereas P-frame and B-frame, both of which depend on others, follow it. To minimize transient frame loss, the timing of switching service should be right before the first packet of a GOP; otherwise, the new device would not be able to decode the first GOP it receives. Once the data plane gets a session's update, it starts to monitor its data packets until the update is committed. Upon receiving the first packet of the followup GOP, it commits the update into the forwarding table and the session's data packets start to be forwarded to the new device. 5.5. SMP Service Procedure This section contains the procedure of the SMP service. 5.5.1. Best Delivery of Service In Figure 2, Alice wants to share a video clip with Bob by clicking "Share video" button, selecting "Bob" from her contact list and inputting the video's URL on her laptop's SMPA. This video service can be provided by the video server at her laptop or other service sources. Her laptop's SMPA sends a VSR to SMPP after receiving the command, and then SMPP discovers the Bob's most appropriate device at the time using a SRR through SMPS. The VSR is then forwarded to the SMPA at Bob's office laptop, which has the highest priority during daytime and remains online. A confirmation is then shown on his laptop's SMPA. After Bob clicks its "Accept" button, SMPA invokes Li, et al. Expires May 9, 2013 [Page 11] Internet-Draft Multimedia Service Migration for SUMD November 2012 the video application to connect to SMPP. SMPP then requests the video and bridges the corresponding session. +--------+ +--------+ | Alice | | Bob | +-+------+ +------+-+ |(1) (5)(9)| | +------------+ +----------------+ | | | Laptop | | Phone | | | | +--------+ | (2)VSR (12)MTR | +------------+ | | |--+>| SMPA |-+----- |-------------+>| SMPA | | | | +--------+ | | | | +-----+------+ | | | +--------+ | | | | |(13) | | | | Video | | | | | +-----+------+ | | | | Server |-+--| | | (14) | | Video | | | | +--------+ | | | | |-----------+-| Application| | | +------------+ | | | | | +------------+ | | | | | | +----------------+ | (8)| | | | +----------------+ | | \ | | | Laptop | | +--------+ +--------+ (4)VSR | +------------+ | | | | SRR | |----------+>| SMPA |<+--| | SMPS |<------>| SMPP |<---------+-+-----+------+ | | | (3)(11)| | (10)MFR | |(6) | +--------+ +--------+ | +-----+------+ | | | | Video | | |--------------+-| Application| | (7) | +------------+ | +----------------+ Figure 2: SMP Service Procedure. 5.5.2. User-triggered Service Migration Before leaving the office, Bob wants to switch the video service from his laptop to his phone. From Step 9 in Figure 2, he clicks "Service Migration" button, selects his phone from his contact list and selects this ongoing service on SMPA. SMPA then sends a MFR with the service's SID to SMPP. In turn, SMPP locates Bob's phone using a SRR through SMPS, and sends a MTR to the phone's SMPA. Upon receiving this request, the SMPA invokes the video application to connect to SMPP. The service will be switched to the phone after certain latency and the session of the laptop's application is halted. Li, et al. Expires May 9, 2013 [Page 12] Internet-Draft Multimedia Service Migration for SUMD November 2012 6. Naming and Namespace Management In this section, we introduce the namespace design in SMP and several basic management functions. 6.1. Naming Principles The namespace is designed by both taking the ID/Locator split approach and meeting the requirements of the single-user, multi- device scenario. We organize it into three layers: Name, ID, and Locator. They are joined with two-dimensional (2D) mapping: Name to ID to Locator, User ID (UID) to Device IDs (DIDs). 6.1.1. Name/ID/Locator The SMP system maintains a namespace group for each user, based on which the contact list in the SMPAs at his/her devices is kept. In the contact list, friends (users) and devices are recognized via user names (UNs) and device names (DNs), respectively. In each namespace group, the names, which are changeable and human-readable, are assigned by its owner. The UN of each friend should be unique and the DN of each device needs to be unique in its owner's device set. Two identities, UID and DID, are introduced to identify the user and the device, respectively. DID substitutes for the identity role of IP address so that the IP address only serves as the locator. Both UID and DID are globally unique and persistent. The email address used to register the SMP system by each user is considered as his/her UID. A device's DID, which is represented in the DNS-like dotted notation, is generated by combining its owner's UID with its name that is initially specified by its owner. The initial device name has to be unique in the owner's device set so that DID can ensure global uniqueness with UID. For example, Bob registers his UID as bob@ucla.edu and the DID of his laptop, named laptop at its registration, would be laptop.bob@ucla.edu. 6.1.2. 2D Name Mapping Each locally unique UN or DN is associated with a globally unique UID or DID, respectively. Each DID is mapped to its care-of IP address (CoA). The former mapping is maintained in each namespace group, whereas the latter is managed in the global namespace at SMPS. Devices can discover each other with the peer's DID through the DNS- like resolution service at SMPS. Another dimension of the mapping is between a UID and (multi-)DID as a user may own multiple devices. It can be done by the identity itself because each DID contains its owner's UID. Li, et al. Expires May 9, 2013 [Page 13] Internet-Draft Multimedia Service Migration for SUMD November 2012 6.2. Namespace Management Each user has a namespace group in the SMPAs of his/her devices, in which (s)he manages his/her own devices and keeps the information of his/her friends and their devices. SMPS manages the global namespace, which contains all namespace groups and the preference setting of each user, as well as both the CoA and the status of each device. A user's preference setting is the ranking of preferred device(s) by the user for different scenarios, whereas a device's status can be online, offline, busy or away. A namespace group is constructed mainly via two functions: service registration, and user and device introduction. In order to keep the global namespace to be consistent with each namespace group, the functions of namespace state synchronization and mobility management are introduced. These four functions are supported by the collaboration between the namespace sync module at SMPA and the namespace management module at SMPS. 6.2.1. Service Registration Each user needs to register the SMP system with his/her email through an installed SMPA at any of his/her devices before using SMP service. His/her namespace group will then be created, which initially contains only the information of the device used for registration. 6.2.2. User and Device Introduction In the SMP system, users or devices can introduce with each other using two schemes: Local Rendezvous and Centralized Coordination. The owner(s) of two devices can connect both of them to a shared local wireless network such as WiFi or Bluetooth, and apply the local rendezvous scheme in SMPA, which is similar to Apple's Bonjour [Bonjour], to find each other. One end initializes the introduction process and the other acknowledges the request. If both of them belong to the same owner, one of the devices should be newly introduced and will thus be added into the owner's personal namespace. Then, each namespace group with this personal namespace will also be updated. However, if their owners are different, through user introduction, each user's personal namespace will be inserted into the other's namespace group. The medium used for local rendezvous is not limited to WiFi or Bluetooth, since E-mail and SMS are also applicable. User and device introduction can also be done by issuing requests through the SMPS coordination. In the former, either of two ends issues a request to SMPS through SMPA at one of his/her devices, and this request will be subsequently sent to the SMPAs at all other devices. S(he) can confirm it on any device. In the latter, a user Li, et al. Expires May 9, 2013 [Page 14] Internet-Draft Multimedia Service Migration for SUMD November 2012 can issue requests directly to SMPS through any of his/her online devices. 6.2.3. Namespace State Synchronization SMPA uses periodic heartbeat messages to maintain its device's status and employs the latest modification timestamp to check whether it should synchronize its namespace with SMPS or not. SMPS responds to each heartbeat message with the information of all changes on the devices' status in the SMPA's namespace group. SMPA then updates these changes in its contact list. When SMPS detects the loss of several consecutive heartbeat messages within certain time period, the device's status will become off-line. To reduce the overhead of namespace synchronization, only the latest modification timestamp of the SMPA's namespace group is included in the heartbeat messages. If it is different from the timestamp in the SMPS database, SMPA will synchronize its namespace group with SMPS. The fact that many modifications may happen after the latest synchronization may result in namespace conflicts between SMPS and SMPA. We make each of SMPS and SMPA keep all the logs of its modifications. They can obtain the updated information by reorganizing the updates and applying them in time order. After resolving conflicts, they update the current time to their latest modification timestamp. 6.2.4. Mobility Management The namespace sync module at SMPA continually monitors the change of its device's CoA. Upon detection, the new CoA will be immediately updated to the global namespace database through the namespace management module at SMPS. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations The security aspects of the proxy-based applications also apply to this memo. TBC. 9. Informative References [Bonjour] "Apple computer, inc. Bonjour", . Li, et al. Expires May 9, 2013 [Page 15] Internet-Draft Multimedia Service Migration for SUMD November 2012 [Qik] "Qik: an application for instant video sharing", . [VLC] "VLC: an open source multimedia solution", . [YouTube] "Youtube", . Authors' Addresses Chi-Yu Li UCLA 4681 Boelter Hall Los Angeles, CA 90095 USA Phone: +1 323 528 1039 Email: lichiyu@cs.ucla.edu Bojie Li Huawei Shenzhen, P.R.C. Phone: +86 755 2878 0808 Email: libojie@huawei.com Chenghui Peng Huawei Shenzhen, P.R.C. Phone: +86 755 2878 0808 Email: pengchenghui@huawei.com Wei Zhang Huawei Shenzhen, P.R.C. Phone: +86 755 2878 0808 Email: wendy.zhangwei@huawei.com Li, et al. Expires May 9, 2013 [Page 16] Internet-Draft Multimedia Service Migration for SUMD November 2012 Songwu Lu UCLA 4731C Boelter Hall Los Angeles, CA 90095 USA Phone: +1 310 794 9289 Email: slu@cs.ucla.edu Li, et al. Expires May 9, 2013 [Page 17]