idnits 2.17.1 draft-ietf-ppsp-reqs-05.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 25 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 == 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 (October 08, 2011) is 4574 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-ppsp-survey-02 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-09 == Outdated reference: A later version (-15) exists of draft-ietf-ppsp-problem-statement-05 Summary: 0 errors (**), 0 flaws (~~), 6 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: Informational Y. Zhang 5 Expires: April 10, 2012 China Mobile Communication 6 Corporation 7 V. Pascual 8 Acme Packet 9 C. Williams 10 Consultant 11 L. Xiao 12 Nokia Siemens Networks 13 October 08, 2011 15 P2P Streaming Protocol (PPSP) Requirements 16 draft-ietf-ppsp-reqs-05 18 Abstract 20 The objective of the PPSP work is to standardize the key signaling 21 protocols that apply to tracker and peers in a Peer-to-Peer (P2P) 22 streaming system. These protocols are called PPSP. This document 23 enumerates the requirements for the PPSP, which should be considered 24 when designing PPSP. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 10, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Overview of PPSP . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. PPSP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 6 77 4.2. PPSP Tracker Protocol Requirements . . . . . . . . . . . . 8 78 4.3. PPSP Peer Protocol Requirements . . . . . . . . . . . . . 9 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 Peer to Peer (P2P) computing has been successfully used in many 90 fields, from one-to-one communication like Voice over IP (VoIP) and 91 Instance Messaging (IM), to one-to-many communication like streaming, 92 file sharing and gaming. In the streaming area, the popularity of 93 P2P real-time and video on demand (VoD) streaming technology has been 94 demonstrated by PPLive [PPLive], PPStream [PPStream], UUSee [UUSee], 95 Pando [Pando] etc. Take PPLive for example, it has over 5 million 96 online users at the same time for real-time streaming. P2P streaming 97 applications account for more and more Internet traffic. According 98 to statistics in a major Chinese Internet Service Provider (ISP), the 99 traffic generated by P2P streaming applications exceeded 50% of the 100 total backbone traffic during peak time in 2008 101 [I-D.ietf-ppsp-problem-statement]. 103 Given the increasing integration of P2P streaming into the global 104 content delivery infrastructure, the lack of an open, standard P2P 105 streaming protocol has become a major missing component in the 106 Internet protocol stack. Multiple similar but proprietary P2P 107 streaming protocols result in repetitious development efforts and 108 lock-in effects. More importantly, it leads to substantial 109 difficulties when integrating P2P streaming as a component of a 110 global content delivery infrastructure. For example, proprietary P2P 111 streaming protocols do not integrate well with infrastructure devices 112 such as caches and other edge devices 113 [I-D.ietf-ppsp-problem-statement]. 115 The objective of the PPSP work is to standardize the key signaling 116 protocols that apply to tracker and peers in a P2P streaming system. 117 These protocols are called PPSP. PPSP will serve as an enabling 118 technology, building on the development experiences of existing P2P 119 streaming systems. Its design will allow it to integrate with IETF 120 efforts on distributed resource location, traffic localization, and 121 streaming control mechanisms. It allows effective integration with 122 edge infrastructures such as cache and mobile edge equipment 123 [I-D.ietf-ppsp-problem-statement]. 125 This document enumerates the requirements for the PPSP, which should 126 be considered when designing PPSP. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119] and 133 indicate requirement levels for compliant implementations. 135 This document uses the following PPSP-related terms, which are 136 defined in [I-D.ietf-ppsp-problem-statement], including: 138 Chunk, Live streaming, Peer/PPSP peer, PPSP, Swarm, Tracker/PPSP 139 tracker, Video-on-demand (VoD). 141 Furthermore, the following additional terms will be used: 143 Peer list: A list of peers which are in a same swarm maintained by 144 the tracker. A peer can fetch the peer list of a swarm from either 145 tracker or other peers to know which peers have the required 146 streaming content. 148 Peer ID: An identifier of a peer such that other peers or tracker can 149 refer the ID for the peer. 151 Swarm ID: An identifier of a swarm containing a group of peers 152 sharing a same streaming content. 154 Chunk ID: An identifier of a chunk in a streaming content. 156 3. Overview of PPSP 158 As described in [I-D.ietf-ppsp-problem-statement], the following 159 components are considered in the scope of PPSP: 161 1) Tracker communication. Tracker communication is a component that 162 enables each peer to get peer list from the tracker and/or provide 163 content availability to the tracker. 165 2) Peer communication. Peer communication is a component that 166 enables each peer to exchange content availability and request 167 content from other peers. 169 3) Report. Report is a component that enables peers to report 170 streaming status to the tracker. The information may include swarm 171 IDs to show swarms that the peer is taking active part in, chunk list 172 for each swarm to show the current content availability in the peer, 173 inbound/outbound traffic capacity, amount of neighbor peers, peer 174 health degree, total amount of bytes uploaded/downloaded to neighbour 175 peers, and other streaming parameters. 177 Therefore, PPSP includes the PPSP tracker protocol - a signaling 178 protocol between PPSP trackers and PPSP peers, and the PPSP peer 179 protocol - a signaling protocol among PPSP peers. 181 PPSP tracker protocol will define: 183 1) Standard format/encoding of information between PPSP peers and 184 PPSP tracker. Some of this exchanged information may be explicitly 185 marked as optional. Exchanged information may include peer list, 186 swarm ID, chunk information, content availability, streaming status 187 including online time, link status, node capability and other 188 streaming parameters. 190 2) Standard messages between PPSP peers and PPSP trackers defining 191 how PPSP peers report streaming status and request to PPSP trackers, 192 as well as how PPSP trackers reply to the requests. 194 PPSP peer protocol will define: 196 1) Standard format/encoding of information among PPSP peers, such as 197 chunk description. 199 2) Standard messages among PPSP peers defining how PPSP peers 200 advertise chunk availability to each other, as well as the signaling 201 for requesting the chunks among PPSP peers. 203 This document itemizes requirements for the following aspects of 204 PPSP: 206 1) Basic requirements to PPSP protocols (peer and tracker protocols), 207 entities (peer and tracker), streaming content, and QoS issues. 209 2) General requirements to the tracker protocol. 211 3) General requirements to the peer protocol. 213 4) Security requirements. 215 4. PPSP Requirements 217 4.1. Basic Requirements 219 PPSP.REQ-1: The tracker and the peer protocols SHOULD be as similar 220 as possible, in terms of design, message formats and flows. 222 It is desirable that the peer protocol would be an extension to the 223 tracker protocol by adding a few message types, or vice versa. 225 PPSP.REQ-2: The tracker protocol and the peer protocol SHOULD enable 226 peers to receive streaming content within the required time 227 constraints, i.e., fulfill streaming feature. 229 PPSP.REQ-3: Each peer MUST have a unique ID (i.e. peer ID) in a 230 swarm. 232 It's a basic requirement for a peer to be uniquely identified in a 233 swarm that other peers or tracker can refer to the peer by ID. 235 PPSP.REQ-4: The streaming content MUST be uniquely identified by a 236 swarm ID. 238 A swarm refers to a group of peers sharing the same streaming 239 content. A swarm ID uniquely identifies a swarm. The swarm ID can 240 be used in two cases: 1) a peer requests the tracker for the peer 241 list indexed by a swarm ID; 2) a peer tells the tracker about the 242 swarms it belongs to. 244 PPSP.REQ-5: The streaming content MUST allow to be partitioned into 245 chunks. 247 A key characteristic of P2P streaming system is allowing the data 248 fetching from different peers concurrently. Therefore, the whole 249 streaming content must allow to be partitioned into small pieces or 250 chunks for transmission between peers. 252 PPSP.REQ-6: Each chunk MUST have an unique ID (i.e. chunk ID) in the 253 swarm. 255 Each chunk must have an unique ID in the swarm such as the peer can 256 understand which chunks are stored in which peers and which chunks 257 are requested by other peers. An example for generating the chunk ID 258 is the buffer map approach [I-D.ietf-ppsp-survey]. 260 PPSP.REQ-7: The tracker protocol and peer protocol are Recommended to 261 be carried over TCP (or UDP, when delivery requirements cannot be met 262 by TCP). 264 PPSP.REQ-8: The tracker and peer protocol together MUST facilitate 265 acceptable QoS (e.g. low startup delay, low channel/content switching 266 time and minimal end-to-end delay) for both on-demand and live 267 streaming, even for very popular content. The tracker and peer 268 protocol do not include the algorithm required for scalable 269 streaming. However, the tracker and peer protocol SHALL NOT restrict 270 or place limits on any such algorithm. 272 There are basic QoS requirements for streaming system. Setup time to 273 receive a new streaming channel or to switch between channels should 274 be reasonable small. End to end delay (time between content 275 generation, e.g. camera and content consumption, e.g. user side 276 monitor) will become critical in case of live streaming. Especially 277 in provisioning of sports events, end to end delay of 1 minute and 278 more are not acceptable. 280 For instance, the tracker and peer protocols can support carrying QoS 281 related parameters (e.g. video quality, delay requirements) together 282 with the priorities of these parameters, and QoS situation (e.g. 283 performance, available uplink bandwidth) of content providing peers. 285 There are also some other possible mechanisms, e.g. addition of super 286 peers, in-network storage, request of alternative peer addresses, and 287 the usage of QoS information for an advanced peer selection. 289 4.2. PPSP Tracker Protocol Requirements 291 The tracker protocol defines how the peers report and request 292 information to/from the tracker and how the tracker replies to the 293 requests. The tracker discovery and the possible communication 294 between trackers are out of the scope of tracker protocol. 296 PPSP.TP.REQ-1: The tracker MUST implement the tracker protocol for 297 receiving queries and periodical peer status reports/updates from the 298 peers and for sending the corresponding replies. 300 PPSP.TP.REQ-2: The peer MUST implement the tracker protocol for 301 sending queries and periodical peer status reports/updates to the 302 tracker and receiving the corresponding replies. 304 PPSP.TP.REQ-3: The tracker request message MUST allow the requesting 305 peer to solicit the peer list from the tracker with respect to a 306 specific swarm ID. 308 The tracker request message may also include the requesting peer's 309 preference parameter, e.g. preferred number of peers in the peer 310 list, or preferred downloading bandwidth. The track will then be 311 able to select an appropriate set of peers for the requesting peer 312 according to the preference. 314 PPSP.TP.REQ-4: The tracker reply message MUST allow the tracker to 315 offer the peer list to the requesting peer with respect of a specific 316 swarm ID. 318 PPSP.TP.REQ-5: The tracker SHOULD support generating the peer list 319 with the help of traffic optimization services, e.g. ALTO 320 [I-D.ietf-alto-protocol]. 322 PPSP.TP.REQ-6: The peer status report/update MUST have the ability to 323 inform the tracker about the peer's activity in the swarm. 325 PPSP.TP.REQ-7: The chunk availability information of the peer SHOULD 326 be reported to tracker when tracker needs such information to steer 327 peer selection. The chunk information MUST at least contain the 328 chunk ID. 330 PPSP.TP.REQ-8: The chunk availability information between peer and 331 tracker MUST be as expressed as compactly as possible. 333 The peers may report CHUNK AVAILABILTY DIGEST information (i.e. 334 compact expression of chunk availability) to the tracker when 335 possible to decrease the bandwidth consumption for messages in 336 bandwidth constraint environment like mobile network. For example, 337 if a peer has a bitmap like 111111...1(100 continuous 1)xxx..., the 338 100 continuous "1" can be expressed by one byte with seven bits 339 representing 100 and one bit representing "1". In this example, 100- 340 8=92 bits are saved. Considering the frequency of exchange of CHUNK 341 AVAILBILITY and the fact that many bitmaps have quite a long length 342 of continuous "1" or "0", such compression makes sense. 344 PPSP.TP.REQ-9: The status of the peer SHOULD be reported to the 345 tracker when tracker needs such information to steer peer selection. 347 For example, peer status can be online time, physical link status 348 including DSL/WIFI/etc, battery status, processing capability, and 349 other capabilities of the peer. Therefore, the tracker is able to 350 select better candidate peers for streaming. 352 4.3. PPSP Peer Protocol Requirements 354 The peer protocol defines how the peers advertise streaming content 355 availability and exchange status with each other. The peer protocol 356 also defines the requests and responses of the chunks among the 357 peers. The first task for this WG will be to decide which signaling 358 and media transfer protocols will be used. The WG will consider 359 existing protocols and, if needed, identify potential extensions to 360 these protocols. 362 PPSP.PP.REQ-1: The streaming content availability request message 363 MUST allow the peer to solicit the chunk information from other peers 364 in the peer list. The chunk information MUST at least contain the 365 chunk ID. This chunk availability information MUST NOT be passed on 366 to other peer, unless validated (e.g. prevent hearsay and DoS). 368 PPSP.PP.REQ-2: The streaming content availability reply message MUST 369 allow the peer to offer the information of the chunks in its content 370 buffer. The chunk information MUST at least contain the chunk ID. 372 PPSP.PP.REQ-3: The streaming content availability request message 373 SHOULD allow the peer to solicit an additional list of peers to that 374 received from the tracker - with the same swarm ID. The reply 375 message MUST contain swarm-membership information of the peers that 376 have explicitly indicated they are part of the swarm, verifiable by 377 the receiver. This additional list of peers MUST only contain peers 378 which have been checked to be valid and online recently (e.g. prevent 379 hearsay and DoS). 381 It is possible that a peer may need additional peers for certain 382 streaming content. Therefore, it is allowed that the peer 383 communicates with the peers in the current peer list to obtain an 384 additional list of peers in the same swarm. 386 PPSP.PP.REQ-4: Streaming content availability update message among 387 the peers MUST be supported by peer protocol. In the push based 388 model, where peers advocate their own chunk availability proactively, 389 the content availability request message described in PP.REQ-1 is not 390 needed. The peer protocol MUST implement either pull-based, push- 391 based or both. 393 Due to the dynamic change of the buffered streaming content in each 394 peer and the frequent join/leave of peers in the swarm, the streaming 395 content availability among a peer's neighbours (i.e. the peers known 396 to a peer by getting the peer lists from either tracker or peers) 397 always changes and thus requires being updated on time. This update 398 should be done at least on demand. For example, when a peer requires 399 finding more peers with certain chunks, it sends a message to some 400 other peers in the swarm for streaming content availability update. 401 Alternatively, each peer in the swarm can advertise its streaming 402 content availability to some other peers periodically. However, the 403 detailed mechanisms for this update such as how far to spread such 404 update message, how often to send this update message, etc should 405 leave to peer algorithms, rather than protocol concerns. 407 PPSP.PP.REQ-5: The chunk availability information between peers MUST 408 be as expressed as compactly as possible. 410 In PP.REQ-1/2/4, the peers may exchange CHUNK AVAILABILTY DIGEST 411 information (i.e. compact expression of chunk availability) to with 412 other peers when possible to decrease the bandwidth consumption for 413 messages in bandwidth constraint environment like mobile network. 415 PPSP.PP.REQ-6: The peer status report/update SHOULD be advertised 416 among the peers to reflect the status of the peer. 418 Peer status information should be advertised among the peers via the 419 peer status report/update message. For example, peer status can be 420 online time, physical link status including DSL/WIFI/etc, battery 421 status, processing capability, and other capabilities of the peer. 423 With this information, a peer can select more appropriate peers for 424 streaming. 426 PPSP.PP.REQ-7: The peers MUST implement the peer protocol for chunk 427 data (not availability information) requests and responses among the 428 peers before the streaming content is transmitted. 430 5. Security Considerations 432 The scope of this section is to analyze the security threats and 433 provide the requirements for PPSP. 435 PPSP.SEC.REQ-1: PPSP MUST support closed swarms, where the peers are 436 authenticated. 438 This ensures that only the authenticated users can access the 439 original media in the P2P streaming system. This can be achieved by 440 security mechanisms such as user authentication and/or key management 441 scheme. 443 PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP 444 SHOULD be supported and the corresponding key management scheme 445 SHOULD scale well in P2P streaming system. 447 PPSP.SEC.REQ-3: PPSP MUST provide an option to encrypt the data 448 exchange among the PPSP entities. 450 PPSP.SEC.REQ-4: PPSP MUST have mechanisms to limit potential damage 451 caused by malfunctioning and badly behaving peers in the P2P 452 streaming system. 454 Such an attack will degrade the quality of the rendered media at the 455 receiver. For example, in a P2P live video streaming system a 456 polluter can introduce corrupted chunks. Each receiver integrates 457 into its playback stream the polluted chunks it receives from its 458 other neighbors. Since the peers forwards chunks to other peers, the 459 polluted content can potentially spread through much of the P2P 460 streaming network. 462 PPSP.SEC.REQ-5: PPSP SHOULD support identifying badly behaving peers, 463 and exclude or reject them from the P2P streaming system. 465 PPSP.SEC.REQ-6: PPSP MUST prevent peers from DoS attacks which will 466 exhaust the P2P streaming system's available resource. 468 Given the prevalence of DoS attacks in the Internet, it is important 469 to realize that a similar threat could exist in a large-scale 470 streaming system where attackers are capable of consuming a lot of 471 resources with just a small amount of effort. 473 PPSP.SEC.REQ-7: PPSP SHOULD be robust, i.e., when centralized tracker 474 fails the P2P streaming system SHOULD still work by supporting 475 distributed trackers. 477 PPSP.SEC.REQ-8: Existing P2P security mechanisms SHOULD be re-used as 478 much as possible in PPSP, to avoid developing new security 479 mechanisms. 481 PPSP.SEC.REQ-9: Integrity of the streaming content in PPSP MUST be 482 supported to provide a peer with the possibility to identify 483 inauthentic media content (undesirable modified by other entities 484 rather than its genuine source). The corresponding checksum 485 distribution and verification scheme SHOULD scale well in P2P 486 streaming system and be robust against distrustful trackers/peers. 488 6. IANA Considerations 490 This document presently raises no IANA considerations. 492 7. Acknowledgements 494 The authors would like to thank many people for discussing P2P 495 streaming. We would particularly like to thank: Yingjie Gu, Haibin 496 Song, Xingfeng Jiang from Huawei, Hui Zhang, Jan Seedorf, Martin 497 Stiemerling from NEC Labs, Jun Lei from University of Goettingen, 498 James Seng from PPLive, Das Saumitra from Qualcomm, Christian Schmidt 499 from NSN, Akbar Rahman from Interdigital, Lingli Deng from China 500 Mobile, Johan Pouwelse, Arno Bakker and Wesley Eddy. 502 8. References 504 8.1. Normative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 8.2. Informative References 511 [PPLive] "www.pplive.com". 513 [PPStream] 514 "www.ppstream.com". 516 [UUSee] "www.uusee.com". 518 [Pando] "www.pando.com". 520 [I-D.ietf-ppsp-survey] 521 Gu, Y., Zong, N., Zhang, H., Zhang, Y., Lei, J., 522 Camarillo, G., Liu, Y., Montuno, D., and X. Lei, "Survey 523 of P2P Streaming Applications", draft-ietf-ppsp-survey-02 524 (work in progress), July 2011. 526 [I-D.ietf-alto-protocol] 527 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 528 draft-ietf-alto-protocol-09 (work in progress), June 2011. 530 [I-D.ietf-ppsp-problem-statement] 531 Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang, 532 "Problem Statement of P2P Streaming Protocol (PPSP)", 533 draft-ietf-ppsp-problem-statement-05 (work in progress), 534 September 2011. 536 Authors' Addresses 538 Ning Zong (editor) 539 Huawei Technologies 540 Huawei Base, No.101 Software Avenue, Nanjing, China 542 Phone: +86 25 56624760 543 Email: zongning@huawei.com 545 Yunfei Zhang 546 China Mobile Communication Corporation 548 Phone: +86 13601032119 549 Email: zhangyunfei@chinamobile.com 551 Victor Pascual 552 Acme Packet 553 Anabel Segura 10, Madrid 28108, Spain 555 Email: VPascual@acmepacket.com 556 Carl Williams 557 Consultant 558 Palo Alto, California 94306 560 Email: carlw@mcsr-labs.org 562 Lin Xiao 563 Nokia Siemens Networks 565 Phone: +86 10 84358977 566 Email: lin.xiao@nsn.com