idnits 2.17.1 draft-ietf-fecframe-pseudo-cdp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (March 7, 2009) is 5527 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-02 == Outdated reference: A later version (-09) exists of draft-ietf-fecframe-config-signaling-01 ** Downref: Normative reference to an Informational draft: draft-ietf-fecframe-config-signaling (ref. 'I-D.ietf-fecframe-config-signaling') Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 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: Standards Track A. Begen 5 Expires: September 8, 2009 Cisco Systems 6 March 7, 2009 8 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source 9 Flows in FEC Framework 10 draft-ietf-fecframe-pseudo-cdp-01 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 8, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document provides a pseudo Content Delivery Protocol (CDP) to 59 protect multiple source flows with one or more repair flows based on 60 the FEC Framework document and the Session Description Protocol (SDP) 61 elements defined for the framework. The purpose of the document is 62 not to provide a full-pledged protocol, but to show how the defined 63 framework and SDP elements can be combined together to design a CDP. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 69 3. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 3 70 4. Construction of a Repair Flow from Multiple Source Flows . . . 4 71 4.1. Example: Two Source Flows Protected by a Single Repair 72 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Reconstruction of Source Flows from Repair Flow(s) . . . . . . 10 74 5.1. Example: Multiple Source Flows Protected by a Single 75 Repair Flow . . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The Forward Error Correction (FEC) Framework (described in 85 [I-D.ietf-fecframe-framework]) and SDP Elements for FEC Framework 86 (described in [I-D.ietf-fecframe-sdp-elements]) together define 87 mechanisms sufficient enough to build an actual Content Delivery 88 Protocol (CDP) with FEC protection. Methods to convey FEC Framework 89 Configuration Information (described in 90 [I-D.ietf-fecframe-config-signaling]) on the other hand provides the 91 signaling protocols that may be used as part of CDP to communicate 92 FEC Scheme-Specific Information from FEC sender to a single as well 93 as multiple FEC receivers. This document aims at providing a 94 guideline on how the mechanisms defined in 95 [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-sdp-elements] 96 can be sufficiently used to design a CDP over a non-trivial scenario, 97 namely protection of multiple source flows with one or more repair 98 flows. 100 In particular, we provide clarifications and descriptions on how: 102 o source and repair flows may be uniquely identified, 104 o source blocks may be generated from one or more source flows, 106 o repair flows may be paired with the source flows, 108 o the receiver explicitly and implicitly identifies individual 109 flows, 111 o source blocks are regenerated at the receiver and the missing 112 source symbols in a source block are recovered. 114 2. Requirements Notation 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Definitions/Abbreviations 122 This document uses the following definitions. For further 123 definitions that apply to FEC Framework in general, see 124 [I-D.ietf-fecframe-framework]. 126 CDP: Content Delivery Protocol. 128 FEC: Forward Error Correction. 130 Source Flow: The packet flow or flows to which FEC protection is to 131 be applied. 133 Repair Flow: The packet flow or flows carrying FEC data. 135 Transport Protocol: The protocol used for transport of the source 136 data flow being protected. 138 FEC Scheme: A specification which defines the additional protocol 139 aspects required to use a particular FEC code with the FEC 140 framework. 142 Source Block: The group of source data packets which are to be FEC 143 protected as a single block. 145 Source FEC Payload ID: An FEC Payload ID specifically for use with 146 source packets. 148 Repair FEC Payload ID: An FEC Payload ID specifically for use with 149 repair packets. 151 4. Construction of a Repair Flow from Multiple Source Flows 153 At the sender side, CDP constructs the source blocks (SB) by 154 multiplexing transport payloads from multiple flows (See Figure 1 and 155 Figure 2). According to the FEC Framework, each source block is FEC 156 protected separately. Each source block is given to the specific FEC 157 encoder used within the CDP as input and as the outputs Explicit 158 Source FEC Payload ID, Repair FEC Payload ID, and Repair Payloads 159 corresponding to that source block are generated. Note that Explicit 160 Source FEC payload ID is optional and if CDP has implicit means of 161 constructing the source block at the sender/receiver (e.g., by using 162 any existing sequence numbers in the payload), the Explicit Source 163 FEC payload ID might not be output. 165 +------------+ 166 s_1 --------> | | 167 . Source | Source | +--------+ +--------+ +--------+ 168 . Flows | Block |=> ..|SB_(j+1)| | SB_j | |SB_(j-1)| .. 169 s_n --------> | Generation | +--------+ +--------+ +--------+ 170 +------------+ 172 Figure 1: Source Block generation for an FEC scheme 174 Figure 2 shows the structure of a source block. A CDP MUST clearly 175 specify which payload corresponds to which source flow and the length 176 of each payload. 178 <------------------ Source Block (SB) -------------------> 180 +-------...-----+-------...-----+- -+-------...-----+ 181 | Payload_1 | Payload_2 | . . . | Payload_n | 182 +-------...-----+-------...-----+- -+-------...-----+ 183 \______ _______|______ _______| |______ _______| 184 \/ \/ \/ 185 FID_1,Len_1 FID_2,Len_2 FID_n,Len_n 187 Figure 2: Structure of a Source Block 189 Flow ID (FID) value provides a unique short-hand identifier for the 190 source flows. FID is specified and associated with the possibly 191 wildcarded tuple of {Source IP Address, Destination IP Address, 192 Source Transport Port, Destination Transport Port, Transport 193 Protocol} in the SDP file. When wildcarded, certain fields in the 194 tuple are not needed for distinguishing the source flows. The tuple 195 is carried in the IP and transport headers of the source packets. 196 Since FID is utilized by the CDP and FEC scheme to distinguish 197 between the source packets, the tuple MUST have a one-to-one mapping 198 to a valid FID. This point will be clearer in the specific example 199 given later in this section. The length of FID must be a priori 200 fixed and known to both the receiver and sender. Alternatively, it 201 might be specified in the FEC-Scheme-Specific Information field in 202 the SDP element [I-D.ietf-fecframe-sdp-elements]. 204 The payload length (Len) information is needed to figure out how many 205 bits, bytes, or symbols (depending on the FEC scheme) from a 206 particular source flow are included in the source block. If the 207 payload is not an integer multiple of the specified symbol length, 208 the remaining portion is padded with zeros (See Figure 3 and 209 Figure 4). 211 +------+ 212 +--------+ +--------+ +--------+ | | -------> r_1 213 .. |SB_(j+1)| | SB_j | |SB_(j-1)| .. --> | FEC | Repair . 214 +--------+ +--------+ +--------+ |Scheme| Flows . 215 | | -------> r_k 216 +------+ 218 Figure 3: Repair flow generation by an FEC scheme 220 <------------------ Source Block (SB) -------------------> 221 | | | | | | 222 +-------...-----+-------...-----+- -+-------...-----+ | 223 | Payload_1 | Payload_2 | . . . | Payload_n |0| 224 +-------...-----+-------...-----+- -+-------...-----+ | 225 | | | | | | 226 | Symbol_1 | Symbol_2 | Symbol_3 | . . . | Symbol_m | 227 |<-------->|<-------->|<-------->| |<-------->| 229 +------+ 230 Symbol_1,..,Symbol_m => | FEC | => Symbol_u,..,Symbol_1 231 | Enc. | 232 +------+ 234 Figure 4: Repair flow payload generation 236 FEC schemes typically expect a source block of certain size, say m 237 symbols. Therefore, the FEC encoder divides each source block into m 238 symbols (with some padding if the source block is shorter than the 239 expected m symbols) and generates u repair symbols which are 240 functions of the m symbols in the original source block. The repair 241 symbols are grouped by the FEC scheme into repair payloads with each 242 repair payload assigned a Repair FEC Payload ID in order to associate 243 each repair payload with a particular source block at the receiver. 244 If the payloads in a given source block have sequence numbers that 245 can uniquely specify their location in the source block, an Explicit 246 Source FEC Payload ID may not be generated for these payloads. 247 Otherwise, Explicit Source FEC Payload IDs are generated for each 248 payload and indicate the order the payloads appear in the source 249 block. 251 Note that FID and length information are not actually transmitted 252 with the source payloads since both information can be gathered by 253 other means as it will be clear in the next sections. 255 4.1. Example: Two Source Flows Protected by a Single Repair Flow 257 In this section, we present an example of source flow and repair flow 258 generation by the CDP. We have two source flows with flow IDs of 0 259 and 1 to be protected by a single repair flow (See Figure 5). The 260 first source flow is multicast to 224.1.1.1 and the second source 261 flow is multicast to 224.1.1.2. Both flows use the port number 262 30000. The SDP description below states that the source flow defined 263 by the tuple {*,224.1.1.1,*,30000} is identified with FID=0 and the 264 source flow defined by the tuple {*,224.1.1.2,*,30000} is identified 265 with FID=1. The SDP description also states that the repair flow is 266 to be received at the multicast address of 224.1.2.1 and at port 267 30000. 269 SOURCE FLOWS | INSTANCE #1 270 0: Source Flow |_________| 2: Repair Flow 271 1: Source Flow | 273 Figure 5: Example: Two source flows and one repair flow 275 v=0 276 o=ali 1122334455 1122334466 IN IP4 fec.example.com 277 s=FEC Framework Examples 278 t=0 0 279 a=group:FEC S1 S2 R1 280 m=video 30000 RTP/AVP 100 281 c=IN IP4 224.1.1.1/127 282 a=rtpmap:100 MP2T/90000 283 a=fec-source-flow: id=0 284 a=mid:S1 285 m=video 30000 RTP/AVP 101 286 c=IN IP4 224.1.1.2/127 287 a=rtpmap:101 MP2T/90000 288 a=fec-source-flow: id=1 289 a=mid:S2 290 m=application 30000 udp/fec 291 c=IN IP4 224.1.2.1/127 292 a=fec-repair-flow: encoding-id=0; ss-fssi=5hu= 293 a=repair-window: 200 294 a=mid:R1 296 Figure 6 shows the first and the second source blocks (SB_1 and SB_2) 297 generated from these two source flows. In this example, SB_1 is of 298 length 10000 bytes. Suppose that the FEC scheme uses a symbol length 299 of 512 bytes. Then SB_1 can be divided into 20 symbols after padding 300 the source block for 240 bytes. Assume that the FEC scheme is 301 rate-2/3 erasure code, hence, it generates 10 repair symbols from 20 302 original symbols for SB_1. On the other hand, SB_2 is 7000-byte long 303 and can be divided into 14 symbols after padding 168 bytes. Using 304 the same encoder, suppose that 7 repair symbols are generated for 305 SB_2. 307 <-------- Source Block 1 --------> 308 +------------+-------------------+ 309 | $1 $2 $3 $4| #1 #2 #3 #4 #5 #6 | 0..00 310 +------------+-------------------+ 311 \__________________ __________________/ 312 \/ 313 @1 @2 @3 @4 @5 @6 @7 @8 @9 @10 315 <---- Source Block 2 ----> 316 +----------------+-------+ 317 | $5 $6 $7 $8 $9 | #7 #8 |0..00 318 +----------------+-------+ 319 \______________ _____________/ 320 \/ 321 @11 @12 @13 @14 @15 @16 @17 323 $: 1000-byte payload from source flow 1 324 #: 1000-byte payload from source flow 2 325 @: Repair symbol 327 Figure 6: Source block with two source flows 329 The information on the unit of payload length, FEC scheme, symbol 330 size, and coding rates can be specified in the FEC Scheme-Specific 331 Information (FSSI) field of the SDP element. If the values of the 332 payload lengths from each source flow and the order of appearance of 333 source flows in every source block are fixed during the session, 334 these values may be also provided in the FSSI field. To carry FSSI 335 information to the FEC receivers, one may utilize the signaling 336 methods described in [I-D.ietf-fecframe-config-signaling]. In our 337 example, we will consider the case where the ordering is fixed and 338 known both at the sender and the receiver, but the payload lengths 339 will be variable from one source block to another. We assume that 340 the payload of a source flow with an FID smaller than another flow's 341 FID precedes other payloads in a source block. 343 The FEC scheme gets the source blocks as input and generates the 344 parity blocks for each source block to protect the whole source 345 block. In the example, the repair payloads for SB_1 consist of 512- 346 byte symbols, denoted by @1 to @10. Similarly @11 to @17 constitute 347 the repair payloads for SB_2. The FEC scheme outputs the repair 348 payloads along with the Repair FEC Payload IDs. In our example, 349 Repair FEC Payload ID provides information on the source block 350 sequence number and the order the repair symbols are generated. For 351 instance @3 is the third FEC repair symbol for SB_1 and the three 352 tuple {@3, SB_1,3} can uniquely deliver this information. In our 353 example, the FEC scheme also provides Explicit Source FEC Payload IDs 354 that carry information to indicate which source symbols correspond to 355 which source block sequence number and its relative position in the 356 source block. For instance the two tuple {SB_2,2} can be attached to 357 $6 as the Explicit Source FEC Payload ID to indicate that $6 is 358 protected together with packets belonging to SB_2, and $6 is the 359 second payload in SB_2. 361 The source packets are generated from the source symbols by 362 concatenating consecutive symbols in one packet. There SHOULD NOT be 363 any fragmentation of a source symbol, e.g., symbols #7 and #8 can be 364 concatenated in one transport payload of 2000-bytes (The 365 implementation SHOULD make sure that the size of the resulting source 366 packet - payload plus the overhead - is not larger than the path 367 MTU), but one portion of symbol #7 SHOULD NOT be put in one source 368 packet and the remaining portion in another source packet. The 369 simplest implementation is to place each source symbol in a different 370 source packet as shown in Figure 7. 372 +------------------------------------+ 373 | IP header {224.1.1.1} | 374 +------------------------------------+ 375 | Transport header {30000} | 376 +------------------------------------+ 377 | Original Transport Payload {$6} | 378 +------------------------------------+ 379 | Source FEC Payload ID {SB_2,2} | 380 +------------------------------------+ 382 Figure 7: Example of a source packet 384 The repair packets are generated from the repair symbols belonging to 385 the same source block by grouping consecutive symbols in one packet. 386 There should not be any fragmentation of a repair symbol, e.g., 387 symbols @4, @5, and @6 can be concatenated in one transport payload 388 of 1536-bytes, but @6 SHOULD NOT be divided into smaller sub-symbols 389 and spread over multiple repair packets. The Repair FEC Payload ID 390 MUST carry sufficient information for the decoding process and in our 391 example indicating source block sequence number, length of each 392 source payload, and the order that the first parity block in a repair 393 packet is generated are sufficient. The exact header format of 394 Repair FEC Payload ID may be specified in the FSSI field of the SDP 395 element. In Figure 8 for instance, the repair symbols @4, @5, and @6 396 are concatenated together. The Payload ID {SB_1,4,4,6} states that 397 the repair symbols protect SB_1, the first repair symbol in the 398 payload is generated as the 4th symbol and the source block consists 399 of two source flows carrying 4 and 6 packets from each. 401 +------------------------------------+ 402 | IP header {224.1.2.1} | 403 +------------------------------------+ 404 | Transport header {30000} | 405 +------------------------------------+ 406 | Repair FEC Payload ID {SB_1,4,4,6} | 407 +------------------------------------+ 408 | Repair Symbols {@4,@5,@6} | 409 +------------------------------------+ 411 Figure 8: Example of a repair packet 413 5. Reconstruction of Source Flows from Repair Flow(s) 415 5.1. Example: Multiple Source Flows Protected by a Single Repair Flow 417 At the receiver, source flows 1 and 2 are received at 418 {224.1.1.1,30000} and {224.1.1.2,30000}, while the repair flow is 419 received at {224.1.2.1,30000}. The CDP can map these tuples to the 420 flow IDs using the SDP elements. Accordingly, the payloads received 421 at {224.1.1.1,30000} and {224.1.1.2,30000} are mapped to flow IDs 0 422 and 1, respectively. 424 The CDP passes the flow IDs and received payloads along with the 425 Explicit Source FEC Payload ID to the FEC scheme defined in the SDP 426 description. The CDP also passes the received repair packet payloads 427 and Repair FEC Payload ID to the FEC scheme. The FEC scheme can 428 construct the original source block with missing packets by using the 429 information given in the FEC Payload IDs. The FEC Repair Payload ID 430 provides the information that SB_1 has packets from two flows with 4 431 packets from the first one and 6 packets from the second one. Flow 432 IDs state that the packets from source flow 0 precedes the packets 433 from source flow 1. Explicit Source FEC Payload IDs on the other 434 hand provide the information about which source payload appears in 435 what order. Therefore, the FEC scheme can depict an source block 436 with exact locations of the missing packets. Figure 9 depicts the 437 case for SB_1. Since the original source block with missing packets 438 can be constructed at the decoder and the FEC scheme knows the coding 439 rate (e.g., it might be carried in the FSSI field in the SDP 440 description), a proper decoding operation can start as soon as the 441 repair symbols are provided to the FEC scheme. 443 <-------- Source Block 1 --------> 444 +------------+-------------------+ 445 | $1 $2 X X | #1 X #3 #4 #5 #6 | 446 +------------+-------------------+ 448 O: Symbols received from the source flow 1 for SB_1 449 #: Symbols received from the source flow 2 for SB_1 450 X: Lost source symbols 452 Figure 9: Source block regeneration 454 When the FEC scheme can recover any missing block while more repair 455 symbols are arriving, it provides the recovered blocks along with the 456 source flow IDs of the recovered blocks as outputs to the CDP. The 457 receiver knows how long to wait to repair the remaining missing 458 packets (e.g., specified by the 'repair-window' attribute in the SDP 459 description). After the associated timer expires, the CDP hands over 460 whatever could be recovered from the source flow to the application 461 layer and continues with processing the next source block. 463 6. Security Considerations 465 For the general security considerations related to the FEC Framework, 466 refer to [I-D.ietf-fecframe-framework]. There are no additional 467 security considerations that apply to this document. 469 7. IANA Considerations 471 There are no IANA related issues considered in this document. 473 8. Acknowledgments 475 The authors would like to thank the FEC Framework Design Team for 476 their inputs, suggestions and contributions. 478 9. Normative References 480 [I-D.ietf-fecframe-framework] 481 Watson, M., "Forward Error Correction (FEC) Framework", 482 draft-ietf-fecframe-framework-03 (work in progress), 483 October 2008. 485 [I-D.ietf-fecframe-sdp-elements] 486 Begen, A., "SDP Elements for FEC Framework", 487 draft-ietf-fecframe-sdp-elements-02 (work in progress), 488 November 2008. 490 [I-D.ietf-fecframe-config-signaling] 491 Asati, R., "Methods to convey FEC Framework Configuration 492 Information", draft-ietf-fecframe-config-signaling-01 493 (work in progress), November 2008. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, March 1997. 498 Authors' Addresses 500 Ulas C. Kozat 501 DoCoMo USA Labs 502 3240 Hillview Avenue 503 Palo Alto, CA 94304-1201 504 USA 506 Phone: +1 650 496 4739 507 Email: kozat@docomolabs-usa.com 509 Ali Begen 510 Cisco Systems 511 170 West Tasman Drive 512 San Jose, CA 95134 513 USA 515 Email: abegen@cisco.com