idnits 2.17.1 draft-ietf-rmt-pi-alc-revised-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2009) is 5299 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Downref: Normative reference to an Experimental RFC: RFC 3738 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-10) exists of draft-ietf-msec-tesla-for-alc-norm-08 == Outdated reference: A later version (-06) exists of draft-ietf-rmt-simple-auth-for-alc-norm-01 -- 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: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 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) Qualcomm Inc. 6 Intended status: Standards Track October 20, 2009 7 Expires: April 23, 2010 9 Asynchronous Layered Coding (ALC) Protocol Instantiation 10 draft-ietf-rmt-pi-alc-revised-09 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 23, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document describes the Asynchronous Layered Coding (ALC) 59 protocol, a massively scalable reliable content delivery protocol. 60 Asynchronous Layered Coding combines the Layered Coding Transport 61 (LCT) building block, a multiple rate congestion control building 62 block and the Forward Error Correction (FEC) building block to 63 provide congestion controlled reliable asynchronous delivery of 64 content to an unlimited number of concurrent receivers from a single 65 sender. This document obsoletes RFC3450. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Delivery service models . . . . . . . . . . . . . . . . . 5 71 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.3. Environmental Requirements and Considerations . . . . . . 6 73 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 7 74 2.1. LCT building block . . . . . . . . . . . . . . . . . . . . 8 75 2.2. Multiple rate congestion control building block . . . . . 10 76 2.3. FEC building block . . . . . . . . . . . . . . . . . . . . 11 77 2.4. Session Description . . . . . . . . . . . . . . . . . . . 12 78 2.5. Packet authentication building block . . . . . . . . . . . 14 79 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 15 80 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 16 81 4.1. Packet format used by ALC . . . . . . . . . . . . . . . . 16 82 4.2. LCT Header-Extension Fields . . . . . . . . . . . . . . . 17 83 4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 18 84 4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 18 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 21 87 5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 21 88 5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 22 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 90 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 91 8. Changes from RFC3450 . . . . . . . . . . . . . . . . . . . . . 27 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 9.1. Normative references . . . . . . . . . . . . . . . . . . . 28 94 9.2. Informative references . . . . . . . . . . . . . . . . . . 28 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 97 1. Introduction 99 This document describes a massively scalable reliable content 100 delivery protocol, Asynchronous Layered Coding (ALC), for multiple 101 rate congestion controlled reliable content delivery. The protocol 102 is specifically designed to provide massive scalability using IP 103 multicast as the underlying network service. Massive scalability in 104 this context means the number of concurrent receivers for an object 105 is potentially in the millions, the aggregate size of objects to be 106 delivered in a session ranges from hundreds of kilobytes to hundreds 107 of gigabytes, each receiver can initiate reception of an object 108 asynchronously, the reception rate of each receiver in the session is 109 the maximum fair bandwidth available between that receiver and the 110 sender, and all of this can be supported using a single sender. 112 Because ALC is focused on reliable content delivery, the goal is to 113 deliver objects as quickly as possible to each receiver while at the 114 same time remaining network friendly to competing traffic. Thus, the 115 congestion control used in conjunction with ALC should strive to 116 maximize use of available bandwidth between receivers and the sender 117 while at the same time backing off aggressively in the face of 118 competing traffic. 120 The sender side of ALC consists of generating packets based on 121 objects to be delivered within the session and sending the 122 appropriately formatted packets at the appropriate rates to the 123 channels associated with the session. The receiver side of ALC 124 consists of joining appropriate channels associated with the session, 125 performing congestion control by adjusting the set of joined channels 126 associated with the session in response to detected congestion, and 127 using the packets to reliably reconstruct objects. All information 128 flow in an ALC session is in the form of data packets sent by a 129 single sender to channels that receivers join to receive data. 131 ALC does specify the Session Description needed by receivers before 132 they join a session, but the mechanisms by which receivers obtain 133 this required information is outside the scope of ALC. An 134 application that uses ALC may require that receivers report 135 statistics on their reception experience back to the sender, but the 136 mechanisms by which receivers report back statistics is outside the 137 scope of ALC. In general, ALC is designed to be a minimal protocol 138 instantiation that provides reliable content delivery without 139 unnecessary limitations to the scalability of the basic protocol. 141 This document is a product of the IETF RMT WG and follows the general 142 guidelines provided in [RFC3269]. 144 A previous version of this document was published in the 145 "Experimental" category as [RFC3450] and is obsoleted by this 146 document. 148 This Proposed Standard specification is thus based on and backwards 149 compatible with the protocol defined in [RFC3450] updated according 150 to accumulated experience and growing protocol maturity since its 151 original publication. Said experience applies both to this 152 specification itself and to congestion control strategies related to 153 the use of this specification. 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in BCP 14, [RFC2119]. 159 1.1. Delivery service models 161 ALC can support several different reliable content delivery service 162 models as described in [RFC5651]. 164 1.2. Scalability 166 Massive scalability is a primary design goal for ALC. IP multicast 167 is inherently massively scalable, but the best effort service that it 168 provides does not provide session management functionality, 169 congestion control or reliability. ALC provides all of this on top 170 of IP multicast without sacrificing any of the inherent scalability 171 of IP multicast. ALC has the following properties: 173 o To each receiver, it appears as if though there is a dedicated 174 session from the sender to the receiver, where the reception rate 175 adjusts to congestion along the path from sender to receiver. 177 o To the sender, there is no difference in load or outgoing rate if 178 one receiver is joined to the session or a million (or any number 179 of) receivers are joined to the session, independent of when the 180 receivers join and leave. 182 o No feedback packets are required from receivers to the sender. 184 o Almost all packets in the session that pass through a bottleneck 185 link are utilized by downstream receivers, and the session shares 186 the link with competing flows fairly in proportion to their 187 utility. 189 Thus, ALC provides a massively scalable content delivery transport 190 that is network friendly. 192 ALC intentionally omits any application specific features that could 193 potentially limit its scalability. By doing so, ALC provides a 194 minimal protocol that is massively scalable. Applications may be 195 built on top of ALC to provide additional features that may limit the 196 scalability of the application. Such applications are outside the 197 scope of this document. 199 1.3. Environmental Requirements and Considerations 201 All of the environmental requirements and considerations that apply 202 to the LCT building block [RFC5651], the FEC building block 203 [RFC5052], the multiple rate congestion control building block and to 204 any additional building blocks that ALC uses also apply to ALC. 206 The IP multicast model defined in [RFC1112] is commonly known as Any- 207 Source Multicast (ASM), in contrast to Source-Specific Multicast 208 (SSM) which is defined in [RFC3569]. One issues that is specific to 209 ALC with respect to ASM is the way the multiple rate congestion 210 control building block interacts with ASM. The congestion control 211 building block may use the measured difference in time between when a 212 join to a channel is sent and when the first packet from the channel 213 arrives in determining the receiver reception rate. The congestion 214 control building block may also use packet sequence numbers per 215 channel to measure losses, and this is also used to determine the 216 receiver reception rate. These features raise two concerns with 217 respect to ASM: The time difference between when the join to a 218 channel is sent and when the first packet arrives can be significant 219 due to the use of Rendezvous Points (RPs) and the Multicast Source 220 Discovery Protocol (MSDP) [RFC3618] protocol, and packets can be lost 221 in the switch over from the (*,G) join to the RP and the (S,G) join 222 directly to the sender. Both of these issues could potentially 223 substantially degrade the reception rate of receivers. To ameliorate 224 these concerns, it is recommended during deployment to ensure that 225 the RP be as close to the sender as possible. SSM does not share 226 these same concerns. For a fuller consideration of these issues, 227 consult the multiple rate congestion control building block. 229 2. Architecture Definition 231 ALC uses the LCT building block [RFC5651] to provide in-band session 232 management functionality. ALC uses a multiple rate congestion 233 control building block that is compliant with [RFC2357] to provide 234 congestion control that is feedback free. Receivers adjust their 235 reception rates individually by joining and leaving channels 236 associated with the session. ALC uses the FEC building block 237 [RFC5052] to provide reliability. The sender generates encoding 238 symbols based on the object to be delivered using FEC codes and sends 239 them in packets to channels associated with the session. Receivers 240 simply wait for enough packets to arrive in order to reliably 241 reconstruct the object. Thus, there is no request for retransmission 242 of individual packets from receivers that miss packets in order to 243 assure reliable reception of an object, and the packets and their 244 rate of transmission out of the sender can be independent of the 245 number and the individual reception experiences of the receivers. 247 The definition of a session for ALC is the same as it is for LCT. An 248 ALC session comprises multiple channels originating at a single 249 sender that are used for some period of time to carry packets 250 pertaining to the transmission of one or more objects that can be of 251 interest to receivers. Congestion control is performed over the 252 aggregate of packets sent to channels belonging to a session. The 253 fact that an ALC session is restricted to a single sender does not 254 preclude the possibility of receiving packets for the same objects 255 from multiple senders. However, each sender would be sending packets 256 to a a different session to which congestion control is individually 257 applied. Although receiving concurrently from multiple sessions is 258 allowed, how this is done at the application level is outside the 259 scope of this document. 261 ALC is a protocol instantiation as defined in [RFC3048]. This 262 document describes version 1 of ALC which MUST use version 1 of LCT 263 described in [RFC5651]. Like LCT, ALC is designed to be used with 264 the IP multicast network service. This specification defines ALC as 265 payload of the UDP transport protocol [RFC0768] that supports IP 266 multicast delivery of packets. 268 The ALC packet format is illustrated in Figure 1. An ALC packet 269 header immediately follows the IP/UDP header and consists of the 270 default LCT header that is described in [RFC5651] followed by the FEC 271 Payload ID that is described in [RFC5052]. The Congestion Control 272 Information field within the LCT header carries the required 273 Congestion Control Information that is described in the multiple rate 274 congestion control building block specified that is compliant with 275 [RFC2357]. The packet payload that follows the ALC packet header 276 consists of encoding symbols that are identified by the FEC Payload 277 ID as described in [RFC5052]. 279 +----------------------------------------+ 280 | IP Header | 281 +----------------------------------------+ 282 | UDP Header | 283 +----------------------------------------+ 284 | LCT Header | 285 +----------------------------------------+ 286 | FEC Payload Id | 287 +----------------------------------------+ 288 | Encoding Symbols | 289 +----------------------------------------+ 291 Figure 1: ALC Packet Format 293 Each receiver is required to obtain a Session Description before 294 joining an ALC session. As described later, the Session Description 295 includes out-of-band information required for the LCT, FEC and the 296 multiple rate congestion control building blocks. The FEC Object 297 Transmission Information specified in the FEC building block 298 [RFC5052] required for each object to be received by a receiver can 299 be communicated to a receiver either out-of-band or in-band using a 300 Header Extension. The means for communicating the Session 301 Description and the FEC Object Transmission Information to a receiver 302 is outside the scope of this document. 304 2.1. LCT building block 306 LCT requires receivers to be able to uniquely identify and 307 demultiplex packets associated with an LCT session, and ALC inherits 308 and strengthens this requirement. A Transport Session Identifier 309 (TSI) MUST be associated with each session and MUST be carried in the 310 LCT header of each ALC packet. The TSI is scoped by the sender IP 311 address, and the (sender IP address, TSI) pair MUST uniquely identify 312 the session. 314 The LCT header contains a Congestion Control Information (CCI) field 315 that MUST be used to carry the Congestion Control Information from 316 the specified multiple rate congestion control protocol. There is a 317 field in the LCT header that specifies the length of the CCI field, 318 and the multiple rate congestion control building block MUST uniquely 319 identify a format of the CCI field that corresponds to this length. 321 The LCT header contains a Codepoint field that MAY be used to 322 communicate to a receiver the settings for information that may vary 323 during a session. If used, the mapping between settings and 324 Codepoint values is to be communicated in the Session Description, 325 and this mapping is outside the scope of this document. For example, 326 the FEC Encoding ID that is part of the FEC Object Transmission 327 Information as specified in the FEC building block [RFC5052] could 328 vary for each object carried in the session, and the Codepoint value 329 could be used to communicate the FEC Encoding ID to be used for each 330 object. The mapping between FEC Encoding IDs and Codepoints could 331 be, for example, the identity mapping. 333 If more than one object is to be carried within a session then the 334 Transmission Object Identifier (TOI) MUST be used in the LCT header 335 to identify which packets are to be associated with which objects. 336 In this case the receiver MUST use the TOI to associate received 337 packets with objects. The TOI is scoped by the IP address of the 338 sender and the TSI, i.e., the TOI is scoped by the session. The TOI 339 for each object is REQUIRED to be unique within a session, but is not 340 required be unique across sessions. Furthermore, the same object MAY 341 have a different TOI in different sessions. The mapping between TOIs 342 and objects carried in a session is outside the scope of this 343 document. 345 If only one object is carried within a session then the TOI MAY be 346 omitted from the LCT header. 348 The LCT header from version 1 of the LCT building block [RFC5651] 349 MUST be used. 351 The LCT Header includes a two-bit Protocol Specific Indication (PSI) 352 field in bits 6 and 7 of the first word of the LCT header. These two 353 bits are used by ALC as follows: 355 0 1 2 3 356 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 357 +-+-+ 358 ...|X|Y|... 359 +-+-+ 361 Figure 2: PSI bits within LCT Headder 363 PSI bit X - Source Packet Indicator (SPI) 365 PSI bit Y - Reserved 367 The Source Packet Indicator is used with systematic FEC Schemes which 368 define a different FEC Payload ID format for packets containing only 369 source data compared to the FEC Payload ID format for packets 370 containing repair data. For such FEC Schemes, then the SPI MUST be 371 set to 1 when the FEC Payload ID format for packets containing only 372 source data is used and the SPI MUST be set to zero, when the FEC 373 Payload ID for packerts containing repair data is used. In the case 374 of FEC Schemes which define only a single FEC Payload ID format, then 375 the SPI MUST be set to zero by the sender and MUST be ignored by the 376 receiver. 378 Support of two FEC Payload ID formats allows FEC Payload ID 379 information which is only of relevance when FEC decoding is to be 380 performed to be provided in the FEC Payload ID format for packets 381 containing repair data. This information need not be processed by 382 receivers which do not perform FEC decoding (either because no FEC 383 decoding is required or because the receiver does not support FEC 384 decoding). 386 2.2. Multiple rate congestion control building block 388 At a minimum, implementions of ALC MUST support [RFC3738]. Note that 389 [RFC3738] has been published in the "Experimental" category and thus 390 has lower maturity level than the present document. Caution should 391 be used since it may be less stable than this document. 393 Congestion control MUST be applied to all packets within a session 394 independently of which information about which object is carried in 395 each packet. Multiple rate congestion control is specified because 396 of its suitability to scale massively and because of its suitability 397 for reliable content delivery. [RFC3738] specifies in-band 398 Congestion Control Information (CCI) that MUST be carried in the CCI 399 field of the LCT header. 401 Alternative multiple rate congestion control building blocks MAY be 402 supported. The multiple rate congestion control building block MAY 403 specify more than one format for the CCI field, but it MUST specify 404 at most one format for each of the possible lengths 32, 64, 96 or 128 405 bits. The value of C in the LCT header that determines the length of 406 the CCI field MUST correspond to one of the lengths for the CCI 407 defined in the multiple rate congestion control building block, this 408 length MUST be the same for all packets sent to a session, and the 409 CCI format that corresponds to the length as specified in the 410 multiple rate congestion control building block MUST be the format 411 used for the CCI field in the LCT header. 413 When using a multiple rate congestion control building block a sender 414 sends packets in the session to several channels at potentially 415 different rates. Then, individual receivers adjust their reception 416 rate within a session by adjusting which set of channels they are 417 joined to at each point in time depending on the available bandwidth 418 between the receiver and the sender, but independent of other 419 receivers. 421 2.3. FEC building block 423 The FEC building block [RFC5052] provides reliable object delivery 424 within an ALC session. Each object sent in the session is 425 independently encoded using FEC codes as described in [RFC3453], 426 which provide a more in-depth description of the use of FEC codes in 427 reliable content delivery protocols. All packets in an ALC session 428 MUST contain an FEC Payload ID in a format that is compliant with the 429 FEC Scheme in use. The FEC Payload ID uniquely identifies the 430 encoding symbols that constitute the payload of each packet, and the 431 receiver MUST use the FEC Payload ID to determine how the encoding 432 symbols carried in the payload of the packet were generated from the 433 object as described in the FEC building block. 435 As described in [RFC5052], a receiver is REQUIRED to obtain the FEC 436 Object Transmission Information for each object for which data 437 packets are received from the session. In the context of ALC, the 438 FEC Object Transmission Information includes: 440 o The FEC Encoding ID. 442 o If an Under-Specified FEC Encoding ID is used then the FEC 443 Instance ID associated with the FEC Encoding ID. 445 o For each object in the session, the transfer length of the object 446 in bytes. 448 Additional FEC Object Transmission Information may be required 449 depending on the FEC Scheme that is used (identified by the FEC 450 Encoding ID). 452 Some of the FEC Object Transmission Information MAY be implicit based 453 on the FEC Scheme and/or implementation. As an example, source block 454 lengths may be derived by a fixed algorithm from the object length. 455 As another example, it may be that all source blocks are the same 456 length and this is what is passed out-of-band to the receiver. As 457 another example, it could be that the full sized source block length 458 is provided and this is the length used for all but the last source 459 block, which is calculated based on the full source block length and 460 the object length. As another example, it could be that the same FEC 461 Encoding ID and FEC Instance ID are always used for a particular 462 application and thus the FEC Encoding ID and FEC Instance ID are 463 implicitly defined. 465 Sometimes the objects that will be sent in a session are completely 466 known before the receiver joins the session, in which case the FEC 467 Object Transmission Information for all objects in the session can be 468 communicated to receivers before they join the session. At other 469 times the objects may not know when the session begins, or receivers 470 may join a session in progress and may not be interested in some 471 objects for which transmission has finished, or receivers may leave a 472 session before some objects are even available within the session. 473 In these cases, the FEC Object Transmission Information for each 474 object may be dynamically communicated to receivers at or before the 475 time packets for the object are received from the session. This may 476 be accomplished using either an out-of-band mechanism, in-band using 477 the Codepoint field or a Header Extension, or any combination of 478 these methods. How the FEC Object Transmission Information is 479 communicated to receivers is outside the scope of this document. 481 If packets for more than one object are transmitted within a session 482 then a Transmission Object Identifier (TOI) that uniquely identifies 483 objects within a session MUST appear in each packet header. Portions 484 of the FEC Object Transmission Information could be the same for all 485 objects in the session, in which case these portions can be 486 communicated to the receiver with an indication that this applies to 487 all objects in the session. These portions may be implicitly 488 determined based on the application, e.g., an application may use the 489 same FEC Encoding ID for all objects in all sessions. If there is a 490 portion of the FEC Object Transmission Information that may vary from 491 object to object and if this FEC Object Transmission Information is 492 communicated to a receiver out-of-band then the TOI for the object 493 MUST also be communicated to the receiver together with the 494 corresponding FEC Object Transmission Information, and the receiver 495 MUST use the corresponding FEC Object Transmission Information for 496 all packets received with that TOI. How the TOI and corresponding 497 FEC Object Transmission Information is communicated out-of-band to 498 receivers is outside the scope of this document. 500 It is also possible that there is a portion of the FEC Object 501 Transmission Information that may vary from object to object that is 502 carried in-band, for example in the CodePoint field or in Header 503 Extensions. How this is done is outside the scope of this document. 504 In this case the FEC Object Transmission Information is associated 505 with the object identified by the TOI carried in the packet. 507 2.4. Session Description 509 Before a receiver can join an ALC session, the receiver needs to 510 obtain a session description that contains the following information: 512 o The multiple rate congestion control building block to be used for 513 the session; 515 o The sender IP address; 517 o The number of channels in the session; 519 o The address and port number used for each channel in the session; 521 o The Transport Session ID (TSI) to be used for the session; 523 o An indication of whether or not the session carries packets for 524 more than one object; 526 o If Header Extensions are to be used, the format of these Header 527 Extensions. 529 o Enough information to determine the packet authentication scheme 530 being used, if it is being used. 532 How the Session Description is communicated to receivers is outside 533 the scope of this document. 535 The Codepoint field within the LCT portion of the header CAN be used 536 to communicate in-band some of the dynamically changing information 537 within a session. To do this, a mapping between Codepoint values and 538 the different dynamic settings MUST be included within the Session 539 Description, and then settings to be used are communicated via the 540 Codepoint value placed into each packet. For example, it is possible 541 that multiple objects are delivered within the same session and that 542 a different FEC encoding algorithm is used for different types of 543 objects. Then the Session Description could contain the mapping 544 between Codepoint values and FEC Encoding IDs. As another example, 545 it is possible that a different packet authentication scheme is used 546 for different packets sent to the session. In this case, the mapping 547 between the packet authentication scheme and Codepoint values could 548 be provided in the Session Description. Combinations of settings can 549 be mapped to Codepoint values as well. For example, a particular 550 combination of a FEC Encoding ID and a packet authentication scheme 551 could be associated with a Codepoint value. 553 The Session Description could also include, but is not limited to: 555 o The mappings between combinations of settings and Codepoint 556 values; 558 o The data rates used for each channel; 560 o The length of the packet payload; 561 o Any information that is relevant to each object being transported, 562 such as the Object Transmission Information for each object, when 563 the object will be available within the session and for how long. 565 The Session Description could be in a form such as SDP as defined in 566 [RFC4566], or XML metadata as defined in [RFC3023], or HTTP/Mime 567 headers as defined in [RFC2616], etc. It might be carried in a 568 session announcement protocol such as SAP as defined in [RFC2974], 569 obtained using a proprietary session control protocol, located on a 570 web page with scheduling information, or conveyed via E-mail or other 571 out-of-band methods. Discussion of Session Description formats and 572 methods for communication of Session Descriptions to receivers is 573 beyond the scope of this document. 575 2.5. Packet authentication building block 577 It is RECOMMENDED that implementors of ALC use some packet 578 authentication scheme to protect the protocol from attacks. Suitable 579 schemes are described in [I-D.ietf-msec-tesla-for-alc-norm] and 580 [I-D.ietf-rmt-simple-auth-for-alc-norm]. 582 3. Conformance Statement 584 This Protocol Instantiation document, in conjunction with the LCT 585 building block [RFC5651], the FEC building block [RFC5052] and 586 [RFC3738] completely specifies a working reliable multicast transport 587 protocol that conforms to the requirements described in [RFC2357]. 589 4. Functionality Definition 591 This section describes the format and functionality of the data 592 packets carried in an ALC session as well as the sender and receiver 593 operations for a session. 595 4.1. Packet format used by ALC 597 The packet format used by ALC is the UDP header followed by the LCT 598 header followed by the FEC Payload ID followed by the packet payload. 599 The LCT header is defined in the LCT building block [RFC5651] and the 600 FEC Payload ID is described in the FEC building block [RFC5052]. The 601 Congestion Control Information field in the LCT header contains the 602 required Congestion Control Information that is described in the 603 multiple rate congestion control building block used. The packet 604 payload contains encoding symbols generated from an object. If more 605 than one object is carried in the session then the Transmission 606 Object ID (TOI) within the LCT header MUST be used to identify which 607 object the encoding symbols are generated from. Within the scope of 608 an object, encoding symbols carried in the payload of the packet are 609 identified by the FEC Payload ID as described in the FEC building 610 block. 612 The version number of ALC specified in this document is 1. The 613 version number field of the LCT header MUST be interpreted as the ALC 614 version number field. This version of ALC implicitly makes use of 615 version 1 of the LCT building block defined in [RFC5651]. 617 The overall ALC packet format is depicted in Figure 3. The packet is 618 an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP 619 header. The ALC packet format has no dependencies on the IP version 620 number. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | UDP header | 626 | | 627 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 628 | LCT header | 629 | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | FEC Payload ID | 632 | | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Encoding Symbol(s) | 635 | ... | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Figure 3: Overall ALC packet format 640 In some special cases an ALC sender may need to produce ALC packets 641 that do not contain any payload. This may be required, for example, 642 to signal the end of a session or to convey congestion control 643 information. These data-less packets do not contain the FEC Payload 644 ID either, but only the LCT header fields. The total datagram 645 length, conveyed by outer protocol headers (e.g., the IP or UDP 646 header), enables receivers to detect the absence of the ALC payload 647 and FEC Payload ID. 649 For ALC the length of the TSI field within the LCT header is REQUIRED 650 to be non-zero. This implies that the sender MUST NOT set both the 651 LCT flags S and H to zero. 653 4.2. LCT Header-Extension Fields 655 All senders and receivers implementing ALC MUST support the EXT_NOP 656 Header Extension and MUST recognize EXT_AUTH, but are not required be 657 able to parse its content. The EXT_NOP and EXT_AUTH LCT Header 658 Extensions are defined in [RFC5651] 660 This specification defines a new LCT Header Extension, "EXT_FTI", for 661 the purpose of communicating the FEC Object Transmission Information 662 in association with data packets of an object. The LCT Header 663 Extension Type for EXT_FTI is 64. 665 The Header Extension Content (HEC) field of the EXT_FTI LCT Header 666 Extension contains the encoded FEC Object Transmission Information as 667 defined in [RFC5052]. The format of the encoded FEC Object 668 Transmission Information is dependent on the FEC Scheme in use and so 669 is outside the scope of this document. 671 4.3. Sender Operation 673 The sender operation when using ALC includes all the points made 674 about the sender operation when using the LCT building block 675 [RFC5651], the FEC building block [RFC5052] and the multiple rate 676 congestion control building block. 678 A sender using ALC should make available the required Session 679 Description as described in Section 2.4. A sender should also make 680 available the required FEC Object Transmission Information as 681 described in Section 2.3. 683 Within a session a sender transmits a sequence of packets to the 684 channels associated with the session. The ALC sender MUST obey the 685 rules for filling in the CCI field in the packet headers and MUST 686 send packets at the appropriate rates to the channels associated with 687 the session as dictated by the multiple rate congestion control 688 building block. 690 The ALC sender MUST use the same TSI for all packets in the session. 691 Several objects MAY be delivered within the same ALC session. If 692 more than one object is to be delivered within a session then the 693 sender MUST use the TOI field and each object MUST be identified by a 694 unique TOI within the session, and the sender MUST use corresponding 695 TOI for all packets pertaining to the same object. The FEC Payload 696 ID MUST correspond to the encoding symbol(s) for the object carried 697 in the payload of the packet. 699 It is RECOMMENDED that packet authentication be used. If packet 700 authentication is used then the Header Extensions described in 701 Section 4.2 MAY be used to carry the authentication. 703 4.4. Receiver Operation 705 The receiver operation when using ALC includes all the points made 706 about the receiver operation when using the LCT building block 707 [RFC5651], the FEC building block [RFC5052] and the multiple rate 708 congestion control building block. 710 To be able to participate in a session, a receiver needs to obtain 711 the required Session Description as listed in Section 2.4. How 712 receivers obtain a Session Description is outside the scope of this 713 document. 715 As described in Section 2.3, a receiver needs to obtain the required 716 FEC Object Transmission Information for each object for which the 717 receiver receives and processes packets. 719 Upon receipt of each packet the receiver proceeds with the following 720 steps in the order listed. 722 1. The receiver MUST parse the packet header and verify that it is a 723 valid header. If it is not valid then the packet MUST be 724 discarded without further processing. 726 2. The receiver MUST verify that the sender IP address together with 727 the TSI carried in the header matches one of the (sender IP 728 address, TSI) pairs that was received in a Session Description 729 and that the receiver is currently joined to. If there is not a 730 match then the packet MUST be silently discarded without further 731 processing. The remaining steps are performed within the scope 732 of the (sender IP address, TSI) session of the received packet. 734 3. The receiver MUST process and act on the CCI field in accordance 735 with the multiple rate congestion control building block. 737 4. If more than one object is carried in the session, the receiver 738 MUST verify that the TOI carried in the LCT header is valid. If 739 the TOI is not valid, the packet MUST be discarded without 740 further processing. 742 5. The receiver SHOULD process the remainder of the packet, 743 including interpreting the other header fields appropriately, and 744 using the FEC Payload ID and the encoding symbol(s) in the 745 payload to reconstruct the corresponding object. 747 It is RECOMMENDED that packet authentication be used. If packet 748 authentication is used then it is RECOMMENDED that the receiver 749 immediately check the authenticity of a packet before proceeding with 750 step (3) above. If immediate checking is possible and if the packet 751 fails the check then the receiver MUST silently discard the packet. 753 Some packet authentication schemes such as TESLA 754 [I-D.ietf-msec-tesla-for-alc-norm] do not allow an immediate 755 authenticity check. In this case the receiver SHOULD check the 756 authenticity of a packet as soon as possible, and if the packet fails 757 the check then it MUST be silently discarded before step (5) above. 758 It is RECOMMENDED that if receivers detect many packets which fail 759 authentication checks within a session then the above procedure 760 should be modified for this session so that Step 3 is delayed until 761 after the authentication check and only performed if the check 762 succeeds. 764 5. Security Considerations 766 The same security consideration that apply to the LCT, FEC and the 767 multiple rate congestion control building blocks also apply to ALC. 769 ALC is especially vulnerable to denial- of-service attacks by 770 attackers that try to send forged packets to the session which would 771 prevent successful reconstruction or cause inaccurate reconstruction 772 of large portions of the object by receivers. ALC is also 773 particularly affected by such an attack because many receivers may 774 receive the same forged packet. There are two ways to protect 775 against such attacks, one at the application level and one at the 776 packet level. It is RECOMMENDED that prevention be provided at both 777 levels. 779 At the application level, it is RECOMMENDED that an integrity check 780 on the entire received object be done once the object is 781 reconstructed to ensure it is the same as the sent object. Moreover, 782 in order to obtain strong cryptographic integrity protection a 783 digital signature verifiable by the receiver SHOULD be used to 784 provide this application level integrity check. However, if even one 785 corrupted or forged packet is used to reconstruct the object, it is 786 likely that the received object will be reconstructed incorrectly. 787 This will appropriately cause the integrity check to fail and in this 788 case the inaccurately reconstructed object SHOULD be discarded. 789 Thus, the acceptance of a single forged packet can be an effective 790 denial of service attack for distributing objects, but an object 791 integrity check at least prevents inadvertent use of inaccurately 792 reconstructed objects. The specification of an application level 793 integrity check of the received object is outside the scope of this 794 document. 796 At the packet level, it is RECOMMENDED that a packet level 797 authentication be used to ensure that each received packet is an 798 authentic and uncorrupted packet containing data for the object 799 arriving from the specified sender. Packet level authentication has 800 the advantage that corrupt or forged packets can be discarded 801 individually and the received authenticated packets can be used to 802 accurately reconstruct the object. Thus, the effect of a denial of 803 service attack that injects forged packets is proportional only to 804 the number of forged packets, and not to the object size. 805 [I-D.ietf-rmt-simple-auth-for-alc-norm]and 806 [I-D.ietf-msec-tesla-for-alc-norm] described packet level 807 authentication schemes which can be used with the ALC protocol. 809 In addition to providing protection against reconstruction of 810 inaccurate objects, packet level authentication can also provide some 811 protection against denial of service attacks on the multiple rate 812 congestion control. Attackers can try to inject forged packets with 813 incorrect congestion control information into the multicast stream, 814 thereby potentially adversely affecting network elements and 815 receivers downstream of the attack, and much less significantly the 816 rest of the network and other receivers. Thus, it is also 817 RECOMMENDED that packet level authentication be used to protect 818 against such attacks. TESLA [I-D.ietf-msec-tesla-for-alc-norm] can 819 also be used to some extent to limit the damage caused by such 820 attacks. However, with TESLA a receiver can only determine if a 821 packet is authentic several seconds after it is received, and thus an 822 attack against the congestion control protocol can be effective for 823 several seconds before the receiver can react to slow down the 824 session reception rate. 826 Reverse Path Forwarding checks SHOULD be enabled in all network 827 routers and switches along the path from the sender to receivers to 828 limit the possibility of a bad agent injecting forged packets into 829 the multicast tree data path. 831 5.1. Baseline Secure ALC Operation 833 This section describes a baseline mode of secure ALC protocol 834 operation based on application of the IPsec security protocol. This 835 approach is documented here to provide a reference, interoperable 836 secure mode of operation. However, additional approaches to ALC 837 security, including other forms of IPsec application, MAY be 838 specified in the future. For example, the use of the EXT_AUTH header 839 extension could enable ALC-specific authentication or security 840 encapsulation headers similar to those of IPsec to be specified and 841 inserted into the ALC/LCT protocol message headers. This would allow 842 header compression techniques to be applied to IP and ALC protocol 843 headers when needed in a similar fashion to that of RTP [RFC3550] and 844 as preserved in the specification for Secure Real Time Protocol 845 (SRTP) [RFC3711]. 847 The baseline approach described is applicable to ALC operation 848 configured for SSM (or SSM-like) operation where there is a single 849 sender. The receiver set would maintain a single IPSec Security 850 Association (SA) for each ALC sender. 852 5.1.1. IPsec Approach 854 To support this baseline form of secure ALC one-to-many SSM 855 operation, each node SHALL be configured with a transport mode IPsec 856 Security Association and corresponding Security Policy Database (SPD) 857 entry. This entry will be used for sender-to-group multicast packet 858 authentication and optionally encryption. 860 The ALC sender SHALL use an IPsec SA configured for ESP protocol 861 [RFC4303] operation with the option for data origination 862 authentication enabled. It is also RECOMMENDED that this IPsec ESP 863 SA be also configured to provide confidentiality protection for IP 864 packets containing ALC protocol messages. This is suggested to make 865 the realization of complex replay attacks much more difficult. The 866 encryption key for this SA SHALL be preplaced at the sender and 867 receiver(s) prior to ALC protocol operation. Use of automated key 868 management is RECOMMENDED as a rekey SHALL be required prior to 869 expiration of the sequence space for the SA. This is necessary so 870 that receivers may use the built-in IPsec replay attack protection 871 possible for an IPsec SA with a single source (the ALC sender). Thus 872 the receivers SHALL enable replay attack protection for this SA used 873 to secure ALC sender traffic. The sender IPsec SPD entry MUST be 874 configured to process outbound packets to the destination address and 875 UDP port number of the applicable ALC session. 877 The ALC receiver(s) MUST be configured with the SA and SPD entry to 878 properly process the IPsec-secured packets from the sender. Note 879 that use of ESP confidentiality, as RECOMMENDED, for secure ALC 880 protocol operation makes it more difficult for adversaries to conduct 881 effective replay attacks that may mislead receivers on content 882 reception. This baseline approach can be used for ALC protocol 883 sessions with multiple senders if a distinct SA is established for 884 each sender. 886 It is anticipated in early deployments of this baseline approach to 887 ALC security that key management will be conducted out-of-band with 888 respect to ALC protocol operation. For ALC unidirectional operation, 889 it is possible that receivers may retrieve keying information from a 890 central server via out-of-band (with respect to ALC) communication as 891 needed or otherwise conduct group key updates with a similar 892 centralized approach. However, it may be possible with some key 893 management schemes for rekey messages to be transmitted to the group 894 as a message or transport object within the ALC reliable transfer 895 session. Additional specification is necessary to define an in-band 896 key management scheme for ALC sessions perhaps using the mechanisms 897 of the automated group key management specifications cited in this 898 document. 900 5.1.2. IPsec Requirements 902 In order to implement this secure mode of ALC protocol operation, the 903 following IPsec capabilities are required. 905 5.1.2.1. Selectors 907 The implementation MUST be able to use the source address, 908 destination address, protocol (UDP), and UDP port numbers as 909 selectors in the SPD. 911 5.1.2.2. Mode 913 IPsec in transport mode MUST be supported. The use of IPsec 914 [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED 915 such that unauthenticated packets are not received by the ALC 916 protocol implementation. 918 5.1.2.3. Key Management 920 An automated key management scheme for group key distribution and 921 rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830] 922 SHOULD be used. Relatively short-lived ALC sessions MAY be able to 923 use Manual Keying with a single, preplaced key, particularly if 924 Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec 925 implementation used. It should also be noted that it may be possible 926 for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be 927 included in the ALC application reliable data transmission as 928 transport objects if appropriate interfaces were available between 929 the ALC application and the key management daemon. 931 5.1.2.4. Security Policy 933 Receivers SHOULD accept connections only from the designated, 934 authorized sender(s). It is expected that appropriate key management 935 will provide encryption keys only to receivers authorized to 936 participate in a designated session. The approach outlined here 937 allows receiver sets to be controlled on a per-sender basis. 939 5.1.2.5. Authentication and Encryption 941 Large ALC group sizes may necessitate some form of key management 942 that does rely upon shared secrets. The GDOI and GSAKMP protocols 943 mentioned here allow for certificate-based authentication. These 944 certificates SHOULD use IP addresses for authentication. However, it 945 is likely that available group key management implementations will 946 not be ALC-specific. 948 5.1.2.6. Availability 950 The IPsec requirements profile outlined here is commonly available on 951 many potential ALC hosts. The principal issue is that configuration 952 and operation of IPsec typically requires privileged user 953 authorization. Automated key management implementations are 954 typically configured with the privileges necessary to effect system 955 IPsec configuration needed. 957 6. IANA Considerations 959 This specification registers the following LCT Header Extensions 960 Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength: 962 +-------+---------+--------------------+ 963 | Value | Name | Reference | 964 +-------+---------+--------------------+ 965 | 64 | EXT_FTI | This specification | 966 +-------+---------+--------------------+ 968 7. Acknowledgments 970 This specification is substantially based on RFC3450 [RFC3450] and 971 thus credit for the authorship of this document is primarily due to 972 the authors of RFC3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, 973 Luigi Rizzo and Jon Crowcroft. Vincent Roca, Justin Chapweske and 974 Roger Kermode also contributed to RFC3450. Additional thanks are due 975 to Vincent Roca and Rod Walsh for contributions to this update to 976 Proposed Standard. 978 8. Changes from RFC3450 980 This section summarises the changes that were made from the 981 Experimental version of this specification published as RFC3450 982 [RFC3450]: 984 o Update all references to the obsoleted RFC 2068 to RFC 2616 986 o Removed the 'Statement of Intent' from the introduction (The 987 statement of intent was meant to clarify the "Experimental" status 988 of RFC3450.) 990 o Removed the 'Intellectual Property Issues' Section and replaced 991 with a standard IPR Statement 993 o Remove material duplicated in LCT 995 o Update references for LCT and FEC Building Block to new versions 996 and align with changes in the FEC Building Block. 998 o Split normative and informative references 1000 o Material applicable in a general LCT context, not just for ALC has 1001 been moved to LCT 1003 o The first bit of the "Protocol Specific Indication" in the LCT 1004 Header is defined as a "Source Packet Indication". This is used 1005 in the case that an FEC Scheme defines two FEC Payload ID formats, 1006 one of which is for packets containing only source symbols which 1007 can be processed by receivers that do not support FEC Decoding. 1009 o Definition and IANA registration of the EXT_FTI LCT Header 1010 Extension 1012 9. References 1014 9.1. Normative references 1016 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1017 August 1980. 1019 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1020 RFC 1112, August 1989. 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, March 1997. 1025 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1026 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1027 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1029 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1030 Types", RFC 3023, January 2001. 1032 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 1033 Control (WEBRC) Building Block", RFC 3738, April 2004. 1035 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1036 Internet Protocol", RFC 4301, December 2005. 1038 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1039 RFC 4303, December 2005. 1041 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1042 Description Protocol", RFC 4566, July 2006. 1044 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1045 Correction (FEC) Building Block", RFC 5052, August 2007. 1047 [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1048 Transport (LCT) Building Block", RFC 5651, October 2009. 1050 9.2. Informative references 1052 [I-D.ietf-msec-tesla-for-alc-norm] 1053 Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in 1054 the ALC and NORM Protocols", 1055 draft-ietf-msec-tesla-for-alc-norm-08 (work in progress), 1056 September 2009. 1058 [I-D.ietf-rmt-simple-auth-for-alc-norm] 1059 Roca, V., "Simple Authentication Schemes for the ALC and 1060 NORM Protocols", 1061 draft-ietf-rmt-simple-auth-for-alc-norm-01 (work in 1062 progress), March 2009. 1064 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1065 Criteria for Evaluating Reliable Multicast Transport and 1066 Application Protocols", RFC 2357, June 1998. 1068 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1069 Announcement Protocol", RFC 2974, October 2000. 1071 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1072 Floyd, S., and M. Luby, "Reliable Multicast Transport 1073 Building Blocks for One-to-Many Bulk-Data Transfer", 1074 RFC 3048, January 2001. 1076 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 1077 Reliable Multicast Transport (RMT) Building Blocks and 1078 Protocol Instantiation documents", RFC 3269, April 2002. 1080 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 1081 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 1082 Instantiation", RFC 3450, December 2002. 1084 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1085 M., and J. Crowcroft, "The Use of Forward Error Correction 1086 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1088 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1089 Group Domain of Interpretation", RFC 3547, July 2003. 1091 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1092 Jacobson, "RTP: A Transport Protocol for Real-Time 1093 Applications", STD 64, RFC 3550, July 2003. 1095 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 1096 Multicast (SSM)", RFC 3569, July 2003. 1098 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1099 Protocol (MSDP)", RFC 3618, October 2003. 1101 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1102 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1103 RFC 3711, March 2004. 1105 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1106 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1107 August 2004. 1109 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1110 "GSAKMP: Group Secure Association Key Management 1111 Protocol", RFC 4535, June 2006. 1113 Authors' Addresses 1115 Michael Luby 1116 Qualcomm Inc. 1117 3165 Kifer Road 1118 Santa Clara, CA 95051 1119 US 1121 Email: luby@qualcomm.com 1123 Mark Watson 1124 Qualcomm Inc. 1125 3165 Kifer Road 1126 Santa Clara, CA 95051 1127 US 1129 Email: watson@qualcomm.com 1131 Lorenzo Vicisano 1132 Qualcomm Inc. 1133 3165 Kifer Road 1134 Santa Clara, CA 95051 1135 US 1137 Email: vicisano@qualcomm.com