idnits 2.17.1 draft-chesterfield-avt-rtcpssm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 9 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 47: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 48: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 654: '...level attributes MUST be used to indic...' RFC 2119 keyword, line 660: '...st reflection -- MUST be used to indic...' RFC 2119 keyword, line 664: '...nicast ljs -- MUST be used to indic...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 141 has weird spacing: '... an optiona...' == Line 189 has weird spacing: '...10. The metho...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'NLB' on line 851 == Unused Reference: '8' is defined on line 809, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-avt-rtp-new-10 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-10 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. '2') == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-02 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-20) exists of draft-ietf-msdp-spec-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-msdp-spec (ref. '6') == Outdated reference: A later version (-01) exists of draft-shepherd-ssm232-00 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-08) exists of draft-holbrook-idmr-igmpv3-ssm-00 -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2434 (ref. '10') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '11') -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-09) exists of draft-ietf-avt-srtp-01 == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-srcfilter-00 Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 Internet Draft Julian Chesterfield 3 draft-chesterfield-avt-rtcpssm-02.txt AT&T Internet Research 4 Joerg Ott 5 Tellique Kommunikationstechnik GmbH 7 November, 2001 8 Expires: May, 2002 10 RTCP Extension for Single Source Multicast Sessions with 11 Unicast RTCP feedback 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as work in progress. 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 35 This document specifies a modification to the Real-time Transport 36 Control Protocol to enable the operation of RTP/RTCP using unicast 37 RTCP feedback for Single Source multicast sessions such as Source 38 Specific Multicast (SSM) Communication where the traditional model 39 of Any Source Multicast (ASM) group communication of many to 40 many is either not possible or not preferred. This draft can be 41 applied to any group communication which might benefit from a sender 42 controlled summarised reporting mechanism. It extends [1], section 6 43 which defines the RTP session group control channel. 45 1. Conventions and Acronyms 47 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 48 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 49 document, are to be interpreted as described in RFC 2119. 51 2. Introduction 53 RTP [1] provides a real-time transport mechanism suitable for unicast 54 or Internet Standard Multicast communication between multimedia 55 applications. Typical uses are for real-time or near real-time 56 group communication via audio and video data streams. An important 57 component of the RTP protocol is the control channel, defined 58 as the Real-Time Control Protocol (RTCP). RTCP involves the 59 periodic transmission of control packets between group members in a 60 session, enabling the distribution or calculation of session specific 61 information such as packet loss, and round trip time calculation to 62 other hosts. An additional advantage of providing a control channel 63 for a session is that a third-party session monitor can listen to the 64 traffic and establish network conditions and diagnose faults based on 65 receiver locations. 67 RTP was designed to operate in a unicast mode or in the traditional 68 mode of Any Source Multicast (ASM) Group communication which 69 encompasses a network which supports both one to many and many to 70 many communication via a common group address in the range 224.0.0.0 71 through 239.255.255.255. Typical routing protocols that enable such 72 communication are Distance Vector Multicast Routing Protocol (DVMRP) 73 [2] or Protocol Independent Multicast (PIM) [3][4] Sparse/Dense Mode 74 in combination with an Inter-domain routing protocol such as 75 Multicast Border Gateway Protocol (MBGP) [5] with Multicast Source 76 Discovery (MSDP) [6]. Such routing protocols enable a host to join a 77 single Multicast group address and send to or receive traffic from 78 all members in the group with no prior knowledge of membership. In 79 order to enable such a service in the network, however there is a 80 great deal of complexity involved at the routing level. The Source 81 Specific Multicast (SSM) [7] Model has the advantage of removing a 82 great deal of the routing complexity involved in multicast group 83 creation and source information distribution. The disadvantage of SSM 84 with respect to Real-time traffic using RTP is that the 85 simplification to the routing protocols removes the ability for any 86 member of the group to communicate with any other member of the group 87 without an explicit SSM (Source, Group) or unicast join to that host. 88 The solution proposed in this draft defines a new method for 89 distributing control information amongst all members in a multicast 90 session and is designed to operate under any multicast group 91 communication scenario. It is, however, of particular benefit to SSM 92 sessions in the absence of receivers being able to communicate with 93 each other. The RTP data stream protocol itself is unaffected. 95 The basic architectural models to which this feedback method could 96 apply are: 98 a) SSM groups with a single sender. This is the main motivation 99 behind the unicast RTCP feedback mechanism and allows SSM groups 100 which do not have many to many communication capability, 101 traditionally available in ASM multicast groups to still receive RTP 102 data streams and operate on them in the usual manner. SSM adopts the 103 notion of a sender data channel which provides a one to many 104 communication facility from the source to all the receivers in the 105 group. The feedback is unicast to the source on the standard RTCP 106 port. 108 b) One to many broadcast networks such as satellite communication 109 typically using a terrestrial link low bandwidth return channel or a 110 broadband cable link. This architecture differs very little from the 111 SSM channel concept, but most likely will require a translator of 112 some kind to render the RTP data stream onto the satellite or cable 113 distribution channel. 115 c) ASM with a single sender. An SDP session announcement type 116 identifies a session as having a single sender receiving unicast RTCP 117 feedback. Receivers join the multicast group address and receive RTP 118 and RTCP data on the specified address/port combinations. The RTCP 119 feedback is directed to the source on the RTCP port. This model is 120 not considered to be more efficient than a standard multicast group 121 RTP communication scenario, and is therefore not recommended to 122 replace the traditional mechanism, however it might be useful in 123 helping to prevent overtaxing multicast routing infrastructure that 124 does not scale as efficiently. 126 SSM sessions are typically assigned a value in the group address 127 range 232.0.0.0 through 232.255.255.255, although this is not a 128 requirement. A session may be assigned any valid multicast address, 129 as long as the local network is configured to allow source specific 130 joins outside the suggested SSM range. In order for a host to receive 131 traffic from an SSM capable source, it must support the IGMPv3 132 multicast group membership reporting protocol which enables the host 133 to explicitly request traffic from a source,group pair. In this case, 134 the host is aware of the significance of the address range and is 135 therefore capable of identifying the unicast RTCP feedback session 136 requirements based on this knowledge. For sessions which take 137 advantage of the unicast feedback model but do not inherently need to 138 use it, it is anticipated that an SDP syntax will be defined. 140 The modifications proposed in this document are intended to provide 141 an optional replacement to the method of RTCP operation for sessions 142 which either require or may benefit from a new reporting structure. 143 For certain distribution networks, such as SSM networks, this may be 144 a requirement, however in other cases this is an optional feature 145 which may be used. 147 3. Basic Operation 149 This draft proposes two methods for enabling receiver feedback to 150 all members in a session. Each involves the unicasting of RTCP 151 packets to a source whose job it is to distribute the information 152 to the members of the group. The source must always be able to 153 communicate with all the other members in order for either mechanism 154 to work. 156 The first method, the 'Simple Feedback Model' is a basic mechanism 157 whereby all receiver reports are unicast to the source and 158 subsequently forwarded by the source to all receivers on the 159 multicast feedback channel. The advantage of using this method is 160 that an existing receiver implementation requires little modification 161 in order to operate in this new state. Instead of forwarding Receiver 162 Reports to a multicast address, it uses a unicast address and still 163 receives RTCP traffic in the usual manner. This method also has the 164 advantage of being backwards compatible with RTP/RTCP implementations 165 which do not support unicast feedback to the source and operate using 166 the standard multicast group communication model, ASM. In a session 167 that is using ASM, such a receiver would multicast Receiver Reports 168 to the group address and port+1 as stated in [1]. This would still be 169 received by all receivers. In a session using an SSM distribution 170 network, the network would prevent any data from the receiver being 171 distributed further than the first hop router. Additionally, any data 172 heard from this receiver by other hosts on the same subnet should be 173 filtered out by the host IP stack and will therefore not cause any 174 problems with respect to the calculation of Receiver RTCP bandwidth 175 since this receiver will not be heard by any other members. 177 The second method, the 'Sender Feedback Summary Model' is a 178 summarised reporting scheme that provides savings in bandwidth by 179 consolidating all the receiver reports into one summary packet which 180 is then distributed to all the receivers. The advantage of this 181 scheme is apparent for large group sessions where the basic 182 forwarding mechanism outlined above would create a large amount of 183 packet replication in order to forward all the information to all the 184 receivers. The basic operation of the scheme is the same as the first 185 method, however it requires that all the members in the session 186 understand the new summarised packet format outlined in section 7.1. 188 To differentiate between the two reporting mechanisms, a new SDP 189 identifier is created and discussed in section 10. The method of 190 reporting must be decided prior to the start of the session, a 191 distribution source may not change the method during a session. 193 4. Definitions 195 Distribution Source: In order for unicast feedback to work, there 196 must only be one session distribution source for any subset of 197 receivers to which RTCP feedback is directed. Heterogeneous 198 networks comprised of ASM multiple sender groups, unicast 199 only clients and/or SSM single sender/receiver groups may be 200 connected via translators or mixers (see section 9 for details on 201 this) to create a single source group. However, in order for 202 unicast feedback to work, only one source must be responsible for 203 distributing the RTP stream and forwarding RTCP information to all 204 receivers. 206 RTP and RTCP Channels: The data distribution from the source to the 207 receivers whether via an SSM {source,group} identifier, a standard 208 ASM multicast group or a unicast reflector, is referred to as the 209 RTP and RTCP channels. These channels are differentiated via the 210 port numbers as [port] and [port + 1] for RTP and RTCP 211 respectively. See [1] for further explanation of the port 212 numbering. 214 Unicast RTCP Feedback Target: For a session defined as having a 215 distribution source A, on ports n and n+1, the unicast feedback 216 target is the IP address of Source A on port n+1. 218 SSRC: Synchronization source. A 32-bit value that uniquely identifies 219 each member in a session. See [1] for further information. 221 Report blocks: In the RTCP design [1] it is encouraged to stack 222 multiple report blocks in Sender and Receiver report packets. In 223 this way, a variable size packet is created which can include 224 information from one source pertaining to multiple sources in the 225 group. The concept of report blocks is extended in this draft to 226 encompass Loss Jitter Summary packets in which a source can 227 optionally stack multiple reports into one packet in order to 228 provide additional feedback on the RTCP traffic received from the 229 group. 231 5. Packet types 233 The RTCP packet types defined in [1] are: 235 type description Payload number 236 SR sender report 200 237 RR receiver report 201 238 SDES source description 202 239 BYE goodbye 203 240 APP application-defined 204 242 These remain unmodified. In addition to the exisiting types, two new 243 packet types are introduced. Further information on each of these is 244 provided in this draft. The packet types are: 246 type description Payload number 247 RSI Receiver Summary Information [see section 12] 248 LJS Loss and Jitter Summary [see section 12] 250 6. Simple feedback model 252 6.1 Packet Formats 254 For this mechanism, the packet types used remain the same as for 255 standard RTCP feedback in [1]. Receivers generate Receiver Reports 256 with information on the quality of the stream received from the 257 source. The source must create Sender Reports which include timestamp 258 information for stream synchronisation and round trip time 259 calculation. Both senders and receivers are required to send SDES 260 packets as outlined in [1]. The usual rules for BYE and APP packets 261 also apply. 263 6.2 Distribution Source behaviour 265 For the simple feedback model, the source provides a simple packet 266 reflection mechanism. It is the default behaviour for any 267 distribution source and is the minimum requirement for acting as a 268 source to a group of receivers using unicast RTCP feedback. 270 The source may not stack report blocks received from different SSRCs 271 into one packet for retransmission to the group. Every RTCP packet 272 from each receiver must be reflected individually. 274 The source must listen for unicast RTCP data sent to the RTCP port. 275 All unicast data received on this port must be forwarded to the 276 group on the multicast RTP channel. Any multicast data received on 277 this port must not be forwarded but processed as defined in [1]. 279 The reflected traffic should not be included in the transmission 280 interval calculation by the source. In other words the source should 281 not consider reflected packets as part of it's own control data 282 bandwidth allowance. The algorithm for computing the allowance is 283 explained in section 9. The control bandwidth traffic included in the 284 calculation includes any Sender reports to the group, along with any 285 additional SDES and APP packets. 287 If an application wishes to use APP packets, it is recommended that 288 the 'simple feedback model' be used since it is likely that all 289 receivers in the session will need to hear the APP specific packets. 290 This decision must be made in advance of the session and indicated in 291 the SDP announcement. 293 6.3 Receiver behaviour 295 Receivers listen on the RTP and RTCP channels for data. Each receiver 296 calculates it's share of the receiver bandwidth based on the 297 standard rules i.e. 75% of the RTCP bandwidth is divided equally 298 between all unique SSRCs in the session. See section 9 for further 299 information on this. When a receiver is eligible to transmit, it 300 sends a unicast Receiver Report packet to the RTCP port of the 301 distribution source. 303 7. Sender feedback summary model 305 In the sender feedback summary mode, the sender is required to 306 summarise the information received from all the Receiver Reports 307 generated by the receivers and place the information into summary 308 reports. The sender must send at least 1 Receiver Summary Information 309 packet for each reporting interval. The sender can additionally stack 310 Loss Jitter Summary (LJS) reports after the RSI packet. Each LJS 311 packet corresponds to the initial RSI packet and acts as an 312 enhancement to the basic summary information required by the 313 receivers to calculate their reporting time interval. For this 314 reason LJS packets are not required but recommended. RSI and LJS 315 packets are sent in addition to the standard Sender Reports and SDES 316 packets outlined in [1]. 318 7.1 Packet Formats 320 The Sender feedback summary model introduces 2 new packet formats. 321 The Receiver Summary Information packet (RSI) which must be sent by a 322 source if the summarised feedback mechanism is selected and the 323 optional Loss and Jitter Summary report packet (LJS) that may be 324 appended to the RSI packet to provide more detailed information on 325 the overall session characteristics reported by all receivers. 327 7.1.1 RSI: Receiver Summary Information RTCP Packet 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |V=2|P| SC | PT | length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | SSRC of Sender | 334 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 335 | group size | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | AFL | HCNL | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Highest interarrival jitter | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Receiver RTCP Bandwidth | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | collision SSRC #1 | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | . . . | 347 The RSI packet consists of a main report block modeled along the same 348 lines as a receiver report with optional LJS blocks appended. The 349 first 4 bytes of header extension follow the standard RTP header 350 outline. This ensures backwards compatibility with older versions 351 which may not understand the RSI packet format but can read the 352 length field indicating the end of the report block. The following 353 fields are included: 355 The fields "V", "P", and "length" have the same meaning as per [1]. 357 SC: 5 bits 358 The number of collision SSRC entries towards the end of the report 359 block. A value of 0 is allowed. 361 SSRC: 32 bits 362 The synchronisation source identifier for the originator of the 363 summary report packet. 365 group size: 32 bits 366 This field provides the sender's view of the number of receivers 367 in a session. This should include the sender itself and any other 368 senders potentially connected to the session e.g. via a 369 mixer/translator gateway. The group size is calculated according 370 to the rules outlined in [1]. 372 Average fraction lost (AFL): 8 bits 373 The average fraction lost indicated by receiver reports forwarded 374 to this source, expressed as a fixed point number with the binary 375 point at the left edge of the field. 377 Highest cumulative number of packets lost (HCNL): 24 bits 378 Highest 'cumulative number of packets lost' value out of all RTCP 379 RR packets since the last RSI from any of the receivers. 381 Highest interarrival jitter: 32 bits 382 Highest 'interarrival jitter' value out of all RTCP RR packets 383 since the last RSI from any of the receivers. 385 receiver bandwidth: 32 bits 386 indicates the maximum bandwidth allocated to any single receiver 387 for sending RTCP data relating to the session. This is a fraction 388 value indicating a percentage of the session bandwidth, expressed 389 as a fixed point number with the binary point at the left edge of 390 the field. 392 collision SSRC: n x 32 bits 393 the final fields in the packet are used to identify any SSRCs 394 that are duplicated within the group. Usually this is handled by 395 the hosts upon detection of the same SSRC, however since receivers 396 no longer have a global view of the session, the collision 397 algorithm is handled by the source. SSRCs that collide are listed 398 in the packet and it is the responsibility of the receiver(s) to 399 detect the collision and select another ID. 401 7.1.2 LJS: Loss Jitter Summary RTCP Packet 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 |V=2|P| LJSC | PT | Length | header 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | SSRC of Sender | 408 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 409 | NLB | LF | MIL | MAL | NJB | JF | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Minimum Jitter Value | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Maximum Jitter Value | report 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 415 | Loss Buckets | 1 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Loss Buckets cont... | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Jitter Buckets | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Jitter Buckets cont... | 422 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 423 | ... | report 424 | ... | block 425 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 2 427 Loss Jitter Summary Count (LJSC): 5 bits 428 The number of Loss Jitter Summary report blocks contained in this 429 packet 430 Number of Loss Buckets (NLB): 4 bits 431 The number of Loss Buckets over the reserved 64 bit space. 432 Possible values are 0, 1, 2, 4, 8, 16 434 Loss Factor (LF): 4 bits 435 Indicates the multiplicative factor to be applied to the Loss 436 Bucket values. Possible values are 1 - 15. 438 Minimum Loss Value (MIL): 8 bits 439 Minimum loss value. In combination with the Maximum Loss value 440 indicates the range covered by the Loss Bucket values. Possible 441 values are 0 - 99. The Minimum Loss Value must always be less than 442 the maximum, expressed as a fixed point number with the binary 443 point at the left edge of the field. 445 Maximum Loss Value (MAL): 8 bits 446 Maximum loss value. In combination with the Minimum Loss value 447 indicates the range covered by the Loss Bucket values. Possible 448 values are 1 - 100. The maximum Loss Value must always be greater 449 than the minimum, expressed as a fixed point number with the 450 binary point at the left edge of the field. 452 Number of Jitter Buckets (NJB): 4 bits 453 The number of Jitter Buckets over the reserved 64 bit space. 454 Possible values are 0, 1, 2, 4, 8, 16 456 Jitter Factor (JF): 4 bits 457 Indicates the multiplicative factor to be applied to the Jitter 458 Bucket values. Possible values are 1 - 15. 460 Minimum Jitter Value (MIJ): 32 bits 461 Minimum jitter value. In combination with the Maximum jitter value 462 indicates the range covered by the jitter Bucket values. The 463 Minimum jitter Value must always be less than the maximum. 465 Maximum Jitter Value (MAJ): 32 bits 466 Maximum jitter value. In combination with the Minimum jitter value 467 indicates the range covered by the jitter Bucket values. The 468 Maximum jitter Value must always be greater than the minimum. 470 Loss Buckets: 16*4 bits - 8*8 bits - 4*16 bits - 2*32 bits - 1*64 471 bits 472 Loss Bucket. The size and number of buckets depends upon the value 473 of NLB. This indicates the division of the 64 bit space. Depending 474 upon whether NLB is 16, 8, 4, 2 or 1, the size of each LB will be 475 4, 8, 16, 32 or 64 bits respectively. Each value must be 476 multiplied by the Loss Factor. 478 Jitter Buckets: 16*4 bits - 8*8 bits - 4*16 bits - 2*32 bits - 1*64 479 bits 480 Jitter Bucket. The size of the bucket depends upon the value of 481 JLB. This indicates the division of the 64 bit space. Depending 482 upon whether JLB is 16, 8, 4, 2 or 1, the size of each JB will be 483 4, 8, 16, 32 or 64 bits respectively. Each value must be 484 multiplied by the Jitter Factor. 486 7.2 Distribution Source behaviour 488 The length field of the RSI packet must be calculated over the length 489 of the whole packet, using the 490 method defined in [1]. The group size must be included in the RSI 491 packet. The source should also calculate the Receiver RTCP bandwidth 492 field. Typically this value will be calculated as outlined in [1] 493 using the group size and session bandwidth as variables. This field 494 does however provide the source with the capability to control the 495 amount of feedback from the receivers and can be increased or 496 decreased based on the requirements of the source. Regardless of the 497 value selected by the source for the RTCP bandwidth field, the source 498 must continue to forward Sender reports and RSI packets at the rate 499 allowed by its bandwidth allocation. See section 9 for further 500 details. 502 In order to identify SSRC collisions, the source is responsible for 503 maintaining a record of each SSRC and the correpsonding IP address 504 within at least one reporting interval in order to differentiate 505 between clients. It is recommended that an updated list of more than 506 one interval be maintained to increase accuracy. This mechanism 507 does not prevent the possibility of collisions since IP addresses may 508 not be unique e.g. due to NAT gateways, however it greatly increases 509 the capability to detect collisions. In the event that collisions are 510 not detected, the effect will be an innaccurate impression of the 511 group size on the part of the source. Since the statistical 512 probablility that collisions will both occur and be undetectable is 513 very low, the clients would have to randomly select the same SSRC and 514 be located behind the same NAT gateway, this should not be a 515 significant concern. 517 For the LJS packet, the source must decide which are the most 518 significant values to convey. The packet format provides flexibility 519 in the amount of detail conveyed by the data points. There is a 520 trade-off between the granularity of the data and the accuracy based 521 on the factorisation values, the number of buckets and the min and 522 max values. In order to focus on a particular region of the 523 distribution, the source can adjust the minimum and maximum values 524 and either increase the number of buckets and possibly the 525 factorisation, or decrease the number of buckets and provide more 526 accurate values. See Appendix B for detailed examples on how to 527 convey RTCP reports as LJS information. 529 The results should correspond as near as possible to the values 530 received during the interval since the last report. 532 The source may stack as many report blocks as required in order to 533 convey loss and jitter information. 535 7.3 Receiver behaviour 537 The receiver must process RSI packets and adapt session parameters 538 such as the RTCP bandwidth based on the information received. The 539 receiver no longer has a global view of the session, and will 540 therefore be unable to receive information from individual receivers 541 aside from itself. However, the information portrayed by the source 542 can be extremely detailed, providing the receiver with an accurate 543 view of the session quality overall, without the processing overhead 544 associated with listening to and analysing all the receiver reports. 546 The SSRC collision list must be checked against the SSRC selected by 547 the receiver to ensure there are no collisions. The group size value 548 provides the receiver with the data necessary to calculate it's share 549 of the RTCP bandwidth. This share of the bandwidth may be overridden 550 by the 'Receiver RTCP Bandwidth' field. This field provides the 551 source with the capability to control the amount of feedback from the 552 receivers. 554 The receiver can handle the LJS data as desired. This data is most 555 useful in providing the receiver with a more global view of the 556 conditions experienced by other receivers, and enables the client to 557 place itself within the distribution and establish the extent to 558 which it's reported conditions correspond to the group reports as a 559 whole. Appendix A provides further information and examples of 560 data processing at the receiver. 562 The receiver should assume that any report blocks in the same packet 563 correspond to the same data set received by the source during the 564 last reporting time interval. This applies to packets with multiple 565 blocks, where each block conveys a different range of values. 567 8. Mixer/Translator issues 569 The original RTP specification allows for the use of mixers and 570 translators in an RTP session which help to connect heterogeneous 571 networks into one session. There are a number of issues, however 572 which are raised by the unicast feedback model proposed in this 573 document. The term 'mixer' refers to devices that provide data stream 574 multiplexing where multiple sources are combined into one stream. 575 Conversely, a translator does not multiplex streams, but simply 576 acts as a bridge between two distribution mechanisms, e.g. a unicast 577 to multicast network translator. Since the issues raised by this 578 draft apply equally to either a mixer or translator, they are 579 referred to from this point onwards generically as a gateway. 581 A gateway between distribution networks in a session must ensure that 582 all members in the session receive all the relevant traffic to enable 583 the usual operation by the clients. A typical use may be to connect 584 an older implementation of an RTP client with an SSM distribution 585 network, where the client is not capable of unicasting feedback to 586 the source. In this instance the gateway must join the session on 587 behalf of the client and send and receive traffic from the session to 588 the client. Certain hybrid scenarios may have different requirements. 590 8.1 Use of a mixer-translator 592 The gateway must adhere to the SDP descriptor for the single source 593 session and use the feedback mechanism indicated. Receivers should be 594 aware that by introducing a gateway into the session, more than one 595 source may potentially be active in a session since the gateway may 596 be forwarding traffic from either multiple unicast sources or from an 597 ASM session to the SSM receivers. Receivers should still forward 598 unicast RTCP reports in the usual manner to the distribution source, 599 which in this case would be the gateway itself. It is recommended 600 that the simple packet reflection mechanism be used under these 601 circumstances since attempting to coordinate RSI + LJS reporting 602 between more than one source may be complicated unless the gateway is 603 capable of undertaking the summarisation itself. 605 8.2 Encryption and Authentication issues 607 Encryption and security issues are discussed in detail in section 11. 608 A gateway must be able to follow the same security policy as the 609 client in order to unicast forward RTCP data to the source, and it 610 therefore must be able to apply the same authentication and/or 611 encryption policy required for the session. Transparent bridging, 612 where the gateway is not acting as the distribution source, and 613 subsequent unicast feedback to the source is only allowed if the 614 gateway can conduct the same source authentication as required by the 615 receivers. 617 9. Transmission interval calculation 619 The Control Traffic Bandwidth referred to in [1] is an arbitrary 620 amount which is intended to be supplied by a session management 621 application (e.g. [9]) or decided based upon the bandwidth of a 622 single sender in a session. A receiver must calculate the number of 623 other members in a session based upon either it's own SSRC count 624 determined by the forwarded Receiver Reports, or from the RSI report 625 from a sender. 627 The RTCP transmission Interval calculation remains the same as in the 628 original RTP specification [1]. In the original specification, the 629 senders are allocated 1/4 of the control traffic bandwidth if 630 they number 25% or less than the group size. Otherwise the allocation 631 for senders is the percentage of senders to group size. The remaining 632 bandwidth is allocated to the receivers to be divided evenly amongst 633 the group. The source 634 should calculate the transmission interval for RSI + LJS packets out 635 of it's 1/4 of the control traffic bandwidth with a minimum 636 transmission interval of 5 seconds. 638 10. SDP Extensions 640 The Session Description Protocol (SDP) is used as a means to describe 641 media sessions in terms of their transport addresses, codecs, and 642 further attributes. Providing RTCP feedback via unicast as specified 643 in this document constitutes another session parameter. To make 644 receivers aware that they are supposed to provide their feedback 645 via unicast, this needs to be indicated in the session description. 646 Similarly, parameters of SSM RTCP feedback -- such as the mode of 647 summarizing information at the sender and the target unicast address 648 to send feedback information to -- needs to be provided. This section 649 defines the necessary SDP parameters (that also need to be registered 650 with IANA). 652 10.1 SSM RTCP Session Identification 654 A new session level attributes MUST be used to indicate the use of 655 unicast instead of multicast feedback: "rtcp:unicast". 657 This attribute uses one further parameter to specify the mode of 658 operation. 660 rtcp:unicast reflection -- MUST be used to indicate packet reflection 661 by the RTCP target (without further 662 processing). 664 rtcp:unicast ljs -- MUST be used to indicate the "Loss Jitter 665 Summary" mode of operation 667 rtcp:unicast rsi -- MUST be used to indicate the "Receiver 668 Summary Information" mode of operation. 670 10.2 SSM Source Specification 672 In addition, in an SSM RTCP session, the sender(s) need to be 673 indicated for both source-specific joins to the multicast group 674 as well as for addressing RTCP packets to. 676 This is done following the proposal for SDP source filters 677 documented in draft-ietf-mmusic-sdp-srcfilter-00.txt [15]. 679 From this specification, only the inclusion mode ("a=incl:") 680 MUST be used for SSM RTCP. 682 There SHOULD be exactly one "a=incl:" attribute listing the 683 address of the sender. The RTCP port MUST be derived from the 684 m= line of the media description. 686 11. Security Considerations 688 Packet bombing of unsuspecting victims via a fake SDP or SSM address 689 is a real concern for this architecture. For this reason it is 690 required that a security policy be applied to any session which 691 involves unicast feedback of data to a single IP address. At a 692 minimum, it is recommended that source authentication be conducted by 693 every receiver prior to unicasting data. 695 An additional concern is the problem of fake RSI + LJS packets which 696 could increase the RTCP bandwidth sent to the source. Any security 697 policy must address this as a minimum requirement. 699 Receiver authentication would also be beneficial, since Denial of 700 Service attacks by generating false Receiver Reports is also 701 possible. The consequences of this are not as drastic, affecting only 702 the group size and transmission interval calculation and therefore 703 the integrity and frequency of the reported data. 705 The issue of source feedback implosion should not occur in the event 706 that receivers practice the standard RTP/RTCP guidelines for starting 707 sessions and for implementing the scaling algorithm based on the 708 number of hosts. An additional issue which should be addressed, but 709 is beyond the scope of this document is the potential for host 710 anonymity which is facilitated by Source Specific Multicast and adds 711 additional security measures into group communication. By explicitly 712 controlling receiver feedback, a source could solicit feedback from 713 the receivers in a scalable way without the need to inform all 714 members in a session of the group membership. 716 11.1 Security Requirements Outline 718 In order to overcome the issues outlined above, there are some 719 minimal and recommended policies which must be addressed: 721 - The information providing the unicast feedback address 722 needs to be authenticated as being from a trusted source. 724 - Data integrity of the RTCP traffic from the source, particularly 725 RSI + LJS packets is also required. 727 - Receiver authentication is recommended in order to ensure 728 integrity of RTCP traffic and group size. 730 - Data encryption of both the RTCP and RTP streams are optional 731 but recommended for this draft. 733 Ideally, a public key infrastructure would provide the mechanism 734 necessary to ensure the trusted authentication of distributed SDP 735 announcements. Since this is not generally available, the following 736 precautions are highly recommended. 738 The primary danger of the use of a fake session announcement must be 739 addressed by the distribution media itself since SDP remains 740 independent of the underlying mechanism and provides no facility to 741 combat authentication and/or message integrity. The most common 742 methods of distributing SDP messages are the Session Announcement 743 Protocol (SAP)[11], a web page or an email message. All of these 744 mechanisms provide the capability to authenticate the source of the 745 announcement: 747 - SAP has the option to include an authentication header in 748 the message which assures the integrity of the message contents 749 and identifies the source of the message via public key 750 encryption. 752 - A secure web server can be used to provide Secure Sockets Layer 753 (SSL) [12] authentication of the web site containing the SDP 754 message. 756 - An email message can be signed using a public key mechanism to 757 ensure data integrity. 759 All of these methods rely on a level of trust in order to validate 760 the public key of the originator of the message. The establishment of 761 trust is beyond the scope of this document, however it is recommended 762 that receivers should only trust an originating source if a digital 763 certificate signed by a trusted third party such as a Signing 764 Authority is available or if the key has been received prior to the 765 session via some secure out-of-band method. 767 A number of options are available to address the issue of session 768 data integrity, the most obvious being the use of Secure RTP (SRTP) 769 [14] or a more general security framework such as TESLA [13]. 770 Adopting such a scheme to ensure that both source traffic and 771 receiver messages are encrypted would prevent the generation of fake 772 RTCP traffic to the group or from any unsolicited receivers. 774 12. IANA Considerations 776 Based on the guidelines suggested in [10], this document proposes 2 777 new RTCP data payload types for consideration by IANA. 779 Furthermore, four new SDP media-level attributes are defined in 780 section 10. 782 13. References 784 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 785 "RTP - A Transport Protocol for Real-time Applications," Internet 786 Draft, draft-ietf-avt-rtp-new-10.txt, Work in Progress, July 2001. 788 [2] Pusateri, T, "Distance Vector Multicast Routing Protocol", 789 draft-ietf-idmr-dvmrp-v3-10, August 2000 791 [3] Fenner, B, Handley, M, Holbrook, H, Kouvelas, I, "Protocol 792 Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification 793 (Revised)", draft-ietf-pim-sm-v2-new-02.txt, March 2001 795 [4] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM-DM" 796 draft-ietf-pim-refresh-02.txt, November, 2000 798 [5] Thaler, D, Cain, B, "BGP Attributes for Multicast Tree 799 Construction", draft-ietf-idmr-bgp-mcast-attr-00.txt, February 1999 801 [6] Farinacci, D, Rekhter, Y, Meyer, D, Lothberg, P, Kilmer, H, 802 Hall, J, "Multicast Source Discovery Protocol (MSDP)", 803 draft-ietf-msdp-spec-06.txt, July 2000 805 [7] Shepherd, G, Luczycki, E, Rockell, R, "Source-Specific Protocol 806 Independent Multicast in 232/8", draft-shepherd-ssm232-00.txt, March 807 2000. 809 [8] Holbrook, H, Cain, B, "Using IGMPv3 For Source-Specific 810 Multicast", draft-holbrook-idmr-igmpv3-ssm-00.txt, July 2000. 812 [9] Session Directory Rendez-vous (SDR), developed at University 813 College London by Mark Handley and the Multimedia Research Group. 815 [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 816 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 818 [11] Handley, M, Perkins, C, Whelan, E, "Session Announcement 819 Protocol", (SAP), RFC 2974, October 2000. 821 [12] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 822 Netscape Communications Corp., Nov 18, 1996. 824 [13] Perrig, Canetti, Briscoe, Tygar, Song, "TESLA: Multicast Source 825 Authentication Transform", draft-irtf-smug-tesla-00.txt. 827 [14] E. Carrara, D. McGrew, M. Naslund, K. Norrman, D. Oran, "The 828 Secure Real Time Transport Protocol", draft-ietf-avt-srtp-01.txt. 830 [15] B. Quinn, "SDP Source-Filters", Internet Draft 831 draft-ietf-mmusic-sdp-srcfilter-00.txt, Work in Progress, May 2000. 833 13. Appendix 835 A LJS packet processing at the receiver 837 A.1 Algorithm 839 X values represent the loss percentage. 840 Y values represent the number of receivers. 842 Number of x values is the NLB value 843 xrange = MAL - MIL 844 First data point = MIL,first ydata 845 then 846 Foreach ydata => xdata += (MIL + (xrange / NLB)) 848 A.2 Pseudo-code 850 Packet Variables -> factor,NLB,MIL,MAL 851 Code variables -> xrange, ydata[NLB],x,y 853 xrange = MAL - MIL 854 x = MIL; 855 for(i=0;i