idnits 2.17.1 draft-ietf-fecframe-sdp-elements-01.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 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 897. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 903. 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 (July 14, 2008) is 5764 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-02 ** 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 (-09) exists of draft-ietf-fecframe-config-signaling-00 ** Downref: Normative reference to an Informational draft: draft-ietf-fecframe-config-signaling (ref. 'I-D.ietf-fecframe-config-signaling') == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-08 Summary: 5 errors (**), 0 flaws (~~), 7 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 July 14, 2008 5 Expires: January 15, 2009 7 SDP Elements for FEC Framework 8 draft-ietf-fecframe-sdp-elements-01 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 January 15, 2009. 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 . . . . . . . . . 5 57 4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 10 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-01 . . . . . . . . . . . 18 81 9.2. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 18 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 Intellectual Property and Copyright Statements . . . . . . . . . . 21 88 1. Introduction 90 The Forward Error Correction (FEC) Framework, described in 91 [I-D.ietf-fecframe-framework], outlines a general framework for using 92 FEC-based error recovery in packet flows carrying media content. 93 While a continuous signaling between the sender(s) and receiver(s) is 94 not required for a Content Delivery Protocol (CDP) that uses the FEC 95 Framework, a set of parameters pertaining to the FEC Framework MUST 96 be initially communicated between the sender(s) and receiver(s). A 97 signaling protocol (such as the one described in 98 [I-D.ietf-fecframe-config-signaling]) is required to enable such 99 communication and the parameters must be appropriately encoded so 100 that they can be carried by the signaling protocol. 102 One format to encode the parameters is the Session Description 103 Protocol (SDP) [RFC4566]. SDP provides a simple text-based format 104 for announcements and invitations to describe multimedia sessions. 105 These SDP announcements and invitations include sufficient 106 information for the sender(s) and receiver(s) to participate in the 107 multimedia sessions. SDP also provides a framework for capability 108 negotiation, which MAY be used to negotiate all or a subset of the 109 parameters pertaining to the individual sessions. 111 The purpose of this document is to introduce the SDP elements that 112 MUST be used by the CDPs using the FEC Framework that choose SDP 113 [RFC4566] as their session description protocol. 115 2. Requirements Notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Forward Error Correction (FEC) and FEC Framework 123 This section gives a brief overview of FEC and the FEC Framework. 125 3.1. Forward Error Correction (FEC) 127 Any application that needs a reliable transmission over an unreliable 128 packet network has to cope with the packet losses. FEC is an 129 effective approach that provides reliable transmission particularly 130 in multicast and broadcast applications where the feedback from the 131 receiver(s) may be potentially limited. In a nutshell, FEC groups 132 source packets into blocks and applies protection to generate a 133 desired number of repair packets. 135 Repair packets MAY be sent on demand or independently of any receiver 136 feedback. The choice depends on the FEC code used by the 137 application, the error characteristics of the underlying network, the 138 transport scheme (e.g., unicast, multicast, and broadcast), and the 139 application. At the receiver side, lost packets can be recovered by 140 erasure decoding provided that a sufficient number of source and 141 repair packets are received. See [I-D.ietf-fecframe-framework] for 142 further details. 144 3.2. FEC Framework 146 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 147 framework for using FEC codes in multimedia applications that stream 148 audio, video or other types of multimedia content. It defines the 149 common components and aspects of Content Delivery Protocols (CDP). 150 The FEC Framework also defines the requirements for the FEC schemes 151 that need to be used within a CDP. However, the details of the FEC 152 schemes are not specified within the FEC Framework. For example, the 153 FEC Framework defines what configuration information has to be known 154 at the sender and receiver(s) at minimum, but the FEC Framework 155 neither specifies how the FEC repair packets are generated and used 156 to recover missing source packets, nor dictates how the configuration 157 information is communicated between the sender and receiver(s). 158 These are rather specified by the individual FEC schemes or CDPs. 160 For a proper operation, the information required by the FEC Framework 161 and the details of an FEC scheme have to be communicated between the 162 sender and receiver(s). One way to provide this information is to 163 use the Session Description Protocol (SDP) [RFC4566]. SDP provides a 164 commonly used text-based format for announcements and invitations 165 that describe multimedia sessions. These SDP announcements and 166 invitations include sufficient information for clients to participate 167 in multimedia sessions. By using the SDP capability negotiation 168 framework, all or a subset of the parameters pertaining to the FEC 169 Framework MAY also be negotiated between the sender and receiver(s). 171 The purpose of this document is to introduce the SDP elements that 172 MUST be used by the CDPs using the FEC Framework that choose SDP 173 [RFC4566] as their session description protocol. 175 Note that there are many similarities between the FEC Framework 176 [I-D.ietf-fecframe-framework] and the FEC Building Block [RFC5052], 177 which describes a framework that uses FEC codes to provide 178 reliability to bulk data transfer applications running over IP 179 multicast or broadcast. See [I-D.ietf-fecframe-framework] for 180 further details. 182 3.3. FEC Framework Configuration Information 184 The FEC Framework defines a minimum set of information that MUST be 185 communicated between the sender and receiver(s) for a proper 186 operation of an FEC scheme. This information is called the FEC 187 Framework Configuration Information. This information specifies how 188 the sender applies protection to the source flow(s) and how the 189 repair flow(s) can be used to recover lost data. In other words, 190 this information specifies the relationship(s) between the source and 191 repair flows. 193 The FEC Framework Configuration Information includes identifiers for 194 unique identification of the source and repair flows that carry the 195 source and repair packets, respectively. For example, a packet flow 196 that is transmitted over UDP is uniquely identified by the tuple of 197 {Source IP Address, Destination IP Address, Source UDP port, 198 Destination UDP port}. However, an integer identifier MAY be used 199 internally within the FEC scheme as a shorthand to identify this 200 flow. 202 Multiple instances of the FEC Framework MAY simultaneously exist at 203 the sender and the receiver(s) for different source flows, for the 204 same source flow, or for various combinations of source flows. Each 205 instance of the FEC Framework MUST provide the following FEC 206 Framework Configuration Information: 208 1. Identification of the repair flows. 210 2. For each source flow protected by the repair flow(s): 212 a. Definition of the source flow. 214 b. An integer identifier for this flow definition (i.e., tuple). 215 This identifier MUST be unique amongst all source flows that are 216 protected by the same FEC repair flow. The identifiers SHOULD be 217 allocated starting from zero and increasing by one for each flow. 219 A source flow identifier need not be carried in source packets 220 since source packets are directly associated with a flow by virtue 221 of their packet headers. Note that an application MAY wildcard 222 some of the fields if only a subset of the fields of the tuple 223 (e.g., {Destination IP Address, Destination UDP port} ) is 224 sufficient. 226 3. The FEC Encoding ID that identifies the FEC scheme. 228 4. The length of the Explicit Source FEC Payload ID (in bytes). 230 This value MAY be zero indicating that no Explicit Source FEC 231 Payload ID is used by the FEC scheme. If it is nonzero, however, 232 it means that the Explicit Source FEC Payload ID is used. In this 233 case, only one FEC scheme MUST be used for this source flow, 234 unless the generic tag (defined in [I-D.ietf-fecframe-framework]) 235 is used by all of the FEC schemes protecting this source flow. 237 5. An opaque container for the FEC-Scheme-Specific Information 238 required only by the sender. This information is referred to as 239 the Sender-Side FEC-Scheme-Specific Information (SS-FSSI). 241 6. An opaque container for the FEC-Scheme-Specific Information 242 required by the receiver. This information is referred to as the 243 Receiver-Side FEC-Scheme-Specific Information (RS-FSSI). 245 FSSI includes the information that is specific to the FEC scheme used 246 by the CDP. FSSI is used to communicate the information that cannot 247 be adequately represented otherwise and is essential for proper FEC 248 encoding and decoding operations. The motivation behind separating 249 the FSSI required only by the sender from the rest of the FSSI is to 250 provide the receiver or the 3rd party entities a means of controlling 251 the FEC operations at the sender. Any FSSI other than the one solely 252 required by the sender MUST be communicated via the RS-FSSI 253 container. 255 The variable-length opaque SS-FSSI and RS-FSSI containers transmit 256 the information in the form of an octet string. The FEC schemes 257 define the structure of this octet string, which MAY contain multiple 258 distinct elements. If the FEC scheme does not require any specific 259 information, the FSSI MAY be null. For the fully-specified FEC 260 schemes, a full description of the encoded information in both 261 containers MUST be provided. See [I-D.ietf-fecframe-framework] for 262 details. 264 4. SDP Descriptors for FEC Framework 266 This section defines the SDP elements that MUST be used to describe 267 the FEC Framework Configuration Information in multimedia sessions by 268 the CDPs that choose SDP [RFC4566] as their session description 269 protocol. Example SDP configurations can be found in Section 5. 271 4.1. Transport Protocol Identifiers 273 This specification defines a class of new transport protocol 274 identifiers for SDP media descriptions. For all existing identifiers 275 , this specification defines the identifier 'FEC/'. 276 This identifier MAY be used as the transport protocol identifier in 277 the media descriptions for the source data to indicate that the FEC 278 Source Packet format defined in Section 6.3 of 279 [I-D.ietf-fecframe-framework] is used, where the original transport 280 payload field is formatted according to . However, if the FEC 281 scheme does not use the Explicit Source FEC Payload ID as described 282 in Section 6.3 of [I-D.ietf-fecframe-framework], then the original 283 transport protocol identifier MUST be used to support backward 284 compatibility with the receivers that do not support FEC at all. 286 This specification also defines another transport protocol 287 identifier, 'UDP/FEC', to indicate the FEC Repair Packet format 288 defined in Section 6.4 of [I-D.ietf-fecframe-framework]. 290 4.2. Media Stream Grouping 292 The FEC Framework [I-D.ietf-fecframe-framework] states that multiple 293 instances of the FEC Framework MAY exist at the sender and the 294 receiver(s), and a source flow MAY be protected by multiple FEC 295 Framework instances. Furthermore, within a single FEC Framework 296 instance, multiple source flows MAY be protected by multiple repair 297 flows. However, each repair flow MUST provide protection for a 298 single FEC Framework instance. An example scenario is shown in 299 Figure 1. Here, source flows 0 and 1 are grouped together and 300 protected by repair flow 3; source flow 0 is also protected by repair 301 flow 4; source flows 1 and 2 are grouped together and protected by 302 repair flows 5, 6 and 7. 304 The motivation behind grouping source flows before applying FEC 305 protection is that a better coding performance can be achieved by 306 doing so and many receivers may benefit from this grouping. For 307 example, consider a layered video source that consists of one base 308 layer (e.g., source flow 0) and one enhancement layer (e.g., source 309 flow 1), where each layer is carried in a separate flow. Repair flow 310 3 protects the combination of the base and enhancement layers for the 311 receivers who receive both layers, and repair flow 4 protects the 312 base layer only, for the receivers who want the base layer only, or 313 who receive both layers but prefer FEC protection for the base layer 314 only due to their bandwidth and/or processing limitations. 316 Using multiple FEC Framework instances for a single source flow 317 provides flexibility to the receivers. Different instances may use 318 larger or smaller source block sizes, which accommodate the receivers 319 that have looser and tighter latency requirements, respectively. 320 Different instances may also provide FEC protection at different 321 redundancy levels. This enables the receivers experiencing different 322 packet loss rates to choose the repair flows that are tailored to 323 their needs. 325 ____| FEC FRAMEWORK 326 / | INSTANCE 327 / | 3: Repair Flow 328 / 329 SOURCE FLOWS / | FEC FRAMEWORK 330 0: Source Flow |___/ |------| INSTANCE 331 __| 1: Source Flow | | 4: Repair Flow 332 | | 2: Source Flow 333 | | FEC FRAMEWORK 334 |__________________________| INSTANCE 335 | 5: Repair Flow 336 | 6: Repair Flow 337 | 7: Repair Flow 339 Figure 1: Example scenario with multiple FEC Framework instances 341 The 'group' attribute and the FEC grouping semantics defined in 342 [RFC4756] are used to associate source and repair flows together with 343 the following additional requirement: 345 In the case that the Explicit Source FEC Payload ID is used, then 346 only one FEC scheme MUST be used for this source flow, unless the 347 generic tag is used by all of the FEC schemes for the Source FEC 348 Payload ID, as defined in [I-D.ietf-fecframe-framework]. 350 The 'group' attribute MAY be used to group multiple repair flows with 351 one or more source flows. Note that [RFC3388] prohibits an "m" line 352 identified by its 'mid' attribute from appearing in more than one 353 "a=group:FEC" line. Thus, [RFC3388] mandates us to write 355 a=group:FEC 0 1 2 3 4 5 6 7 357 for the scenario sketched in Figure 1. This limitation prevents us 358 from indicating particular associations between the source and repair 359 flows by using an "a=group:FEC" line per FEC Framework instance 360 [RFC4756]. 362 Editor's note: The FEC grouping and flow association issues are 363 currently under discussion in FECFRAME and MMUSIC WGs. This section 364 will be updated once a decision is made. 366 The FEC Framework also supports additivity among the repair flows, 367 meaning that multiple repair flows MAY be decoded jointly to improve 368 the recovery chances of the missing packets. In addition, the sender 369 MAY assign different levels of priority to each repair flow. See 370 Section 4.5 for details. 372 4.3. Source IP Addresses 374 The 'source-filter' attribute of SDP ("a=source-filter") as defined 375 in [RFC4570] is used to express the source addresses or fully 376 qualified domain names in the FEC Framework. 378 Editor's note: Additional requirements or exceptions regarding 379 source filters are TBD. 381 4.4. Source Flows 383 The FEC Framework allows that multiple source flows MAY be grouped 384 and protected together by a single or multiple FEC Framework 385 instances. For this reason, as described in Section 3.3, individual 386 source flows MUST be identified with unique identifiers. For this 387 purpose, we introduce the attribute 'fec-source-flow'. 389 The syntax for the new attribute in ABNF [RFC5234] is as follows: 391 fec-source-flow-line = "a=fec-source-flow:" source-id 392 [";" SP tag-length] CRLF 394 source-id = "id=" src-id 395 src-id = 1*DIGIT 397 tag-length = "tag-len=" tlen 398 tlen = *DIGIT 400 The MANDATORY parameter 'id' is used to identify the source flow. 401 Note that the parameter 'id' MUST be an integer. 403 The OPTIONAL 'tag-len' parameter is used to specify the length of the 404 Explicit Source FEC Payload ID field (in bytes) and MUST be used 405 according to the requirements listed in Section 4.2. If no value is 406 specified for the 'tag-len' parameter, it indicates a value of zero. 408 4.5. Repair Flows 410 A repair flow MUST contain only repair packets formatted as described 411 in [I-D.ietf-fecframe-framework] for a single FEC Framework instance. 412 In other words, packets belonging to source flows or other repair 413 flows from a different FEC Framework instance MUST NOT be sent within 414 this flow. We introduce the attribute 'fec-repair-flow' to describe 415 the repair flows. 417 The syntax for the new attribute in ABNF is as follows: 419 fec-repair-flow-line = "a=fec-repair-flow:" fec-encoding-id 420 [";" SP flow-priority] [";" SP sender-side-scheme-specific] 421 [";" SP receiver-side-scheme-specific] CRLF 423 fec-encoding-id = "encoding-id=" enc-id 424 enc-id = 1*DIGIT ; FEC Encoding ID 426 flow-priority = "priority=" priority-of-the-flow 427 priority-of-the-flow = *DIGIT 429 sender-side-scheme-specific = "ss-fssi=" sender-info 430 sender-info = *CHAR 432 receiver-side-scheme-specific = "rs-fssi=" receiver-info 433 receiver-info = *CHAR 435 The MANDATORY parameter 'encoding-id' is used to identify the FEC 436 scheme used to generate this repair flow. These identifiers MUST be 437 registered with IANA by the FEC schemes that use the FEC Framework. 439 The OPTIONAL parameter 'priority' is used to indicate the priorities 440 of the repair flows. The exact usage of the parameter 'priority' and 441 the pertaining rules SHOULD be defined by the FEC scheme or the CDP. 442 If no value is specified for the parameter 'priority', it means that 443 the receiver(s) MAY receive and use the repair flows in any order. 444 However, if a priority is assigned to the repair flow(s), the 445 receivers MUST follow the specified order in receiving and using the 446 repair flow(s). 448 The OPTIONAL parameters 'ss-fssi' and 'rs-fssi' are opaque containers 449 to convey the FEC-Scheme-Specific Information (FSSI) that includes 450 the information that is specific to the FEC scheme used by the CDP 451 and is necessary for proper FEC encoding and decoding operations. 452 The FSSI required only by the sender (called Sender-Side FSSI) MUST 453 be communicated in the container specified by the parameter 'ss- 454 fssi'. Any other FSSI (called Receiver-Side FSSI) MUST be 455 communicated in the container specified by the parameter 'rs-fssi'. 456 In both containers, FSSI is transmitted in the form of an octet 457 string. The FEC schemes define the structure of this octet string, 458 which MAY contain multiple distinct elements. If the FEC scheme does 459 not require any specific information, the 'ss-fssi' and 'rs-fssi' 460 parameters MAY be null and ignored. 462 4.6. Repair Window 464 An FEC encoder processes a block of source packets and generates a 465 number of repair packets, which are then transmitted within a certain 466 duration. At the receiver side, the FEC decoder tries to decode all 467 the packets received within the repair window to recover the missing 468 packets, if there are any. Repair window stands for the time that 469 spans the source packets and the corresponding repair packets. 470 Assuming that there is no issue of delay variation, the FEC decoder 471 SHOULD NOT wait longer than the repair window since additional 472 waiting would not help the recovery process. 474 This document specifies a new attribute to describe the size of the 475 repair window in milliseconds and microseconds. 477 The syntax for the attribute in ABNF is as follows: 479 repair-window-line = "a=repair-window:" window-size 480 [SP unit] CRLF 482 window-size = 1*DIGIT 484 unit = ms / us 486 is the unit of time the repair window size is specified with. 487 Currently, two units are defined: "ms", which stands for 488 milliseconds and "us", which stands for microseconds. The default 489 unit is "ms". Alternative units MAY be defined in the future by 490 registering them with IANA. 492 The 'a=repair-window' attribute is a media-level attribute since each 493 repair flow MAY have a different repair window value. 495 4.7. Bandwidth Specification 497 The bandwidth specification as defined in [RFC4566] denotes the 498 proposed bandwidth to be used by the session or media. The 499 specification of bandwidth is OPTIONAL. 501 In the context of the FEC Framework, the bandwidth specification can 502 be used to express the bandwidth of the repair flows or the bandwidth 503 of the session. If included in the SDP, it SHALL adhere to the 504 following rules: 506 The session-level bandwidth for an FEC Framework instance MAY be 507 specified. In this case, it is RECOMMENDED to use the Transport 508 Independent Application Specific (TIAS) bandwidth modifier [RFC3890] 509 and the 'a=maxprate' attribute for the session. 511 The media-level bandwidth for the individual repair flows MAY also be 512 specified. In this case, it is RECOMMENDED to use the TIAS bandwidth 513 modifier [RFC3890]. 515 The Application Specific (AS) bandwidth modifier [RFC4566] MAY be 516 used instead of TIAS, however, this is NOT RECOMMENDED since TIAS 517 allows the calculation of the bitrate according to the IP version and 518 transport protocol, whereas AS does not. Thus, in TIAS-based bitrate 519 calculations, the packet size SHALL include all headers and payload, 520 excluding the IP and UDP headers. In AS-based bitrate calculations, 521 the packet size SHALL include all headers and payload, plus the IP 522 and UDP headers. 524 For the ABNF syntax information of the TIAS and AS, refer to 525 [RFC3890] and [RFC4566], respectively. 527 5. Scenarios and Examples 529 This section discusses the considerations for session announcement 530 and offer/answer models. SDP examples that can be used by the FEC 531 Framework are also provided. 533 5.1. Session Announcement Considerations 535 In multicast-based applications, the FEC Framework Configuration 536 Information pertaining to all FEC protection options available at the 537 sender MAY be advertised to the receivers as a part of a session 538 announcement. This way, the sender can let the receivers know all 539 available options for FEC protection. Based on their needs, the 540 receivers MAY choose protection provided by one or more FEC Framework 541 instances and subscribe to the respective multicast group(s) to 542 receive the repair flow(s). Unless explicitly required by the CDP, 543 the receivers SHOULD NOT send an answer back to the sender specifying 544 their choices. 546 5.2. Offer/Answer Considerations 548 In unicast-based applications, a sender and receiver MAY adopt the 549 offer/answer model [RFC3264] to set the FEC Framework Configuration 550 Information. In this case, the sender offers all available options 551 to the receiver and the receiver answers back to the sender with its 552 choice(s). Note that some FEC protection options MAY be offered to 553 only a particular set of (e.g., premium) receivers. 555 Receivers supporting the SDP Capability Negotiation Framework 556 [I-D.ietf-mmusic-sdp-capability-negotiation] MAY also use this 557 framework to negotiate all or a subset of the FEC Framework 558 parameters. 560 The backward compatibility in offer/answer model is handled as 561 specified in [RFC3388]. If a receiver receives an offer containing 562 FEC grouping and it does not understand the FEC grouping semantics, 563 it MAY respond with an answer that ignores the grouping attribute or 564 MAY refuse the request. In the first case, the offerer MUST 565 establish the connection without FEC. In the second case, if the 566 offerer still wishes to establish the session, it SHOULD retry the 567 request with an offer without FEC. 569 5.3. Examples 571 Editor's note: More examples showing the usage of multiple FEC 572 Framework instances, additivity of the repair flows and 573 prioritization of the repair flows will be provided once the issues 574 related to FEC grouping and flow association are resolved. 576 Editor's note: As of now, no FEC Encoding ID has been registered 577 with IANA. In the examples below, an FEC Encoding ID of zero and an 578 encoding (i.e., payload format) of 'parityfec' will be used for 579 illustrative purposes. Artificial content for the SS-FSSI and RS- 580 FSSI will also be provided. 582 [RFC3388] defines the media stream identification attribute ('mid') 583 as a token in ABNF. In contrast, the identifiers for the source 584 flows MUST be integers and SHOULD be allocated starting from zero and 585 increasing by one for each flow. To avoid any ambiguity, using the 586 same values for identifying the media streams and source flows is NOT 587 RECOMMENDED, even when 'mid' values are integers. 589 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme 591 SOURCE FLOWS | INSTANCE #1 592 0: Source Flow |---------| 1: Repair Flow 594 Figure 6: 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 S1 598 R1" line. The source and repair flows are sent to the same port on 599 different multicast groups. The repair window is set to 150 ms. 601 v=0 602 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 603 s=FEC Framework Examples 604 t=0 0 605 a=group:FEC S1 R1 606 m=video 30000 RTP/AVP 100 607 c=IN IP4 224.1.1.1/127 608 a=rtpmap:100 MP2T/90000 609 a=fec-source-flow: id=0 610 a=mid:S1 611 m=application 30000 RTP/AVP 110 612 c=IN IP4 224.1.2.1/127 613 a=rtpmap:110 1d-interleaved-parityfec/90000 614 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X 615 a=repair-window: 150 616 a=mid:R1 618 5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme 620 SOURCE FLOWS | INSTANCE #1 621 0: Source Flow |_________| 2: Repair Flow 622 1: Source Flow | 624 Figure 8: 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 S1 S2 R1" line. The source 629 and repair flows are sent to the same port on different multicast 630 groups. The repair window is set to 150500 us. 632 v=0 633 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 634 s=FEC Framework Examples 635 t=0 0 636 a=group:FEC S1 S2 R1 637 m=video 30000 RTP/AVP 100 638 c=IN IP4 224.1.1.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 224.1.1.2/127 644 a=rtpmap:101 MP2T/90000 645 a=fec-source-flow: id=1 646 a=mid:S2 647 m=application 30000 RTP/AVP 110 648 c=IN IP4 224.1.2.1/127 649 a=rtpmap:110 1d-interleaved-parityfec/90000 650 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X 651 a=repair-window: 150500 us 652 a=mid:R1 654 5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 656 SOURCE FLOWS | INSTANCE #1 657 0: Source Flow |---------| 2: Repair Flow 658 1: Source Flow |_ 659 \-------| INSTANCE #2 660 | 3: Repair Flow 662 Figure 10: Scenario #3 664 In this example, we have two source video flows (mid:S1 and mid:S2) 665 and two FEC repair flows (mid:R1 and mid:R2). The source flows 666 mid:S1 and mid:S2 are protected by the repair flows mid:R1 and 667 mid:R2, respectively. We form two FEC groups with the "a=group:FEC 668 S1 R1" and "a=group:FEC S2 R2" lines. The source and repair flows 669 are sent to the same port on different multicast groups. The repair 670 window is set to 200 ms and 400 ms for the first and second FEC 671 group, respectively. 673 v=0 674 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 675 s=FEC Framework Examples 676 t=0 0 677 a=group:FEC S1 R1 678 a=group:FEC S2 R2 679 m=video 30000 RTP/AVP 100 680 c=IN IP4 224.1.1.1/127 681 a=rtpmap:100 MP2T/90000 682 a=fec-source-flow: id=0 683 a=mid:S1 684 m=video 30000 RTP/AVP 101 685 c=IN IP4 224.1.1.2/127 686 a=rtpmap:101 MP2T/90000 687 a=fec-source-flow: id=1 688 a=mid:S2 689 m=application 30000 RTP/AVP 110 690 c=IN IP4 224.1.2.1/127 691 a=rtpmap:110 1d-interleaved-parityfec/90000 692 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X 693 a=repair-window: 200 ms 694 a=mid:R1 695 m=application 30000 RTP/AVP 111 696 c=IN IP4 224.1.2.2/127 697 a=rtpmap:111 1d-interleaved-parityfec/90000 698 a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; rs-fssi=456WSX 699 a=repair-window: 400 ms 700 a=mid:R2 702 6. Security Considerations 704 For the general security considerations related to SDP, refer to 705 [RFC4566]. For the security considerations related to source/FEC 706 media stream grouping in SDP and use of source address filters in 707 SDP, refer to [RFC4756] and [RFC4570], respectively. 709 7. IANA Considerations 711 7.1. Transport Protocols 713 The 'proto' sub-field of the media description line ("m=") describes 714 the transport protocol used. This document registers the following 715 values: 717 UDP/FEC 719 Editor's note: Additional transport protocols to be registered are 720 TBD. 722 7.2. Attribute Names 724 As recommended by [RFC4566], the following attribute names should be 725 registered with IANA. 727 The contact information for the registrations is: 729 Ali Begen 730 abegen@cisco.com 732 SDP Attribute ("att-field"): 733 Attribute name: fec-source-flow 734 Long form: Pointer to FEC Source Flow 735 Type of name: att-field 736 Type of attribute: Media level 737 Subject to charset: No 738 Purpose: See this document 739 Reference: This document 740 Values: See this document 742 SDP Attribute ("att-field"): 743 Attribute name: fec-repair-flow 744 Long form: Pointer to FEC Repair Flow 745 Type of name: att-field 746 Type of attribute: Media level 747 Subject to charset: No 748 Purpose: See this document 749 Reference: This document 750 Values: See this document 752 SDP Attribute ("att-field"): 753 Attribute name: repair-window 754 Long form: Repair Window Size 755 Type of name: att-field 756 Type of attribute: Media level 757 Subject to charset: No 758 Purpose: See this document 759 Reference: This document 760 Values: See this document 762 8. Acknowledgments 764 The author would like to thank the FEC Framework Design Team for 765 their inputs, suggestions and contributions. 767 9. Change Log 769 9.1. draft-ietf-fecframe-sdp-elements-01 771 The following are the major changes compared to version 00: 773 o Additive repair flows can now be from different instances. The 774 sender may also assign different levels of priorities to each 775 repair flow regardless of whether the repair flows are additive or 776 not. 778 o SDP examples are fixed. 780 o Comments posted in the mailing list are incorporated. 782 9.2. draft-ietf-fecframe-sdp-elements-00 784 This is the initial version, which is based on an earlier individual 785 submission. The following are the major changes compared to that 786 document: 788 o The opaque container in the FEC Framework Configuration 789 Information (FEC-Scheme-Specific Information) is now divided into 790 two parts: information needed only by the sender and information 791 needed by the receiver. The repair flow descriptors are also 792 updated accordingly. 794 o "Minimum Buffer Size" is now called "Repair Window." Its size can 795 also be specified in microseconds in addition to milliseconds. 797 o Simple examples with complete SDPs are included. 799 o "Scheme ID" is changed to "Encoding ID" to be consistent with the 800 framework draft. 802 o Some other editorial changes. 804 10. References 805 10.1. Normative References 807 [I-D.ietf-fecframe-framework] 808 Watson, M., "Forward Error Correction (FEC) Framework", 809 draft-ietf-fecframe-framework-02 (work in progress), 810 July 2008. 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, March 1997. 815 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 816 Description Protocol", RFC 4566, July 2006. 818 [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol 819 (SDP) Source Filters", RFC 4570, July 2006. 821 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 822 Session Description Protocol", RFC 4756, November 2006. 824 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 825 Schulzrinne, "Grouping of Media Lines in the Session 826 Description Protocol (SDP)", RFC 3388, December 2002. 828 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 829 Modifier for the Session Description Protocol (SDP)", 830 RFC 3890, September 2004. 832 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 833 Specifications: ABNF", STD 68, RFC 5234, January 2008. 835 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 836 with Session Description Protocol (SDP)", RFC 3264, 837 June 2002. 839 [I-D.ietf-fecframe-config-signaling] 840 Asati, R., "Signaling Protocol to convey FEC Framework 841 Configuration Information", 842 draft-ietf-fecframe-config-signaling-00 (work in 843 progress), July 2008. 845 [I-D.ietf-mmusic-sdp-capability-negotiation] 846 Andreasen, F., "SDP Capability Negotiation", 847 draft-ietf-mmusic-sdp-capability-negotiation-08 (work in 848 progress), December 2007. 850 10.2. Informative References 852 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 853 Correction (FEC) Building Block", RFC 5052, August 2007. 855 Author's Address 857 Ali Begen 858 Cisco Systems 859 170 West Tasman Drive 860 San Jose, CA 95134 861 USA 863 Email: abegen@cisco.com 865 Full Copyright Statement 867 Copyright (C) The IETF Trust (2008). 869 This document is subject to the rights, licenses and restrictions 870 contained in BCP 78, and except as set forth therein, the authors 871 retain all their rights. 873 This document and the information contained herein are provided on an 874 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 875 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 876 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 877 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 878 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 879 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 881 Intellectual Property 883 The IETF takes no position regarding the validity or scope of any 884 Intellectual Property Rights or other rights that might be claimed to 885 pertain to the implementation or use of the technology described in 886 this document or the extent to which any license under such rights 887 might or might not be available; nor does it represent that it has 888 made any independent effort to identify any such rights. Information 889 on the procedures with respect to rights in RFC documents can be 890 found in BCP 78 and BCP 79. 892 Copies of IPR disclosures made to the IETF Secretariat and any 893 assurances of licenses to be made available, or the result of an 894 attempt made to obtain a general license or permission for the use of 895 such proprietary rights by implementers or users of this 896 specification can be obtained from the IETF on-line IPR repository at 897 http://www.ietf.org/ipr. 899 The IETF invites any interested party to bring to its attention any 900 copyrights, patents or patent applications, or other proprietary 901 rights that may cover technology that may be required to implement 902 this standard. Please address the information to the IETF at 903 ietf-ipr@ietf.org. 905 Acknowledgment 907 Funding for the RFC Editor function is provided by the IETF 908 Administrative Support Activity (IASA).