idnits 2.17.1 draft-roca-rmt-newfcast-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1310. 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 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 14, 2008) is 5737 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 1033 -- Looks like a reference, but probably isn't: '3' on line 1033 -- Looks like a reference, but probably isn't: '4' on line 1033 == Missing Reference: 'REF' is mentioned on line 1156, but not defined -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT V. Roca 3 Internet-Draft INRIA 4 Intended status: Experimental B. Adamson 5 Expires: January 15, 2009 Naval Research Laboratory 6 July 14, 2008 8 FCAST: Scalable Object Delivery for the ALC and NORM Protocols 9 draft-roca-rmt-newfcast-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 15, 2009. 36 Abstract 38 This document introduces the FCAST object (e.g., file) delivery 39 application on top of the ALC and NORM reliable multicast protocols. 40 FCAST is a highly scalable application that provides a reliable 41 object delivery service. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 47 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 48 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 5 49 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 50 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 51 4. FCAST Principles . . . . . . . . . . . . . . . . . . . . . . . 6 52 4.1. FCAST Content Delivery Service . . . . . . . . . . . . . . 6 53 4.2. Meta-Data Transmission . . . . . . . . . . . . . . . . . . 6 54 4.3. Meta-Data Content . . . . . . . . . . . . . . . . . . . . 7 55 4.4. Carousel Transmission . . . . . . . . . . . . . . . . . . 8 56 4.5. Carousel Instance Object . . . . . . . . . . . . . . . . . 9 57 4.6. FCAST Sender Behavior . . . . . . . . . . . . . . . . . . 10 58 4.7. FCAST Receiver Behavior . . . . . . . . . . . . . . . . . 11 59 4.8. FCAST Object Identification . . . . . . . . . . . . . . . 12 60 4.9. FCAST/ALC Additional Specificities . . . . . . . . . . . . 13 61 4.10. FCAST/NORM Additional Specificities . . . . . . . . . . . 13 62 5. FCAST Specifications . . . . . . . . . . . . . . . . . . . . . 14 63 5.1. Compound Object Header Format . . . . . . . . . . . . . . 14 64 5.2. Carousel Instance Object (CIO) Format . . . . . . . . . . 16 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 66 6.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 18 67 6.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 19 68 6.2.1. Access to Confidential Objects . . . . . . . . . . . . 19 69 6.2.2. Object Corruption . . . . . . . . . . . . . . . . . . 19 70 6.3. Attacks Against the Session Control Parameters and 71 Associated Building Blocks . . . . . . . . . . . . . . . . 20 72 6.3.1. Attacks Against the Session Description . . . . . . . 21 73 6.3.2. Attacks Against the FCAST CIO . . . . . . . . . . . . 21 74 6.3.3. Attacks Against the Object Meta-Data . . . . . . . . . 22 75 6.3.4. Attacks Against the ALC/LCT Parameters . . . . . . . . 22 76 6.3.5. Attacks Against the Associated Building Blocks . . . . 22 77 6.4. Other Security Considerations . . . . . . . . . . . . . . 23 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 83 Appendix A. FCAST in practice . . . . . . . . . . . . . . . . . . 25 84 Appendix B. FCAST Examples . . . . . . . . . . . . . . . . . . . 26 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 86 Intellectual Property and Copyright Statements . . . . . . . . . . 29 88 1. Introduction 90 This document introduces the FCAST reliable and scalable object 91 (e.g., file) delivery application. Two versions of FCAST exist: 93 o FCAST/ALC that relies on the Asynchronous Layer Coding (ALC) 94 [RMT-PI-ALC] and the Layered Coding Transport (LCT) [RMT-BB-LCT] 95 reliable multicast transport protocol, and 97 o FCAST/NORM that relies on the NACK-Oriented Reliable Multicast 98 (NORM) [RMT-PI-NORM] reliable multicast transport protocol. 100 Hereafter, the term FCAST denotes either FCAST/ALC or FCAST/NORM. 102 Depending on the target use case, the delivery service provided by 103 FCAST is more or less reliable. For instance, with FCAST/ALC used in 104 ON-DEMAND mode over a time period that largely exceeds the typical 105 download time, the service can be considered as fully reliable. 106 Similarly, when FCAST is used along with a session control 107 application that collects reception information and takes appropriate 108 corrective measures (e.g., a direct point-to-point retransmission of 109 missing packets, or a new multicast recovery session, see 110 Appendix A), then the service can be considered as fully reliable. 111 On the opposite, if FCAST operates in PUSH mode, then the service is 112 usually only partially reliable, and a receiver that is disconnected 113 during a sufficient time will perhaps not have the possibility to 114 download the object. 116 Depending on the target use case, the FCAST scalability is more or 117 less important. For instance, if FCAST/ALC is used on top of purely 118 unidirectional transport channels, with no feedback information at 119 all, which is the default mode of operation, then the scalability is 120 maximum since neither FCAST, nor ALC, UDP or IP generates any 121 feedback message. On the opposite, the FCAST/NORM scalability is 122 typically limited by NORM scalability itself. Similarly, if FCAST is 123 used along with a session control application that collects reception 124 information from the receivers, then this session control application 125 limits the scalability of the global object delivery system. This 126 situation can of course be mitigated by using a hierarchy of feedback 127 message aggregators or servers. The details of this is out of the 128 scope of the present document. 130 A design goal behind FCAST is to define a streamlined solution, in 131 order to enable lightweight implementations of the protocol stack, 132 and limit the operational processing and storage requirements. A 133 consequence of this choice is that FCAST cannot be considered as a 134 versatile application, capable of addressing all the possible use- 135 cases. On the opposite, FCAST has some intrinsic limitations. From 136 this point of view it differs from FLUTE [RMT-FLUTE] which favors 137 flexibility at the expense of some additional complexity. 139 A good example of the design choices that are meant to favor 140 simplicity, is the way FCAST manages the meta-data of an object: with 141 FCAST, the meta-data are simply prepended to the object. This 142 solution has many advantages in terms of simplicity as will be 143 described later on. But it also has an intrinsic limitation since it 144 does not enable a receiver to decide in advance, before beginning 145 reception of the object, whether the object is of interest or not. 146 Thus, if there is no out-of-band mechanism to enable receivers to 147 obtain the meta-data (or a subset) in advance, then all the objects 148 sent in the FCAST session should be of interest to all receivers. If 149 this is not the case, a receiver will probably waste time and 150 resources to receive and decode objects that will turn out to be 151 useless to him. 153 1.1. Applicability 155 FCAST is compatible with any congestion control protocol designed for 156 ALC/LCT or NORM. However, depending on the use-case, the data flow 157 generated by the FCAST application might not be constant, but instead 158 be bursty in nature. Similarly, depending on the use-case, an FCAST 159 session might be very short. Whether and how this will impact the 160 congestion control protocol is out of the scope of the present 161 document. 163 FCAST is compatible with any security mechanism designed for ALC/LCT 164 or NORM. The use of a security scheme is strongly RECOMMENDED (see 165 Section 6). 167 FCAST is compatible with any FEC scheme designed for ALC/LCT or NORM. 168 Whether FEC is used or not, and the kind of FEC scheme used, is to 169 some extent transparent to FCAST. 171 FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST 172 specification has any implication on the source or destination IP 173 address. 175 2. Requirements notation 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 3. Definitions, Notations and Abbreviations 183 3.1. Definitions 185 This document uses the following definitions: 187 FCAST/ALC denotes the FCAST application running on top of the ALC/ 188 LCT reliable transport protocol; 190 FCAST/NORM denotes the FCAST application running on top of the 191 NORM reliable transport protocol; 193 FCAST denotes either FCAST/ALC or FCAST/NORM; 195 Compound Object denotes an ALC or NORM transport object composed 196 of the Compound Object Header Section 5.1, including any meta-data 197 and the content of the original application object (e.g., a file); 199 Carousel denotes the compound object transmission system of an 200 FCAST sender; 202 Carousel Instance denotes a fixed set of registered compound 203 objects that are sent by the carousel during a certain number of 204 cycles. Whenever compound objects need to be added or removed, a 205 new Carousel Instance is defined; 207 Carousel Instance Object (CIO) denotes a specific object that 208 lists the compound objects that comprise a given carousel 209 instance; 211 Carousel Cycle denotes a transmission round within which all the 212 compound objects registered in the Carousel Instance are 213 transmitted a certain number of times. By default, compound 214 objects are transmitted once per cycle, but higher values are 215 possible, that might differ on a per-object basis; 217 The Transmission Object Identifier (TOI) refers the numeric 218 identifier associated to a specific object by the underlying 219 transport layer. In the case of ALC, this corresponds to the TOI 220 described in that specification while for the NORM specification 221 this corresponds to the NormObjectId described there. 223 3.2. Abbreviations 225 This document uses the following abbreviations: 227 +------------------+-------------------------------------+ 228 | Abbreviation | Definition | 229 +------------------+-------------------------------------+ 230 | CIO | Carousel Instance Object | 231 | FEC OTI | FEC Object Transmission Information | 232 | TOI | Transmission Object Identifier | 233 +------------------+-------------------------------------+ 235 4. FCAST Principles 237 4.1. FCAST Content Delivery Service 239 The basic goal of FCAST is to transmit objects to a group of 240 receivers in a reliable way. The receiver set MAY be restricted to a 241 single receiver or MAY include possibly a very large number of 242 receivers. FCAST is specified to support two forms of operation. 244 1. FCAST/ALC: where the FCAST application is meant to run on top of 245 the ALC/LCT reliable multicast transport protocol, and 247 2. FCAST/NORM: where the FCAST application is meant to run on top of 248 the NORM reliable multicast transport protocol. 250 This specification is designed such that both forms of operation 251 share as much commonality as possible. 253 While the choice of the underlying transport protocol (i.e., ALC or 254 NORM) and its parameters may limit the practical receiver group size, 255 nothing in FCAST itself limits it. The transmission might be fully 256 reliable, or only partially reliable depending upon the way ALC or 257 NORM is used (e.g., whether FEC encoding and/or NACK-based repair 258 requests are used or not), the way the FCAST carousel is used (e.g., 259 whether the objects are made available for a long time span or not), 260 and the way in which FCAST itself is employed (e.g., whether there is 261 a session control application that might automatically extend an 262 existing FCAST session until all receivers have received the 263 transmitted content). 265 FCAST is designed to be as self-sufficient as possible, in particular 266 in the way object meta-data is attached to object data content. 267 However, for some uses, meta-data MAY also be communicated by an out- 268 of-band mechanism that is out of the scope of the present document. 270 4.2. Meta-Data Transmission 272 FCAST usually carries meta-data elements by prepending them to the 273 object it refers to. As a result, a compound object is created that 274 is composed of a header followed by the original object content. 275 This header is itself composed of the meta-data as well as several 276 fields, for instance to indicate the boundaries between the various 277 parts of this compound object. 279 Attaching the meta-data to the object is an efficient solution, since 280 it guaranties that meta-data be received along with the associated 281 object, and it allows the transport of the meta-data to benefit from 282 any transport-layer FEC erasure protection of the compound object. 283 However a limit of this scheme, as such, is that a client does not 284 know the meta-data of an object before it begins receiving the object 285 and perhaps not until decoding the object completely depending upon 286 the transport protocol used and its particular FEC code type and 287 parameters. 289 However, this solution can be associated to another in-band (e.g., 290 via NORM INFO messages, Section 4.10) or out-of-band signaling 291 mechanism (Appendix A) in order to carry the whole meta-data (or a 292 subset of it) possibly ahead of time. 294 4.3. Meta-Data Content 296 The meta-data associated to an object can be composed of, but are not 297 limited to: 299 o Content-Location: the URI of the object, which gives the name and 300 location of the object; 302 o Content-Type: the MIME type of the object; 304 o Content-Length: the size of the initial object, before any content 305 encoding (if any). Note that this content length does not include 306 the meta-data nor the header of the compound object; 308 o Content-Encoding: the optional encoding of the object performed by 309 FCAST; 311 o Content-MD5: the MD5 message digest of the object in order to 312 check its integrity. Note that this digest is meant to protect 313 from transmission and processing errors, not from deliberate 314 attacks by an intelligent attacker. Note also that this digest 315 only protects the object, not the header, and therefore not the 316 meta-data; 318 o a digital signature for this object; 320 This list is not limited and new meta-data information can be added. 321 For instance, when dealing with very large objects (e.g., that 322 largely exceed the working memory of a receiver), it can be 323 interesting to split this object into several sub-objects. When a 324 file is split into several objects by FCAST, the meta-data includes: 326 o Fcast_Obj_Slice_Nb: the total number of slices. A value strictly 327 greater than 1 indicates that this object is the result of a split 328 of the original object; 330 o Fcast_Obj_Slice_Idx: the slice index (in the [0 .. SliceNb[ 331 interval); 333 o Fcast_Obj_Slice_Offset: the offset at which this slice starts 334 within the original object; 336 When meta-data elements are communicated out-of-band, in advance of 337 data transmission, the following pieces of information may also be 338 useful: 340 o TOI: the Transmission Object Identifier (TOI) of the object, in 341 order to enable a receiver to easily associate the meta-data to 342 the object for which he receives packets; 344 o FEC Object Transmission Information (FEC OTI). In this case the 345 FCAST sender does not need to use the optional EXT_FTI mechanism 346 of ALC or NORM protocols. 348 4.4. Carousel Transmission 350 A set of FCAST compound objects scheduled for transmission are 351 considered a logical "Carousel". A single "Carousel Instance" is 352 comprised of a fixed set of compound objects. Whenever the FCAST 353 application needs to add new objects to or remove old objects from 354 the transmission set, a new Carousel Instance is defined since the 355 set of compound objects changes. 357 For a given Carousel Instance, one or more transmission cycles are 358 possible. During each cycle, all of the compound objects comprising 359 the Carousel are sent. By default, each object is transmitted once 360 per cycle. However, in order to allow different levels of priority, 361 some objects MAY be transmitted more often that others during a 362 cycle, and/or benefit from higher FEC protection than others. This 363 can be the case for instance of the CIO objects (Section 4.5). For 364 some FCAST usage (e.g., a unidirectional "push" mode), a Carousel 365 Instance may have only a single transmission cycle. In other cases 366 there may be a large number of transmission cycles (e.g., such as an 367 "on-demand" mode where objects are made available for download during 368 a possibly very long period of time). 370 4.5. Carousel Instance Object 372 The FCAST sender MAY transmit an OPTIONAL Carousel Instance Object 373 (CIO). The CIO carries a list of the compound objects that are part 374 of a given Carousel Instance. The objects are listed using their 375 respective Transmission Object Identifiers (TOI). There is no 376 reserved TOI value for the CIO, since this object is regarded by ALC/ 377 LCT or NORM as a standard object. The nature of this object is 378 indicated by means of a specific meta-data field so that it can be 379 recognized and processed by the FCAST application as needed. 381 The CIO includes a Carousel Instance ID (CID) that identifies the 382 Carousel Instance. The CIO includes a "Complete" flag that is used 383 to indicate that no other modification to the enclosed list will be 384 done in the future. However the CIO does not describe the objects 385 themselves (i.e., there is no meta-data). Any objects that are not 386 incuded in the CIO list MUST NOT be considered as part of the current 387 Carousel Instance, even if they were part of any previous Carousel 388 Instances. 390 Note use of a CIO is NOT mandatory. If it is not used, then the 391 clients will progressively learn what files are part of the carousel 392 instance by receiving ALC or NORM packets with new TOIs. However use 393 of the CIO has several benefits: 395 o Receivers know when they can leave the session, i.e., when they 396 have received all the objects that are part of the delivery 397 session, thanks to the "Complete" flag; 399 o In case of a session with a dynamic set of objects, the sender can 400 reliably inform the receivers that some objects have been removed 401 from the carousel with the CIO. This solution is more robust than 402 the "Close Object flag (B)" of ALC/LCT since a client with an 403 intermittent connectivity might loose all the packets containing 404 this B flag. And while NORM provides a robust object cancellation 405 mechanism in the form of its NORM_CMD(SQUELCH) message in response 406 to receiver NACK repair requests, the use of the CIO provides an 407 additional means for receivers to learn of objects for which it is 408 futile to request repair 410 The decision of whether a CIO should be used, as well as how often 411 and when it should be sent, is left to the sender and depends on many 412 parameters, including the target use case and the session dynamics. 413 In case of an FCAST session in a strictly unidirectional, proactive 414 transmission mode (i.e., "push" mode), the CIO SHOULD be sent before 415 the objects (and repeated periodically during the Carousel Instance 416 transmission to enable late receivers to catch up, if this is 417 desired). In case of a highly dynamic FCAST session, a CIO will 418 probably be sent at the beginning of each new carousel instance, and 419 then periodically. The period of CIO repetition depends on the 420 desired maximum latency that could be experienced by late receivers 421 who joined the FCAST session in the middle of a carousel instance 422 transmission cycle, and therefore missed the initial CIO 423 transmission. These operational aspects are out of the scope of the 424 present document. 426 4.6. FCAST Sender Behavior 428 The following operations take place at a sender: 430 1. The user (or another application) selects a set of objects (e.g., 431 files) to deliver and submits them to the FCAST application. The 432 user also specifies how many times each object should be sent in 433 this carousel instance. Said differently, if objects have 434 similar lengths, assigning them a different number of 435 transmissions leads to define different transmission priorities 436 to each of them; 438 2. For each object, FCAST creates the compound object and registers 439 this latter in the carousel instance. 441 3. The user then informs FCAST when all the objects of the set have 442 been submitted. If no new object will be submitted later to 443 FCAST (i.e., if the session's content is now complete), the user 444 SHOULD also provide FCAST this information; 446 4. At this point, the FCAST application knows the full list of 447 compound objects that are part of the carousel instance and can 448 define a transmission schedule of these objects. This 449 specification does not mandate any transmission schedule scheme. 450 This is left to the developer within the provisions of the 451 underlying ALC or NORM protocol used. 453 5. The FCAST application will create a CIO as needed. If no new 454 object will be submitted, then the sender includes the "Complete" 455 keyword in any CIO created to inform the receivers that no object 456 in addition to the ones specified in this carousel instance will 457 be sent. While this specification RECOMMENDS that the sender 458 SHOULD send the CIO prior to the transmission of the associated 459 objects, it does not mandate if or how the CIO transmission 460 should be repeated during the associated carousel instance. This 461 is left to the developer; 463 6. The FCAST application then starts the carousel transmission, for 464 the number of cycles specified (which might be infinite), taking 465 into account the possible transmission specificities of each 466 object. The transmissions take place until: 468 * the desired number of transmission cycles has been reached, or 470 * the user wants to prematurely stop the transmissions, or 472 * the user wants to add one or several new objects to the 473 carousel, or on the opposite wants to remove old objects from 474 the carousel. In that case a new carousel instance must be 475 created. 477 Then continue at Step 1 above. 479 _*** Editor's note: Question: should a sender use a CIO with an 480 empty list of objects when he has reached the desired number of 481 cycles? Do we say "SHOULD" or "MUST"? Possible wording (to 482 discuss): When the desired number of transmission cycles has been 483 reached, after a small duration during which the user did not 484 submit any new object and did not tell FCAST to add some more 485 transmission cycles, the sender SHOULD create and send a CIO with 486 an empty list of objects. However, it should be noted that doing 487 so is sub-optimal if some of the objects are to be sent once again 488 latter on, since the receiver will destroy those objects that have 489 not been totally decoded upon receiving this CIO._ 491 4.7. FCAST Receiver Behavior 493 The following operations take place at an FCAST receiver: 495 1. The receiver joins the session and collects symbols; 497 2. As the header portion of compound objects are received (which may 498 be received before the entire object is received with some ALC/ 499 NORM transport configurations), the receiver processes the meta- 500 data and may choose to continue to receive the object content or 501 not; 503 3. When a compound object has been entirely received, the receiver 504 processes the header, retrieves the object meta-data, perhaps 505 decodes the meta-data, and processes the object accordingly; 507 4. When a CIO is received, which is indicated by the 'I' flag set in 508 the compound object header, the receiver decodes the CIO, and 509 retrieves the list of objects that are part of the current 510 carousel instance. This list is used to remove objects sent in a 511 previous carousel instance that might not have been totally 512 decoded. This list is also used to set up a new filter, since 513 all the received content for objects from the given sender that 514 are not part of this list SHOULD be immediately discarded; 516 5. 518 _*** Editor's note: there is an exception: the TOI for the 519 following CIO. This TOI is perhaps not yet known, but it MUST 520 NOT be filtered. This is where having a floating TOI for CIOs 521 makes things a bit more complex. How to address this problem 522 is TBD._ 524 6. When a receiver has received a CIO with the "Complete" flag set, 525 and has successfully received all the objects of the current 526 carousel instance, it can safely exit from the current FCAST 527 session; 529 4.8. FCAST Object Identification 531 FCAST objects are directly associated with the object-based transport 532 service that the ALC and NORM protocols provide. In each of these 533 protocols, messages containing transport object content are labeled 534 with a numeric transport object identifier (i.e., the ALC TOI and the 535 NORM _NormTransportId_). For purposes of this document, this 536 identifier in either case (ALC or NORM) is referred to as the TOI. 537 The FCAST Compound Object Header meta-data can include an attribute 538 that identifies the given object's TOI. Additionally, the CIO lists 539 objects for the applicable Carousel Instance by using the TOI. 541 In both NORM and ALC, it is possible that the transport 542 identification space may eventually wrap for very long-lived 543 sessions. This can possibly introduce some ambiguity in FCAST object 544 identification if a sender retains some older objects in newer 545 Carousel Instances with updated object sets. Thus, when an updated 546 object set for a new Carousel Instance transport identifiers that 547 exceed one-half of the TOI sequence space (or otherwise exceed the 548 sender repair window capability in the case of NORM) it may be 549 necessary to re-enqueue old objects within the Carousel with new TOI 550 to stay within transport identifier limits. To allow receivers to 551 properly combine new transport symbols for any olders objects with 552 newly-assigned TOIs to achieve reliable transfer, a mechanism is 553 required to equate the object(s) with new TOI with the older object 554 TOI. _This mechanism is TBD._ 556 _*** Editor's note: Perhaps a way to disambiguate possible 557 wrapping of TOI is by concatenation of the Carousel Instance Id 558 and TOI? And also provide a mechanism to equate an object with a 559 new TOI in a new Carousel Instance with an older TOI in an older 560 Carousel Instance if it represents the same content. This way the 561 transport object id could "move forward" as needed and receivers 562 could possibly combine symbols from the new transmission with the 563 older content. Vincent had a scheme that partially addressed this 564 notion in an email._ 566 4.9. FCAST/ALC Additional Specificities 568 There are no additional details or options for FCAST/ALC operation. 570 4.10. FCAST/NORM Additional Specificities 572 The NORM Protocol provides a few additional capabilities that can be 573 used to specifically support FCAST operation: 575 1. The NORM_INFO message for conveying "out-of-band" content with 576 respect to a given transport object MAY be used to provide the 577 FCAST compound object header and meta-data to the receiver group. 578 NORM's NACK-based repair request signaling allows for an object's 579 NORM_INFO content to be requested separately and more quickly 580 than the object's "in-band" data content that is typically 581 encoded using FEC. However, the limitation here is that the 582 Compound Object Header and its meta-data MUST fit within the byte 583 size limit defined by the NORM sender's configured "segment size" 584 (typically a little less than the network MTU). 586 2. The NORM_CMD(SQUELCH) messages used by the NORM protocol sender 587 to inform receivers of objects that have been canceled when 588 receivers make repair requests for such invalid objects. 590 3. NORM also supports an optional positive acknowledgment mechanism 591 that can be used for small-scale multicast receiver group sizes. 592 Also, it may be possible in some cases for the sender to infer, 593 after some period without receiving NACKs at the end of its 594 transmission that the receiver set has fully received the 595 transmitted content. In particular, if the sender completes its 596 end-of-transmission series of NORM_CMD(FLUSH) messages without 597 receiving repair requests from the group, it may have some 598 assurance that the receiver set has received the content prior to 599 that point. 601 Receivers automatically learn of the availability of NORM_INFO for a 602 given object from a flag in the NORM_DATA message header. When 603 NORM_INFO is used for FCAST/NORM operation, the NORM_INFO content 604 MUST contain the FCAST Compound Object Header and meta-data for that 605 object. In this case, the data content portion of the NORM transport 606 object is the original application object. When NORM_INFO is not 607 used for a given sender object (i.e., the corresponding NORM_DATA 608 header flag is not set), the NORM transport object data content sent 609 MUST contain the FCAST Compound Object Header unless this information 610 is signaled by another means (out of scope of this document) prior to 611 the carousel transmission. 613 It should also be noted that the NORM_INFO message header may carry 614 the EXT_FTI extension. The reliable delivery of the NORM_INFO 615 content allows the individual objects' FEC Transmission Information 616 to be provided to the receivers without burdening every packet (i.e. 617 NORM_DATA messages) with this additional, but important, content. 619 5. FCAST Specifications 621 This section details the technical aspects of FCAST. 623 5.1. Compound Object Header Format 625 In an FCAST session, its compound objects are constructed by 626 prepending the Compound Object Header including any meta-data content 627 as shown in Figure 1 before the original object data content. 628 0 1 2 3 629 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 |rsvd |I|MDE|MDF| Header Length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | | 634 | Object Meta-Data Content (optional, variable length) | 635 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | | Padding (optional) | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | | 639 . Object Data Content (optional, variable length) . 640 . . 641 . . 643 Figure 1: Compound Object Header with Meta-Data 645 The Compound Object Header fields are: 647 +------------+------------------------------------------------------+ 648 | Field | Description | 649 +------------+------------------------------------------------------+ 650 | I | 1-bit field that, when set to 1, indicates the | 651 | | object is a Carousel Instance Object (CIO). When | 652 | | set to 0, this field indicates that the transported | 653 | | object is a standard object. | 654 | Meta-Data | 2-bit field that defines the optional encoding of | 655 | Encoding | the Object Meta-Data Content field (see Section 7). | 656 | (MDEnc) | A plain text encoding is the default encoding and is | 657 | | associated value 0. A gzip encoding MAY be | 658 | | supported and is associated to value 1. Other | 659 | | encodings MAY be defined in the future. | 660 | Meta-Data | 2-bit field that defines the format of the object | 661 | Format | meta-data (see Section 7). An HTTP/1.1 | 662 | (MDFmt) | metainformation format [RFC2068] MUST be supported | 663 | | and is associated to value 0. Other formats (e.g., | 664 | | XML) MAY be defined in the future. | 665 | Header | 24-bit field indicating total length (in bytes) of | 666 | Length | all fields of the Compound Object Header, except the | 667 | | optional padding. A header length field set to | 668 | | value 4 means that there is no meta-data included. | 669 | | When this size is not multiple to 32 bits words, | 670 | | padding is added. It should be noted that the | 671 | | meta-data field maximum size is equal to 2^24 - 4 | 672 | | bytes. | 673 | Object | Optional, variable length field that contains the | 674 | Meta-Data | meta-data associated to the object, either in plain | 675 | | text or encoded, as specified by the MDEnc field. | 676 | | The Meta-Data is NULL-terminated plain text of the | 677 | | "TYPE" ":" "VALUE" "" format used in HTTP/1.1 | 678 | | for metainformation [RFC2068]. The various | 679 | | meta-data items can appear in any order. The | 680 | | associated string, when non empty, MUST be | 681 | | NULL-terminated. When no meta-data is communicated, | 682 | | this field MUST be empty. | 683 | Padding | Optional, variable length field of zero-value bytes | 684 | | to align start of object data content to 32-bit | 685 | | boundary. Padding is only used when the header | 686 | | length value, in bytes, is not multiple of 4. | 687 | Object | Data content of original object represented by this | 688 | Data | Compound Object. Note that the length of this | 689 | Content | content is the transported object size minus the | 690 | | Compound Object Header Length | 691 +------------+------------------------------------------------------+ 693 _*** Editor's note: Should we add a checksum to protect the header 694 itself? Since meta-data do not use an XML encoding, there is no 695 way to digitally sign it to check its integrity. A checksum could 696 offer some integrity guaranty (not security of course). _ 698 5.2. Carousel Instance Object (CIO) Format 700 The format of the CIO, which is a particular compound object, is 701 given in Figure 2. Because the CIO is transmitted as a special 702 compound object, the following CIO-specific meta-data entry is 703 defined: 705 o Fcast_CIO_complete: when set to 1, it indicates that no new 706 objects in addition to the ones whose TOI are specified in this 707 CIO, or the ones that have been specified in the previous CIO(s), 708 will be generated; 710 o Fcast_CIO_ID: this value identifies the carousel instance. It 711 starts from 0 and is incremented by 1 for each new carousel 712 instance. This entry is not mandatory since the TOI numbering of 713 the compound objects carrying a CIO can be used to identify the 714 latest CIO instance. However, this value can be useful to detect 715 possible gaps in the carousel instances, for instance caused by 716 long disconnection periods. It can also be usefull to avoid 717 problems when TOI wrapping to 0 takes place. 719 Additionaly, the following standard meta-data entries are often used: 721 o Content-Encoding: the optional encoding of the CIO object, by 722 FCAST. For instance: 723 Content-Encoding: gzip 724 indicates that the Object List field has been encoded with gzip 725 [RFC1952]. When set to 0, this flag indicates the the Object List 726 field is plain text. The support of gzip encoding is MANDATORY, 727 both for an FCAST sender and for an FCAST receiver 729 0 1 2 3 730 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 732 |rsvd |1|MDE|MDF| Header Length | | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h 734 | | d 735 | Object Meta-Data Content (optional, variable length) | r 736 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 737 | | Padding (optional) | v 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 739 . . | 740 . Object List (variable length) . O 741 . . b 742 . +-+-+-+-+-+-+-+-+ j 743 . | | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 746 Figure 2: Carousel Instance Object Format 748 The CIO fields are: 750 +------------+------------------------------------------------------+ 751 | Field | Description | 752 +------------+------------------------------------------------------+ 753 | Object | List of TOIs included in the current carousel | 754 | List | instance, in an exhaustive way. This list, whose | 755 | | format is defined below, can be either in plain text | 756 | | (if Z is not set) or gzip'ed (if Z is set). An | 757 | | empty list (0 length field) indicates that the | 758 | | current carousel instance does not include any | 759 | | object. | 760 +------------+------------------------------------------------------+ 762 The non-encoded (i.e., plain text) Object List is a NULL-terminated, 763 ASCII string containing the list of TOIs included in the current 764 carousel instance, specified either as the individual TOIs of each 765 object, or as TOI spans, or combinations of these. The format of the 766 ASCII string is a comma-separated list of individual "TOI" values or 767 "TOI_a-TOI_b" elements. This latter case means that all values 768 between TOI_a and TOI_b, inclusive, are part of the list. We further 769 require that TOI_a be strictly inferior to TOI_b. The ABNF 770 specification is the following: 772 cio-list = *(list-elem *( "," list-elem)) 773 list-elem = toi-value / toi-range 774 toi-value = 1*DIGIT 775 toi-range = toi-value "-" toi-value 776 ; additionally, the first toi-value MUST be 777 ; strictly inferior to the second toi-value 778 DIGIT = %x30-39 779 ; a digit between O and 9, inclusive 781 It is RECOMMENDED, for processing reasons, that all the TOI values in 782 the list be given in increasing order. However a receiver MUST be 783 able to handle non-monotonically increasing values. It is 784 RECOMMENDED, for processing reasons, that a given TOI value NOT be 785 included mutiple times in the list. 787 6. Security Considerations 789 6.1. Problem Statement 791 A content delivery system is potentially subject to attacks. Attacks 792 may target: 794 o the network (to compromise the routing infrastructure, e.g., by 795 creating congestion), 797 o the Content Delivery Protocol (CDP) (e.g., to compromise the 798 normal behavior of FCAST) or 800 o the content itself (e.g., to corrupt the objects being 801 transmitted). 803 These attacks can be launched either: 805 o against the data flow itself (e.g., by sending forged packets), 807 o against the session control parameters (e.g., by corrupting the 808 session description, the CIO, the object meta-data, or the ALC/LCT 809 control parameters), that are sent either in-band or out-of-band, 810 or 812 o against some associated building blocks (e.g., the congestion 813 control component). 815 In the following sections we provide more details on these possible 816 attacks and sketch some possible counter-measures. 818 6.2. Attacks Against the Data Flow 820 Let us consider attacks against the data flow first. At least, the 821 following types of attacks exist: 823 o attacks that are meant to give access to a confidential object 824 (e.g., in case of a non-free content) and 826 o attacks that try to corrupt the object being transmitted (e.g., to 827 inject malicious code within an object, or to prevent a receiver 828 from using an object, which is a kind of Denial of Service (DoS)). 830 6.2.1. Access to Confidential Objects 832 Access control to the object being transmitted is typically provided 833 by means of encryption. This encryption can be done over the whole 834 object (e.g., by the content provider, before submitting the object 835 to FCAST), or be done on a packet per packet basis (e.g., when IPSec/ 836 ESP is used [RFC4303]). If confidentiality is a concern, it is 837 RECOMMENDED that one of these solutions be used. 839 6.2.2. Object Corruption 841 Protection against corruptions (e.g., in case of forged packets) is 842 achieved by means of a content integrity verification/sender 843 authentication scheme. This service can be provided at the object 844 level, but in that case a receiver has no way to identify which 845 symbol(s) is(are) corrupted if the object is detected as corrupted. 846 This service can also be provided at the packet level. In this case, 847 after removing all corrupted packets, the file may be in some cases 848 recovered. Several techniques can provide this content integrity/ 849 sender authentication service: 851 o at the object level, the object can be digitally signed (with 852 public key cryptography), for instance by using RSASSA-PKCS1-v1_5 853 [RFC3447]. This signature enables a receiver to check the object 854 integrity, once this latter has been fully decoded. Even if 855 digital signatures are computationally expensive, this calculation 856 occurs only once per object, which is usually acceptable; 858 o at the packet level, each packet can be digitally signed. A major 859 limitation is the high computational and transmission overheads 860 that this solution requires (unless perhaps if Elliptic Curve 861 Cryptography (ECC) is used). To avoid this problem, the signature 862 may span a set of packets (instead of a single one) in order to 863 amortize the signature calculation. But if a single packets is 864 missing, the integrity of the whole set cannot be checked; 866 o at the packet level, a Group Message Authentication Code (MAC) 867 [RFC2104] scheme can be used, for instance by using HMAC-SHA-1 868 with a secret key shared by all the group members, senders and 869 receivers. This technique creates a cryptographically secured 870 digest of a packet that is sent along with the packet. The Group 871 MAC scheme does not create prohibitive processing load nor 872 transmission overhead, but it has a major limitation: it only 873 provides a group authentication/integrity service since all group 874 members share the same secret group key, which means that each 875 member can send a forged packet. It is therefore restricted to 876 situations where group members are fully trusted (or in 877 association with another technique as a pre-check); 879 o at the packet level, Timed Efficient Stream Loss-Tolerant 880 Authentication (TESLA) [RFC4082] is an attractive solution that is 881 robust to losses, provides a true authentication/integrity 882 service, and does not create any prohibitive processing load or 883 transmission overhead. Yet checking a packet requires a small 884 delay (a second or more) after its reception; 886 o at the packet level, IPSec/AH [RFC4302] (possibly associated to 887 IPSec/ ESP) can be used to protect all the packets being exchanged 888 in a session. 890 Techniques relying on public key cryptography (digital signatures and 891 TESLA during the bootstrap process, when used) require that public 892 keys be securely associated to the entities. This can be achieved by 893 a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by 894 pre-distributing securely the public keys of each group member. 896 Techniques relying on symmetric key cryptography (Group MAC) require 897 that a secret key be shared by all group members. This can be 898 achieved by means of a group key management protocol, or simply by 899 pre-distributing securely the secret key (but this manual solution 900 has many limitations). 902 It is up to the developer and deployer, who know the security 903 requirements and features of the target application area, to define 904 which solution is the most appropriate. In any case, whenever there 905 is any concern of the threat of file corruption, it is RECOMMENDED 906 that at least one of these techniques be used. 908 6.3. Attacks Against the Session Control Parameters and Associated 909 Building Blocks 911 Let us now consider attacks against the session control parameters 912 and the associated building blocks. The attacker has at least the 913 following opportunities to launch an attack: 915 o the attack can target the session description, 917 o the attack can target the FCAST CIO, 919 o the attack can target the meta-data of an object, 921 o the attack can target the ALC/LCT parameters, carried within the 922 LCT header or 924 o the attack can target the FCAST associated building blocks. 926 The latter one is particularly true with the multiple rate congestion 927 control protocol which may be required. 929 The consequences of these attacks are potentially serious, since they 930 can compromise the behavior of content delivery system or even 931 compromise the network itself. 933 6.3.1. Attacks Against the Session Description 935 An FCAST receiver may potentially obtain an incorrect Session 936 Description for the session. The consequence of this is that 937 legitimate receivers with the wrong Session Description are unable to 938 correctly receive the session content, or that receivers 939 inadvertently try to receive at a much higher rate than they are 940 capable of, thereby possibly disrupting other traffic in the network. 942 To avoid these problems, it is RECOMMENDED that measures be taken to 943 prevent receivers from accepting incorrect Session Descriptions. One 944 such measure is the sender authentication to ensure that receivers 945 only accept legitimate Session Descriptions from authorized senders. 946 How these measures are archived is outside the scope of this document 947 since this session description is usually carried out-of-band. 949 6.3.2. Attacks Against the FCAST CIO 951 Corrupting the FCAST CIO is one way to create a Denial of Service 952 attack. For example, the attacker removes legitimate object TOIs 953 from the list. 955 It is therefore RECOMMENDED that measures be taken to guarantee the 956 integrity and to check the sender's identity of the CIO. To that 957 purpose, one of the counter-measures mentioned above (Section 6.2.2) 958 SHOULD be used. These measures will either be applied on a packet 959 level, or globally over the whole CIO object. When there is no 960 packet level integrity verification scheme, it is RECOMMENDED to 961 digitally sign the CIO. 963 6.3.3. Attacks Against the Object Meta-Data 965 Corrupting the object meta-data is another way to create a Denial of 966 Service attack. For example, the attacker changes the MD5 sum 967 associated to a file. This possibly leads a receiver to reject the 968 files received, no matter whether the files have been correctly 969 received or not. When the meta-data are appended to the object, 970 corrupting the meta-data means that the compound object will be 971 corrupted. 973 It is therefore RECOMMENDED that measures be taken to guarantee the 974 integrity and to check the sender's identity of the compound object. 975 To that purpose, one of the counter-measures mentioned above 976 (Section 6.2.2) SHOULD be used. These measures will either be 977 applied on a packet level, or globally over the whole compound 978 object. When there is no packet level integrity verification scheme, 979 it is RECOMMENDED to digitally sign the compound object. 981 6.3.4. Attacks Against the ALC/LCT Parameters 983 By corrupting the ALC/LCT header (or header extensions) one can 984 execute attacks on the underlying ALC/LCT implementation. For 985 example, sending forged ALC packets with the Close Session flag (A) 986 set one can lead the receiver to prematurely close the session. 987 Similarly, sending forged ALC packets with the Close Object flag (B) 988 set one can lead the receiver to prematurely give up the reception of 989 an object. 991 It is therefore RECOMMENDED that measures be taken to guarantee the 992 integrity and to check the sender's identity of each ALC packet 993 received. To that purpose, one of the counter-measures mentioned 994 above (Section 6.2.2) SHOULD be used. 996 6.3.5. Attacks Against the Associated Building Blocks 998 Let us first focus on the congestion control building block that may 999 be used in the ALC session. A receiver with an incorrect or 1000 corrupted implementation of the multiple rate congestion control 1001 building block may affect the health of the network in the path 1002 between the sender and the receiver. That may also affect the 1003 reception rates of other receivers who joined the session. 1005 When congestion control building block is applied with FCAST, it is 1006 therefore RECOMMENDED that receivers be required to identify 1007 themselves as legitimate before they receive the Session Description 1008 needed to join the session. How receivers identify themselves as 1009 legitimate is outside the scope of this document. If authenticating 1010 a receiver does not prevent this latter to launch an attack, it will 1011 enable the network operator to identify him and to take counter- 1012 measures. 1014 When congestion control building block is applied with FCAST/ALC, it 1015 is also RECOMMENDED that a packet level authentication scheme be 1016 used, as explained in Section 6.2.2. Some of them, like TESLA, only 1017 provide a delayed authentication service, whereas congestion control 1018 requires a rapid reaction. It is therefore RECOMMENDED [2] that a 1019 receiver using TESLA quickly reduces its subscription level when the 1020 receiver believes that a congestion did occur, even if the packet has 1021 not yet been authenticated. Therefore TESLA will not prevent DoS 1022 attacks where an attacker makes the receiver believe that a 1023 congestion occurred. This is an issue for the receiver, but this 1024 will not compromise the network since no congestion actually 1025 occurred. Other authentication methods that do not feature this 1026 delayed authentication could be preferred, or a group MAC scheme 1027 could be used in parallel to TESLA to reduce the probability of this 1028 attack. 1030 6.4. Other Security Considerations 1032 Lastly, we note that the security considerations that apply to, and 1033 are described in, ALC [2], LCT [3] and FEC [4] also apply to FCAST as 1034 FCAST builds on those specifications. In addition, any security 1035 considerations that apply to any congestion control building block 1036 used in conjunction with FCAST also applies to FCAST. 1038 7. IANA Considerations 1040 This document requires a IANA registration for the following 1041 attributes: 1043 Object meta-data format (MDFmt): All implementations MUST support 1044 format 0 (default). 1046 +----------------------------------------+-------------+ 1047 | format name | Value | 1048 +----------------------------------------+-------------+ 1049 | as per HTTP/1.1 metainformation format | 0 (default) | 1050 +----------------------------------------+-------------+ 1052 Object Meta-Data Encoding (MDENC): All implementations MUST support 1053 value 0 (default). 1055 +------------+-------------+ 1056 | Name | Value | 1057 +------------+-------------+ 1058 | plain text | 0 (default) | 1059 | gzip | 1 | 1060 +------------+-------------+ 1062 8. Acknowledgments 1064 The authors would like to thank Toni Paila and Rod Walsh for their 1065 challenging comments throughout the design of FCAST. The authors are 1066 grateful to the authors of [ALC_00] for specifying the first version 1067 of FCAST/ALC. 1069 9. References 1071 9.1. Normative References 1073 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1074 Requirement Levels", BCP 14, RFC 2119, March 1997. 1076 [RMT-PI-ALC] 1077 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1078 Layered Coding (ALC) Protocol Instantiation", Work 1079 in Progress, November 2007. 1081 [RMT-BB-LCT] 1082 Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1083 Transport (LCT) Building Block", Work in Progress, 1084 February 2007. 1086 [RMT-PI-NORM] 1087 Adamson, B., Bormann, C., Handley, M., and J. Macker, 1088 "Negative-acknowledgment (NACK)-Oriented Reliable 1089 Multicast (NORM) Protocol", Work in Progress, May 2008. 1091 [RMT-FLUTE] 1092 Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, 1093 "FLUTE - File Delivery over Unidirectional Transport", 1094 Work in Progress, October 2007. 1096 9.2. Informative References 1098 [ALC_00] Luby, M., Gemmell, G., Vicisano, L., Crowcroft, J., and B. 1099 Lueckenhoff, "Asynchronous Layered Coding: a Scalable 1100 Reliable Multicast Protocol", 1101 draft-ietf-rmt-pi-alc-00.txt, March 2000. 1103 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1104 Randers-Pehrson, "GZIP file format specification version 1105 4.3", RFC 1952, May 1996. 1107 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1108 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1109 RFC 2068, January 1997. 1111 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1112 Hashing for Message Authentication", RFC 2104, 1113 February 1997. 1115 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1116 Standards (PKCS) #1: RSA Cryptography Specifications 1117 Version 2.1", RFC 3447, February 2003. 1119 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 1120 Briscoe, "Timed Efficient Stream Loss-Tolerant 1121 Authentication (TESLA): Multicast Source Authentication 1122 Transform Introduction", RFC 4082, June 2005. 1124 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1125 December 2005. 1127 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1128 RFC 4303, December 2005. 1130 Appendix A. FCAST in practice 1132 This section discusses how FCAST/ALC and FCAST/NORM can be used in 1133 practise. 1135 Out-of-band transmission of the object meta-data: In some use- 1136 cases, the meta-data (or a subset of them) will be communicated to 1137 the receivers by means of an out-of-band mechanism. In some use- 1138 cases, this out-of-band mechanism can itself be a dedicated FCAST 1139 session. It is also possible that the TOI of each object be known 1140 in advance (e.g., the TOI can be reserved). When this is the 1141 case, sending this TOI along with the meta-data makes it possible 1142 for a receiver to know in advance the meta-data associated to each 1143 object, which enables the end-user (or the terminal when a set of 1144 preferences or selection criteria have been filled) to filter the 1145 incoming packets and discard those associated to a non-desired 1146 object. 1148 SDP: The FCAST session parameters can be communicated in numerous 1149 ways. One of them consists in using the Session Description 1150 Protocol (SDP) [REF]. 1152 RoHC: In some situations, for instance in low-bandwidth wireless 1153 environments, it can be desirable to compress the various protocol 1154 headers (in our case IP, UDP, and possibly ALC/LCT) in a robust 1155 way. The Robust Header Compression (RoHC) family of compression 1156 schemes [REF] can be used to that purpose. 1158 Object aggregation: 1160 Session-level protocol: It is often desirable to use FCAST as a 1161 robust transport solution under the control of a session level 1162 protocol. This session level protocol can for instance have a 1163 certain knowledge of the set of receivers and perform receiver 1164 management operations. Examples of such operations include but 1165 are not limited to accepting new receivers in the group or 1166 performing cleaning operations after the departure of a receiver, 1167 managing security aspects like group keying or performing AAA. 1168 This session level protocol can also provide a higher level 1169 reliability framework, in order to make sure that each active 1170 receiver has received correctly a given object, and in case this 1171 is not the case, it can launch a recovery mechanism that might 1172 sometimes imply a direct point-to-point retransmission of missing 1173 symbols, or when the number of receivers concerned is higher than 1174 a certain threshold, a new multicast recovery session. 1176 Appendix B. FCAST Examples 1178 Figure 3 shows a compound object: 1180 0 1 2 3 1181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | 0 |0| 0 | 0 | 37 | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 . . 1186 . meta-data ASCII null terminated string (33 bytes) . 1187 . . 1188 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | | padding | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 . . 1192 . Object data . 1193 . . 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 Figure 3: Compound Object Example 1198 where the meta-data ASCII string, in HTTP/1.1 meta-information format 1199 contains: 1201 Content-Location: example.txt 1203 This string is 33 bytes long, including the NULL-termination 1204 character. There is no gzip encoding of the meta-data (Z=0) and 1205 there is no Content-Length information either since this length can 1206 easily be calculated by the receiver as the FEC OTI transfer length 1207 minus the header length. 1209 Figure 4 shows a compound object without any meta-data: 1210 0 1 2 3 1211 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | 0 |0| 0 | 0 | 4 | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 . . 1216 . Object data . 1217 . . 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 Figure 4: Compound Object Example with no Meta-Data. 1222 The fact there is no meta-data is indicated by the value 3 of the 1223 Header Length field. 1225 Figure 5 shows an example CIO object, in the case of a static FCAST 1226 session, i.e., a session where the set of objects is set once and for 1227 all. 1229 0 1 2 3 1230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | 0 |1| 0 | 0 | 4 | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 . . 1235 . Object List string . 1236 . . 1237 . +-+-+-+-+-+-+-+-+ 1238 . | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 Figure 5: Example of CIO, in case of a static session. 1243 The object list contains the following string: 1245 1,2,3,100-104,200-203,299 1247 There are therefore a total of 3+5+4+1 = 13 objects in the carousel 1248 instance, and therefore in the FCAST session. There is no meta-data 1249 associated to this CIO. The session being static the sender did not 1250 feel the necessity to carry a Carousel Instance ID meta-data. 1252 Authors' Addresses 1254 Vincent Roca 1255 INRIA 1256 655, av. de l'Europe 1257 Inovallee; Montbonnot 1258 ST ISMIER cedex 38334 1259 France 1261 Email: vincent.roca@inria.fr 1262 URI: http://planete.inrialpes.fr/~roca/ 1264 Brian Adamson 1265 Naval Research Laboratory 1266 Washington, DC 20375 1267 USA 1269 Email: adamson@itd.nrl.navy.mil 1270 URI: http://cs.itd.nrl.navy.mil 1272 Full Copyright Statement 1274 Copyright (C) The IETF Trust (2008). 1276 This document is subject to the rights, licenses and restrictions 1277 contained in BCP 78, and except as set forth therein, the authors 1278 retain all their rights. 1280 This document and the information contained herein are provided on an 1281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1283 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1284 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1285 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1288 Intellectual Property 1290 The IETF takes no position regarding the validity or scope of any 1291 Intellectual Property Rights or other rights that might be claimed to 1292 pertain to the implementation or use of the technology described in 1293 this document or the extent to which any license under such rights 1294 might or might not be available; nor does it represent that it has 1295 made any independent effort to identify any such rights. Information 1296 on the procedures with respect to rights in RFC documents can be 1297 found in BCP 78 and BCP 79. 1299 Copies of IPR disclosures made to the IETF Secretariat and any 1300 assurances of licenses to be made available, or the result of an 1301 attempt made to obtain a general license or permission for the use of 1302 such proprietary rights by implementers or users of this 1303 specification can be obtained from the IETF on-line IPR repository at 1304 http://www.ietf.org/ipr. 1306 The IETF invites any interested party to bring to its attention any 1307 copyrights, patents or patent applications, or other proprietary 1308 rights that may cover technology that may be required to implement 1309 this standard. Please address the information to the IETF at 1310 ietf-ipr@ietf.org.