idnits 2.17.1 draft-ietf-rmt-pi-alc-revised-01.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 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 986. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 19, 2005) is 6764 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 863, but no explicit reference was found in the text == Unused Reference: 'HOL2001' is defined on line 888, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-rmt-bb-lct-revised-00 == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-01 ** 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) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 8 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 Digital Fountain 5 Expires: April 22, 2006 Gemmell 6 Microsoft Research 7 Vicisano 8 Cisco Systems, Inc. 9 Rizzo 10 Univ. di Pisa 11 Crowcroft 12 University of Cambridge 13 October 19, 2005 15 Asynchronous Layered Coding (ALC) Protocol Instantiation 16 draft-ietf-rmt-pi-alc-revised-01 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 22, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 This document describes the Asynchronous Layered Coding (ALC) 49 protocol, a massively scalable reliable content delivery protocol. 50 Asynchronous Layered Coding combines the Layered Coding Transport 51 (LCT) building block, a multiple rate congestion control building 52 block and the Forward Error Correction (FEC) building block to 53 provide congestion controlled reliable asynchronous delivery of 54 content to an unlimited number of concurrent receivers from a single 55 sender. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Delivery service models . . . . . . . . . . . . . . . . . 4 61 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Environmental Requirements and Considerations . . . . . . 4 63 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6 64 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7 65 2.2. Multiple rate congestion control building block . . . . . 8 66 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 9 67 2.4. Session Description . . . . . . . . . . . . . . . . . . . 11 68 2.5. Packet authentication building block . . . . . . . . . . . 12 69 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 13 70 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 14 71 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 14 72 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 15 73 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 16 74 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 16 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 78 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 8.1. RFC3450 to draft-ietf-rmt-pi-alc-revised-00 . . . . . . . 23 80 8.2. draft-ietf-rmt-pi-alc-revised-01 . . . . . . . . . . . . . 23 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 9.1. Normative references . . . . . . . . . . . . . . . . . . . 24 83 9.2. Informative references . . . . . . . . . . . . . . . . . . 24 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 85 Intellectual Property and Copyright Statements . . . . . . . . . . 28 87 1. Introduction 89 This document describes a massively scalable reliable content 90 delivery protocol, Asynchronous Layered Coding (ALC), for multiple 91 rate congestion controlled reliable content delivery. The protocol 92 is specifically designed to provide massive scalability using IP 93 multicast as the underlying network service. Massive scalability in 94 this context means the number of concurrent receivers for an object 95 is potentially in the millions, the aggregate size of objects to be 96 delivered in a session ranges from hundreds of kilobytes to hundreds 97 of gigabytes, each receiver can initiate reception of an object 98 asynchronously, the reception rate of each receiver in the session is 99 the maximum fair bandwidth available between that receiver and the 100 sender, and all of this can be supported using a single sender. 102 Because ALC is focused on reliable content delivery, the goal is to 103 deliver objects as quickly as possible to each receiver while at the 104 same time remaining network friendly to competing traffic. Thus, the 105 congestion control used in conjunction with ALC should strive to 106 maximize use of available bandwidth between receivers and the sender 107 while at the same time backing off aggressively in the face of 108 competing traffic. 110 The sender side of ALC consists of generating packets based on 111 objects to be delivered within the session and sending the 112 appropriately formatted packets at the appropriate rates to the 113 channels associated with the session. The receiver side of ALC 114 consists of joining appropriate channels associated with the session, 115 performing congestion control by adjusting the set of joined channels 116 associated with the session in response to detected congestion, and 117 using the packets to reliably reconstruct objects. All information 118 flow in an ALC session is in the form of data packets sent by a 119 single sender to channels that receivers join to receive data. 121 ALC does specify the Session Description needed by receivers before 122 they join a session, but the mechanisms by which receivers obtain 123 this required information is outside the scope of ALC. An 124 application that uses ALC may require that receivers report 125 statistics on their reception experience back to the sender, but the 126 mechanisms by which receivers report back statistics is outside the 127 scope of ALC. In general, ALC is designed to be a minimal protocol 128 instantiation that provides reliable content delivery without 129 unnecessary limitations to the scalability of the basic protocol. 131 This document is a product of the IETF RMT WG and follows the general 132 guidelines provided in [RFC3269]. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in BCP 14, [RFC2119]. 138 1.1. Delivery service models 140 ALC can support several different reliable content delivery service 141 models as described in [I-D.ietf-rmt-bb-lct-revised]. 143 1.2. Scalability 145 Massive scalability is a primary design goal for ALC. IP multicast 146 is inherently massively scalable, but the best effort service that it 147 provides does not provide session management functionality, 148 congestion control or reliability. ALC provides all of this on top 149 of IP multicast without sacrificing any of the inherent scalability 150 of IP multicast. ALC has the following properties: 152 o To each receiver, it appears as if though there is a dedicated 153 session from the sender to the receiver, where the reception rate 154 adjusts to congestion along the path from sender to receiver. 156 o To the sender, there is no difference in load or outgoing rate if 157 one receiver is joined to the session or a million (or any number 158 of) receivers are joined to the session, independent of when the 159 receivers join and leave. 161 o No feedback packets are required from receivers to the sender. 163 o Almost all packets in the session that pass through a bottleneck 164 link are utilized by downstream receivers, and the session shares 165 the link with competing flows fairly in proportion to their 166 utility. 168 Thus, ALC provides a massively scalable content delivery transport 169 that is network friendly. 171 ALC intentionally omits any application specific features that could 172 potentially limit its scalability. By doing so, ALC provides a 173 minimal protocol that is massively scalable. Applications may be 174 built on top of ALC to provide additional features that may limit the 175 scalability of the application. Such applications are outside the 176 scope of this document. 178 1.3. Environmental Requirements and Considerations 180 All of the environmental requirements and considerations that apply 181 to the LCT building block [I-D.ietf-rmt-bb-lct-revised], the FEC 182 building block [I-D.ietf-rmt-fec-bb-revised], the multiple rate 183 congestion control building block and to any additional building 184 blocks that ALC uses also apply to ALC. 186 One issues that is specific to ALC with respect to the Any- Source 187 Multicast (ASM) model of IP multicast as defined in RFC 1112 188 [RFC1112] is the way the multiple rate congestion control building 189 block interacts with ASM. The congestion control building block may 190 use the measured difference in time between when a join to a channel 191 is sent and when the first packet from the channel arrives in 192 determining the receiver reception rate. The congestion control 193 building block may also uses packet sequence numbers per channel to 194 measure losses, and this is also used to determine the receiver 195 reception rate. These features raise two concerns with respect to 196 ASM: The time difference between when the join to a channel is sent 197 and when the first packet arrives can be significant due to the use 198 of Rendezvous Points (RPs) and the MSDP protocol, and packets can be 199 lost in the switch over from the (*,G) join to the RP and the (S,G) 200 join directly to the sender. Both of these issues could potentially 201 substantially degrade the reception rate of receivers. To ameliorate 202 these concerns, it is RECOMMENDED that the RP be as close to the 203 sender as possible. SSM does not share these same concerns. For a 204 fuller consideration of these issues, consult the multiple rate 205 congestion control building block. 207 2. Architecture Definition 209 ALC uses the LCT building block [I-D.ietf-rmt-bb-lct-revised] to 210 provide in-band session management functionality. ALC uses a 211 multiple rate congestion control building block that is compliant 212 with [RFC2357] to provide congestion control that is feedback free. 213 Receivers adjust their reception rates individually by joining and 214 leaving channels associated with the session. ALC uses the FEC 215 building block [I-D.ietf-rmt-fec-bb-revised] to provide reliability. 216 The sender generates encoding symbols based on the object to be 217 delivered using FEC codes and sends them in packets to channels 218 associated with the session. Receivers simply wait for enough 219 packets to arrive in order to reliably reconstruct the object. Thus, 220 there is no request for retransmission of individual packets from 221 receivers that miss packets in order to assure reliable reception of 222 an object, and the packets and their rate of transmission out of the 223 sender can be independent of the number and the individual reception 224 experiences of the receivers. 226 The definition of a session for ALC is the same as it is for LCT. An 227 ALC session comprises multiple channels originating at a single 228 sender that are used for some period of time to carry packets 229 pertaining to the transmission of one or more objects that can be of 230 interest to receivers. Congestion control is performed over the 231 aggregate of packets sent to channels belonging to a session. The 232 fact that an ALC session is restricted to a single sender does not 233 preclude the possibility of receiving packets for the same objects 234 from multiple senders. However, each sender would be sending packets 235 to a a different session to which congestion control is individually 236 applied. Although receiving concurrently from multiple sessions is 237 allowed, how this is done at the application level is outside the 238 scope of this document. 240 ALC is a protocol instantiation as defined in [RFC3048]. This 241 document describes version 1 of ALC which MUST use version 1 of LCT 242 described in [I-D.ietf-rmt-bb-lct-revised]. Like LCT, ALC is 243 designed to be used with the IP multicast network service. This 244 specification defines ALC as payload of the UDP transport protocol 245 [RFC0768] that supports IP multicast delivery of packets. Future 246 versions of this specification, or companion documents may extend ALC 247 to use the IP network layer service directly. ALC could be used as 248 the basis for designing a protocol that uses a different underlying 249 network service such as unicast UDP, but the design of such a 250 protocol is outside the scope of this document. 252 An ALC packet header immediately follows the UDP header and consists 253 of the default LCT header that is described in [I-D.ietf-rmt-bb-lct- 254 revised] followed by the FEC Payload ID that is described in 256 [I-D.ietf-rmt-fec-bb-revised]. The Congestion Control Information 257 field within the LCT header carries the required Congestion Control 258 Information that is described in the multiple rate congestion control 259 building block specified that is compliant with [RFC2357]. The 260 packet payload that follows the ALC packet header consists of 261 encoding symbols that are identified by the FEC Payload ID as 262 described in [I-D.ietf-rmt-fec-bb-revised]. 264 Each receiver is required to obtain a Session Description before 265 joining an ALC session. As described later, the Session Description 266 includes out-of-band information required for the LCT, FEC and the 267 multiple rate congestion control building blocks. The FEC Object 268 Transmission Information specified in the FEC building block 269 [I-D.ietf-rmt-fec-bb-revised] required for each object to be received 270 by a receiver can be communicated to a receiver either out-of-band or 271 in-band using a Header Extension. The means for communicating the 272 Session Description and the FEC Object Transmission Information to a 273 receiver is outside the scope of this document. 275 2.1. LCT building block 277 LCT requires receivers to be able to uniquely identify and 278 demultiplex packets associated with an LCT session, and ALC inherits 279 and strengthens this requirement. A Transport Session Identifier 280 (TSI) MUST be associated with each session and MUST be carried in the 281 LCT header of each ALC packet. The TSI is scoped by the sender IP 282 address, and the (sender IP address, TSI) pair MUST uniquely identify 283 the session. 285 The LCT header contains a Congestion Control Information (CCI) field 286 that MUST be used to carry the Congestion Control Information from 287 the specified multiple rate congestion control protocol. There is a 288 field in the LCT header that specifies the length of the CCI field, 289 and the multiple rate congestion control building block MUST uniquely 290 identify a format of the CCI field that corresponds to this length. 292 The LCT header contains a Codepoint field that MAY be used to 293 communicate to a receiver the settings for information that may vary 294 during a session. If used, the mapping between settings and 295 Codepoint values is to be communicated in the Session Description, 296 and this mapping is outside the scope of this document. For example, 297 the FEC Encoding ID that is part of the FEC Object Transmission 298 Information as specified in the FEC building block [I-D.ietf-rmt-fec- 299 bb-revised] could vary for each object carried in the session, and 300 the Codepoint value could be used to communicate the FEC Encoding ID 301 to be used for each object. The mapping between FEC Encoding IDs and 302 Codepoints could be, for example, the identity mapping. 304 If more than one object is to be carried within a session then the 305 Transmission Object Identifier (TOI) MUST be used in the LCT header 306 to identify which packets are to be associated with which objects. 307 In this case the receiver MUST use the TOI to associate received 308 packets with objects. The TOI is scoped by the IP address of the 309 sender and the TSI, i.e., the TOI is scoped by the session. The TOI 310 for each object is REQUIRED to be unique within a session, but MAY 311 NOT be unique across sessions. Furthermore, the same object MAY have 312 a different TOI in different sessions. The mapping between TOIs and 313 objects carried in a session is outside the scope of this document. 315 If only one object is carried within a session then the TOI MAY be 316 omitted from the LCT header. 318 The LCT header from version 1 of the LCT building block [I-D.ietf- 319 rmt-bb-lct-revised] MUST be used. 321 The LCT Header includes a two-bit Protocol Specific Indication (PSI) 322 field. These two bits are used by ALC as follows: 324 PSI bit 0 (LSB) - Source Packet Indicator (SPI) 326 PSI bit 1 (MSB) - Reserved 328 The Source Packet Indicator is used with systematic FEC Schemes which 329 define a different FEC Payload ID format for packets containing only 330 source data compared to the FEC Payload ID format for packets 331 containing repair data. For such FEC Schemes, then the SPI MUST be 332 set to 1 when the FEC Payload ID format for packets containing only 333 source data is used and the SPI MUST be set to zero, when the FEC 334 Payload ID for packerts containing repair data is used. In the case 335 of FEC Schemes which define only a single FEC Payload ID format, then 336 the SPI MUST be set to zero by the sender and MUST be ignored by the 337 receiver. 339 Support of two FEC Payload ID formats allows FEC Payload ID 340 information which is only of relevance when FEC decoding is to be 341 performed to be provided in the FEC Payload ID format for packets 342 containing repair data. This information need not be processed by 343 receivers which do not perform FEC decoding (either because no FEC 344 decoding is required or because the receiver does not support FEC 345 decoding). 347 2.2. Multiple rate congestion control building block 349 Implementors of ALC MUST implement a multiple rate feedback-free 350 congestion control building block that is in accordance to [RFC2357]. 351 Congestion control MUST be applied to all packets within a session 352 independently of which information about which object is carried in 353 each packet. Multiple rate congestion control is specified because 354 of its suitability to scale massively and because of its suitability 355 for reliable content delivery. The multiple rate congestion control 356 building block MUST specify in-band Congestion Control Information 357 (CCI) that MUST be carried in the CCI field of the LCT header. The 358 multiple rate congestion control building block MAY specify more than 359 one format, but it MUST specify at most one format for each of the 360 possible lengths 32, 64, 96 or 128 bits. The value of C in the LCT 361 header that determines the length of the CCI field MUST correspond to 362 one of the lengths for the CCI defined in the multiple rate 363 congestion control building block, this length MUST be the same for 364 all packets sent to a session, and the CCI format that corresponds to 365 the length as specified in the multiple rate congestion control 366 building block MUST be the format used for the CCI field in the LCT 367 header. 369 When using a multiple rate congestion control building block a sender 370 sends packets in the session to several channels at potentially 371 different rates. Then, individual receivers adjust their reception 372 rate within a session by adjusting which set of channels they are 373 joined to at each point in time depending on the available bandwidth 374 between the receiver and the sender, but independent of other 375 receivers. 377 2.3. FEC building block 379 The FEC building block [I-D.ietf-rmt-fec-bb-revised] provides 380 reliable object delivery within an ALC session. Each object sent in 381 the session is independently encoded using FEC codes as described in 382 [RFC3453], which provide a more in-depth description of the use of 383 FEC codes in reliable content delivery protocols. All packets in an 384 ALC session MUST contain an FEC Payload ID in a format that is 385 compliant with the FEC Scheme in use. The FEC Payload ID uniquely 386 identifies the encoding symbols that constitute the payload of each 387 packet, and the receiver MUST use the FEC Payload ID to determine how 388 the encoding symbols carried in the payload of the packet were 389 generated from the object as described in the FEC building block. 391 As described in [I-D.ietf-rmt-fec-bb-revised], a receiver is REQUIRED 392 to obtain the FEC Object Transmission Information for each object for 393 which data packets are received from the session. In the context of 394 ALC, the FEC Object Transmission Information includes: 396 o The FEC Encoding ID. 398 o If an Under-Specified FEC Encoding ID is used then the FEC 399 Instance ID associated with the FEC Encoding ID. 401 o For each object in the session, the transfer length of the object 402 in bytes. 404 Additional FEC Object Transmission Information may be required 405 depending on the FEC Scheme that is used (identified by the FEC 406 Encoding ID). 408 Some of the FEC Object Transmission Information MAY be implicit based 409 on the FEC Scheme and/or implementation. As an example, source block 410 lengths may be derived by a fixed algorithm from the object length. 411 As another example, it may be that all source blocks are the same 412 length and this is what is passed out-of-band to the receiver. As 413 another example, it could be that the full sized source block length 414 is provided and this is the length used for all but the last source 415 block, which is calculated based on the full source block length and 416 the object length. As another example, it could be that the same FEC 417 Encoding ID and FEC Instance ID are always used for a particular 418 application and thus the FEC Encoding ID and FEC Instance ID are 419 implicitly defined. 421 Sometimes the objects that will be sent in a session are completely 422 known before the receiver joins the session, in which case the FEC 423 Object Transmission Information for all objects in the session can be 424 communicated to receivers before they join the session. At other 425 times the objects may not know when the session begins, or receivers 426 may join a session in progress and may not be interested in some 427 objects for which transmission has finished, or receivers may leave a 428 session before some objects are even available within the session. 429 In these cases, the FEC Object Transmission Information for each 430 object may be dynamically communicated to receivers at or before the 431 time packets for the object are received from the session. This may 432 be accomplished using either an out-of-band mechanism, in-band using 433 the Codepoint field or a Header Extension, or any combination of 434 these methods. How the FEC Object Transmission Information is 435 communicated to receivers is outside the scope of this document. 437 If packets for more than one object are transmitted within a session 438 then a Transmission Object Identifier (TOI) that uniquely identifies 439 objects within a session MUST appear in each packet header. Portions 440 of the FEC Object Transmission Information could be the same for all 441 objects in the session, in which case these portions can be 442 communicated to the receiver with an indication that this applies to 443 all objects in the session. These portions may be implicitly 444 determined based on the application, e.g., an application may use the 445 same FEC Encoding ID for all objects in all sessions. If there is a 446 portion of the FEC Object Transmission Information that may vary from 447 object to object and if this FEC Object Transmission Information is 448 communicated to a receiver out-of-band then the TOI for the object 449 MUST also be communicated to the receiver together with the 450 corresponding FEC Object Transmission Information, and the receiver 451 MUST use the corresponding FEC Object Transmission Information for 452 all packets received with that TOI. How the TOI and corresponding 453 FEC Object Transmission Information is communicated out-of-band to 454 receivers is outside the scope of this document. 456 It is also possible that there is a portion of the FEC Object 457 Transmission Information that may vary from object to object that is 458 carried in-band, for example in the CodePoint field or in Header 459 Extensions. How this is done is outside the scope of this document. 460 In this case the FEC Object Transmission Information is associated 461 with the object identified by the TOI carried in the packet. 463 2.4. Session Description 465 The Session Description that a receiver is REQUIRED to obtain before 466 joining an ALC session MUST contain the following information: 468 o The multiple rate congestion control building block to be used for 469 the session; 471 o The sender IP address; 473 o The number of channels in the session; 475 o The address and port number used for each channel in the session; 477 o The Transport Session ID (TSI) to be used for the session; 479 o An indication of whether or not the session carries packets for 480 more than one object; 482 o If Header Extensions are to be used, the format of these Header 483 Extensions. 485 o Enough information to determine the packet authentication scheme 486 being used, if it is being used. 488 How the Session Description is communicated to receivers is outside 489 the scope of this document. 491 The Codepoint field within the LCT portion of the header CAN be used 492 to communicate in-band some of the dynamically changing information 493 within a session. To do this, a mapping between Codepoint values and 494 the different dynamic settings MUST be included within the Session 495 Description, and then settings to be used are communicated via the 496 Codepoint value placed into each packet. For example, it is possible 497 that multiple objects are delivered within the same session and that 498 a different FEC encoding algorithm is used for different types of 499 objects. Then the Session Description could contain the mapping 500 between Codepoint values and FEC Encoding IDs. As another example, 501 it is possible that a different packet authentication scheme is used 502 for different packets sent to the session. In this case, the mapping 503 between the packet authentication scheme and Codepoint values could 504 be provided in the Session Description. Combinations of settings can 505 be mapped to Codepoint values as well. For example, a particular 506 combination of a FEC Encoding ID and a packet authentication scheme 507 could be associated with a Codepoint value. 509 The Session Description could also include, but is not limited to: 511 o The mappings between combinations of settings and Codepoint 512 values; 514 o The data rates used for each channel; 516 o The length of the packet payload; 518 o Any information that is relevant to each object being transported, 519 such as the Object Transmission Information for each object, when 520 the object will be available within the session and for how long. 522 The Session Description could be in a form such as SDP as defined in 523 [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime 524 headers as defined in [RFC2616], etc. It might be carried in a 525 session announcement protocol such as SAP as defined in [RFC2974], 526 obtained using a proprietary session control protocol, located on a 527 web page with scheduling information, or conveyed via E-mail or other 528 out-of-band methods. Discussion of Session Description formats and 529 methods for communication of Session Descriptions to receivers is 530 beyond the scope of this document. 532 2.5. Packet authentication building block 534 It is RECOMMENDED that implementors of ALC use some packet 535 authentication scheme to protect the protocol from attacks. An 536 example of a possibly suitable scheme is described in [PER2001]. 537 Packet authentication in ALC, if used, is to be integrated through 538 the Header Extension support for packet authentication provided in 539 the LCT building block. 541 3. Conformance Statement 543 This Protocol Instantiation document, in conjunction with the LCT 544 building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block 545 [I-D.ietf-rmt-fec-bb-revised] and with a multiple rate congestion 546 control building block completely specifies a working reliable 547 multicast transport protocol that conforms to the requirements 548 described in [RFC2357]. 550 4. Functionality Definition 552 This section describes the format and functionality of the data 553 packets carried in an ALC session as well as the sender and receiver 554 operations for a session. 556 4.1. Packet format used by ALC 558 The packet format used by ALC is the UDP header followed by the LCT 559 header followed by the FEC Payload ID followed by the packet payload. 560 The LCT header is defined in the LCT building block [I-D.ietf-rmt-bb- 561 lct-revised] and the FEC Payload ID is described in the FEC building 562 block [I-D.ietf-rmt-fec-bb-revised]. The Congestion Control 563 Information field in the LCT header contains the REQUIRED Congestion 564 Control Information that is described in the multiple rate congestion 565 control building block used. The packet payload contains encoding 566 symbols generated from an object. If more than one object is carried 567 in the session then the Transmission Object ID (TOI) within the LCT 568 header MUST be used to identify which object the encoding symbols are 569 generated from. Within the scope of an object, encoding symbols 570 carried in the payload of the packet are identified by the FEC 571 Payload ID as described in the FEC building block. 573 The version number of ALC specified in this document is 1. The 574 version number field of the LCT header MUST be interpreted as the ALC 575 version number field. This version of ALC implicitly makes use of 576 version 1 of the LCT building block defined in [I-D.ietf-rmt-bb-lct- 577 revised]. 579 The overall ALC packet format is depicted in Figure 1. The packet is 580 an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP 581 header. The ALC packet format has no dependencies on the IP version 582 number. 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | UDP header | 588 | | 589 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 590 | LCT header | 591 | | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | FEC Payload ID | 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Encoding Symbol(s) | 597 | ... | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 1: Overall ALC packet format 602 In some special cases an ALC sender may need to produce ALC packets 603 that do not contain any payload. This may be required, for example, 604 to signal the end of a session or to convey congestion control 605 information. These data-less packets do not contain the FEC Payload 606 ID either, but only the LCT header fields. The total datagram 607 length, conveyed by outer protocol headers (e.g., the IP or UDP 608 header), enables receivers to detect the absence of the ALC payload 609 and FEC Payload ID. 611 For ALC the length of the TSI field within the LCT header is REQUIRED 612 to be non-zero. This implies that the sender MUST NOT set both the 613 LCT flags S and H to zero. 615 4.2. LCT Header-Extension Fields 617 All senders and receivers implementing ALC MUST support the EXT_NOP 618 Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to 619 parse its content. The EXT_NOP and EXT_AUTH LCT Header Extensions 620 are defined in [I-D.ietf-rmt-bb-lct-revised] 622 This specification defines a new LCT Header Extension, "EXT_FTI", for 623 the purpose of communicating the FEC Object Transmission Information 624 in association with data packets of an object. The LCT Header 625 Extension Type for EXT_FTI is 64. 627 The Header Extension Content (HEC) field of the EXT_FTI LCT Header 628 Extension contains the encoded FEC Object Transmission Information as 629 defined in [I-D.ietf-rmt-fec-bb-revised]. The format of the encoded 630 FEC Object Transmission Information is dependent on the FEC Scheme in 631 use and so is outside the scope of this document. 633 4.3. Sender Operation 635 The sender operation when using ALC includes all the points made 636 about the sender operation when using the LCT building block 637 [I-D.ietf-rmt-bb-lct-revised], the FEC building block [I-D.ietf-rmt- 638 fec-bb-revised] and the multiple rate congestion control building 639 block. 641 A sender using ALC MUST make available the required Session 642 Description as described in Section 2.4. A sender also MUST make 643 available the required FEC Object Transmission Information as 644 described in Section 2.3. 646 Within a session a sender transmits a sequence of packets to the 647 channels associated with the session. The ALC sender MUST obey the 648 rules for filling in the CCI field in the packet headers and MUST 649 send packets at the appropriate rates to the channels associated with 650 the session as dictated by the multiple rate congestion control 651 building block. 653 The ALC sender MUST use the same TSI for all packets in the session. 654 Several objects MAY be delivered within the same ALC session. If 655 more than one object is to be delivered within a session then the 656 sender MUST use the TOI field and each object MUST be identified by a 657 unique TOI within the session, and the sender MUST use corresponding 658 TOI for all packets pertaining to the same object. The FEC Payload 659 ID MUST correspond to the encoding symbol(s) for the object carried 660 in the payload of the packet. 662 It is RECOMMENDED that packet authentication be used. If packet 663 authentication is used then the Header Extensions described in 664 Section 4.2 MUST be used to carry the authentication. 666 4.4. Receiver Operation 668 The receiver operation when using ALC includes all the points made 669 about the receiver operation when using the LCT building block 670 [I-D.ietf-rmt-bb-lct-revised], the FEC building block [I-D.ietf-rmt- 671 fec-bb-revised] and the multiple rate congestion control building 672 block. 674 To be able to participate in a session, a receiver MUST obtain the 675 REQUIRED Session Description as listed in Section 2.4. How receivers 676 obtain a Session Description is outside the scope of this document. 678 To be able to be a receiver in a session, the receiver MUST be able 679 to process the ALC header. The receiver MUST be able to discard, 680 forward, store or process the other headers and the packet payload. 681 If a receiver is not able to process the ALC header, it MUST drop 682 from the session. 684 As described in Section 2.3, a receiver MUST obtain the required FEC 685 Object Transmission Information for each object for which the 686 receiver receives and processes packets. 688 Upon receipt of each packet the receiver proceeds with the following 689 steps in the order listed. 691 1. The receiver MUST parse the packet header and verify that it is a 692 valid header. If it is not valid then the packet MUST be 693 discarded without further processing. If multiple packets are 694 received that cannot be parsed then the receiver SHOULD leave the 695 session. 697 2. The receiver MUST verify that the sender IP address together with 698 the TSI carried in the header matches one of the (sender IP 699 address, TSI) pairs that was received in a Session Description 700 and that the receiver is currently joined to. If there is not a 701 match then the packet MUST be discarded without further 702 processing. If multiple packets are received with non-matching 703 (sender IP address, TSI) values then the receiver SHOULD leave 704 the session. If the receiver is joined to multiple ALC sessions 705 then the remainder of the steps are performed within the scope of 706 the (sender IP address, TSI) session of the received packet. 708 3. The receiver MUST process and act on the CCI field in accordance 709 with the multiple rate congestion control building block. 711 4. If more than one object is carried in the session, the receiver 712 MUST verify that the TOI carried in the LCT header is valid. If 713 the TOI is not valid, the packet MUST be discarded without 714 further processing. 716 5. The receiver SHOULD process the remainder of the packet, 717 including interpreting the other header fields appropriately, and 718 using the FEC Payload ID and the encoding symbol(s) in the 719 payload to reconstruct the corresponding object. 721 It is RECOMMENDED that packet authentication be used. If packet 722 authentication is used then it is RECOMMENDED that the receiver 723 immediately check the authenticity of a packet before proceeding with 724 step (3) above. If immediate checking is possible and if the packet 725 fails the check then the receiver MUST discard the packet and reduce 726 its reception rate to a minimum before continuing to regulate its 727 reception rate using the multiple rate congestion control. 729 Some packet authentication schemes such as TESLA [PER2001] do not 730 allow an immediate authenticity check. In this case the receiver 731 SHOULD check the authenticity of a packet as soon as possible, and if 732 the packet fails the check then it MUST be discarded before step (5) 733 above and reduce its reception rate to a minimum before continuing to 734 regulate its reception rate using the multiple rate congestion 735 control. 737 5. Security Considerations 739 The same security consideration that apply to the LCT, FEC and the 740 multiple rate congestion control building blocks also apply to ALC. 742 Because of the use of FEC, ALC is especially vulnerable to denial- 743 of-service attacks by attackers that try to send forged packets to 744 the session which would prevent successful reconstruction or cause 745 inaccurate reconstruction of large portions of the object by 746 receivers. ALC is also particularly affected by such an attack 747 because many receivers may receive the same forged packet. There are 748 two ways to protect against such attacks, one at the application 749 level and one at the packet level. It is RECOMMENDED that prevention 750 be provided at both levels. 752 At the application level, it is RECOMMENDED that an integrity check 753 on the entire received object be done once the object is 754 reconstructed to ensure it is the same as the sent object. Moreover, 755 in order to obtain strong cryptographic integrity protection a 756 digital signature verifiable by the receiver SHOULD be used to 757 provide this application level integrity check. However, if even one 758 corrupted or forged packet is used to reconstruct the object, it is 759 likely that the received object will be reconstructed incorrectly. 760 This will appropriately cause the integrity check to fail and in this 761 case the inaccurately reconstructed object SHOULD be discarded. 762 Thus, the acceptance of a single forged packet can be an effective 763 denial of service attack for distributing objects, but an object 764 integrity check at least prevents inadvertent use of inaccurately 765 reconstructed objects. The specification of an application level 766 integrity check of the received object is outside the scope of this 767 document. 769 At the packet level, it is RECOMMENDED that a packet level 770 authentication be used to ensure that each received packet is an 771 authentic and uncorrupted packet containing FEC data for the object 772 arriving from the specified sender. Packet level authentication has 773 the advantage that corrupt or forged packets can be discarded 774 individually and the received authenticated packets can be used to 775 accurately reconstruct the object. Thus, the effect of a denial of 776 service attack that injects forged packets is proportional only to 777 the number of forged packets, and not to the object size. Although 778 there is currently no IETF standard that specifies how to do 779 multicast packet level authentication, TESLA [PER2001] is a known 780 multicast packet authentication scheme that would work. 782 In addition to providing protection against reconstruction of 783 inaccurate objects, packet level authentication can also provide some 784 protection against denial of service attacks on the multiple rate 785 congestion control. Attackers can try to inject forged packets with 786 incorrect congestion control information into the multicast stream, 787 thereby potentially adversely affecting network elements and 788 receivers downstream of the attack, and much less significantly the 789 rest of the network and other receivers. Thus, it is also 790 RECOMMENDED that packet level authentication be used to protect 791 against such attacks. TESLA [PER2001] can also be used to some 792 extent to limit the damage caused by such attacks. However, with 793 TESLA a receiver can only determine if a packet is authentic several 794 seconds after it is received, and thus an attack against the 795 congestion control protocol can be effective for several seconds 796 before the receiver can react to slow down the session reception 797 rate. 799 Reverse Path Forwarding checks SHOULD be enabled in all network 800 routers and switches along the path from the sender to receivers to 801 limit the possibility of a bad agent injecting forged packets into 802 the multicast tree data path. 804 6. IANA Considerations 806 This specification registers the following LCT Header Extensions 807 Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength: 809 +-------+---------+--------------------+ 810 | Value | Name | Reference | 811 +-------+---------+--------------------+ 812 | 64 | EXT_FTI | This specification | 813 +-------+---------+--------------------+ 815 7. Acknowledgments 817 Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their 818 detailed comments on this document. 820 8. Change Log 822 8.1. RFC3450 to draft-ietf-rmt-pi-alc-revised-00 824 Update all references to the obsoleted RFC 2068 to RFC 2616 826 Removed the 'Statement of Intent' from the introduction 828 The statement of intent was meant to clarify the "Experimental" 829 status of RFC3450. It does not apply to this draft that is 830 intended for "Standard Track" submission. 832 Removed the 'Intellectual Property Issues' Section and replaced with 833 a standard IPR Statement 835 8.2. draft-ietf-rmt-pi-alc-revised-01 837 Remove material duplicated in LCT 839 Update references for LCT and FEC Building Block to new versions. 841 Split normative and informative references 843 9. References 845 9.1. Normative references 847 [I-D.ietf-rmt-bb-lct-revised] 848 Luby, M., "Layered Coding Transport (LCT) Building Block", 849 draft-ietf-rmt-bb-lct-revised-00 (work in progress), 850 July 2005. 852 [I-D.ietf-rmt-fec-bb-revised] 853 Watson, M., "Forward Error Correction (FEC) Building 854 Block", draft-ietf-rmt-fec-bb-revised-01 (work in 855 progress), September 2005. 857 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 858 August 1980. 860 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 861 RFC 1112, August 1989. 863 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 864 3", BCP 9, RFC 2026, October 1996. 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, March 1997. 869 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 870 Protocol", RFC 2327, April 1998. 872 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 873 Criteria for Evaluating Reliable Multicast Transport and 874 Application Protocols", RFC 2357, June 1998. 876 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 877 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 878 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 880 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 881 Announcement Protocol", RFC 2974, October 2000. 883 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 884 Types", RFC 3023, January 2001. 886 9.2. Informative references 888 [HOL2001] Holbrook, H., "A Channel Model for Multicast", Ph.D. 889 Dissertation, Stanford University, Department of Computer 890 Science, Stanford, CA , August 2001. 892 [PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, 893 "Efficient and Secure Source Authentication for 894 Multicast", Network and Distributed System Security 895 Symposium, NDSS 2001, pp. 35-46 , February 2001. 897 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 898 Floyd, S., and M. Luby, "Reliable Multicast Transport 899 Building Blocks for One-to-Many Bulk-Data Transfer", 900 RFC 3048, January 2001. 902 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 903 Reliable Multicast Transport (RMT) Building Blocks and 904 Protocol Instantiation documents", RFC 3269, April 2002. 906 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 907 M., and J. Crowcroft, "The Use of Forward Error Correction 908 (FEC) in Reliable Multicast", RFC 3453, December 2002. 910 Authors' Addresses 912 Michael Luby 913 Digital Fountain 914 39141 Civic Center Dr. 915 Suite 300 916 Fremont, CA 94538 917 US 919 Email: luby@digitalfountain.com 921 Mark Watson 922 Digital Fountain 923 39141 Civic Center Dr. 924 Suite 300 925 Fremont, CA 94538 926 US 928 Email: mark@digitalfountain.com 930 Jim Gemmell 931 Microsoft Research 932 455 Market St. #1690 933 San Francisco, CA 94105 934 US 936 Email: jgemmell@microsoft.com 938 Lorenzo Vicisano 939 Cisco Systems, Inc. 940 510 McCarthy Blvd. 941 Milpitas, CA 95035 942 US 944 Email: lorenzo@cisco.com 945 Luigi Rizzo 946 Univ. di Pisa 947 Dip. Ing. dell'Informazione, 948 via Diotisalvi 2 949 Pisa, PI 56126 950 Italy 952 Email: luigi@iet.unipi.it 954 Jon Crowcroft 955 University of Cambridge 956 Computer Laboratory 957 William Gates Building 958 J J Thomson Avenue 959 Cambridge, CB3 0FD 960 United Kingdom 962 Email: Jon.Crowcroft@cl.cam.ac.uk 964 Intellectual Property Statement 966 The IETF takes no position regarding the validity or scope of any 967 Intellectual Property Rights or other rights that might be claimed to 968 pertain to the implementation or use of the technology described in 969 this document or the extent to which any license under such rights 970 might or might not be available; nor does it represent that it has 971 made any independent effort to identify any such rights. Information 972 on the procedures with respect to rights in RFC documents can be 973 found in BCP 78 and BCP 79. 975 Copies of IPR disclosures made to the IETF Secretariat and any 976 assurances of licenses to be made available, or the result of an 977 attempt made to obtain a general license or permission for the use of 978 such proprietary rights by implementers or users of this 979 specification can be obtained from the IETF on-line IPR repository at 980 http://www.ietf.org/ipr. 982 The IETF invites any interested party to bring to its attention any 983 copyrights, patents or patent applications, or other proprietary 984 rights that may cover technology that may be required to implement 985 this standard. Please address the information to the IETF at 986 ietf-ipr@ietf.org. 988 Disclaimer of Validity 990 This document and the information contained herein are provided on an 991 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 992 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 993 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 994 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 995 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 996 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 998 Copyright Statement 1000 Copyright (C) The Internet Society (2005). This document is subject 1001 to the rights, licenses and restrictions contained in BCP 78, and 1002 except as set forth therein, the authors retain all their rights. 1004 Acknowledgment 1006 Funding for the RFC Editor function is currently provided by the 1007 Internet Society.