idnits 2.17.1 draft-ietf-fecframe-sdp-elements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (June 4, 2009) is 5440 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) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-03 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-rfc3388bis-02 == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-rfc4756bis-02 == Outdated reference: A later version (-09) exists of draft-ietf-fecframe-config-signaling-01 == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-10 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework A. Begen 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track June 4, 2009 5 Expires: December 6, 2009 7 SDP Elements for FEC Framework 8 draft-ietf-fecframe-sdp-elements-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on December 6, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document specifies the use of Session Description Protocol (SDP) 57 to describe the parameters required to signal the Forward Error 58 Correction (FEC) Framework Configuration Information between the 59 sender(s) and receiver(s). This document also provides examples that 60 show the semantics for grouping multiple source and repair flows 61 together for the applications that simultaneously use multiple 62 instances of the FEC Framework. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 68 3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 4 69 3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 4 70 3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 5 71 3.3. FEC Framework Configuration Information . . . . . . . . . 6 72 4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 7 73 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 8 74 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 8 75 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 10 76 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 11 79 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 12 80 5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 13 81 5.1. Declarative Considerations . . . . . . . . . . . . . . . . 13 82 5.2. Offer/Answer Model Considerations . . . . . . . . . . . . 13 83 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme . 14 85 5.3.2. Two Source Flows, One Repair Flow and One FEC 86 Scheme . . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.3.3. Two Source Flows, Two Repair Flows and Two FEC 88 Schemes . . . . . . . . . . . . . . . . . . . . . . . 16 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 17 92 7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 18 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 94 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 9.1. draft-ietf-fecframe-sdp-elements-03 . . . . . . . . . . . 19 96 9.2. draft-ietf-fecframe-sdp-elements-02 . . . . . . . . . . . 19 97 9.3. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 19 98 9.4. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 19 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction 106 The Forward Error Correction (FEC) Framework, described in 107 [I-D.ietf-fecframe-framework], outlines a general framework for using 108 FEC-based error recovery in packet flows carrying media content. 109 While a continuous signaling between the sender(s) and receiver(s) is 110 not required for a Content Delivery Protocol (CDP) that uses the FEC 111 Framework, a set of parameters pertaining to the FEC Framework MUST 112 be initially communicated between the sender(s) and receiver(s). A 113 signaling protocol (such as the one described in 114 [I-D.ietf-fecframe-config-signaling]) is required to enable such 115 communication and the parameters must be appropriately encoded so 116 that they can be carried by the signaling protocol. 118 One format to encode the parameters is the Session Description 119 Protocol (SDP) [RFC4566]. SDP provides a simple text-based format 120 for announcements and invitations to describe multimedia sessions. 121 These SDP announcements and invitations include sufficient 122 information for the sender(s) and receiver(s) to participate in the 123 multimedia sessions. SDP also provides a framework for capability 124 negotiation, which may be used to negotiate all or a subset of the 125 parameters pertaining to the individual sessions. 127 The purpose of this document is to introduce the SDP elements that 128 MUST be used by the CDPs using the FEC Framework that choose SDP 129 [RFC4566] as their session description protocol. 131 2. Requirements Notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 3. Forward Error Correction (FEC) and FEC Framework 139 This section gives a brief overview of FEC and the FEC Framework. 141 3.1. Forward Error Correction (FEC) 143 Any application that needs a reliable transmission over an unreliable 144 packet network has to cope with packet losses. FEC is an effective 145 approach that provides reliable transmission particularly in 146 multicast and broadcast applications where the feedback from the 147 receiver(s) is potentially limited. 149 In a nutshell, FEC groups source packets into blocks and applies 150 protection to generate a desired number of repair packets. These 151 repair packets may be sent on demand or independently of any receiver 152 feedback. The choice depends on the FEC scheme or the Content 153 Delivery Protocol used by the application, the packet loss 154 characteristics of the underlying network, the transport scheme 155 (e.g., unicast, multicast and broadcast) and the application. At the 156 receiver side, lost packets can be recovered by erasure decoding 157 provided that a sufficient number of source and repair packets have 158 been received. 160 3.2. FEC Framework 162 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 163 framework for using FEC codes in multimedia applications that stream 164 audio, video or other types of multimedia content. It defines the 165 common components and aspects of Content Delivery Protocols (CDP). 166 The FEC Framework also defines the requirements for the FEC schemes 167 that need to be used within a CDP. However, the details of the FEC 168 schemes are not specified within the FEC Framework. For example, the 169 FEC Framework defines what configuration information has to be known 170 at the sender and receiver(s) at minimum, but the FEC Framework 171 neither specifies how the FEC repair packets are generated and used 172 to recover missing source packets, nor dictates how the configuration 173 information is communicated between the sender and receiver(s). 174 These are rather specified by the individual FEC schemes or CDPs. 176 For a proper operation, the information required by the FEC Framework 177 and the details of an FEC scheme have to be communicated between the 178 sender and receiver(s). One way to provide this information is to 179 use the Session Description Protocol (SDP) [RFC4566]. SDP provides a 180 commonly used text-based format for announcements and invitations 181 that describe multimedia sessions. These SDP announcements and 182 invitations include sufficient information for clients to participate 183 in multimedia sessions. By using the SDP capability negotiation 184 framework, all or a subset of the parameters pertaining to the FEC 185 Framework may also be negotiated between the sender and receiver(s). 187 The purpose of this document is to introduce the SDP elements that 188 MUST be used by the CDPs using the FEC Framework that choose SDP 189 [RFC4566] as their session description protocol. 191 Note that there are many similarities between the FEC Framework 192 [I-D.ietf-fecframe-framework] and the FEC Building Block [RFC5052], 193 which describes a framework that uses FEC codes to provide 194 reliability to bulk data transfer applications running over IP 195 multicast or broadcast. See [I-D.ietf-fecframe-framework] for 196 further details. 198 3.3. FEC Framework Configuration Information 200 The FEC Framework defines a minimum set of information that MUST be 201 communicated between the sender and receiver(s) for a proper 202 operation of an FEC scheme. This information is called the FEC 203 Framework Configuration Information. This information specifies how 204 the sender applies protection to the source flow(s) and how the 205 repair flow(s) can be used to recover lost data. In other words, 206 this information specifies the relationship(s) between the source and 207 repair flows. 209 The FEC Framework Configuration Information includes identifiers for 210 unique identification of the source and repair flows that carry the 211 source and repair packets, respectively. For example, a packet flow 212 that is transmitted over UDP is uniquely identified by the tuple of 213 {Source IP Address, Destination IP Address, Source UDP Port, 214 Destination UDP Port}. However, an integer identifier MAY be used 215 internally within the FEC scheme as a shorthand to identify this 216 flow. 218 Multiple instances of the FEC Framework MAY simultaneously exist at 219 the sender and the receiver(s) for different source flows, for the 220 same source flow, or for various combinations of source flows. Each 221 instance of the FEC Framework MUST provide the following FEC 222 Framework Configuration Information: 224 1. Identification of the repair flows. 226 2. For each source flow protected by the repair flow(s): 228 a. Definition of the source flow. 230 b. An integer identifier for this flow definition (i.e., tuple). 231 This identifier MUST be unique amongst all source flows that are 232 protected by the same FEC repair flow. The identifiers SHOULD be 233 allocated starting from zero and increasing by one for each flow. 235 A source flow identifier need not be carried in source packets 236 since source packets are directly associated with a flow by virtue 237 of their packet headers. Note that an application MAY wildcard 238 some of the fields if only a subset of the fields of the tuple 239 (e.g., {Destination IP Address, Destination UDP Port} ) is 240 sufficient. 242 3. The FEC Encoding ID that identifies the FEC scheme. 244 4. The length of the Explicit Source FEC Payload ID (in bytes). 246 This value MAY be zero indicating that no Explicit Source FEC 247 Payload ID is used by the FEC scheme. If it is nonzero, however, 248 it means that the Explicit Source FEC Payload ID is used. In this 249 case, only one FEC scheme MUST be used for this source flow, 250 unless the generic tag (defined in [I-D.ietf-fecframe-framework]) 251 is used by all of the FEC schemes protecting this source flow. 253 5. An opaque container for the FEC-Scheme-Specific Information (FSSI) 254 that is required by only the receiver or by both the receiver and 255 sender. 257 6. Another opaque container for the FSSI that is only required by the 258 sender. This is referred to as the Sender-Side FEC-Scheme- 259 Specific Information (SS-FSSI). 261 FSSI includes the information that is specific to the FEC scheme used 262 by the CDP. FSSI is used to communicate the information that cannot 263 be adequately represented otherwise and is essential for proper FEC 264 encoding and decoding operations. The motivation behind separating 265 the FSSI required only by the sender from the rest of the FSSI is to 266 provide the receiver or the 3rd party entities a means of controlling 267 the FEC operations at the sender. Any FSSI other than the one solely 268 required by the sender MUST be communicated via the FSSI container. 270 The variable-length opaque SS-FSSI and FSSI containers transmit the 271 information in the form of an octet string. The FEC schemes define 272 the structure of this octet string, which MAY contain multiple 273 distinct elements. If the FEC scheme does not require any specific 274 information, the FSSI MAY be null. For the fully-specified FEC 275 schemes, a full description of the encoded information in both 276 containers MUST be provided. See [I-D.ietf-fecframe-framework] for 277 details. 279 Editor's note: Should we mandate base64 encoding for these fields in 280 SDP? 282 Editor's note: When RTP transport is used for the source and/or 283 repair flows, the information included in the FSSI/SS-FSSI containers 284 will be carried via the format-specific parameters ("a=fmtp" line). 286 4. SDP Descriptors for FEC Framework 288 This section defines the SDP elements that MUST be used to describe 289 the FEC Framework Configuration Information in multimedia sessions by 290 the CDPs that choose SDP [RFC4566] as their session description 291 protocol. Example SDP configurations can be found in Section 5. 293 4.1. Transport Protocol Identifiers 295 This specification defines a class of new transport protocol 296 identifiers for SDP media descriptions. For all existing identifiers 297 , this specification defines the identifier 'FEC/'. 298 This identifier MAY be used as the transport protocol identifier in 299 the media descriptions for the source data to indicate that the FEC 300 Source Packet format defined in Section 6.3 of 301 [I-D.ietf-fecframe-framework] is used, where the original transport 302 payload field is formatted according to . However, if the FEC 303 scheme does not use the Explicit Source FEC Payload ID as described 304 in Section 6.3 of [I-D.ietf-fecframe-framework], then the original 305 transport protocol identifier MUST be used to support backward 306 compatibility with the receivers that do not support FEC at all. 308 This specification also defines another transport protocol 309 identifier, 'UDP/FEC', to indicate the FEC Repair Packet format 310 defined in Section 6.4 of [I-D.ietf-fecframe-framework]. 312 4.2. Media Stream Grouping 314 The FEC Framework [I-D.ietf-fecframe-framework] states that multiple 315 instances of the FEC Framework MAY exist at the sender and the 316 receiver(s), and a source flow MAY be protected by multiple FEC 317 Framework instances. Furthermore, within a single FEC Framework 318 instance, multiple source flows MAY be protected by multiple repair 319 flows. However, each repair flow MUST provide protection for a 320 single FEC Framework instance. An example scenario is shown in 321 Figure 1. Here, source flows 0 and 1 are grouped together and 322 protected by repair flow 3; source flow 0 is also protected by repair 323 flow 4; source flows 1 and 2 are grouped together and protected by 324 repair flows 5, 6 and 7. 326 The motivation behind grouping source flows before applying FEC 327 protection is that a better coding performance may be achieved by 328 doing so and many receivers may benefit from this grouping. For 329 example, consider a layered video source that consists of one base 330 layer (e.g., source flow 0) and one enhancement layer (e.g., source 331 flow 1), where each layer is carried in a separate flow. Repair flow 332 3 protects the combination of the base and enhancement layers for the 333 receivers who receive both layers, and repair flow 4 protects the 334 base layer only, for the receivers who want the base layer only, or 335 who receive both layers but prefer FEC protection for the base layer 336 only due to a bandwidth and/or processing-power limitation. 338 Using multiple FEC Framework instances for a single source flow 339 provides flexibility to the receivers. Different instances may offer 340 repair flows that are generated by different FEC schemes, and 341 receivers choose receiving the appropriate repair flow(s) that they 342 can support and decode. Alternatively, different instances (whether 343 they use the same FEC scheme or not) may use larger and smaller 344 source block sizes, which accommodate the receivers that have looser 345 and tighter latency requirements, respectively. In addition, 346 different instances may also provide FEC protection at different 347 redundancy levels. This is particularly useful in multicast 348 scenarios where different receivers might experience different packet 349 loss rates and each receiver can choose the repair flow that is 350 tailored to its needs. 352 | FEC FRAMEWORK 353 +--------| INSTANCE 354 | | 3: Repair Flow 355 | 356 SOURCE FLOWS | | FEC FRAMEWORK 357 0: Source Flow |_| |-----| INSTANCE 358 __| 1: Source Flow | | 4: Repair Flow 359 | | 2: Source Flow 360 | | FEC FRAMEWORK 361 |__________________________| INSTANCE 362 | 5: Repair Flow 363 | 6: Repair Flow 364 | 7: Repair Flow 366 Figure 1: Example scenario with multiple FEC Framework instances 368 The 'group' attribute and the FEC grouping semantics defined in 369 [I-D.ietf-mmusic-rfc3388bis] and [I-D.ietf-mmusic-rfc4756bis], 370 respectively are used to associate source and repair flows together 371 with the following additional requirement: 373 In the case that the Explicit Source FEC Payload ID is used, then 374 only one FEC scheme MUST be used for this source flow, unless the 375 generic tag is used by all of the FEC schemes for the Source FEC 376 Payload ID, as defined in [I-D.ietf-fecframe-framework]. 378 The FEC Framework also supports additivity among the repair flows, 379 meaning that multiple repair flows MAY be decoded jointly to improve 380 the recovery chances of the missing packets. 381 [I-D.ietf-mmusic-rfc4756bis] explains how the additive repair flows 382 can be described in SDP. 384 4.3. Source IP Addresses 386 The 'source-filter' attribute of SDP ("a=source-filter") as defined 387 in [RFC4570] is used to express the source addresses or fully 388 qualified domain names in the FEC Framework. 390 4.4. Source Flows 392 The FEC Framework allows that multiple source flows MAY be grouped 393 and protected together by a single or multiple FEC Framework 394 instances. For this reason, as described in Section 3.3, individual 395 source flows MUST be identified with unique identifiers. For this 396 purpose, we introduce the attribute 'fec-source-flow'. 398 The syntax for the new attribute in ABNF [RFC5234] is as follows: 400 fec-source-flow-line = "a=fec-source-flow:" source-id 401 [";" SP tag-length] CRLF 403 source-id = "id=" src-id 404 src-id = 1*DIGIT 406 tag-length = "tag-len=" tlen 407 tlen = *DIGIT 409 The MANDATORY parameter 'id' is used to identify the source flow. 410 Note that the parameter 'id' MUST be an integer. 412 The OPTIONAL 'tag-len' parameter is used to specify the length of the 413 Explicit Source FEC Payload ID field (in bytes) and MUST be used 414 according to the requirements listed in Section 4.2. If no value is 415 specified for the 'tag-len' parameter, it indicates a value of zero. 417 4.5. Repair Flows 419 A repair flow MUST contain only repair packets formatted as described 420 in [I-D.ietf-fecframe-framework] for a single FEC Framework instance. 421 In other words, packets belonging to source flows or other repair 422 flows from a different FEC Framework instance MUST NOT be sent within 423 this flow. We introduce the attribute 'fec-repair-flow' to describe 424 the repair flows. 426 The syntax for the new attribute in ABNF is as follows: 428 fec-repair-flow-line = "a=fec-repair-flow:" fec-encoding-id 429 [";" SP flow-preference] 430 [";" SP sender-side-scheme-specific] 431 [";" SP scheme-specific] CRLF 433 fec-encoding-id = "encoding-id=" enc-id 434 enc-id = 1*DIGIT ; FEC Encoding ID 436 flow-preference = "preference-lvl=" preference-level-of-the-flow 437 preference-level-of-the-flow = *DIGIT 439 sender-side-scheme-specific = "ss-fssi=" sender-info 440 sender-info = *CHAR 442 scheme-specific = "fssi=" scheme-info 443 scheme-info = *CHAR 445 The MANDATORY parameter 'encoding-id' is used to identify the FEC 446 scheme used to generate this repair flow. These identifiers MUST be 447 registered with IANA by the FEC schemes that use the FEC Framework. 449 The OPTIONAL parameter 'preference-lvl' is used to indicate the 450 preferred order of using the repair flows. The exact usage of the 451 parameter 'preference-lvl' and the pertaining rules MAY be defined by 452 the FEC scheme or the CDP. If no value is specified for the 453 parameter 'preference-lvl', it means that the receiver(s) MAY receive 454 and use the repair flows in any order. However, if a preference 455 level is assigned to the repair flow(s), the receivers are encouraged 456 to follow the specified order in receiving and using the repair 457 flow(s). 459 The OPTIONAL parameters 'ss-fssi' and 'fssi' are opaque containers to 460 convey the FEC-Scheme-Specific Information (FSSI) that includes the 461 information that is specific to the FEC scheme used by the CDP and is 462 necessary for proper FEC encoding and decoding operations. The FSSI 463 required only by the sender (called Sender-Side FSSI) MUST be 464 communicated in the container specified by the parameter 'ss-fssi'. 465 Any other FSSI MUST be communicated in the container specified by the 466 parameter 'fssi'. In both containers, FSSI is transmitted in the 467 form of an octet string. The FEC schemes define the structure of 468 this octet string, which MAY contain multiple distinct elements. If 469 the FEC scheme does not require any specific information, the 'ss- 470 fssi' and 'fssi' parameters MAY be null and ignored. 472 4.6. Repair Window 474 An FEC encoder processes a block of source packets and generates a 475 number of repair packets, which are then transmitted within a certain 476 duration. At the receiver side, the FEC decoder tries to decode all 477 the packets received within the repair window to recover the missing 478 packets, if there are any. Repair window stands for the time that 479 spans the source packets and the corresponding repair packets. 480 Assuming that there is no issue of delay variation, the FEC decoder 481 SHOULD NOT wait longer than the repair window since additional 482 waiting would not help the recovery process. 484 This document specifies a new attribute to describe the size of the 485 repair window in milliseconds and microseconds. 487 The syntax for the attribute in ABNF is as follows: 489 repair-window-line = "a=repair-window:" window-size 490 [SP unit] CRLF 492 window-size = 1*DIGIT 494 unit = ms / us 496 is the unit of time the repair window size is specified with. 497 Currently, two units are defined: "ms", which stands for 498 milliseconds and "us", which stands for microseconds. The default 499 unit is "ms". Alternative units MAY be defined in the future by 500 registering them with IANA. 502 The 'a=repair-window' attribute is a media-level attribute since each 503 repair flow MAY have a different repair window size. 505 4.7. Bandwidth Specification 507 The bandwidth specification as defined in [RFC4566] denotes the 508 proposed bandwidth to be used by the session or media. The 509 specification of bandwidth is OPTIONAL. 511 In the context of the FEC Framework, the bandwidth specification can 512 be used to express the bandwidth of the repair flows or the bandwidth 513 of the session. If included in the SDP, it SHALL adhere to the 514 following rules: 516 The session-level bandwidth for an FEC Framework instance MAY be 517 specified. In this case, it is RECOMMENDED to use the Transport 518 Independent Application Specific (TIAS) bandwidth modifier [RFC3890] 519 and the 'a=maxprate' attribute for the session. 521 The media-level bandwidth for the individual repair flows MAY also be 522 specified. In this case, it is RECOMMENDED to use the TIAS bandwidth 523 modifier [RFC3890]. 525 The Application Specific (AS) bandwidth modifier [RFC4566] MAY be 526 used instead of TIAS, however, this is NOT RECOMMENDED since TIAS 527 allows the calculation of the bitrate according to the IP version and 528 transport protocol, whereas AS does not. Thus, in TIAS-based bitrate 529 calculations, the packet size SHALL include all headers and payload, 530 excluding the IP and UDP headers. In AS-based bitrate calculations, 531 the packet size SHALL include all headers and payload, plus the IP 532 and UDP headers. 534 For the ABNF syntax information of the TIAS and AS, refer to 535 [RFC3890] and [RFC4566], respectively. 537 5. Scenarios and Examples 539 This section discusses the considerations for session announcement 540 and offer/answer models. SDP examples that can be used by the FEC 541 Framework are also provided. 543 5.1. Declarative Considerations 545 In multicast-based applications, the FEC Framework Configuration 546 Information pertaining to all FEC protection options available at the 547 sender MAY be advertised to the receivers as a part of a session 548 announcement. This way, the sender can let the receivers know all 549 available options for FEC protection. Based on their needs, the 550 receivers MAY choose protection provided by one or more FEC Framework 551 instances and subscribe to the respective multicast group(s) to 552 receive the repair flow(s). Unless explicitly required by the CDP, 553 the receivers SHOULD NOT send an answer back to the sender specifying 554 their choices. 556 5.2. Offer/Answer Model Considerations 558 In unicast-based applications, a sender and receiver MAY adopt the 559 offer/answer model [RFC3264] to set the FEC Framework Configuration 560 Information. In this case, the sender offers all available options 561 to the receiver and the receiver answers back to the sender with its 562 choice(s). Note that some FEC protection options MAY be offered to 563 only a particular set of receivers. 565 Receivers supporting the SDP Capability Negotiation Framework 566 [I-D.ietf-mmusic-sdp-capability-negotiation] MAY also use this 567 framework to negotiate all or a subset of the FEC Framework 568 parameters. 570 The backward compatibility in offer/answer model is handled as 571 specified in [I-D.ietf-mmusic-rfc4756bis]. 573 5.3. Examples 575 Editor's note: As of now, no FEC Encoding ID has been registered 576 with IANA. In the examples below, an FEC Encoding ID of zero will be 577 used for illustrative purposes. Artificial content for the SS-FSSI 578 and FSSI will also be provided. 580 [I-D.ietf-mmusic-rfc3388bis] defines the media stream identification 581 attribute ('mid') as a token in ABNF. In contrast, the identifiers 582 for the source flows MUST be integers and SHOULD be allocated 583 starting from zero and increasing by one for each flow. To avoid any 584 ambiguity, using the same values for identifying the media streams 585 and source flows is NOT RECOMMENDED, even when 'mid' values are 586 integers. 588 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme 590 SOURCE FLOWS | INSTANCE #1 591 0: Source Flow |---------| 1: Repair Flow 592 | 594 Figure 2: Scenario #1 596 In this example, we have one source video flow (mid:S1) and one FEC 597 repair flow (mid:R1). We form one FEC group with the "a=group:FEC-XR 598 S1 R1" line. The source and repair flows are sent to the same port 599 on different multicast groups. The repair window is set to 150 ms. 601 v=0 602 o=ali 1122334455 1122334466 IN IP4 fec.example.com 603 s=FEC Framework Examples 604 t=0 0 605 a=group:FEC-XR S1 R1 606 m=video 30000 RTP/AVP 100 607 c=IN IP4 233.252.0.1/127 608 a=rtpmap:100 MP2T/90000 609 a=fec-source-flow: id=0 610 a=mid:S1 611 m=application 30000 udp/fec 612 c=IN IP4 233.252.0.2/127 613 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X 614 a=repair-window:150 615 a=mid:R1 617 5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme 619 SOURCE FLOWS 620 0: Source Flow | | INSTANCE #1 621 |---------| 2: Repair Flow 622 1: Source Flow | 624 Figure 3: Scenario #2 626 In this example, we have two source video flows (mid:S1 and mid:S2) 627 and one FEC repair flow (mid:R1), protecting both source flows. We 628 form one FEC group with the "a=group:FEC-XR S1 S2 R1" line. The 629 source and repair flows are sent to the same port on different 630 multicast groups. The repair window is set to 150500 us. 632 v=0 633 o=ali 1122334455 1122334466 IN IP4 fec.example.com 634 s=FEC Framework Examples 635 t=0 0 636 a=group:FEC-XR S1 S2 R1 637 m=video 30000 RTP/AVP 100 638 c=IN IP4 233.252.0.1/127 639 a=rtpmap:100 MP2T/90000 640 a=fec-source-flow: id=0 641 a=mid:S1 642 m=video 30000 RTP/AVP 101 643 c=IN IP4 233.252.0.2/127 644 a=rtpmap:101 MP2T/90000 645 a=fec-source-flow: id=1 646 a=mid:S2 647 m=application 30000 udp/fec 648 c=IN IP4 233.252.0.3/127 649 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X 650 a=repair-window:150500 us 651 a=mid:R1 653 5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 655 SOURCE FLOWS | INSTANCE #1 656 0: Source Flow |---------| 2: Repair Flow 658 1: Source Flow |---------| INSTANCE #2 659 | 3: Repair Flow 661 Figure 4: Scenario #3 663 In this example, we have two source video flows (mid:S1 and mid:S2) 664 and two FEC repair flows (mid:R1 and mid:R2). The source flows 665 mid:S1 and mid:S2 are protected by the repair flows mid:R1 and 666 mid:R2, respectively. We form two FEC groups with the "a=group: 667 FEC-XR S1 R1" and "a=group:FEC-XR S2 R2" lines. The source and 668 repair flows are sent to the same port on different multicast groups. 669 The repair window is set to 200 ms and 400 ms for the first and 670 second FEC group, respectively. 672 v=0 673 o=ali 1122334455 1122334466 IN IP4 fec.example.com 674 s=FEC Framework Examples 675 t=0 0 676 a=group:FEC-XR S1 R1 677 a=group:FEC-XR S2 R2 678 m=video 30000 RTP/AVP 100 679 c=IN IP4 233.252.0.1/127 680 a=rtpmap:100 MP2T/90000 681 a=fec-source-flow: id=0 682 a=mid:S1 683 m=video 30000 RTP/AVP 101 684 c=IN IP4 233.252.0.2/127 685 a=rtpmap:101 MP2T/90000 686 a=fec-source-flow: id=1 687 a=mid:S2 688 m=application 30000 udp/fec 689 c=IN IP4 233.252.0.3/127 690 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X 691 a=repair-window:200 ms 692 a=mid:R1 693 m=application 30000 udp/fec 694 c=IN IP4 233.252.0.4/127 695 a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; fssi=456WSX 696 a=repair-window:400 ms 697 a=mid:R2 699 6. Security Considerations 701 There is a weak threat if the SDP is modified in a way that it shows 702 incorrect association and/or grouping of the source and repair flows. 703 Such attacks may result in failure of FEC protection and/or 704 mishandling of other media streams. It is RECOMMENDED that the 705 receiver SHOULD do integrity check on SDP and follow the security 706 considerations of SDP [RFC4566] to only trust SDP from trusted 707 sources. For other general security considerations related to SDP, 708 refer to [RFC4566]. For the security considerations related to the 709 use of source address filters in SDP, refer to [RFC4570]. 711 7. IANA Considerations 713 7.1. Transport Protocols 715 The 'proto' sub-field of the media description line ("m=") describes 716 the transport protocol used. This document registers the following 717 values: 719 UDP/FEC 721 Editor's note: Additional transport protocols to be registered are 722 TBD. 724 7.2. Attribute Names 726 As recommended by [RFC4566], the following attribute names should be 727 registered with IANA. 729 The contact information for the registrations is: 731 Ali Begen 732 abegen@cisco.com 734 SDP Attribute ("att-field"): 735 Attribute name: fec-source-flow 736 Long form: Pointer to FEC Source Flow 737 Type of name: att-field 738 Type of attribute: Media level 739 Subject to charset: No 740 Purpose: See this document 741 Reference: This document 742 Values: See this document 744 SDP Attribute ("att-field"): 745 Attribute name: fec-repair-flow 746 Long form: Pointer to FEC Repair Flow 747 Type of name: att-field 748 Type of attribute: Media level 749 Subject to charset: No 750 Purpose: See this document 751 Reference: This document 752 Values: See this document 754 SDP Attribute ("att-field"): 755 Attribute name: repair-window 756 Long form: Repair Window Size 757 Type of name: att-field 758 Type of attribute: Media level 759 Subject to charset: No 760 Purpose: See this document 761 Reference: This document 762 Values: See this document 764 8. Acknowledgments 766 The author would like to thank the FEC Framework Design Team for 767 their inputs, suggestions and contributions. 769 9. Change Log 771 9.1. draft-ietf-fecframe-sdp-elements-03 773 The following are the major changes compared to version 02: 775 o Now referencing to 3388bis and 4756bis instead of RFC 3388 and RFC 776 4756, respectively. Also cleaned up the editor's notes regarding 777 the grouping issues. 779 o Parameter "priority" has been replaced with "preference-lvl" for 780 the repair flows. 782 9.2. draft-ietf-fecframe-sdp-elements-02 784 The following are the major changes compared to version 01: 786 o Clarified the definitions for the FSSI fields. 788 o Hostnames in the SDP examples are fixed. 790 9.3. draft-ietf-fecframe-sdp-elements-01 792 The following are the major changes compared to version 00: 794 o Additive repair flows can now be from different instances. The 795 sender may also assign different levels of priorities to each 796 repair flow regardless of whether the repair flows are additive or 797 not. 799 o SDP examples are fixed. 801 o Comments posted in the mailing list are incorporated. 803 9.4. draft-ietf-fecframe-sdp-elements-00 805 This is the initial version, which is based on an earlier individual 806 submission. The following are the major changes compared to that 807 document: 809 o The opaque container in the FEC Framework Configuration 810 Information (FEC-Scheme-Specific Information) is now divided into 811 two parts: information needed only by the sender and information 812 needed by the receiver. The repair flow descriptors are also 813 updated accordingly. 815 o "Minimum Buffer Size" is now called "Repair Window." Its size can 816 also be specified in microseconds in addition to milliseconds. 818 o Simple examples with complete SDPs are included. 820 o "Scheme ID" is changed to "Encoding ID" to be consistent with the 821 framework draft. 823 o Some other editorial changes. 825 10. References 827 10.1. Normative References 829 [I-D.ietf-fecframe-framework] 830 Watson, M., "Forward Error Correction (FEC) Framework", 831 draft-ietf-fecframe-framework-03 (work in progress), 832 October 2008. 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14, RFC 2119, March 1997. 837 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 838 Description Protocol", RFC 4566, July 2006. 840 [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol 841 (SDP) Source Filters", RFC 4570, July 2006. 843 [I-D.ietf-mmusic-rfc3388bis] 844 Camarillo, G., "The SDP (Session Description Protocol) 845 Grouping Framework", draft-ietf-mmusic-rfc3388bis-02 (work 846 in progress), January 2009. 848 [I-D.ietf-mmusic-rfc4756bis] 849 Begen, A., "Forward Error Correction Grouping Semantics in 850 Session Description Protocol", 851 draft-ietf-mmusic-rfc4756bis-02 (work in progress), 852 April 2009. 854 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 855 Modifier for the Session Description Protocol (SDP)", 856 RFC 3890, September 2004. 858 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 859 Specifications: ABNF", STD 68, RFC 5234, January 2008. 861 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 862 with Session Description Protocol (SDP)", RFC 3264, 863 June 2002. 865 10.2. Informative References 867 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 868 Correction (FEC) Building Block", RFC 5052, August 2007. 870 [I-D.ietf-fecframe-config-signaling] 871 Asati, R., "Methods to convey FEC Framework Configuration 872 Information", draft-ietf-fecframe-config-signaling-01 873 (work in progress), November 2008. 875 [I-D.ietf-mmusic-sdp-capability-negotiation] 876 Andreasen, F., "SDP Capability Negotiation", 877 draft-ietf-mmusic-sdp-capability-negotiation-10 (work in 878 progress), May 2009. 880 Author's Address 882 Ali Begen 883 Cisco Systems 884 170 West Tasman Drive 885 San Jose, CA 95134 886 USA 888 Email: abegen@cisco.com