idnits 2.17.1 draft-ott-avtcore-rtcp-overlay-multicast-02.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 == Line 230 has weird spacing: '...ies and media...' -- The document date (March 8, 2012) is 4424 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5117 (ref. '5') (Obsoleted by RFC 7667) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group V. Singh 3 Internet-Draft J. Devadoss 4 Intended status: Informational J. Ott 5 Expires: September 9, 2012 Aalto University 6 I. Curcio 7 Nokia 8 March 8, 2012 10 Real-time Transport Control Protocol (RTCP) in Overlay Multicast 11 draft-ott-avtcore-rtcp-overlay-multicast-02.txt 13 Abstract 15 The Real-time Transport Control Protocol(RTCP) is designed to operate 16 along with Real-time Transport Protocol(RTP) in unicast, single- 17 source multicast and any-source multicast environments. With the 18 availability of overlay multicast and Application Layer 19 Multicast(ALM), the suitability of RTCP in such environments need to 20 be analyzed. The applicability of the existing RTCP reporting 21 architectures in overlay multicast and ALM environments are 22 investigated and the new features that may be required are discussed 23 in this document. 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 September 9, 2012. 42 Copyright Notice 44 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overlay Multicast . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Classifying feedback reporting mechanism . . . . . . . . . . . 5 63 5. Classifying overlay multicast topologies and 64 media/overlay operations . . . . . . . . . . . . . . . . . . . 6 65 6. RTP Entities in an overlay multicast network . . . . . . . . . 6 66 7. Applicability of RTCP reporting as defined in RFC 3550 . . . . 8 67 8. Applicability of RTCP with unicast feedback target . . . . . . 9 68 9. Desirable features of RTCP in overlay multicast . . . . . . . 10 69 10. An example explaining the issues . . . . . . . . . . . . . . . 10 70 11. Endpoint Reporting . . . . . . . . . . . . . . . . . . . . . . 11 71 12. Hop-by-hop RTCP reporting . . . . . . . . . . . . . . . . . . 12 72 13. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 12 73 14. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 16. Normative References . . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 RTP [2] provides transport mechanisms suitable for unicast, any- 81 source multicast and single-source multicast. RTP is used to carry 82 audio and video streams together with the RTP control protocol to 83 provide periodic feedback about the media streams received in a 84 specific duration. The RTCP reporting interval is defined as part of 85 the RTCP and depends on the number of participants, type of 86 participants(sender or receiver) and the operating environment of the 87 session(point to point or multicast). 89 The RFC3550 [2] specifies the maximum RTCP bandwidth to be 5% of the 90 media bit rate. In point to point sessions, each participant gets a 91 equal share of 2.5% of the media bit rate to be used for RTCP. In 92 multicast (including any-source multicast and source-specific 93 multicast) sessions, the senders usually share 25% of the allocated 94 RTCP bandwidth and the receivers share the remaining 75% of the RTCP 95 bandwidth. The RTCP bandwidth share may be modified using RFC 3556 96 [4], but will generally be kept small so as to have a smooth media 97 stream flow. 99 In a multicast session, the RTCP reports are multicast so that each 100 participant can receive the RTCP reports from every other participant 101 and thus obtain a "global" view of the multicast session. This, 102 however, requires multicast connectivity between all peers and thus 103 cannot be applied to Source-specific Multicast (SSM) [6]. Specific 104 RTCP extensions were developed for SSM [7] introducing a mechanism of 105 RTCP reporting where the RTCP reports are unicast to a feedback 106 target. This mechanism is specifically applicable in scenarios where 107 many-to-many group communication is not available or not desired or a 108 sender-controlled summarized reporting is desired. RTCP reports are 109 unicast to a feedback target specified during initialization or 110 inside RTCP reports. The RTCP reporting interval calculation 111 specified in RTCP Extension for SSM uses the same mechanisms as 112 specified in RFC3550 [2]; the distribution source may send RTCP RSI 113 reports to control the rate at which RTCP reports are generated by 114 the receivers. The aforementioned rules for bandwidth modifications 115 apply as well. 117 Recent interest in overlay multicasting and ALM -- to substitute for 118 the lack of globally available native IP any-source multicast -- 119 motivates also carrying RTP-based media streams in such environments. 121 In ALM, the participating nodes form a distribution tree to forward 122 the data. ALM involves the use of different mechanisms to construct 123 and maintain the distribution tree. In overlay multicast, individual 124 multicast enabled networks are connected by virtual unicast links. 125 Overlay multicast involves mechanisms to construct optimal 126 interconnection of virtual links. An ALM can be viewed as a sub 127 class of overlay multicast, if the individual multicast enabled 128 networks have only one participating node. So, further in this 129 document, when we refer to overlay multicast it also includes ALM. 130 Depending on the abstraction chosen for the overlay multicast, the 131 RTP/RTCP entities using it may or may not be aware of the hop-by-hop 132 forwarding of the packets: 134 If they are not, regular any-source multicast operation of RTP and 135 RTCP as per RFC 3550 is a workable, yet possibly not optimal 136 solution. 138 If RTP entities are aware of the forwarding process, additional RTCP 139 reporting and aggregation mechanisms may be applied and the existing 140 RTCP reporting mechanisms need to be investigated for their 141 applicability in overlay multicast 143 In either case, in an overlay multicast environment, using RTP to 144 transport media streams will be straightforward, 146 In this document, we take a very first stab at reviewing the RTCP 147 reporting mechanism specified in RFC3550 [2] and the RTCP Extension 148 for SSM to find its applicability in the overlay multicast 149 environment. We also discuss on the specific characteristics of the 150 overlay multicast and the type of reporting that is desired on such 151 environments. This document also complements the RTP topologies 152 overview [5]. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in BCP 14, RFC 2119 [1] 159 and indicate requirement levels for compliant implementations. 161 The terminology defined in RTP [2], the RTP Profile for Audio and 162 Video Conferences with Minimal Control [3], and the RTCP Extension 163 for SSM [7], apply. 165 For the time being, in this document, by overlay multicast we refer 166 to a multicast overlay offering media distribution from a single 167 source, analogous to SSM. 169 3. Overlay Multicast 171 In overlay multicast, the media streams are multicast over an network 172 of virtual links that is constructed using mechanisms in line with 173 the requirements of the application using the overlay. The 174 construction and maintenance of the overlay involves mechanisms for 175 bootstrapping the new participant to the overlay, routing, pro- 176 active/reactive repair, improving scalability and recovery from loss 177 of a forwarding node or a virtual link. In this document, these 178 mechanisms are further referred to as overlay operation. As the 179 overlay network is formed by the participating nodes, the loss of a 180 participating node brings change in the network structure. So, there 181 is an inherent instability in the overlay multicast which are 182 addressed by the overlay operation. 184 In overlay multicast, the participating nodes can use mechanisms for 185 providing error resilience and congestion control that can 186 proactively adapt or reactively repair the media streams depending on 187 the receiver metrics reported by the nodes below its hierarchy. In 188 this document, the error resilience mechanisms together with 189 congestion control techniques are further referred to as media 190 operation. 192 The media operation depends on the metrics (reported reception 193 quality) reported by the participants. The overlay operation can 194 depend on different types of metrics and may also include the media 195 quality metrics like round trip time, observed packet loss, jitter 196 etc. As the overlay operation depends on the application using the 197 overlay, there can be significant overlap with the metrics used by 198 media operation. 200 Using RTP in overlay multicast does not require any change to its 201 specification. Every participating node that receives the RTP packet 202 replicates the packet and sends down the distribution tree. RTCP SR 203 follows the same path as RTP, so it does not bring in changes with 204 its use in overlay multicast. In the case of RTCP RR, it reports the 205 receiver's perceived media quality and it carries significant data 206 based on which the algorithms of media and/or overlay operation can 207 operate. 209 The multicast overlay maintenance mechanisms may operate entirely 210 independent of RTCP reporting, they may choose to leverage parts of 211 the RTCP reporting, or they may rely entirely on RTCP. In this 212 document, we are concerned about the operation of RTCP reporting in 213 such an environment and we do not take (at this point) any position 214 on the way the overlay operates. 216 4. Classifying feedback reporting mechanism 218 Any feedback reporting mechanism in a session with n participants can 219 be classified into one of the following categories. 220 o (i) 1 to 1 reporting 221 o (ii) 1 to n reporting 222 o (iii) 1 to m reporting (m < n, every node reports to m nodes) 223 An example of '1 to 1' reporting is RTCP in SSM with unicast feedback 224 target (and, of course, in case of point-to-point sessions). An 225 example of '1 to n' reporting is RTCP in multicast mode as specified 226 in RFC 3550. In further sections, we shall be referring to these 227 mechanisms while discussing the applicability of a RTCP reporting 228 model. 230 5. Classifying overlay multicast topologies and media/overlay 231 operations 233 The effectiveness of a chosen RTCP reporting model, directly depends 234 on the type of overlay multicast topology, type of the media/overlay 235 operation and the number of participants in the session. Therefore, 236 when considering the applicability of a RTCP reporting model, they 237 need to be evaluated against the every possible combinations of 238 overlay multicast topology, media and overlay operation. 240 The overlay multicast topologies can be broadly classified into two 241 categories. 242 o (i) Overlay multicast, with no or very minimal overlay 243 operations(virtual links are statically configured) 244 o (ii) Overlay multicast, that relies on overlay operations to 245 dynamically configure distribution tree. 247 The overlay and media operations can be classified into two 248 categories. 249 o (i) Centralized: A single entity decides on the type of media/ 250 overlay operations. 251 o (ii) Distributed: At any instant more than one entity is 252 attempting to perform media/overlay operation. 254 6. RTP Entities in an overlay multicast network 256 The below figure represents a sample overlay multicast network. In 257 this section, we see how the RTP entities can be used to describe a 258 overlay multicast network. 260 o(0) -Media source 261 / \ 262 / \ 263 _________ o(OMN1) o(OMN2) OMN -> Overlay Multicast Node 264 |I P | \\ /\ 265 |multicast| || / \ 266 |network | || / \ 267 --------- || OMN5 OMN6 ___ OMN7 268 _____|| \ 269 / \ \___ OMN8 270 ___o(OMN3) \ (OMN4)____ 271 | IP | \o IP | 272 |multicast| |multicast| 273 |network | |network | 274 --------- --------- 276 Figure 1: A sample overlay multicast topology 278 Describing an Overlay Multicast Node (OMN) using RTP entities: Each 279 OMN can be considered as a combination of a RTP media handler and a 280 RTP translator. The purpose of the translator is to replicate and 281 forward the streams to different network destinations and to handle 282 RTCP reports. The media handler receives RTP streams, processes 283 received RTCP reports and generates RTCP receiver reports. 285 Role of RTP Translator in forwarding RTP streams: The RTP translator 286 in each OMN forwards the received RTP packets(from its parent node) 287 to all virtual links it is connected with. For example, RTP 288 translator in OMN1 forwards RTP packets to its RTP media handler, 289 OMN3, OMN4 and the IP multicast network it is connected with. 291 Role of RTP Translator in handling RTCP reports: When there is no 292 change to the media encoding, the RTP translator uses the straight 293 case of Replicate and Forward mechanism. 295 Replicate and Forward: The RTP translator replicates and forwards the 296 RTCP RR received from one virtual link to all other virtual links. 297 Below, we explain using OMN1 as example. The RTP translator in OMN1 298 receives RTCP RR from, 299 o the media handler(which is within the same node) 300 o the native multicast network 301 o OMN3 302 o OMN4 303 o parent OMN (which is forwarding the RTCP RRs received from the 304 other virtual links, it is connected with) 306 To explain the RTCP forwarding rules, we take an sample event where 307 the translator in OMN1 receives a RTCP RR from IP multicast network. 309 The event response shall be that, it is forwarded to the media 310 handler(within OMN1), OMN3, OMN4 and to the parent node(in the case 311 of OMN1, it is media source). In this way, all participating nodes 312 in the session shall receive RTCP RR from all other participating 313 nodes. 315 In the overlay multicast scenario, the RTP translator in an OMN can 316 be extended to do other operations, such as, filtering and 317 aggregating RTCP reports, etc. But to realize it, the scope and 318 definitions of an RTP translator needs to be analyzed. (TBD) 320 7. Applicability of RTCP reporting as defined in RFC 3550 322 If this reporting mechanism is to be used in an overlay multicast, 323 then the RTP translator in each node replicates and forwards the RTCP 324 reports on all (virtual) links except the incoming (virtual) link. 325 It is a form of '1 to n' reporting, where all participants get a copy 326 of the RTCP report sent by every other participant. Now, let us look 327 at the effectiveness of this reporting model in the overlay multicast 328 environment. 330 With the increase in number of receivers, the RTCP reporting interval 331 increases. The larger the reporting interval, fewer the options 332 available for media operation. For example, with 'x' number of 333 participants, it can be possible to do retransmission based on an 334 RTCP report indicating a lost packet. But with the increasing number 335 of participants (say n*x), the interval gets bigger by n times 336 leading to fewer options of error repair mechanisms. In IP 337 multicast, the error resilience mechanisms like adaptive FEC, 338 retransmission can be performed only by the source or one designated 339 participant/observer. But in the case of overlay multicast, there 340 are more options available to deploy these mechanisms at intermediary 341 nodes which become an inherent part of the forwarding tree. 342 Furthermore, the importance of overlay operation increases with 343 increasing number of participants: the larger the number of nodes, 344 the greater the importance of overlay operation in maintaining 345 stability i.e., the importance of the reports that influence the 346 quality of the overlay operation grows. 348 The proportional relationship of number of nodes with the RTCP 349 reporting interval was designed to limit the bandwidth consumed by 350 the RTCP and provide scalability so as to evolve as a multicast 351 session with many number of participants. But in the overlay 352 multicast scenario, with the reducing number of reports per time unit 353 the quality of the overlay is reduced due to reduced effectiveness of 354 media and overlay operation. 356 In contrast to any-source multicast, however, the RTCP reports sent 357 by a particular node are not automatically received by all other 358 nodes. Instead, the RTCP reports travel along the virtual links 359 formed between participating nodes. This may be used to limit their 360 spread and may allow for mechanisms improving overall efficiency of 361 RTCP reporting. 363 Thus, while the total number of participants in an RTP session limits 364 the RTCP bandwidth consumption within 5% of the media session, this 365 limit may not need to be applied the total consumption across the 366 entire overlay multicast, but be maintained in local regions only. 368 8. Applicability of RTCP with unicast feedback target 370 If RTCP/SSM reporting mechanism is to be used in an overlay 371 multicast, then the RTCP RR reports are unicast to a designated node 372 that is either within or outside the overlay multicast. It is a form 373 of '1 to 1' reporting and here we discuss on its applicability in the 374 overlay multicast. 376 RTCP/SSM defines the use of a single distribution source in 377 conjunction with one or more feedback targets. If multiple feedback 378 targets are to be used, their respective setup and coordination is 379 outside the scope of the RTCP/SSM specification. Conceptually, 380 however, the RTCP/SSM mechanisms support the idea of hierarchical 381 report aggregation and forwarding, even though the RTP media as well 382 as the RTCP sender reporting distribution paths are supposed to use 383 SSM multicasting at the IP layer. This notion of RTCP aggregation 384 would need to become more explicit, but could provide a first basis 385 for realizing overlay multicast. 387 Overlay multicast also provides explicit support for using 388 intermediary (participating nodes in the distribution tree) media 389 error resilience mechanisms. Stepwise RTCP aggregation would also 390 make the necessary feedback information available to the individual 391 intermediate nodes and could thus provide the hook for invoking 392 repair mechanisms. 394 The (kind of) centralized reporting and centralized decision making 395 in RTCP/SSM would need to be expanded to allow for more flexible 396 media and/or overlay operation and, in particular, would need to 397 cover the assignment and maintenance of feedback targets as regular 398 part of the overlay operation. 400 An interesting issue is whether this source-specific type of 401 operation could be expanded later towards multi-source operation in 402 order to support any-source multicast overlays as well. While RTCP/ 403 SSM seems to be a promising starting point, this latter step is left 404 for further study. 406 9. Desirable features of RTCP in overlay multicast 408 The following list is an initial set of desirable functions for 409 media/overlay operation: 410 o Need for a mechanism of RTCP reporting, where the reporting 411 interval is decoupled from the number of participants in the media 412 session. But still the original reason behind this linkage 413 (limiting the RTCP bandwidth consumption) can be maintained 414 through other suitable mechanisms. In essence, fine-granular RTCP 415 reporting could be confined to subgroups while the global 416 bandwidth limitation is still maintained. 417 o Overlay multicast brings in the option to use media operation at 418 intermediate nodes. With more frequent reporting, their 419 effectiveness increases. So, to increase the reporting frequency 420 and at the same time limit the bandwidth consumption, a RTCP RR 421 reporting mechanism that provides the feature of '1 to m'(n > m, n 422 - number of participants in the session) reporting is needed. By 423 choosing a small m, the RTCP RR reporting frequency can be 424 increased as it is directed only to a small subset of 425 participating nodes. Such subset reporting could be carried out 426 at a single hierarchy level inside an overlay multicast or across 427 multiple such levels. 428 o Media operation should be able to leverage the additionally 429 available reporting information to optimize performance (for error 430 control, possibly congestion control, etc.) 431 o Overlay operation can be either centralized or distributed. For 432 example, the decisions related to overlay operations can be made 433 only by a single node for the whole network or can be distributed 434 to many groups, with each groups making the decisions depending on 435 the collected metrics. In the later form of overlay operation, 436 the availability of '1 to m' reporting provides timely and more 437 precise information for the algorithms used in the overlay 438 operation. As each group can act independent from the other 439 groups, there may not be a need for reporting across the groups 440 but there may be a need for a higher reporting frequency within 441 the group. 443 10. An example explaining the issues 445 We take the below example for explaining the desired form of RTCP 446 reporting in overlay multicast. 448 o(0) -Media source 449 / \ 450 / \ 451 / \ 452 o(1) o(2) 453 /|\ /|\ 454 / | \ / | \ 455 o o o o o o 456 (3)(5)(7) (4)(6)(8) 458 Figure 2: A sample overlay multicast topology 460 In the above figure, the nodes {1, 3, 5 and 7} and {2, 4, 6 and 8} 461 are considered as a group with node 1 and 2 acting as their 462 respective group leaders. The overlay operation involves changing 463 the group leader based on the metrics reported by the participating 464 nodes. 466 In the above example, the nodes {1, 3, 5 and 7} are more interested 467 in RTCP reports from the nodes within their group rather than in the 468 RTCP reports from {2 or 4 or 6 or 8}. If the RTCP reporting interval 469 is supposed to be proportional to the number of participants in the 470 session, then the individual groups see reduced reporting due to the 471 increase in the number of participants. This reduces the 472 effectiveness of both media and overlay operation. 474 The paper "Construction of an Efficient Overlay Multicast 475 Infrastructure for Real-time Applications" is an overlay multicast 476 solution, that dynamically re-arranges the distribution tree based on 477 the metrics reported(or measured with) 'm' other nodes. 478 (http://www.ieee-infocom.org/2003/papers/37_03.PDF) 480 11. Endpoint Reporting 482 For a Distribution Source (DS), RFC5760 [7] defines a feedback 483 reflection mechanism and a feedback summary mechanism (RSI). In the 484 case of overlay networks, each node forwards RTP packets and 485 therefore, also generates and receives RTCP packets. Therefore, each 486 node SHOULD also perform feedback reflection or summarization. 487 However, unlike the RFC5760 [7], where the DS transmits the resulting 488 feedback over the multicast RTCP channel, the intermediate node in an 489 overlay networks needs to transmit the feedback packets both upstream 490 and downstream. In the section, feedback information refers to 491 Receiver Reports or RSI, as the case may be. In a given setup the 492 feedback information between intermediate nodes and distribution 493 source MUST be consistent and the leaf nodes MUST always send RRs. 495 In this section, we describe the behavior of an intermediate node. 496 o Local Information: is the node's receiver report. Typically, this 497 information will be used to create summary reports (RSI) or 498 compounded with other reports (in case of feedback reflection). 499 The local information is always sent upstream to its parent node. 500 o Source Information: Feedback information received from an upstream 501 node is sent downstream. The node MUST add or summarize its local 502 information before transmitting it downstream. 503 o Sub-tree Information: Feedback information received from the child 504 nodes is summarized or reflected in both upstream and downstream 505 directions. The node need not add or summarize its local 506 information before transmitting the sub-tree information. 508 12. Hop-by-hop RTCP reporting 510 In an overlay network, the Sender Reports (SR) originate from the 511 source and percolate through the distribution tree to the leaf nodes. 512 Sinnce the intermediate nodes just forward RTP packets, they do not 513 generate SRs. Furthermore, they may either send RRs or RSIs 514 downstream, this information is insufficient to measure the 515 performance (of the links) between two consecutive intermediate 516 nodes. To assist with better performance measurements, each 517 intermediate node MUST generate an Intermediate Forwarder Report 518 (IFR) and send it to its parent and child nodes -- the IFR carries 519 loss and discard metrics, and NTP Timestamps for making RTT 520 measurements. 522 13. Packet Formats 524 TBD. 526 14. Security Considerations 528 TBD. 530 15. IANA Considerations 532 TBD 534 16. Normative References 536 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 537 Levels", BCP 14, RFC 2119, March 1997. 539 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 540 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 541 RFC 3550, July 2003. 543 [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 544 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 546 [4] Casner, S., "Session Description Protocol (SDP) Bandwidth 547 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 548 July 2003. 550 [5] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 551 January 2008. 553 [6] Bhattacharyya, S., "An Overview of Source-Specific Multicast 554 (SSM)", RFC 3569, July 2003. 556 [7] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 557 Protocol (RTCP) Extensions for Single-Source Multicast Sessions 558 with Unicast Feedback", RFC 5760, February 2010. 560 Authors' Addresses 562 Varun Singh 563 Aalto University 564 School of Electrical Engineering 565 Otakaari 5 A 566 Espoo, FIN 02150 567 Finland 569 Email: varun@comnet.tkk.fi 571 Jegadish Devadoss 572 Aalto University 573 School of Electrical Engineering 574 Otakaari 5 A 575 Espoo, FIN 02150 576 Finland 578 Email: jegadish@netlab.tkk.fi 579 Joerg Ott 580 Aalto University 581 School of Electrical Engineering 582 Otakaari 5 A 583 Espoo, FIN 02150 584 Finland 586 Email: jo@comnet.tkk.fi 588 Igor D.D. Curcio 589 Nokia 590 P.O. Box 88 (Tieteenkatu 1) 591 Tampere, FIN 33721 592 Finland 594 Email: igor.curcio@nokia.com