idnits 2.17.1 draft-kozat-fecframe-pseudo-cdp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 525. 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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 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 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 7, 2008) is 5743 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-01 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 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: Standards Track A. Begen 5 Expires: January 8, 2009 Cisco Systems 6 July 7, 2008 8 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source 9 Flows in FEC Framework 10 draft-kozat-fecframe-pseudo-cdp-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 8, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document provides a pseudo Content Delivery Protocol (CDP) to 44 protect multiple source flows with one or more repair flows based on 45 the FEC Framework document and the Session Description Protocol (SDP) 46 elements defined for the framework. The purpose of the document is 47 not to provide a full-pledged protocol, but to show how the defined 48 framework and SDP elements can be combined together to design a CDP. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 54 3. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 3 55 4. Construction of a Repair Flow from Multiple Source Flows . . . 4 56 4.1. Example: Two Source Flows Protected by a Single Repair 57 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Reconstruction of Source Flows from Repair Flow(s) . . . . . . 10 59 5.1. Example: Multiple Source Flows Protected by a Single 60 Repair Flow . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 64 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . . . . . . . 13 68 1. Introduction 70 The Forward Error Correction (FEC) Framework (described in 71 [I-D.ietf-fecframe-framework]) and SDP Elements for FEC Framework 72 (described in [I-D.ietf-fecframe-sdp-elements]) together define 73 mechanisms sufficient enough to build an actual Content Delivery 74 Protocol (CDP). This document aims at providing a guideline on how 75 the mechanisms defined in each document become useful over a non- 76 trivial scenario, namely protection of multiple source flows with one 77 or more repair flows. 79 In particular, we provide clarifications and descriptions on how: 81 o source and repair flows may be uniquely identified, 83 o source blocks may be generated from one or more source flows, 85 o repair flows may be paired with the source flows, 87 o the receiver explicitly and implicitly identifies individual 88 flows, 90 o source blocks are regenerated at the receiver and the missing 91 source symbols in a source block are recovered. 93 2. Requirements Notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Definitions/Abbreviations 101 This document uses the following definitions. For further 102 definitions that apply to FEC Framework in general, see 103 [I-D.ietf-fecframe-framework]. 105 CDP: Content Delivery Protocol. 107 FEC: Forward Error Correction. 109 Source Flow: The packet flow or flows to which FEC protection is to 110 be applied. 112 Repair Flow: The packet flow or flows carrying FEC data. 114 Transport Protocol: The protocol used for transport of the source 115 data flow being protected. 117 FEC Scheme: A specification which defines the additional protocol 118 aspects required to use a particular FEC code with the FEC 119 framework. 121 Source Block: The group of source data packets which are to be FEC 122 protected as a single block. 124 Source FEC Payload ID: An FEC Payload ID specifically for use with 125 source packets. 127 Repair FEC Payload ID: An FEC Payload ID specifically for use with 128 repair packets. 130 4. Construction of a Repair Flow from Multiple Source Flows 132 At the sender side, CDP constructs the source blocks (SB) by 133 multiplexing transport payloads from multiple flows (See Figure 1 and 134 Figure 2). According to the FEC Framework, each source block is FEC 135 protected separately. Each source block is given to the specific FEC 136 encoder used within the CDP as input and as the outputs Explicit 137 Source FEC Payload ID, Repair FEC Payload ID, and Repair Payloads 138 corresponding to that source block are generated. Note that Explicit 139 Source FEC payload ID is optional and if CDP has implicit means of 140 constructing the source block at the sender/receiver (e.g., by using 141 any existing sequence numbers in the payload), the Explicit Source 142 FEC payload ID might not be output. 144 +------------+ 145 s_1 --------> | | 146 . Source | Source | +--------+ +--------+ +--------+ 147 . Flows | Block |=> ..|SB_(j+1)| | SB_j | |SB_(j-1)| .. 148 s_n --------> | Generation | +--------+ +--------+ +--------+ 149 +------------+ 151 Figure 1: Source Block generation for an FEC scheme 153 Figure 2 shows the structure of a source block. A CDP MUST clearly 154 specify which payload corresponds to which source flow and the length 155 of each payload. 157 <------------------ Source Block (SB) -------------------> 159 +-------...-----+-------...-----+- -+-------...-----+ 160 | Payload_1 | Payload_2 | . . . | Payload_n | 161 +-------...-----+-------...-----+- -+-------...-----+ 162 \______ _______|______ _______| |______ _______| 163 \/ \/ \/ 164 FID_1,Len_1 FID_2,Len_2 FID_n,Len_n 166 Figure 2: Structure of a Source Block 168 Flow ID (FID) value provides a unique short-hand identifier for the 169 source flows. FID is specified and associated with the possibly 170 wildcarded tuple of {Source IP Address, Destination IP Address, 171 Source Transport Port, Destination Transport Port, Transport 172 Protocol} in the SDP file. When wildcarded, certain fields in the 173 tuple are not needed for distinguishing the source flows. The tuple 174 is carried in the IP and transport headers of the source packets. 175 Since FID is utilized by the CDP and FEC scheme to distinguish 176 between the source packets, the tuple MUST have a one-to-one mapping 177 to a valid FID. This point will be clearer in the specific example 178 given later in this section. The length of FID must be a priori 179 fixed and known to both the receiver and sender. Alternatively, it 180 might be specified in the FEC-Scheme-Specific Information field in 181 the SDP element [I-D.ietf-fecframe-sdp-elements]. 183 The payload length (Len) information is needed to figure out how many 184 bits, bytes, or symbols (depending on the FEC scheme) from a 185 particular source flow are included in the source block. If the 186 payload is not an integer multiple of the specified symbol length, 187 the remaining portion is padded with zeros (See Figure 3 and 188 Figure 4). 190 +------+ 191 +--------+ +--------+ +--------+ | | -------> r_1 192 .. |SB_(j+1)| | SB_j | |SB_(j-1)| .. --> | FEC | Repair . 193 +--------+ +--------+ +--------+ |Scheme| Flows . 194 | | -------> r_k 195 +------+ 197 Figure 3: Repair flow generation by an FEC scheme 199 <------------------ Source Block (SB) -------------------> 200 | | | | | | 201 +-------...-----+-------...-----+- -+-------...-----+ | 202 | Payload_1 | Payload_2 | . . . | Payload_n |0| 203 +-------...-----+-------...-----+- -+-------...-----+ | 204 | | | | | | 205 | Symbol_1 | Symbol_2 | Symbol_3 | . . . | Symbol_m | 206 |<-------->|<-------->|<-------->| |<-------->| 208 +------+ 209 Symbol_1,..,Symbol_m => | FEC | => Symbol_u,..,Symbol_1 210 | Enc. | 211 +------+ 213 Figure 4: Repair flow payload generation 215 FEC schemes typically expect a source block of certain size, say m 216 symbols. Therefore, the FEC encoder divides each source block into m 217 symbols (with some padding if the source block is shorter than the 218 expected m symbols) and generates u repair symbols which are 219 functions of the m symbols in the original source block. The repair 220 symbols are grouped by the FEC scheme into repair payloads with each 221 repair payload assigned a Repair FEC Payload ID in order to associate 222 each repair payload with a particular source block at the receiver. 223 If the payloads in a given source block have sequence numbers that 224 can uniquely specify their location in the source block, an Explicit 225 Source FEC Payload ID may not be generated for these payloads. 226 Otherwise, Explicit Source FEC Payload IDs are generated for each 227 payload and indicate the order the payloads appear in the source 228 block. 230 Note that FID and length information are not actually transmitted 231 with the source payloads since both information can be gathered by 232 other means as it will be clear in the next sections. 234 4.1. Example: Two Source Flows Protected by a Single Repair Flow 236 In this subsection, we present an example of source flow and repair 237 flow generation by the CDP. We have two source flows with flow IDs 238 of 0 and 1 to be protected by a single repair flow (See Figure 5). 239 The first source flow is multicast to 224.1.1.1 and the second source 240 flow is multicast to 224.1.1.2. Both flows use the port number 241 30000. The SDP description below states that the source flow defined 242 by the tuple {*,224.1.1.1,*,30000} is identified with FID=0 and the 243 source flow defined by the tuple {*,224.1.1.2,*,30000} is identified 244 with FID=1. The SDP description also states that the repair flow is 245 to be received at the multicast address of 224.1.2.1 and at port 246 30000. 248 SOURCE FLOWS | INSTANCE #1 249 0: Source Flow |_________| 2: Repair Flow 250 1: Source Flow | 252 Figure 5: Example: Two source flows and one repair flow 254 v=0 255 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 256 s=FEC Framework Examples 257 t=0 0 258 a=group:FEC S1 S2 R1 259 m=video 30000 RTP/AVP 100 260 c=IN IP4 224.1.1.1/127 261 a=rtpmap:100 MP2T/90000 262 a=fec-source-flow: id=0 263 a=mid:S1 264 m=video 30000 RTP/AVP 101 265 c=IN IP4 224.1.1.2/127 266 a=rtpmap:101 MP2T/90000 267 a=fec-source-flow: id=1 268 a=mid:S2 269 m=application 30000 RTP/AVP 110 270 c=IN IP4 224.1.2.1/127 271 a=rtpmap:110 1d-interleaved-parityfec/90000 272 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X 273 a=repair-window: 200 274 a=mid:R1 276 Figure 7 shows the first and the second source blocks (SB_1 and SB_2) 277 generated from these two source flows. In this example, SB_1 is of 278 length 10000 bytes. Suppose that the FEC scheme uses a symbol length 279 of 512 bytes. Then SB_1 can be divided into 20 symbols after padding 280 the source block for 240 bytes. Assume that the FEC scheme is 281 rate-2/3 erasure code, hence, it generates 10 repair symbols from 20 282 original symbols for SB_1. On the other hand, SB_2 is 7000-byte long 283 and can be divided into 14 symbols after padding 168 bytes. Using 284 the same encoder, suppose that 7 repair symbols are generated for 285 SB_2. 287 <-------- Source Block 1 --------> 288 +------------+-------------------+ 289 | $1 $2 $3 $4| #1 #2 #3 #4 #5 #6 | 0..00 290 +------------+-------------------+ 291 \__________________ __________________/ 292 \/ 293 @1 @2 @3 @4 @5 @6 @7 @8 @9 @10 295 <---- Source Block 2 ----> 296 +----------------+-------+ 297 | $5 $6 $7 $8 $9 | #7 #8 |0..00 298 +----------------+-------+ 299 \______________ _____________/ 300 \/ 301 @11 @12 @13 @14 @15 @16 @17 303 $: 1000-byte payload from source flow 1 304 #: 1000-byte payload from source flow 2 305 @: Repair symbol 307 Figure 7: Source block with two source flows 309 The information on the unit of payload length, FEC scheme, symbol 310 size, and coding rates can be specified in the FEC Scheme Specific 311 Information (FSSI) field of the SDP element. If the values of the 312 payload lengths from each source flow and the order of appearance of 313 source flows in every source block are fixed during the session, 314 these values may be also provided in the FSSI field. In our example, 315 we will consider the case where the ordering is fixed and known both 316 at the sender and the receiver, but the payload lengths will be 317 variable from one source block to another. We assume that the 318 payload of a source flow with an FID smaller than another flow's FID 319 precedes other payloads in a source block. 321 The FEC scheme gets the source blocks as input and generates the 322 parity blocks for each source block to protect the whole source 323 block. In the example, the repair payloads for SB_1 consist of 512- 324 byte symbols, denoted by @1 to @10. Similarly @11 to @17 constitute 325 the repair payloads for SB_2. The FEC scheme outputs the repair 326 payloads along with the Repair FEC Payload IDs. In our example, 327 Repair FEC Payload ID provides information on the source block 328 sequence number and the order the repair symbols are generated. For 329 instance @3 is the third FEC repair symbol for SB_1 and the three 330 tuple {@3, SB_1,3} can uniquely deliver this information. In our 331 example, the FEC scheme also provides Explicit Source FEC Payload IDs 332 that carry information to indicate which source symbols correspond to 333 which source block sequence number and its relative position in the 334 source block. For instance the two tuple {SB_2,2} can be attached to 335 $6 as the Explicit Source FEC Payload ID to indicate that $6 is 336 protected together with packets belonging to SB_2, and $6 is the 337 second payload in SB_2. 339 The source packets are generated from the source symbols by 340 concatenating consecutive symbols in one packet. There SHOULD NOT be 341 any fragmentation of a source symbol, e.g., symbols #7 and #8 can be 342 concatenated in one transport payload of 2000-bytes (The 343 implementation SHOULD make sure that the size of the resulting source 344 packet - payload plus the overhead - is not larger than the path 345 MTU), but one portion of symbol #7 SHOULD NOT be put in one source 346 packet and the remaining portion in another source packet. The 347 simplest implementation is to place each source symbol in a different 348 source packet as shown in Figure 8. 350 +------------------------------------+ 351 | IP header {224.1.1.1} | 352 +------------------------------------+ 353 | Transport header {30000} | 354 +------------------------------------+ 355 | Original Transport Payload {$6} | 356 +------------------------------------+ 357 | Source FEC Payload ID {SB_2,2} | 358 +------------------------------------+ 360 Figure 8: Example of a source packet 362 The repair packets are generated from the repair symbols belonging to 363 the same source block by grouping consecutive symbols in one packet. 364 There should not be any fragmentation of a repair symbol, e.g., 365 symbols @4, @5, and @6 can be concatenated in one transport payload 366 of 1536-bytes, but @6 SHOULD NOT be divided into smaller sub-symbols 367 and spread over multiple repair packets. The Repair FEC Payload ID 368 MUST carry sufficient information for the decoding process and in our 369 example indicating source block sequence number, length of each 370 source payload, and the order that the first parity block in a repair 371 packet is generated are sufficient. The exact header format of 372 Repair FEC Payload ID may be specified in the FSSI field of the SDP 373 element. In Figure 9 for instance, the repair symbols @4, @5, and @6 374 are concatenated together. The Payload ID {SB_1,4,4,6} states that 375 the repair symbols protect SB_1, the first repair symbol in the 376 payload is generated as the 4th symbol and the source block consists 377 of two source flows carrying 4 and 6 packets from each. 379 +------------------------------------+ 380 | IP header {224.1.2.1} | 381 +------------------------------------+ 382 | Transport header {30000} | 383 +------------------------------------+ 384 | Repair FEC Payload ID {SB_1,4,4,6} | 385 +------------------------------------+ 386 | Repair Symbols {@4,@5,@6} | 387 +------------------------------------+ 389 Figure 9: Example of a repair packet 391 5. Reconstruction of Source Flows from Repair Flow(s) 393 5.1. Example: Multiple Source Flows Protected by a Single Repair Flow 395 At the receiver, source flows 1 and 2 are received at 396 {224.1.1.1,30000} and {224.1.1.2,30000}, while the repair flow is 397 received at {224.1.2.1,30000}. The CDP can map these tuples to the 398 flow IDs using the SDP elements. Accordingly, the payloads received 399 at {224.1.1.1,30000} and {224.1.1.2,30000} are mapped to flow IDs 0 400 and 1, respectively. 402 The CDP passes the flow IDs and received payloads along with the 403 Explicit Source FEC Payload ID to the FEC scheme defined in the SDP 404 description. The CDP also passes the received repair packet payloads 405 and Repair FEC Payload ID to the FEC scheme. The FEC scheme can 406 construct the original source block with missing packets by using the 407 information given in the FEC Payload IDs. The FEC Repair Payload ID 408 provides the information that SB_1 has packets from two flows with 4 409 packets from the first one and 6 packets from the second one. Flow 410 IDs state that the packets from source flow 0 precedes the packets 411 from source flow 1. Explicit Source FEC Payload IDs on the other 412 hand provide the information about which source payload appears in 413 what order. Therefore, the FEC scheme can depict an source block 414 with exact locations of the missing packets. Figure 10 depicts the 415 case for SB_1. Since the original source block with missing packets 416 can be constructed at the decoder and the FEC scheme knows the coding 417 rate (e.g., it might be carried in the FSSI field in the SDP 418 description), a proper decoding operation can start as soon as the 419 repair symbols are provided to the FEC scheme. 421 <-------- Source Block 1 --------> 422 +------------+-------------------+ 423 | $1 $2 X X | #1 X #3 #4 #5 #6 | 424 +------------+-------------------+ 426 O: Symbols received from the source flow 1 for SB_1 427 #: Symbols received from the source flow 2 for SB_1 428 X: Lost source symbols 430 Figure 10: Source block regeneration 432 When the FEC scheme can recover any missing block while more repair 433 symbols are arriving, it provides the recovered blocks along with the 434 source flow IDs of the recovered blocks as outputs to the CDP. The 435 receiver knows how long to wait to repair the remaining missing 436 packets (e.g., specified by the 'repair-window' attribute in the SDP 437 description). After the associated timer expires, the CDP hands over 438 whatever could be recovered from the source flow to the application 439 layer and continues with processing the next source block. 441 6. Security Considerations 443 TBC. 445 7. IANA Considerations 447 TBC. 449 8. Acknowledgments 451 TBC. 453 9. Normative References 455 [I-D.ietf-fecframe-framework] 456 Watson, M., "Forward Error Correction (FEC) Framework", 457 draft-ietf-fecframe-framework-01 (work in progress), 458 November 2007. 460 [I-D.ietf-fecframe-sdp-elements] 461 Begen, A., "SDP Elements for FEC Framework", 462 draft-ietf-fecframe-sdp-elements-00 (work in progress), 463 February 2008. 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, March 1997. 468 Authors' Addresses 470 Ulas C. Kozat 471 DoCoMo USA Labs 472 3240 Hillview Avenue 473 Palo Alto, CA 94304-1201 474 USA 476 Phone: +1 650 496 4739 477 Email: kozat@docomolabs-usa.com 479 Ali Begen 480 Cisco Systems 481 170 West Tasman Drive 482 San Jose, CA 95134 483 USA 485 Email: abegen@cisco.com 487 Full Copyright Statement 489 Copyright (C) The IETF Trust (2008). 491 This document is subject to the rights, licenses and restrictions 492 contained in BCP 78, and except as set forth therein, the authors 493 retain all their rights. 495 This document and the information contained herein are provided on an 496 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 497 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 498 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 499 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 500 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 501 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 503 Intellectual Property 505 The IETF takes no position regarding the validity or scope of any 506 Intellectual Property Rights or other rights that might be claimed to 507 pertain to the implementation or use of the technology described in 508 this document or the extent to which any license under such rights 509 might or might not be available; nor does it represent that it has 510 made any independent effort to identify any such rights. Information 511 on the procedures with respect to rights in RFC documents can be 512 found in BCP 78 and BCP 79. 514 Copies of IPR disclosures made to the IETF Secretariat and any 515 assurances of licenses to be made available, or the result of an 516 attempt made to obtain a general license or permission for the use of 517 such proprietary rights by implementers or users of this 518 specification can be obtained from the IETF on-line IPR repository at 519 http://www.ietf.org/ipr. 521 The IETF invites any interested party to bring to its attention any 522 copyrights, patents or patent applications, or other proprietary 523 rights that may cover technology that may be required to implement 524 this standard. Please address the information to the IETF at 525 ietf-ipr@ietf.org. 527 Acknowledgment 529 Funding for the RFC Editor function is provided by the IETF 530 Administrative Support Activity (IASA).