idnits 2.17.1 draft-ietf-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 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 524. 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 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 (October 27, 2008) is 5653 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-03 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-01 Summary: 1 error (**), 0 flaws (~~), 4 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: April 30, 2009 Cisco Systems 6 October 27, 2008 8 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source 9 Flows in FEC Framework 10 draft-ietf-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 April 30, 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 section, we present an example of source flow and repair flow 237 generation by the CDP. We have two source flows with flow IDs of 0 238 and 1 to be protected by a single repair flow (See Figure 5). The 239 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.example.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 udp/fec 270 c=IN IP4 224.1.2.1/127 271 a=fec-repair-flow: encoding-id=0; ss-fssi=5hu= 272 a=repair-window: 200 273 a=mid:R1 275 Figure 7 shows the first and the second source blocks (SB_1 and SB_2) 276 generated from these two source flows. In this example, SB_1 is of 277 length 10000 bytes. Suppose that the FEC scheme uses a symbol length 278 of 512 bytes. Then SB_1 can be divided into 20 symbols after padding 279 the source block for 240 bytes. Assume that the FEC scheme is 280 rate-2/3 erasure code, hence, it generates 10 repair symbols from 20 281 original symbols for SB_1. On the other hand, SB_2 is 7000-byte long 282 and can be divided into 14 symbols after padding 168 bytes. Using 283 the same encoder, suppose that 7 repair symbols are generated for 284 SB_2. 286 <-------- Source Block 1 --------> 287 +------------+-------------------+ 288 | $1 $2 $3 $4| #1 #2 #3 #4 #5 #6 | 0..00 289 +------------+-------------------+ 290 \__________________ __________________/ 291 \/ 292 @1 @2 @3 @4 @5 @6 @7 @8 @9 @10 294 <---- Source Block 2 ----> 295 +----------------+-------+ 296 | $5 $6 $7 $8 $9 | #7 #8 |0..00 297 +----------------+-------+ 298 \______________ _____________/ 299 \/ 300 @11 @12 @13 @14 @15 @16 @17 302 $: 1000-byte payload from source flow 1 303 #: 1000-byte payload from source flow 2 304 @: Repair symbol 306 Figure 7: Source block with two source flows 308 The information on the unit of payload length, FEC scheme, symbol 309 size, and coding rates can be specified in the FEC Scheme Specific 310 Information (FSSI) field of the SDP element. If the values of the 311 payload lengths from each source flow and the order of appearance of 312 source flows in every source block are fixed during the session, 313 these values may be also provided in the FSSI field. In our example, 314 we will consider the case where the ordering is fixed and known both 315 at the sender and the receiver, but the payload lengths will be 316 variable from one source block to another. We assume that the 317 payload of a source flow with an FID smaller than another flow's FID 318 precedes other payloads in a source block. 320 The FEC scheme gets the source blocks as input and generates the 321 parity blocks for each source block to protect the whole source 322 block. In the example, the repair payloads for SB_1 consist of 512- 323 byte symbols, denoted by @1 to @10. Similarly @11 to @17 constitute 324 the repair payloads for SB_2. The FEC scheme outputs the repair 325 payloads along with the Repair FEC Payload IDs. In our example, 326 Repair FEC Payload ID provides information on the source block 327 sequence number and the order the repair symbols are generated. For 328 instance @3 is the third FEC repair symbol for SB_1 and the three 329 tuple {@3, SB_1,3} can uniquely deliver this information. In our 330 example, the FEC scheme also provides Explicit Source FEC Payload IDs 331 that carry information to indicate which source symbols correspond to 332 which source block sequence number and its relative position in the 333 source block. For instance the two tuple {SB_2,2} can be attached to 334 $6 as the Explicit Source FEC Payload ID to indicate that $6 is 335 protected together with packets belonging to SB_2, and $6 is the 336 second payload in SB_2. 338 The source packets are generated from the source symbols by 339 concatenating consecutive symbols in one packet. There SHOULD NOT be 340 any fragmentation of a source symbol, e.g., symbols #7 and #8 can be 341 concatenated in one transport payload of 2000-bytes (The 342 implementation SHOULD make sure that the size of the resulting source 343 packet - payload plus the overhead - is not larger than the path 344 MTU), but one portion of symbol #7 SHOULD NOT be put in one source 345 packet and the remaining portion in another source packet. The 346 simplest implementation is to place each source symbol in a different 347 source packet as shown in Figure 8. 349 +------------------------------------+ 350 | IP header {224.1.1.1} | 351 +------------------------------------+ 352 | Transport header {30000} | 353 +------------------------------------+ 354 | Original Transport Payload {$6} | 355 +------------------------------------+ 356 | Source FEC Payload ID {SB_2,2} | 357 +------------------------------------+ 359 Figure 8: Example of a source packet 361 The repair packets are generated from the repair symbols belonging to 362 the same source block by grouping consecutive symbols in one packet. 363 There should not be any fragmentation of a repair symbol, e.g., 364 symbols @4, @5, and @6 can be concatenated in one transport payload 365 of 1536-bytes, but @6 SHOULD NOT be divided into smaller sub-symbols 366 and spread over multiple repair packets. The Repair FEC Payload ID 367 MUST carry sufficient information for the decoding process and in our 368 example indicating source block sequence number, length of each 369 source payload, and the order that the first parity block in a repair 370 packet is generated are sufficient. The exact header format of 371 Repair FEC Payload ID may be specified in the FSSI field of the SDP 372 element. In Figure 9 for instance, the repair symbols @4, @5, and @6 373 are concatenated together. The Payload ID {SB_1,4,4,6} states that 374 the repair symbols protect SB_1, the first repair symbol in the 375 payload is generated as the 4th symbol and the source block consists 376 of two source flows carrying 4 and 6 packets from each. 378 +------------------------------------+ 379 | IP header {224.1.2.1} | 380 +------------------------------------+ 381 | Transport header {30000} | 382 +------------------------------------+ 383 | Repair FEC Payload ID {SB_1,4,4,6} | 384 +------------------------------------+ 385 | Repair Symbols {@4,@5,@6} | 386 +------------------------------------+ 388 Figure 9: Example of a repair packet 390 5. Reconstruction of Source Flows from Repair Flow(s) 392 5.1. Example: Multiple Source Flows Protected by a Single Repair Flow 394 At the receiver, source flows 1 and 2 are received at 395 {224.1.1.1,30000} and {224.1.1.2,30000}, while the repair flow is 396 received at {224.1.2.1,30000}. The CDP can map these tuples to the 397 flow IDs using the SDP elements. Accordingly, the payloads received 398 at {224.1.1.1,30000} and {224.1.1.2,30000} are mapped to flow IDs 0 399 and 1, respectively. 401 The CDP passes the flow IDs and received payloads along with the 402 Explicit Source FEC Payload ID to the FEC scheme defined in the SDP 403 description. The CDP also passes the received repair packet payloads 404 and Repair FEC Payload ID to the FEC scheme. The FEC scheme can 405 construct the original source block with missing packets by using the 406 information given in the FEC Payload IDs. The FEC Repair Payload ID 407 provides the information that SB_1 has packets from two flows with 4 408 packets from the first one and 6 packets from the second one. Flow 409 IDs state that the packets from source flow 0 precedes the packets 410 from source flow 1. Explicit Source FEC Payload IDs on the other 411 hand provide the information about which source payload appears in 412 what order. Therefore, the FEC scheme can depict an source block 413 with exact locations of the missing packets. Figure 10 depicts the 414 case for SB_1. Since the original source block with missing packets 415 can be constructed at the decoder and the FEC scheme knows the coding 416 rate (e.g., it might be carried in the FSSI field in the SDP 417 description), a proper decoding operation can start as soon as the 418 repair symbols are provided to the FEC scheme. 420 <-------- Source Block 1 --------> 421 +------------+-------------------+ 422 | $1 $2 X X | #1 X #3 #4 #5 #6 | 423 +------------+-------------------+ 425 O: Symbols received from the source flow 1 for SB_1 426 #: Symbols received from the source flow 2 for SB_1 427 X: Lost source symbols 429 Figure 10: Source block regeneration 431 When the FEC scheme can recover any missing block while more repair 432 symbols are arriving, it provides the recovered blocks along with the 433 source flow IDs of the recovered blocks as outputs to the CDP. The 434 receiver knows how long to wait to repair the remaining missing 435 packets (e.g., specified by the 'repair-window' attribute in the SDP 436 description). After the associated timer expires, the CDP hands over 437 whatever could be recovered from the source flow to the application 438 layer and continues with processing the next source block. 440 6. Security Considerations 442 TBC. 444 7. IANA Considerations 446 TBC. 448 8. Acknowledgments 450 TBC. 452 9. Normative References 454 [I-D.ietf-fecframe-framework] 455 Watson, M., "Forward Error Correction (FEC) Framework", 456 draft-ietf-fecframe-framework-03 (work in progress), 457 October 2008. 459 [I-D.ietf-fecframe-sdp-elements] 460 Begen, A., "SDP Elements for FEC Framework", 461 draft-ietf-fecframe-sdp-elements-01 (work in progress), 462 July 2008. 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 Authors' Addresses 469 Ulas C. Kozat 470 DoCoMo USA Labs 471 3240 Hillview Avenue 472 Palo Alto, CA 94304-1201 473 USA 475 Phone: +1 650 496 4739 476 Email: kozat@docomolabs-usa.com 478 Ali Begen 479 Cisco Systems 480 170 West Tasman Drive 481 San Jose, CA 95134 482 USA 484 Email: abegen@cisco.com 486 Full Copyright Statement 488 Copyright (C) The IETF Trust (2008). 490 This document is subject to the rights, licenses and restrictions 491 contained in BCP 78, and except as set forth therein, the authors 492 retain all their rights. 494 This document and the information contained herein are provided on an 495 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 496 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 497 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 498 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 499 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 500 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 502 Intellectual Property 504 The IETF takes no position regarding the validity or scope of any 505 Intellectual Property Rights or other rights that might be claimed to 506 pertain to the implementation or use of the technology described in 507 this document or the extent to which any license under such rights 508 might or might not be available; nor does it represent that it has 509 made any independent effort to identify any such rights. Information 510 on the procedures with respect to rights in RFC documents can be 511 found in BCP 78 and BCP 79. 513 Copies of IPR disclosures made to the IETF Secretariat and any 514 assurances of licenses to be made available, or the result of an 515 attempt made to obtain a general license or permission for the use of 516 such proprietary rights by implementers or users of this 517 specification can be obtained from the IETF on-line IPR repository at 518 http://www.ietf.org/ipr. 520 The IETF invites any interested party to bring to its attention any 521 copyrights, patents or patent applications, or other proprietary 522 rights that may cover technology that may be required to implement 523 this standard. Please address the information to the IETF at 524 ietf-ipr@ietf.org. 526 Acknowledgment 528 Funding for the RFC Editor function is provided by the IETF 529 Administrative Support Activity (IASA).