idnits 2.17.1 draft-ietf-fecframe-sdp-elements-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (April 28, 2010) is 5083 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) == Missing Reference: 'RFCXXXX' is mentioned on line 773, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-07 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-rfc4756bis-07 == Outdated reference: A later version (-09) exists of draft-ietf-fecframe-config-signaling-02 Summary: 1 error (**), 0 flaws (~~), 6 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 4 Intended status: Standards Track April 28, 2010 5 Expires: October 30, 2010 7 SDP Elements for FEC Framework 8 draft-ietf-fecframe-sdp-elements-06 10 Abstract 12 This document specifies the use of Session Description Protocol (SDP) 13 to describe the parameters required to signal the Forward Error 14 Correction (FEC) Framework Configuration Information between the 15 sender(s) and receiver(s). This document also provides examples that 16 show the semantics for grouping multiple source and repair flows 17 together for the applications that simultaneously use multiple 18 instances of the FEC Framework. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on October 30, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 18 92 7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 18 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 94 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 9.1. draft-ietf-fecframe-sdp-elements-06 . . . . . . . . . . . 19 96 9.2. draft-ietf-fecframe-sdp-elements-05 . . . . . . . . . . . 19 97 9.3. draft-ietf-fecframe-sdp-elements-04 . . . . . . . . . . . 19 98 9.4. draft-ietf-fecframe-sdp-elements-03 . . . . . . . . . . . 19 99 9.5. draft-ietf-fecframe-sdp-elements-02 . . . . . . . . . . . 20 100 9.6. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 20 101 9.7. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 20 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 1. Introduction 109 The Forward Error Correction (FEC) Framework, described in 110 [I-D.ietf-fecframe-framework], outlines a general framework for using 111 FEC-based error recovery in packet flows carrying media content. 112 While a continuous signaling between the sender(s) and receiver(s) is 113 not required for a Content Delivery Protocol (CDP) that uses the FEC 114 Framework, a set of parameters pertaining to the FEC Framework MUST 115 be initially communicated between the sender(s) and receiver(s). A 116 signaling protocol (such as the one described in 117 [I-D.ietf-fecframe-config-signaling]) is required to enable such 118 communication and the parameters must be appropriately encoded so 119 that they can be carried by the signaling protocol. 121 One format to encode the parameters is the Session Description 122 Protocol (SDP) [RFC4566]. SDP provides a simple text-based format 123 for announcements and invitations to describe multimedia sessions. 124 These SDP announcements and invitations include sufficient 125 information for the sender(s) and receiver(s) to participate in the 126 multimedia sessions. SDP also provides a framework for capability 127 negotiation, which may be used to negotiate all or a subset of the 128 parameters pertaining to the individual sessions. 130 The purpose of this document is to introduce the SDP elements that 131 MUST be used by the CDPs using the FEC Framework that choose SDP 132 [RFC4566] as their session description protocol. 134 2. Requirements Notation 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. Forward Error Correction (FEC) and FEC Framework 142 This section gives a brief overview of FEC and the FEC Framework. 144 3.1. Forward Error Correction (FEC) 146 Any application that needs a reliable transmission over an unreliable 147 packet network has to cope with packet losses. FEC is an effective 148 approach that provides reliable transmission particularly in 149 multicast and broadcast applications where the feedback from the 150 receiver(s) is potentially limited. 152 In a nutshell, FEC groups source packets into blocks and applies 153 protection to generate a desired number of repair packets. These 154 repair packets may be sent on demand or independently of any receiver 155 feedback. The choice depends on the FEC scheme or the Content 156 Delivery Protocol used by the application, the packet loss 157 characteristics of the underlying network, the transport scheme 158 (e.g., unicast, multicast and broadcast) and the application. At the 159 receiver side, lost packets can be recovered by erasure decoding 160 provided that a sufficient number of source and repair packets have 161 been received. 163 3.2. FEC Framework 165 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 166 framework for using FEC codes in multimedia applications that stream 167 audio, video or other types of multimedia content. It defines the 168 common components and aspects of Content Delivery Protocols (CDP). 169 The FEC Framework also defines the requirements for the FEC schemes 170 that need to be used within a CDP. However, the details of the FEC 171 schemes are not specified within the FEC Framework. For example, the 172 FEC Framework defines what configuration information has to be known 173 at the sender and receiver(s) at minimum, but the FEC Framework 174 neither specifies how the FEC repair packets are generated and used 175 to recover missing source packets, nor dictates how the configuration 176 information is communicated between the sender and receiver(s). 177 These are rather specified by the individual FEC schemes or CDPs. 179 For a proper operation, the information required by the FEC Framework 180 and the details of an FEC scheme have to be communicated between the 181 sender and receiver(s). One way to provide this information is to 182 use the Session Description Protocol (SDP) [RFC4566]. SDP provides a 183 commonly used text-based format for announcements and invitations 184 that describe multimedia sessions. These SDP announcements and 185 invitations include sufficient information for clients to participate 186 in multimedia sessions. By using the SDP capability negotiation 187 framework, all or a subset of the parameters pertaining to the FEC 188 Framework may also be negotiated between the sender and receiver(s). 190 The purpose of this document is to introduce the SDP elements that 191 MUST be used by the CDPs using the FEC Framework that choose SDP 192 [RFC4566] as their session description protocol. 194 Note that there are many similarities between the FEC Framework 195 [I-D.ietf-fecframe-framework] and the FEC Building Block [RFC5052], 196 which describes a framework that uses FEC codes to provide 197 reliability to bulk data transfer applications running over IP 198 multicast or broadcast. See [I-D.ietf-fecframe-framework] for 199 further details. 201 3.3. FEC Framework Configuration Information 203 The FEC Framework defines a minimum set of information that MUST be 204 communicated between the sender and receiver(s) for a proper 205 operation of an FEC scheme. This information is called the FEC 206 Framework Configuration Information. This information specifies how 207 the sender applies protection to the source flow(s) and how the 208 repair flow(s) can be used to recover lost data. In other words, 209 this information specifies the relationship(s) between the source and 210 repair flows. 212 The FEC Framework Configuration Information includes identifiers for 213 unique identification of the source and repair flows that carry the 214 source and repair packets, respectively. For example, a packet flow 215 that is transmitted over UDP is uniquely identified by the tuple of 216 {Source IP Address, Destination IP Address, Source UDP Port, 217 Destination UDP Port}. However, an integer identifier MAY be used 218 internally within the FEC scheme as a shorthand to identify this 219 flow. 221 Multiple instances of the FEC Framework MAY simultaneously exist at 222 the sender and the receiver(s) for different source flows, for the 223 same source flow, or for various combinations of source flows. Each 224 instance of the FEC Framework MUST provide the following FEC 225 Framework Configuration Information: 227 1. Identification of the repair flows. 229 2. For each source flow protected by the repair flow(s): 231 a. Definition of the source flow. 233 b. An integer identifier for this flow definition (i.e., tuple). 234 This identifier MUST be unique amongst all source flows that are 235 protected by the same FEC repair flow. The identifiers SHOULD be 236 allocated starting from zero and increasing by one for each flow. 238 A source flow identifier need not be carried in source packets 239 since source packets are directly associated with a flow by virtue 240 of their packet headers. Note that an application MAY wildcard 241 some of the fields if only a subset of the fields of the tuple 242 (e.g., {Destination IP Address, Destination UDP Port} ) is 243 sufficient. 245 3. The FEC Encoding ID that identifies the FEC scheme. 247 4. The length of the Explicit Source FEC Payload ID (in bytes). 249 This value MAY be zero indicating that no Explicit Source FEC 250 Payload ID is used by the FEC scheme. If it is nonzero, however, 251 it means that the Explicit Source FEC Payload ID is used. In this 252 case, only one FEC scheme MUST be used for this source flow, 253 unless the generic tag (defined in [I-D.ietf-fecframe-framework]) 254 is used by all of the FEC schemes protecting this source flow. 256 5. A container for the FEC-Scheme-Specific Information (FSSI) that is 257 required by only the receiver or by both the receiver and sender. 259 6. Another container for the FSSI that is only required by the 260 sender. This is referred to as the Sender-Side FEC-Scheme- 261 Specific Information (SS-FSSI). 263 FSSI includes the information that is specific to the FEC scheme used 264 by the CDP. FSSI is used to communicate the information that cannot 265 be adequately represented otherwise and is essential for proper FEC 266 encoding and decoding operations. The motivation behind separating 267 the FSSI required only by the sender from the rest of the FSSI is to 268 provide the receiver or the third party entities a means of 269 controlling the FEC operations at the sender. Any FSSI other than 270 the one solely required by the sender MUST be communicated via the 271 FSSI container. 273 The variable-length SS-FSSI and FSSI containers transmit the 274 information in textual representation and MAY contain multiple 275 distinct elements. For the fully-specified FEC schemes, a full 276 description of these elements for both containers MUST be provided. 277 If the FEC scheme does not require any specific information, the FSSI 278 MAY be null. 280 Note that when RTP transport is used for the source and/or repair 281 flows, the information in the FSSI/SS-FSSI containers will be carried 282 via the format-specific parameters (i.e., "a=fmtp" line). 284 4. SDP Descriptors for FEC Framework 286 This section defines the SDP elements that MUST be used to describe 287 the FEC Framework Configuration Information in multimedia sessions by 288 the CDPs that choose SDP [RFC4566] as their session description 289 protocol. Example SDP configurations can be found in Section 5. 291 4.1. Transport Protocol Identifiers 293 This specification defines a class of new transport protocol 294 identifiers for SDP media descriptions. For all existing identifiers 295 , this specification defines the identifier 'FEC/'. 296 This identifier MAY be used as the transport protocol identifier in 297 the media descriptions for the source data to indicate that the FEC 298 Source Packet format defined in Section 6.3 of 299 [I-D.ietf-fecframe-framework] is used, where the original transport 300 payload field is formatted according to . However, if the FEC 301 scheme does not use the Explicit Source FEC Payload ID as described 302 in Section 6.3 of [I-D.ietf-fecframe-framework], then the original 303 transport protocol identifier MUST be used to support backward 304 compatibility with the receivers that do not support FEC at all. 306 This specification also defines another transport protocol 307 identifier, 'UDP/FEC', to indicate the FEC Repair Packet format 308 defined in Section 6.4 of [I-D.ietf-fecframe-framework]. 310 4.2. Media Stream Grouping 312 The FEC Framework [I-D.ietf-fecframe-framework] states that multiple 313 instances of the FEC Framework MAY exist at the sender and the 314 receiver(s), and a source flow MAY be protected by multiple FEC 315 Framework instances. Furthermore, within a single FEC Framework 316 instance, multiple source flows MAY be protected by multiple repair 317 flows. However, each repair flow MUST provide protection for a 318 single FEC Framework instance. An example scenario is shown in 319 Figure 1. Here, source flows 0 and 1 are grouped together and 320 protected by repair flow 3; source flow 0 is also protected by repair 321 flow 4; source flows 1 and 2 are grouped together and protected by 322 repair flows 5, 6 and 7. 324 The motivation behind grouping source flows before applying FEC 325 protection is that a better coding performance may be achieved by 326 doing so and many receivers may benefit from this grouping. For 327 example, consider a layered video source that consists of one base 328 layer (e.g., source flow 0) and one enhancement layer (e.g., source 329 flow 1), where each layer is carried in a separate flow. Repair flow 330 3 protects the combination of the base and enhancement layers for the 331 receivers who receive both layers, and repair flow 4 protects the 332 base layer only, for the receivers who want the base layer only, or 333 who receive both layers but prefer FEC protection for the base layer 334 only due to a bandwidth and/or processing-power limitation. 336 Using multiple FEC Framework instances for a single source flow 337 provides flexibility to the receivers. Different instances may offer 338 repair flows that are generated by different FEC schemes, and 339 receivers choose receiving the appropriate repair flow(s) that they 340 can support and decode. Alternatively, different instances (whether 341 they use the same FEC scheme or not) may use larger and smaller 342 source block sizes, which accommodate the receivers that have looser 343 and tighter latency requirements, respectively. In addition, 344 different instances may also provide FEC protection at different 345 redundancy levels. This is particularly useful in multicast 346 scenarios where different receivers might experience different packet 347 loss rates and each receiver can choose the repair flow that is 348 tailored to its needs. 350 | FEC FRAMEWORK 351 +--------| INSTANCE 352 | | 3: Repair Flow 353 | 354 SOURCE FLOWS | | FEC FRAMEWORK 355 0: Source Flow |_| |-----| INSTANCE 356 __| 1: Source Flow | | 4: Repair Flow 357 | | 2: Source Flow 358 | | FEC FRAMEWORK 359 |__________________________| INSTANCE 360 | 5: Repair Flow 361 | 6: Repair Flow 362 | 7: Repair Flow 364 Figure 1: Example scenario with multiple FEC Framework instances 366 The 'group' attribute and the FEC grouping semantics defined in 367 [I-D.ietf-mmusic-rfc3388bis] and [I-D.ietf-mmusic-rfc4756bis], 368 respectively are used to associate source and repair flows together 369 with the following additional requirement: 371 In the case that the Explicit Source FEC Payload ID is used, then 372 only one FEC scheme MUST be used for this source flow, unless the 373 generic tag is used by all of the FEC schemes for the Source FEC 374 Payload ID, as defined in [I-D.ietf-fecframe-framework]. 376 The FEC Framework also supports additivity among the repair flows, 377 meaning that multiple repair flows MAY be decoded jointly to improve 378 the recovery chances of the missing packets. 379 [I-D.ietf-mmusic-rfc4756bis] explains how the additive repair flows 380 can be described in SDP. 382 4.3. Source IP Addresses 384 The 'source-filter' attribute of SDP ("a=source-filter") as defined 385 in [RFC4570] is used to express the source addresses or fully 386 qualified domain names in the FEC Framework. 388 4.4. Source Flows 390 The FEC Framework allows that multiple source flows MAY be grouped 391 and protected together by a single or multiple FEC Framework 392 instances. For this reason, as described in Section 3.3, individual 393 source flows MUST be identified with unique identifiers. For this 394 purpose, we introduce the attribute 'fec-source-flow'. 396 The syntax for the new attribute in ABNF [RFC5234] is as follows: 398 fec-source-flow-line = "a=fec-source-flow:" source-id 399 [";" SP tag-length] CRLF 401 source-id = "id=" src-id 402 src-id = 1*DIGIT 404 tag-length = "tag-len=" tlen 405 tlen = *DIGIT 407 The MANDATORY parameter 'id' is used to identify the source flow. 408 Note that the parameter 'id' MUST be an integer. 410 The OPTIONAL 'tag-len' parameter is used to specify the length of the 411 Explicit Source FEC Payload ID field (in bytes) and MUST be used 412 according to the requirements listed in Section 4.2. If no value is 413 specified for the 'tag-len' parameter, it indicates a value of zero. 415 4.5. Repair Flows 417 A repair flow MUST contain only repair packets formatted as described 418 in [I-D.ietf-fecframe-framework] for a single FEC Framework instance. 419 In other words, packets belonging to source flows or other repair 420 flows from a different FEC Framework instance MUST NOT be sent within 421 this flow. We introduce the attribute 'fec-repair-flow' to describe 422 the repair flows. 424 The syntax for the new attribute in ABNF is as follows: 426 fec-repair-flow-line = "a=fec-repair-flow:" SP fec-encoding-id 427 [";" SP flow-preference] 428 [";" SP sender-side-scheme-specific] 429 [";" SP scheme-specific] CRLF 431 fec-encoding-id = "encoding-id=" enc-id 432 enc-id = 1*DIGIT ; FEC Encoding ID 434 flow-preference = "preference-lvl=" preference-level-of-the-flow 435 preference-level-of-the-flow = *DIGIT 437 sender-side-scheme-specific = "ss-fssi=" sender-info 438 sender-info = *CHAR 440 scheme-specific = "fssi=" scheme-info 441 scheme-info = *CHAR 443 The MANDATORY parameter 'encoding-id' is used to identify the FEC 444 scheme used to generate this repair flow. These identifiers MUST be 445 registered with IANA by the FEC schemes that use the FEC Framework. 447 The OPTIONAL parameter 'preference-lvl' is used to indicate the 448 preferred order of using the repair flows. The exact usage of the 449 parameter 'preference-lvl' and the pertaining rules MAY be defined by 450 the FEC scheme or the CDP. If no value is specified for the 451 parameter 'preference-lvl', it means that the receiver(s) MAY receive 452 and use the repair flows in any order. However, if a preference 453 level is assigned to the repair flow(s), the receivers are encouraged 454 to follow the specified order in receiving and using the repair 455 flow(s). 457 The OPTIONAL parameters 'ss-fssi' and 'fssi' are containers to convey 458 the FEC-Scheme-Specific Information (FSSI) that includes the 459 information that is specific to the FEC scheme used by the CDP and is 460 necessary for proper FEC encoding and decoding operations. The FSSI 461 required only by the sender (called Sender-Side FSSI) MUST be 462 communicated in the container specified by the parameter 'ss-fssi'. 463 Any other FSSI MUST be communicated in the container specified by the 464 parameter 'fssi'. In both containers, FSSI is transmitted in the 465 form of textual representation and MAY contain multiple distinct 466 elements. If the FEC scheme does not require any specific 467 information, the 'ss-fssi' and 'fssi' parameters MAY be null and 468 ignored. 470 4.6. Repair Window 472 Repair window is the time that spans an FEC block, which consists of 473 the source block and the corresponding repair packets. 475 At the sender side, the FEC encoder processes a block of source 476 packets and generates a number of repair packets. Then both the 477 source and repair packets are transmitted within a certain duration 478 not larger than the value of the repair window. The value of the 479 repair window impacts the maximum number of source packets that can 480 be included in an FEC block. 482 At the receiver side, the FEC decoder should wait at least for the 483 duration of the repair window after getting the first packet in an 484 FEC block to allow all the repair packets to arrive (The waiting time 485 can be adjusted if there are mising packets at the beginning of the 486 FEC block). The FEC decoder may start decoding the already received 487 packets sooner, however, it SHOULD NOT register an FEC decoding 488 failure until it waits at least for the repair-window duration. 490 This document specifies a new attribute to describe the size of the 491 repair window in milliseconds and microseconds. 493 The syntax for the attribute in ABNF is as follows: 495 repair-window-line = "a=repair-window:" window-size 496 [unit] CRLF 498 window-size = 1*DIGIT 500 unit = ms / us 502 is the unit of time the repair window size is specified with. 503 Currently, two units are defined: 'ms', which stands for 504 milliseconds and 'us', which stands for microseconds. The default 505 unit is 'ms'. Alternative units MAY be defined in the future by 506 registering them with IANA. 508 The 'a=repair-window' attribute is a media-level attribute since each 509 repair flow MAY have a different repair window size. 511 Specifying the repair window size in an absolute time value may not 512 correspond to an integer number of packets or exactly match with the 513 clock rate used in RTP (in case of RTP transport) causing mismatches 514 among subsequent repair windows. However, in practice, this mismatch 515 does not break anything in the FEC decoding process. 517 4.7. Bandwidth Specification 519 The bandwidth specification as defined in [RFC4566] denotes the 520 proposed bandwidth to be used by the session or media. The 521 specification of bandwidth is OPTIONAL. 523 In the context of the FEC Framework, the bandwidth specification can 524 be used to express the bandwidth of the repair flows or the bandwidth 525 of the session. If included in the SDP, it SHALL adhere to the 526 following rules: 528 The session-level bandwidth for an FEC Framework instance MAY be 529 specified. In this case, it is RECOMMENDED to use the Transport 530 Independent Application Specific (TIAS) bandwidth modifier [RFC3890] 531 and the 'a=maxprate' attribute for the session. 533 The media-level bandwidth for the individual repair flows MAY also be 534 specified. In this case, it is RECOMMENDED to use the TIAS bandwidth 535 modifier [RFC3890]. 537 The Application Specific (AS) bandwidth modifier [RFC4566] MAY be 538 used instead of TIAS, however, this is NOT RECOMMENDED since TIAS 539 allows the calculation of the bitrate according to the IP version and 540 transport protocol, whereas AS does not. Thus, in TIAS-based bitrate 541 calculations, the packet size SHALL include all headers and payload, 542 excluding the IP and UDP headers. In AS-based bitrate calculations, 543 the packet size SHALL include all headers and payload, plus the IP 544 and UDP headers. 546 For the ABNF syntax information of the TIAS and AS, refer to 547 [RFC3890] and [RFC4566], respectively. 549 5. Scenarios and Examples 551 This section discusses the considerations for session announcement 552 and offer/answer models. SDP examples that can be used by the FEC 553 Framework are also provided. 555 5.1. Declarative Considerations 557 In multicast-based applications, the FEC Framework Configuration 558 Information pertaining to all FEC protection options available at the 559 sender MAY be advertised to the receivers as a part of a session 560 announcement. This way, the sender can let the receivers know all 561 available options for FEC protection. Based on their needs, the 562 receivers MAY choose protection provided by one or more FEC Framework 563 instances and subscribe to the respective multicast group(s) to 564 receive the repair flow(s). Unless explicitly required by the CDP, 565 the receivers SHOULD NOT send an answer back to the sender specifying 566 their choices. 568 5.2. Offer/Answer Model Considerations 570 In unicast-based applications, a sender and receiver MAY adopt the 571 offer/answer model [RFC3264] to set the FEC Framework Configuration 572 Information. In this case, the sender offers all available options 573 to the receiver and the receiver answers back to the sender with its 574 choice(s). Note that some FEC protection options MAY be offered to 575 only a particular set of receivers. 577 Receivers supporting the SDP Capability Negotiation Framework 578 [I-D.ietf-mmusic-sdp-capability-negotiation] MAY also use this 579 framework to negotiate all or a subset of the FEC Framework 580 parameters. 582 The backward compatibility in offer/answer model is handled as 583 specified in [I-D.ietf-mmusic-rfc4756bis]. 585 5.3. Examples 587 [I-D.ietf-mmusic-rfc3388bis] defines the media stream identification 588 attribute ('mid') as a token in ABNF. In contrast, the identifiers 589 for the source flows MUST be integers and SHOULD be allocated 590 starting from zero and increasing by one for each flow. To avoid any 591 ambiguity, using the same values for identifying the media streams 592 and source flows is NOT RECOMMENDED, even when 'mid' values are 593 integers. 595 In the examples below, an FEC Encoding ID of zero will be used for 596 illustrative purposes. Artificial content for the SS-FSSI and FSSI 597 will also be provided. 599 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme 601 SOURCE FLOWS | INSTANCE #1 602 0: Source Flow |---------| 1: Repair Flow 603 | 605 Figure 2: Scenario #1 607 In this example, we have one source video flow (mid:S1) and one FEC 608 repair flow (mid:R1). We form one FEC group with the "a=group:FEC-XR 609 S1 R1" line. The source and repair flows are sent to the same port 610 on different multicast groups. The repair window is set to 150 ms. 612 v=0 613 o=ali 1122334455 1122334466 IN IP4 fec.example.com 614 s=FEC Framework Examples 615 t=0 0 616 a=group:FEC-XR S1 R1 617 m=video 30000 RTP/AVP 100 618 c=IN IP4 233.252.0.1/127 619 a=rtpmap:100 MP2T/90000 620 a=fec-source-flow: id=0 621 a=mid:S1 622 m=application 30000 udp/fec 623 c=IN IP4 233.252.0.2/127 624 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 625 a=repair-window:150 626 a=mid:R1 628 5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme 630 SOURCE FLOWS 631 0: Source Flow | | INSTANCE #1 632 |---------| 2: Repair Flow 633 1: Source Flow | 635 Figure 3: Scenario #2 637 In this example, we have two source video flows (mid:S1 and mid:S2) 638 and one FEC repair flow (mid:R1), protecting both source flows. We 639 form one FEC group with the "a=group:FEC-XR S1 S2 R1" line. The 640 source and repair flows are sent to the same port on different 641 multicast groups. The repair window is set to 150500 us. 643 v=0 644 o=ali 1122334455 1122334466 IN IP4 fec.example.com 645 s=FEC Framework Examples 646 t=0 0 647 a=group:FEC-XR S1 S2 R1 648 m=video 30000 RTP/AVP 100 649 c=IN IP4 233.252.0.1/127 650 a=rtpmap:100 MP2T/90000 651 a=fec-source-flow: id=0 652 a=mid:S1 653 m=video 30000 RTP/AVP 101 654 c=IN IP4 233.252.0.2/127 655 a=rtpmap:101 MP2T/90000 656 a=fec-source-flow: id=1 657 a=mid:S2 658 m=application 30000 udp/fec 659 c=IN IP4 233.252.0.3/127 660 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 661 a=repair-window:150500us 662 a=mid:R1 664 5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 666 SOURCE FLOWS | INSTANCE #1 667 0: Source Flow |---------| 2: Repair Flow 669 1: Source Flow |---------| INSTANCE #2 670 | 3: Repair Flow 672 Figure 4: Scenario #3 674 In this example, we have two source video flows (mid:S1 and mid:S2) 675 and two FEC repair flows (mid:R1 and mid:R2). The source flows 676 mid:S1 and mid:S2 are protected by the repair flows mid:R1 and 677 mid:R2, respectively. We form two FEC groups with the "a=group: 678 FEC-XR S1 R1" and "a=group:FEC-XR S2 R2" lines. The source and 679 repair flows are sent to the same port on different multicast groups. 680 The repair window is set to 200 ms and 400 ms for the first and 681 second FEC group, respectively. 683 v=0 684 o=ali 1122334455 1122334466 IN IP4 fec.example.com 685 s=FEC Framework Examples 686 t=0 0 687 a=group:FEC-XR S1 R1 688 a=group:FEC-XR S2 R2 689 m=video 30000 RTP/AVP 100 690 c=IN IP4 233.252.0.1/127 691 a=rtpmap:100 MP2T/90000 692 a=fec-source-flow: id=0 693 a=mid:S1 694 m=video 30000 RTP/AVP 101 695 c=IN IP4 233.252.0.2/127 696 a=rtpmap:101 MP2T/90000 697 a=fec-source-flow: id=1 698 a=mid:S2 699 m=application 30000 udp/fec 700 c=IN IP4 233.252.0.3/127 701 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 702 a=repair-window:200ms 703 a=mid:R1 704 m=application 30000 udp/fec 705 c=IN IP4 233.252.0.4/127 706 a=fec-repair-flow: encoding-id=0; ss-fssi=n:14,k:10 707 a=repair-window:400ms 708 a=mid:R2 710 6. Security Considerations 712 There is a weak threat if the SDP is modified in a way that it shows 713 incorrect association and/or grouping of the source and repair flows. 714 Such attacks may result in failure of FEC protection and/or 715 mishandling of other media streams. It is RECOMMENDED that the 716 receiver SHOULD do integrity check on SDP and follow the security 717 considerations of SDP [RFC4566] to only trust SDP from trusted 718 sources. For other general security considerations related to SDP, 719 refer to [RFC4566]. For the security considerations related to the 720 use of source address filters in SDP, refer to [RFC4570]. 722 7. IANA Considerations 724 The following contact information shall be used for all registrations 725 in this document: 727 Ali Begen 728 abegen@cisco.com 730 7.1. Transport Protocols 732 The 'proto' sub-field of the media description line ("m=") describes 733 the transport protocol used. This document registers the following 734 values: 736 UDP/FEC 738 7.2. Attribute Names 740 As recommended by [RFC4566], the following attribute names should be 741 registered with IANA. 743 Note to the RFC Editor: In the following, please replace "XXXX" with 744 the number of this document prior to publication as an RFC. 746 SDP Attribute ("att-field"): 747 Attribute name: fec-source-flow 748 Long form: Pointer to FEC Source Flow 749 Type of name: att-field 750 Type of attribute: Media level 751 Subject to charset: No 752 Purpose: See this document 753 Reference: [RFCXXXX] 754 Values: See this document 756 SDP Attribute ("att-field"): 757 Attribute name: fec-repair-flow 758 Long form: Pointer to FEC Repair Flow 759 Type of name: att-field 760 Type of attribute: Media level 761 Subject to charset: No 762 Purpose: See this document 763 Reference: [RFCXXXX] 764 Values: See this document 766 SDP Attribute ("att-field"): 767 Attribute name: repair-window 768 Long form: Repair Window Size 769 Type of name: att-field 770 Type of attribute: Media level 771 Subject to charset: No 772 Purpose: See this document 773 Reference: [RFCXXXX] 774 Values: See this document 776 8. Acknowledgments 778 The author would like to thank the FEC Framework Design Team for 779 their inputs, suggestions and contributions. 781 9. Change Log 783 9.1. draft-ietf-fecframe-sdp-elements-06 785 The following are the major changes compared to version 05: 787 o Addressed the comments received during the WGLC. 789 9.2. draft-ietf-fecframe-sdp-elements-05 791 The following are the major changes compared to version 04: 793 o Updated boilerplate. 795 9.3. draft-ietf-fecframe-sdp-elements-04 797 The following are the major changes compared to version 03: 799 o Incorporated final outstanding issues for the WGLC. 801 9.4. draft-ietf-fecframe-sdp-elements-03 803 The following are the major changes compared to version 02: 805 o Now referencing to 3388bis and 4756bis instead of RFC 3388 and RFC 806 4756, respectively. Also cleaned up the editor's notes regarding 807 the grouping issues. 809 o Parameter "priority" has been replaced with "preference-lvl" for 810 the repair flows. 812 9.5. draft-ietf-fecframe-sdp-elements-02 814 The following are the major changes compared to version 01: 816 o Clarified the definitions for the FSSI fields. 818 o Hostnames in the SDP examples are fixed. 820 9.6. draft-ietf-fecframe-sdp-elements-01 822 The following are the major changes compared to version 00: 824 o Additive repair flows can now be from different instances. The 825 sender may also assign different levels of priorities to each 826 repair flow regardless of whether the repair flows are additive or 827 not. 829 o SDP examples are fixed. 831 o Comments posted in the mailing list are incorporated. 833 9.7. draft-ietf-fecframe-sdp-elements-00 835 This is the initial version, which is based on an earlier individual 836 submission. The following are the major changes compared to that 837 document: 839 o The opaque container in the FEC Framework Configuration 840 Information (FEC-Scheme-Specific Information) is now divided into 841 two parts: information needed only by the sender and information 842 needed by the receiver. The repair flow descriptors are also 843 updated accordingly. 845 o "Minimum Buffer Size" is now called "Repair Window." Its size can 846 also be specified in microseconds in addition to milliseconds. 848 o Simple examples with complete SDPs are included. 850 o "Scheme ID" is changed to "Encoding ID" to be consistent with the 851 framework draft. 853 o Some other editorial changes. 855 10. References 856 10.1. Normative References 858 [I-D.ietf-fecframe-framework] 859 Watson, M., "Forward Error Correction (FEC) Framework", 860 draft-ietf-fecframe-framework-07 (work in progress), 861 March 2010. 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, March 1997. 866 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 867 Description Protocol", RFC 4566, July 2006. 869 [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol 870 (SDP) Source Filters", RFC 4570, July 2006. 872 [I-D.ietf-mmusic-rfc3388bis] 873 Camarillo, G. and H. Schulzrinne, "The SDP (Session 874 Description Protocol) Grouping Framework", 875 draft-ietf-mmusic-rfc3388bis-04 (work in progress), 876 November 2009. 878 [I-D.ietf-mmusic-rfc4756bis] 879 Begen, A., "Forward Error Correction Grouping Semantics in 880 Session Description Protocol", 881 draft-ietf-mmusic-rfc4756bis-07 (work in progress), 882 April 2010. 884 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 885 Modifier for the Session Description Protocol (SDP)", 886 RFC 3890, September 2004. 888 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 889 Specifications: ABNF", STD 68, RFC 5234, January 2008. 891 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 892 with Session Description Protocol (SDP)", RFC 3264, 893 June 2002. 895 10.2. Informative References 897 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 898 Correction (FEC) Building Block", RFC 5052, August 2007. 900 [I-D.ietf-fecframe-config-signaling] 901 Asati, R., "Methods to convey FEC Framework Configuration 902 Information", draft-ietf-fecframe-config-signaling-02 903 (work in progress), February 2010. 905 [I-D.ietf-mmusic-sdp-capability-negotiation] 906 Andreasen, F., "SDP Capability Negotiation", 907 draft-ietf-mmusic-sdp-capability-negotiation-13 (work in 908 progress), March 2010. 910 Author's Address 912 Ali Begen 913 Cisco 914 170 West Tasman Drive 915 San Jose, CA 95134 916 USA 918 Email: abegen@cisco.com