Network Working Group Hongluan.Liao Internet Draft Jin.Peng Intended status: Standards Track China Mobile Expires: April 23, 2011 Zhenyu.Yu Yiwen.Wang BUPT October 24, 2010 A RELOAD Usage for Distributed Conference Media Processing draft-liao-p2psip-dcmp-01 Status of this Memo This Internet-Draft is submitted 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 April 23, 2011. Copyright Notice Copyright (c) 2010 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 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. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. liao Expires April 23, 2011 [Page 1] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 Abstract This document proposes a RELOAD Usage for Distributed Conference Platform which can support a lot of meetings simultaneously. It designs a new distributed conference architecture. In this architecture the component called MCS is responsible for the process of media data including audio and video. Some conference UEs which have enough bandwidth or other conditions could also undertake parts of media data process. All the MCSs form the reload overlay. The capacity and state information of conference UEs is stored in the RELOAD overlay. One or several MCSs will be selected to provide media process for a meeting and these MCSs process all the transcoding and transmission of audio and video data, and decide which media process task could be assigned to Conference UEs. Table of Contents 1. Introduction ................................................. 3 2. Terminology .................................................. 3 3. System overview .............................................. 4 3.1. Architecture ............................................ 4 3.2. Entities ................................................ 5 3.2.1. CCS (Conference Control Server) .................... 5 3.2.2. CDB (Conference Database) .......................... 5 3.2.3. MCS (Media Control Server) ......................... 5 3.2.4. UE (User Equipment) ................................ 6 3.3. Kind data structure ..................................... 6 4. Scenario and procedure ....................................... 8 4.1. Create a conference ..................................... 8 4.2. Participate in a conference ............................. 8 4.3. Leave a conference ..................................... 10 4.4. State measurement and reporting ........................ 10 5. Media Process Mechanism ..................................... 12 5.1. Audio Stream Process ................................... 12 5.1.1. Audio Mixer Selection ............................. 12 5.1.2. Audio Mixer Transmission .......................... 14 5.2. Video Stream Process ................................... 14 5.2.1. Video Stream Transmission ......................... 14 5.2.2. Video Stream Delivery ............................. 17 5.2.3. Video Stream Mixture .............................. 18 5.2.4. Video Stream Transmission Switch .................. 18 6. Kind Definition ............................................. 18 7. Security Considerations ..................................... 18 8. IANA Considerations ......................................... 19 9. References .................................................. 19 9.1. Normative References ................................... 19 liao Expires April 23, 2011 [Page 2] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 10. Acknowledgments ............................................ 19 1. Introduction In traditional video conference architecture, performance and capacity of single server is limited. It can only support a certain number of online users simultaneously. Large scale conference systems need to deploy a lot of servers to process audio and video data, this point would be the bottleneck. As the network environment and hardware ability of UEs become better and better, so making full use of the ability of UEs to help processing parts of media data is very useful. In this draft, the video conference platform is suitable for the following scenario. This platform could be run by operator and support many meetings simultaneously; for a single meeting the number of participants is relatively small. Considering the above scenario, the scheme of traditional video conference system need deploy many servers to process media data, a very high cost. Therefore, we introduced the Distributed Conference Media Processing. On the basis of traditional software video conferencing, our project makes full use of UEs to undertake parts of the task of audio and video processing to reduce the server bandwidth and hardware resources cost. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. The terminology and definitions from the RELOAD base[I-D.ietf-p2psip- base], the peer-to-peer SIP concepts draft[I-D.ietf-p2psip-concepts]. MCS: Media Control Server is responsible for the process of media data including transmission or transcoding all the MCS constitute a Reload overlay. The capacity and state information of conference UEs is stored in the RELOAD overlay. UE: User Equipment can execute the conference operation as a client. liao Expires April 23, 2011 [Page 3] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 CCS: Conference Control Server mainly handle UE online state and other conference functions such as instant message and it will assigns suitable MCS to UE when they join a conference. CDB: Conference Database mainly maintains static User and conference information. Owner MCS: Owner MCS stores conference information in the RELOAD overlay. Service MCS: CCS assigns one Service MCS to every UE, which is responsible for handling the UE's media request. 3. System overview 3.1. Architecture This section defines the overall architecture and the main functions of each entity. Figure 1 depicts the network architecture based on Reload overlay which consists of a set of cooperating peers. The main functions of the core network are provided by the overlay in which the peers can efficiently route messages to other peers and efficiently store and retrieve conference information. +-----+ | UE1 |# +-----+ # @ # @ # @ # ******** ******** # * MCS4 *--------* MCS1 * # ******** ******** # | | +-----+ +-----+ +-----+ | Reload | | UE2 |# # # # | CCS |-----| CDB | | | @+-----+ +-----+ +-----+ ******** ******** @ # * MCS3 *--------* MCS2 * @ # ******** ******** # @ # @ # @ # +-----+ # | UE3 | +-----+ Figure 1 Distributed Conference Architecture liao Expires April 23, 2011 [Page 4] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 CCS and CDB is the system manager, and CDB is a centralized user database. MCS is a media processing server. Each MCS is a peer in the Reload overlay, and the capacity and state information of conference UEs is the resources. Each UE is a client in the reload overlay. In addition, UE in different network may be assigned to different MCS to access. The MCSs will be deployed in different networks too, So that the system will choose a proximal MCS for the UEs to process their media data. 3.2. Entities The following part includes a description of each major functional entity in distributed video conference system, and a brief introduction of each entity's behaviors and interactions with other entities. 3.2.1. CCS (Conference Control Server) According to the scale of UE, there may be several CCS servers in the conference system. The main functions include: o Responsibility for authorization and maintaining online information of UE; o UE Management of participating in a conference. 3.2.2. CDB (Conference Database) There is only one CDB in system. The main functions may include: o Store and maintain conference and UE static information; o IP address and location information of MCS in the system o Accept request from CCS and return the relative data to MCS; 3.2.3. MCS (Media Control Server) According to the scale of UEs, there may be many MCS in system. The main functions may include: o Receive audio and video data from UEs, and transmit it to other UE who send a request. liao Expires April 23, 2011 [Page 5] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 o Based on requirement mix the audio and video streaming or convert BitRate; o Maintain and manage capability and state information of UEs in a conference, and execute distributed algorithm; o Every MCS have only one identity and adopt Reload protocol to look up each other. 3.2.4. UE (User Equipment) UE include the types of PC, mobile telephone, Set-Top Box, MID, etc. The main functions may include: o Initialization, join, exit and other operation about a conference; o Receive and send audio and video data. o Some UEs may be selected by MCSs to undertake the tasks of transmit media data. 3.3. Kind data structure Each DcmpRegistration data structure stores each UE the related performance parameter and which MCS is service for this UE. The data structure uses the RELOAD dictionary type whereas the Dictionary Key- value is the Node-ID behind the dictionary entry. The data structure of type DcmpRegistration is shown as follows: struct { DictionaryKey UE_ID; DataValue delay; } DictionaryEntry; struct { opaque UE_CPU <0..2^16-1>; opaque UE_Memory <0..2^16-1>; opaque UE_UpBW <0..2^16-1>; liao Expires April 23, 2011 [Page 6] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 opaque UE_DownBW <0..2^16-1>; opaque UE_BitRate <0..2^16-1>; DictionaryEntry UE_delay; } Performance; struct { uint16 length; uint128 MCS_ID; bool flag; Performance performance_data; } DcmpRegistration; The content of the DcmpRegistration structure are as follows: length the length of the registration PDU MCS_ID MCS serviced for this UE flag mark of whether UE assume the task of media processing performance_data performance parameter about this UE. Performance_data define as follows: o Assume that a conference has n UEs, each UE is numbered from 1 to n; the CPU capacity of each UE is defined as UE_CPU, memory capacity is defined as UE_Memory, upload bandwidth is defined as UE_UpBW, download bandwidth is defined as UE_DownBW, video bit rate is defined as UE_BitRate; liao Expires April 23, 2011 [Page 7] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 o Delay between itself and other UE in the same conference is defined as UE_delay; Data stored in this structure is used for optimizing media transmission. 4. Scenario and procedure 4.1. Create a conference This scenario will describe UE how to create a conference. UE1 CCS CDB -------------------------------- |conference | | | creation | | |~~~~~~~~~> | | | save information | |~~~~~~~~~> | | | ACK | | |<~~~~~~~~~ | | ACK | | |<~~~~~~~~~ | | | | | Figure 2 Creation a conference UE1 set the conference name, type, the number of participant and other information, then sent conference creation request to the CCS; In this procedure, CDB just store the attribute of the conference. When new entrant comes CCS stores the additional information in CDB. See more in 4.2. 4.2. Participate in a conference In this scenario, UE1 will participate in an existing conference. liao Expires April 23, 2011 [Page 8] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 Other UE1 CCS CDB MCS1 overlay MCS0 UE --------------------------------------------------------------------- | join | | | | | | |~~~~~~~~> | | | | | | | get information | | | | | |~~~~~~~~> | | | | | | Conference information | | | | | |<~~~~~~~~ | | | | | | save information | | | | | |~~~~~~~~> | | | | | |assign MCS| | | | | | |<~~~~~~~~ | | | | | | | | | UE1 online notice | | | | ~~~~~~~~ | ~~~~~~~~ | ~~~~~~~~ | ~~~~~~~~ | ~~~~~> | | |AppAttach | | | | | |<-------- |--------- |--------> | | | | +- |----+ | | | | | | |Measure| | | | | | | +- |----+ | | | | | | | | StoreReq | | | | | |--------- |--------- |--------> | | | | | | | | StoreReq | | | | | | |--------> | | | | | | | | StoreReq | | | | | | |--------> | | | | | | | StoreAns | | | | | | |<-------- | | | | | | StoreAns | | | | | | |<-------- | | | | | StoreAns | | | | | |<-------- |--------- |--------- | | | | | | | | | | | Figure 3 Participate in a conference UE1 sent the join request to CCS. The request should contain the conference ID. CCS takes the conference ID as keyword to request the relative data from CDB. According to the information returned by the CDB, CCS will choose a proper MCS as UE's service MCS based on geographical information. Then CCS update the relative information, including the MCS that service for the same conference and the number of UE serviced by each MCS, also including UEs that has joined in the same conference. UE1 receive the assignment result, and then establishes a connection with service node using AppAttach. At the same time, UE measure liao Expires April 23, 2011 [Page 9] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 performance parameter and store the initial DcmpRegistration to the overlay. 4.3. Leave a conference In this scenario, UE1 will exit from a conference. UE1 CCS CDB MCS1 overlay MCS0 ------------------------------------------------------------- | | | | | | | | StoreReq | | | | |--------- |--------- |--------> | | | | | | | StoreReq | | | | | |--------> | | | | | | | StoreReq | | | | | |--------> | | | | | | StoreAns | | | | | |<-------- | | | | | StoreAns | | | | | |<-------- | | | | StoreAns | | | | |<-------- |--------- |--------- | | | | leave | | | | | |~~~~~~~~> | | | | | | delete information | | | | |~~~~~~~~> | | | | | | ACK | | | | | |<~~~~~~~~ | | | | | ACK | | | | | |<~~~~~~~~ | | | | | | | | | | | Figure 4 Departure form a conference When UE1 exit from conference, it must delete the relative item stored in overlay and CDB server. 4.4. State measurement and reporting liao Expires April 23, 2011 [Page 10] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 UE2 MCS2 MCS0 overlay UE1 UE3 --------------------------------------------------------------- | | | | | | | FetchReq | | | | | |--------> | | | | | | | FetchReq | | | | | |--------> | | | | | | FetchAns | | | | | |<-------- | | | | | | | | | | | FetchAns | | | | | |<-------- | | | | | | | | | | | +-- |---+ | | | | | |Measure| | | | | | +-- |---+ | | | | | | | | | | | | | Measure | | | |<~~~~~~~~ |~~~~~~~~~ |~~~~~~~~~ |~~~~~~~~> | | | | | Measure | | | |<~~~~~~~~ |~~~~~~~~~ |~~~~~~~~~ |~~~~~~~~~ |~~~~~~~~> | | StoreReq | | | | | |--------> | | | | | | | StoreReq | | | | | |--------> | | | | | | StoreAns | | | | | |<-------- | | | | | StoreAns | | | | | |<-------- | | | | | | | | | | | Figure 5 Measure and report In this scene assuming that UE1 and UE3 have already joined in the meeting UE2 is a new entrant and its service MCS is MCS2. UE2 get the UE list of the same conference and need to detect its own status and measure the delay between other UE and itself, and then stored them in the overlay in DcmpRegistration. UE2 will detect its own state parameters including: CPU capacity is defined as UECPU, the memory capacity is defined as UEMemory, uplaod bandwidth is defined as UEUpBW, the download bandwidth is defined as UEDownBW, video bit rate is defined as the UE_BitRate(bit) delay between itself and other UEs: UEDelay (UE2, UE1), UEDelay (UE2, UE3). UEs which have joined in a meeting need to detect some parameters When new UE join or detect periodically. liao Expires April 23, 2011 [Page 11] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 5. Media Process Mechanism This section describes the handling mechanism of audio and video stream data in the distributed conference platform. 5.1. Audio Stream Process 5.1.1. Audio Mixer Selection In the distributed conference platform, audio streams of UEs could be mixed together and then transmitted to each UE This is called audio mixing mode which is optional. For the mode in which the audio streams are not mixed will not be considered in current version. The following part of this section will focus on the mechanism of audio mixing mode. If capable UEs exist, one of them will be selected to mix the audio streams. The solution of Choosing Several UEs could be considered, but it is beyond the scope of current version. The MCS server assigned to UE who is the first to join the conference will be responsible for the decision of UE selection. The determination should incorporate with bandwidth, chip ability and other conditions. If there is no suitable UE to be selected The MCS server will be responsible for audio mixing itself. When the mixing node failed for some reasons, the MCS server will take over the task or choose new UE to do the job. As an example, Figure 6 showed the audio-mixing node selection procedure. liao Expires April 23, 2011 [Page 12] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 UE3 UE2 UE1 MCS2 MCS1 Overlay Owner MCS new client old mixer ------------------------------------------------------------------- | | | | | | | | UE3 joins the conference and MCS2 is its server | | | | | | | | | | | MCS2 informs MCS1 | | | | | UE3 joined | | | | | | | ~~~~~~~> | | | | | | | | | | | | | | | FetchReq Clients list | | | | | ------> | -------> | | | | | | FetchAns | | | | | | <------ | <------- | | | | | | | | | | | | +----------------+ | | | | | | |Re-Computing the| | | | | | | | Audio mixer | | | | | | | +----------------+ | | | | | | | | | | MCS1 notices UE3 is the mixer | | | | <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | UE3 ACK Response | | | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> | | | | | | | | | | | | Inform UE3 is the mixer | | | | | |<~~~~~~~~~~~~~~~~~~ | | | | | <~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | | | | | | | Audio Stream | | | | | |<======= | | | | | | |<================ | | | | | | | | | | | | Figure 6 Selection of audio-mix peer in a Distributed Conference In this case, UE3 joined in the conference which UE1 and UE2 have already join. MSC1 is responsible to decide the proper UE to undertake the audio mixing task. In the first phrase there is no UE selected as mixing node, so MSC1 will be responsible for audio mixing. 1. UE3 registers in the conference and stores its information to the overlay through MCS2; 2. MCS2 informs MCS1 that a new node UE3 joined in the conference; liao Expires April 23, 2011 [Page 13] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 3. MCS1 fetches current UE list from overlay which include the ability information of all UEs; 4. After check of node capacity MCS1 find UE3 could be selected as mixing node. 5. MCS1 will notices UE3 the selection result. UE3 gives acknowledge response; 6. MCS1 informs UE1 and UE2 the new audio mixing node is UE3; 7. UE1 and UE2 will send their audio stream data to UE3. 5.1.2. Audio Mixer Transmission After selecting the audio mixer, all the UEs firstly sends their own audio stream data to the mixer, the mixer node completes the mixing of different audio streams and then sends the final mixed audio stream to all the other UEs. 5.2. Video Stream Process Video stream processing is different from the audio stream processing. The video stream handling requires much more resources than the audio transmission, such as CPU ability and bandwidth. This section will introduce the procedures of video stream processing. 5.2.1. Video Stream Transmission For this section, When UE1 wants to watch the video of UE0, UE0's MCS is responsible to choose the transmission path according the UE capacity information stored in the overlay. Then UE0's MCS informs UE1 and UE0 the transmission path and UE0 starts transmit video stream. Figure 7 gives an example of the procedure. liao Expires April 23, 2011 [Page 14] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 UE3 UE2 UE1 MCS2 MCS1 Overlay Owner MCS ------------------------------------------------------------------- | | UE1 wants to | | | | | | watch UE3 video| | | | | | | | | | | | | | Req UE3's Video | FetchReq UE3's Serv | | | |~~~~~~~~~~~~~~~~~~> |--------> |--------> | | | | | | FetchAns | | | | | |<-------- |<-------- | | | | | | | | | | | Informs watch Req | | | | | |<~~~~~~~~ | | | | | | | | | | | | | +----------------+ | | | | | | |Check Video | | | | | | | | Transmission | | | | | | | | Path | | | | | | | +----------------+ | | | | | | | | | | Inform UE2 to be the Relay node | | | | | |<~~~~~~~ | | | | | |<~~~~~~~~~~~~~~~~ | | | | |<~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | | | | | | | | Video Req | | | | | |<~~~~~~ |<~~~~~~ | | | | | | | | | | | | | Video | Video | | | | | |======> |======> | | | | | | | | | | | | | | | | | | | Figure 7 Video steam transmission in a Distributed Conference In this example, MCS1 serves UE1, MCS2 serves UE2 and UE3. The owner MCS stores the conference information. 1. UE1 wants to watch UE3's video and sends request to its service MCS1; 2. MCS1 asks Owner MCS through certain route policy for UE3's Service MCS information. Owner gives a response that MCS2 is the service MCS of UE3, MCS sends request to MCS2; 3. MCS1 checks suitable video transmission path and find UE2 could be the relay node to transfer video stream; liao Expires April 23, 2011 [Page 15] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 4. MCS1 informs the result to UE1, UE2 and UE3; 5. UE3 starts sending its video stream to UE2 and UE2 transfer it to UE1. The video stream transmission mode from one node to another can be classified 3 kinds. Figure 8 shows the different cases of video transmission. +-----+ +-----+ | UE2 | | UE2 | +-----+ +-----+ +-----+ | UE2 | ) ) +-----+ ( ( Video Stream ( Video Stream V ) ) ######## ( V # MCS2 # ) +-----+ ######## Video Stream | UE3 | ) Video Stream ( +-----+ ( ) ) ######## ( Video Stream # MCS1 # ) ( ######## V ) ( +-----+ V ) | UE1 | +-----+ V +-----+ | UE1 | +-----+ +-----+ | UE1 | +-----+ Model 1 Model 2 Model 3 Figure 8 Different Video Stream Transmission modes In this scenario, UE1 wants to watch UE2's video. The video steam can be transmitted in 3 ways: o Mode 1: When two UEs are in the same LAN or their network conditions can satisfy the requirement of the delay and bandwidth. The clients can be connected directly. UE2 can send its own video stream directly to UE1 without the help of other node. liao Expires April 23, 2011 [Page 16] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 o Mode 2: When two UEs can't send video stream directly, MCS will try to find another UE to transfer the video stream. If MCS find the node UE3, then UE2'll send the stream to UE3 and UE3 transfers the stream to UE1. o Mode 3: If no UE can be found, MCS will undertake the process task. UE2 transfers its video stream to MCS2 MCS2 forwards the video stream to UE1's server MCS1. Finally, MCS1 sends video stream to UE1. In order to spare the server resource as much as possible, method 1 and method 2 have a higher priority to be used. 5.2.2. Video Stream Delivery In a meeting, UE may need to send its video stream to several other UEs for watching. In order to make full use of the media transmission ability of UE node, an appropriate transmission model should be constructed, such as Tree-based model and Mesh-based model. The construction of the model should incorporate bandwidth, chip power, delay and other conditions, but the details still need to be further studied. Figure 9 gives an example of Tree-based transmission model. +--------------+ | Video Source | +--------------+ / \ / \ / \ v v #---------# #---------# # Capable # # Capable # # Peer1 # # Peer2 # #---------# #---------# / \ / \ / \ / \ v v v v ******** ******** ******** ******** * Peer3* * Peer4* * Peer5* * Peer6* ******** ******** ******** ******** Figure 9 Tree-based transmission model In the Tree-based model, the video source node, as the root of the tree, is responsible to construct and maintain the video multicast tree. Three aspects should be considered: First, the more capable the peer is, the lower the level it is. This ensures the powerful peers liao Expires April 23, 2011 [Page 17] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 take the most jobs. Second, the level of the tree may be kept as low as possible to ensure the reality of the conference. Third, the tree should be stable enough to ensure the continuity of the conference. How to construct the multicast tree need to be further studied. 5.2.3. Video Stream Mixture In some cases, UE would like to watch several peers' video stream while its bandwidth is not enough for the video transmission. Therefore, different video stream need to be mixed together firstly, then forward to the destination. To find a proper mixer peer, lots of conditions should be considered, especially chip ability. The details still need to be further studied. 5.2.4. Video Stream Transmission Switch If selected node failed, the service MCS server will take it over or select new UE to undertake the task. 6. Kind Definition This section formally defines the DCMP-REGISTRATION kind. Name DCMP-REGISTRATION Kind IDs The Resource name DCMP-REGISTRATION Kind-ID is the Conference- URI. The data stored is the DcmpRegistration that contains a symbol of processing media and "performance_data" describing a UE node's capability and network condition in the conference. Data Model The data model for the DCMP-REGISTRATION Kind-ID is dictionary. The dictionary key is the Node-ID. Access Control USER-NODE-MATCH 7. Security Considerations This document does not currently consider the security considerations of this approach. TODO. liao Expires April 23, 2011 [Page 18] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 8. IANA Considerations There are no IANA considerations with this document. 9. References 9.1. Normative References [1] [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-10 (work in progress), Aug 3, 2010. [2] [I-D.ietf-p2psip-sip] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "A SIP Usage for RELOAD", draft-ietf-p2psip-sip-04 (work in progress), March 2010. [3] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] [I-D.ietf-p2psip-disco] A. Knauf, G. Hege, T C. Schmidt, HAW Hamburg, M. Waehlisch, "A RELOAD Usage for Distributed Conference Control (DisCo)", draft-knauf-p2psip-disco-00, June 28, 2010 10. Acknowledgments Thanks to the many people who contributed include Jin Peng, Hongluan Liao, Zhenyu Yu and Yiwen Wang. This document was prepared using 2-Word-v2.0.template.dot. liao Expires April 23, 2011 [Page 19] Internet-Draft P2P Traffic Localization by Alias Tracker October 2010 Authors' Addresses Hongluan Liao China Mobile Phone: +8610-6600-6688 ext. 3214 Email: liaohongluan@chinamobile.com Jin Peng China Mobile Phone: +8610-6600-6688 ext. 3252 Email: pengjin@chinamobile.com Zhenyu Yu Beijing University of Posts & Telecommunications (BUPT) Phone: Email: buptyzy@139.com Yiwen Wang Beijing University of Posts & Telecommunications (BUPT) Phone: Email: ewangbupt@139.com liao Expires April 23, 2011 [Page 20]