idnits 2.17.1 draft-ietf-rmt-flute-sdp-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Sep 12, 2012) is 4238 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3926 (Obsoleted by RFC 6726) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT R. Walsh 3 Internet-Draft J. Peltotalo 4 Intended status: Standards Track S. Peltotalo 5 Expires: March 16, 2013 Tampere University of Technology 6 I. Curcio 7 Nokia Research Center 8 H. Mehta 9 Sep 12, 2012 11 SDP Descriptors for FLUTE 12 draft-ietf-rmt-flute-sdp-03 14 Abstract 16 This document specifies the use of SDP to describe the parameters 17 required to begin, join, receive data from, and/or end FLUTE 18 sessions. It also provides a Composite Session SDP media grouping 19 semantic for grouping media streams into protocol-specific sessions, 20 such as multiple-channel FLUTE sessions. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 16, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 70 2.1. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. FLUTE Descriptors . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. FLUTE Protocol Identifier . . . . . . . . . . . . . . . . 7 73 3.2. Composite Session Semantics . . . . . . . . . . . . . . . 8 74 3.2.1. Composite Session Semantics for FLUTE Sessions . . . . 9 75 3.2.2. Composite Session Semantics for Protocols other 76 than FLUTE . . . . . . . . . . . . . . . . . . . . . . 10 77 3.3. Source IP Address . . . . . . . . . . . . . . . . . . . . 10 78 3.4. Transport Session Identifier . . . . . . . . . . . . . . . 11 79 3.5. Session Timing Parameters . . . . . . . . . . . . . . . . 12 80 3.6. Channelization Descriptors . . . . . . . . . . . . . . . . 12 81 3.6.1. Number of Channels . . . . . . . . . . . . . . . . . . 12 82 3.6.2. Destination IP Address and Port Number for Channels . 13 83 3.7. FEC Scheme . . . . . . . . . . . . . . . . . . . . . . . . 15 84 3.8. Content Description Pointer . . . . . . . . . . . . . . . 16 85 3.9. Security Parameters . . . . . . . . . . . . . . . . . . . 17 86 3.10. Bandwidth Specification . . . . . . . . . . . . . . . . . 17 87 3.10.1. Bandwidth Specification for Composite Sessions . . . . 18 88 3.11. SDP Specific Parameters . . . . . . . . . . . . . . . . . 18 89 4. SDP Syntax Examples . . . . . . . . . . . . . . . . . . . . . 19 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 6.1. Transport Protocol . . . . . . . . . . . . . . . . . . . . 23 93 6.1.1. Media formats ("fmt") . . . . . . . . . . . . . . . . 23 94 6.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 23 95 6.3. Composite Session Token to Differentiate FLUTE Sessions . 25 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 97 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 9.1. From draft-ietf-rmt-flute-sdp-02 to 100 draft-ietf-rmt-flute-sdp-03 . . . . . . . . . . . . . . . 28 101 9.2. From draft-ietf-rmt-flute-sdp-01 to 102 draft-ietf-rmt-flute-sdp-02 . . . . . . . . . . . . . . . 28 103 9.3. From draft-ietf-rmt-flute-sdp-00 to 104 draft-ietf-rmt-flute-sdp-01 . . . . . . . . . . . . . . . 28 105 9.4. From draft-mehta-rmt-flute-sdp-06 to 106 draft-ietf-rmt-flute-sdp-00 . . . . . . . . . . . . . . . 28 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 108 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 109 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 110 Appendix A. Use of FEC Attributes with RTP Sessions 111 (informative) . . . . . . . . . . . . . . . . . . . . 33 112 Appendix B. Further Design Logic for FEC-OTI Descriptors . . . . 34 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 115 1. Introduction 117 The Session Description Protocol (SDP) [RFC4566] provides a general- 118 purpose format for describing multimedia sessions in announcements or 119 invitations. SDP uses an entirely textual data format (the US-ASCII 120 subset of UTF-8 [RFC3629]) to maximize portability among transports. 121 SDP does not define a protocol, but only the syntax to describe a 122 multimedia session with sufficient information to participate in that 123 session. Session descriptions may be sent using arbitrary existing 124 application protocols for transport (e.g. FLUTE 125 [I-D.ietf-rmt-flute-revised], SAP [RFC2974], SIP [RFC3261], RTSP 126 [RFC2326], HTTP [RFC2616], email etc.). 128 SDP defines two protocol identifiers that represent unreliable 129 connectionless protocols. These are RTP/AVP and UDP. These are 130 appropriate choices for multimedia streams. [RFC4145] defines 131 protocol identifiers for connection-oriented reliable transports: TCP 132 and TCP/TLS. 134 This document defines two new protocol identifiers for File Delivery 135 over Unidirectional Transport (FLUTE) protocol 136 [I-D.ietf-rmt-flute-revised] and other required SDP attributes for 137 initiating a FLUTE session. The formal ABNF syntax [RFC5234] is used 138 for the attributes. This SDP syntax is independent of whether Any 139 Source Multicast (ASM) or Source Specific Multicast (SSM) is used to 140 route the media. 142 Note, this document may also be used to describe sessions of the 143 experimental FLUTE specification [RFC3926]. 145 2. Conventions Used in This Document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 RFC2119 [RFC2119]. 152 2.1. New Terms 154 SDP instance: A syntactically complete SDP description of an SDP 155 session, possibly stored in a single computer file. 157 Composite Session: An SDP mechanism that enables the grouping of 158 media lines in to distinct sessions, so that a single SDP instance 159 can describe multiple protocol-specific sessions. 161 3. FLUTE Descriptors 163 The FLUTE specification [I-D.ietf-rmt-flute-revised] describes the 164 optional and required parameters for a FLUTE session. This document 165 specifies the SDP parameters for FLUTE sessions that can be used for 166 the discovery of FLUTE download and/or service announcement sessions. 167 Listed below are the required and optional SDP parameters for FLUTE 168 sessions (the parameters introduced, or made mandatory, by this 169 specification but not inherited from the FLUTE specification are 170 marked with an asterisk "*"). 172 The required parameters are: 174 o The source IP address; 176 o The number of channels in the session; 178 o The destination IP address and port number for each channel in the 179 session; 181 o The Transport Session Identifier (TSI) of the session; 183 o An indication that the session is a FLUTE session; 185 * The start time and end time of the session. 187 The optional parameters are: 189 o FEC scheme (a subset of FEC Object Transmission Information); 191 o Some information that tells receiver in the first place, that the 192 session contains files that are of interest; 194 o Security parameters relevant for the session; 196 * Bandwidth specification. 198 (Note, the best practice to provide parameters for FLUTE's optional 199 content encoding of FDT Instances is in-band within FLUTE sessions 200 and is therefore not specified using SDP.) 202 (Note, out-of-band FEC Object Transmission Information useful for 203 FLUTE sessions is limited to SDP signaling of capabilities 204 requirements describing FEC Encoding ID(s) and FEC Instance ID(s) as 205 FLUTE provides header fields for machine configuration for object 206 reception. This specification also provides a "fec-oti-extension", 207 as an informative appendix, so that the same SDP syntax can be used 208 to describe sessions using protocols other than FLUTE that do not 209 have an in-band mechanism for FEC machine configuration.) 211 (Note, description of congestion control parameters are not in scope 212 of this document.) 214 The semantics of a FLUTE session within an SDP description differ 215 slightly from that of the well-establish RTP session descriptions. A 216 FLUTE session includes one or more FLUTE channels which are each a 217 distinct media stream. (Note, the SDP specification [RFC4566] use of 218 the term "media stream" is semantically equivalent to the FLUTE 219 specification use of the term "channel".) Generally, each RTP media 220 is recognized as a distinct RTP media session. Hence, to preserve 221 harmony with RTP media sessions within SDP descriptions, the optional 222 Composite Session mechanism is specified in this document, using the 223 SDP Grouping Framework [RFC5888]. 225 The description of these parameters in SDP is presented in the 226 following sections. 228 3.1. FLUTE Protocol Identifier 230 The following is the ABNF syntax for an "m=" line, as specified by 231 RFC4566 [RFC4566]: 233 media-field = "m=" media SP port ["/" integer] SP 234 proto 1*(SP fmt) CRLF 236 We define two new values for the "proto" sub-field: FLUTE/UDP and 237 FLUTE/UDP/ESP. The FLUTE/UDP protocol identifier specifies that the 238 session being described will use the FLUTE 239 [I-D.ietf-rmt-flute-revised] protocol on top of a UDP connection. 240 The FLUTE/UDP/ESP protocol identifier specifies that the session 241 being described will use the FLUTE [I-D.ietf-rmt-flute-revised] 242 protocol on top of a UDP connection and session security is achieved 243 by means of IPsec/ESP in transport mode [RFC4303]. 245 As described below, more than one FLUTE session may be described by a 246 single SDP instance using the Composite Session mechanism. 248 The fmt (format) list may be ignored for FLUTE. The fmt list of 249 FLUTE "m=" lines MAY contain a single "*" character to indicate that 250 miscellaneous and unspecified MIME types (file formats) are contained 251 in the FLUTE session. Use of any other values (MIME types) in a 252 FLUTE fmt list is out of scope of this specification. "0" is known to 253 be used in the fmt list to represent the same semantic as "*", in a 254 non-standardized way, and so implementers may take this into account. 255 An example of a FLUTE/UDP protocol identifier is shown in Section 4. 257 FLUTE is a general file delivery protocol and so it is not considered 258 necessary to identify a list of media types per FLUTE session or 259 channel in this session description specification. 261 3.2. Composite Session Semantics 263 The Composite Session mechanism enables the grouping of media lines 264 in to distinct sessions. The complete Composite Session semantics 265 are protocol-specific - as determined by the protocol id of the 266 grouped media lines. This section defines the Composite Session 267 semantic generically and protocol-id-independently. Subsection 268 3.2.1. defines the FLUTE/UDP and FLUTE/UDP/ESP protocol identifier 269 specific semantic. 271 This mechanism is useful where multiple FLUTE sessions are described 272 as part of a larger service or application, and so where maintaining 273 and delivering session descriptions together (with a shared delivery 274 fate) is good practice. It may also improve bandwidth efficiency by 275 eliminating repetition of redundant descriptors that would be 276 necessary with multiple discrete SDP instances. 278 The Composite Session mechanism inherits the "group" and "mid" 279 attributes from the SDP grouping framework [RFC5888] and introduces 280 the "CS" (Composite Session) token as a "semantics-extension". 282 When the Composite Session mechanism is used: the SDP grouping 283 framework [RFC5888] MUST be used (and requirements from that are 284 inherited); and the "CS" token MUST be used with the "group" 285 attribute to indicate a Composite Session grouping. The SDP grouping 286 framework declares groups at session-level and labels media (with the 287 "mid" attribute) at media-level. Hence, all media given "mid" values 288 that are identified in an "a=group:CS" line belong to the same 289 Composite Session group and inherit the grouping specified for these 290 mid values at session-level. 292 The first (leftmost and uppermost) mid value declared for a Composite 293 Session group is the Primary Media. Just as session-level attributes 294 are inherited to media-level declarations (unless specifically 295 overwritten by an additional media-level attribute), Primary Media 296 attributes SHALL be inherited to all media of a particular Composite 297 Session group. These primary media attributes (i.e. Composite 298 Session default attributes) SHALL be overwritten at media level (for 299 the specific media) where an attribute's syntax mandates this 300 behavior for media-level overwriting of SDP session-level attributes; 301 and media-level attribute overwriting of session level attribute 302 inheritance shall not be allowed otherwise. 304 3.2.1. Composite Session Semantics for FLUTE Sessions 306 When an SDP instance specifies only one FLUTE session, using the 307 Composite Session mechanism is OPTIONAL. When an SDP instance 308 specifies more than one FLUTE session, using the Composite Session 309 mechanism is REQUIRED. 311 The Composite Session provides an unambiguous way to define multiple 312 FLUTE sessions as distinct from multiple the media-sessions semantics 313 of RTP. It is used for describing more than one FLUTE session in an 314 SDP instance and so its general use and support in SDP are OPTIONAL. 315 For SDP instances which describe multiple FLUTE sessions, the 316 Composite Session semantics MUST be used. Whenever an SDP describes 317 just one FLUTE session with more than a single media stream of one 318 FLUTE protocol identifier (i.e. a FLUTE channel), use of the 319 Composite Session semantics is RECOMMENDED. 321 To support simple applications, as well as ensure harmony with FLUTE 322 SDP standards outside of the IETF [3GPP.26.346], when the Composite 323 Session mechanism is not used for media of the FLUTE/UDP or FLUTE/ 324 UDP/ESP protocol, exactly one FLUTE session is specified within the 325 SDP instance and all FLUTE/UDP or FLUTE/UDP/ESP media of that SDP 326 instance belong to the same FLUTE session (this is known as the 327 Restricted Behavior). 329 The Composite Session mechanism SHOULD NOT be used where the target 330 clients are expected to include simpler FLUTE SDP parsers, such as in 331 some releases of 3GPP MBMS [3GPP.26.346]. In this Restricted 332 Behavior only one media protocol SHALL be described in one SDP 333 instance (i.e. only FLUTE/UDP or only FLUTE/UDP/ESP or neither). 335 A partial example of using the Composite Session mechanism for FLUTE 336 is shown below. 338 339 a=group:CS 1 2 340 a=group:CS 3 341 m=application 12345 FLUTE/UDP * 342 a=mid:1 343 344 m=application 12346 FLUTE/UDP * 345 a=mid:2 346 347 m=application 56789 FLUTE/UDP * 348 a=mid:3 349 351 The example shows two groups with the 1st and 3rd media ("m=") lines 352 (mid values 1 and 3) being the Primary Media for each group 353 respectively. In the example, the media with mid value "2" inherits 354 attributes of the media with mid value "1".) Each of these groups 355 identifies a separate FLUTE Session. Several of the attributes 356 subsequently specified in this document use this feature of Primary 357 Media inheritance to all media of a Composite Session. 359 3.2.2. Composite Session Semantics for Protocols other than FLUTE 361 The Composite Session mechanism solves the problem of describing 362 multiple FLUTE sessions in a single SDP instance. However, this does 363 not place any restrictions on the use of the Composite Session 364 mechanism with transport protocols other than FLUTE/UDP or FLUTE/UDP/ 365 ESP, nor on whether a complete SDP would include media of other 366 transport protocols too. Specification of Composite Session 367 semantics beyond the use of FLUTE sessions is outside the scope of 368 this document. 370 3.3. Source IP Address 372 The Asynchronous Layered Coding (ALC) [RFC5775] and the Layered 373 Coding Transport (LCT) [RFC5651] specifications require that all the 374 channels of a single ALC/LCT session are from the same source IP 375 address. Hence, there MUST be exactly one source IP address per 376 FLUTE session, and therefore one source IP address per description of 377 a FLUTE session description. Restricted behavior is one source IP 378 address per SDP instance. Where multiple FLUTE sessions are 379 described within one SDP instance this means one source IP address 380 per Composite Session. 382 The source IP address MUST be defined according to the source-filter 383 attribute ("a=source-filter") [RFC4570], with the following 384 exceptions: 386 o The source-filter attribute MUST be included in any SDP instance 387 describing FLUTE sessions and per FLUTE session described. 389 o The number of source-filter attributes in any SDP describing FLUTE 390 sessions must be exactly equal to the number of FLUTE sessions 391 described in that SDP. 393 o In the restricted behavior of only one FLUTE session description 394 in an SDP and no use of the Composite Session mechanism: The 395 source-filter attribute MUST be in the session part of the session 396 description and MUST NOT be given per media. Note, the 397 requirement that there must not be more than a single source- 398 filter attribute in the session part is inherited from the SDP 399 Source Filter specification [RFC4570]. 401 o Where the Composite Session mechanism is used: The source-filter 402 attribute MUST be in the media part of Primary Media of each 403 distinct FLUTE session, and MUST NOT be given in other media 404 declarations but these, nor in the session-level part of the SDP. 406 o Exactly one source address is specified by any instance of this 407 attribute. Exactly one source address MUST be given in an 408 inclusive-mode "src-list". Exclusive-mode MUST NOT be used. 410 o The "*" value MUST be used for the "dest-address" sub-field, even 411 when the FLUTE session employs only a single channel (e.g. a 412 multicast group). 414 An example of the use of this attribute is: 416 a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9 418 This example uses the source-filter attribute to describe an IPv6 419 source address. 421 3.4. Transport Session Identifier 423 The combination of the TSI and the source IP address identifies a 424 FLUTE session. Each TSI MUST uniquely identify a FLUTE session for a 425 given source IP address during the time that the session is active 426 and also for a large time before and after the active session time. 427 This requirement is inherited from LCT [RFC5651]. Note, the SDP 428 specification [RFC4566] advises that sessions expire 30 minutes after 429 the session-end time given in the t-field. This should be considered 430 an absolute minimum interpretation of a "large time". TSI reuse is 431 NOT RECOMMENDED whenever possible (thus, making "large time" 432 unbounded regarding TSI reuse). 434 The TSI MUST be described by the "flute-tsi" attribute. 436 There MUST be exactly one occurrence of the "flute-tsi" attribute per 437 FLUTE session description of an SDP instance. 439 o The number of "flute-tsi" attributes in any SDP describing FLUTE 440 sessions must be exactly equal to the number of FLUTE sessions 441 described in that SDP. 443 o In the restricted behavior of only one FLUTE session description 444 in an SDP and no use of the Composite Session mechanism: The 445 "flute-tsi" attribute MUST be in the session part of the session 446 description and MUST NOT be given per media. A "flute-tsi" 447 attribute in the session-part SHALL be used to identify restricted 448 behavior. 450 o Where the Composite Session mechanism is used: The "flute-tsi" 451 attribute MUST be in the media part of Primary Media of each 452 distinct FLUTE session, and MUST NOT be given in other media 453 declarations but these, and MUST NOT be given in the session-level 454 part of the SDP. 456 The syntax for the attribute in ABNF is given below: 458 flute-tsi-line = "a=flute-tsi:" tsi CRLF 459 tsi = 1*DIGIT 461 Note, the range of values a TSI can adopt depends on the bit-length 462 of the TSI for a session as defined by RFC5651 [RFC5651]. 464 3.5. Session Timing Parameters 466 The SDP timing field "t=" [RFC4566] MUST be used to indicate the 467 FLUTE session start and end times. This value applies to all FLUTE 468 and transport sessions defined in a single SDP instance and, thus, 469 FLUTE sessions of different timing values need to be declared in 470 different SDP instances. 472 Note, implementers may assume reasonable clock synchronization 473 between SDP description, receiver wall clock and sender wall clock 474 (within 60 seconds) unless specified otherwise for a specific 475 deployment. The method to achieve this is beyond the scope of the 476 current specifications, but may use well known and mature approaches 477 such as SNTP [RFC5905]. 479 3.6. Channelization Descriptors 481 This section specifies the description of the channel(s) used within 482 a FLUTE session. The required parameters for channelization 483 description are: 485 o Number of channels 487 o Destination IP address and port number for channels 489 3.6.1. Number of Channels 491 The FLUTE specification allows the use of multiple channels (e.g. 492 multicast groups) to transport the files of a single FLUTE session. 493 This is referred to as FLUTE session channelization in this document. 494 A FLUTE channel is equivalent to an ALC/LCT channel. An ALC/LCT 495 channel is defined by the combination of a sender and an address 496 associated with the channel by the sender. Details of each channel 497 are defined by SDP media-level information also described in this 498 document. The number of channels of a certain FLUTE session is 499 calculated by summing the number of unique destination IP address and 500 port number pairs for a certain FLUTE session. 502 The OPTIONAL "flute-ch" attribute describes the number of channels 503 used by the source to transmit a FLUTE session. When present, it is 504 used to validate the channel number calculation based on the number 505 of destination address/port pairs, and it is expected to be used 506 where SDP proxies and other automatic and manual editing that 507 introduces errors would cause bad failure conditions at the client. 509 When the "flute-ch" attribute is used: 511 o The number of "flute-ch" attributes in any SDP describing FLUTE 512 sessions MUST be exactly equal to the number of FLUTE sessions 513 described in that SDP. A client SHOULD discard all of an SDP 514 instance if this condition is not met. Alternative behavior, such 515 as retries at delivery, error reporting and partial use of SDP 516 instances known to include errors, are beyond the scope of this 517 document. 519 o In the restricted behavior of only one FLUTE session description 520 in an SDP and no use of the Composite Session mechanism: Any 521 "flute-ch" attribute MUST be in the session part of the session 522 description and MUST NOT be given per media. 524 o Where the Composite Session mechanism is used: The "flute-ch" 525 attribute MUST be in the media part of Primary Media of each 526 distinct FLUTE session, and MUST NOT be given in other media 527 declarations but these, nor in the session-level part of the SDP. 529 The syntax for the attribute in ABNF is given below: 531 flute-channel-line = "a=flute-ch:" ch CRLF 532 ch = integer 533 ;integer is as defined in [RFC4566], and its value is the number of 534 ;channels used by the source to transmit data in a FLUTE session. 536 3.6.2. Destination IP Address and Port Number for Channels 538 SDP media-level information describes one or more channels. The 539 channel parameters MUST be given per channel and are: 541 o Destination IP address 543 o Destination port number 545 The destination IP address MUST be defined according to the 546 connection data field ("c=") of SDP [RFC4566]. The destination port 547 number MUST be defined according to the "port" sub-field of the media 548 description field ("m=") of SDP [RFC4566]. 550 A "c=" line can describe multiple addresses by using "number of 551 addresses" sub-field, and also an "m=" line can describe multiple 552 ports by using "number of ports" sub-field. So multiple channels can 553 be described by using one "c=" line and one "m=" line (called "slash 554 notation"). 556 When more than one channel is used in a multicast FLUTE session, it 557 is RECOMMENDED that the channels are differentiated based on 558 destination IP address, and channels are not differentiated based on 559 destination port (although those ports could be same or different for 560 each of the channels). Whenever destination port number is used to 561 differentiate between FLUTE channels, the same destination IP address 562 MUST be used for all channels in that FLUTE session. Note, when more 563 than one channel is used in a unicast FLUTE session, the channels 564 have to be differentiated based on destination ports, as only one 565 destination IP address could be used. Also note, the use of address 566 and port to differentiate channels is a FLUTE sender configuration 567 decision that the SDP describes, and so a receiver implementation 568 still needs to handle all valid cases. 570 In the case where the same destination IP address is used for all the 571 channels of the session and only the destination port number 572 differentiates channels, the destination IP address MAY be given by 573 the connection data field at session-level for all channels (if so, 574 the connection data field MUST NOT be used at media-level). 576 In the case where each channel has a different destination IP 577 address, the destination IP addresses MUST be given at media-level, 578 i.e. following an "m=" line. 580 Some applications of FLUTE and FLUTE SDP benefit from identifying an 581 ordinal sequence of FLUTE channels in a FLUTE session. In this case, 582 the sequence of multiple channels MUST be determined by the order in 583 which their media descriptions are defined in the session description 584 (i.e. the first media description gives the first channel in the 585 sequence). This applies individually to each FLUTE session of an SDP 586 whether one or more FLUTE sessions are described. In the case of the 587 slash notation usage for specifying multiple destination addresses or 588 ports, the order of the channel sequence MUST be lowest value first 589 and highest last. Note, slash notation for both destination IP 590 address and port would be incompatible with requirement to not use 591 both destination IP address and port to differentiate channels in a 592 FLUTE session and thus slash notation for both destination IP address 593 and port is not allowed for a single FLUTE session - i.e. for a 594 single composite session (when the SDP describes multiple FLUTE 595 sessions) or for a single SDP instance (when only one FLUTE session 596 is described). 598 Also we need to indicate the presence of a FLUTE session on a certain 599 channel. This is done by using the "m=" line in the SDP description 600 as shown in the following example: 602 m=application 12345 FLUTE/UDP * 603 c=IN IP6 FF33::8000:1 605 In the above SDP attributes, the "m=" line indicates the media used 606 and the "c=" line together with "m=" line's "port" sub-field 607 indicates the corresponding channel's address and port respectively. 608 Thus, in the above example, the media is transported on a channel 609 that uses FLUTE over UDP. Further, the "c=" line indicates the 610 channel's address, which, in this case, is an IPv6 address, and "m=" 611 line indicates the channel's port (12345). 613 Note, the value of the destination IP address can indicate whether a 614 multicast media belongs to an ASM or a SSM group as described by 615 [RFC4607]. 617 3.7. FEC Scheme 619 An SDP description for a FLUTE session MAY include information for 620 one or more FEC schemes (a subset of FEC Object Transmission 621 Information (FEC-OTI) [RFC5052] that is useful for reception 622 capability evaluation at the receiver). FEC parameters can be placed 623 either at session-level or at media-level, although it is RECOMMENDED 624 to place them at session-level. Furthermore, if FEC parameters are 625 placed at media level (contrary to the recommendation) and the 626 Composite Session mechanism is used, they SHOULD only be placed in 627 the Primary Media for any FLUTE session description. If FEC 628 declarations on both session and media level use the same reference 629 number (fec-ref) then the media level declaration takes precedence 630 for that media component. FEC parameters include: 632 o FEC Encoding ID 634 o FEC Instance ID (for FEC Encoding IDs 128-255) 636 Where any FEC scheme is given, FEC parameters MUST be described in a 637 "FEC-declaration" attribute. Multiple instances of this attribute 638 MAY exist both at session-level and media-level. If an instance 639 exists at session-level (or in a Primary Media), a reference to it 640 MAY be used at media-level, and an attribute "FEC" MUST be defined 641 for this purpose. 643 The syntax for the attributes in ABNF is given below: 645 fec-declaration-line = "a=FEC-declaration:" fec-ref SP 646 fec-enc-id [";" SP fec-inst-id] CRLF 647 fec-ref = 1*3DIGIT 648 ;value is the SDP-internal identifier for FEC-declaration 650 fec-enc-id = "encoding-id=" enc-id 651 enc-id = 1*DIGIT 652 ;value is the FEC Encoding ID used 654 fec-inst-id = "instance-id=" inst-id 655 inst-id = 1*DIGIT 656 ;value is the FEC Instance ID used 658 fec-line = "a=FEC:" fec-ref CRLF 660 Examples of FEC scheme information are shown in Section 4. 662 The FEC parameters are for capabilities description for the session. 663 These parameters do not mandate a certain machine configuration but 664 instead indicate which capabilities might be needed for successful 665 reception of objects from specific channels. (Note, any "FDT-like" 666 fuller description of files in the session could give the FEC 667 parameters per file). FLUTE's FDT syntax (and codepoint header field 668 usage) allows complete specification of these FEC parameters in-band 669 with FLUTE (per file). Thus machine configuration can be performed 670 using FLUTE alone. 672 A more complete list of notes on the design logic for the FEC-OTI 673 descriptors is provided as an appendix to this document. 675 3.8. Content Description Pointer 677 The syntax of the information that tells receiver, in the first 678 place, that the session contains files that are of interest is out of 679 scope of this document. However, the SDP MAY include a content 680 description pointer at the session-level and/or media-level 681 (including Primary Media of Composite Sessions) to enable efficient 682 linkage to such information. 684 The content description pointer attribute describes to the 685 receiver(s) the URI where the content description is stored. The 686 content description pointer MUST be defined according to the 687 "content-desc" attribute. 689 The syntax for the attribute in ABNF is given below: 691 content-desc-line = "a=content-desc:" URI-reference CRLF 692 ;URI-reference is as defined in [RFC3986]. 694 An example of content description pointer is shown in Section 4. 696 3.9. Security Parameters 698 To support the baseline secure ALC operation [RFC5775], subsection 699 3.2.1. defines the FLUTE/UDP/ESP protocol identifier for a FLUTE 700 session where the session security is achieved using IPsec/ESP in a 701 transport mode. 703 This document describes two informative ways which can be used to 704 deliver the needed security parameters for IPsec/ESP Security 705 Association (SA). Firstly, the "key-mgmt" attribute defined in 706 [RFC4567] can be used to carry messages, as specified by a key 707 management protocol, in order to secure the media. In [RFC4567] the 708 usage of the Multimedia Internet KEYing (MIKEY) key management 709 protocol [RFC3830] is defined and guidelines for the registration of 710 additional key management protocols is also provided. 712 Secondly, the "crypto" attribute defined in [RFC4568] provides 713 cryptographic key distribution capabilities, but it is intended for 714 usage when keying material is protected along with the signaling 715 (i.e. when the session description itself is retrieved using a secure 716 method). [RFC4568] describes this attribute primarily for a unicast 717 offer/answer models, but also for "offer only" mode with multicast 718 delivery, and sets a policy by mandating that "the sender MUST 719 include exactly one crypto attribute" (implying "one crypto attribute 720 per media", although [RFC4568] is slightly ambiguous on this). The 721 definition of composite session adds a case to the usage of the 722 crypto attribute and so, a crypto attribute definition in a Composite 723 Session Primary Media SHALL BE inherited to all media of that 724 particular Composite Session group, except where individual child 725 media overwrite this with their own crypto attribute. 727 3.10. Bandwidth Specification 729 The specification of bandwidth (data rate) is OPTIONAL and where 730 included in the SDP it SHALL adhere to the following rules. 732 The maximum bit-rate required by a particular FLUTE media line (one 733 or more FLUTE channels, depending on the usage or IP address and port 734 ranges) MAY be specified. In this case it is RECOMMENDED to use the 735 TIAS bandwidth modifier [RFC3890] on media-level, although the AS 736 bandwidth modifier [RFC4566] MAY be used on media-level. 738 The session bit-rate MAY also be specified. In this case it is 739 RECOMMENDED to use the TIAS bandwidth modifier and the "a=maxprate" 740 attribute for the session, and again AS is optional but not 741 recommended. 743 TIAS is generally preferred as it allows the calculation of the bit- 744 rate in environments with translation of IP version or transport 745 protocol, where as AS does not and thus adds significant complexity 746 in such environments. 748 Any Transport Independent (TIAS) bandwidth SHALL be the largest sum 749 of the sizes of all FLUTE/UDP or FLUTE/UDP/ESP packets transmitted 750 during any one second long period of the FLUTE session, depending on 751 which level it is being used, expressed as kilobits. The size of the 752 packet SHALL include all FLUTE, ALC, LCT and any extensions headers 753 and payload. IP, UDP and ESP headers are excluded from the TIAS bit- 754 rate calculation. Any Application Specific (AS) bandwidth SHALL be 755 the largest sum of the sizes of all FLUTE/UDP or FLUTE/UDP/ESP 756 packets transmitted during any one second long period for the related 757 media line(s), expressed as kilobits. The size of the packet SHALL 758 be the complete packet, i.e. IP, UDP, ESP and FLUTE headers, and the 759 data payload. 761 3.10.1. Bandwidth Specification for Composite Sessions 763 Where the multimedia session bit-rate is specified (at SDP session 764 level) this applies to all media, irrespective of whether the 765 Composite Session mechanism is used to describe multiple sessions 766 (e.g. multiple FLUTE sessions). So if multiple Composite Sessions 767 are described in a single SDP instance and SDP session-level bit-rate 768 is described, this session-level bit-rate would not relate to any 769 single Composite Session. 771 A normal TIAS or AS bit-rate declaration at the Primary Media level 772 is to be interpreted as media-specific and not imply any inheritance 773 to other media of the same Composite Session. It is RECOMMENDED that 774 aggregate Composite Session bandwidth is calculated as the sum of all 775 constituent media bit-rate declarations. Specification of a 776 descriptor specifically for aggregate Composite Session bandwidth is 777 beyond the scope of this document. 779 3.11. SDP Specific Parameters 781 SDP [RFC4566] also mandates three parameters ("v=", "o=" and "s=") 782 that would be present in every FLUTE SDP instance regardless of their 783 usefulness to the FLUTE session description. 785 4. SDP Syntax Examples 787 This section gives examples of the use of SDP attributes to describe 788 a FLUTE session. 790 v=0 791 o=user123 2890844526 2890842807 IN IP6 2001:0DB8::112E:144A:1E24 792 s=File delivery session example 793 i=More information 794 t=2873397496 2873404696 795 a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9 796 a=flute-tsi:3 797 a=flute-ch:2 798 a=FEC-declaration:0 encoding-id=0 799 a=FEC-declaration:1 encoding-id=129; instance-id=0 800 a=content-desc:http://www.example.com/flute-sessions/session001 801 m=application 12345 FLUTE/UDP * 802 c=IN IP6 FF33::8000:1 803 a=FEC:0 804 m=application 12346 FLUTE/UDP * 805 c=IN IP6 FF33::8000:2 806 a=FEC:1 808 Figure 1: An SDP Instance for a FLUTE Session with Two Channels 810 Figure 1 shows an example SDP instance for a FLUTE session with two 811 channels. (Note, to introduce the SDP semantics of the current 812 document in simpler smaller steps, figure 1 does not follow the 813 recommendation of subsection 3.2.1 to use the Composite Session 814 semantics when an SDP describes more than one FLUTE media stream. 815 Thus, the form of figure 1 is not expected to be normally used in 816 practice.) 818 The attribute defined in the line "a=source-filter: incl IN IP6 * 819 2001:0DB8:1:2:240:96FF:FE25:8EC9" describes a source filter. In this 820 example the source indicates that the receiver(s) should include the 821 given IP address (2001:0DB8:1:2:240:96FF:FE25:8EC9) into the session. 822 It should be noted that although other possibilities may be used, in 823 this case only the incl and * attributes may be used in the above 824 attribute. 826 The attribute defined in the line "a=flute-tsi:3" describes the 827 Transport Session Identifier for the session. The pair made of the 828 source IP address and the TSI together uniquely identifies a FLUTE 829 session. 831 The source indicates in the above example that it will transmit data 832 in the FLUTE session on two channels (a=flute-ch:2). The source then 833 specifies the channels. 835 The "a=FEC-declaration" lines describes two different FEC schemes 836 used in the FLUTE session. 838 The "a=content-desc" line describes the URI where the content 839 description is stored. 841 The line "m=application 12345 FLUTE/UDP *" indicates the media used 842 for the channel. In this example, there are two "m=" lines for the 843 two channels described. 845 The destination addresses for the channels are given in the "c=" 846 lines. These also show to the receiver(s) that the channels are two 847 (maybe more in other cases) consecutive channels of an ordinal 848 sequence of channels. 850 The "a=FEC" lines at media-level reference FEC declarations at 851 session-level ("a=FEC-declaration"). 853 v=0 854 o=user123 2890844526 2890842807 IN IP6 2001:0DB8::112E:144A:1E24 855 s=File delivery session example 856 i=More information 857 t=2873397496 2873404696 858 a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9 859 a=flute-tsi:2 860 a=flute-ch:1 861 m=application 12345 FLUTE/UDP * 862 c=IN IP6 FF33::8000:1 863 a=FEC-declaration:0 encoding-id=129; instance-id=0 865 Figure 2: An SDP Instance for a FLUTE Session with One Channel 867 Figure 2 shows an example SDP instance for a FLUTE session with one 868 channel. 870 v=0 871 o=user123 2890844526 2890842807 IN IP6 2001:0DB8::112E:144A:1E24 872 s=File delivery session example 873 i=More information 874 t=2873397496 2873404696 875 a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9 876 a=FEC-declaration:0 encoding-id=0 877 a=FEC-declaration:1 encoding-id=129; instance-id=0' 878 a=group:CS 1 2 879 a=group:CS 3 4 880 m=application 12345 FLUTE/UDP * 881 c=IN IP6 FF33::8000:1 882 a=flute-tsi:1 883 a=FEC:0 884 a=mid:1 885 m=application 12346 FLUTE/UDP * 886 c=IN IP6 FF33::8000:2 887 a=mid:2 888 m=application 12347 FLUTE/UDP * 889 c=IN IP6 FF33::8000:3 890 a=flute-tsi:2 891 a=FEC:1 892 a=mid:3 893 m=application 12348 FLUTE/UDP * 894 c=IN IP6 FF33::8000:4 895 a=mid:4 897 Figure 3: An SDP Instance for Multiple (two) FLUTE Sessions using the 898 Composite Session Mechanism 900 Figure 3 shows an example SDP instance for multiple FLUTE sessions 901 using the Composite Session mechanism. 903 5. Security Considerations 905 See [RFC4566] for security considerations specific to the Session 906 Description Protocol in general. See also [RFC4570] for security 907 consideration related to source address filters. 909 [I-D.ietf-rmt-flute-revised] provides security consideration 910 regarding FLUTE sessions, from which Section 7.3.1 specifically 911 addresses attacks against the session description. The current 912 document does not introduce additional security considerations beyond 913 these prior specifications. 915 6. IANA Considerations 917 6.1. Transport Protocol 919 The "proto" sub-field of the media description field ("m=") describes 920 the transport protocol used. This document registers two values: 921 "FLUTE/UDP" is a reference to FLUTE [I-D.ietf-rmt-flute-revised] 922 running over UDP/IP. "FLUTE/UDP/ESP" is a reference to FLUTE 923 [I-D.ietf-rmt-flute-revised] running over UDP/IP and the session 924 security is achieved by means of IPsec/ESP in a transport mode 925 [RFC4303]. 927 6.1.1. Media formats ("fmt") 929 FLUTE media using the "FLUTE/UDP" or "FLUTE/UDP/ESP" proto value may 930 use the character "*" as their "fmt" value. The "*" character 931 represents a wild card which indicates that miscellaneous and 932 unspecified MIME types are contained in the FLUTE session. 933 Alternatively a list of MIME types (file formats) may be given in the 934 "fmt" list. These formats SHOULD be registered. Use of an existing 935 MIME subtype for the format is encouraged. If no MIME subtype 936 exists, it is RECOMMENDED that a suitable one is registered through 937 the IETF process as described in RFC4289 [RFC4289]. 939 6.2. Attribute Names 941 As recommended by [RFC4566], the new attribute names "flute-tsi", 942 "flute-ch", "FEC-declaration", "FEC", "FEC-OTI-extension" and 943 "content-desc" should be registered with IANA, as follows: 945 The following contact information shall be used for all registrations 946 included here: 948 Contact: Rod Walsh 949 EMail: roderick.walsh (at) tut.fi 951 SDP Attribute ("att-field"): 952 Attribute name: flute-tsi 953 Long form: FLUTE Transport Session Identifier 954 Type of name: att-field 955 Type of attribute: Session level or media level 956 Subject to charset: No 957 Purpose: See this document 958 Reference: This document 959 Values: See this document 961 SDP Attribute ("att-field"): 962 Attribute name: flute-ch 963 Long form: Number of Channels in a FLUTE Session 964 Type of name: att-field 965 Type of attribute: Session level or media level 966 Subject to charset: No 967 Purpose: See this document 968 Reference: This document 969 Values: See this document 971 SDP Attribute ("att-field"): 972 Attribute name: FEC-declaration 973 Long form: Forward Error Correction Declaration 974 Type of name: att-field 975 Type of attribute: Session level or media level 976 Subject to charset: No 977 Purpose: See this document 978 Reference: This document 979 Values: See this document 981 SDP Attribute ("att-field"): 982 Attribute name: FEC 983 Long form: A Reference to FEC Declaration 984 Type of name: att-field 985 Type of attribute: Media level 986 Subject to charset: No 987 Purpose: See this document 988 Reference: This document 989 Values: See this document 991 SDP Attribute ("att-field"): 992 Attribute name: FEC-OTI-extension 993 Long form: FEC Object Transmission Information extension 994 Type of name: att-field 995 Type of attribute: Session level or media level 996 Subject to charset: No 997 Purpose: See this document 998 Reference: This document 999 Values: See this document 1001 SDP Attribute ("att-field"): 1002 Attribute name: content-desc 1003 Long form: Content Description Pointer 1004 Type of name: att-field 1005 Type of attribute: Session level or media level 1006 Subject to charset: No 1007 Purpose: See this document 1008 Reference: This document 1009 Values: See this document 1011 6.3. Composite Session Token to Differentiate FLUTE Sessions 1013 IANA needs to register the following new 'semantics' attribute for 1014 the SDP grouping framework [RFC5888]: 1016 Semantics Token Reference 1017 --------------------------------- ----- --------- 1018 Composite Session CS This document 1020 It should be registered in the SDP parameters registry 1021 (http://www.iana.org/assignments/sdp-parameters) under Semantics for 1022 the "group" SDP Attribute. 1024 7. Acknowledgements 1026 The authors would like to thank all the people who gave feedback on 1027 this document. 1029 8. Contributors 1031 Magnus Westerlund 1032 Ericsson Research 1033 Ericsson AB 1034 SE-164 80 Stockholm 1035 Sweden 1036 EMail: Magnus.Westerlund (at) ericsson.com 1038 Joerg Ott 1039 Aalto University 1040 Otakaari 5A 1041 FI-02150 Espoo 1042 Finland 1043 EMail: jo (at) netlab.tkk.fi 1045 Vincent Roca 1046 INRIA 1047 655, av. de l'Europe 1048 Inovallee; Montbonnot 1049 ST ISMIER cedex 38334 1050 France 1051 Email: vincent.roca (at) inria.fr 1053 9. Change Log 1055 9.1. From draft-ietf-rmt-flute-sdp-02 to draft-ietf-rmt-flute-sdp-03 1057 One clarification in Section 3.6.1 and two clarifications in Section 1058 3.6.2 (no changes to the meaning). 1060 9.2. From draft-ietf-rmt-flute-sdp-01 to draft-ietf-rmt-flute-sdp-02 1062 Author affiliation update 1064 Changed the term "FEC OTI" to "FEC scheme" where appropriate to avoid 1065 misunderstandings between the current specification's use for OTI 1066 capability requirements description and the wider application of OTI 1067 for receiver FEC configuration for LCT/FLUTE objects (the latter 1068 being beyond the scope of the present specification). 1070 More specific reference to Section 7.3.1 in 1071 [I-D.ietf-rmt-flute-revised] for attacks against session descriptions 1072 is added to Section 5. 1074 Moved the note on out of scope congestion control to a more sensible 1075 place. 1077 Added note for Figure 1 to explain why it does not follow a 1078 recommendation. 1080 Changed spellings to US English. 1082 9.3. From draft-ietf-rmt-flute-sdp-00 to draft-ietf-rmt-flute-sdp-01 1084 New value for the "proto" sub-field, i.e. FLUTE/UDP/ESP defined. 1086 New section "Security Parameters" added. This section defines two 1087 possibilities which can be used to set up the needed security 1088 parameters for ESP. 1090 Clarifications for: media-level attribute overwriting of Composite 1091 Session Primary Media attributes; media protocol usage for Restricted 1092 Behavior only one; crypto attribute usage. 1094 9.4. From draft-mehta-rmt-flute-sdp-06 to draft-ietf-rmt-flute-sdp-00 1096 Document name changed to reflect the status as an official working 1097 group draft. 1099 All editorial notes removed, except those related to open CC and SEC 1100 discussion. 1102 Clarified Composite Session Semantics regarding primary media. "The 1103 first media line declared..." changed to "The first (leftmost) mid 1104 value declared...". 1106 Clarifying note added to disambiguate the apparent difference between 1107 LCT and SDP "guard interval" for session expiry and session id reuse. 1108 This include the non mandatory recommendation to avoid TSI reuse 1109 whenever possible (e.g. for a 48bit TSI and non-extremely-high- 1110 frequency session changes from a specific sender, this would often be 1111 the case). 1113 Documented the previously implicit assumption regarding wall clock 1114 synchronization. 1116 RFC5445 reference corrected (now in the informative references 1117 section). 1119 10. References 1121 10.1. Normative References 1123 [I-D.ietf-rmt-flute-revised] 1124 Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 1125 "FLUTE - File Delivery over Unidirectional Transport", 1126 draft-ietf-rmt-flute-revised-16 (work in progress), 1127 June 2012. 1129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1130 Requirement Levels", BCP 14, RFC 2119, March 1997. 1132 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1133 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 1134 April 2010. 1136 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1137 Transport (LCT) Building Block", RFC 5651, October 2009. 1139 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1140 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1142 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1143 Description Protocol", RFC 4566, July 2006. 1145 [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol 1146 (SDP) Source Filters", RFC 4570, July 2006. 1148 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1149 10646", STD 63, RFC 3629, November 2003. 1151 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1152 Resource Identifier (URI): Generic Syntax", STD 66, 1153 RFC 3986, January 2005. 1155 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1156 Correction (FEC) Building Block", RFC 5052, August 2007. 1158 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1159 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1161 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 1162 Modifier for the Session Description Protocol (SDP)", 1163 RFC 3890, September 2004. 1165 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1166 RFC 4303, December 2005. 1168 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1169 Carrara, "Key Management Extensions for Session 1170 Description Protocol (SDP) and Real Time Streaming 1171 Protocol (RTSP)", RFC 4567, July 2006. 1173 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1174 Description Protocol (SDP) Security Descriptions for Media 1175 Streams", RFC 4568, July 2006. 1177 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1178 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1179 August 2004. 1181 10.2. Informative References 1183 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 1184 "FLUTE - File Delivery over Unidirectional Transport", 1185 RFC 3926, October 2004. 1187 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1188 Announcement Protocol", RFC 2974, October 2000. 1190 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1191 A., Peterson, J., Sparks, R., Handley, M., and E. 1192 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1193 June 2002. 1195 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1196 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1197 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1199 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1200 the Session Description Protocol (SDP)", RFC 4145, 1201 September 2005. 1203 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1204 IP", RFC 4607, August 2006. 1206 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1207 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1209 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 1210 Extensions (MIME) Part Four: Registration Procedures", 1211 BCP 13, RFC 4289, December 2005. 1213 [RFC5445] Watson, M., "Basic Forward Error Correction (FEC) 1214 Schemes", RFC 5445, March 2009. 1216 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1217 Time Protocol Version 4: Protocol and Algorithms 1218 Specification", RFC 5905, June 2010. 1220 [3GPP.26.346] 1221 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1222 Protocols and codecs", 3GPP TS 26.346 10.4.0, June 2012. 1224 Appendix A. Use of FEC Attributes with RTP Sessions (informative) 1226 The "FEC-declaration" and "FEC" attributes provide general FEC-OTI 1227 information in FEC Encoding ID and FEC Instance ID values. These may 1228 also be used for RTP sessions employing same FEC Building Block (e.g. 1229 as is done for 3GPP MBMS [3GPP.26.346]). However, semantics of RTP 1230 are different from FLUTE (FEC is per session not per object) and RTP 1231 does not have in-band mechanism to signal FEC OTI extensions. Thus, 1232 RTP FEC declarations are expected to be used for machine 1233 configuration as well as capability requirements specification (for 1234 FLUTE it is generally only the latter). 1236 Hence, the FLUTE SDP, defined in this document, may be extended using 1237 a "FEC-OTI-extension" attribute, depending on the configuration needs 1238 of the FEC decoder used and the lack of an alternative means to 1239 signal the extended FEC-OTI information. The purpose of extended 1240 FEC-OTI information is to define FEC code/instance-specific OTI 1241 required for receiver FEC payload configuration. The contents of 1242 such an extension would be FEC code-specific and exact specification, 1243 beyond adherence to the ABNF below, needs to be specified by any FEC 1244 code using this attribute, and hence is outside the scope of this 1245 appendix. 1247 A "FEC-OTI-extension" attribute must be immediately preceded by its 1248 associated "FEC-declaration" attribute and so the full FEC-OTI, 1249 including extension, will be found in two neighboring attribute 1250 lines. The fec-ref value binds a "FEC-OTI-extension" and "FEC- 1251 declaration attribute" pair. 1253 The syntax for the attribute in ABNF is given below: 1255 fec-oti-extension-line = "a=FEC-OTI-extension:" fec-ref SP 1256 oti-extension CRLF 1257 oti-extension = base64 1258 base64 = *base64-unit [base64-pad] 1259 base64-unit = 4base64-char 1260 base64-pad = 2base64-char "==" / 3base64-char "=" 1261 base64-char = ALPHA / DIGIT / "+" / "/" 1263 Appendix B. Further Design Logic for FEC-OTI Descriptors 1265 There are several reasons that the FEC Encoding and Instance IDs are 1266 optional capabilities descriptions: 1268 1. It is not always necessary to explicitly describe the FEC 1269 capabilities in advance of the session - e.g. for simple (and 1270 short) sessions it can be more elegant to discover this from the 1271 session (FDT) itself (even when some mechanism for machine- 1272 readable session parameters, such as IP addresses and ports, is 1273 wanted in advance). 1275 2. There may be some other out-of-band discovery of FEC capability 1276 requirements (e.g. well known-FEC/standardized capabilities for a 1277 certain application, verbal agreement between a group, etc.) that 1278 provides the FEC capability information. This document does not 1279 want to prevent this, and in this case repeating the information 1280 in SDP instance would be unnecessary and wasteful (and probably 1281 result in implementations not following the flute-sdp 1282 specification). 1284 3. FLUTE defaults to Compact No-Code FEC [RFC5445] and support for 1285 this is mandatory for FLUTE anyway so it is a given (capability 1286 requirement) which does not need to be described by the SDP 1287 instance. In cases where only Compact No-Code FEC is required, 1288 there is no use in specifying any FEC Encoding (and Instance) IDs 1289 in the SDP instance(though it is allowed). 1291 4. In cases where a FLUTE session description (SDP instance) is not 1292 defined once for all time, it is possible that the FEC usage is 1293 not known in advance and the FEC capabilities would only be added 1294 to the SDP in a later version of that SDP instance when the FEC 1295 codes have been selected (e.g. a larger audience may suggest 1296 stronger FEC to make FLUTE delivery more reliable, whereas 1297 additional bi-directional messages may be scalable for smaller 1298 groups). 1300 5. Also, in cases where a FLUTE session description (SDP instance) 1301 is very static (e.g. once for all time for that session), it is 1302 possible that the FEC usage is not known in advance and it needs 1303 to be left to some other mechanism (e.g. FDT) to discover any 1304 FEC capability requirements set closer to the session 1305 transmission - with the same examples as mentioned above. 1307 Also, in a complex case of very many FEC codes being used in the 1308 session giving a full list in SDP instance is not seen as being 1309 reasonable (but this is likely to be a rare case anyway). 1311 Authors' Addresses 1313 Rod Walsh 1314 Tampere University of Technology 1315 P.O. Box 553 (Korkeakoulunkatu 1) 1316 Tampere FI-33101 1317 Finland 1319 Email: roderick.walsh (at) tut.fi 1321 Jani Peltotalo 1322 Tampere University of Technology 1323 P.O. Box 553 (Korkeakoulunkatu 1) 1324 Tampere FI-33101 1325 Finland 1327 Email: jani.peltotalo (at) ieee.org 1329 Sami Peltotalo 1330 Tampere University of Technology 1331 P.O. Box 553 (Korkeakoulunkatu 1) 1332 Tampere FI-33101 1333 Finland 1335 Email: sami.peltotalo (at) tut.fi 1337 Igor D.D. Curcio 1338 Nokia Research Center 1339 P.O. Box 88 (Tieteenkatu 1) 1340 Tampere FI-33721 1341 Finland 1343 Email: igor.curcio (at) nokia.com 1345 Harsh Mehta 1347 Email: harsh.mehta (at) gmail.com