idnits 2.17.1 draft-ietf-rmt-pi-alc-revised-08.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 (September 3, 2009) is 5341 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-07 == 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 September 3, 2009 7 Expires: March 7, 2010 9 Asynchronous Layered Coding (ALC) Protocol Instantiation 10 draft-ietf-rmt-pi-alc-revised-08 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 March 7, 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 . . . . . . . . . . . . . . . . . . . . 10 77 2.4. Session Description . . . . . . . . . . . . . . . . . . . 12 78 2.5. Packet authentication building block . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . . 30 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 [RFC3450], which was published in the "Experimental" category and 145 which is obsoleted by this document, contained a previous versions of 146 the protocol. 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 [I-D.ietf-rmt-bb-lct-revised]. 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 [I-D.ietf-rmt-bb-lct-revised], the FEC 203 building block [RFC5052], the multiple rate congestion control 204 building block and to any additional building blocks that ALC uses 205 also apply to ALC. 207 One issues that is specific to ALC with respect to the Any- Source 208 Multicast (ASM) model of IP multicast as defined in RFC 1112 209 [RFC1112] is the way the multiple rate congestion control building 210 block interacts with ASM. The congestion control building block may 211 use the measured difference in time between when a join to a channel 212 is sent and when the first packet from the channel arrives in 213 determining the receiver reception rate. The congestion control 214 building block may also uses packet sequence numbers per channel to 215 measure losses, and this is also used to determine the receiver 216 reception rate. These features raise two concerns with respect to 217 ASM: The time difference between when the join to a channel is sent 218 and when the first packet arrives can be significant due to the use 219 of Rendezvous Points (RPs) and the MSDP protocol, and packets can be 220 lost in the switch over from the (*,G) join to the RP and the (S,G) 221 join directly to the sender. Both of these issues could potentially 222 substantially degrade the reception rate of receivers. To ameliorate 223 these concerns, it is RECOMMENDED that the RP be as close to the 224 sender as possible. SSM does not share these same concerns. For a 225 fuller consideration of these issues, consult the multiple rate 226 congestion control building block. 228 2. Architecture Definition 230 ALC uses the LCT building block [I-D.ietf-rmt-bb-lct-revised] to 231 provide in-band session management functionality. ALC uses a 232 multiple rate congestion control building block that is compliant 233 with [RFC2357] to provide congestion control that is feedback free. 234 Receivers adjust their reception rates individually by joining and 235 leaving channels associated with the session. ALC uses the FEC 236 building block [RFC5052] to provide reliability. The sender 237 generates encoding symbols based on the object to be delivered using 238 FEC codes and sends them in packets to channels associated with the 239 session. Receivers simply wait for enough packets to arrive in order 240 to reliably reconstruct the object. Thus, there is no request for 241 retransmission of individual packets from receivers that miss packets 242 in order to assure reliable reception of an object, and the packets 243 and their rate of transmission out of the sender can be independent 244 of the number and the individual reception experiences of the 245 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 [I-D.ietf-rmt-bb-lct-revised]. Like LCT, ALC is 264 designed to be used with the IP multicast network service. This 265 specification defines ALC as payload of the UDP transport protocol 266 [RFC0768] that supports IP multicast delivery of packets. 268 An ALC packet header immediately follows the UDP header and consists 269 of the default LCT header that is described in 270 [I-D.ietf-rmt-bb-lct-revised] followed by the FEC Payload ID that is 271 described in [RFC5052]. The Congestion Control Information field 272 within the LCT header carries the required Congestion Control 273 Information that is described in the multiple rate congestion control 274 building block specified that is compliant with [RFC2357]. The 275 packet payload that follows the ALC packet header consists of 276 encoding symbols that are identified by the FEC Payload ID as 277 described in [RFC5052]. 279 Each receiver is required to obtain a Session Description before 280 joining an ALC session. As described later, the Session Description 281 includes out-of-band information required for the LCT, FEC and the 282 multiple rate congestion control building blocks. The FEC Object 283 Transmission Information specified in the FEC building block 284 [RFC5052] required for each object to be received by a receiver can 285 be communicated to a receiver either out-of-band or in-band using a 286 Header Extension. The means for communicating the Session 287 Description and the FEC Object Transmission Information to a receiver 288 is outside the scope of this document. 290 2.1. LCT building block 292 LCT requires receivers to be able to uniquely identify and 293 demultiplex packets associated with an LCT session, and ALC inherits 294 and strengthens this requirement. A Transport Session Identifier 295 (TSI) MUST be associated with each session and MUST be carried in the 296 LCT header of each ALC packet. The TSI is scoped by the sender IP 297 address, and the (sender IP address, TSI) pair MUST uniquely identify 298 the session. 300 The LCT header contains a Congestion Control Information (CCI) field 301 that MUST be used to carry the Congestion Control Information from 302 the specified multiple rate congestion control protocol. There is a 303 field in the LCT header that specifies the length of the CCI field, 304 and the multiple rate congestion control building block MUST uniquely 305 identify a format of the CCI field that corresponds to this length. 307 The LCT header contains a Codepoint field that MAY be used to 308 communicate to a receiver the settings for information that may vary 309 during a session. If used, the mapping between settings and 310 Codepoint values is to be communicated in the Session Description, 311 and this mapping is outside the scope of this document. For example, 312 the FEC Encoding ID that is part of the FEC Object Transmission 313 Information as specified in the FEC building block [RFC5052] could 314 vary for each object carried in the session, and the Codepoint value 315 could be used to communicate the FEC Encoding ID to be used for each 316 object. The mapping between FEC Encoding IDs and Codepoints could 317 be, for example, the identity mapping. 319 If more than one object is to be carried within a session then the 320 Transmission Object Identifier (TOI) MUST be used in the LCT header 321 to identify which packets are to be associated with which objects. 322 In this case the receiver MUST use the TOI to associate received 323 packets with objects. The TOI is scoped by the IP address of the 324 sender and the TSI, i.e., the TOI is scoped by the session. The TOI 325 for each object is REQUIRED to be unique within a session, but is not 326 required be unique across sessions. Furthermore, the same object MAY 327 have a different TOI in different sessions. The mapping between TOIs 328 and objects carried in a session is outside the scope of this 329 document. 331 If only one object is carried within a session then the TOI MAY be 332 omitted from the LCT header. 334 The LCT header from version 1 of the LCT building block 335 [I-D.ietf-rmt-bb-lct-revised] MUST be used. 337 The LCT Header includes a two-bit Protocol Specific Indication (PSI) 338 field in bits 6 and 7 of the first word of the LCT header. These two 339 bits are used by ALC as follows: 341 0 1 2 3 342 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 343 +-+-+ 344 ...|X|Y|... 345 +-+-+ 347 Figure 1: PSI bits within LCT Headder 349 PSI bit X - Source Packet Indicator (SPI) 351 PSI bit Y - Reserved 353 The Source Packet Indicator is used with systematic FEC Schemes which 354 define a different FEC Payload ID format for packets containing only 355 source data compared to the FEC Payload ID format for packets 356 containing repair data. For such FEC Schemes, then the SPI MUST be 357 set to 1 when the FEC Payload ID format for packets containing only 358 source data is used and the SPI MUST be set to zero, when the FEC 359 Payload ID for packerts containing repair data is used. In the case 360 of FEC Schemes which define only a single FEC Payload ID format, then 361 the SPI MUST be set to zero by the sender and MUST be ignored by the 362 receiver. 364 Support of two FEC Payload ID formats allows FEC Payload ID 365 information which is only of relevance when FEC decoding is to be 366 performed to be provided in the FEC Payload ID format for packets 367 containing repair data. This information need not be processed by 368 receivers which do not perform FEC decoding (either because no FEC 369 decoding is required or because the receiver does not support FEC 370 decoding). 372 2.2. Multiple rate congestion control building block 374 At a minimum, implementions of ALC MUST support [RFC3738]. 376 Congestion control MUST be applied to all packets within a session 377 independently of which information about which object is carried in 378 each packet. Multiple rate congestion control is specified because 379 of its suitability to scale massively and because of its suitability 380 for reliable content delivery. [RFC3738] specifies in-band 381 Congestion Control Information (CCI) that MUST be carried in the CCI 382 field of the LCT header. 384 Alternative multiple rate congestion control building blocks MAY be 385 supported. The multiple rate congestion control building block MAY 386 specify more than one format for the CCI field, but it MUST specify 387 at most one format for each of the possible lengths 32, 64, 96 or 128 388 bits. The value of C in the LCT header that determines the length of 389 the CCI field MUST correspond to one of the lengths for the CCI 390 defined in the multiple rate congestion control building block, this 391 length MUST be the same for all packets sent to a session, and the 392 CCI format that corresponds to the length as specified in the 393 multiple rate congestion control building block MUST be the format 394 used for the CCI field in the LCT header. 396 When using a multiple rate congestion control building block a sender 397 sends packets in the session to several channels at potentially 398 different rates. Then, individual receivers adjust their reception 399 rate within a session by adjusting which set of channels they are 400 joined to at each point in time depending on the available bandwidth 401 between the receiver and the sender, but independent of other 402 receivers. 404 2.3. FEC building block 406 The FEC building block [RFC5052] provides reliable object delivery 407 within an ALC session. Each object sent in the session is 408 independently encoded using FEC codes as described in [RFC3453], 409 which provide a more in-depth description of the use of FEC codes in 410 reliable content delivery protocols. All packets in an ALC session 411 MUST contain an FEC Payload ID in a format that is compliant with the 412 FEC Scheme in use. The FEC Payload ID uniquely identifies the 413 encoding symbols that constitute the payload of each packet, and the 414 receiver MUST use the FEC Payload ID to determine how the encoding 415 symbols carried in the payload of the packet were generated from the 416 object as described in the FEC building block. 418 As described in [RFC5052], a receiver is REQUIRED to obtain the FEC 419 Object Transmission Information for each object for which data 420 packets are received from the session. In the context of ALC, the 421 FEC Object Transmission Information includes: 423 o The FEC Encoding ID. 425 o If an Under-Specified FEC Encoding ID is used then the FEC 426 Instance ID associated with the FEC Encoding ID. 428 o For each object in the session, the transfer length of the object 429 in bytes. 431 Additional FEC Object Transmission Information may be required 432 depending on the FEC Scheme that is used (identified by the FEC 433 Encoding ID). 435 Some of the FEC Object Transmission Information MAY be implicit based 436 on the FEC Scheme and/or implementation. As an example, source block 437 lengths may be derived by a fixed algorithm from the object length. 438 As another example, it may be that all source blocks are the same 439 length and this is what is passed out-of-band to the receiver. As 440 another example, it could be that the full sized source block length 441 is provided and this is the length used for all but the last source 442 block, which is calculated based on the full source block length and 443 the object length. As another example, it could be that the same FEC 444 Encoding ID and FEC Instance ID are always used for a particular 445 application and thus the FEC Encoding ID and FEC Instance ID are 446 implicitly defined. 448 Sometimes the objects that will be sent in a session are completely 449 known before the receiver joins the session, in which case the FEC 450 Object Transmission Information for all objects in the session can be 451 communicated to receivers before they join the session. At other 452 times the objects may not know when the session begins, or receivers 453 may join a session in progress and may not be interested in some 454 objects for which transmission has finished, or receivers may leave a 455 session before some objects are even available within the session. 456 In these cases, the FEC Object Transmission Information for each 457 object may be dynamically communicated to receivers at or before the 458 time packets for the object are received from the session. This may 459 be accomplished using either an out-of-band mechanism, in-band using 460 the Codepoint field or a Header Extension, or any combination of 461 these methods. How the FEC Object Transmission Information is 462 communicated to receivers is outside the scope of this document. 464 If packets for more than one object are transmitted within a session 465 then a Transmission Object Identifier (TOI) that uniquely identifies 466 objects within a session MUST appear in each packet header. Portions 467 of the FEC Object Transmission Information could be the same for all 468 objects in the session, in which case these portions can be 469 communicated to the receiver with an indication that this applies to 470 all objects in the session. These portions may be implicitly 471 determined based on the application, e.g., an application may use the 472 same FEC Encoding ID for all objects in all sessions. If there is a 473 portion of the FEC Object Transmission Information that may vary from 474 object to object and if this FEC Object Transmission Information is 475 communicated to a receiver out-of-band then the TOI for the object 476 MUST also be communicated to the receiver together with the 477 corresponding FEC Object Transmission Information, and the receiver 478 MUST use the corresponding FEC Object Transmission Information for 479 all packets received with that TOI. How the TOI and corresponding 480 FEC Object Transmission Information is communicated out-of-band to 481 receivers is outside the scope of this document. 483 It is also possible that there is a portion of the FEC Object 484 Transmission Information that may vary from object to object that is 485 carried in-band, for example in the CodePoint field or in Header 486 Extensions. How this is done is outside the scope of this document. 487 In this case the FEC Object Transmission Information is associated 488 with the object identified by the TOI carried in the packet. 490 2.4. Session Description 492 The Session Description that a receiver is REQUIRED to obtain before 493 joining an ALC session MUST contain the following information: 495 o The multiple rate congestion control building block to be used for 496 the session; 498 o The sender IP address; 500 o The number of channels in the session; 502 o The address and port number used for each channel in the session; 504 o The Transport Session ID (TSI) to be used for the session; 506 o An indication of whether or not the session carries packets for 507 more than one object; 509 o If Header Extensions are to be used, the format of these Header 510 Extensions. 512 o Enough information to determine the packet authentication scheme 513 being used, if it is being used. 515 How the Session Description is communicated to receivers is outside 516 the scope of this document. 518 The Codepoint field within the LCT portion of the header CAN be used 519 to communicate in-band some of the dynamically changing information 520 within a session. To do this, a mapping between Codepoint values and 521 the different dynamic settings MUST be included within the Session 522 Description, and then settings to be used are communicated via the 523 Codepoint value placed into each packet. For example, it is possible 524 that multiple objects are delivered within the same session and that 525 a different FEC encoding algorithm is used for different types of 526 objects. Then the Session Description could contain the mapping 527 between Codepoint values and FEC Encoding IDs. As another example, 528 it is possible that a different packet authentication scheme is used 529 for different packets sent to the session. In this case, the mapping 530 between the packet authentication scheme and Codepoint values could 531 be provided in the Session Description. Combinations of settings can 532 be mapped to Codepoint values as well. For example, a particular 533 combination of a FEC Encoding ID and a packet authentication scheme 534 could be associated with a Codepoint value. 536 The Session Description could also include, but is not limited to: 538 o The mappings between combinations of settings and Codepoint 539 values; 541 o The data rates used for each channel; 543 o The length of the packet payload; 545 o Any information that is relevant to each object being transported, 546 such as the Object Transmission Information for each object, when 547 the object will be available within the session and for how long. 549 The Session Description could be in a form such as SDP as defined in 550 [RFC4566], or XML metadata as defined in [RFC3023], or HTTP/Mime 551 headers as defined in [RFC2616], etc. It might be carried in a 552 session announcement protocol such as SAP as defined in [RFC2974], 553 obtained using a proprietary session control protocol, located on a 554 web page with scheduling information, or conveyed via E-mail or other 555 out-of-band methods. Discussion of Session Description formats and 556 methods for communication of Session Descriptions to receivers is 557 beyond the scope of this document. 559 2.5. Packet authentication building block 561 It is RECOMMENDED that implementors of ALC use some packet 562 authentication scheme to protect the protocol from attacks. Suitable 563 schemes are described in [I-D.ietf-msec-tesla-for-alc-norm] and 565 [I-D.ietf-rmt-simple-auth-for-alc-norm]. 567 3. Conformance Statement 569 This Protocol Instantiation document, in conjunction with the LCT 570 building block [I-D.ietf-rmt-bb-lct-revised], the FEC building block 571 [RFC5052] and [RFC3738] completely specifies a working reliable 572 multicast transport protocol that conforms to the requirements 573 described in [RFC2357]. 575 4. Functionality Definition 577 This section describes the format and functionality of the data 578 packets carried in an ALC session as well as the sender and receiver 579 operations for a session. 581 4.1. Packet format used by ALC 583 The packet format used by ALC is the UDP header followed by the LCT 584 header followed by the FEC Payload ID followed by the packet payload. 585 The LCT header is defined in the LCT building block 586 [I-D.ietf-rmt-bb-lct-revised] and the FEC Payload ID is described in 587 the FEC building block [RFC5052]. The Congestion Control Information 588 field in the LCT header contains the REQUIRED Congestion Control 589 Information that is described in the multiple rate congestion control 590 building block used. The packet payload contains encoding symbols 591 generated from an object. If more than one object is carried in the 592 session then the Transmission Object ID (TOI) within the LCT header 593 MUST be used to identify which object the encoding symbols are 594 generated from. Within the scope of an object, encoding symbols 595 carried in the payload of the packet are identified by the FEC 596 Payload ID as described in the FEC building block. 598 The version number of ALC specified in this document is 1. The 599 version number field of the LCT header MUST be interpreted as the ALC 600 version number field. This version of ALC implicitly makes use of 601 version 1 of the LCT building block defined in 602 [I-D.ietf-rmt-bb-lct-revised]. 604 The overall ALC packet format is depicted in Figure 2. The packet is 605 an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP 606 header. The ALC packet format has no dependencies on the IP version 607 number. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | UDP header | 613 | | 614 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 615 | LCT header | 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | FEC Payload ID | 619 | | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Encoding Symbol(s) | 622 | ... | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Figure 2: Overall ALC packet format 627 In some special cases an ALC sender may need to produce ALC packets 628 that do not contain any payload. This may be required, for example, 629 to signal the end of a session or to convey congestion control 630 information. These data-less packets do not contain the FEC Payload 631 ID either, but only the LCT header fields. The total datagram 632 length, conveyed by outer protocol headers (e.g., the IP or UDP 633 header), enables receivers to detect the absence of the ALC payload 634 and FEC Payload ID. 636 For ALC the length of the TSI field within the LCT header is REQUIRED 637 to be non-zero. This implies that the sender MUST NOT set both the 638 LCT flags S and H to zero. 640 4.2. LCT Header-Extension Fields 642 All senders and receivers implementing ALC MUST support the EXT_NOP 643 Header Extension and MUST recognize EXT_AUTH, but are not required be 644 able to parse its content. The EXT_NOP and EXT_AUTH LCT Header 645 Extensions are defined in [I-D.ietf-rmt-bb-lct-revised] 647 This specification defines a new LCT Header Extension, "EXT_FTI", for 648 the purpose of communicating the FEC Object Transmission Information 649 in association with data packets of an object. The LCT Header 650 Extension Type for EXT_FTI is 64. 652 The Header Extension Content (HEC) field of the EXT_FTI LCT Header 653 Extension contains the encoded FEC Object Transmission Information as 654 defined in [RFC5052]. The format of the encoded FEC Object 655 Transmission Information is dependent on the FEC Scheme in use and so 656 is outside the scope of this document. 658 4.3. Sender Operation 660 The sender operation when using ALC includes all the points made 661 about the sender operation when using the LCT building block 662 [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and 663 the multiple rate congestion control building block. 665 A sender using ALC MUST make available the required Session 666 Description as described in Section 2.4. A sender also MUST make 667 available the required FEC Object Transmission Information as 668 described in Section 2.3. 670 Within a session a sender transmits a sequence of packets to the 671 channels associated with the session. The ALC sender MUST obey the 672 rules for filling in the CCI field in the packet headers and MUST 673 send packets at the appropriate rates to the channels associated with 674 the session as dictated by the multiple rate congestion control 675 building block. 677 The ALC sender MUST use the same TSI for all packets in the session. 678 Several objects MAY be delivered within the same ALC session. If 679 more than one object is to be delivered within a session then the 680 sender MUST use the TOI field and each object MUST be identified by a 681 unique TOI within the session, and the sender MUST use corresponding 682 TOI for all packets pertaining to the same object. The FEC Payload 683 ID MUST correspond to the encoding symbol(s) for the object carried 684 in the payload of the packet. 686 It is RECOMMENDED that packet authentication be used. If packet 687 authentication is used then the Header Extensions described in 688 Section 4.2 MAY be used to carry the authentication. 690 4.4. Receiver Operation 692 The receiver operation when using ALC includes all the points made 693 about the receiver operation when using the LCT building block 694 [I-D.ietf-rmt-bb-lct-revised], the FEC building block [RFC5052] and 695 the multiple rate congestion control building block. 697 To be able to participate in a session, a receiver MUST obtain the 698 REQUIRED Session Description as listed in Section 2.4. How receivers 699 obtain a Session Description is outside the scope of this document. 701 As described in Section 2.3, a receiver MUST obtain the required FEC 702 Object Transmission Information for each object for which the 703 receiver receives and processes packets. 705 Upon receipt of each packet the receiver proceeds with the following 706 steps in the order listed. 708 1. The receiver MUST parse the packet header and verify that it is a 709 valid header. If it is not valid then the packet MUST be 710 discarded without further processing. 712 2. The receiver MUST verify that the sender IP address together with 713 the TSI carried in the header matches one of the (sender IP 714 address, TSI) pairs that was received in a Session Description 715 and that the receiver is currently joined to. If there is not a 716 match then the packet MUST be silently discarded without further 717 processing. The remaining steps are performed within the scope 718 of the (sender IP address, TSI) session of the received packet. 720 3. The receiver MUST process and act on the CCI field in accordance 721 with the multiple rate congestion control building block. 723 4. If more than one object is carried in the session, the receiver 724 MUST verify that the TOI carried in the LCT header is valid. If 725 the TOI is not valid, the packet MUST be discarded without 726 further processing. 728 5. The receiver SHOULD process the remainder of the packet, 729 including interpreting the other header fields appropriately, and 730 using the FEC Payload ID and the encoding symbol(s) in the 731 payload to reconstruct the corresponding object. 733 It is RECOMMENDED that packet authentication be used. If packet 734 authentication is used then it is RECOMMENDED that the receiver 735 immediately check the authenticity of a packet before proceeding with 736 step (3) above. If immediate checking is possible and if the packet 737 fails the check then the receiver MUST silently discard the packet. 739 Some packet authentication schemes such as TESLA 740 [I-D.ietf-msec-tesla-for-alc-norm] do not allow an immediate 741 authenticity check. In this case the receiver SHOULD check the 742 authenticity of a packet as soon as possible, and if the packet fails 743 the check then it MUST be silently discarded before step (5) above. 744 It is RECOMMENDED that if receivers detect many packets which fail 745 authentication checks within a session then the above procedure 746 should be modified for this session so that Step 3 is delayed until 747 after the authentication check and only performed if the check 748 succeeds. 750 5. Security Considerations 752 The same security consideration that apply to the LCT, FEC and the 753 multiple rate congestion control building blocks also apply to ALC. 755 ALC is especially vulnerable to denial- of-service attacks by 756 attackers that try to send forged packets to the session which would 757 prevent successful reconstruction or cause inaccurate reconstruction 758 of large portions of the object by receivers. ALC is also 759 particularly affected by such an attack because many receivers may 760 receive the same forged packet. There are two ways to protect 761 against such attacks, one at the application level and one at the 762 packet level. It is RECOMMENDED that prevention be provided at both 763 levels. 765 At the application level, it is RECOMMENDED that an integrity check 766 on the entire received object be done once the object is 767 reconstructed to ensure it is the same as the sent object. Moreover, 768 in order to obtain strong cryptographic integrity protection a 769 digital signature verifiable by the receiver SHOULD be used to 770 provide this application level integrity check. However, if even one 771 corrupted or forged packet is used to reconstruct the object, it is 772 likely that the received object will be reconstructed incorrectly. 773 This will appropriately cause the integrity check to fail and in this 774 case the inaccurately reconstructed object SHOULD be discarded. 775 Thus, the acceptance of a single forged packet can be an effective 776 denial of service attack for distributing objects, but an object 777 integrity check at least prevents inadvertent use of inaccurately 778 reconstructed objects. The specification of an application level 779 integrity check of the received object is outside the scope of this 780 document. 782 At the packet level, it is RECOMMENDED that a packet level 783 authentication be used to ensure that each received packet is an 784 authentic and uncorrupted packet containing data for the object 785 arriving from the specified sender. Packet level authentication has 786 the advantage that corrupt or forged packets can be discarded 787 individually and the received authenticated packets can be used to 788 accurately reconstruct the object. Thus, the effect of a denial of 789 service attack that injects forged packets is proportional only to 790 the number of forged packets, and not to the object size. 791 [I-D.ietf-rmt-simple-auth-for-alc-norm]and 792 [I-D.ietf-msec-tesla-for-alc-norm] described packet level 793 authentication schemes which can be used with the ALC protocol. 795 In addition to providing protection against reconstruction of 796 inaccurate objects, packet level authentication can also provide some 797 protection against denial of service attacks on the multiple rate 798 congestion control. Attackers can try to inject forged packets with 799 incorrect congestion control information into the multicast stream, 800 thereby potentially adversely affecting network elements and 801 receivers downstream of the attack, and much less significantly the 802 rest of the network and other receivers. Thus, it is also 803 RECOMMENDED that packet level authentication be used to protect 804 against such attacks. TESLA [I-D.ietf-msec-tesla-for-alc-norm] can 805 also be used to some extent to limit the damage caused by such 806 attacks. However, with TESLA a receiver can only determine if a 807 packet is authentic several seconds after it is received, and thus an 808 attack against the congestion control protocol can be effective for 809 several seconds before the receiver can react to slow down the 810 session reception rate. 812 Reverse Path Forwarding checks SHOULD be enabled in all network 813 routers and switches along the path from the sender to receivers to 814 limit the possibility of a bad agent injecting forged packets into 815 the multicast tree data path. 817 5.1. Baseline Secure ALC Operation 819 This section describes a baseline mode of secure ALC protocol 820 operation based on application of the IPsec security protocol. This 821 approach is documented here to provide a reference, interoperable 822 secure mode of operation. However, additional approaches to ALC 823 security, including other forms of IPsec application, MAY be 824 specified in the future. For example, the use of the EXT_AUTH header 825 extension could enable ALC-specific authentication or security 826 encapsulation headers similar to those of IPsec to be specified and 827 inserted into the ALC/LCT protocol message headers. This would allow 828 header compression techniques to be applied to IP and ALC protocol 829 headers when needed in a similar fashion to that of RTP [RFC3550] and 830 as preserved in the specification for Secure Real Time Protocol 831 (SRTP) [RFC3711]. 833 The baseline approach described is applicable to ALC operation 834 configured for SSM (or SSM-like) operation where there is a single 835 sender. The receiver set would maintain a single IPSec Security 836 Association (SA) for each ALC sender. 838 5.1.1. IPsec Approach 840 To support this baseline form of secure ALC one-to-many SSM 841 operation, each node SHALL be configured with a transport mode IPsec 842 Security Association and corresponding Security Policy Database (SPD) 843 entry. This entry will be used for sender-to-group multicast packet 844 authentication and optionally encryption. 846 The ALC sender SHALL use an IPsec SA configured for ESP protocol 847 [RFC4303] operation with the option for data origination 848 authentication enabled. It is also RECOMMENDED that this IPsec ESP 849 SA be also configured to provide confidentiality protection for IP 850 packets containing ALC protocol messages. This is suggested to make 851 the realization of complex replay attacks much more difficult. The 852 encryption key for this SA SHALL be preplaced at the sender and 853 receiver(s) prior to ALC protocol operation. Use of automated key 854 management is RECOMMENDED as a rekey SHALL be required prior to 855 expiration of the sequence space for the SA. This is necessary so 856 that receivers may use the built-in IPsec replay attack protection 857 possible for an IPsec SA with a single source (the ALC sender). Thus 858 the receivers SHALL enable replay attack protection for this SA used 859 to secure ALC sender traffic. The sender IPsec SPD entry MUST be 860 configured to process outbound packets to the destination address and 861 UDP port number of the applicable ALC session. 863 The ALC receiver(s) MUST be configured with the SA and SPD entry to 864 properly process the IPsec-secured packets from the sender. Note 865 that use of ESP confidentiality, as RECOMMENDED, for secure ALC 866 protocol operation makes it more difficult for adversaries to conduct 867 effective replay attacks that may mislead receivers on content 868 reception. This baseline approach can be used for ALC protocol 869 sessions with multiple senders if a distinct SA is established for 870 each sender. 872 It is anticipated in early deployments of this baseline approach to 873 ALC security that key management will be conducted out-of-band with 874 respect to ALC protocol operation. For ALC unidirectional operation, 875 it is possible that receivers may retrieve keying information from a 876 central server via out-of-band (with respect to ALC) communication as 877 needed or otherwise conduct group key updates with a similar 878 centralized approach. However, it may be possible with some key 879 management schemes for rekey messages to be transmitted to the group 880 as a message or transport object within the ALC reliable transfer 881 session. Additional specification is necessary to define an in-band 882 key management scheme for ALC sessions perhaps using the mechanisms 883 of the automated group key management specifications cited in this 884 document. 886 5.1.2. IPsec Requirements 888 In order to implement this secure mode of ALC protocol operation, the 889 following IPsec capabilities are required. 891 5.1.2.1. Selectors 893 The implementation MUST be able to use the source address, 894 destination address, protocol (UDP), and UDP port numbers as 895 selectors in the SPD. 897 5.1.2.2. Mode 899 IPsec in transport mode MUST be supported. The use of IPsec 900 [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED 901 such that unauthenticated packets are not received by the ALC 902 protocol implementation . 904 5.1.2.3. Key Management 906 An automated key management scheme for group key distribution and 907 rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830] 908 SHOULD be used. Relatively short-lived ALC sessions MAY be able to 909 use Manual Keying with a single, preplaced key, particularly if 910 Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec 911 implementation used. It should also be noted that it may be possible 912 for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be 913 included in the ALC application reliable data transmission as 914 transport objects if appropriate interfaces were available between 915 the ALC application and the key management daemon. 917 5.1.2.4. Security Policy 919 Receivers SHOULD accept connections only from the designated, 920 authorized sender(s). It is expected that appropriate key management 921 will provide encryption keys only to receivers authorized to 922 participate in a designated session. The approach outlined here 923 allows receiver sets to be controlled on a per-sender basis. 925 5.1.2.5. Authentication and Encryption 927 Large ALC group sizes may necessitate some form of key management 928 that does rely upon shared secrets. The GDOI and GSAKMP protocols 929 mentioned here allow for certificate-based authentication. These 930 certificates SHOULD use IP addresses for authentication. However, it 931 is likely that available group key management implementations will 932 not be ALC-specific. 934 5.1.2.6. Availability 936 The IPsec requirements profile outlined here is commonly available on 937 many potential ALC hosts. The principal issue is that configuration 938 and operation of IPsec typically requires privileged user 939 authorization. Automated key management implementations are 940 typically configured with the privileges necessary to effect system 941 IPsec configuration needed. 943 6. IANA Considerations 945 This specification registers the following LCT Header Extensions 946 Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength: 948 +-------+---------+--------------------+ 949 | Value | Name | Reference | 950 +-------+---------+--------------------+ 951 | 64 | EXT_FTI | This specification | 952 +-------+---------+--------------------+ 954 7. Acknowledgments 956 This specification is substantially based on RFC3450 [RFC3450] and 957 thus credit for the authorship of this document is primarily due to 958 the authors of RFC3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, 959 Luigi Rizzo and Jon Crowcroft. Vincent Roca, Justin Chapweske and 960 Roger Kermode also contributed to RFC3450. Additional thanks are due 961 to Vincent Roca and Rod Walsh for contributions to this update to 962 Proposed Standard. 964 8. Changes from RFC3450 966 This section summarises the changes that were made from the 967 Experimental version of this specification published as RFC3450 968 [RFC3450]: 970 o Update all references to the obsoleted RFC 2068 to RFC 2616 972 o Removed the 'Statement of Intent' from the introduction (The 973 statement of intent was meant to clarify the "Experimental" status 974 of RFC3450.) 976 o Removed the 'Intellectual Property Issues' Section and replaced 977 with a standard IPR Statement 979 o Remove material duplicated in LCT 981 o Update references for LCT and FEC Building Block to new versions 982 and align with changes in the FEC Building Block. 984 o Split normative and informative references 986 o Material applicable in a general LCT context, not just for ALC has 987 been moved to LCT 989 o The first bit of the "Protocol Specific Indication" in the LCT 990 Header is defined as a "Source Packet Indication". This is used 991 in the case that an FEC Scheme defines two FEC Payload ID formats, 992 one of which is for packets containing only source symbols which 993 can be processed by receivers that do not support FEC Decoding. 995 o Definition and IANA registration of the EXT_FTI LCT Header 996 Extension 998 9. References 1000 9.1. Normative references 1002 [I-D.ietf-rmt-bb-lct-revised] 1003 Luby, M., Watson, M., and L. Vicisano, "Layered Coding 1004 Transport (LCT) Building Block", 1005 draft-ietf-rmt-bb-lct-revised-11 (work in progress), 1006 August 2009. 1008 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1009 August 1980. 1011 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1012 RFC 1112, August 1989. 1014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1015 Requirement Levels", BCP 14, RFC 2119, March 1997. 1017 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1018 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1019 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1021 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1022 Types", RFC 3023, January 2001. 1024 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 1025 Control (WEBRC) Building Block", RFC 3738, April 2004. 1027 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1028 Internet Protocol", RFC 4301, December 2005. 1030 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1031 RFC 4303, December 2005. 1033 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1034 Description Protocol", RFC 4566, July 2006. 1036 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1037 Correction (FEC) Building Block", RFC 5052, August 2007. 1039 9.2. Informative references 1041 [I-D.ietf-msec-tesla-for-alc-norm] 1042 Roca, V., Francillon, A., and S. Faurite, "Use of TESLA in 1043 the ALC and NORM Protocols", 1044 draft-ietf-msec-tesla-for-alc-norm-07 (work in progress), 1045 December 2008. 1047 [I-D.ietf-rmt-simple-auth-for-alc-norm] 1048 Roca, V., "Simple Authentication Schemes for the ALC and 1049 NORM Protocols", 1050 draft-ietf-rmt-simple-auth-for-alc-norm-01 (work in 1051 progress), March 2009. 1053 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1054 Criteria for Evaluating Reliable Multicast Transport and 1055 Application Protocols", RFC 2357, June 1998. 1057 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1058 Announcement Protocol", RFC 2974, October 2000. 1060 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1061 Floyd, S., and M. Luby, "Reliable Multicast Transport 1062 Building Blocks for One-to-Many Bulk-Data Transfer", 1063 RFC 3048, January 2001. 1065 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 1066 Reliable Multicast Transport (RMT) Building Blocks and 1067 Protocol Instantiation documents", RFC 3269, April 2002. 1069 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 1070 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 1071 Instantiation", RFC 3450, December 2002. 1073 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1074 M., and J. Crowcroft, "The Use of Forward Error Correction 1075 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1077 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1078 Group Domain of Interpretation", RFC 3547, July 2003. 1080 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1081 Jacobson, "RTP: A Transport Protocol for Real-Time 1082 Applications", STD 64, RFC 3550, July 2003. 1084 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1085 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1086 RFC 3711, March 2004. 1088 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1089 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1090 August 2004. 1092 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1093 "GSAKMP: Group Secure Association Key Management 1094 Protocol", RFC 4535, June 2006. 1096 Authors' Addresses 1098 Michael Luby 1099 Qualcomm Inc. 1100 3165 Kifer Road 1101 Santa Clara, CA 95051 1102 US 1104 Email: luby@qualcomm.com 1106 Mark Watson 1107 Qualcomm Inc. 1108 3165 Kifer Road 1109 Santa Clara, CA 95051 1110 US 1112 Email: watson@qualcomm.com 1114 Lorenzo Vicisano 1115 Qualcomm Inc. 1116 3165 Kifer Road 1117 Santa Clara, CA 95051 1118 US 1120 Email: vicisano@qualcomm.com