idnits 2.17.1 draft-westerlund-avtext-sdes-hdr-ext-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 11, 2014) is 3454 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: 'RFC6776' is defined on line 517, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-02 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-12 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft B. Burman 4 Intended status: Standards Track Ericsson 5 Expires: May 15, 2015 R. Even 6 Huawei Technologies 7 M. Zanaty 8 Cisco Systems 9 November 11, 2014 11 RTP Header Extension for RTCP Source Description Items 12 draft-westerlund-avtext-sdes-hdr-ext-03 14 Abstract 16 Source Description (SDES) items are normally transported in RTP 17 control protocol (RTCP). In some cases it can be beneficial to speed 18 up the delivery of these items. Mainly when a new source (SSRC) 19 joins an RTP session and the receivers needs this source's relation 20 to other sources and its synchronization context, which are fully or 21 partially identified using SDES items. To enable this optimization, 22 this document specifies a new RTP header extension that can carry any 23 type of SDES items. 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 May 15, 2015. 42 Copyright Notice 44 Copyright (c) 2014 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 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5 66 4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 5 67 4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 5 68 4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6 69 4.2.1. One or Two Byte Headers . . . . . . . . . . . . . . . 6 70 4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 6 71 4.2.3. Transmission Considerations . . . . . . . . . . . . . 7 72 4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 8 73 4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 8.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 This specification defines an RTP header extension [RFC3550][RFC5285] 85 that can carry RTCP source description (SDES) items. By including 86 selected SDES items in an header extension the determination of 87 relationship and synchronization context for new RTP streams (SSRCs) 88 in an RTP session can be speeded up. Which relationship and what 89 information depends on the SDES items carried. This becomes a 90 complement to using only RTCP for SDES Item delivery. 92 First, some requirements language is defined. The following section 93 motivates why this header extension is sometimes required or at least 94 provides a significant improvement compared to waiting for regular 95 RTCP packet transmissions of the information. This is followed by a 96 specification of the header extension. Next, a sub-space of the 97 header-extension URN is defined to be used for existing and future 98 SDES items, and the existing SDES items are registered. 100 2. Definitions 102 2.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2.2. Terminology 110 This document uses terminology defined in "A Taxonomy of Grouping 111 Semantics and Mechanisms for Real-Time Transport Protocol (RTP) 112 Sources" [I-D.ietf-avtext-rtp-grouping-taxonomy] . In particular the 113 following definitions: 115 Media Source 117 RTP Stream 119 Media Encoder 121 Encoded Stream 123 Participant 125 3. Motivation 127 Source Description (SDES) items are being associated with a 128 particular SSRC and thus RTP stream. The source description items 129 provide various meta data associated with the SSRC. How important it 130 is to have this data no later than when receiving the first RTP 131 packets depends on the item itself. The CNAME item is one item that 132 is commonly needed if not at reception of the first RTP packet for 133 this SSRC, so at least by the time the first media can be played out. 134 If not, the synchronization context cannot be determined and thus any 135 related streams cannot be correctly synchronized. Thus, this is a 136 great example for the need to have this information early when a new 137 RTP stream is received. 139 The main reason for new SSRCs in an RTP session is that a media 140 sources are added. This either because an end-point is adding a new 141 actual media source, or additional participants in a multi-party 142 session being added to the session. Another reason for a new SSRC 143 can be an SSRC collision that forces the colliding parties to select 144 a new SSRC. 146 Returning to the case of rapid media synchronization, there exist an 147 RTP header extension for Rapid Synchronization of RTP Flows 148 [RFC6051]. That header extension carries the clock information 149 present in the RTCP sender report (SR) packets. It however assumes 150 that the CNAME binding is known, which can be provided via signaling 151 in some cases, but not all. Thus an RTP header extension for 152 carrying SDES items like CNAME is a powerful combination to enable 153 rapid synchronization in all cases. 155 The Rapid Synchronization of RTP Flows specification does provide an 156 analysis of the initial synchronization delay for different sessions 157 depending on number of receivers as well as on session bandwidth 158 (Section 2.1 of [RFC6051]). These results are applicable also for 159 other SDES items that have a similar time dependency until the 160 information can be sent using RTCP. Thus the benefit for reduction 161 of initial delay before information is available can be determined 162 for some use cases from these figures. 164 That document also discusses the case of late joiners, and defines an 165 RTCP Feedback format to request synchronization information, which is 166 another potential use case for SDES items in RTP header extension. 167 It would for example be natural to include CNAME SDES item with the 168 header extension containing the NTP formatted reference clock to 169 ensure synchronization. 171 Some new SDES items are currently proposed, which can all benefit 172 from timely delivery: 174 MID: This is a media description identifier that matches the value 175 of the SDP a=mid attribute, to associate RTP streams multiplexed 176 on the same transport with their respective SDP media description 177 as described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. 179 SRCNAME: This is a media source and encoding identifier to enable 180 support for simulcast and improve some scalable encoding usages 181 [I-D.westerlund-avtext-rtcp-sdes-srcname]. This SDES item could 182 be used both for new sources and late joiners. 184 APPID: This SDES item provides an application specific identifier 185 dynamically assigned to a particular RTP stream. The intention is 186 to provide a receiver with information about the current role of 187 the received RTP stream or its usage in an application 188 [I-D.even-mmusic-application-token]. Thus a particular ID can be 189 reassigned many times during the lifetime of an RTP session. This 190 puts additional timing requirements, not only for new sources and 191 late joiners, but also whenever the Application token is 192 reassigned to another stream. 194 Based on the above, there appear to be good reasons why an RTP header 195 extension for SDES items is worthwhile to pursue. 197 4. Specification 199 This section first specifies the SDES item RTP header extension 200 format, followed by some usage considerations. 202 4.1. SDES Item Header Extension 204 The RTP header extension scheme that allows for multiple extensions 205 to be included is defined in "A General Mechanism for RTP Header 206 Extensions" [RFC5285]. That specification defines both short and 207 long item headers. The short headers (One-byte) are restricted to 1 208 to 16 bytes of data, while the long format (Two-byte) supports a data 209 length of 0 to 255 bytes. Thus that RTP header extension format is 210 capable of supporting any SDES item from a data length perspective. 212 The ID field, independent of short or long format, identifies both 213 the type of RTP header extension and, in the case of the SDES item 214 header extension, the type of SDES item. The mapping is done in 215 signaling by identifying the header extension and SDES item type 216 using a URN, which is defined in the IANA consideration (Section 5) 217 for all existing SDES items. 219 4.1.1. One-Byte Format 221 The one-byte header format for an SDES item extension element 222 consists of the One-Byte header (defined in Section 4.2 of 223 [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length 224 field (len) that identifies how many bytes (len value +1) of data 225 that follows the header. The data part consists of len+1 bytes of 226 UTF-8 text. The type of text is determined by the ID field value and 227 its mapping to the type of SDES item. 229 0 1 2 3 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | ID | len | SDES Item text value ... | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 1 237 4.1.2. Two-Byte Format 239 The two-byte header format for an SDES item extension element 240 consists of the two-byte header (defined in Section 4.3 of 241 [RFC5285]), which consists of an 8-bit ID followed by an 8-bit length 242 field (len) that identifies how many bytes of data that follows the 243 header. The data part consists of len bytes of UTF-8 text. The type 244 of text is determined by the ID field value and its mapping to the 245 type of SDES item. 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | ID | len | SDES Item text value ... | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 2 255 4.2. Usage of the SDES Item Header Extension 257 This section discusses various usage considerations; which form of 258 header extension to use, the packet expansion, and when to send SDES 259 items in header extension. 261 4.2.1. One or Two Byte Headers 263 The RTP header extensions for SDES items MAY use either the one-byte 264 or two-byte header formats, depending on the text value size for the 265 used SDES items. The one-byte header SHOULD be used when all non 266 SDES item header extensions supports the one-byte format and all SDES 267 item text values contain at most 16 bytes. Note that the RTP header 268 extension specification does not allow mixing one-byte and two-byte 269 headers for the same RTP stream (SSRC), so if the value size of any 270 of the SDES items value requires the two-byte header, the all other 271 header extensions MUST also use the two-byte header format. 273 For example using CNAMEs that are generated according to "Guidelines 274 for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" 275 [RFC7022], using short term persistent values, and if 96-bit random 276 values prior to base64 encoding are sufficient, then they will fit 277 into the One-Byte header format. 279 4.2.2. MTU and Packet Expansion 281 The RTP packet size will clearly increase when they include the 282 header extension. How much depends on which header extensions and 283 their data parts. The SDES items can vary in size. There are also 284 some use-cases which require transmitting multiple SDES items in the 285 same packet to ensure that all relevant data reaches the receiver. 286 An example of that is when you need both the CNAME, a SRCNAME and an 287 appId plus the rapid time synchronization extension from RFC 6051. 288 Such a combination is quite likely to result in at least 16+3+1+8 289 bytes of data plus the headers, which will be another 8 bytes for 290 one-byte headers, thus in total 36 bytes. 292 The packet expansion can cause an issue when it cannot be taken into 293 account when producing the RTP payload. Thus an RTP payload that is 294 created to meet a particular IP level Maximum Transmission Unit 295 (MTU), taking the addition of IP/UDP/RTP headers into account but 296 excluding RTP header extensions suddenly exceeds the MTU, resulting 297 in IP fragmentation. IP fragmentation is known to negatively impact 298 the loss rate due to middleboxes unwilling or not capable of dealing 299 with IP fragments. 301 As this is a real issue, the media encoder and payload packetizer 302 should be flexible and be capable of handling dynamically varying 303 payload size restrictions to counter the packet expansion caused by 304 header extensions. If that is not possible, some reasonable worst 305 case packet expansion should be calculated and used to reduce the RTP 306 payload size of all RTP packets the sender transmits. 308 4.2.3. Transmission Considerations 310 The general recommendation is to only send header extensions when 311 needed. This is especially true for SDES items that can be sent in 312 periodic repetitions of RTCP throughout the whole session. Thus, the 313 different usages (Section 4.2.4) have different recommendations. 314 First some general considerations for getting the header extensions 315 delivered to the receiver: 317 1. The probability for packet loss and burst loss determine how many 318 repetitions of the header extensions will be required to reach a 319 targeted delivery probability, and if bust loss is likely what 320 dispersion would be needed to avoid getting multiple header 321 extensions lost in a single burst. 323 2. How early the SDES item information is needed, from the first 324 received RTP data or only after some set of packets are received, 325 can guide if the header extension(s) should be in all of the 326 first N packets or be included only once per set of packets, for 327 example once per video frame. 329 3. The use of RTP level robustness mechanisms, such as RTP 330 retransmission [RFC4588], or Forward Error Correction, e.g., 331 [RFC5109] may treat packets differently from a robustness 332 perspective, and SDES header extensions should be added to 333 packets that get a treatment corresponding to the relative 334 importance of receiving the information. 336 In summary, the number of header extension transmissions should be 337 tailored to a desired probability of delivery taking the receiver 338 population size into account. For the very basic case, N repetitions 339 of the header extensions should be sufficient, but may not be 340 optimal. N is selected so that probability of delivery of at least 341 one out of the N reaches the target value when calculating 1-P^N, 342 where P is the probability of packet loss. For point to point or 343 small receiver populations, it might also be possible to use 344 feedback, such as RTCP, to determine when the information in the 345 header extensions has likely reached all receivers. 347 4.2.4. Different Usages 349 4.2.4.1. New SSRC 351 A new SSRC joins an RTP session. As this SSRC is completely new for 352 everyone, the goal is to ensure that all receivers with high 353 probability receives the information in the header extension. Thus 354 header extension transmission strategies that allow some margins in 355 the delivery probability should be considered. 357 4.2.4.2. Late Joiner 359 In a multi-party RTP session where one or a small number of receivers 360 join a session where the majority of receivers already have all 361 necessary information, the use of header extensions to deliver 362 relevant information should be tailored to reach the new receivers. 363 The trigger to send header extensions can for example either be RTCP 364 from new receiver(s) or an explicit request like the Rapid 365 Resynchronization Request defined in [RFC6051]. 367 4.2.4.3. Information Change 369 In cases when the SDES item text value is changed and the new SDES 370 information is tightly coupled to and thus needs to be synchronized 371 with a related change in the RTP stream, use of a header extension is 372 far superior to RTCP SDES. In this case it is equal or even more 373 important with timely SDES information than in the case of new SSRCs 374 (Section 4.2.4.1). Continued use of the old SDES information can 375 lead to really undesired effects in the application. Application 376 Token [I-D.even-mmusic-application-token] would be one such case. 377 Thus, header extension transmission strategies with high probability 378 of delivery should be chosen. 380 4.2.5. SDES Items in RTCP 382 As this RTP header extensions information, i.e. SDES Items can and 383 will be sent also in RTCP it is worth some reflections on this 384 interaction. There also exist the possibility to schedule a non- 385 regular RTCP packet transmission containing important SDES items if 386 one uses a RTP/AVPF based RTP profile. Depending on which mode ones 387 RTCP feedback transmitter is working on extra RTCP packets may be 388 sent as immediate or early packets, enabling more timely deliver of 389 SDES information. 391 There is however two aspects that differ between using RTP header 392 extension and any non-regular transmission of RTCP packets. First, 393 as the RTCP packet is a separate packet, there is no direct relation 394 and also no fate sharing between the relevant media data and the SDES 395 information. The order of arrival for the packets will matter. With 396 a header-extension the SDES items can be ensured to arrive if the 397 media data to played out arrives. Secondly, it is difficult to 398 determine if an RTCP packet is actually delivered. This, as the RTCP 399 packets lack both sequence number or a mechanism providing feedback 400 on the RTCP packets themselves. 402 5. IANA Considerations 404 This IANA section firstly proposes to: 406 o Reserve the SDES item RTP header extension defined in this 407 document for use with current and future SDES items. 409 o Register and assign the URN sub-space "urn:ietf:params:rtp- 410 hdrext:sdes:" in the RTP Compact Header Extensions registry. 412 The reason to require registering a URN within that sub-space is that 413 the name represent an RTCP Source Description item, where a 414 specification is strongly recommended. The formal policy is 415 maintained from the main space, i.e. Expert Review. 417 Secondly, it is proposed that only the current existing SDES items 418 that are critical for immediate media processing, and therefore 419 should fate share their delivery with RTP media, are registered for 420 usage in the RTP Compact Header Extensions registry : 422 URN SDES Item Reference 423 ================================================================== 424 urn:ietf:params:rtp-hdrext:sdes:cname CNAME [RFC3550] 426 6. Security Considerations 428 Source Description items may contain data that are sensitive from a 429 security perspective. There exist SDES items that are or may be 430 sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, 431 PHONE, LOC and H323-CADDR. Others may contain sensitive information 432 like NOTE and PRIV, while others may be sensitive from profiling 433 implementations for vulnerability or other reasons, like TOOL. The 434 CNAME sensitivity can vary depending on how it is generated and what 435 persistence it has. A short term CNAME identifier generated using a 436 random number generator may have minimal security implications, while 437 one of the form user@host has privacy concerns and one generated from 438 a MAC address has long term tracking potentials. 440 The above security concerns may have to be put in relation to needs 441 of third party monitoring. In RTP sessions where any type of 442 confidentiality protection is enabled, the SDES item header 443 extensions SHOULD also be protected per default. This implies that 444 to provide confidentiality, users of SRTP need to implement encrypted 445 header extensions per [RFC6904]. Commonly, it is expected that the 446 same security level is applied both RTCP packets carrying SDES items, 447 as a RTP header extension containing a SDES item. If the security 448 level is different it is important to consider the security 449 properties as the worst in each aspect for the different 450 configurations. 452 As the SDES items are used by the RTP based application to establish 453 relationships between RTP streams or between an RTP stream and 454 information about the originating Participant, there SHOULD be strong 455 requirements on integrity and source authentication of the header 456 extensions. If not, an attacker can modify the SDES item value to 457 create erroneous relationship bindings in the receiving application. 459 7. Acknowledgements 461 The authors likes to thanks the following individuals for feedback 462 and suggestions; Colin Perkins. 464 8. References 466 8.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 472 Jacobson, "RTP: A Transport Protocol for Real-Time 473 Applications", STD 64, RFC 3550, July 2003. 475 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 476 Header Extensions", RFC 5285, July 2008. 478 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 479 Real-time Transport Protocol (SRTP)", RFC 6904, April 480 2013. 482 8.2. Informative References 484 [I-D.even-mmusic-application-token] 485 Even, R., Lennox, J., and Q. Wu, "The Session Description 486 Protocol (SDP) Application Token Attribute", draft-even- 487 mmusic-application-token-03 (work in progress), April 488 2014. 490 [I-D.ietf-avtext-rtp-grouping-taxonomy] 491 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 492 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 493 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 494 rtp-grouping-taxonomy-02 (work in progress), June 2014. 496 [I-D.ietf-mmusic-sdp-bundle-negotiation] 497 Holmberg, C., Alvestrand, H., and C. Jennings, 498 "Negotiating Media Multiplexing Using the Session 499 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 500 negotiation-12 (work in progress), October 2014. 502 [I-D.westerlund-avtext-rtcp-sdes-srcname] 503 Westerlund, M., "RTCP Source Description Item SRCNAME to 504 Label Individual Media Sources", draft-westerlund-avtext- 505 rtcp-sdes-srcname-03 (work in progress), October 2013. 507 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 508 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 509 July 2006. 511 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 512 Correction", RFC 5109, December 2007. 514 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 515 Flows", RFC 6051, November 2010. 517 [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information 518 Reporting Using a Source Description (SDES) Item and an 519 RTCP Extended Report (XR) Block", RFC 6776, October 2012. 521 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 522 "Guidelines for Choosing RTP Control Protocol (RTCP) 523 Canonical Names (CNAMEs)", RFC 7022, September 2013. 525 Authors' Addresses 527 Magnus Westerlund 528 Ericsson 529 Farogatan 6 530 SE-164 80 Stockholm 531 Sweden 533 Phone: +46 10 714 82 87 534 Email: magnus.westerlund@ericsson.com 536 Bo Burman 537 Ericsson 538 Kistavagen 25 539 SE-164 80 Stockholm 540 Sweden 542 Phone: +46 10 714 13 11 543 Email: bo.burman@ericsson.com 545 Roni Even 546 Huawei Technologies 547 Tel Aviv 548 Israel 550 Email: roni.even@mail01.huawei.com 552 Mo Zanaty 553 Cisco Systems 554 7100 Kit Creek 555 RTP, NC 27709 556 USA 558 Email: mzanaty@cisco.com