idnits 2.17.1 draft-zong-ppsp-reqs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 27 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: PPSP.SEC.REQ-9: Security mechanisms of PPSP SHOULD not limit the scalability, performance and reliability of the P2P streaming system. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 07, 2010) is 5035 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Survey' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'ProbSta' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'P2PLive' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'LiveStream' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-p2psip-base' is defined on line 559, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-01 == Outdated reference: A later version (-06) exists of draft-zhang-ppsp-problem-statement-05 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPSP N. Zong, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track Y. Zhang 5 Expires: January 8, 2011 China Mobile Communication 6 Corporation 7 V. Pascual 8 C. Williams 9 Consultant 10 L. Xiao 11 Nokia Siemens Networks 12 July 07, 2010 14 P2P Streaming Protocol (PPSP) Requirements 15 draft-zong-ppsp-reqs-04 17 Abstract 19 The objective of the PPSP work is to standardize the key signaling 20 protocols that apply to tracker and peers in a Peer-to-Peer (P2P) 21 streaming system. These protocols are called PPSP. This document 22 enumerates the requirements for the PPSP, which should be considered 23 when designing PPSP. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 8, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Overview of PPSP . . . . . . . . . . . . . . . . . . . . . . . 6 74 4. PPSP Requirements . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 7 76 4.1.1. Basic Requirements to PPSP Node . . . . . . . . . . . 7 77 4.1.2. Basic Requirements to PPSP content resource . . . . . 7 78 4.1.3. Other General Requriements . . . . . . . . . . . . . . 8 79 4.2. PPSP Tracker Protocol Requirements . . . . . . . . . . . . 8 80 4.3. PPSP Peer Protocol Requirements . . . . . . . . . . . . . 9 81 4.4. PPSP Error Handling and Overload Protection 82 Requirements . . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 Peer to Peer (P2P) computing has been successfully used in many 94 fields, from one to one communication like Voice over IP (VoIP) and 95 Instance Messaging (IM), to one to many communication like streaming, 96 file sharing and gaming. In the streaming area, the popularity of 97 P2P real-time and video on demand (VoD) streaming technology has been 98 demonstrated by PPlive [WWW.PPLive], PPStream [WWW.PPStream], UUSee 99 [WWW.UUSee], Pando [WWW.Pando] etc. Take PPLive for example, it has 100 over 5 million online users at the same time for real-time streaming. 101 Also some web2.0 streaming applications such as Youtube 102 [WWW.YouTube], Tudou [WWW.Tudou] are reported to use or are preparing 103 to use P2P engine to accelerate its downloading rate and cut down the 104 transmission cost. P2P streaming applications account for more and 105 more Internet traffic. According to statistics in a major Chinese 106 Internet Service Provider (ISP), the traffic generated by P2P 107 streaming applications exceeded 50% of the total backbone traffic 108 during peak time in 2008. [PPSPPS] 110 Given the increasing integration of P2P streaming into the global 111 content delivery infrastructure, the lack of an open, standard P2P 112 streaming protocol has become a major missing component in the 113 Internet protocol stack. Multiple similar but proprietary P2P 114 streaming protocols result in repetitious development efforts and 115 lock-in effects. More importantly, it leads to substantial 116 difficulties when integrating P2P streaming as a component of a 117 global content delivery infrastructure. For example, proprietary P2P 118 streaming protocols do not integrate well with infrastructure devices 119 such as caches and other edge devices. [PPSPPS] 121 The objective of the PPSP work is to standardize the key signaling 122 protocols that apply to tracker and peers in a P2P streaming system. 123 These protocols are called PPSP. PPSP will serve as an enabling 124 technology, building on the development experiences of existing P2P 125 streaming systems. Its design will allow it to integrate with IETF 126 efforts on distributed resource location, traffic localization, and 127 streaming control mechanisms. It allows effective integration with 128 edge infrastructures such as cache and mobile edge equipment. 129 [PPSPPS] 131 This document enumerates the requirements for the PPSP, which should 132 be considered when designing PPSP. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119] and 139 indicate requirement levels for compliant implementations. 141 This document uses the following PPSP-related terms, which are 142 defined in [PPSPPS], including: 144 Chunk, Live streaming, Peer/PPSP peer, PPSP, Swarm, Tracker/PPSP 145 tracker, Video-on-demand (VoD). 147 Furthermore, the following additional terms will be used: 149 Peer list: A list of peer ID which are in a same swarm maintained by 150 the PPSP tracker. A peer must fetch the peer list of a swarm from 151 the tracker to know which peers have the required content. 153 Swarm ID: Identifier for certain swarm. It is used to describe a 154 specific resource shared among peers. 156 Usage type: Information used to identify the type of shared content. 157 Currently there are two usage types in PPSP: live streaming and VoD. 158 PPSP may also be extended to support more usage types, e.g. data 159 file. 161 Chunk ID: An identifier of a chunk for a certain resource which shows 162 the position (or time slot) of the chunk in the whole file (or live 163 streaming). A peer should report to tracker which chunks are 164 actively maintained in its buffer by sending the chunk IDs of a file 165 for certain swarm. 167 Buffer map: A map to indicate which chunks a peer currently has 168 buffered and can share with other peers. The buffer map can include 169 the offset (the ID of the first chunk stored by the peer), the length 170 of the buffer map, and a string of zeroes and ones indicating which 171 chunks are available. It reflects the content availability of a peer 172 in coarse grain. 174 <------- Buffer Map Length -------------> 175 +---+---+---+---+---+---+---+---+---+---+ 176 <---------->| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 177 offset +---+---+---+---+---+---+---+---+---+---+ 178 |--------------------------------------------------------------------> 179 Content Length 181 Figure 1: Buffer Map 183 Bitmap: A map of bits to reflect the availability of the smallest 184 transmission units in chunks. It can also be generally described as 185 content availability of a peer. Peers in a swarm need exchange the 186 bitmap information to know where to get their interested data units. 188 3. Overview of PPSP 190 As described in [PPSPPS], the following components are considered in 191 the scope of PPSP: 193 1) Tracker communication. Tracker communication is a component that 194 enables each peer to get peer list from the tracker and/or provide 195 content availability to the tracker. 197 2) Peer communication. Peer communication is a component that 198 enables each peer to exchange content availability and request other 199 peers for content. 201 3) Report. Report is a component that enables peers to report 202 streaming status to the tracker. The information may include swarm 203 IDs to show swarms that the peer is taking active part in, chunk list 204 for each swarm to show the current content availability in the peer, 205 inbound/outbound traffic capacity, amount of neighbor peers, peer 206 health degree and other streaming parameters. 208 Therefore, PPSP includes the PPSP tracker protocol - a signaling 209 protocol between PPSP trackers and PPSP peers, and the PPSP peer 210 protocol - a signaling protocol among PPSP peers. 212 PPSP tracker protocol will define: 214 1) Standard format/encoding of information between PPSP peers and 215 PPSP trackers, such as peer list, swarm ID, chunk information,content 216 availability, streaming status including online time, link status, 217 node capability and other streaming parameters. 219 2) Standard messages between PPSP peers and PPSP trackers defining 220 how PPSP peers report streaming status and request to PPSP trackers, 221 as well as how PPSP trackers reply to the requests. 223 PPSP peer protocol will define: 225 1) Standard format/encoding of information among PPSP peers, such as 226 chunk description. 228 2) Standard messages among PPSP peers defining how PPSP peers 229 advertise chunk availability to each other, as well as the signaling 230 for requesting the chunks among PPSP peers. 232 This document itemizes requirements for the following aspects of 233 PPSP: 235 1) Basic requirements to PPSP nodes (peer/tracker) and the content 236 resource. 238 2) General requirements to the message format and process flow of 239 PPSP tracker protocol. 241 3) General requirements to the message format and process flow of 242 PPSP peer protocol. 244 4) Error handling and overload protection requirements. 246 5) Security requirements. 248 4. PPSP Requirements 250 4.1. Basic Requirements 252 In order to make PPSP work, some basic requirements must be 253 satisfied, which are necessary preconditions for peers and trackers 254 to take part in PPSP services and for content being shared among PPSP 255 peers. 257 4.1.1. Basic Requirements to PPSP Node 259 PPSP.REQ-1: Each peer in PPSP MUST has a unique identifier, i.e. peer 260 ID. 262 It's a basic requirement for a peer to have an identity in PPSP 263 communication that other peers or tracker can refer the ID for the 264 peer. 266 PPSP.REQ-2: The tracker in PPSP MUST have a public identity that can 267 be discovered and accessed by PPSP peers. 269 It requires trackers are reachable with identifiers from Internet or 270 other IP network. But how to discover the tracker is not in the 271 scope of PPSP. 273 4.1.2. Basic Requirements to PPSP content resource 275 PPSP.REQ-3: The data resources shared in PPSP services MUST be 276 classified and identified by different usage types. 278 PPSP is designed for P2P live streaming and VoD. It also has the 279 potential to be used for P2P data file sharing. These usage types 280 have different requirements for truck queries and transmission 281 behaviors, e.g. data downloading order and time constraint. 282 Therefore, usage types are necessary to guide different content 283 sharing behaviors. 285 PPSP.REQ-4: The content in PPSP MUST be identified by swarm ID. 287 A swarm refers to a group of peers sharing the same content. It 288 could be a TV Channel, film name or file name. Swarm ID can be 289 looked as a resource ID to denote a specific content. The swarm ID 290 can be used in two cases: 1) a peer requests the tracker for the peer 291 list indexed by a swarm ID; 2) a peer tells the tracker about the 292 swarms it belongs to. 294 PPSP.REQ-5: The content resource shared by a swarm in PPSP MUST allow 295 being partitioned into chunks with a standard format. 297 A key characteristic of P2P streaming system is allowing the data 298 fetching from different peers concurrently. Therefore, the whole 299 content must be partitioned into small peaces, called chunks in PPSP, 300 for transmission. The chunks must be formed and sorted by a standard 301 way, so when a peer says it requires some chunks, e.g. 011, 012 and 302 013, other peers could understand which peaces wanted by the peer 303 exactly. Also, a normative buffer map can be used to show the chunk 304 availability of a peer. 306 PPSP.REQ-6: The content resource shared by a swarm in PPSP MUST have 307 a standard data format. 309 So, the availability of each data unit in a peer can be denoted in a 310 normative bitmap structure. By exchanging the bitmap, peers in a 311 swarm can schedule the transmission in the grain of the smallest data 312 units. 314 4.1.3. Other General Requriements 316 PPSP.REQ-7: The Tracker Protocol and Peer Protocol SHOULD enable 317 peers to receive streaming data within the time constraints required 318 by specific content items. 320 PPSP.REQ-8: The Tracker Protocol and Peer Protocol are Recommended to 321 be carried over TCP (or UDP, when delivery requirements cannot be met 322 by TCP). 324 4.2. PPSP Tracker Protocol Requirements 326 PPSP tracker protocol defines how PPSP peers report and request 327 information to/from PPSP trackers and how PPSP trackers reply to the 328 requests. The tracker discovery and the possible communication 329 between trackers are out of the scope of the PPSP tracker protocol. 331 PPSP.TP.REQ-1: The PPSP trackers MUST implement the PPSP tracker 332 protocol, for receiving PPSP tracker queries and periodical peer 333 status reports/updates from peers and for sending the corresponding 334 replies. 336 PPSP.TP.REQ-2: The PPSP peers MUST implement the PPSP tracker 337 protocol for sending PPSP tracker queries and periodical peer status 338 reports/updates to PPSP tracker and receiving the corresponding 339 replies from tracker. 341 PPSP.TP.REQ-3: The tracker request message MUST allow the peer to 342 solicit the peer list from tracker with the respect of the specific 343 swarm ID. 345 PPSP.TP.REQ-4: The tracker request message MAY include parameter of 346 requested number of downloading peers or preferred downloading 347 bandwidth. 349 PPSP.TP.REQ-5: The tracker reply message MUST allow the PPSP tracker 350 to offer list of active peers with the respect of the requested 351 swarm. 353 PPSP.TP.REQ-6: The peer status report (update) message MUST have the 354 ability to inform the tracker about the peer!_s activity with the 355 swarm and chunk information of the peer. 357 PPSP.TP.REQ-7: The PPSP tracker MAY generate the peer list with the 358 help of traffic optimization services, e.g. Alto. 360 PPSP.TP.REQ-8: The peer status report (update) message MAY have the 361 option to carry streaming status of the peer, including online time, 362 link status, peer capability and other streaming parameters of the 363 peer. Therefore, the tracker is able to select better candidate 364 peers for streaming without the help of other traffic optimization 365 services. 367 4.3. PPSP Peer Protocol Requirements 369 PPSP peer protocol defines how PPSP peers advertise data availability 370 and exchange neighbor peer information. The protocol will also 371 define the requests and responses of data chunks and peer properties 372 among PPSP peers. The transport mechanism and transmission control 373 are out of the scope. 375 PPSP.PP.REQ-1: The PPSP peers MUST implement the PPSP peer protocol 376 to exchange information and negotiate the data chunk requests and 377 responses before any content is transmitted. 379 PPSP.PP.REQ-2: The content availability request message MUST allow 380 the peer to solicit the chunk ID and bitmap information from other 381 peers with the respect of the peer list received from tracker. 383 PPSP.PP.REQ-3: The content availability reply message MUST allow the 384 PPSP peer to offer the list of chunk ID and bitmap of the data in its 385 buffer. 387 PPSP.PP.REQ-4: The content availability reply message MAY offer 388 information of other active peers than that in the peer list with the 389 same swarm ID and required chunks. 391 It is possible that a peer may need additional peers for certain 392 content. Therefore, it is allowed that the peer communicates with 393 the peers in the current peer list to obtain additional group of 394 peers in the swarm. 396 PPSP.PP.REQ-5: The content availability update message MUST be 397 advertised among swarm peers periodically or on-demand. 399 During the content transmission and the dynamic join/leave of peers, 400 the content availability information of neighborhoods are changing, 401 which requires being updated on time. A simple way to realize it is 402 advertising the chunk availability periodically among peers. 403 However, how often the advertisement is an open issue. Different 404 usage types may differ in the requirement. Too frequent updates 405 waste the network resource. Therefore, the update can be done on 406 demand. When a peer find there are not enough peers with certain 407 chunks, it will generate an update request to its neighbors to enrich 408 the peer list it maintains. 410 PPSP.PP.REQ-6: The peer streaming status update information MAY be 411 advertised among peers. 413 Streaming status information should be related to the content 414 delivery, including online time, link status, peer capability and 415 other streaming parameters of the peer. With this information, a 416 peer can select more appropriate peers for content sharing based on 417 some content sharing strategies and/or application requirements. 419 4.4. PPSP Error Handling and Overload Protection Requirements 421 PPSP.ERR.REQ-1: A peer MUST be able to respond with error information 422 to the peers sending PPSP messages, when some information (e.g. peer 423 list, chunk expression) cannot be understood in the message. 425 Local Peer Peers/Tracker 426 | | 427 | PPSP Message | 428 |<-----------------------------------------------| 429 | | 430 | Error Information | 431 |----------------------------------------------->| 432 | | 433 | | 435 Figure 2: Error Handling 437 PPSP.ERR.REQ-2: A PPSP tracker, which is operating close to its 438 capacity limit, MUST be able to inform peers about its impending 439 overload situation, and redirect them to another PPSP tracker. 441 PPSP.ERR.REQ-3: A PPSP tracker, which is operating close to its 442 capacity limit, MUST be able to inform peers about its impending 443 overload situation, and terminate the conversation with the current 444 PPSP tracker. 446 PPSP.ERR.REQ-4: A PPSP tracker, which is operating close to its 447 capacity limit, MUST be able to inform peers about its impending 448 overload situation, and reject new conversation attempts. 450 5. Security Considerations 452 The scope of this section is to analyze the security threats and 453 provide the requirements for PPSP. While P2P streaming system 454 prevails in recent years, an important but less studied problem is 455 security. 457 PPSP.SEC.REQ-1: PPSP MUST ensure that only authorized users can 458 access the original media in the P2P streaming system. This can be 459 achieved by defining or adopting such mechanisms as user 460 authentication and/or key management scheme. 462 PPSP.SEC.REQ-2: Confidentiality of the streaming data SHOULD be 463 supported and the corresponding key management scheme MUST scale well 464 without degrading the system performance. 466 PPSP.SEC.REQ-3: PPSP MUST provide an option to encrypt data exchange 467 among PPSP entities. 469 PPSP.SEC.REQ-4: PPSP MUST prevent stream pollution attacks. In the 470 stream pollution attack, the attacker mixes into the stream bogus 471 chunks, or declare the chunks it doesn't have. 473 Such an attack will degrade the quality of the rendered media at the 474 receiver. For example, in a P2P live video streaming system a 475 polluter can introduce corrupted chunks. Each receiver integrates 476 into its playback stream the polluted chunks it receives from its 477 other neighbors. Since the peers forwards chunks to other peers, the 478 polluted content can potentially spread through much of the P2P 479 streaming network. 481 PPSP.SEC.REQ-5: PPSP MUST have mechanisms to limit potential damage 482 caused by malfunctioning and badly behaving peers in the P2P 483 streaming system. In addition there must be a way to identify badly 484 behaving peers, and exclude or reject them from the P2P streaming 485 system. 487 PPSP.SEC.REQ-6: PPSP MUST prevent peers from exhausting the P2P 488 streaming system's available resource, e.g. processing capacity, 489 bandwidth, etc. 491 Given the prevalence of DoS attacks in the Internet, it is important 492 to realize that a similar threat could exist in a large-scale 493 streaming system where attackers are capable of consuming a lot of 494 resources with just a small amount of effort. 496 PPSP.SEC.REQ-7: PPSP SHOULD minimize the dependency on reachability 497 of centralized servers. 499 PPSP.SEC.REQ-8: Existing security mechanisms SHOULD be re-used as 500 much as possible in PPSP, to avoid developing new security 501 mechanisms. 503 PPSP.SEC.REQ-9: Security mechanisms of PPSP SHOULD not limit the 504 scalability, performance and reliability of the P2P streaming system. 506 6. IANA Considerations 508 This document presently raises no IANA considerations. 510 7. Acknowledgements 512 The authors would like to thank many people for discussing P2P 513 streaming. We would particularly like to thank: Yingjie Gu, Haibin 514 Song, Xingfeng Jiang from Huawei Technologies, Hui Zhang from NEC 515 Labs, Jun Lei from University of Goettingen, James Seng from PPLive, 516 Das Saumitra from Qualcomm, and Christian Schmidt from NSN. 518 8. References 520 8.1. Normative References 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 8.2. Informative References 527 [WWW.PPLive] 528 "www.pplive.com". 530 [WWW.PPStream] 531 "www.ppstream.com". 533 [WWW.UUSee] 534 "www.uusee.com". 536 [WWW.Pando] 537 "www.pando.com". 539 [WWW.YouTube] 540 "www.youtube.com". 542 [WWW.Tudou] 543 "www.tudou.com". 545 [Survey] Zong, N. and X. Jiang, "Survey of P2P Streaming", 546 IETF PPSP BoF, November 2008. 548 [ProbSta] Zhang, Y., "Problem Statement of P2P Streaming Protocol 549 (PPSP)", IETF PPSP BoF, November 2008. 551 [P2PLive] Guo, Y., Liang, C., and Y. Liu, "Adaptive Queue-based 552 Chunk Scheduling for P2P Live Streaming", IFIP 553 Networking Proceedings, May 2008. 555 [LiveStream] 556 Pascual, V., "Live Streaming over P2PSIP", International 557 SIP Conference 10th Edition, January 2009. 559 [I-D.ietf-p2psip-base] 560 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 561 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 562 Base Protocol", draft-ietf-p2psip-base-01 (work in 563 progress), December 2008. 565 [PPSPPS] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang, 566 "PPSP Problem Statement", 567 draft-zhang-ppsp-problem-statement-05 (work in progress). 569 Authors' Addresses 571 Ning Zong (editor) 572 Huawei Technologies 574 Phone: +86 25 56622975 575 Email: zongning@huawei.com 577 Yunfei Zhang 578 China Mobile Communication Corporation 580 Phone: +86 13601032119 581 Email: zhangyunfei@chinamobile.com 583 Victor Pascual 584 Consultant 586 Email: victor.pascual.avila@gmail.com 588 Carl Williams 589 Consultant 590 Palo Alto, California 94306 592 Email: carlw@mcsr-labs.org 594 Lin Xiao 595 Nokia Siemens Networks 597 Phone: +86 10 84055824 598 Email: lin.xiao@nsn.com