idnits 2.17.1 draft-ietf-fecframe-sdp-elements-11.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 (October 21, 2010) is 4934 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 706, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-10 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-09) exists of draft-ietf-fecframe-config-signaling-03 Summary: 1 error (**), 0 flaws (~~), 5 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 October 21, 2010 5 Expires: April 24, 2011 7 Session Description Protocol Elements for FEC Framework 8 draft-ietf-fecframe-sdp-elements-11 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 April 24, 2011. 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 . . . . . . . . . 5 72 4. SDP Elements . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6 74 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7 75 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 7 76 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 10 79 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 11 80 5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 11 81 5.1. Declarative Considerations . . . . . . . . . . . . . . . . 11 82 5.2. Offer/Answer Model Considerations . . . . . . . . . . . . 12 83 6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.1. One Source Flow, One Repair Flow and One FEC Scheme . . . 12 85 6.2. Two Source Flows, One Repair Flow and One FEC Scheme . . . 13 86 6.3. Two Source Flows, Two Repair Flows and Two FEC Schemes . . 14 87 6.4. One Source Flow, Two Repair Flows and Two FEC Schemes . . 15 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 8.1. Registration of Transport Protocols . . . . . . . . . . . 16 91 8.2. Registration of SDP Attributes . . . . . . . . . . . . . . 17 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 The Forward Error Correction (FEC) Framework, described in 102 [I-D.ietf-fecframe-framework], outlines a general framework for using 103 FEC-based error recovery in packet flows carrying media content. 104 While a continuous signaling between the sender(s) and receiver(s) is 105 not required for a Content Delivery Protocol (CDP) that uses the FEC 106 Framework, a set of parameters pertaining to the FEC Framework has to 107 be initially communicated between the sender(s) and receiver(s). A 108 signaling protocol (such as the one described in 109 [I-D.ietf-fecframe-config-signaling]) is required to enable such 110 communication and the parameters need to be appropriately encoded so 111 that they can be carried by the signaling protocol. 113 One format to encode the parameters is the Session Description 114 Protocol (SDP) [RFC4566]. SDP provides a simple text-based format 115 for announcements and invitations to describe multimedia sessions. 116 These SDP announcements and invitations include sufficient 117 information for the sender(s) and receiver(s) to participate in the 118 multimedia sessions. SDP also provides a framework for capability 119 negotiation, which can be used to negotiate all or a subset of the 120 parameters pertaining to the individual sessions. 122 The purpose of this document is to introduce the SDP elements that 123 are used by the CDPs using the FEC Framework that choose SDP 124 [RFC4566] as their session description protocol. 126 2. Requirements Notation 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 3. Forward Error Correction (FEC) and FEC Framework 134 This section gives a brief overview of FEC and the FEC Framework. 136 3.1. Forward Error Correction (FEC) 138 Any application that needs a reliable transmission over an unreliable 139 packet network has to cope with packet losses. FEC is an effective 140 approach that provides reliable transmission particularly in 141 multicast and broadcast applications where the feedback from the 142 receiver(s) is either not available or quite limited. 144 In a nutshell, FEC groups source packets into blocks and applies 145 protection to generate a desired number of repair packets. These 146 repair packets can be sent on demand or independently of any receiver 147 feedback. The choice depends on the FEC scheme or the Content 148 Delivery Protocol used by the application, the packet loss 149 characteristics of the underlying network, the transport scheme 150 (e.g., unicast, multicast and broadcast) and the application. At the 151 receiver side, lost packets can be recovered by erasure decoding 152 provided that a sufficient number of source and repair packets have 153 been received. 155 3.2. FEC Framework 157 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 158 framework for using FEC codes in multimedia applications that stream 159 audio, video or other types of multimedia content. It defines the 160 common components and aspects of Content Delivery Protocols (CDP). 161 The FEC Framework also defines the requirements for the FEC schemes 162 that need to be used within a CDP. However, the details of the FEC 163 schemes are not specified within the FEC Framework. For example, the 164 FEC Framework defines what configuration information has to be known 165 at the sender and receiver(s) at minimum, but the FEC Framework 166 neither specifies how the FEC repair packets are generated and used 167 to recover missing source packets, nor dictates how the configuration 168 information is communicated between the sender and receiver(s). 169 These are rather specified by the individual FEC schemes or CDPs. 171 3.3. FEC Framework Configuration Information 173 The FEC Framework [I-D.ietf-fecframe-framework] defines a minimum set 174 of information that has to be communicated between the sender and 175 receiver(s) for a proper operation of an FEC scheme. This 176 information is called the FEC Framework Configuration Information. 177 This information includes unique identifiers for the source and 178 repair flows that carry the source and repair packets, respectively. 179 It also specifies how the sender applies protection to the source 180 flow(s) and how the repair flow(s) can be used to recover lost data. 182 Multiple instances of the FEC Framework can simultaneously exist at 183 the sender and the receiver(s) for different source flows, for the 184 same source flow, or for various combinations of the source flows. 185 Each instance of the FEC Framework provides the following FEC 186 Framework Configuration Information: 188 1. Identification of the repair flows. 190 2. For each source flow protected by the repair flow(s): 192 a. Definition of the source flow. 194 b. An integer identifier for this flow definition (i.e., tuple). 195 This identifier MUST be unique amongst all source flows that are 196 protected by the same FEC repair flow. The identifiers SHOULD be 197 allocated starting from zero and increasing by one for each flow. 198 A source flow identifier need not be carried in source packets 199 since source packets are directly associated with a flow by virtue 200 of their packet headers. 202 3. The FEC Encoding ID, identifying the FEC scheme. 204 4. The length of the Explicit Source FEC Payload ID (in octets). 206 5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, each 207 consisting of a name and a value where the valid element names and 208 value ranges are defined by the FEC scheme. 210 FSSI includes the information that is specific to the FEC scheme used 211 by the CDP. FSSI is used to communicate the information that cannot 212 be adequately represented otherwise and is essential for proper FEC 213 encoding and decoding operations. The motivation behind separating 214 the FSSI required only by the sender (which is carried in Sender-Side 215 FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of 216 the FSSI is to provide the receiver or the third party entities a 217 means of controlling the FEC operations at the sender. Any FSSI 218 other than the one solely required by the sender MUST be communicated 219 via the FSSI container. 221 The variable-length SS-FSSI and FSSI containers transmit the 222 information in textual representation and contain zero or more 223 distinct elements, whose descriptions are provided by the fully- 224 specified FEC schemes. 226 4. SDP Elements 228 This section defines the SDP elements that MUST be used to describe 229 the FEC Framework Configuration Information in multimedia sessions by 230 the CDPs that choose SDP [RFC4566] as their session description 231 protocol. Example SDP descriptions can be found in Section 6. 233 4.1. Transport Protocol Identifiers 235 This specification defines a new transport protocol identifier for 236 the FEC schemes that take a UDP-formatted input stream and append an 237 Explicit Source FEC Payload ID as described in Section 5.3 of 238 [I-D.ietf-fecframe-framework] to generate a source flow. This new 239 protocol identifier is 'FEC/UDP'. To use input streams that are 240 formatted according to another (as listed in the table for 241 the 'proto' field in the Session Description Protocol (SDP) 242 Parameters registry), the corresponding 'FEC/' transport 243 protocol identifier MUST be registered with IANA by following the 244 instructions specified in [RFC4566]. 246 Note that if an FEC scheme does not use the Explicit Source FEC 247 Payload ID as described in Section 4.1 of 248 [I-D.ietf-fecframe-framework], then the original transport protocol 249 identifier MUST be used to support backward compatibility with the 250 receivers that do not support FEC at all. 252 This specification also defines another transport protocol 253 identifier, 'UDP/FEC', to indicate the FEC Repair Packet format 254 defined in Section 5.4 of [I-D.ietf-fecframe-framework]. For 255 detailed registration information, refer to Section 8.1. 257 4.2. Media Stream Grouping 259 In FEC Framework, the 'group' attribute and the FEC grouping 260 semantics defined in [RFC5888] and [RFC5956], respectively are used 261 to associate source and repair flows together. 263 4.3. Source IP Addresses 265 The 'source-filter' attribute of SDP ("a=source-filter") as defined 266 in [RFC4570] is used to express the source addresses or fully 267 qualified domain names in the FEC Framework. 269 4.4. Source Flows 271 The FEC Framework allows that multiple source flows MAY be grouped 272 and protected together by a single or multiple FEC Framework 273 instances. For this reason, as described in Section 3.3, individual 274 source flows MUST be identified with unique identifiers. For this 275 purpose, we introduce the attribute 'fec-source-flow'. 277 The syntax for the new attribute in ABNF [RFC5234] is as follows: 279 fec-source-flow-line = "a=fec-source-flow:" SP source-id 280 [";" SP tag-length] CRLF 282 source-id = "id=" src-id 283 src-id = 1*DIGIT ; Represented as 32-bit non-negative 284 ; integers and leading zeros are ignored 286 tag-length = "tag-len=" tlen 287 tlen = %x31-39 *DIGIT 289 The REQUIRED parameter 'id' is used to identify the source flow. 290 Parameter 'id' MUST be an integer. 292 The 'tag-len' parameter is used to specify the length of the Explicit 293 Source FEC Payload ID field (in octets). In the case that an 294 Explicit Source FEC Payload ID is used, the 'tag-len' parameter MUST 295 exist and indicate its length. Otherwise, the 'tag-len' parameter 296 MUST NOT exist. 298 4.5. Repair Flows 300 A repair flow MUST contain only repair packets formatted as described 301 in [I-D.ietf-fecframe-framework] for a single FEC Framework instance, 302 i.e., packets belonging to source flows or other repair flows from a 303 different FEC Framework instance cannot be sent within this flow. We 304 introduce the attribute 'fec-repair-flow' to describe the repair 305 flows. 307 The syntax for the new attribute in ABNF is as follows (CHAR and CTL 308 are defined in [RFC5234]): 310 fec-repair-flow-line = "a=fec-repair-flow:" SP fec-encoding-id 311 [";" SP flow-preference] 312 [";" SP sender-side-scheme-specific] 313 [";" SP scheme-specific] CRLF 315 fec-encoding-id = "encoding-id=" enc-id 316 enc-id = 1*DIGIT ; FEC Encoding ID 318 flow-preference = "preference-lvl=" preference-level-of-the-flow 319 preference-level-of-the-flow = 1*DIGIT 321 sender-side-scheme-specific = "ss-fssi=" sender-info 322 sender-info = element *( "," element ) 323 element = name ":" value 324 name = token 325 token = 1* 326 value = * 327 separator = "(" / ")" / "<" / ">" / "@" 328 / "," / ";" / ":" / "\" / DQUOTE 329 / "/" / "[" / "]" / "?" / "=" 330 / "{" / "}" / SP / HTAB 332 scheme-specific = "fssi=" scheme-info 333 scheme-info = element *( "," element ) 335 The REQUIRED parameter 'encoding-id' is used to identify the FEC 336 scheme used to generate this repair flow. These identifiers (in the 337 range of [0 - 255]) are registered by the FEC schemes that use the 338 FEC Framework and are maintained by IANA. 340 The OPTIONAL parameter 'preference-lvl' is used to indicate the 341 preferred order of using the repair flows. The exact usage of the 342 parameter 'preference-lvl' and the pertaining rules MAY be defined by 343 the FEC scheme or the CDP. If the parameter 'preference-lvl' does 344 not exist, it means that the receiver(s) MAY receive and use the 345 repair flows in any order. However, if a preference level is 346 assigned to the repair flow(s), the receivers are encouraged to 347 follow the specified order in receiving and using the repair flow(s). 349 The OPTIONAL parameters 'ss-fssi' and 'fssi' are containers to convey 350 the FEC-Scheme-Specific Information (FSSI) that includes the 351 information that is specific to the FEC scheme used by the CDP and is 352 necessary for proper FEC encoding and decoding operations. The FSSI 353 required only by the sender (called Sender-Side FSSI) MUST be 354 communicated in the container specified by the parameter 'ss-fssi'. 355 Any other FSSI MUST be communicated in the container specified by the 356 parameter 'fssi'. In both containers, FSSI is transmitted in the 357 form of textual representation and MAY contain multiple distinct 358 elements. If the FEC scheme does not require any specific 359 information, the 'ss-fssi' and 'fssi' parameters MUST NOT exist. 361 4.6. Repair Window 363 Repair window is the time that spans an FEC block, which consists of 364 the source block and the corresponding repair packets. 366 At the sender side, the FEC encoder processes a block of source 367 packets and generates a number of repair packets. Then both the 368 source and repair packets are transmitted within a certain duration 369 not larger than the value of the repair window. The value of the 370 repair window impacts the maximum number of source packets that can 371 be included in an FEC block. 373 At the receiver side, the FEC decoder should wait at least for the 374 duration of the repair window after getting the first packet in an 375 FEC block to allow all the repair packets to arrive (The waiting time 376 can be adjusted if there are missing packets at the beginning of the 377 FEC block). The FEC decoder can start decoding the already received 378 packets sooner, however, it SHOULD NOT register an FEC decoding 379 failure until it waits at least for the repair-window duration. 381 This document specifies a new attribute to describe the size of the 382 repair window in milliseconds and microseconds. 384 The syntax for the attribute in ABNF is as follows: 386 repair-window-line = "a=repair-window:" window-size unit CRLF 388 window-size = %x31-39 *DIGIT ; Represented as 389 ; 32-bit non-negative integers 391 unit = "ms" / "us" 393 is the unit of time the repair window size is specified with. 394 Two units are defined here: 'ms', which stands for milliseconds and 395 'us', which stands for microseconds. 397 The 'a=repair-window' attribute is a media-level attribute since each 398 repair flow MAY have a different repair window size. 400 Specifying the repair window size in an absolute time value does not 401 necessarily correspond to an integer number of packets or exactly 402 match with the clock rate used in RTP (in case of RTP transport) 403 causing mismatches among subsequent repair windows. However, in 404 practice, this mismatch does not break anything in the FEC decoding 405 process. 407 4.7. Bandwidth Specification 409 The bandwidth specification as defined in [RFC4566] denotes the 410 proposed bandwidth to be used by the session or media. The 411 specification of bandwidth is OPTIONAL. 413 In the context of the FEC Framework, the bandwidth specification can 414 be used to express the bandwidth of the repair flows or the bandwidth 415 of the session. If included in the SDP, it SHALL adhere to the 416 following rules: 418 The session-level bandwidth for an FEC Framework instance or the 419 media-level bandwidth for the individual repair flows MAY be 420 specified. In this case, it is RECOMMENDED to use the Transport 421 Independent Application Specific (TIAS) bandwidth modifier [RFC3890] 422 and the 'a=maxprate' attribute unless the Application Specific (AS) 423 bandwidth modifier [RFC4566] is used. The use of AS bandwidth 424 modifier is NOT RECOMMENDED since TIAS allows the calculation of the 425 bitrate according to the IP version and transport protocol, whereas 426 AS does not. Thus, in TIAS-based bitrate calculations, the packet 427 size SHALL include all headers and payload, excluding the IP and UDP 428 headers. In AS-based bitrate calculations, the packet size SHALL 429 include all headers and payload, plus the IP and UDP headers. 431 For the ABNF syntax information of the TIAS and AS, refer to 432 [RFC3890] and [RFC4566], respectively. 434 5. Scenarios and Examples 436 This section discusses the considerations for Session Announcement 437 and Offer/Answer Models. 439 5.1. Declarative Considerations 441 In multicast-based applications, the FEC Framework Configuration 442 Information pertaining to all FEC protection options available at the 443 sender MAY be advertised to the receivers as a part of a session 444 announcement. This way, the sender can let the receivers know all 445 available options for FEC protection. Based on their needs, the 446 receivers MAY choose protection provided by one or more FEC Framework 447 instances and subscribe to the respective multicast session(s) to 448 receive the repair flow(s). Unless explicitly required by the CDP, 449 the receivers SHOULD NOT send an answer back to the sender specifying 450 their choices since this can easily overwhelm the sender particularly 451 in large-scale multicast applications. 453 5.2. Offer/Answer Model Considerations 455 In unicast-based applications, a sender and receiver MAY adopt the 456 Offer/Answer Model [RFC3264] to set the FEC Framework Configuration 457 Information. In this case, the sender offers the options available 458 to this particular receiver and the receiver answers back to the 459 sender with its choice(s). 461 Receivers supporting the SDP Capability Negotiation Framework 462 [RFC5939] MAY also use this framework to negotiate all or a subset of 463 the FEC Framework parameters. 465 The backward compatibility in Offer/Answer Model is handled as 466 specified in [RFC5956]. 468 6. SDP Examples 470 This section provides SDP examples that can be used by the FEC 471 Framework. 473 [RFC5888] defines the media stream identification attribute ('mid') 474 as a token in ABNF. In contrast, the identifiers for the source 475 flows MUST be integers and SHOULD be allocated starting from zero and 476 increasing by one for each flow. To avoid any ambiguity, using the 477 same values for identifying the media streams and source flows is NOT 478 RECOMMENDED, even when 'mid' values are integers. 480 In the examples below, random FEC Encoding IDs will be used for 481 illustrative purposes. Artificial content for the SS-FSSI and FSSI 482 will also be provided. 484 6.1. One Source Flow, One Repair Flow and One FEC Scheme 486 SOURCE FLOWS | INSTANCE #1 487 S1: Source Flow |--------| R1: Repair Flow 488 | 490 Figure 1: Scenario #1 492 In this example, we have one source video flow (mid:S1) and one FEC 493 repair flow (mid:R1). We form one FEC group with the "a=group:FEC-FR 494 S1 R1" line. The source and repair flows are sent to the same port 495 on different multicast groups. The repair window is set to 150 ms. 497 v=0 498 o=ali 1122334455 1122334466 IN IP4 fec.example.com 499 s=FEC Framework Examples 500 t=0 0 501 a=group:FEC-FR S1 R1 502 m=video 30000 RTP/AVP 100 503 c=IN IP4 233.252.0.1/127 504 a=rtpmap:100 MP2T/90000 505 a=fec-source-flow: id=0 506 a=mid:S1 507 m=application 30000 UDP/FEC 508 c=IN IP4 233.252.0.2/127 509 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 510 a=repair-window:150ms 511 a=mid:R1 513 6.2. Two Source Flows, One Repair Flow and One FEC Scheme 515 SOURCE FLOWS 516 S2: Source Flow | | INSTANCE #1 517 |---------| R2: Repair Flow 518 S3: Source Flow | 520 Figure 2: Scenario #2 522 In this example, we have two source video flows (mid:S2 and mid:S3) 523 and one FEC repair flow (mid:R2), protecting both source flows. We 524 form one FEC group with the "a=group:FEC-FR S2 S3 R2" line. The 525 source and repair flows are sent to the same port on different 526 multicast groups. The repair window is set to 150500 us. 528 v=0 529 o=ali 1122334455 1122334466 IN IP4 fec.example.com 530 s=FEC Framework Examples 531 t=0 0 532 a=group:FEC-FR S2 S3 R2 533 m=video 30000 RTP/AVP 100 534 c=IN IP4 233.252.0.1/127 535 a=rtpmap:100 MP2T/90000 536 a=fec-source-flow: id=0 537 a=mid:S2 538 m=video 30000 RTP/AVP 101 539 c=IN IP4 233.252.0.2/127 540 a=rtpmap:101 MP2T/90000 541 a=fec-source-flow: id=1 542 a=mid:S3 543 m=application 30000 UDP/FEC 544 c=IN IP4 233.252.0.3/127 545 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 546 a=repair-window:150500us 547 a=mid:R2 549 6.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 551 SOURCE FLOWS | INSTANCE #1 552 S4: Source Flow |--------| R3: Repair Flow 554 S5: Source Flow |--------| INSTANCE #2 555 | R4: Repair Flow 557 Figure 3: Scenario #3 559 In this example, we have two source video flows (mid:S4 and mid:S5) 560 and two FEC repair flows (mid:R3 and mid:R4). The source flows 561 mid:S4 and mid:S5 are protected by the repair flows mid:R3 and 562 mid:R4, respectively. We form two FEC groups with the "a=group: 563 FEC-FR S4 R3" and "a=group:FEC-FR S5 R4" lines. The source and 564 repair flows are sent to the same port on different multicast groups. 565 The repair window is set to 200 ms and 400 ms for the first and 566 second FEC group, respectively. 568 v=0 569 o=ali 1122334455 1122334466 IN IP4 fec.example.com 570 s=FEC Framework Examples 571 t=0 0 572 a=group:FEC-FR S4 R3 573 a=group:FEC-FR S5 R4 574 m=video 30000 RTP/AVP 100 575 c=IN IP4 233.252.0.1/127 576 a=rtpmap:100 MP2T/90000 577 a=fec-source-flow: id=0 578 a=mid:S4 579 m=video 30000 RTP/AVP 101 580 c=IN IP4 233.252.0.2/127 581 a=rtpmap:101 MP2T/90000 582 a=fec-source-flow: id=1 583 a=mid:S5 584 m=application 30000 UDP/FEC 585 c=IN IP4 233.252.0.3/127 586 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 587 a=repair-window:200ms 588 a=mid:R3 589 m=application 30000 UDP/FEC 590 c=IN IP4 233.252.0.4/127 591 a=fec-repair-flow: encoding-id=0; ss-fssi=n:14,k:10 592 a=repair-window:400ms 593 a=mid:R4 595 6.4. One Source Flow, Two Repair Flows and Two FEC Schemes 597 SOURCE FLOWS | INSTANCE #1 598 S6: Source Flow |--------| R5: Repair Flow 599 | 600 |--------| INSTANCE #2 601 | R6: Repair Flow 603 Figure 4: Scenario #4 605 In this example, we have one source video flow (mid:S6) and two FEC 606 repair flows (mid:R5 and mid:R6) with different preference levels. 607 The source flow mid:S6 is protected by both of the repair flows. We 608 form two FEC groups with the "a=group:FEC-FR S6 R5" and "a=group: 609 FEC-FR S6 R6" lines. The source and repair flows are sent to the 610 same port on different multicast groups. The repair window is set to 611 200 ms for both FEC groups. 613 v=0 614 o=ali 1122334455 1122334466 IN IP4 fec.example.com 615 s=FEC Framework Examples 616 t=0 0 617 a=group:FEC-FR S6 R5 618 a=group:FEC-FR S6 R6 619 m=video 30000 RTP/AVP 100 620 c=IN IP4 233.252.0.1/127 621 a=rtpmap:100 MP2T/90000 622 a=fec-source-flow: id=0 623 a=mid:S6 624 m=application 30000 UDP/FEC 625 c=IN IP4 233.252.0.3/127 626 a=fec-repair-flow: encoding-id=0; preference-lvl=0; ss-fssi=n:7,k:5 627 a=repair-window:200ms 628 a=mid:R5 629 m=application 30000 UDP/FEC 630 c=IN IP4 233.252.0.4/127 631 a=fec-repair-flow: encoding-id=1; preference-lvl=1; ss-fssi=t:3 632 a=repair-window:200ms 633 a=mid:R6 635 7. Security Considerations 637 There is a weak threat if the SDP is modified in a way that it shows 638 incorrect association and/or grouping of the source and repair flows. 639 Such attacks can result in failure of FEC protection and/or 640 mishandling of other media streams. It is RECOMMENDED that the 641 receiver does integrity check on SDP to only trust SDP from trusted 642 sources. The receiver MUST also follow the security considerations 643 of SDP [RFC4566]. For other general security considerations related 644 to SDP, refer to [RFC4566]. For the security considerations related 645 to the use of source address filters in SDP, refer to [RFC4570]. 647 The security considerations for the FEC Framework also apply. Refer 648 to [I-D.ietf-fecframe-framework] for details. 650 8. IANA Considerations 652 Note to the RFC Editor: In the following, please replace "XXXX" with 653 the number of this document prior to publication as an RFC. 655 8.1. Registration of Transport Protocols 657 This specification updates the Session Description Protocol (SDP) 658 Parameters registry as defined in Section 8.2.2 of [RFC4566]. 660 Specifically, it adds the following values to the table for the 661 'proto' field. 663 Type SDP Name Reference 664 ------ ---------- ----------- 665 proto FEC/UDP [RFCXXXX] 666 proto UDP/FEC [RFCXXXX] 668 This specification also defines a class of new transport protocol 669 identifiers. For all existing identifiers (listed in the 670 table for the 'proto' field in the Session Description Protocol (SDP) 671 Parameters registry), this specification defines the identifier 'FEC/ 672 '. 674 8.2. Registration of SDP Attributes 676 This document registers new attribute names in SDP. 678 SDP Attribute ("att-field"): 679 Attribute name: fec-source-flow 680 Long form: Pointer to FEC Source Flow 681 Type of name: att-field 682 Type of attribute: Media level 683 Subject to charset: No 684 Purpose: Provide parameters for an FEC source flow 685 Reference: [RFCXXXX] 686 Values: See [RFCXXXX] 688 SDP Attribute ("att-field"): 689 Attribute name: fec-repair-flow 690 Long form: Pointer to FEC Repair Flow 691 Type of name: att-field 692 Type of attribute: Media level 693 Subject to charset: No 694 Purpose: Provide parameters for an FEC repair flow 695 Reference: [RFCXXXX] 696 Values: See [RFCXXXX] 698 SDP Attribute ("att-field"): 699 Attribute name: repair-window 700 Long form: Pointer to FEC Repair Window 701 Type of name: att-field 702 Type of attribute: Media level 703 Subject to charset: No 704 Purpose: Indicate the size of the repair window 705 Reference: [RFCXXXX] 706 Values: See [RFCXXXX] 708 9. Acknowledgments 710 The author would like to thank the FEC Framework Design Team for 711 their inputs, suggestions and contributions. 713 10. References 715 10.1. Normative References 717 [I-D.ietf-fecframe-framework] 718 Watson, M., "Forward Error Correction (FEC) Framework", 719 draft-ietf-fecframe-framework-10 (work in progress), 720 September 2010. 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 726 Description Protocol", RFC 4566, July 2006. 728 [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol 729 (SDP) Source Filters", RFC 4570, July 2006. 731 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 732 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 734 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 735 the Session Description Protocol", RFC 5956, 736 September 2010. 738 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 739 Modifier for the Session Description Protocol (SDP)", 740 RFC 3890, September 2004. 742 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 743 Specifications: ABNF", STD 68, RFC 5234, January 2008. 745 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 746 with Session Description Protocol (SDP)", RFC 3264, 747 June 2002. 749 10.2. Informative References 751 [I-D.ietf-fecframe-config-signaling] 752 Asati, R., "Methods to convey FEC Framework Configuration 753 Information", draft-ietf-fecframe-config-signaling-03 754 (work in progress), June 2010. 756 [RFC5939] Andreasen, F., "Session Description Protocol (SDP) 757 Capability Negotiation", RFC 5939, September 2010. 759 Author's Address 761 Ali Begen 762 Cisco 763 181 Bay Street 764 Toronto, ON M5J 2T3 765 Canada 767 Email: abegen@cisco.com