idnits 2.17.1 draft-ietf-fecframe-sdp-elements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 882. 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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 9 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 08, 2008) is 5916 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-01 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888) == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-08 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 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 February 08, 2008 5 Expires: August 11, 2008 7 SDP Elements for FEC Framework 8 draft-ietf-fecframe-sdp-elements-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 11, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document specifies the use of Session Description Protocol (SDP) 42 to describe the parameters required to signal the Forward Error 43 Correction (FEC) Framework Configuration Information between the 44 sender(s) and receiver(s). This document also provides the semantics 45 for grouping multiple source and repair flows together for the 46 applications that simultaneously use multiple instances of the FEC 47 Framework. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 53 3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 3 54 3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 3 55 3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 4 56 3.3. FEC Framework Configuration Information . . . . . . . . . 4 57 4. FEC Framework Descriptors . . . . . . . . . . . . . . . . . . 6 58 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6 59 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7 60 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 9 61 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 11 64 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 11 65 5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 12 66 5.1. Session Announcement Considerations . . . . . . . . . . . 12 67 5.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 12 68 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme . 13 70 5.3.2. Two Source Flows, One Repair Flow and One FEC 71 Scheme . . . . . . . . . . . . . . . . . . . . . . . . 14 72 5.3.3. Two Source Flows, Two Repair Flows and Two FEC 73 Schemes . . . . . . . . . . . . . . . . . . . . . . . 15 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 16 77 7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 17 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 79 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 9.1. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 18 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 Intellectual Property and Copyright Statements . . . . . . . . . . 20 87 1. Introduction 89 The Forward Error Correction (FEC) Framework, described in 90 [I-D.ietf-fecframe-framework], outlines a general framework for using 91 FEC-based error recovery in packet flows carrying media content. 92 While a continuous signaling between the sender(s) and receiver(s) is 93 not required for a Content Delivery Protocol (CDP) that uses the FEC 94 Framework, a set of parameters pertaining to the FEC Framework MUST 95 be initially communicated between the sender(s) and receiver(s). 97 One way to communicate this information is to use the Session 98 Description Protocol (SDP) [RFC4566]. SDP provides a simple text- 99 based format for announcements and invitations to describe multimedia 100 sessions. These SDP announcements and invitations include sufficient 101 information for the sender(s) and receiver(s) to participate in the 102 multimedia sessions. SDP also provides a framework for capability 103 negotiation, which MAY be used to negotiate all or a subset of the 104 parameters pertaining to the individual sessions. 106 The purpose of this document is to introduce the SDP elements that 107 MUST be used by the CDPs using the FEC Framework that choose SDP 108 [RFC4566] as their session description protocol. 110 2. Requirements Notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Forward Error Correction (FEC) and FEC Framework 118 This section gives a brief overview of FEC and the FEC Framework. 120 3.1. Forward Error Correction (FEC) 122 Any application that needs a reliable transmission over an unreliable 123 packet network has to cope with the packet losses. FEC is an 124 effective approach that provides reliable transmission particularly 125 in multicast and broadcast applications where the feedback from the 126 receiver(s) may be potentially limited. In a nutshell, FEC groups 127 source packets into blocks and applies protection to generate a 128 desired number of repair packets. 130 Repair packets MAY be sent on demand or independently of any receiver 131 feedback. The choice depends on the FEC code used by the 132 application, the error characteristics of the underlying network, the 133 transport scheme (e.g., unicast, multicast, and broadcast), and the 134 application. At the receiver side, lost packets can be recovered by 135 erasure decoding provided that a sufficient number of source and 136 repair packets are received. See [I-D.ietf-fecframe-framework] for 137 further details. 139 3.2. FEC Framework 141 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 142 framework for using FEC codes in multimedia applications that stream 143 audio, video or other types of multimedia content. It defines the 144 common components and aspects of Content Delivery Protocols (CDP). 145 The FEC Framework also defines the requirements for the FEC schemes 146 that need to be used within a CDP. However, the details of the FEC 147 schemes are not specified within the FEC Framework. For example, the 148 FEC Framework defines what configuration information has to be known 149 at the sender and receiver(s) at minimum, but the FEC Framework 150 neither specifies how the FEC repair packets are generated and used 151 to recover missing source packets, nor dictates how the configuration 152 information is communicated between the sender and receiver(s). 153 These are rather specified by the individual FEC schemes or CDPs. 155 For a proper operation, the information required by the FEC Framework 156 and the details of an FEC scheme have to be communicated between the 157 sender and receiver(s). One way to provide this information is to 158 use the Session Description Protocol (SDP) [RFC4566]. SDP provides a 159 commonly used text-based format for announcements and invitations 160 that describe multimedia sessions. These SDP announcements and 161 invitations include sufficient information for clients to participate 162 in multimedia sessions. By using the SDP capability negotiation 163 framework, all or a subset of the parameters pertaining to the FEC 164 Framework MAY also be negotiated between the sender and receiver(s). 166 The purpose of this document is to introduce the SDP elements that 167 MUST be used by the CDPs using the FEC Framework that choose SDP 168 [RFC4566] as their session description protocol. 170 Note that there are many similarities between the FEC Framework 171 [I-D.ietf-fecframe-framework] and the FEC Building Block [RFC5052], 172 which describes a framework that uses FEC codes to provide 173 reliability to bulk data transfer applications running over IP 174 multicast or broadcast. See [I-D.ietf-fecframe-framework] for 175 further details. 177 3.3. FEC Framework Configuration Information 179 The FEC Framework defines a minimum set of information that MUST be 180 communicated between the sender and receiver(s) for a proper 181 operation of an FEC scheme. This information is called the FEC 182 Framework Configuration Information. This information specifies how 183 the sender applies protection to the source flow(s) and how the 184 repair flow(s) can be used to recover lost data. In other words, 185 this information specifies the relationship(s) between the source and 186 repair flows. 188 The FEC Framework Configuration Information includes identifiers for 189 unique identification of the source and repair flows that carry the 190 source and repair packets, respectively. For example, a packet flow 191 that is transmitted over UDP is uniquely identified by the tuple of 192 {Source IP Address, Destination IP Address, Source UDP port, 193 Destination UDP port}. However, an integer identifier MAY be used 194 internally within the FEC scheme as a shorthand to identify this 195 flow. 197 Multiple instances of the FEC Framework MAY simultaneously exist at 198 the sender and the receiver(s) for different source flows, for the 199 same source flow, or for various combinations of source flows. Each 200 instance of the FEC Framework MUST provide the following FEC 201 Framework Configuration Information: 203 1. Identification of the repair flows. 205 2. For each source flow protected by the repair flow(s): 207 a. Definition of the source flow. 209 b. An integer identifier for this flow definition (i.e., tuple). 210 This identifier MUST be unique amongst all source flows that are 211 protected by the same FEC repair flow. The identifiers SHOULD be 212 allocated starting from zero and increasing by one for each flow. 214 A source flow identifier need not be carried in source packets 215 since source packets are directly associated with a flow by virtue 216 of their packet headers. Note that an application MAY wildcard 217 some of the fields if only a subset of the fields of the tuple 218 (e.g., {Destination IP Address, Destination UDP port} ) is 219 sufficient. 221 3. The FEC Encoding ID that identifies the FEC scheme. 223 4. The length of the Explicit Source FEC Payload ID (in bytes). 225 This value MAY be zero indicating that no Explicit Source FEC 226 Payload ID is used by the FEC scheme. If it is nonzero, however, 227 it means that the Explicit Source FEC Payload ID is used. In this 228 case, only one FEC scheme MUST be used for this source flow, 229 unless the generic tag (defined in [I-D.ietf-fecframe-framework]) 230 is used by all of the FEC schemes protecting this source flow. 232 5. An opaque container for the FEC-Scheme-Specific Information 233 required only by the sender. This information is referred to as 234 the Sender-Side FEC-Scheme-Specific Information (SS-FSSI). 236 6. An opaque container for the FEC-Scheme-Specific Information 237 required by the receiver. This information is referred to as the 238 Receiver-Side FEC-Scheme-Specific Information (RS-FSSI). 240 FSSI includes the information that is specific to the FEC scheme used 241 by the CDP. FSSI is used to communicate the information that cannot 242 be adequately represented otherwise and is essential for proper FEC 243 encoding and decoding operations. The motivation behind separating 244 the FSSI required only by the sender from the rest of the FSSI is to 245 provide the receiver or the 3rd party entities a means of controlling 246 the FEC operations at the sender. Any FSSI other than the one solely 247 required by the sender MUST be communicated via the RS-FSSI 248 container. 250 The variable-length opaque SS-FSSI and RS-FSSI containers transmit 251 the information in the form of an octet string. The FEC schemes 252 define the structure of this octet string, which MAY contain multiple 253 distinct elements. If the FEC scheme does not require any specific 254 information, the FSSI MAY be null. For the fully-specified FEC 255 schemes, a full description of the encoded information in both 256 containers MUST be provided. See [I-D.ietf-fecframe-framework] for 257 details. 259 4. FEC Framework Descriptors 261 This section defines the SDP elements that MUST be used to describe 262 the FEC Framework Configuration Information in multimedia sessions by 263 the CDPs that choose SDP [RFC4566] as their session description 264 protocol. Example SDP configurations can be found in Section 5. 266 4.1. Transport Protocol Identifiers 268 This specification defines a class of new transport protocol 269 identifiers for SDP media descriptions. For all existing identifiers 270 , this specification defines the identifier 'FEC/'. 271 This identifier MAY be used as the transport protocol identifier in 272 the media descriptions for the source data to indicate that the FEC 273 Source Packet format defined in Section 6.3 of 274 [I-D.ietf-fecframe-framework] is used, where the original transport 275 payload field is formatted according to . However, if the FEC 276 scheme does not use the Explicit Source FEC Payload ID as described 277 in Section 6.3 of [I-D.ietf-fecframe-framework], then the original 278 transport protocol identifier MUST be used to support backward 279 compatibility with the receivers that do not support FEC at all. 281 This specification also defines another transport protocol 282 identifier, 'UDP/FEC', to indicate the FEC Repair Packet format 283 defined in Section 6.4 of [I-D.ietf-fecframe-framework]. 285 4.2. Media Stream Grouping 287 The FEC Framework [I-D.ietf-fecframe-framework] states that multiple 288 instances of the FEC Framework MAY exist at the sender and the 289 receiver(s), and a source flow MAY be protected by multiple FEC 290 Framework instances. Furthermore, within a single FEC Framework 291 instance, multiple source flows MAY be protected by multiple repair 292 flows. However, each repair flow MUST provide protection for a 293 single FEC Framework instance. An example scenario is shown in 294 Figure 1. Here, source flows 0 and 1 are grouped together and 295 protected by repair flow 3; source flow 0 is also protected by repair 296 flow 4; source flows 1 and 2 are grouped together and protected by 297 repair flows 5, 6 and 7. 299 The motivation behind grouping source flows before applying FEC 300 protection is that a better coding performance can be achieved by 301 doing so and many receivers may benefit from this grouping. For 302 example, consider a layered video source that consists of one base 303 layer (e.g., source flow 0) and one enhancement layer (e.g., source 304 flow 1), where each layer is carried in a separate flow. Repair flow 305 3 protects the combination of the base and enhancement layers for the 306 receivers who receive both layers, and repair flow 4 protects the 307 base layer only, for the receivers who want the base layer only, or 308 who receive both layers but prefer FEC protection for the base layer 309 only due to their bandwidth and/or processing limitations. 311 Using multiple FEC Framework instances for a single source flow 312 provides flexibility to the receivers. Some instances may use larger 313 or smaller source block sizes, which accommodate the receivers that 314 have looser and tighter latency requirements, respectively. 315 Different instances may also provide FEC protection at different 316 redundancy levels. This enables the receivers experiencing different 317 packet loss rates to choose the repair flows that are tailored to 318 their needs. 320 ____| FEC FRAMEWORK 321 / | INSTANCE 322 / | 3: Repair Flow 323 / 324 SOURCE FLOWS / __| FEC FRAMEWORK 325 0: Source Flow |___/ |---' | INSTANCE 326 1: Source Flow | |____ | 4: Repair Flow 327 2: Source Flow | \ 328 \ | FEC FRAMEWORK 329 \_| INSTANCE 330 | 5: Repair Flow 331 | 6: Repair Flow 332 | 7: Repair Flow 334 Figure 1: Example scenario with multiple FEC Framework instances 336 The 'group' attribute and the FEC grouping semantics defined in 337 [RFC4756] are used to associate source and repair flows together with 338 the following additional requirement: 340 In the case that the Explicit Source FEC Payload ID is used, then 341 only one FEC scheme MUST be used for this source flow, unless the 342 generic tag is used by all of the FEC schemes for the Source FEC 343 Payload ID, as defined in [I-D.ietf-fecframe-framework]. 345 The 'group' attribute MAY be used to group multiple repair flows with 346 one or more source flows. Note that [RFC3388] prohibits an "m" line 347 identified by its 'mid' attribute from appearing in more than one 348 "a=group:FEC" line. Thus, [RFC3388] mandates us to write 350 a=group:FEC 0 1 2 3 4 5 6 7 352 for the scenario sketched in Figure 1. This limitation prevents us 353 from indicating particular associations between the source and repair 354 flows by using an "a=group:FEC" line per FEC Framework instance 355 [RFC4756]. 357 Editor's note: The FEC grouping and flow association issues are 358 currently under discussion in FECFRAME and MMUSIC WGs. This section 359 will be updated once a decision is made. 361 The FEC Framework also supports additivity among the repair flows, 362 meaning that multiple repair flows MAY be decoded jointly to improve 363 the recovery chances of the missing packets. In addition, the sender 364 MAY assign different levels of priority to each repair flow. See 365 Section 4.5 for details. 367 4.3. Source IP Addresses 369 The 'source-filter' attribute of SDP ("a=source-filter") as defined 370 in [RFC4570] is used to express the source addresses or fully 371 qualified domain names in the FEC Framework. 373 Editor's note: Additional requirements or exceptions regarding 374 source filters are TBD. 376 4.4. Source Flows 378 The FEC Framework allows that multiple source flows MAY be grouped 379 and protected together by a single or multiple FEC Framework 380 instances. For this reason, as described in Section 3.3, individual 381 source flows MUST be identified with unique identifiers. For this 382 purpose, we introduce the attribute 'fec-source-flow'. 384 The syntax for the new attribute in ABNF [RFC5234] is as follows: 386 fec-source-flow-line = "a=fec-source-flow:" source-id 387 [";" SP tag-length] CRLF 389 source-id = "id=" src-id 390 src-id = 1*DIGIT 392 tag-length = "tag-len=" tlen 393 tlen = *DIGIT 395 The MANDATORY parameter 'id' is used to identify the source flow. 396 Note that the parameter 'id' MUST be an integer. 398 The OPTIONAL 'tag-len' parameter is used to specify the length of the 399 Explicit Source FEC Payload ID field (in bytes) and MUST be used 400 according to the requirements listed in Section 4.2. If no value is 401 specified for the 'tag-len' parameter, it indicates a value of zero. 403 4.5. Repair Flows 405 A repair flow MUST contain only repair packets formatted as described 406 in [I-D.ietf-fecframe-framework] for a single FEC Framework instance. 407 In other words, packets belonging to source flows or other repair 408 flows from a different FEC Framework instance MUST NOT be sent within 409 this flow. We introduce the attribute 'fec-repair-flow' to describe 410 the repair flows. 412 The syntax for the new attribute in ABNF is as follows: 414 fec-repair-flow-line = "a=fec-repair-flow:" fec-encoding-id 415 [";" SP flow-priority] [";" SP sender-side-scheme-specific] 416 [";" SP receiver-side-scheme-specific] CRLF 418 fec-encoding-id = "encoding-id=" enc-id 419 enc-id = 1*DIGIT ; FEC Encoding ID 421 flow-priority = "priority=" priority-of-the-flow 422 priority-of-the-flow = *DIGIT 424 sender-side-scheme-specific = "ss-fssi=" sender-info 425 sender-info = *CHAR 427 receiver-side-scheme-specific = "rs-fssi=" receiver-info 428 receiver-info = *CHAR 430 The MANDATORY parameter 'encoding-id' is used to identify the FEC 431 scheme used to generate this repair flow. These identifiers MUST be 432 registered with IANA by the FEC schemes that use the FEC Framework. 434 The OPTIONAL parameter 'priority' is used to indicate the priorities 435 of the repair flows when multiple repair flows are grouped together 436 to be used in an additive manner within a single FEC Framework 437 instance. The exact usage of the parameter 'priority' and the 438 pertaining rules SHOULD be defined by the FEC scheme or the CDP. If 439 no value is specified for the parameter 'priority', it means that the 440 receiver(s) MAY receive and use the repair flows in any order. 441 However, if a priority is assigned to the repair flow(s), the 442 receivers MUST follow the specified order in receiving and using the 443 repair flow(s). 445 The OPTIONAL parameters 'ss-fssi' and 'rs-fssi' are opaque containers 446 to convey the FEC-Scheme-Specific Information (FSSI) that includes 447 the information that is specific to the FEC scheme used by the CDP 448 and is necessary for proper FEC encoding and decoding operations. 449 The FSSI required only by the sender (called Sender-Side FSSI) MUST 450 be communicated in the container specified by the parameter 'ss- 451 fssi'. Any other FSSI (called Receiver-Side FSSI) MUST be 452 communicated in the container specified by the parameter 'rs-fssi'. 453 In both containers, FSSI is transmitted in the form of an octet 454 string. The FEC schemes define the structure of this octet string, 455 which MAY contain multiple distinct elements. If the FEC scheme does 456 not require any specific information, the 'ss-fssi' and 'rs-fssi' 457 parameters MAY be null and ignored. 459 4.6. Repair Window 461 An FEC encoder processes a block of source packets and generates a 462 number of repair packets, which are then transmitted within a certain 463 duration. At the receiver side, the FEC decoder tries to decode all 464 the packets received within the repair window to recover the missing 465 packets, if there are any. Repair window stands for the time that 466 spans the source packets and the corresponding repair packets. 467 Assuming that there is no issue of delay variation, the FEC decoder 468 SHOULD NOT wait longer than the repair window since additional 469 waiting would not help the recovery process. 471 This document specifies a new attribute to describe the size of the 472 repair window in milliseconds and microseconds. 474 The syntax for the attribute in ABNF is as follows: 476 repair-window-line = "a=repair-window:" window-size 477 [SP unit] CRLF 479 window-size = 1*DIGIT 481 unit = ms / us 483 is the unit of time the repair window size is specified with. 484 Currently, two units are defined: "ms", which stands for 485 milliseconds and "us", which stands for microseconds. The default 486 unit is "ms". Alternative units MAY be defined in the future by 487 registering them with IANA. 489 The 'a=repair-window' attribute is a media-level attribute since each 490 repair flow MAY have a different repair window value. 492 4.7. Bandwidth Specification 494 The bandwidth specification as defined in [RFC4566] denotes the 495 proposed bandwidth to be used by the session or media. The 496 specification of bandwidth is OPTIONAL. 498 In the context of the FEC Framework, the bandwidth specification can 499 be used to express the bandwidth of the repair flows or the bandwidth 500 of the session. If included in the SDP, it SHALL adhere to the 501 following rules: 503 The session-level bandwidth for an FEC Framework instance MAY be 504 specified. In this case, it is RECOMMENDED to use the Transport 505 Independent Application Specific (TIAS) bandwidth modifier [RFC3890] 506 and the 'a=maxprate' attribute for the session. 508 The media-level bandwidth for the individual repair flows MAY also be 509 specified. In this case, it is RECOMMENDED to use the TIAS bandwidth 510 modifier [RFC3890]. 512 The Application Specific (AS) bandwidth modifier [RFC4566] MAY be 513 used instead of TIAS, however, this is NOT RECOMMENDED since TIAS 514 allows the calculation of the bitrate according to the IP version and 515 transport protocol, whereas AS does not. Thus, in TIAS-based bitrate 516 calculations, the packet size SHALL include all headers and payload, 517 excluding the IP and UDP headers. In AS-based bitrate calculations, 518 the packet size SHALL include all headers and payload, plus the IP 519 and UDP headers. 521 For the ABNF syntax information of the TIAS and AS, refer to 522 [RFC3890] and [RFC4566], respectively. 524 5. Scenarios and Examples 526 This section discusses the considerations for session announcement 527 and offer/answer models. SDP examples that can be used by the FEC 528 Framework are also provided. 530 5.1. Session Announcement Considerations 532 In multicast-based applications, the FEC Framework Configuration 533 Information pertaining to all FEC protection options available at the 534 sender MAY be advertised to the receivers as a part of a session 535 announcement. This way, the sender can let the receivers know all 536 available options for FEC protection. Based on their needs, the 537 receivers MAY choose protection provided by one or more FEC Framework 538 instances and subscribe to the respective multicast group(s) to 539 receive the repair flow(s). Unless explicitly required by the CDP, 540 the receivers SHOULD NOT send an answer back to the sender specifying 541 their choices. 543 5.2. Offer/Answer Considerations 545 In unicast-based applications, a sender and receiver MAY adopt the 546 offer/answer model [RFC3264] to set the FEC Framework Configuration 547 Information. In this case, the sender offers all available options 548 to the receiver and the receiver answers back to the sender with its 549 choice(s). Note that some FEC protection options MAY be offered to 550 only a particular set of (e.g., premium) receivers. 552 Receivers supporting the SDP Capability Negotiation Framework 553 [I-D.ietf-mmusic-sdp-capability-negotiation] MAY also use this 554 framework to negotiate all or a subset of the FEC Framework 555 parameters. 557 The backward compatibility in offer/answer model is handled as 558 specified in [RFC3388]. If a receiver receives an offer containing 559 FEC grouping and it does not understand the FEC grouping semantics, 560 it MAY respond with an answer that ignores the grouping attribute or 561 MAY refuse the request. In the first case, the offerer MUST 562 establish the connection without FEC. In the second case, if the 563 offerer still wishes to establish the session, it SHOULD retry the 564 request with an offer without FEC. 566 5.3. Examples 568 Editor's note: More examples showing the usage of multiple FEC 569 Framework instances, additivity of the repair flows and 570 prioritization of the repair flows will be provided once the issues 571 related to FEC grouping and flow association are resolved. 573 Editor's note: As of now, no FEC Encoding ID has been registered 574 with IANA. In the examples below, an FEC Encoding ID of zero and an 575 encoding (i.e., payload format) of 'parityfec' will be used for 576 illustrative purposes. Artificial content for the SS-FSSI and RS- 577 FSSI will also be provided. 579 [RFC3388] defines the media stream identification attribute ('mid') 580 as a token in ABNF. In contrast, the identifiers for the source 581 flows MUST be integers and SHOULD be allocated starting from zero and 582 increasing by one for each flow. To avoid any ambiguity, using the 583 same values for identifying the media streams and source flows is NOT 584 RECOMMENDED, even when 'mid' values are integers. 586 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme 588 SOURCE FLOWS | INSTANCE #1 589 0: Source Flow |---------| 1: Repair Flow 591 Figure 6: Scenario #1 593 In this example, we have one source video stream (mid:S1) and one FEC 594 repair stream (mid:R1). We form one FEC group with the "a=group:FEC 595 S1 R1" line. The source and repair streams are sent to the same port 596 on different multicast groups. The repair window is set to 150 ms. 598 v=0 599 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 600 s=FEC Framework Examples 601 t=0 0 602 a=group:FEC S1 R1 603 m=video 30000 RTP/AVP 100 604 c=IN IP4 224.1.1.1/127 605 a=rtpmap:100 MP2T/90000 606 a=fec-source-flow: id=0 607 a=mid:S1 608 m=video 30000 RTP/AVP 110 609 c=IN IP4 224.1.2.1/127 610 a=rtpmap:110 parityfec/90000 611 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X 612 a=repair-window: 150 613 a=mid:R1 615 5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme 617 SOURCE FLOWS | INSTANCE #1 618 0: Source Flow |_________| 2: Repair Flow 619 1: Source Flow | 621 Figure 8: Scenario #2 623 In this example, we have two source video streams (mid:S1 and mid:S2) 624 and one FEC repair stream (mid:R1), protecting both source streams. 625 We form one FEC group with the "a=group:FEC S1 S2 R1" line. The 626 source and repair streams are sent to the same port on different 627 multicast groups. The repair window is set to 150500 us. 629 v=0 630 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 631 s=FEC Framework Examples 632 t=0 0 633 a=group:FEC S1 S2 R1 634 m=video 30000 RTP/AVP 100 635 c=IN IP4 224.1.1.1/127 636 a=rtpmap:100 MP2T/90000 637 a=fec-source-flow: id=0 638 a=mid:S1 639 m=video 30000 RTP/AVP 101 640 c=IN IP4 224.1.1.2/127 641 a=rtpmap:101 MP2T/90000 642 a=fec-source-flow: id=1 643 a=mid:S2 644 m=video 30000 RTP/AVP 110 645 c=IN IP4 224.1.2.1/127 646 a=rtpmap:110 parityfec/90000 647 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X 648 a=repair-window: 150500 us 649 a=mid:R1 651 5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 653 SOURCE FLOWS | INSTANCE #1 654 0: Source Flow |---------| 2: Repair Flow 655 1: Source Flow |_ 656 \-------| INSTANCE #2 657 | 3: Repair Flow 659 Figure 10: Scenario #3 661 In this example, we have two source video streams (mid:S1 and mid:S2) 662 and two FEC repair streams (mid:R1 and mid:R2). The source streams 663 mid:S1 and mid:S2 are protected by the repair streams mid:R1 and 664 mid:R2, respectively. We form two FEC groups with the "a=group:FEC 665 S1 R1" and "a=group:FEC S2 R2" lines. The source and repair streams 666 are sent to the same port on different multicast groups. The repair 667 window is set to 200 ms and 400 ms for the first and second FEC 668 group, respectively. 670 v=0 671 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 672 s=FEC Framework Examples 673 t=0 0 674 a=group:FEC S1 R1 675 a=group:FEC S2 R2 676 m=video 30000 RTP/AVP 100 677 c=IN IP4 224.1.1.1/127 678 a=rtpmap:100 MP2T/90000 679 a=fec-source-flow: id=0 680 a=mid:S1 681 m=video 30000 RTP/AVP 101 682 c=IN IP4 224.1.1.2/127 683 a=rtpmap:101 MP2T/90000 684 a=fec-source-flow: id=1 685 a=mid:S2 686 m=video 30000 RTP/AVP 110 687 c=IN IP4 224.1.2.1/127 688 a=rtpmap:110 parityfec/90000 689 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X 690 a=repair-window: 200 ms 691 a=mid:R1 692 m=video 30000 RTP/AVP 111 693 c=IN IP4 224.1.2.2/127 694 a=rtpmap:111 parityfec/90000 695 a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; rs-fssi=456WSX 696 a=repair-window: 400 ms 697 a=mid:R2 699 6. Security Considerations 701 For the general security considerations related to SDP, refer to 702 [RFC4566]. For the security considerations related to source/FEC 703 media stream grouping in SDP and use of source address filters in 704 SDP, refer to [RFC4756] and [RFC4570], respectively. 706 7. IANA Considerations 708 7.1. Transport Protocols 710 The 'proto' sub-field of the media description line ("m=") describes 711 the transport protocol used. This document registers the following 712 values: 714 UDP/FEC 716 Editor's note: Additional transport protocols to be registered are 717 TBD. 719 7.2. Attribute Names 721 As recommended by [RFC4566], the following attribute names should be 722 registered with IANA. 724 The contact information for the registrations is: 726 Ali Begen 727 abegen@cisco.com 729 SDP Attribute ("att-field"): 730 Attribute name: fec-source-flow 731 Long form: Pointer to FEC Source Flow 732 Type of name: att-field 733 Type of attribute: Media level 734 Subject to charset: No 735 Purpose: See this document 736 Reference: This document 737 Values: See this document 739 SDP Attribute ("att-field"): 740 Attribute name: fec-repair-flow 741 Long form: Pointer to FEC Repair Flow 742 Type of name: att-field 743 Type of attribute: Media level 744 Subject to charset: No 745 Purpose: See this document 746 Reference: This document 747 Values: See this document 749 SDP Attribute ("att-field"): 750 Attribute name: repair-window 751 Long form: Repair Window Size 752 Type of name: att-field 753 Type of attribute: Media level 754 Subject to charset: No 755 Purpose: See this document 756 Reference: This document 757 Values: See this document 759 8. Acknowledgments 761 The author would like to thank the FEC Framework Design Team for 762 their inputs, suggestions and contributions. 764 9. Change Log 766 9.1. draft-ietf-fecframe-sdp-elements-00 768 This is the initial version, which is based on an earlier individual 769 submission. The following are the major changes compared to that 770 document: 772 o The opaque container in the FEC Framework Configuration 773 Information (FEC-Scheme-Specific Information) is now divided into 774 two parts: information needed only by the sender and information 775 needed by the receiver. The repair flow descriptors are also 776 updated accordingly. 778 o "Minimum Buffer Size" is now called "Repair Window." Its size can 779 also be specified in microseconds in addition to milliseconds. 781 o Simple examples with complete SDPs are included. 783 o "Scheme ID" is changed to "Encoding ID" to be consistent with the 784 framework draft. 786 o Some other editorial changes. 788 10. References 790 10.1. Normative References 792 [I-D.ietf-fecframe-framework] 793 Watson, M., "Forward Error Correction (FEC) Framework", 794 draft-ietf-fecframe-framework-01 (work in progress), 795 November 2007. 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, March 1997. 800 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 801 Description Protocol", RFC 4566, July 2006. 803 [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol 804 (SDP) Source Filters", RFC 4570, July 2006. 806 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 807 Session Description Protocol", RFC 4756, November 2006. 809 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 810 Schulzrinne, "Grouping of Media Lines in the Session 811 Description Protocol (SDP)", RFC 3388, December 2002. 813 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 814 Modifier for the Session Description Protocol (SDP)", 815 RFC 3890, September 2004. 817 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 818 Specifications: ABNF", STD 68, RFC 5234, January 2008. 820 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 821 with Session Description Protocol (SDP)", RFC 3264, 822 June 2002. 824 [I-D.ietf-mmusic-sdp-capability-negotiation] 825 Andreasen, F., "SDP Capability Negotiation", 826 draft-ietf-mmusic-sdp-capability-negotiation-08 (work in 827 progress), December 2007. 829 10.2. Informative References 831 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 832 Correction (FEC) Building Block", RFC 5052, August 2007. 834 Author's Address 836 Ali Begen 837 Cisco Systems 838 170 West Tasman Drive 839 San Jose, CA 95134 840 USA 842 Email: abegen@cisco.com 844 Full Copyright Statement 846 Copyright (C) The IETF Trust (2008). 848 This document is subject to the rights, licenses and restrictions 849 contained in BCP 78, and except as set forth therein, the authors 850 retain all their rights. 852 This document and the information contained herein are provided on an 853 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 854 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 855 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 856 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 857 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 858 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 860 Intellectual Property 862 The IETF takes no position regarding the validity or scope of any 863 Intellectual Property Rights or other rights that might be claimed to 864 pertain to the implementation or use of the technology described in 865 this document or the extent to which any license under such rights 866 might or might not be available; nor does it represent that it has 867 made any independent effort to identify any such rights. Information 868 on the procedures with respect to rights in RFC documents can be 869 found in BCP 78 and BCP 79. 871 Copies of IPR disclosures made to the IETF Secretariat and any 872 assurances of licenses to be made available, or the result of an 873 attempt made to obtain a general license or permission for the use of 874 such proprietary rights by implementers or users of this 875 specification can be obtained from the IETF on-line IPR repository at 876 http://www.ietf.org/ipr. 878 The IETF invites any interested party to bring to its attention any 879 copyrights, patents or patent applications, or other proprietary 880 rights that may cover technology that may be required to implement 881 this standard. Please address the information to the IETF at 882 ietf-ipr@ietf.org. 884 Acknowledgment 886 Funding for the RFC Editor function is provided by the IETF 887 Administrative Support Activity (IASA).