idnits 2.17.1 draft-ietf-fecframe-pseudo-cdp-05.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 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 17, 2012) is 4180 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework U. Kozat 3 Internet-Draft DoCoMo USA Labs 4 Intended status: Informational A. Begen 5 Expires: April 20, 2013 Cisco 6 October 17, 2012 8 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source 9 Flows in FEC Framework 10 draft-ietf-fecframe-pseudo-cdp-05 12 Abstract 14 This document provides a pseudo Content Delivery Protocol (CDP) to 15 protect multiple source flows with one or more repair flows based on 16 the FEC Framework and the Session Description Protocol (SDP) elements 17 defined for the framework. The purpose of the document is not to 18 provide a full-fledged protocol, but to show how the defined 19 framework and SDP elements can be combined together to implement a 20 CDP. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 20, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 4 70 3. Construction of a Repair Flow from Multiple Source Flows . . . 4 71 3.1. Example: Two Source Flows Protected by a Single Repair 72 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Reconstruction of Source Flows from Repair Flow(s) . . . . . . 11 74 4.1. Example: Multiple Source Flows Protected by a Single 75 Repair Flow . . . . . . . . . . . . . . . . . . . . . . . 11 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The Forward Error Correction (FEC) Framework (described in [RFC6363]) 85 and SDP Elements for FEC Framework (described in [RFC6364]) together 86 define mechanisms sufficient enough to build an actual Content 87 Delivery Protocol (CDP) with FEC protection. Methods to convey FEC 88 Framework Configuration Information (described in [RFC6695]) on the 89 other hand provides the signaling protocols that may be used as part 90 of CDP to communicate FEC Scheme-Specific Information from FEC sender 91 to a single as well as multiple FEC receivers. This document 92 provides a guideline on how the mechanisms defined in [RFC6363] and 93 [RFC6364] can be sufficiently used to design a CDP over a non-trivial 94 scenario, namely protection of multiple source flows with one or more 95 repair flows. 97 In particular, we provide clarifications and descriptions on how: 99 o source and repair flows may be uniquely identified, 101 o source blocks may be generated from one or more source flows, 103 o repair flows may be paired with the source flows, 105 o the receiver explicitly and implicitly identifies individual 106 flows, 108 o source blocks are regenerated at the receiver and the missing 109 source symbols in a source block are recovered. 111 2. Definitions/Abbreviations 113 This document uses all the definitions and abbreviations from Section 114 2 of [RFC6363] minus the RFC 2119 requirements language. 116 3. Construction of a Repair Flow from Multiple Source Flows 118 At the sender side, CDP constructs the source blocks (SB) by 119 multiplexing transport payloads from multiple flows (See Figure 1 and 120 Figure 2). According to the FEC Framework, each source block is FEC- 121 protected separately. Each source block is given to the specific FEC 122 encoder used within the CDP as input and as the outputs Explicit 123 Source FEC Payload ID, Repair FEC Payload ID, and Repair Payloads 124 corresponding to that source block are generated. Note that Explicit 125 Source FEC payload ID is optional and if CDP has implicit means of 126 constructing the source block at the sender/receiver (e.g., by using 127 any existing sequence numbers in the payload), the Explicit Source 128 FEC payload ID might not be output. 130 +------------+ 131 s_1 --------> | | 132 . Source | Source | +--------+ +--------+ +--------+ 133 . Flows | Block |==> ..|SB_(j+1)| | SB_j | |SB_(j-1)| .. 134 s_n --------> | Generation | +--------+ +--------+ +--------+ 135 +------------+ 137 Figure 1: Source Block generation for an FEC scheme 139 Figure 2 shows the structure of a source block. A CDP must clearly 140 specify which payload corresponds to which source flow and the length 141 of each payload. 143 <------------------ Source Block (SB) -------------------> 145 +-------...-----+-------...-----+- -+-------...-----+ 146 | Payload_1 | Payload_2 | . . . | Payload_n | 147 +-------...-----+-------...-----+- -+-------...-----+ 148 \______ _______|______ _______| |______ _______| 149 \/ \/ \/ 150 FID_1,Len_1 FID_2,Len_2 FID_n,Len_n 152 Figure 2: Structure of a Source Block 154 Flow ID (FID) value provides a unique short-hand identifier for the 155 source flows. FID is specified and associated with the possibly 156 wildcarded tuple of {source IP address, source port, destination IP 157 address, destination port, transport protocol} in the SDP 158 description. When wildcarded, certain fields in the tuple are not 159 needed for distinguishing the source flows. The tuple is carried in 160 the IP and transport headers of the source packets. Since FID is 161 utilized by the CDP and FEC scheme to distinguish between the source 162 packets, the tuple must have a one-to-one mapping to a valid FID. 163 This point will be clearer in the specific example given later in 164 this section. The length of FID must be a priori fixed and known to 165 both the receiver and sender. Alternatively, it might be specified 166 in the FEC-Scheme-Specific Information field in the SDP element 167 [RFC6364]. 169 The payload length (Len) information is needed to figure out how many 170 bits, bytes, or symbols (depending on the FEC scheme) from a 171 particular source flow are included in the source block. If the 172 payload is not an integer multiple of the specified symbol length, 173 the remaining portion is padded with zeros (See Figure 3 and 174 Figure 4). 176 +------+ 177 +--------+ +--------+ +--------+ | | -------> r_1 178 .. |SB_(j+1)| | SB_j | |SB_(j-1)| .. ==> | FEC | Repair . 179 +--------+ +--------+ +--------+ |Scheme| Flows . 180 | | -------> r_k 181 +------+ 183 Figure 3: Repair flow generation by an FEC scheme 185 <------------------ Source Block (SB) -------------------> 186 | | | | | | 187 +-------...-----+-------...-----+- -+-------...-----+ | 188 | Payload_1 | Payload_2 | . . . | Payload_n |0| 189 +-------...-----+-------...-----+- -+-------...-----+ | 190 | | | | | | 191 | Symbol_1 | Symbol_2 | Symbol_3 | . . . | Symbol_m | 192 |<-------->|<-------->|<-------->| |<-------->| 194 +------+ 195 Symbol_1,..,Symbol_m => | FEC | => Symbol_u,..,Symbol_1 196 | Enc. | 197 +------+ 199 Figure 4: Repair flow payload generation 201 FEC schemes typically expect a source block of certain size, say m 202 symbols. Therefore, the FEC encoder divides each source block into m 203 symbols (with some padding if the source block is shorter than the 204 expected m symbols) and generates u repair symbols which are 205 functions of the m symbols in the original source block. The repair 206 symbols are grouped by the FEC scheme into repair payloads with each 207 repair payload assigned a Repair FEC Payload ID in order to associate 208 each repair payload with a particular source block at the receiver. 209 If the payloads in a given source block have sequence numbers that 210 can uniquely specify their location in the source block, an Explicit 211 Source FEC Payload ID may not be generated for these payloads. 212 Otherwise, Explicit Source FEC Payload IDs are generated for each 213 payload and indicate the order the payloads appear in the source 214 block. 216 Note that FID and length information are not actually transmitted 217 with the source payloads since both information can be gathered by 218 other means as it will be clear in the next sections. 220 3.1. Example: Two Source Flows Protected by a Single Repair Flow 222 In this section, we present an example of source flow and repair flow 223 generation by the CDP. We have two source flows with flow IDs of 0 224 and 1 to be protected by a single repair flow (See Figure 5). The 225 first source flow is multicast to 233.252.0.1 and the second source 226 flow is multicast to 233.252.0.2. Both flows use the port number 227 30000. 229 SOURCE FLOWS 230 S1: Source Flow | | INSTANCE #1 231 |---------| R3: Repair Flow 232 S2: Source Flow | 234 Figure 5: Example: Two source flows and one repair flow 236 The SDP description below states that the source flow defined by the 237 tuple {*,*,233.252.0.1,30000} is identified with FID=0 and the source 238 flow defined by the tuple {*,*,233.252.0.2,30000} is identified with 239 FID=1 (via the 'id' parameter of the "fec-source-flow" attribute). 240 The SDP description also states that the repair flow is to be 241 received at the multicast address of 233.252.0.3 and at port 30000. 243 v=0 244 o=ali 1122334455 1122334466 IN IP4 fec.example.com 245 s=FEC Framework Examples 246 t=0 0 247 a=group:FEC-FR S1 S2 R3 248 m=video 30000 RTP/AVP 100 249 c=IN IP4 233.252.0.1/127 250 a=rtpmap:100 MP2T/90000 251 a=fec-source-flow: id=0 252 a=mid:S1 253 m=video 30000 RTP/AVP 101 254 c=IN IP4 233.252.0.2/127 255 a=rtpmap:101 MP2T/90000 256 a=fec-source-flow: id=1 257 a=mid:S2 258 m=application 30000 UDP/FEC 259 c=IN IP4 233.252.0.3/127 260 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5 261 a=repair-window:150ms 262 a=mid:R3 264 Figure 6 shows the first and the second source blocks (SB_1 and SB_2) 265 generated from these two source flows. In this example, SB_1 is of 266 length 10000 bytes. Suppose that the FEC scheme uses a symbol length 267 of 512 bytes. Then SB_1 can be divided into 20 symbols after padding 268 the source block for 240 bytes. Assume that the FEC scheme is 269 rate-2/3 erasure code, hence, it generates 10 repair symbols from 20 270 original symbols for SB_1. On the other hand, SB_2 is 7000-byte long 271 and can be divided into 14 symbols after padding 168 bytes. Using 272 the same encoder, suppose that 7 repair symbols are generated for 273 SB_2. 275 <-------- Source Block 1 --------> 276 +------------+-------------------+ 277 | $1 $2 $3 $4| #1 #2 #3 #4 #5 #6 | 0..00 278 +------------+-------------------+ 279 \__________________ __________________/ 280 \/ 281 @1 @2 @3 @4 @5 @6 @7 @8 @9 @10 283 <---- Source Block 2 ----> 284 +----------------+-------+ 285 | $5 $6 $7 $8 $9 | #7 #8 |0..00 286 +----------------+-------+ 287 \______________ _____________/ 288 \/ 289 @11 @12 @13 @14 @15 @16 @17 291 $: 1000-byte payload from source flow 1 292 #: 1000-byte payload from source flow 2 293 @: Repair symbol 295 Figure 6: Source block with two source flows 297 The information on the unit of payload length, FEC scheme, symbol 298 size, and coding rates can be specified in the FEC Scheme-Specific 299 Information (FSSI) field of the SDP element. If the values of the 300 payload lengths from each source flow and the order of appearance of 301 source flows in every source block are fixed during the session, 302 these values may be also provided in the FSSI field. To carry FSSI 303 information to the FEC receivers, one may use the signaling methods 304 described in [RFC6695]. In our example, we will consider the case 305 where the ordering is fixed and known both at the sender and the 306 receiver, but the payload lengths will be variable from one source 307 block to another. We assume that the payload of a source flow with 308 an FID smaller than another flow's FID precedes other payloads in a 309 source block. 311 The FEC scheme gets the source blocks as input and generates the 312 parity blocks for each source block to protect the whole source 313 block. In the example, the repair payloads for SB_1 consist of 512- 314 byte symbols, denoted by @1 to @10. Similarly @11 to @17 constitute 315 the repair payloads for SB_2. The FEC scheme outputs the repair 316 payloads along with the Repair FEC Payload IDs. In our example, 317 Repair FEC Payload ID provides information on the source block 318 sequence number and the order the repair symbols are generated. For 319 instance @3 is the third FEC repair symbol for SB_1 and the three 320 tuple {@3,SB_1,3} can uniquely deliver this information. In our 321 example, the FEC scheme also provides Explicit Source FEC Payload IDs 322 that carry information to indicate which source symbols correspond to 323 which source block sequence number and the relative position in the 324 source block. For instance the two tuple {SB_2,2} can be attached to 325 $6 as the Explicit Source FEC Payload ID to indicate that $6 is 326 protected together with packets belonging to SB_2, and $6 is the 327 second payload in SB_2. 329 The source packets are generated from the source symbols by 330 concatenating consecutive symbols in one packet. There should not be 331 any fragmentation of a source symbol, e.g., symbols #7 and #8 can be 332 concatenated in one transport payload of 2000-bytes (The 333 implementation should make sure that the size of the resulting source 334 packet - payload plus the overhead - is not larger than the path 335 MTU), but one portion of symbol #7 should not be put in one source 336 packet and the remaining portion in another source packet. The 337 simplest implementation is to place each source symbol in a different 338 source packet as shown in Figure 7. 340 +------------------------------------+ 341 | IP header {233.252.0.1} | 342 +------------------------------------+ 343 | Transport header {30000} | 344 +------------------------------------+ 345 | Original Transport Payload {$6} | 346 +------------------------------------+ 347 | Source FEC Payload ID {SB_2,2} | 348 +------------------------------------+ 350 Figure 7: Example of a source packet for IPv4 352 The repair packets are generated from the repair symbols belonging to 353 the same source block by grouping consecutive symbols in one packet. 354 There should not be any fragmentation of a repair symbol, e.g., 355 symbols @4, @5, and @6 can be concatenated in one transport payload 356 of 1536-bytes, but @6 should not be divided into smaller sub-symbols 357 and spread over multiple repair packets. The Repair FEC Payload ID 358 must carry sufficient information for the decoding process and in our 359 example indicating source block sequence number, length of each 360 source payload, and the order that the first parity block in a repair 361 packet is generated are sufficient. The exact header format of 362 Repair FEC Payload ID may be specified in the FSSI field of the SDP 363 element. In Figure 8 for instance, the repair symbols @4, @5, and @6 364 are concatenated together. The Payload ID {SB_1,4,4,6} states that 365 the repair symbols protect SB_1, the first repair symbol in the 366 payload is generated as the 4th symbol and the source block consists 367 of two source flows carrying 4 and 6 packets from each. 369 +------------------------------------+ 370 | IP header {233.252.0.3} | 371 +------------------------------------+ 372 | Transport header {30000} | 373 +------------------------------------+ 374 | Repair FEC Payload ID {SB_1,4,4,6} | 375 +------------------------------------+ 376 | Repair Symbols {@4,@5,@6} | 377 +------------------------------------+ 379 Figure 8: Example of a repair packet for IPv4 381 4. Reconstruction of Source Flows from Repair Flow(s) 383 Here we provide an example for reconstructing multiple source flows 384 from a single repair flow. 386 4.1. Example: Multiple Source Flows Protected by a Single Repair Flow 388 At the receiver, source flows 1 and 2 are received at 389 {233.252.0.1,30000} and {233.252.0.2,30000}, while the repair flow is 390 received at {233.252.0.3,30000}. The CDP can map these tuples to the 391 flow IDs using the SDP elements. Accordingly, the payloads received 392 at {233.252.0.1,30000} and {233.252.0.2,30000} are mapped to flow IDs 393 0 and 1, respectively. 395 The CDP passes the flow IDs and received payloads along with the 396 Explicit Source FEC Payload ID to the FEC scheme defined in the SDP 397 description. The CDP also passes the received repair packet payloads 398 and Repair FEC Payload ID to the FEC scheme. The FEC scheme can 399 construct the original source block with missing packets by using the 400 information given in the FEC Payload IDs. The FEC Repair Payload ID 401 provides the information that SB_1 has packets from two flows with 4 402 packets from the first one and 6 packets from the second one. Flow 403 IDs state that the packets from source flow 0 precedes the packets 404 from source flow 1. Explicit Source FEC Payload IDs on the other 405 hand provide the information about which source payload appears in 406 what order. Therefore, the FEC scheme can depict an source block 407 with exact locations of the missing packets. Figure 9 depicts the 408 case for SB_1. Since the original source block with missing packets 409 can be constructed at the decoder and the FEC scheme knows the coding 410 rate (e.g., it might be carried in the FSSI field in the SDP 411 description), a proper decoding operation can start as soon as the 412 repair symbols are provided to the FEC scheme. 414 <-------- Source Block 1 --------> 415 +------------+-------------------+ 416 | $1 $2 X X | #1 X #3 #4 #5 #6 | 417 +------------+-------------------+ 419 O: Symbols received from the source flow 1 for SB_1 420 #: Symbols received from the source flow 2 for SB_1 421 X: Lost source symbols 423 Figure 9: Source block regeneration 425 When the FEC scheme can recover any missing symbol while more repair 426 symbols are arriving, it provides the recovered blocks along with the 427 source flow IDs of the recovered blocks as outputs to the CDP. The 428 receiver knows how long to wait to repair the remaining missing 429 packets (e.g., specified by the 'repair-window' attribute in the SDP 430 description). After the associated timer expires, the CDP hands over 431 whatever could be recovered from the source flow to the application 432 layer and continues with processing the next source block. 434 5. Security Considerations 436 For the general security considerations related to the FEC Framework, 437 refer to [RFC6363]. For the security considerations related to the 438 SDP elements in the FEC Framework, refer to [RFC6364]. There are no 439 additional security considerations that apply to this document. 441 6. IANA Considerations 443 There are no IANA related issues considered in this document. 445 7. Acknowledgments 447 The authors would like to thank the FEC Framework Design Team for 448 their inputs, suggestions and contributions. 450 8. Normative References 452 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 453 Correction (FEC) Framework", RFC 6363, October 2011. 455 [RFC6364] Begen, A., "Session Description Protocol Elements for the 456 Forward Error Correction (FEC) Framework", RFC 6364, 457 October 2011. 459 [RFC6695] Asati, R., "Methods to Convey Forward Error Correction 460 (FEC) Framework Configuration Information", RFC 6695, 461 August 2012. 463 Authors' Addresses 465 Ulas C. Kozat 466 DoCoMo USA Labs 467 3240 Hillview Avenue 468 Palo Alto, CA 94304-1201 469 USA 471 Phone: +1 650 496 4739 472 Email: kozat@docomolabs-usa.com 474 Ali Begen 475 Cisco 476 181 Bay Street 477 Toronto, ON M5J 2T3 478 Canada 480 Email: abegen@cisco.com