idnits 2.17.1 draft-ietf-rmt-pi-alc-revised-04.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 988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1012. 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If more than one object is to be carried within a session then the Transmission Object Identifier (TOI) MUST be used in the LCT header to identify which packets are to be associated with which objects. In this case the receiver MUST use the TOI to associate received packets with objects. The TOI is scoped by the IP address of the sender and the TSI, i.e., the TOI is scoped by the session. The TOI for each object is REQUIRED to be unique within a session, but MAY NOT be unique across sessions. Furthermore, the same object MAY have a different TOI in different sessions. The mapping between TOIs and objects carried in a session is outside the scope of this document. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: All senders and receivers implementing ALC MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to parse its content. The EXT_NOP and EXT_AUTH LCT Header Extensions are defined in [I-D.ietf-rmt-bb-lct-revised] -- 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 (February 22, 2007) is 6271 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2026' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'HOL2001' is defined on line 919, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-rmt-bb-lct-revised-04 == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-04 ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Downref: Normative reference to an Informational RFC: RFC 2357 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Experimental RFC: RFC 2974 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 3450 (Obsoleted by RFC 5775) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast Transport (RMT) Luby 3 Working Group Watson 4 Internet-Draft Vicisano 5 Obsoletes: 3450 (if approved) Digital Fountain 6 Intended status: Standards Track February 22, 2007 7 Expires: August 26, 2007 9 Asynchronous Layered Coding (ALC) Protocol Instantiation 10 draft-ietf-rmt-pi-alc-revised-04 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 August 26, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes the Asynchronous Layered Coding (ALC) 44 protocol, a massively scalable reliable content delivery protocol. 45 Asynchronous Layered Coding combines the Layered Coding Transport 46 (LCT) building block, a multiple rate congestion control building 47 block and the Forward Error Correction (FEC) building block to 48 provide congestion controlled reliable asynchronous delivery of 49 content to an unlimited number of concurrent receivers from a single 50 sender. This document obsoletes RFC3450. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Delivery service models . . . . . . . . . . . . . . . . . 4 56 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Environmental Requirements and Considerations . . . . . . 5 58 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6 59 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7 60 2.2. Multiple rate congestion control building block . . . . . 9 61 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 9 62 2.4. Session Description . . . . . . . . . . . . . . . . . . . 11 63 2.5. Packet authentication building block . . . . . . . . . . . 12 64 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14 65 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 15 66 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 15 67 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 16 68 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 17 69 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 73 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 24 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 9.1. Normative references . . . . . . . . . . . . . . . . . . . 25 76 9.2. Informative references . . . . . . . . . . . . . . . . . . 25 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 78 Intellectual Property and Copyright Statements . . . . . . . . . . 28 80 1. Introduction 82 This document describes a massively scalable reliable content 83 delivery protocol, Asynchronous Layered Coding (ALC), for multiple 84 rate congestion controlled reliable content delivery. The protocol 85 is specifically designed to provide massive scalability using IP 86 multicast as the underlying network service. Massive scalability in 87 this context means the number of concurrent receivers for an object 88 is potentially in the millions, the aggregate size of objects to be 89 delivered in a session ranges from hundreds of kilobytes to hundreds 90 of gigabytes, each receiver can initiate reception of an object 91 asynchronously, the reception rate of each receiver in the session is 92 the maximum fair bandwidth available between that receiver and the 93 sender, and all of this can be supported using a single sender. 95 Because ALC is focused on reliable content delivery, the goal is to 96 deliver objects as quickly as possible to each receiver while at the 97 same time remaining network friendly to competing traffic. Thus, the 98 congestion control used in conjunction with ALC should strive to 99 maximize use of available bandwidth between receivers and the sender 100 while at the same time backing off aggressively in the face of 101 competing traffic. 103 The sender side of ALC consists of generating packets based on 104 objects to be delivered within the session and sending the 105 appropriately formatted packets at the appropriate rates to the 106 channels associated with the session. The receiver side of ALC 107 consists of joining appropriate channels associated with the session, 108 performing congestion control by adjusting the set of joined channels 109 associated with the session in response to detected congestion, and 110 using the packets to reliably reconstruct objects. All information 111 flow in an ALC session is in the form of data packets sent by a 112 single sender to channels that receivers join to receive data. 114 ALC does specify the Session Description needed by receivers before 115 they join a session, but the mechanisms by which receivers obtain 116 this required information is outside the scope of ALC. An 117 application that uses ALC may require that receivers report 118 statistics on their reception experience back to the sender, but the 119 mechanisms by which receivers report back statistics is outside the 120 scope of ALC. In general, ALC is designed to be a minimal protocol 121 instantiation that provides reliable content delivery without 122 unnecessary limitations to the scalability of the basic protocol. 124 This document is a product of the IETF RMT WG and follows the general 125 guidelines provided in [RFC3269]. 127 RFC3450 [RFC3450], which is obsoleted by this document, contained a 128 previous versions of the protocol. RFC3450 was published in the 129 "Experimental" category. It was the stated intent of the RMT working 130 group to re-submit these specifications as an IETF Proposed Standard 131 in due course. 133 This Proposed Standard specification is thus based on and backwards 134 compatible with the protocol defined in RFC3450 [RFC3450] updated 135 according to accumulated experience and growing protocol maturity 136 since its original publication. Said experience applies both to this 137 specification itself and to congestion control strategies related to 138 the use of this specification. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in BCP 14, [RFC2119]. 144 1.1. Delivery service models 146 ALC can support several different reliable content delivery service 147 models as described in [I-D.ietf-rmt-bb-lct-revised]. 149 1.2. Scalability 151 Massive scalability is a primary design goal for ALC. IP multicast 152 is inherently massively scalable, but the best effort service that it 153 provides does not provide session management functionality, 154 congestion control or reliability. ALC provides all of this on top 155 of IP multicast without sacrificing any of the inherent scalability 156 of IP multicast. ALC has the following properties: 158 o To each receiver, it appears as if though there is a dedicated 159 session from the sender to the receiver, where the reception rate 160 adjusts to congestion along the path from sender to receiver. 162 o To the sender, there is no difference in load or outgoing rate if 163 one receiver is joined to the session or a million (or any number 164 of) receivers are joined to the session, independent of when the 165 receivers join and leave. 167 o No feedback packets are required from receivers to the sender. 169 o Almost all packets in the session that pass through a bottleneck 170 link are utilized by downstream receivers, and the session shares 171 the link with competing flows fairly in proportion to their 172 utility. 174 Thus, ALC provides a massively scalable content delivery transport 175 that is network friendly. 177 ALC intentionally omits any application specific features that could 178 potentially limit its scalability. By doing so, ALC provides a 179 minimal protocol that is massively scalable. Applications may be 180 built on top of ALC to provide additional features that may limit the 181 scalability of the application. Such applications are outside the 182 scope of this document. 184 1.3. Environmental Requirements and Considerations 186 All of the environmental requirements and considerations that apply 187 to the LCT building block [I-D.ietf-rmt-bb-lct-revised], the FEC 188 building block [I-D.ietf-rmt-fec-bb-revised], the multiple rate 189 congestion control building block and to any additional building 190 blocks that ALC uses also apply to ALC. 192 One issues that is specific to ALC with respect to the Any- Source 193 Multicast (ASM) model of IP multicast as defined in RFC 1112 194 [RFC1112] is the way the multiple rate congestion control building 195 block interacts with ASM. The congestion control building block may 196 use the measured difference in time between when a join to a channel 197 is sent and when the first packet from the channel arrives in 198 determining the receiver reception rate. The congestion control 199 building block may also uses packet sequence numbers per channel to 200 measure losses, and this is also used to determine the receiver 201 reception rate. These features raise two concerns with respect to 202 ASM: The time difference between when the join to a channel is sent 203 and when the first packet arrives can be significant due to the use 204 of Rendezvous Points (RPs) and the MSDP protocol, and packets can be 205 lost in the switch over from the (*,G) join to the RP and the (S,G) 206 join directly to the sender. Both of these issues could potentially 207 substantially degrade the reception rate of receivers. To ameliorate 208 these concerns, it is RECOMMENDED that the RP be as close to the 209 sender as possible. SSM does not share these same concerns. For a 210 fuller consideration of these issues, consult the multiple rate 211 congestion control building block. 213 2. Architecture Definition 215 ALC uses the LCT building block [I-D.ietf-rmt-bb-lct-revised] to 216 provide in-band session management functionality. ALC uses a 217 multiple rate congestion control building block that is compliant 218 with [RFC2357] to provide congestion control that is feedback free. 219 Receivers adjust their reception rates individually by joining and 220 leaving channels associated with the session. ALC uses the FEC 221 building block [I-D.ietf-rmt-fec-bb-revised] to provide reliability. 222 The sender generates encoding symbols based on the object to be 223 delivered using FEC codes and sends them in packets to channels 224 associated with the session. Receivers simply wait for enough 225 packets to arrive in order to reliably reconstruct the object. Thus, 226 there is no request for retransmission of individual packets from 227 receivers that miss packets in order to assure reliable reception of 228 an object, and the packets and their rate of transmission out of the 229 sender can be independent of the number and the individual reception 230 experiences of the receivers. 232 The definition of a session for ALC is the same as it is for LCT. An 233 ALC session comprises multiple channels originating at a single 234 sender that are used for some period of time to carry packets 235 pertaining to the transmission of one or more objects that can be of 236 interest to receivers. Congestion control is performed over the 237 aggregate of packets sent to channels belonging to a session. The 238 fact that an ALC session is restricted to a single sender does not 239 preclude the possibility of receiving packets for the same objects 240 from multiple senders. However, each sender would be sending packets 241 to a a different session to which congestion control is individually 242 applied. Although receiving concurrently from multiple sessions is 243 allowed, how this is done at the application level is outside the 244 scope of this document. 246 ALC is a protocol instantiation as defined in [RFC3048]. This 247 document describes version 1 of ALC which MUST use version 1 of LCT 248 described in [I-D.ietf-rmt-bb-lct-revised]. Like LCT, ALC is 249 designed to be used with the IP multicast network service. This 250 specification defines ALC as payload of the UDP transport protocol 251 [RFC0768] that supports IP multicast delivery of packets. Future 252 versions of this specification, or companion documents may extend ALC 253 to use the IP network layer service directly. ALC could be used as 254 the basis for designing a protocol that uses a different underlying 255 network service such as unicast UDP, but the design of such a 256 protocol is outside the scope of this document. 258 An ALC packet header immediately follows the UDP header and consists 259 of the default LCT header that is described in 260 [I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is 261 described in [I-D.ietf-rmt-fec-bb-revised]. The Congestion Control 262 Information field within the LCT header carries the required 263 Congestion Control Information that is described in the multiple rate 264 congestion control building block specified that is compliant with 265 [RFC2357]. The packet payload that follows the ALC packet header 266 consists of encoding symbols that are identified by the FEC Payload 267 ID as described in [I-D.ietf-rmt-fec-bb-revised]. 269 Each receiver is required to obtain a Session Description before 270 joining an ALC session. As described later, the Session Description 271 includes out-of-band information required for the LCT, FEC and the 272 multiple rate congestion control building blocks. The FEC Object 273 Transmission Information specified in the FEC building block 274 [I-D.ietf-rmt-fec-bb-revised] required for each object to be received 275 by a receiver can be communicated to a receiver either out-of-band or 276 in-band using a Header Extension. The means for communicating the 277 Session Description and the FEC Object Transmission Information to a 278 receiver is outside the scope of this document. 280 2.1. LCT building block 282 LCT requires receivers to be able to uniquely identify and 283 demultiplex packets associated with an LCT session, and ALC inherits 284 and strengthens this requirement. A Transport Session Identifier 285 (TSI) MUST be associated with each session and MUST be carried in the 286 LCT header of each ALC packet. The TSI is scoped by the sender IP 287 address, and the (sender IP address, TSI) pair MUST uniquely identify 288 the session. 290 The LCT header contains a Congestion Control Information (CCI) field 291 that MUST be used to carry the Congestion Control Information from 292 the specified multiple rate congestion control protocol. There is a 293 field in the LCT header that specifies the length of the CCI field, 294 and the multiple rate congestion control building block MUST uniquely 295 identify a format of the CCI field that corresponds to this length. 297 The LCT header contains a Codepoint field that MAY be used to 298 communicate to a receiver the settings for information that may vary 299 during a session. If used, the mapping between settings and 300 Codepoint values is to be communicated in the Session Description, 301 and this mapping is outside the scope of this document. For example, 302 the FEC Encoding ID that is part of the FEC Object Transmission 303 Information as specified in the FEC building block 304 [I-D.ietf-rmt-fec-bb-revised] could vary for each object carried in 305 the session, and the Codepoint value could be used to communicate the 306 FEC Encoding ID to be used for each object. The mapping between FEC 307 Encoding IDs and Codepoints could be, for example, the identity 308 mapping. 310 If more than one object is to be carried within a session then the 311 Transmission Object Identifier (TOI) MUST be used in the LCT header 312 to identify which packets are to be associated with which objects. 313 In this case the receiver MUST use the TOI to associate received 314 packets with objects. The TOI is scoped by the IP address of the 315 sender and the TSI, i.e., the TOI is scoped by the session. The TOI 316 for each object is REQUIRED to be unique within a session, but MAY 317 NOT be unique across sessions. Furthermore, the same object MAY have 318 a different TOI in different sessions. The mapping between TOIs and 319 objects carried in a session is outside the scope of this document. 321 If only one object is carried within a session then the TOI MAY be 322 omitted from the LCT header. 324 The LCT header from version 1 of the LCT building block 325 [I-D.ietf-rmt-bb-lct-revised] MUST be used. 327 The LCT Header includes a two-bit Protocol Specific Indication (PSI) 328 field in bits 6 and 7 of the first word of the LCT header. These two 329 bits are used by ALC as follows: 331 0 1 2 3 332 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 333 +-+-+ 334 ...|A|B|... 335 +-+-+ 337 Figure 1: PSI bits within LCT Headder 339 PSI bit A - Source Packet Indicator (SPI) 341 PSI bit B - Reserved 343 The Source Packet Indicator is used with systematic FEC Schemes which 344 define a different FEC Payload ID format for packets containing only 345 source data compared to the FEC Payload ID format for packets 346 containing repair data. For such FEC Schemes, then the SPI MUST be 347 set to 1 when the FEC Payload ID format for packets containing only 348 source data is used and the SPI MUST be set to zero, when the FEC 349 Payload ID for packerts containing repair data is used. In the case 350 of FEC Schemes which define only a single FEC Payload ID format, then 351 the SPI MUST be set to zero by the sender and MUST be ignored by the 352 receiver. 354 Support of two FEC Payload ID formats allows FEC Payload ID 355 information which is only of relevance when FEC decoding is to be 356 performed to be provided in the FEC Payload ID format for packets 357 containing repair data. This information need not be processed by 358 receivers which do not perform FEC decoding (either because no FEC 359 decoding is required or because the receiver does not support FEC 360 decoding). 362 2.2. Multiple rate congestion control building block 364 Implementors of ALC MUST implement a multiple rate feedback-free 365 congestion control building block that is in accordance to [RFC2357]. 366 Congestion control MUST be applied to all packets within a session 367 independently of which information about which object is carried in 368 each packet. Multiple rate congestion control is specified because 369 of its suitability to scale massively and because of its suitability 370 for reliable content delivery. The multiple rate congestion control 371 building block MUST specify in-band Congestion Control Information 372 (CCI) that MUST be carried in the CCI field of the LCT header. The 373 multiple rate congestion control building block MAY specify more than 374 one format, but it MUST specify at most one format for each of the 375 possible lengths 32, 64, 96 or 128 bits. The value of C in the LCT 376 header that determines the length of the CCI field MUST correspond to 377 one of the lengths for the CCI defined in the multiple rate 378 congestion control building block, this length MUST be the same for 379 all packets sent to a session, and the CCI format that corresponds to 380 the length as specified in the multiple rate congestion control 381 building block MUST be the format used for the CCI field in the LCT 382 header. 384 When using a multiple rate congestion control building block a sender 385 sends packets in the session to several channels at potentially 386 different rates. Then, individual receivers adjust their reception 387 rate within a session by adjusting which set of channels they are 388 joined to at each point in time depending on the available bandwidth 389 between the receiver and the sender, but independent of other 390 receivers. 392 2.3. FEC building block 394 The FEC building block [I-D.ietf-rmt-fec-bb-revised] provides 395 reliable object delivery within an ALC session. Each object sent in 396 the session is independently encoded using FEC codes as described in 397 [RFC3453], which provide a more in-depth description of the use of 398 FEC codes in reliable content delivery protocols. All packets in an 399 ALC session MUST contain an FEC Payload ID in a format that is 400 compliant with the FEC Scheme in use. The FEC Payload ID uniquely 401 identifies the encoding symbols that constitute the payload of each 402 packet, and the receiver MUST use the FEC Payload ID to determine how 403 the encoding symbols carried in the payload of the packet were 404 generated from the object as described in the FEC building block. 406 As described in [I-D.ietf-rmt-fec-bb-revised], a receiver is REQUIRED 407 to obtain the FEC Object Transmission Information for each object for 408 which data packets are received from the session. In the context of 409 ALC, the FEC Object Transmission Information includes: 411 o The FEC Encoding ID. 413 o If an Under-Specified FEC Encoding ID is used then the FEC 414 Instance ID associated with the FEC Encoding ID. 416 o For each object in the session, the transfer length of the object 417 in bytes. 419 Additional FEC Object Transmission Information may be required 420 depending on the FEC Scheme that is used (identified by the FEC 421 Encoding ID). 423 Some of the FEC Object Transmission Information MAY be implicit based 424 on the FEC Scheme and/or implementation. As an example, source block 425 lengths may be derived by a fixed algorithm from the object length. 426 As another example, it may be that all source blocks are the same 427 length and this is what is passed out-of-band to the receiver. As 428 another example, it could be that the full sized source block length 429 is provided and this is the length used for all but the last source 430 block, which is calculated based on the full source block length and 431 the object length. As another example, it could be that the same FEC 432 Encoding ID and FEC Instance ID are always used for a particular 433 application and thus the FEC Encoding ID and FEC Instance ID are 434 implicitly defined. 436 Sometimes the objects that will be sent in a session are completely 437 known before the receiver joins the session, in which case the FEC 438 Object Transmission Information for all objects in the session can be 439 communicated to receivers before they join the session. At other 440 times the objects may not know when the session begins, or receivers 441 may join a session in progress and may not be interested in some 442 objects for which transmission has finished, or receivers may leave a 443 session before some objects are even available within the session. 444 In these cases, the FEC Object Transmission Information for each 445 object may be dynamically communicated to receivers at or before the 446 time packets for the object are received from the session. This may 447 be accomplished using either an out-of-band mechanism, in-band using 448 the Codepoint field or a Header Extension, or any combination of 449 these methods. How the FEC Object Transmission Information is 450 communicated to receivers is outside the scope of this document. 452 If packets for more than one object are transmitted within a session 453 then a Transmission Object Identifier (TOI) that uniquely identifies 454 objects within a session MUST appear in each packet header. Portions 455 of the FEC Object Transmission Information could be the same for all 456 objects in the session, in which case these portions can be 457 communicated to the receiver with an indication that this applies to 458 all objects in the session. These portions may be implicitly 459 determined based on the application, e.g., an application may use the 460 same FEC Encoding ID for all objects in all sessions. If there is a 461 portion of the FEC Object Transmission Information that may vary from 462 object to object and if this FEC Object Transmission Information is 463 communicated to a receiver out-of-band then the TOI for the object 464 MUST also be communicated to the receiver together with the 465 corresponding FEC Object Transmission Information, and the receiver 466 MUST use the corresponding FEC Object Transmission Information for 467 all packets received with that TOI. How the TOI and corresponding 468 FEC Object Transmission Information is communicated out-of-band to 469 receivers is outside the scope of this document. 471 It is also possible that there is a portion of the FEC Object 472 Transmission Information that may vary from object to object that is 473 carried in-band, for example in the CodePoint field or in Header 474 Extensions. How this is done is outside the scope of this document. 475 In this case the FEC Object Transmission Information is associated 476 with the object identified by the TOI carried in the packet. 478 2.4. Session Description 480 The Session Description that a receiver is REQUIRED to obtain before 481 joining an ALC session MUST contain the following information: 483 o The multiple rate congestion control building block to be used for 484 the session; 486 o The sender IP address; 488 o The number of channels in the session; 490 o The address and port number used for each channel in the session; 492 o The Transport Session ID (TSI) to be used for the session; 494 o An indication of whether or not the session carries packets for 495 more than one object; 497 o If Header Extensions are to be used, the format of these Header 498 Extensions. 500 o Enough information to determine the packet authentication scheme 501 being used, if it is being used. 503 How the Session Description is communicated to receivers is outside 504 the scope of this document. 506 The Codepoint field within the LCT portion of the header CAN be used 507 to communicate in-band some of the dynamically changing information 508 within a session. To do this, a mapping between Codepoint values and 509 the different dynamic settings MUST be included within the Session 510 Description, and then settings to be used are communicated via the 511 Codepoint value placed into each packet. For example, it is possible 512 that multiple objects are delivered within the same session and that 513 a different FEC encoding algorithm is used for different types of 514 objects. Then the Session Description could contain the mapping 515 between Codepoint values and FEC Encoding IDs. As another example, 516 it is possible that a different packet authentication scheme is used 517 for different packets sent to the session. In this case, the mapping 518 between the packet authentication scheme and Codepoint values could 519 be provided in the Session Description. Combinations of settings can 520 be mapped to Codepoint values as well. For example, a particular 521 combination of a FEC Encoding ID and a packet authentication scheme 522 could be associated with a Codepoint value. 524 The Session Description could also include, but is not limited to: 526 o The mappings between combinations of settings and Codepoint 527 values; 529 o The data rates used for each channel; 531 o The length of the packet payload; 533 o Any information that is relevant to each object being transported, 534 such as the Object Transmission Information for each object, when 535 the object will be available within the session and for how long. 537 The Session Description could be in a form such as SDP as defined in 538 [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime 539 headers as defined in [RFC2616], etc. It might be carried in a 540 session announcement protocol such as SAP as defined in [RFC2974], 541 obtained using a proprietary session control protocol, located on a 542 web page with scheduling information, or conveyed via E-mail or other 543 out-of-band methods. Discussion of Session Description formats and 544 methods for communication of Session Descriptions to receivers is 545 beyond the scope of this document. 547 2.5. Packet authentication building block 549 It is RECOMMENDED that implementors of ALC use some packet 550 authentication scheme to protect the protocol from attacks. An 551 example of a possibly suitable scheme is described in [PER2001]. 552 Packet authentication in ALC, if used, is to be integrated through 553 the Header Extension support for packet authentication provided in 554 the LCT building block. 556 3. Conformance Statement 558 This Protocol Instantiation document, in conjunction with the LCT 559 building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block 560 [I-D.ietf-rmt-fec-bb-revised] and with a multiple rate congestion 561 control building block completely specifies a working reliable 562 multicast transport protocol that conforms to the requirements 563 described in [RFC2357]. 565 4. Functionality Definition 567 This section describes the format and functionality of the data 568 packets carried in an ALC session as well as the sender and receiver 569 operations for a session. 571 4.1. Packet format used by ALC 573 The packet format used by ALC is the UDP header followed by the LCT 574 header followed by the FEC Payload ID followed by the packet payload. 575 The LCT header is defined in the LCT building block 576 [I-D.ietf-rmt-bb-lct-revised] and the FEC Payload ID is described in 577 the FEC building block [I-D.ietf-rmt-fec-bb-revised]. The Congestion 578 Control Information field in the LCT header contains the REQUIRED 579 Congestion Control Information that is described in the multiple rate 580 congestion control building block used. The packet payload contains 581 encoding symbols generated from an object. If more than one object 582 is carried in the session then the Transmission Object ID (TOI) 583 within the LCT header MUST be used to identify which object the 584 encoding symbols are generated from. Within the scope of an object, 585 encoding symbols carried in the payload of the packet are identified 586 by the FEC Payload ID as described in the FEC building block. 588 The version number of ALC specified in this document is 1. The 589 version number field of the LCT header MUST be interpreted as the ALC 590 version number field. This version of ALC implicitly makes use of 591 version 1 of the LCT building block defined in 592 [I-D.ietf-rmt-bb-lct-revised]. 594 The overall ALC packet format is depicted in Figure 2. The packet is 595 an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP 596 header. The ALC packet format has no dependencies on the IP version 597 number. 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | UDP header | 603 | | 604 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 605 | LCT header | 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | FEC Payload ID | 609 | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Encoding Symbol(s) | 612 | ... | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 2: Overall ALC packet format 617 In some special cases an ALC sender may need to produce ALC packets 618 that do not contain any payload. This may be required, for example, 619 to signal the end of a session or to convey congestion control 620 information. These data-less packets do not contain the FEC Payload 621 ID either, but only the LCT header fields. The total datagram 622 length, conveyed by outer protocol headers (e.g., the IP or UDP 623 header), enables receivers to detect the absence of the ALC payload 624 and FEC Payload ID. 626 For ALC the length of the TSI field within the LCT header is REQUIRED 627 to be non-zero. This implies that the sender MUST NOT set both the 628 LCT flags S and H to zero. 630 4.2. LCT Header-Extension Fields 632 All senders and receivers implementing ALC MUST support the EXT_NOP 633 Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to 634 parse its content. The EXT_NOP and EXT_AUTH LCT Header Extensions 635 are defined in [I-D.ietf-rmt-bb-lct-revised] 637 This specification defines a new LCT Header Extension, "EXT_FTI", for 638 the purpose of communicating the FEC Object Transmission Information 639 in association with data packets of an object. The LCT Header 640 Extension Type for EXT_FTI is 64. 642 The Header Extension Content (HEC) field of the EXT_FTI LCT Header 643 Extension contains the encoded FEC Object Transmission Information as 644 defined in [I-D.ietf-rmt-fec-bb-revised]. The format of the encoded 645 FEC Object Transmission Information is dependent on the FEC Scheme in 646 use and so is outside the scope of this document. 648 4.3. Sender Operation 650 The sender operation when using ALC includes all the points made 651 about the sender operation when using the LCT building block 652 [I-D.ietf-rmt-bb-lct-revised], the FEC building block 653 [I-D.ietf-rmt-fec-bb-revised] and the multiple rate congestion 654 control building block. 656 A sender using ALC MUST make available the required Session 657 Description as described in Section 2.4. A sender also MUST make 658 available the required FEC Object Transmission Information as 659 described in Section 2.3. 661 Within a session a sender transmits a sequence of packets to the 662 channels associated with the session. The ALC sender MUST obey the 663 rules for filling in the CCI field in the packet headers and MUST 664 send packets at the appropriate rates to the channels associated with 665 the session as dictated by the multiple rate congestion control 666 building block. 668 The ALC sender MUST use the same TSI for all packets in the session. 669 Several objects MAY be delivered within the same ALC session. If 670 more than one object is to be delivered within a session then the 671 sender MUST use the TOI field and each object MUST be identified by a 672 unique TOI within the session, and the sender MUST use corresponding 673 TOI for all packets pertaining to the same object. The FEC Payload 674 ID MUST correspond to the encoding symbol(s) for the object carried 675 in the payload of the packet. 677 It is RECOMMENDED that packet authentication be used. If packet 678 authentication is used then the Header Extensions described in 679 Section 4.2 MUST be used to carry the authentication. 681 4.4. Receiver Operation 683 The receiver operation when using ALC includes all the points made 684 about the receiver operation when using the LCT building block 685 [I-D.ietf-rmt-bb-lct-revised], the FEC building block 686 [I-D.ietf-rmt-fec-bb-revised] and the multiple rate congestion 687 control building block. 689 To be able to participate in a session, a receiver MUST obtain the 690 REQUIRED Session Description as listed in Section 2.4. How receivers 691 obtain a Session Description is outside the scope of this document. 693 To be able to be a receiver in a session, the receiver MUST be able 694 to process the ALC header. The receiver MUST be able to discard, 695 forward, store or process the other headers and the packet payload. 696 If a receiver is not able to process the ALC header, it MUST drop 697 from the session. 699 As described in Section 2.3, a receiver MUST obtain the required FEC 700 Object Transmission Information for each object for which the 701 receiver receives and processes packets. 703 Upon receipt of each packet the receiver proceeds with the following 704 steps in the order listed. 706 1. The receiver MUST parse the packet header and verify that it is a 707 valid header. If it is not valid then the packet MUST be 708 discarded without further processing. If multiple packets are 709 received that cannot be parsed then the receiver SHOULD leave the 710 session. 712 2. The receiver MUST verify that the sender IP address together with 713 the TSI carried in the header matches one of the (sender IP 714 address, TSI) pairs that was received in a Session Description 715 and that the receiver is currently joined to. If there is not a 716 match then the packet MUST be discarded without further 717 processing. If multiple packets are received with non-matching 718 (sender IP address, TSI) values then the receiver SHOULD leave 719 the session. If the receiver is joined to multiple ALC sessions 720 then the remainder of the steps are performed within the scope of 721 the (sender IP address, TSI) session of the received packet. 723 3. The receiver MUST process and act on the CCI field in accordance 724 with the multiple rate congestion control building block. 726 4. If more than one object is carried in the session, the receiver 727 MUST verify that the TOI carried in the LCT header is valid. If 728 the TOI is not valid, the packet MUST be discarded without 729 further processing. 731 5. The receiver SHOULD process the remainder of the packet, 732 including interpreting the other header fields appropriately, and 733 using the FEC Payload ID and the encoding symbol(s) in the 734 payload to reconstruct the corresponding object. 736 It is RECOMMENDED that packet authentication be used. If packet 737 authentication is used then it is RECOMMENDED that the receiver 738 immediately check the authenticity of a packet before proceeding with 739 step (3) above. If immediate checking is possible and if the packet 740 fails the check then the receiver MUST discard the packet and reduce 741 its reception rate to a minimum before continuing to regulate its 742 reception rate using the multiple rate congestion control. 744 Some packet authentication schemes such as TESLA [PER2001] do not 745 allow an immediate authenticity check. In this case the receiver 746 SHOULD check the authenticity of a packet as soon as possible, and if 747 the packet fails the check then it MUST be discarded before step (5) 748 above and reduce its reception rate to a minimum before continuing to 749 regulate its reception rate using the multiple rate congestion 750 control. 752 5. Security Considerations 754 The same security consideration that apply to the LCT, FEC and the 755 multiple rate congestion control building blocks also apply to ALC. 757 Because of the use of FEC, ALC is especially vulnerable to denial- 758 of-service attacks by attackers that try to send forged packets to 759 the session which would prevent successful reconstruction or cause 760 inaccurate reconstruction of large portions of the object by 761 receivers. ALC is also particularly affected by such an attack 762 because many receivers may receive the same forged packet. There are 763 two ways to protect against such attacks, one at the application 764 level and one at the packet level. It is RECOMMENDED that prevention 765 be provided at both levels. 767 At the application level, it is RECOMMENDED that an integrity check 768 on the entire received object be done once the object is 769 reconstructed to ensure it is the same as the sent object. Moreover, 770 in order to obtain strong cryptographic integrity protection a 771 digital signature verifiable by the receiver SHOULD be used to 772 provide this application level integrity check. However, if even one 773 corrupted or forged packet is used to reconstruct the object, it is 774 likely that the received object will be reconstructed incorrectly. 775 This will appropriately cause the integrity check to fail and in this 776 case the inaccurately reconstructed object SHOULD be discarded. 777 Thus, the acceptance of a single forged packet can be an effective 778 denial of service attack for distributing objects, but an object 779 integrity check at least prevents inadvertent use of inaccurately 780 reconstructed objects. The specification of an application level 781 integrity check of the received object is outside the scope of this 782 document. 784 At the packet level, it is RECOMMENDED that a packet level 785 authentication be used to ensure that each received packet is an 786 authentic and uncorrupted packet containing FEC data for the object 787 arriving from the specified sender. Packet level authentication has 788 the advantage that corrupt or forged packets can be discarded 789 individually and the received authenticated packets can be used to 790 accurately reconstruct the object. Thus, the effect of a denial of 791 service attack that injects forged packets is proportional only to 792 the number of forged packets, and not to the object size. Although 793 there is currently no IETF standard that specifies how to do 794 multicast packet level authentication, TESLA [PER2001] is a known 795 multicast packet authentication scheme that would work. 797 In addition to providing protection against reconstruction of 798 inaccurate objects, packet level authentication can also provide some 799 protection against denial of service attacks on the multiple rate 800 congestion control. Attackers can try to inject forged packets with 801 incorrect congestion control information into the multicast stream, 802 thereby potentially adversely affecting network elements and 803 receivers downstream of the attack, and much less significantly the 804 rest of the network and other receivers. Thus, it is also 805 RECOMMENDED that packet level authentication be used to protect 806 against such attacks. TESLA [PER2001] can also be used to some 807 extent to limit the damage caused by such attacks. However, with 808 TESLA a receiver can only determine if a packet is authentic several 809 seconds after it is received, and thus an attack against the 810 congestion control protocol can be effective for several seconds 811 before the receiver can react to slow down the session reception 812 rate. 814 Reverse Path Forwarding checks SHOULD be enabled in all network 815 routers and switches along the path from the sender to receivers to 816 limit the possibility of a bad agent injecting forged packets into 817 the multicast tree data path. 819 6. IANA Considerations 821 This specification registers the following LCT Header Extensions 822 Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength: 824 +-------+---------+--------------------+ 825 | Value | Name | Reference | 826 +-------+---------+--------------------+ 827 | 64 | EXT_FTI | This specification | 828 +-------+---------+--------------------+ 830 7. Acknowledgments 832 This specification is substantially based on RFC3450 [RFC3450] and 833 thus credit for the authorship of this document is primarily due to 834 the authors of RFC3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, 835 Luigi Rizzo and Jon Crowcroft. Vincent Roca, Justin Chapweske and 836 Roger Kermode also contributed to RFC3450. Additional thanks are due 837 to Vincent Roca and Rod Walsh for contributions to this update to 838 Proposed Standard. 840 8. Changes from RFC3450 842 This section summarises the changes that were made from the 843 Experimental version of this specification published as RFC3450 844 [RFC3450]: 846 o Update all references to the obsoleted RFC 2068 to RFC 2616 848 o Removed the 'Statement of Intent' from the introduction (The 849 statement of intent was meant to clarify the "Experimental" status 850 of RFC3450.) 852 o Removed the 'Intellectual Property Issues' Section and replaced 853 with a standard IPR Statement 855 o Remove material duplicated in LCT 857 o Update references for LCT and FEC Building Block to new versions 858 and align with changes in the FEC Building Block. 860 o Split normative and informative references 862 o Material applicable in a general LCT context, not just for ALC has 863 been moved to LCT 865 o The first bit of the "Protocol Specific Indication" in the LCT 866 Headert is defined as a "Source Packet Indication". This is used 867 in the case that an FEC Scheme defines two FEC Payload ID formats, 868 one of which is for packets containing only source symbols which 869 can be processed by receivers that do not support FEC Decoding. 871 o Definition and IANA registration of the EXT_FTI LCT Header 872 Extension 874 9. References 876 9.1. Normative references 878 [I-D.ietf-rmt-bb-lct-revised] 879 Luby, M., "Layered Coding Transport (LCT) Building Block", 880 draft-ietf-rmt-bb-lct-revised-04 (work in progress), 881 June 2006. 883 [I-D.ietf-rmt-fec-bb-revised] 884 Watson, M., "Forward Error Correction (FEC) Building 885 Block", draft-ietf-rmt-fec-bb-revised-04 (work in 886 progress), September 2006. 888 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 889 August 1980. 891 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 892 RFC 1112, August 1989. 894 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 895 3", BCP 9, RFC 2026, October 1996. 897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP 14, RFC 2119, March 1997. 900 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 901 Protocol", RFC 2327, April 1998. 903 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 904 Criteria for Evaluating Reliable Multicast Transport and 905 Application Protocols", RFC 2357, June 1998. 907 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 908 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 909 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 911 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 912 Announcement Protocol", RFC 2974, October 2000. 914 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 915 Types", RFC 3023, January 2001. 917 9.2. Informative references 919 [HOL2001] Holbrook, H., "A Channel Model for Multicast", Ph.D. 920 Dissertation, Stanford University, Department of Computer 921 Science, Stanford, CA , August 2001. 923 [PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, 924 "Efficient and Secure Source Authentication for 925 Multicast", Network and Distributed System Security 926 Symposium, NDSS 2001, pp. 35-46 , February 2001. 928 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 929 Floyd, S., and M. Luby, "Reliable Multicast Transport 930 Building Blocks for One-to-Many Bulk-Data Transfer", 931 RFC 3048, January 2001. 933 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 934 Reliable Multicast Transport (RMT) Building Blocks and 935 Protocol Instantiation documents", RFC 3269, April 2002. 937 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 938 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 939 Instantiation", RFC 3450, December 2002. 941 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 942 M., and J. Crowcroft, "The Use of Forward Error Correction 943 (FEC) in Reliable Multicast", RFC 3453, December 2002. 945 Authors' Addresses 947 Michael Luby 948 Digital Fountain 949 39141 Civic Center Dr. 950 Suite 300 951 Fremont, CA 94538 952 US 954 Email: luby@digitalfountain.com 956 Mark Watson 957 Digital Fountain 958 39141 Civic Center Dr. 959 Suite 300 960 Fremont, CA 94538 961 US 963 Email: mark@digitalfountain.com 965 Lorenzo Vicisano 966 Digital Fountain 967 39141 Civic Center Dr. 968 Suite 300 969 Fremont, CA 94538 970 US 972 Email: lorenzo@digitalfountain.com 974 Full Copyright Statement 976 Copyright (C) The IETF Trust (2007). 978 This document is subject to the rights, licenses and restrictions 979 contained in BCP 78, and except as set forth therein, the authors 980 retain all their rights. 982 This document and the information contained herein are provided on an 983 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 984 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 985 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 986 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 987 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 988 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 990 Intellectual Property 992 The IETF takes no position regarding the validity or scope of any 993 Intellectual Property Rights or other rights that might be claimed to 994 pertain to the implementation or use of the technology described in 995 this document or the extent to which any license under such rights 996 might or might not be available; nor does it represent that it has 997 made any independent effort to identify any such rights. Information 998 on the procedures with respect to rights in RFC documents can be 999 found in BCP 78 and BCP 79. 1001 Copies of IPR disclosures made to the IETF Secretariat and any 1002 assurances of licenses to be made available, or the result of an 1003 attempt made to obtain a general license or permission for the use of 1004 such proprietary rights by implementers or users of this 1005 specification can be obtained from the IETF on-line IPR repository at 1006 http://www.ietf.org/ipr. 1008 The IETF invites any interested party to bring to its attention any 1009 copyrights, patents or patent applications, or other proprietary 1010 rights that may cover technology that may be required to implement 1011 this standard. Please address the information to the IETF at 1012 ietf-ipr@ietf.org. 1014 Acknowledgment 1016 Funding for the RFC Editor function is provided by the IETF 1017 Administrative Support Activity (IASA).