Internet DRAFT - draft-li-avtext-service-migration
draft-li-avtext-service-migration
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",
<http://developer.apple.com/networking/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",
<http://qik.com>.
[VLC] "VLC: an open source multimedia solution",
<http://www.videolan.org>.
[YouTube] "Youtube", <http://www.youtube.com>.
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]
