idnits 2.17.1 draft-ietf-rmt-pi-alc-revised-06.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 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1138. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1145. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1151. 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 (November 1, 2008) is 5655 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) == Outdated reference: A later version (-11) exists of draft-ietf-rmt-bb-lct-revised-07 ** 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 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 3450 (Obsoleted by RFC 5775) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 11 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 November 1, 2008 7 Expires: May 5, 2009 9 Asynchronous Layered Coding (ALC) Protocol Instantiation 10 draft-ietf-rmt-pi-alc-revised-06 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 May 5, 2009. 37 Abstract 39 This document describes the Asynchronous Layered Coding (ALC) 40 protocol, a massively scalable reliable content delivery protocol. 41 Asynchronous Layered Coding combines the Layered Coding Transport 42 (LCT) building block, a multiple rate congestion control building 43 block and the Forward Error Correction (FEC) building block to 44 provide congestion controlled reliable asynchronous delivery of 45 content to an unlimited number of concurrent receivers from a single 46 sender. This document obsoletes RFC3450. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Delivery service models . . . . . . . . . . . . . . . . . 4 52 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.3. Environmental Requirements and Considerations . . . . . . 5 54 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 6 55 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 7 56 2.2. Multiple rate congestion control building block . . . . . 9 57 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 9 58 2.4. Session Description . . . . . . . . . . . . . . . . . . . 11 59 2.5. Packet authentication building block . . . . . . . . . . . 12 60 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14 61 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 15 62 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 15 63 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 16 64 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 17 65 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 17 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 67 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 21 68 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 21 69 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 22 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 72 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 27 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 74 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 75 9.2. Informative references . . . . . . . . . . . . . . . . . . 29 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 77 Intellectual Property and Copyright Statements . . . . . . . . . . 31 79 1. Introduction 81 This document describes a massively scalable reliable content 82 delivery protocol, Asynchronous Layered Coding (ALC), for multiple 83 rate congestion controlled reliable content delivery. The protocol 84 is specifically designed to provide massive scalability using IP 85 multicast as the underlying network service. Massive scalability in 86 this context means the number of concurrent receivers for an object 87 is potentially in the millions, the aggregate size of objects to be 88 delivered in a session ranges from hundreds of kilobytes to hundreds 89 of gigabytes, each receiver can initiate reception of an object 90 asynchronously, the reception rate of each receiver in the session is 91 the maximum fair bandwidth available between that receiver and the 92 sender, and all of this can be supported using a single sender. 94 Because ALC is focused on reliable content delivery, the goal is to 95 deliver objects as quickly as possible to each receiver while at the 96 same time remaining network friendly to competing traffic. Thus, the 97 congestion control used in conjunction with ALC should strive to 98 maximize use of available bandwidth between receivers and the sender 99 while at the same time backing off aggressively in the face of 100 competing traffic. 102 The sender side of ALC consists of generating packets based on 103 objects to be delivered within the session and sending the 104 appropriately formatted packets at the appropriate rates to the 105 channels associated with the session. The receiver side of ALC 106 consists of joining appropriate channels associated with the session, 107 performing congestion control by adjusting the set of joined channels 108 associated with the session in response to detected congestion, and 109 using the packets to reliably reconstruct objects. All information 110 flow in an ALC session is in the form of data packets sent by a 111 single sender to channels that receivers join to receive data. 113 ALC does specify the Session Description needed by receivers before 114 they join a session, but the mechanisms by which receivers obtain 115 this required information is outside the scope of ALC. An 116 application that uses ALC may require that receivers report 117 statistics on their reception experience back to the sender, but the 118 mechanisms by which receivers report back statistics is outside the 119 scope of ALC. In general, ALC is designed to be a minimal protocol 120 instantiation that provides reliable content delivery without 121 unnecessary limitations to the scalability of the basic protocol. 123 This document is a product of the IETF RMT WG and follows the general 124 guidelines provided in [RFC3269]. 126 RFC3450 [RFC3450], which is obsoleted by this document, contained a 127 previous versions of the protocol. RFC3450 was published in the 128 "Experimental" category. It was the stated intent of the RMT working 129 group to re-submit these specifications as an IETF Proposed Standard 130 in due course. 132 This Proposed Standard specification is thus based on and backwards 133 compatible with the protocol defined in RFC3450 [RFC3450] updated 134 according to accumulated experience and growing protocol maturity 135 since its original publication. Said experience applies both to this 136 specification itself and to congestion control strategies related to 137 the use of this specification. 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in BCP 14, [RFC2119]. 143 1.1. Delivery service models 145 ALC can support several different reliable content delivery service 146 models as described in [I-D.ietf-rmt-bb-lct-revised]. 148 1.2. Scalability 150 Massive scalability is a primary design goal for ALC. IP multicast 151 is inherently massively scalable, but the best effort service that it 152 provides does not provide session management functionality, 153 congestion control or reliability. ALC provides all of this on top 154 of IP multicast without sacrificing any of the inherent scalability 155 of IP multicast. ALC has the following properties: 157 o To each receiver, it appears as if though there is a dedicated 158 session from the sender to the receiver, where the reception rate 159 adjusts to congestion along the path from sender to receiver. 161 o To the sender, there is no difference in load or outgoing rate if 162 one receiver is joined to the session or a million (or any number 163 of) receivers are joined to the session, independent of when the 164 receivers join and leave. 166 o No feedback packets are required from receivers to the sender. 168 o Almost all packets in the session that pass through a bottleneck 169 link are utilized by downstream receivers, and the session shares 170 the link with competing flows fairly in proportion to their 171 utility. 173 Thus, ALC provides a massively scalable content delivery transport 174 that is network friendly. 176 ALC intentionally omits any application specific features that could 177 potentially limit its scalability. By doing so, ALC provides a 178 minimal protocol that is massively scalable. Applications may be 179 built on top of ALC to provide additional features that may limit the 180 scalability of the application. Such applications are outside the 181 scope of this document. 183 1.3. Environmental Requirements and Considerations 185 All of the environmental requirements and considerations that apply 186 to the LCT building block [I-D.ietf-rmt-bb-lct-revised], the FEC 187 building block [RFC5052], the multiple rate congestion control 188 building block and to any additional building blocks that ALC uses 189 also apply to ALC. 191 One issues that is specific to ALC with respect to the Any- Source 192 Multicast (ASM) model of IP multicast as defined in RFC 1112 193 [RFC1112] is the way the multiple rate congestion control building 194 block interacts with ASM. The congestion control building block may 195 use the measured difference in time between when a join to a channel 196 is sent and when the first packet from the channel arrives in 197 determining the receiver reception rate. The congestion control 198 building block may also uses packet sequence numbers per channel to 199 measure losses, and this is also used to determine the receiver 200 reception rate. These features raise two concerns with respect to 201 ASM: The time difference between when the join to a channel is sent 202 and when the first packet arrives can be significant due to the use 203 of Rendezvous Points (RPs) and the MSDP protocol, and packets can be 204 lost in the switch over from the (*,G) join to the RP and the (S,G) 205 join directly to the sender. Both of these issues could potentially 206 substantially degrade the reception rate of receivers. To ameliorate 207 these concerns, it is RECOMMENDED that the RP be as close to the 208 sender as possible. SSM does not share these same concerns. For a 209 fuller consideration of these issues, consult the multiple rate 210 congestion control building block. 212 2. Architecture Definition 214 ALC uses the LCT building block [I-D.ietf-rmt-bb-lct-revised] to 215 provide in-band session management functionality. ALC uses a 216 multiple rate congestion control building block that is compliant 217 with [RFC2357] to provide congestion control that is feedback free. 218 Receivers adjust their reception rates individually by joining and 219 leaving channels associated with the session. ALC uses the FEC 220 building block [RFC5052] to provide reliability. The sender 221 generates encoding symbols based on the object to be delivered using 222 FEC codes and sends them in packets to channels associated with the 223 session. Receivers simply wait for enough packets to arrive in order 224 to reliably reconstruct the object. Thus, there is no request for 225 retransmission of individual packets from receivers that miss packets 226 in order to assure reliable reception of an object, and the packets 227 and their rate of transmission out of the sender can be independent 228 of the number and the individual reception experiences of the 229 receivers. 231 The definition of a session for ALC is the same as it is for LCT. An 232 ALC session comprises multiple channels originating at a single 233 sender that are used for some period of time to carry packets 234 pertaining to the transmission of one or more objects that can be of 235 interest to receivers. Congestion control is performed over the 236 aggregate of packets sent to channels belonging to a session. The 237 fact that an ALC session is restricted to a single sender does not 238 preclude the possibility of receiving packets for the same objects 239 from multiple senders. However, each sender would be sending packets 240 to a a different session to which congestion control is individually 241 applied. Although receiving concurrently from multiple sessions is 242 allowed, how this is done at the application level is outside the 243 scope of this document. 245 ALC is a protocol instantiation as defined in [RFC3048]. This 246 document describes version 1 of ALC which MUST use version 1 of LCT 247 described in [I-D.ietf-rmt-bb-lct-revised]. Like LCT, ALC is 248 designed to be used with the IP multicast network service. This 249 specification defines ALC as payload of the UDP transport protocol 250 [RFC0768] that supports IP multicast delivery of packets. Future 251 versions of this specification, or companion documents may extend ALC 252 to use the IP network layer service directly. ALC could be used as 253 the basis for designing a protocol that uses a different underlying 254 network service such as unicast UDP, but the design of such a 255 protocol is outside the scope of this document. 257 An ALC packet header immediately follows the UDP header and consists 258 of the default LCT header that is described in 259 [I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is 260 described in [RFC5052]. The Congestion Control Information field 261 within the LCT header carries the required Congestion Control 262 Information that is described in the multiple rate congestion control 263 building block specified that is compliant with [RFC2357]. The 264 packet payload that follows the ALC packet header consists of 265 encoding symbols that are identified by the FEC Payload ID as 266 described in [RFC5052]. 268 Each receiver is required to obtain a Session Description before 269 joining an ALC session. As described later, the Session Description 270 includes out-of-band information required for the LCT, FEC and the 271 multiple rate congestion control building blocks. The FEC Object 272 Transmission Information specified in the FEC building block 273 [RFC5052] required for each object to be received by a receiver can 274 be communicated to a receiver either out-of-band or in-band using a 275 Header Extension. The means for communicating the Session 276 Description and the FEC Object Transmission Information to a receiver 277 is outside the scope of this document. 279 2.1. LCT building block 281 LCT requires receivers to be able to uniquely identify and 282 demultiplex packets associated with an LCT session, and ALC inherits 283 and strengthens this requirement. A Transport Session Identifier 284 (TSI) MUST be associated with each session and MUST be carried in the 285 LCT header of each ALC packet. The TSI is scoped by the sender IP 286 address, and the (sender IP address, TSI) pair MUST uniquely identify 287 the session. 289 The LCT header contains a Congestion Control Information (CCI) field 290 that MUST be used to carry the Congestion Control Information from 291 the specified multiple rate congestion control protocol. There is a 292 field in the LCT header that specifies the length of the CCI field, 293 and the multiple rate congestion control building block MUST uniquely 294 identify a format of the CCI field that corresponds to this length. 296 The LCT header contains a Codepoint field that MAY be used to 297 communicate to a receiver the settings for information that may vary 298 during a session. If used, the mapping between settings and 299 Codepoint values is to be communicated in the Session Description, 300 and this mapping is outside the scope of this document. For example, 301 the FEC Encoding ID that is part of the FEC Object Transmission 302 Information as specified in the FEC building block [RFC5052] could 303 vary for each object carried in the session, and the Codepoint value 304 could be used to communicate the FEC Encoding ID to be used for each 305 object. The mapping between FEC Encoding IDs and Codepoints could 306 be, for example, the identity mapping. 308 If more than one object is to be carried within a session then the 309 Transmission Object Identifier (TOI) MUST be used in the LCT header 310 to identify which packets are to be associated with which objects. 311 In this case the receiver MUST use the TOI to associate received 312 packets with objects. The TOI is scoped by the IP address of the 313 sender and the TSI, i.e., the TOI is scoped by the session. The TOI 314 for each object is REQUIRED to be unique within a session, but MAY 315 NOT be unique across sessions. Furthermore, the same object MAY have 316 a different TOI in different sessions. The mapping between TOIs and 317 objects carried in a session is outside the scope of this document. 319 If only one object is carried within a session then the TOI MAY be 320 omitted from the LCT header. 322 The LCT header from version 1 of the LCT building block 323 [I-D.ietf-rmt-bb-lct-revised] MUST be used. 325 The LCT Header includes a two-bit Protocol Specific Indication (PSI) 326 field in bits 6 and 7 of the first word of the LCT header. These two 327 bits are used by ALC as follows: 329 0 1 2 3 330 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 331 +-+-+ 332 ...|A|B|... 333 +-+-+ 335 Figure 1: PSI bits within LCT Headder 337 PSI bit A - Source Packet Indicator (SPI) 339 PSI bit B - Reserved 341 The Source Packet Indicator is used with systematic FEC Schemes which 342 define a different FEC Payload ID format for packets containing only 343 source data compared to the FEC Payload ID format for packets 344 containing repair data. For such FEC Schemes, then the SPI MUST be 345 set to 1 when the FEC Payload ID format for packets containing only 346 source data is used and the SPI MUST be set to zero, when the FEC 347 Payload ID for packerts containing repair data is used. In the case 348 of FEC Schemes which define only a single FEC Payload ID format, then 349 the SPI MUST be set to zero by the sender and MUST be ignored by the 350 receiver. 352 Support of two FEC Payload ID formats allows FEC Payload ID 353 information which is only of relevance when FEC decoding is to be 354 performed to be provided in the FEC Payload ID format for packets 355 containing repair data. This information need not be processed by 356 receivers which do not perform FEC decoding (either because no FEC 357 decoding is required or because the receiver does not support FEC 358 decoding). 360 2.2. Multiple rate congestion control building block 362 Implementors of ALC MUST implement a multiple rate feedback-free 363 congestion control building block that is in accordance to [RFC2357]. 364 Congestion control MUST be applied to all packets within a session 365 independently of which information about which object is carried in 366 each packet. Multiple rate congestion control is specified because 367 of its suitability to scale massively and because of its suitability 368 for reliable content delivery. The multiple rate congestion control 369 building block MUST specify in-band Congestion Control Information 370 (CCI) that MUST be carried in the CCI field of the LCT header. The 371 multiple rate congestion control building block MAY specify more than 372 one format, but it MUST specify at most one format for each of the 373 possible lengths 32, 64, 96 or 128 bits. The value of C in the LCT 374 header that determines the length of the CCI field MUST correspond to 375 one of the lengths for the CCI defined in the multiple rate 376 congestion control building block, this length MUST be the same for 377 all packets sent to a session, and the CCI format that corresponds to 378 the length as specified in the multiple rate congestion control 379 building block MUST be the format used for the CCI field in the LCT 380 header. 382 When using a multiple rate congestion control building block a sender 383 sends packets in the session to several channels at potentially 384 different rates. Then, individual receivers adjust their reception 385 rate within a session by adjusting which set of channels they are 386 joined to at each point in time depending on the available bandwidth 387 between the receiver and the sender, but independent of other 388 receivers. 390 2.3. FEC building block 392 The FEC building block [RFC5052] provides reliable object delivery 393 within an ALC session. Each object sent in the session is 394 independently encoded using FEC codes as described in [RFC3453], 395 which provide a more in-depth description of the use of FEC codes in 396 reliable content delivery protocols. All packets in an ALC session 397 MUST contain an FEC Payload ID in a format that is compliant with the 398 FEC Scheme in use. The FEC Payload ID uniquely identifies the 399 encoding symbols that constitute the payload of each packet, and the 400 receiver MUST use the FEC Payload ID to determine how the encoding 401 symbols carried in the payload of the packet were generated from the 402 object as described in the FEC building block. 404 As described in [RFC5052], a receiver is REQUIRED to obtain the FEC 405 Object Transmission Information for each object for which data 406 packets are received from the session. In the context of ALC, the 407 FEC Object Transmission Information includes: 409 o The FEC Encoding ID. 411 o If an Under-Specified FEC Encoding ID is used then the FEC 412 Instance ID associated with the FEC Encoding ID. 414 o For each object in the session, the transfer length of the object 415 in bytes. 417 Additional FEC Object Transmission Information may be required 418 depending on the FEC Scheme that is used (identified by the FEC 419 Encoding ID). 421 Some of the FEC Object Transmission Information MAY be implicit based 422 on the FEC Scheme and/or implementation. As an example, source block 423 lengths may be derived by a fixed algorithm from the object length. 424 As another example, it may be that all source blocks are the same 425 length and this is what is passed out-of-band to the receiver. As 426 another example, it could be that the full sized source block length 427 is provided and this is the length used for all but the last source 428 block, which is calculated based on the full source block length and 429 the object length. As another example, it could be that the same FEC 430 Encoding ID and FEC Instance ID are always used for a particular 431 application and thus the FEC Encoding ID and FEC Instance ID are 432 implicitly defined. 434 Sometimes the objects that will be sent in a session are completely 435 known before the receiver joins the session, in which case the FEC 436 Object Transmission Information for all objects in the session can be 437 communicated to receivers before they join the session. At other 438 times the objects may not know when the session begins, or receivers 439 may join a session in progress and may not be interested in some 440 objects for which transmission has finished, or receivers may leave a 441 session before some objects are even available within the session. 442 In these cases, the FEC Object Transmission Information for each 443 object may be dynamically communicated to receivers at or before the 444 time packets for the object are received from the session. This may 445 be accomplished using either an out-of-band mechanism, in-band using 446 the Codepoint field or a Header Extension, or any combination of 447 these methods. How the FEC Object Transmission Information is 448 communicated to receivers is outside the scope of this document. 450 If packets for more than one object are transmitted within a session 451 then a Transmission Object Identifier (TOI) that uniquely identifies 452 objects within a session MUST appear in each packet header. Portions 453 of the FEC Object Transmission Information could be the same for all 454 objects in the session, in which case these portions can be 455 communicated to the receiver with an indication that this applies to 456 all objects in the session. These portions may be implicitly 457 determined based on the application, e.g., an application may use the 458 same FEC Encoding ID for all objects in all sessions. If there is a 459 portion of the FEC Object Transmission Information that may vary from 460 object to object and if this FEC Object Transmission Information is 461 communicated to a receiver out-of-band then the TOI for the object 462 MUST also be communicated to the receiver together with the 463 corresponding FEC Object Transmission Information, and the receiver 464 MUST use the corresponding FEC Object Transmission Information for 465 all packets received with that TOI. How the TOI and corresponding 466 FEC Object Transmission Information is communicated out-of-band to 467 receivers is outside the scope of this document. 469 It is also possible that there is a portion of the FEC Object 470 Transmission Information that may vary from object to object that is 471 carried in-band, for example in the CodePoint field or in Header 472 Extensions. How this is done is outside the scope of this document. 473 In this case the FEC Object Transmission Information is associated 474 with the object identified by the TOI carried in the packet. 476 2.4. Session Description 478 The Session Description that a receiver is REQUIRED to obtain before 479 joining an ALC session MUST contain the following information: 481 o The multiple rate congestion control building block to be used for 482 the session; 484 o The sender IP address; 486 o The number of channels in the session; 488 o The address and port number used for each channel in the session; 490 o The Transport Session ID (TSI) to be used for the session; 492 o An indication of whether or not the session carries packets for 493 more than one object; 495 o If Header Extensions are to be used, the format of these Header 496 Extensions. 498 o Enough information to determine the packet authentication scheme 499 being used, if it is being used. 501 How the Session Description is communicated to receivers is outside 502 the scope of this document. 504 The Codepoint field within the LCT portion of the header CAN be used 505 to communicate in-band some of the dynamically changing information 506 within a session. To do this, a mapping between Codepoint values and 507 the different dynamic settings MUST be included within the Session 508 Description, and then settings to be used are communicated via the 509 Codepoint value placed into each packet. For example, it is possible 510 that multiple objects are delivered within the same session and that 511 a different FEC encoding algorithm is used for different types of 512 objects. Then the Session Description could contain the mapping 513 between Codepoint values and FEC Encoding IDs. As another example, 514 it is possible that a different packet authentication scheme is used 515 for different packets sent to the session. In this case, the mapping 516 between the packet authentication scheme and Codepoint values could 517 be provided in the Session Description. Combinations of settings can 518 be mapped to Codepoint values as well. For example, a particular 519 combination of a FEC Encoding ID and a packet authentication scheme 520 could be associated with a Codepoint value. 522 The Session Description could also include, but is not limited to: 524 o The mappings between combinations of settings and Codepoint 525 values; 527 o The data rates used for each channel; 529 o The length of the packet payload; 531 o Any information that is relevant to each object being transported, 532 such as the Object Transmission Information for each object, when 533 the object will be available within the session and for how long. 535 The Session Description could be in a form such as SDP as defined in 536 [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime 537 headers as defined in [RFC2616], etc. It might be carried in a 538 session announcement protocol such as SAP as defined in [RFC2974], 539 obtained using a proprietary session control protocol, located on a 540 web page with scheduling information, or conveyed via E-mail or other 541 out-of-band methods. Discussion of Session Description formats and 542 methods for communication of Session Descriptions to receivers is 543 beyond the scope of this document. 545 2.5. Packet authentication building block 547 It is RECOMMENDED that implementors of ALC use some packet 548 authentication scheme to protect the protocol from attacks. An 549 example of a possibly suitable scheme is described in [PER2001]. 550 Packet authentication in ALC, if used, is to be integrated through 551 the Header Extension support for packet authentication provided in 552 the LCT building block. 554 3. Conformance Statement 556 This Protocol Instantiation document, in conjunction with the LCT 557 building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block 558 [RFC5052] and with a multiple rate congestion control building block 559 completely specifies a working reliable multicast transport protocol 560 that conforms to the requirements described in [RFC2357]. 562 4. Functionality Definition 564 This section describes the format and functionality of the data 565 packets carried in an ALC session as well as the sender and receiver 566 operations for a session. 568 4.1. Packet format used by ALC 570 The packet format used by ALC is the UDP header followed by the LCT 571 header followed by the FEC Payload ID followed by the packet payload. 572 The LCT header is defined in the LCT building block 573 [I-D.ietf-rmt-bb-lct-revised] and the FEC Payload ID is described in 574 the FEC building block [RFC5052]. The Congestion Control Information 575 field in the LCT header contains the REQUIRED Congestion Control 576 Information that is described in the multiple rate congestion control 577 building block used. The packet payload contains encoding symbols 578 generated from an object. If more than one object is carried in the 579 session then the Transmission Object ID (TOI) within the LCT header 580 MUST be used to identify which object the encoding symbols are 581 generated from. Within the scope of an object, encoding symbols 582 carried in the payload of the packet are identified by the FEC 583 Payload ID as described in the FEC building block. 585 The version number of ALC specified in this document is 1. The 586 version number field of the LCT header MUST be interpreted as the ALC 587 version number field. This version of ALC implicitly makes use of 588 version 1 of the LCT building block defined in 589 [I-D.ietf-rmt-bb-lct-revised]. 591 The overall ALC packet format is depicted in Figure 2. The packet is 592 an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP 593 header. The ALC packet format has no dependencies on the IP version 594 number. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | UDP header | 600 | | 601 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 602 | LCT header | 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | FEC Payload ID | 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Encoding Symbol(s) | 609 | ... | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Figure 2: Overall ALC packet format 614 In some special cases an ALC sender may need to produce ALC packets 615 that do not contain any payload. This may be required, for example, 616 to signal the end of a session or to convey congestion control 617 information. These data-less packets do not contain the FEC Payload 618 ID either, but only the LCT header fields. The total datagram 619 length, conveyed by outer protocol headers (e.g., the IP or UDP 620 header), enables receivers to detect the absence of the ALC payload 621 and FEC Payload ID. 623 For ALC the length of the TSI field within the LCT header is REQUIRED 624 to be non-zero. This implies that the sender MUST NOT set both the 625 LCT flags S and H to zero. 627 4.2. LCT Header-Extension Fields 629 All senders and receivers implementing ALC MUST support the EXT_NOP 630 Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to 631 parse its content. The EXT_NOP and EXT_AUTH LCT Header Extensions 632 are defined in [I-D.ietf-rmt-bb-lct-revised] 634 This specification defines a new LCT Header Extension, "EXT_FTI", for 635 the purpose of communicating the FEC Object Transmission Information 636 in association with data packets of an object. The LCT Header 637 Extension Type for EXT_FTI is 64. 639 The Header Extension Content (HEC) field of the EXT_FTI LCT Header 640 Extension contains the encoded FEC Object Transmission Information as 641 defined in [RFC5052]. The format of the encoded FEC Object 642 Transmission Information is dependent on the FEC Scheme in use and so 643 is outside the scope of this document. 645 4.3. Sender Operation 647 The sender operation when using ALC includes all the points made 648 about the sender operation when using the LCT building block 649 [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and 650 the multiple rate congestion control building block. 652 A sender using ALC MUST make available the required Session 653 Description as described in Section 2.4. A sender also MUST make 654 available the required FEC Object Transmission Information as 655 described in Section 2.3. 657 Within a session a sender transmits a sequence of packets to the 658 channels associated with the session. The ALC sender MUST obey the 659 rules for filling in the CCI field in the packet headers and MUST 660 send packets at the appropriate rates to the channels associated with 661 the session as dictated by the multiple rate congestion control 662 building block. 664 The ALC sender MUST use the same TSI for all packets in the session. 665 Several objects MAY be delivered within the same ALC session. If 666 more than one object is to be delivered within a session then the 667 sender MUST use the TOI field and each object MUST be identified by a 668 unique TOI within the session, and the sender MUST use corresponding 669 TOI for all packets pertaining to the same object. The FEC Payload 670 ID MUST correspond to the encoding symbol(s) for the object carried 671 in the payload of the packet. 673 It is RECOMMENDED that packet authentication be used. If packet 674 authentication is used then the Header Extensions described in 675 Section 4.2 MUST be used to carry the authentication. 677 4.4. Receiver Operation 679 The receiver operation when using ALC includes all the points made 680 about the receiver operation when using the LCT building block 681 [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and 682 the multiple rate congestion control building block. 684 To be able to participate in a session, a receiver MUST obtain the 685 REQUIRED Session Description as listed in Section 2.4. How receivers 686 obtain a Session Description is outside the scope of this document. 688 To be able to be a receiver in a session, the receiver MUST be able 689 to process the ALC header. The receiver MUST be able to discard, 690 forward, store or process the other headers and the packet payload. 692 If a receiver is not able to process the ALC header, it MUST drop 693 from the session. 695 As described in Section 2.3, a receiver MUST obtain the required FEC 696 Object Transmission Information for each object for which the 697 receiver receives and processes packets. 699 Upon receipt of each packet the receiver proceeds with the following 700 steps in the order listed. 702 1. The receiver MUST parse the packet header and verify that it is a 703 valid header. If it is not valid then the packet MUST be 704 discarded without further processing. If multiple packets are 705 received that cannot be parsed then the receiver SHOULD leave the 706 session. 708 2. The receiver MUST verify that the sender IP address together with 709 the TSI carried in the header matches one of the (sender IP 710 address, TSI) pairs that was received in a Session Description 711 and that the receiver is currently joined to. If there is not a 712 match then the packet MUST be discarded without further 713 processing. If multiple packets are received with non-matching 714 (sender IP address, TSI) values then the receiver SHOULD leave 715 the session. If the receiver is joined to multiple ALC sessions 716 then the remainder of the steps are performed within the scope of 717 the (sender IP address, TSI) session of the received packet. 719 3. The receiver MUST process and act on the CCI field in accordance 720 with the multiple rate congestion control building block. 722 4. If more than one object is carried in the session, the receiver 723 MUST verify that the TOI carried in the LCT header is valid. If 724 the TOI is not valid, the packet MUST be discarded without 725 further processing. 727 5. The receiver SHOULD process the remainder of the packet, 728 including interpreting the other header fields appropriately, and 729 using the FEC Payload ID and the encoding symbol(s) in the 730 payload to reconstruct the corresponding object. 732 It is RECOMMENDED that packet authentication be used. If packet 733 authentication is used then it is RECOMMENDED that the receiver 734 immediately check the authenticity of a packet before proceeding with 735 step (3) above. If immediate checking is possible and if the packet 736 fails the check then the receiver MUST discard the packet and reduce 737 its reception rate to a minimum before continuing to regulate its 738 reception rate using the multiple rate congestion control. 740 Some packet authentication schemes such as TESLA [PER2001] do not 741 allow an immediate authenticity check. In this case the receiver 742 SHOULD check the authenticity of a packet as soon as possible, and if 743 the packet fails the check then it MUST be discarded before step (5) 744 above and reduce its reception rate to a minimum before continuing to 745 regulate its reception rate using the multiple rate congestion 746 control. 748 5. Security Considerations 750 The same security consideration that apply to the LCT, FEC and the 751 multiple rate congestion control building blocks also apply to ALC. 753 Because of the use of FEC, ALC is especially vulnerable to denial- 754 of-service attacks by attackers that try to send forged packets to 755 the session which would prevent successful reconstruction or cause 756 inaccurate reconstruction of large portions of the object by 757 receivers. ALC is also particularly affected by such an attack 758 because many receivers may receive the same forged packet. There are 759 two ways to protect against such attacks, one at the application 760 level and one at the packet level. It is RECOMMENDED that prevention 761 be provided at both levels. 763 At the application level, it is RECOMMENDED that an integrity check 764 on the entire received object be done once the object is 765 reconstructed to ensure it is the same as the sent object. Moreover, 766 in order to obtain strong cryptographic integrity protection a 767 digital signature verifiable by the receiver SHOULD be used to 768 provide this application level integrity check. However, if even one 769 corrupted or forged packet is used to reconstruct the object, it is 770 likely that the received object will be reconstructed incorrectly. 771 This will appropriately cause the integrity check to fail and in this 772 case the inaccurately reconstructed object SHOULD be discarded. 773 Thus, the acceptance of a single forged packet can be an effective 774 denial of service attack for distributing objects, but an object 775 integrity check at least prevents inadvertent use of inaccurately 776 reconstructed objects. The specification of an application level 777 integrity check of the received object is outside the scope of this 778 document. 780 At the packet level, it is RECOMMENDED that a packet level 781 authentication be used to ensure that each received packet is an 782 authentic and uncorrupted packet containing FEC data for the object 783 arriving from the specified sender. Packet level authentication has 784 the advantage that corrupt or forged packets can be discarded 785 individually and the received authenticated packets can be used to 786 accurately reconstruct the object. Thus, the effect of a denial of 787 service attack that injects forged packets is proportional only to 788 the number of forged packets, and not to the object size. Although 789 there is currently no IETF standard that specifies how to do 790 multicast packet level authentication, TESLA [PER2001] is a known 791 multicast packet authentication scheme that would work. 793 In addition to providing protection against reconstruction of 794 inaccurate objects, packet level authentication can also provide some 795 protection against denial of service attacks on the multiple rate 796 congestion control. Attackers can try to inject forged packets with 797 incorrect congestion control information into the multicast stream, 798 thereby potentially adversely affecting network elements and 799 receivers downstream of the attack, and much less significantly the 800 rest of the network and other receivers. Thus, it is also 801 RECOMMENDED that packet level authentication be used to protect 802 against such attacks. TESLA [PER2001] can also be used to some 803 extent to limit the damage caused by such attacks. However, with 804 TESLA a receiver can only determine if a packet is authentic several 805 seconds after it is received, and thus an attack against the 806 congestion control protocol can be effective for several seconds 807 before the receiver can react to slow down the session reception 808 rate. 810 Reverse Path Forwarding checks SHOULD be enabled in all network 811 routers and switches along the path from the sender to receivers to 812 limit the possibility of a bad agent injecting forged packets into 813 the multicast tree data path. 815 5.1. Baseline Secure ALC Operation 817 This section describes a baseline mode of secure ALC protocol 818 operation based on application of the IPsec security protocol. This 819 approach is documented here to provide a reference, interoperable 820 secure mode of operation. However, additional approaches to ALC 821 security, including other forms of IPsec application, MAY be 822 specified in the future. For example, the use of the EXT_AUTH header 823 extension could enable ALC-specific authentication or security 824 encapsulation headers similar to those of IPsec to be specified and 825 inserted into the ALC/LCT protocol message headers. This would allow 826 header compression techniques to be applied to IP and ALC protocol 827 headers when needed in a similar fashion to that of RTP [RFC1889] and 828 as preserved in the specification for Secure Real Time Protocol 829 (SRTP) [RFC3711]. 831 The baseline approach described is applicable to ALC operation 832 configured for SSM (or SSM-like) operation where there is a single 833 sender. The receiver set would maintain a single IPSec Security 834 Association (SA) for each ALC sender. 836 5.1.1. IPsec Approach 838 To suppor this baseline form of secure ALC one-to-many SSM operation, 839 each node SHALL be configured with a transport mode IPsec Security 840 Association and corresponding Security Policy Database (SPD) entry. 841 This entry will be used for sender-to-group multicast packet 842 authentication and optionally encryption. 844 The ALC sender SHALL use an IPsec SA configured for ESP protocol 845 [RFC4303] operation with the option for data origination 846 authentication enabled. It is also RECOMMENDED that this IPsec ESP 847 SA be also configured to provide confidentiality protection for IP 848 packets containing ALC protocol messages. This is suggested to make 849 the realization of complex replay attacks much more difficult. The 850 encryption key for this SA SHALL be preplaced at the sender and 851 receiver(s) prior to ALC protocol operation. Use of automated key 852 management is RECOMMENDED as a rekey SHALL be required prior to 853 expiration of the sequence space for the SA. This is necessary so 854 that receivers may use the built-in IPsec replay attack protection 855 possible for an IPsec SA with a single source (the ALC sender). Thus 856 the receivers SHALL enable replay attack protection for this SA used 857 to secure ALC sender traffic. The sender IPsec SPD entry MUST be 858 configured to process outbound packets to the destination address and 859 UDP port number of the applicable ALC session. 861 The ALC receiver(s) MUST be configured with the SA and SPD entry to 862 properly process the IPsec-secured packets from the sender. Note 863 that use of ESP confidentiality, as RECOMMENDED, for secure ALC 864 protocol operation makes it more difficult for adversaries to conduct 865 effective replay attacks that may mislead receivers on content 866 reception. This baseline approach can be used for ALC protocol 867 sessions with multiple senders if a distinct SA is established for 868 each sender. 870 It is anticipated in early deployments of this baseline approach to 871 ALC security that key management will be conducted out-of-band with 872 respect to ALC protocol operation. For ALC unidirectional operation, 873 it is possible that receivers may retrieve keying information from a 874 central server via out-of-band (with respect to ALC) communication as 875 needed or otherwise conduct group key updates with a similar 876 centralized approach. However, it may be possible with some key 877 management schemes for rekey messages to be transmitted to the group 878 as a message or transport object within the ALC reliable transfer 879 session. Additional specification is necessary to define an in-band 880 key management scheme for ALC sessions perhaps using the mechanisms 881 of the automated group key management specifications cited in this 882 document. 884 5.1.2. IPsec Requirements 886 In order to implement this secure mode of ALC protocol operation, the 887 following IPsec capabilities are required. 889 5.1.2.1. Selectors 891 The implementation MUST be able to use the source address, 892 destination address, protocol (UDP), and UDP port numbers as 893 selectors in the SPD. 895 5.1.2.2. Mode 897 IPsec in transport mode MUST be supported. The use of IPsec 898 [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED 899 such that unauthenticated packets are not received by the ALC 900 protocol implementation . 902 5.1.2.3. Key Management 904 An automated key management scheme for group key distribution and 905 rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830] 906 SHOULD be used. Relatively short-lived ALC sessions MAY be able to 907 use Manual Keying with a single, preplaced key, particularly if 908 Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec 909 implementation used. It should also be noted that it may be possible 910 for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be 911 included in the ALC application reliable data transmission as 912 transport objects if appropriate interfaces were available between 913 the ALC application and the key management daemon. 915 5.1.2.4. Security Policy 917 Receivers SHOULD accept connections only from the designated, 918 authorized sender(s). It is expected that appropriate key management 919 will provide encryption keys only to receivers authorized to 920 participate in a designated session. The approach outlined here 921 allows receiver sets to be controlled on a per-sender basis. 923 5.1.2.5. Authentication and Encryption 925 Large ALC group sizes may necessitate some form of key management 926 that does rely upon shared secrets. The GDOI and GSAKMP protocols 927 mentioned here allow for certificate-based authentication. These 928 certificates SHOULD use IP addresses for authentication. However, it 929 is likely that available group key management implementations will 930 not be ALC-specific. 932 5.1.2.6. Availability 934 The IPsec requirements profile outlined here is commonly available on 935 many potential ALC hosts. The principal issue is that configuration 936 and operation of IPsec typically requires privileged user 937 authorization. Automated key management implementations are 938 typically configured with the privileges necessary to effect system 939 IPsec configuration needed. 941 6. IANA Considerations 943 This specification registers the following LCT Header Extensions 944 Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength: 946 +-------+---------+--------------------+ 947 | Value | Name | Reference | 948 +-------+---------+--------------------+ 949 | 64 | EXT_FTI | This specification | 950 +-------+---------+--------------------+ 952 7. Acknowledgments 954 This specification is substantially based on RFC3450 [RFC3450] and 955 thus credit for the authorship of this document is primarily due to 956 the authors of RFC3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, 957 Luigi Rizzo and Jon Crowcroft. Vincent Roca, Justin Chapweske and 958 Roger Kermode also contributed to RFC3450. Additional thanks are due 959 to Vincent Roca and Rod Walsh for contributions to this update to 960 Proposed Standard. 962 8. Changes from RFC3450 964 This section summarises the changes that were made from the 965 Experimental version of this specification published as RFC3450 966 [RFC3450]: 968 o Update all references to the obsoleted RFC 2068 to RFC 2616 970 o Removed the 'Statement of Intent' from the introduction (The 971 statement of intent was meant to clarify the "Experimental" status 972 of RFC3450.) 974 o Removed the 'Intellectual Property Issues' Section and replaced 975 with a standard IPR Statement 977 o Remove material duplicated in LCT 979 o Update references for LCT and FEC Building Block to new versions 980 and align with changes in the FEC Building Block. 982 o Split normative and informative references 984 o Material applicable in a general LCT context, not just for ALC has 985 been moved to LCT 987 o The first bit of the "Protocol Specific Indication" in the LCT 988 Header is defined as a "Source Packet Indication". This is used 989 in the case that an FEC Scheme defines two FEC Payload ID formats, 990 one of which is for packets containing only source symbols which 991 can be processed by receivers that do not support FEC Decoding. 993 o Definition and IANA registration of the EXT_FTI LCT Header 994 Extension 996 9. References 998 9.1. Normative references 1000 [I-D.ietf-rmt-bb-lct-revised] 1001 Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1002 Transport (LCT) Building Block", 1003 draft-ietf-rmt-bb-lct-revised-07 (work in progress), 1004 July 2008. 1006 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1007 August 1980. 1009 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1010 RFC 1112, August 1989. 1012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1013 Requirement Levels", BCP 14, RFC 2119, March 1997. 1015 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1016 Protocol", RFC 2327, April 1998. 1018 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1019 Criteria for Evaluating Reliable Multicast Transport and 1020 Application Protocols", RFC 2357, June 1998. 1022 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1023 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1024 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1026 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1027 Announcement Protocol", RFC 2974, October 2000. 1029 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1030 Types", RFC 3023, January 2001. 1032 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1033 Internet Protocol", RFC 4301, December 2005. 1035 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1036 RFC 4303, December 2005. 1038 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1039 Correction (FEC) Building Block", RFC 5052, August 2007. 1041 9.2. Informative references 1043 [PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, 1044 "Efficient and Secure Source Authentication for 1045 Multicast", Network and Distributed System Security 1046 Symposium, NDSS 2001, pp. 35-46 , February 2001. 1048 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 1049 Jacobson, "RTP: A Transport Protocol for Real-Time 1050 Applications", RFC 1889, January 1996. 1052 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1053 Floyd, S., and M. Luby, "Reliable Multicast Transport 1054 Building Blocks for One-to-Many Bulk-Data Transfer", 1055 RFC 3048, January 2001. 1057 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 1058 Reliable Multicast Transport (RMT) Building Blocks and 1059 Protocol Instantiation documents", RFC 3269, April 2002. 1061 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 1062 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 1063 Instantiation", RFC 3450, December 2002. 1065 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1066 M., and J. Crowcroft, "The Use of Forward Error Correction 1067 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1069 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1070 Group Domain of Interpretation", RFC 3547, July 2003. 1072 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1073 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1074 RFC 3711, March 2004. 1076 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1077 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1078 August 2004. 1080 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1081 "GSAKMP: Group Secure Association Key Management 1082 Protocol", RFC 4535, June 2006. 1084 Authors' Addresses 1086 Michael Luby 1087 Digital Fountain 1088 39141 Civic Center Dr. 1089 Suite 300 1090 Fremont, CA 94538 1091 US 1093 Email: luby@digitalfountain.com 1095 Mark Watson 1096 Digital Fountain 1097 39141 Civic Center Dr. 1098 Suite 300 1099 Fremont, CA 94538 1100 US 1102 Email: mark@digitalfountain.com 1104 Lorenzo Vicisano 1105 Digital Fountain 1106 39141 Civic Center Dr. 1107 Suite 300 1108 Fremont, CA 94538 1109 US 1111 Email: lorenzo@digitalfountain.com 1113 Full Copyright Statement 1115 Copyright (C) The IETF Trust (2008). 1117 This document is subject to the rights, licenses and restrictions 1118 contained in BCP 78, and except as set forth therein, the authors 1119 retain all their rights. 1121 This document and the information contained herein are provided on an 1122 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1123 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1124 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1125 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1126 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1127 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1129 Intellectual Property 1131 The IETF takes no position regarding the validity or scope of any 1132 Intellectual Property Rights or other rights that might be claimed to 1133 pertain to the implementation or use of the technology described in 1134 this document or the extent to which any license under such rights 1135 might or might not be available; nor does it represent that it has 1136 made any independent effort to identify any such rights. Information 1137 on the procedures with respect to rights in RFC documents can be 1138 found in BCP 78 and BCP 79. 1140 Copies of IPR disclosures made to the IETF Secretariat and any 1141 assurances of licenses to be made available, or the result of an 1142 attempt made to obtain a general license or permission for the use of 1143 such proprietary rights by implementers or users of this 1144 specification can be obtained from the IETF on-line IPR repository at 1145 http://www.ietf.org/ipr. 1147 The IETF invites any interested party to bring to its attention any 1148 copyrights, patents or patent applications, or other proprietary 1149 rights that may cover technology that may be required to implement 1150 this standard. Please address the information to the IETF at 1151 ietf-ipr@ietf.org.