idnits 2.17.1 draft-ietf-rmt-pi-alc-revised-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1574. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If more than one object is to be carried within a session then the Transmission Object Identifier (TOI) MUST be used in the LCT header to identify which packets are to be associated with which objects. In this case the receiver MUST use the TOI to associate received packets with objects. The TOI is scoped by the IP address of the sender and the TSI, i.e., the TOI is scoped by the session. The TOI for each object is REQUIRED to be unique within a session, but MAY NOT be unique across sessions. Furthermore, the same object MAY have a different TOI in different sessions. The mapping between TOIs and objects carried in a session is outside the scope of this document. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: All senders and receivers implementing ALC MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to parse its content. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2005) is 6862 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2026' is defined on line 1463, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HOL2001' -- Possible downref: Non-RFC (?) normative reference: ref. 'PER2001' ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Downref: Normative reference to an Informational RFC: RFC 2357 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Experimental RFC: RFC 2974 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Downref: Normative reference to an Informational RFC: RFC 3048 ** Downref: Normative reference to an Informational RFC: RFC 3269 ** Obsolete normative reference: RFC 3451 (Obsoleted by RFC 5651) ** Obsolete normative reference: RFC 3452 (Obsoleted by RFC 5052, RFC 5445) ** Downref: Normative reference to an Informational RFC: RFC 3453 Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast Transport (RMT) Luby 3 Working Group Digital Fountain 4 Internet-Draft Gemmell 5 Expires: January 7, 2006 Microsoft Research 6 Vicisano 7 Cisco Systems, Inc. 8 Rizzo 9 Univ. di Pisa 10 Crowcroft 11 University of Cambridge 12 July 6, 2005 14 Asynchronous Layered Coding (ALC) Protocol Instantiation 15 draft-ietf-rmt-pi-alc-revised-00 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 7, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document describes the Asynchronous Layered Coding (ALC) 49 protocol, a massively scalable reliable content delivery protocol. 50 Asynchronous Layered Coding combines the Layered Coding Transport 51 (LCT) building block, a multiple rate congestion control building 52 block and the Forward Error Correction (FEC) building block to 53 provide congestion controlled reliable asynchronous delivery of 54 content to an unlimited number of concurrent receivers from a single 55 sender. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Delivery service models . . . . . . . . . . . . . . . . . 4 61 1.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.3 Environmental Requirements and Considerations . . . . . . 6 63 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 9 64 2.1 LCT building block . . . . . . . . . . . . . . . . . . . . 10 65 2.2 Multiple rate congestion control building block . . . . . 11 66 2.3 FEC building block . . . . . . . . . . . . . . . . . . . . 11 67 2.4 Session Description . . . . . . . . . . . . . . . . . . . 13 68 2.5 Packet authentication building block . . . . . . . . . . . 15 69 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 16 70 4. Functionality Definition . . . . . . . . . . . . . . . . . . . 17 71 4.1 Packet format used by ALC . . . . . . . . . . . . . . . . 17 72 4.2 Detailed Example of Packet format used by ALC . . . . . . 18 73 4.3 Header-Extension Fields . . . . . . . . . . . . . . . . . 26 74 4.4 Sender Operation . . . . . . . . . . . . . . . . . . . . . 28 75 4.5 Receiver Operation . . . . . . . . . . . . . . . . . . . . 30 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 79 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 36 80 8.1 RFC3450 to draft-ietf-rmt-pi-alc-revised-00 . . . . . . . 36 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 83 Intellectual Property and Copyright Statements . . . . . . . . 39 85 1. Introduction 87 This document describes a massively scalable reliable content 88 delivery protocol, Asynchronous Layered Coding (ALC), for multiple 89 rate congestion controlled reliable content delivery. The protocol 90 is specifically designed to provide massive scalability using IP 91 multicast as the underlying network service. Massive scalability in 92 this context means the number of concurrent receivers for an object 93 is potentially in the millions, the aggregate size of objects to be 94 delivered in a session ranges from hundreds of kilobytes to hundreds 95 of gigabytes, each receiver can initiate reception of an object 96 asynchronously, the reception rate of each receiver in the session is 97 the maximum fair bandwidth available between that receiver and the 98 sender, and all of this can be supported using a single sender. 100 Because ALC is focused on reliable content delivery, the goal is to 101 deliver objects as quickly as possible to each receiver while at the 102 same time remaining network friendly to competing traffic. Thus, the 103 congestion control used in conjunction with ALC should strive to 104 maximize use of available bandwidth between receivers and the sender 105 while at the same time backing off aggressively in the face of 106 competing traffic. 108 The sender side of ALC consists of generating packets based on 109 objects to be delivered within the session and sending the 110 appropriately formatted packets at the appropriate rates to the 111 channels associated with the session. The receiver side of ALC 112 consists of joining appropriate channels associated with the session, 113 performing congestion control by adjusting the set of joined channels 114 associated with the session in response to detected congestion, and 115 using the packets to reliably reconstruct objects. All information 116 flow in an ALC session is in the form of data packets sent by a 117 single sender to channels that receivers join to receive data. 119 ALC does specify the Session Description needed by receivers before 120 they join a session, but the mechanisms by which receivers obtain 121 this required information is outside the scope of ALC. An 122 application that uses ALC may require that receivers report 123 statistics on their reception experience back to the sender, but the 124 mechanisms by which receivers report back statistics is outside the 125 scope of ALC. In general, ALC is designed to be a minimal protocol 126 instantiation that provides reliable content delivery without 127 unnecessary limitations to the scalability of the basic protocol. 129 This document is a product of the IETF RMT WG and follows the general 130 guidelines provided in [RFC3269]. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in BCP 14, [RFC2119]. 136 1.1 Delivery service models 138 ALC can support several different reliable content delivery service 139 models. Some examples are briefly described here. 141 Push service model 143 A push model is a sender initiated concurrent delivery of objects 144 to a selected set of receivers. A push service model can be used 145 for example for reliable delivery of a large object such as a 100 146 GB file. The sender could send a Session Description announcement 147 to a control channel and receivers could monitor this channel and 148 join a session whenever a Session Description of interest arrives. 149 Upon receipt of the Session Description, each receiver could join 150 the session to receive packets until enough packets have arrived 151 to reconstruct the object, at which point the receiver could 152 report back to the sender that its reception was completed 153 successfully. The sender could decide to continue sending packets 154 for the object to the session until all receivers have reported 155 successful reconstruction or until some other condition has been 156 satisfied. In this example, the sender uses ALC to generate 157 packets based on the object and send packets to channels 158 associated with the session, and the receivers use ALC to receive 159 packets from the session and reconstruct the object. 161 There are several features ALC provides to support the push model. 162 For example, the sender can optionally include an Expected 163 Residual Time (ERT) in the packet header that indicates the 164 expected remaining time of packet transmission for either the 165 single object carried in the session or for the object identified 166 by the Transmission Object Identifier (TOI) if there are multiple 167 objects carried in the session. This can be used by receivers to 168 determine if there is enough time remaining in the session to 169 successfully receive enough additional packets to recover the 170 object. If for example there is not enough time, then the push 171 application may have receivers report back to the sender to extend 172 the transmission of packets for the object for enough time to 173 allow the receivers to obtain enough packets to reconstruct the 174 object. The sender could then include an ERT based on the 175 extended object transmission time in each subsequent packet header 176 for the object. As other examples, the LCT header optionally can 177 contain a Close Session flag that indicates when the sender is 178 about to end sending packet to the session and a Close Object flag 179 that indicates when the sender is about to end sending packets to 180 the session for the object identified by the Transmission Object 181 ID. However, these flags are not a completely reliable mechanism 182 and thus the Close Session flag should only be used as a hint of 183 when the session is about to close and the Close Object flag 184 should only be used as a hint of when transmission of packets for 185 the object is about to end. 187 The push model is particularly attractive in satellite networks 188 and wireless networks. In these environments a session may 189 include one channel and a sender may send packets at a fixed rate 190 to this channel, but sending at a fixed rate without congestion 191 control is outside the scope of this document. 193 On-demand content delivery model 195 For an on-demand content delivery service model, senders typically 196 transmit for some given time period selected to be long enough to 197 allow all the intended receivers to join the session and recover a 198 single object. For example a popular software update might be 199 transmitted using ALC for several days, even though a receiver may 200 be able to complete the download in one hour total of connection 201 time, perhaps spread over several intervals of time. In this case 202 the receivers join the session at any point in time when it is 203 active. Receivers leave the session when they have received 204 enough packets to recover the object. The receivers, for example, 205 obtain a Session Description by contacting a web server. 207 Other service models 209 There may be other reliable content delivery service models that 210 can be supported by ALC. The description of the potential 211 applications, the appropriate delivery service model, and the 212 additional mechanisms to support such functionalities when 213 combined with ALC is beyond the scope of this document. 215 1.2 Scalability 217 Massive scalability is a primary design goal for ALC. IP multicast 218 is inherently massively scalable, but the best effort service that it 219 provides does not provide session management functionality, 220 congestion control or reliability. ALC provides all of this on top 221 of IP multicast without sacrificing any of the inherent scalability 222 of IP multicast. ALC has the following properties: 224 o To each receiver, it appears as if though there is a dedicated 225 session from the sender to the receiver, where the reception rate 226 adjusts to congestion along the path from sender to receiver. 228 o To the sender, there is no difference in load or outgoing rate if 229 one receiver is joined to the session or a million (or any number 230 of) receivers are joined to the session, independent of when the 231 receivers join and leave. 233 o No feedback packets are required from receivers to the sender. 235 o Almost all packets in the session that pass through a bottleneck 236 link are utilized by downstream receivers, and the session shares 237 the link with competing flows fairly in proportion to their 238 utility. 240 Thus, ALC provides a massively scalable content delivery transport 241 that is network friendly. 243 ALC intentionally omits any application specific features that could 244 potentially limit its scalability. By doing so, ALC provides a 245 minimal protocol that is massively scalable. Applications may be 246 built on top of ALC to provide additional features that may limit the 247 scalability of the application. Such applications are outside the 248 scope of this document. 250 1.3 Environmental Requirements and Considerations 252 All of the environmental requirements and considerations that apply 253 to the LCT building block [RFC3451], the FEC building block 254 [RFC3452], the multiple rate congestion control building block and to 255 any additional building blocks that ALC uses also apply to ALC. 257 ALC requires connectivity between a sender and receivers, but does 258 not require connectivity from receivers to a sender. ALC inherently 259 works with all types of networks, including LANs, WANs, Intranets, 260 the Internet, asymmetric networks, wireless networks, and satellite 261 networks. Thus, the inherent raw scalability of ALC is unlimited. 262 However, ALC requires receivers to obtain the Session Description 263 out-of-band before joining a session and some implementations of this 264 may limit scalability. 266 If a receiver is joined to multiple ALC sessions then the receiver 267 MUST be able to uniquely identify and demultiplex packets to the 268 correct session. The Transmission Session Identifier (TSI) that MUST 269 appear in each packet header is used for this purpose. The TSI is 270 scoped by the IP address of the sender, and the IP address of the 271 sender together with the TSI uniquely identify the session. Thus, 272 the demultiplexing MUST be done on the basis of the IP address of the 273 sender and the TSI of the session from that sender. 275 ALC is presumed to be used with an underlying IP multicast network or 276 transport service that is a "best effort" service that does not 277 guarantee packet reception, packet reception order, and which does 278 not have any support for flow or congestion control. There are 279 currently two models of multicast delivery, the Any-Source Multicast 280 (ASM) model as defined in [RFC1112] and the Source-Specific Multicast 281 (SSM) model as defined in [HOL2001]. ALC works with both multicast 282 models, but in a slightly different way with somewhat different 283 environmental concerns. When using ASM, a sender S sends packets to 284 a multicast group G, and an ALC channel address consists of the pair 285 (S,G), where S is the IP address of the sender and G is a multicast 286 group address. When using SSM, a sender S sends packets to an SSM 287 channel (S,G), and an ALC channel address coincides with the SSM 288 channel address. 290 A sender can locally allocate unique SSM channel addresses, and this 291 makes allocation of ALC channel addresses easy with SSM. To allocate 292 ALC channel addresses using ASM, the sender must uniquely choose the 293 ASM multicast group address across the scope of the group, and this 294 makes allocation of ALC channel addresses more difficult with ASM. 296 ALC channels and SSM channels coincide, and thus the receiver will 297 only receive packets sent to the requested ALC channel. With ASM, 298 the receiver joins an ALC channel by joining a multicast group G, and 299 all packets sent to G, regardless of the sender, may be received by 300 the receiver. Thus, SSM has compelling security advantages over ASM 301 for prevention of denial of service attacks. In either case, 302 receivers SHOULD use mechanisms to filter out packets from unwanted 303 sources. 305 Other issues specific to ALC with respect to ASM is the way the 306 multiple rate congestion control building block interacts with ASM. 307 The congestion control building block may use the measured difference 308 in time between when a join to a channel is sent and when the first 309 packet from the channel arrives in determining the receiver reception 310 rate. The congestion control building block may also uses packet 311 sequence numbers per channel to measure losses, and this is also used 312 to determine the receiver reception rate. These features raise two 313 concerns with respect to ASM: The time difference between when the 314 join to a channel is sent and when the first packet arrives can be 315 significant due to the use of Rendezvous Points (RPs) and the MSDP 316 protocol, and packets can be lost in the switch over from the (*,G) 317 join to the RP and the (S,G) join directly to the sender. Both of 318 these issues could potentially substantially degrade the reception 319 rate of receivers. To ameliorate these concerns, it is RECOMMENDED 320 that the RP be as close to the sender as possible. SSM does not 321 share these same concerns. For a fuller consideration of these 322 issues, consult the multiple rate congestion control building block. 324 Some networks are not amenable to some congestion control protocols 325 that could be used with ALC. In particular, for a satellite or 326 wireless network, there may be no mechanism for receivers to 327 effectively reduce their reception rate since there may be a fixed 328 transmission rate allocated to the session. 330 ALC is compatible with either IPv4 or IPv6 as no part of the packet 331 is IP version specific. 333 2. Architecture Definition 335 ALC uses the LCT building block [RFC3451] to provide in-band session 336 management functionality. ALC uses a multiple rate congestion 337 control building block that is compliant with [RFC2357] to provide 338 congestion control that is feedback free. Receivers adjust their 339 reception rates individually by joining and leaving channels 340 associated with the session. ALC uses the FEC building block 341 [RFC3452] to provide reliability. The sender generates encoding 342 symbols based on the object to be delivered using FEC codes and sends 343 them in packets to channels associated with the session. Receivers 344 simply wait for enough packets to arrive in order to reliably 345 reconstruct the object. Thus, there is no request for retransmission 346 of individual packets from receivers that miss packets in order to 347 assure reliable reception of an object, and the packets and their 348 rate of transmission out of the sender can be independent of the 349 number and the individual reception experiences of the receivers. 351 The definition of a session for ALC is the same as it is for LCT. An 352 ALC session comprises multiple channels originating at a single 353 sender that are used for some period of time to carry packets 354 pertaining to the transmission of one or more objects that can be of 355 interest to receivers. Congestion control is performed over the 356 aggregate of packets sent to channels belonging to a session. The 357 fact that an ALC session is restricted to a single sender does not 358 preclude the possibility of receiving packets for the same objects 359 from multiple senders. However, each sender would be sending packets 360 to a a different session to which congestion control is individually 361 applied. Although receiving concurrently from multiple sessions is 362 allowed, how this is done at the application level is outside the 363 scope of this document. 365 ALC is a protocol instantiation as defined in [RFC3048]. This 366 document describes version 1 of ALC which MUST use version 1 of LCT 367 described in [RFC3451]. Like LCT, ALC is designed to be used with 368 the IP multicast network service. This specification defines ALC as 369 payload of the UDP transport protocol [RFC0768] that supports IP 370 multicast delivery of packets. Future versions of this 371 specification, or companion documents may extend ALC to use the IP 372 network layer service directly. ALC could be used as the basis for 373 designing a protocol that uses a different underlying network service 374 such as unicast UDP, but the design of such a protocol is outside the 375 scope of this document. 377 An ALC packet header immediately follows the UDP header and consists 378 of the default LCT header that is described in [RFC3451] followed by 379 the FEC Payload ID that is described in [RFC3452]. The Congestion 380 Control Information field within the LCT header carries the required 381 Congestion Control Information that is described in the multiple rate 382 congestion control building block specified that is compliant with 383 [RFC2357]. The packet payload that follows the ALC packet header 384 consists of encoding symbols that are identified by the FEC Payload 385 ID as described in [RFC3452]. 387 Each receiver is required to obtain a Session Description before 388 joining an ALC session. As described later, the Session Description 389 includes out-of-band information required for the LCT, FEC and the 390 multiple rate congestion control building blocks. The FEC Object 391 Transmission Information specified in the FEC building block 392 [RFC3452] required for each object to be received by a receiver can 393 be communicated to a receiver either out-of-band or in-band using a 394 Header Extension. The means for communicating the Session 395 Description and the FEC Object Transmission Information to a receiver 396 is outside the scope of this document. 398 2.1 LCT building block 400 LCT requires receivers to be able to uniquely identify and 401 demultiplex packets associated with an LCT session, and ALC inherits 402 and strengthens this requirement. A Transport Session Identifier 403 (TSI) MUST be associated with each session and MUST be carried in the 404 LCT header of each ALC packet. The TSI is scoped by the sender IP 405 address, and the (sender IP address, TSI) pair MUST uniquely identify 406 the session. 408 The LCT header contains a Congestion Control Information (CCI) field 409 that MUST be used to carry the Congestion Control Information from 410 the specified multiple rate congestion control protocol. There is a 411 field in the LCT header that specifies the length of the CCI field, 412 and the multiple rate congestion control building block MUST uniquely 413 identify a format of the CCI field that corresponds to this length. 415 The LCT header contains a Codepoint field that MAY be used to 416 communicate to a receiver the settings for information that may vary 417 during a session. If used, the mapping between settings and 418 Codepoint values is to be communicated in the Session Description, 419 and this mapping is outside the scope of this document. For example, 420 the FEC Encoding ID that is part of the FEC Object Transmission 421 Information as specified in the FEC building block [RFC3452] could 422 vary for each object carried in the session, and the Codepoint value 423 could be used to communicate the FEC Encoding ID to be used for each 424 object. The mapping between FEC Encoding IDs and Codepoints could 425 be, for example, the identity mapping. 427 If more than one object is to be carried within a session then the 428 Transmission Object Identifier (TOI) MUST be used in the LCT header 429 to identify which packets are to be associated with which objects. 430 In this case the receiver MUST use the TOI to associate received 431 packets with objects. The TOI is scoped by the IP address of the 432 sender and the TSI, i.e., the TOI is scoped by the session. The TOI 433 for each object is REQUIRED to be unique within a session, but MAY 434 NOT be unique across sessions. Furthermore, the same object MAY have 435 a different TOI in different sessions. The mapping between TOIs and 436 objects carried in a session is outside the scope of this document. 438 If only one object is carried within a session then the TOI MAY be 439 omitted from the LCT header. 441 The default LCT header from version 1 of the LCT building block 442 [RFC3451] MUST be used. 444 2.2 Multiple rate congestion control building block 446 Implementors of ALC MUST implement a multiple rate feedback-free 447 congestion control building block that is in accordance to [RFC2357]. 448 Congestion control MUST be applied to all packets within a session 449 independently of which information about which object is carried in 450 each packet. Multiple rate congestion control is specified because 451 of its suitability to scale massively and because of its suitability 452 for reliable content delivery. The multiple rate congestion control 453 building block MUST specify in-band Congestion Control Information 454 (CCI) that MUST be carried in the CCI field of the LCT header. The 455 multiple rate congestion control building block MAY specify more than 456 one format, but it MUST specify at most one format for each of the 457 possible lengths 32, 64, 96 or 128 bits. The value of C in the LCT 458 header that determines the length of the CCI field MUST correspond to 459 one of the lengths for the CCI defined in the multiple rate 460 congestion control building block, this length MUST be the same for 461 all packets sent to a session, and the CCI format that corresponds to 462 the length as specified in the multiple rate congestion control 463 building block MUST be the format used for the CCI field in the LCT 464 header. 466 When using a multiple rate congestion control building block a sender 467 sends packets in the session to several channels at potentially 468 different rates. Then, individual receivers adjust their reception 469 rate within a session by adjusting which set of channels they are 470 joined to at each point in time depending on the available bandwidth 471 between the receiver and the sender, but independent of other 472 receivers. 474 2.3 FEC building block 476 The FEC building block [RFC3452] provides reliable object delivery 477 within an ALC session. Each object sent in the session is 478 independently encoded using FEC codes as described in [RFC3453], 479 which provide a more in-depth description of the use of FEC codes in 480 reliable content delivery protocols. All packets in an ALC session 481 MUST contain an FEC Payload ID in a format that is compliant with the 482 FEC building block [RFC3452]. The FEC Payload ID uniquely identifies 483 the encoding symbols that constitute the payload of each packet, and 484 the receiver MUST use the FEC Payload ID to determine how the 485 encoding symbols carried in the payload of the packet were generated 486 from the object as described in the FEC building block. 488 As described in [RFC3452], a receiver is REQUIRED to obtain the FEC 489 Object Transmission Information for each object for which data 490 packets are received from the session. The FEC Object Transmission 491 Information includes: 493 o The FEC Encoding ID. 495 o If an Under-Specified FEC Encoding ID is used then the FEC 496 Instance ID associated with the FEC Encoding ID. 498 o For each object in the session, the length of the object in bytes. 500 o The additional required FEC Object Transmission Information for 501 the FEC Encoding ID as prescribed in the FEC building block 502 [RFC3452]. For example, when the FEC Encoding ID is 128, the 503 required FEC Object Transmission Information is the number of 504 source blocks that the object is partitioned into and the length 505 of each source block in bytes. 507 Some of the FEC Object Transmission Information MAY be implicit based 508 on the implementation. As an example, source block lengths may be 509 derived by a fixed algorithm from the object length. As another 510 example, it may be that all source blocks are the same length and 511 this is what is passed out-of-band to the receiver. As another 512 example, it could be that the full sized source block length is 513 provided and this is the length used for all but the last source 514 block, which is calculated based on the full source block length and 515 the object length. As another example, it could be that the same FEC 516 Encoding ID and FEC Instance ID are always used for a particular 517 application and thus the FEC Encoding ID and FEC Instance ID are 518 implicitly defined. 520 Sometimes the objects that will be sent in a session are completely 521 known before the receiver joins the session, in which case the FEC 522 Object Transmission Information for all objects in the session can be 523 communicated to receivers before they join the session. At other 524 times the objects may not know when the session begins, or receivers 525 may join a session in progress and may not be interested in some 526 objects for which transmission has finished, or receivers may leave a 527 session before some objects are even available within the session. 528 In these cases, the FEC Object Transmission Information for each 529 object may be dynamically communicated to receivers at or before the 530 time packets for the object are received from the session. This may 531 be accomplished using either an out-of-band mechanism, in-band using 532 the Codepoint field or a Header Extension, or any combination of 533 these methods. How the FEC Object Transmission Information is 534 communicated to receivers is outside the scope of this document. 536 If packets for more than one object are transmitted within a session 537 then a Transmission Object Identifier (TOI) that uniquely identifies 538 objects within a session MUST appear in each packet header. Portions 539 of the FEC Object Transmission Information could be the same for all 540 objects in the session, in which case these portions can be 541 communicated to the receiver with an indication that this applies to 542 all objects in the session. These portions may be implicitly 543 determined based on the application, e.g., an application may use the 544 same FEC Encoding ID for all objects in all sessions. If there is a 545 portion of the FEC Object Transmission Information that may vary from 546 object to object and if this FEC Object Transmission Information is 547 communicated to a receiver out-of-band then the TOI for the object 548 MUST also be communicated to the receiver together with the 549 corresponding FEC Object Transmission Information, and the receiver 550 MUST use the corresponding FEC Object Transmission Information for 551 all packets received with that TOI. How the TOI and corresponding 552 FEC Object Transmission Information is communicated out-of-band to 553 receivers is outside the scope of this document. 555 It is also possible that there is a portion of the FEC Object 556 Transmission Information that may vary from object to object that is 557 carried in-band, for example in the CodePoint field or in Header 558 Extensions. How this is done is outside the scope of this document. 559 In this case the FEC Object Transmission Information is associated 560 with the object identified by the TOI carried in the packet. 562 2.4 Session Description 564 The Session Description that a receiver is REQUIRED to obtain before 565 joining an ALC session MUST contain the following information: 567 o The multiple rate congestion control building block to be used for 568 the session; 570 o The sender IP address; 571 o The number of channels in the session; 573 o The address and port number used for each channel in the session; 575 o The Transport Session ID (TSI) to be used for the session; 577 o An indication of whether or not the session carries packets for 578 more than one object; 580 o If Header Extensions are to be used, the format of these Header 581 Extensions. 583 o Enough information to determine the packet authentication scheme 584 being used, if it is being used. 586 How the Session Description is communicated to receivers is outside 587 the scope of this document. 589 The Codepoint field within the LCT portion of the header CAN be used 590 to communicate in-band some of the dynamically changing information 591 within a session. To do this, a mapping between Codepoint values and 592 the different dynamic settings MUST be included within the Session 593 Description, and then settings to be used are communicated via the 594 Codepoint value placed into each packet. For example, it is possible 595 that multiple objects are delivered within the same session and that 596 a different FEC encoding algorithm is used for different types of 597 objects. Then the Session Description could contain the mapping 598 between Codepoint values and FEC Encoding IDs. As another example, 599 it is possible that a different packet authentication scheme is used 600 for different packets sent to the session. In this case, the mapping 601 between the packet authentication scheme and Codepoint values could 602 be provided in the Session Description. Combinations of settings can 603 be mapped to Codepoint values as well. For example, a particular 604 combination of a FEC Encoding ID and a packet authentication scheme 605 could be associated with a Codepoint value. 607 The Session Description could also include, but is not limited to: 609 o The mappings between combinations of settings and Codepoint 610 values; 612 o The data rates used for each channel; 614 o The length of the packet payload; 616 o Any information that is relevant to each object being transported, 617 such as the Object Transmission Information for each object, when 618 the object will be available within the session and for how long. 620 The Session Description could be in a form such as SDP as defined in 621 [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime 622 headers as defined in [RFC2616], etc. It might be carried in a 623 session announcement protocol such as SAP as defined in [RFC2974], 624 obtained using a proprietary session control protocol, located on a 625 web page with scheduling information, or conveyed via E-mail or other 626 out-of-band methods. Discussion of Session Description formats and 627 methods for communication of Session Descriptions to receivers is 628 beyond the scope of this document. 630 2.5 Packet authentication building block 632 It is RECOMMENDED that implementors of ALC use some packet 633 authentication scheme to protect the protocol from attacks. An 634 example of a possibly suitable scheme is described in [PER2001]. 635 Packet authentication in ALC, if used, is to be integrated through 636 the Header Extension support for packet authentication provided in 637 the LCT building block. 639 3. Conformance Statement 641 This Protocol Instantiation document, in conjunction with the LCT 642 building block [RFC3451], the FEC building block [RFC3452] and with a 643 multiple rate congestion control building block completely specifies 644 a working reliable multicast transport protocol that conforms to the 645 requirements described in [RFC2357]. 647 4. Functionality Definition 649 This section describes the format and functionality of the data 650 packets carried in an ALC session as well as the sender and receiver 651 operations for a session. 653 4.1 Packet format used by ALC 655 The packet format used by ALC is the UDP header followed by the 656 default LCT header followed by the FEC Payload ID followed by the 657 packet payload. The default LCT header is described in the LCT 658 building block [RFC3451] and the FEC Payload ID is described in the 659 FEC building block [RFC3452]. The Congestion Control Information 660 field in the LCT header contains the REQUIRED Congestion Control 661 Information that is described in the multiple rate congestion control 662 building block used. The packet payload contains encoding symbols 663 generated from an object. If more than one object is carried in the 664 session then the Transmission Object ID (TOI) within the LCT header 665 MUST be used to identify which object the encoding symbols are 666 generated from. Within the scope of an object, encoding symbols 667 carried in the payload of the packet are identified by the FEC 668 Payload ID as described in the FEC building block. 670 The version number of ALC specified in this document is 1. This 671 coincides with version 1 of the LCT building block [RFC3451] used in 672 this specification. The LCT version number field should be 673 interpreted as the ALC version number field. 675 The overall ALC packet format is depicted in Figure 1. The packet is 676 an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP 677 header. The ALC packet format has no dependencies on the IP version 678 number. The default LCT header MUST be used by ALC and this default 679 is described in detail in the LCT building block [RFC3451]. 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | UDP header | 685 | | 686 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 687 | Default LCT header | 688 | | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | FEC Payload ID | 691 | | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Encoding Symbol(s) | 694 | ... | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 Figure 1: Overall ALC packet format 699 In some special cases an ALC sender may need to produce ALC packets 700 that do not contain any payload. This may be required, for example, 701 to signal the end of a session or to convey congestion control 702 information. These data-less packets do not contain the FEC Payload 703 ID either, but only the LCT header fields. The total datagram 704 length, conveyed by outer protocol headers (e.g., the IP or UDP 705 header), enables receivers to detect the absence of the ALC payload 706 and FEC Payload ID. 708 4.2 Detailed Example of Packet format used by ALC 710 A detailed example of an ALC packet starting with the LCT header is 711 shown in Figure 2. In the example, the LCT header is the first 5 32- 712 bit words, the FEC Payload ID is the next 2 32-bit words, and the 713 remainder of the packet is the payload. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | 1 | 0 | 0 |1| 1 |0|1|0|0|0| 5 | 128 | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Congestion Control Information (CCI, length = 32 bits) | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Transport Session Identifier (TSI, length = 32 bits) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Transport Object Identifier (TOI, length = 32 bits) | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Sender Current Time | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Source Block Number | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Encoding Symbol ID | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Encoding Symbol(s) | 733 | ... | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Figure 2: A detailed example of the ALC packet format 738 The LCT portion of the overall ALC packet header is of variable size, 739 which is specified by a length field in the third byte of the header. 740 All integer fields are carried in "big-endian" or "network order" 741 format, that is, most significant byte (octet) first. Bits 742 designated as "padding" or "reserved" (r) MUST by set to 0 by senders 743 and ignored by receivers. Unless otherwise noted, numeric constants 744 in this specification are in decimal (base 10). 746 The function and length and particular setting of the value for each 747 field in this detailed example of the header is the following, 748 described in the order of their appearance in the header. 750 ALC version number (V): 4 bits 752 Indicates the ALC version number. The ALC version number for this 753 specification is 1 as shown. This is also the LCT version number. 755 Congestion control flag (C): 2 bits 757 The Congestion Control Information (CCI) field specified by the 758 multiple rate congestion control building block is a multiple of 759 32-bits in length. The multiple rate congestion control building 760 block MUST specify a format for the CCI. The congestion control 761 building block MAY specify formats for different CCI lengths, 762 where the set of possible lengths is 32, 64, 96 or 128 bits. The 763 value of C MUST match the length of exactly one of the possible 764 formats for the congestion control building block, and this format 765 MUST be used for the CCI field. The value of C MUST be the same 766 for all packets sent to a session. 768 C=0 indicates the 32-bit CCI field format is to be used. 770 C=1 indicates the 64-bit CCI field format is to be used. 772 C=2 indicates the 96-bit CCI field format is to be used. 774 C=3 indicates the 128-bit CCI field format is to be used. 776 In the example C=0 indicates that a 32-bit format is to be used. 778 Reserved (r): 2 bits 780 Reserved for future use. A sender MUST set these bits to zero and 781 a receiver MUST ignore these bits. 783 As required, these bits are set to 0 in the example. 785 Transport Session Identifier flag (S): 1 bit 787 This is the number of full 32-bit words in the TSI field. The TSI 788 field is 32*S + 16*H bits in length. For ALC the length of the 789 TSI field is REQUIRED to be non-zero. This implies that the 790 setting S=0 and H=0 MUST NOT be used. 792 In the example S=1 and H=0, and thus the TSI is 32-bits in length. 794 Transport Object Identifier flag (O): 2 bits 796 This is the number of full 32-bit words in the TOI field. The TOI 797 field is 32*O + 16*H bits in length. If more than one object is 798 to be delivered in the session then the TOI MUST be used, in which 799 case the setting O=0 and H=0 MUST NOT be used. 801 In the example O=1 and H=0, and thus the TOI is 32-bits in length. 803 Half-word flag (H): 1 bit 805 The TSI and the TOI fields are both multiples of 32-bits plus 16*H 806 bits in length. This allows the TSI and TOI field lengths to be 807 multiples of a half-word (16 bits), while ensuring that the 808 aggregate length of the TSI and TOI fields is a multiple of 32- 809 bits. 811 In the example H=0 which indicates that both TSI and TOI are both 812 multiples of 32-bits in length. 814 Sender Current Time present flag (T): 1 bit 816 T = 0 indicates that the Sender Current Time (SCT) field is not 817 present. 819 T = 1 indicates that the SCT field is present. The SCT is 820 inserted by senders to indicate to receivers how long the session 821 has been in progress. 823 In the example T=1, which indicates that the SCT is carried in 824 this packet. 826 Expected Residual Time present flag (R): 1 bit 828 R = 0 indicates that the Expected Residual Time (ERT) field is not 829 present. 831 R = 1 indicates that the ERT field is present. 833 The ERT is inserted by senders to indicate to receivers how much 834 longer packets will be sent to the session for either the single 835 object carried in the session or for the object identified by the 836 TOI if there are multiple objects carried in the session. Senders 837 MUST NOT set R = 1 when the ERT for the object is more than 2^32-1 838 time units (approximately 49 days), where time is measured in 839 units of milliseconds. 841 In the example R=0, which indicates that the ERT is not carried in 842 this packet. 844 Close Session flag (A): 1 bit 846 Normally, A is set to 0. The sender MAY set A to 1 when 847 termination of transmission of packets for the session is 848 imminent. A MAY be set to 1 in just the last packet transmitted 849 for the session, or A MAY be set to 1 in the last few seconds of 850 packets transmitted for the session. Once the sender sets A to 1 851 in one packet, the sender SHOULD set A to 1 in all subsequent 852 packets until termination of transmission of packets for the 853 session. A received packet with A set to 1 indicates to a 854 receiver that the sender will immediately stop sending packets for 855 the session. When a receiver receives a packet with A set to 1 856 the receiver SHOULD assume that no more packets will be sent to 857 the session. 859 In the example A=0, and thus this packet does not indicate the 860 close of the session. 862 Close Object flag (B): 1 bit 864 Normally, B is set to 0. The sender MAY set B to 1 when 865 termination of transmission of packets for an object is imminent. 866 If the TOI field is in use and B is set to 1 then termination of 867 transmission for the object identified by the TOI field is 868 imminent. If the TOI field is not in use and B is set to 1 then 869 termination of transmission for the one object in the session 870 identified by out-of-band information is imminent. B MAY be set 871 to 1 in just the last packet transmitted for the object, or B MAY 872 be set to 1 in the last few seconds packets transmitted for the 873 object. Once the sender sets B to 1 in one packet for a 874 particular object, the sender SHOULD set B to 1 in all subsequent 875 packets for the object until termination of transmission of 876 packets for the object. A received packet with B set to 1 877 indicates to a receiver that the sender will immediately stop 878 sending packets for the object. When a receiver receives a packet 879 with B set to 1 then it SHOULD assume that no more packets will be 880 sent for the object to the session. 882 In the example B=0, and thus this packet does not indicate the end 883 of sending data packets for the object. 885 LCT header length (HDR_LEN): 8 bits 887 Total length of the LCT header in units of 32-bit words. The 888 length of the LCT header MUST be a multiple of 32-bits. This 889 field can be used to directly access the portion of the packet 890 beyond the LCT header, i.e., the FEC Payload ID if the packet 891 contains a payload, or the end of the packet if the packet 892 contains no payload. 894 In the example HDR_LEN=5 to indicate that the length of the LCT 895 header portion of the overall ALC is 5 32-bit words. 897 Codepoint (CP): 8 bits 899 This field is used by ALC to carry the mapping that identifies 900 settings for portions of the Session Description that can change 901 within the session. The mapping between Codepoint values and the 902 settings for portions of the Session Description is to be 903 communicated out-of-band. 905 In the example the portion of the Session Description that can 906 change within the session is the FEC Encoding ID, and the identity 907 mapping is used between Codepoint values and FEC Encoding IDs. 908 Thus, CP=128 identifies FEC Encoding ID 128, the "Small Block, 909 Large Block and Expandable FEC Codes" as described in the FEC 910 building block [RFC3452]. The FEC Payload ID associated with FEC 911 Encoding ID 128 is 64-bits in length. 913 Congestion Control Information (CCI): 32, 64, 96 or 128 bits 915 This is field contains the Congestion Control Information as 916 defined by the specified multiple rate congestion control building 917 block. The format of this field is determined by the multiple 918 rate congestion control building block. 920 This field MUST be 32 bits if C=0. 922 This field MUST be 64 bits if C=1. 924 This field MUST be 96 bits if C=2. 926 This field MUST be 128 bits if C=3. 928 In the example, the CCI is 32-bits in length. The format of the 929 CCI field for the example MUST correspond to the format for the 930 32-bit version of the CCI specified in the multiple rate 931 congestion control building block. 933 Transport Session Identifier (TSI): 16, 32 or 48 bits 935 The TSI uniquely identifies a session among all sessions from a 936 particular sender. The TSI is scoped by the sender IP address, 937 and thus the (sender IP address, TSI) pair uniquely identify the 938 session. For ALC, the TSI MUST be included in the LCT header. 940 The TSI MUST be unique among all sessions served by the sender 941 during the period when the session is active, and for a large 942 period of time preceding and following when the session is active. 943 A primary purpose of the TSI is to prevent receivers from 944 inadvertently accepting packets from a sender that belong to 945 sessions other than sessions receivers are subscribed to. For 946 example, suppose a session is deactivated and then another session 947 is activated by a sender and the two sessions use an overlapping 948 set of channels. A receiver that connects and remains connected 949 to the first session during this sender activity could possibly 950 accept packets from the second session as belonging to the first 951 session if the TSI for the two sessions were identical. The 952 mapping of TSI field values to sessions is outside the scope of 953 this document and is to be done out-of-band. 955 The length of the TSI field is 32*S + 16*H bits. Note that the 956 aggregate lengths of the TSI field plus the TOI field is a 957 multiple of 32 bits. 959 In the example the TSI is 32 bits in length. 961 Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 962 bits. 964 This field indicates which object within the session this packet 965 pertains to. For example, a sender might send a number of files 966 in the same session, using TOI=0 for the first file, TOI=1 for the 967 second one, etc. As another example, the TOI may be a unique 968 global identifier of the object that is being transmitted from 969 several senders concurrently, and the TOI value may be the output 970 of a hash function applied to the object. The mapping of TOI 971 field values to objects is outside the scope of this document and 972 is to be done out-of-band. The TOI field MUST be used in all 973 packets if more than one object is to be transmitted in a session, 974 i.e., the TOI field is either present in all the packets of a 975 session or is never present. 977 The length of the TOI field is 32*O + 16*H bits. Note that the 978 aggregate lengths of the TSI field plus the TOI field is a 979 multiple of 32 bits. 981 In the example the TOI is 32 bits in length. 983 Sender Current Time (SCT): 0 or 32 bits 985 This field represents the current clock of the sender at the time 986 this packet was transmitted, measured in units of 1ms and computed 987 modulo 2^32 units from the start of the session. 989 This field MUST NOT be present if T=0 and MUST be present if T=1. 991 In this example the SCT is present. 993 Expected Residual Time (ERT): 0 or 32 bits 995 This field represents the sender expected residual transmission 996 time of packets for either the single object carried in the 997 session or for the object identified by the TOI if there are 998 multiple objects carried in the session. 1000 This field MUST NOT be present if R=0 and MUST be present if R=1. 1002 In this example the ERT is not present. 1004 FEC Payload ID: X bits 1006 The length and format of the FEC Payload ID depends on the FEC 1007 Encoding ID as described in the FEC building block [RFC3452]. The 1008 FEC Payload ID format is determined by the FEC Encoding ID that 1009 MUST be communicated in the Session Description. The Session 1010 Description MAY specify that more than one FEC Encoding ID is used 1011 in the session, in which case the Session Description MUST contain 1012 a mapping that identifies which Codepoint values correspond to 1013 which FEC Encoding IDs. This mapping, if used, is outside the 1014 scope of this document. 1016 The example packet format corresponds to the format for "Small 1017 Block, Large Block and Expandable FEC Codes" as described in the 1018 FEC building block, for which the associated FEC Encoding ID 128. 1019 For FEC Encoding ID 128, the FEC Payload ID consists of the 1020 following two fields that in total are X = 64 bits in length: 1022 Source Block Number (SBN): 32 bits 1024 The Source Block Number identifies from which source block of 1025 the object the encoding symbol(s) in the payload are generated. 1026 These blocks are numbered consecutively from 0 to N-1, where N 1027 is the number of source blocks in the object. 1029 Encoding Symbol ID (ESI): 32 bits 1031 The Encoding Symbol ID identifies which specific encoding 1032 symbol(s) generated from the source block are carried in the 1033 packet payload. The exact details of the correspondence 1034 between Encoding Symbol IDs and the encoding symbol(s) in the 1035 packet payload are dependent on the particular encoding 1036 algorithm used as identified by the FEC Encoding ID and by the 1037 FEC Instance ID. 1039 Encoding Symbol(s): Y bits 1041 The encoding symbols are what the receiver uses to reconstruct an 1042 object. The total length Y of the encoding symbol(s) in the 1043 packet can be determined by the receiver of the packet by 1044 computing the total length of the received packet and subtracting 1045 off the length of the headers. 1047 4.3 Header-Extension Fields 1049 Header Extensions can be used to extend the LCT header portion of the 1050 ALC header to accommodate optional header fields that are not always 1051 used or have variable size. Header Extensions are not used in the 1052 example ALC packet format shown in the previous subsection. Examples 1053 of the use of Header Extensions include: 1055 o Extended-size versions of already existing header fields. 1057 o Sender and Receiver authentication information. 1059 The presence of Header Extensions can be inferred by the LCT header 1060 length (HDR_LEN): if HDR_LEN is larger than the length of the 1061 standard header then the remaining header space is taken by Header 1062 Extension fields. 1064 If present, Header Extensions MUST be processed to ensure that they 1065 are recognized before performing any congestion control procedure or 1066 otherwise accepting a packet. The default action for unrecognized 1067 Header Extensions is to ignore them. This allows the future 1068 introduction of backward-compatible enhancements to ALC without 1069 changing the ALC version number. Non backward-compatible Header 1070 Extensions CANNOT be introduced without changing the ALC version 1071 number. 1073 There are two formats for Header Extension fields, as depicted below. 1074 The first format is used for variable-length extensions, with Header 1075 Extension Type (HET) values between 0 and 127. The second format is 1076 used for fixed length (one 32-bit word) extensions, using HET values 1077 from 127 to 255. 1079 0 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | HET (<=127) | HEL | | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1084 . . 1085 . Header Extension Content (HEC) . 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | HET (>=128) | Header Extension Content (HEC) | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 Figure 3: Format of additional headers 1095 The explanation of each sub-field is the following. 1097 Header Extension Type (HET): 8 bits 1099 The type of the Header Extension. This document defines a number 1100 of possible types. Additional types may be defined in future 1101 versions of this specification. HET values from 0 to 127 are used 1102 for variable-length Header Extensions. HET values from 128 to 255 1103 are used for fixed-length 32-bit Header Extensions. 1105 Header Extension Length (HEL): 8 bits 1107 The length of the whole Header Extension field, expressed in 1108 multiples of 32-bit words. This field MUST be present for 1109 variable-length extensions (HET between 0 and 127) and MUST NOT be 1110 present for fixed-length extensions (HET between 128 and 255). 1112 Header Extension Content (HEC): variable length 1114 The content of the Header Extension. The format of this sub- 1115 field depends on the Header Extension type. For fixed-length 1116 Header Extensions, the HEC is 24 bits. For variable-length Header 1117 Extensions, the HEC field has variable size, as specified by the 1118 HEL field. Note that the length of each Header Extension field 1119 MUST be a multiple of 32 bits. Also note that the total size of 1120 the LCT header, including all Header Extensions and all optional 1121 header fields, cannot exceed 255 32-bit words. 1123 Header Extensions are further divided between general LCT extensions 1124 and Protocol Instantiation specific extensions (PI-specific). 1125 General LCT extensions have HET in the ranges 0:63 and 128:191 1126 inclusive. PI-specific extensions have HET in the ranges 64:127 and 1127 192:255 inclusive. 1129 General LCT extensions are intended to allow the introduction of 1130 backward-compatible enhancements to LCT without changing the LCT 1131 version number. Non backward-compatible Header Extensions CANNOT be 1132 introduced without changing the LCT version number. 1134 PI-specific extensions are reserved for PI-specific use with semantic 1135 and default parsing actions defined by the PI. 1137 The following general LCT Header Extension types are defined: 1139 EXT_NOP=0 No-Operation extension. The information present in 1140 this extension field MUST be ignored by receivers. 1142 EXT_AUTH=1 Packet authentication extension Information used to 1143 authenticate the sender of the packet. The format of 1144 this Header Extension and its processing is outside the 1145 scope of this document and is to be communicated out- 1146 of-band as part of the Session Description. 1148 It is RECOMMENDED that senders provide some form of 1149 packet authentication. If EXT_AUTH is present, 1150 whatever packet authentication checks that can be 1151 performed immediately upon reception of the packet 1152 SHOULD be performed before accepting the packet and 1153 performing any congestion control-related action on it. 1154 Some packet authentication schemes impose a delay of 1155 several seconds between when a packet is received and 1156 when the packet is fully authenticated. Any congestion 1157 control related action that is appropriate MUST NOT be 1158 postponed by any such full packet authentication. 1160 All senders and receivers implementing ALC MUST support the EXT_NOP 1161 Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to 1162 parse its content. 1164 For this version of ALC, the following PI-specific extension is 1165 defined: 1167 EXT_FTI=64 FEC Object Transmission Information extension The 1168 purpose of this extension is to carry in-band the FEC 1169 Object Transmission Information for an object. The 1170 format of this Header Extension and its processing is 1171 outside the scope of this document and is to be 1172 communicated out-of-band as part of the Session 1173 Description. 1175 4.4 Sender Operation 1177 The sender operation when using ALC includes all the points made 1178 about the sender operation when using the LCT building block 1179 [RFC3451], the FEC building block [RFC3452] and the multiple rate 1180 congestion control building block. 1182 A sender using ALC MUST make available the required Session 1183 Description as described in Section 2.4. A sender also MUST make 1184 available the required FEC Object Transmission Information as 1185 described in Section 2.3. 1187 Within a session a sender transmits a sequence of packets to the 1188 channels associated with the session. The ALC sender MUST obey the 1189 rules for filling in the CCI field in the packet headers and MUST 1190 send packets at the appropriate rates to the channels associated with 1191 the session as dictated by the multiple rate congestion control 1192 building block. 1194 The ALC sender MUST use the same TSI for all packets in the session. 1195 Several objects MAY be delivered within the same ALC session. If 1196 more than one object is to be delivered within a session then the 1197 sender MUST use the TOI field and each object MUST be identified by a 1198 unique TOI within the session, and the sender MUST use corresponding 1199 TOI for all packets pertaining to the same object. The FEC Payload 1200 ID MUST correspond to the encoding symbol(s) for the object carried 1201 in the payload of the packet. 1203 Objects MAY be transmitted sequentially within a session, and they 1204 MAY be transmitted concurrently. However, it is good practice to 1205 only send objects concurrently in the same session if the receivers 1206 that participate in that portion of the session have interest in 1207 receiving all the objects. The reason for this is that it wastes 1208 bandwidth and networking resources to have receivers receive data for 1209 objects that they have no interest in. However, there are no rules 1210 with respect to mixing packets for different objects carried within 1211 the session. Although this issue affects the efficiency of the 1212 protocol, it does not affect the correctness nor the inter- 1213 operability of ALC between senders and receivers. 1215 Typically, the sender(s) continues to send packets in a session until 1216 the transmission is considered complete. The transmission may be 1217 considered complete when some time has expired, a certain number of 1218 packets have been sent, or some out-of-band signal (possibly from a 1219 higher level protocol) has indicated completion by a sufficient 1220 number of receivers. 1222 It is RECOMMENDED that packet authentication be used. If packet 1223 authentication is used then the Header Extensions described in 1224 Section 4.3 MUST be used to carry the authentication. 1226 This document does not pose any restriction on packet sizes. 1227 However, network efficiency considerations recommend that the sender 1228 uses as large as possible packet payload size, but in such a way that 1229 packets do not exceed the network's maximum transmission unit size 1230 (MTU), or fragmentation coupled with packet loss might introduce 1231 severe inefficiency in the transmission. It is RECOMMENDED that all 1232 packets have the same or very similar sizes, as this can have a 1233 severe impact on the effectiveness of the multiple rate congestion 1234 control building block. 1236 4.5 Receiver Operation 1238 The receiver operation when using ALC includes all the points made 1239 about the receiver operation when using the LCT building block 1240 [RFC3451], the FEC building block [RFC3452] and the multiple rate 1241 congestion control building block. 1243 To be able to participate in a session, a receiver MUST obtain the 1244 REQUIRED Session Description as listed in Section 2.4. How receivers 1245 obtain a Session Description is outside the scope of this document. 1247 To be able to be a receiver in a session, the receiver MUST be able 1248 to process the ALC header. The receiver MUST be able to discard, 1249 forward, store or process the other headers and the packet payload. 1250 If a receiver is not able to process the ALC header, it MUST drop 1251 from the session. 1253 To be able to participate in a session, a receiver MUST implement the 1254 multiple rate congestion control building block using the Congestion 1255 Control Information field provided in the LCT header. If a receiver 1256 is not able to implement the multiple rate congestion control 1257 building block it MUST NOT join the session. 1259 Several objects can be carried either sequentially or concurrently 1260 within the same session. In this case, each object is identified by 1261 a unique TOI. Note that even if a sender stops sending packets for 1262 an old object before starting to transmit packets for a new object, 1263 both the network and the underlying protocol layers can cause some 1264 reordering of packets, especially when sent over different channels, 1265 and thus receivers SHOULD NOT assume that the reception of a packet 1266 for a new object means that there are no more packets in transit for 1267 the previous one, at least for some amount of time. 1269 As described in Section 2.3, a receiver MUST obtain the required FEC 1270 Object Transmission Information for each object for which the 1271 receiver receives and processes packets. 1273 A receiver MAY concurrently join multiple ALC sessions from one or 1274 more senders. The receiver MUST perform congestion control on each 1275 such session. The receiver MAY make choices to optimize the packet 1276 flow performance across multiple sessions, as long as the receiver 1277 still adheres to the multiple rate congestion control building block 1278 for each session individually. 1280 Upon receipt of each packet the receiver proceeds with the following 1281 steps in the order listed. 1283 1. The receiver MUST parse the packet header and verify that it is a 1284 valid header. If it is not valid then the packet MUST be 1285 discarded without further processing. If multiple packets are 1286 received that cannot be parsed then the receiver SHOULD leave the 1287 session. 1289 2. The receiver MUST verify that the sender IP address together with 1290 the TSI carried in the header matches one of the (sender IP 1291 address, TSI) pairs that was received in a Session Description 1292 and that the receiver is currently joined to. If there is not a 1293 match then the packet MUST be discarded without further 1294 processing. If multiple packets are received with non-matching 1295 (sender IP address, TSI) values then the receiver SHOULD leave 1296 the session. If the receiver is joined to multiple ALC sessions 1297 then the remainder of the steps are performed within the scope of 1298 the (sender IP address, TSI) session of the received packet. 1300 3. The receiver MUST process and act on the CCI field in accordance 1301 with the multiple rate congestion control building block. 1303 4. If more than one object is carried in the session, the receiver 1304 MUST verify that the TOI carried in the LCT header is valid. If 1305 the TOI is not valid, the packet MUST be discarded without 1306 further processing. 1308 5. The receiver SHOULD process the remainder of the packet, 1309 including interpreting the other header fields appropriately, and 1310 using the FEC Payload ID and the encoding symbol(s) in the 1311 payload to reconstruct the corresponding object. 1313 It is RECOMMENDED that packet authentication be used. If packet 1314 authentication is used then it is RECOMMENDED that the receiver 1315 immediately check the authenticity of a packet before proceeding with 1316 step (3) above. If immediate checking is possible and if the packet 1317 fails the check then the receiver MUST discard the packet and reduce 1318 its reception rate to a minimum before continuing to regulate its 1319 reception rate using the multiple rate congestion control. 1321 Some packet authentication schemes such as TESLA [PER2001] do not 1322 allow an immediate authenticity check. In this case the receiver 1323 SHOULD check the authenticity of a packet as soon as possible, and if 1324 the packet fails the check then it MUST be discarded before step (5) 1325 above and reduce its reception rate to a minimum before continuing to 1326 regulate its reception rate using the multiple rate congestion 1327 control. 1329 5. Security Considerations 1331 The same security consideration that apply to the LCT, FEC and the 1332 multiple rate congestion control building blocks also apply to ALC. 1334 Because of the use of FEC, ALC is especially vulnerable to denial- 1335 of-service attacks by attackers that try to send forged packets to 1336 the session which would prevent successful reconstruction or cause 1337 inaccurate reconstruction of large portions of the object by 1338 receivers. ALC is also particularly affected by such an attack 1339 because many receivers may receive the same forged packet. There are 1340 two ways to protect against such attacks, one at the application 1341 level and one at the packet level. It is RECOMMENDED that prevention 1342 be provided at both levels. 1344 At the application level, it is RECOMMENDED that an integrity check 1345 on the entire received object be done once the object is 1346 reconstructed to ensure it is the same as the sent object. Moreover, 1347 in order to obtain strong cryptographic integrity protection a 1348 digital signature verifiable by the receiver SHOULD be used to 1349 provide this application level integrity check. However, if even one 1350 corrupted or forged packet is used to reconstruct the object, it is 1351 likely that the received object will be reconstructed incorrectly. 1352 This will appropriately cause the integrity check to fail and in this 1353 case the inaccurately reconstructed object SHOULD be discarded. 1354 Thus, the acceptance of a single forged packet can be an effective 1355 denial of service attack for distributing objects, but an object 1356 integrity check at least prevents inadvertent use of inaccurately 1357 reconstructed objects. The specification of an application level 1358 integrity check of the received object is outside the scope of this 1359 document. 1361 At the packet level, it is RECOMMENDED that a packet level 1362 authentication be used to ensure that each received packet is an 1363 authentic and uncorrupted packet containing FEC data for the object 1364 arriving from the specified sender. Packet level authentication has 1365 the advantage that corrupt or forged packets can be discarded 1366 individually and the received authenticated packets can be used to 1367 accurately reconstruct the object. Thus, the effect of a denial of 1368 service attack that injects forged packets is proportional only to 1369 the number of forged packets, and not to the object size. Although 1370 there is currently no IETF standard that specifies how to do 1371 multicast packet level authentication, TESLA [PER2001] is a known 1372 multicast packet authentication scheme that would work. 1374 In addition to providing protection against reconstruction of 1375 inaccurate objects, packet level authentication can also provide some 1376 protection against denial of service attacks on the multiple rate 1377 congestion control. Attackers can try to inject forged packets with 1378 incorrect congestion control information into the multicast stream, 1379 thereby potentially adversely affecting network elements and 1380 receivers downstream of the attack, and much less significantly the 1381 rest of the network and other receivers. Thus, it is also 1382 RECOMMENDED that packet level authentication be used to protect 1383 against such attacks. TESLA [PER2001] can also be used to some 1384 extent to limit the damage caused by such attacks. However, with 1385 TESLA a receiver can only determine if a packet is authentic several 1386 seconds after it is received, and thus an attack against the 1387 congestion control protocol can be effective for several seconds 1388 before the receiver can react to slow down the session reception 1389 rate. 1391 Reverse Path Forwarding checks SHOULD be enabled in all network 1392 routers and switches along the path from the sender to receivers to 1393 limit the possibility of a bad agent injecting forged packets into 1394 the multicast tree data path. 1396 A receiver with an incorrect or corrupted implementation of the 1397 multiple rate congestion control building block may affect health of 1398 the network in the path between the sender and the receiver, and may 1399 also affect the reception rates of other receivers joined to the 1400 session. It is therefore RECOMMENDED that receivers be required to 1401 identify themselves as legitimate before they receive the Session 1402 Description needed to join the session. How receivers identify 1403 themselves as legitimate is outside the scope of this document. 1405 Another vulnerability of ALC is the potential of receivers obtaining 1406 an incorrect Session Description for the session. The consequences 1407 of this could be that legitimate receivers with the wrong Session 1408 Description are unable to correctly receive the session content, or 1409 that receivers inadvertently try to receive at a much higher rate 1410 than they are capable of, thereby disrupting traffic in portions of 1411 the network. To avoid these problems, it is RECOMMENDED that 1412 measures be taken to prevent receivers from accepting incorrect 1413 Session Descriptions, e.g., by using source authentication to ensure 1414 that receivers only accept legitimate Session Descriptions from 1415 authorized senders. How this is done is outside the scope of this 1416 document. 1418 6. IANA Considerations 1420 No information in this specification is directly subject to IANA 1421 registration. However, building blocks components used by ALC may 1422 introduce additional IANA considerations. In particular, the FEC 1423 building block used by ALC does require IANA registration of the FEC 1424 codecs used. 1426 7. Acknowledgments 1428 Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their 1429 detailed comments on this document. 1431 8. Change Log 1433 8.1 RFC3450 to draft-ietf-rmt-pi-alc-revised-00 1435 Update all references to the obsoleted RFC 2068 to RFC 2616 1437 Removed the 'Statement of Intent' from the introduction 1439 The statement of intent was meant to clarify the "Experimental" 1440 status of RFC3450. It does not apply to this draft that is 1441 intended for "Standard Track" submission. 1443 Removed the 'Intellectual Property Issues' Section and replaced with 1444 a standart IPR Statement 1446 9. References 1448 [HOL2001] Holbrook, H., "A Channel Model for Multicast", Ph.D. 1449 Dissertation, Stanford University, Department of Computer 1450 Science, Stanford, CA , August 2001. 1452 [PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, 1453 "Efficient and Secure Source Authentication for 1454 Multicast", Network and Distributed System Security 1455 Symposium, NDSS 2001, pp. 35-46 , February 2001. 1457 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1458 August 1980. 1460 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1461 RFC 1112, August 1989. 1463 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1464 3", BCP 9, RFC 2026, October 1996. 1466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1467 Requirement Levels", BCP 14, RFC 2119, March 1997. 1469 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1470 Protocol", RFC 2327, April 1998. 1472 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1473 Criteria for Evaluating Reliable Multicast Transport and 1474 Application Protocols", RFC 2357, June 1998. 1476 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1477 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1478 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1480 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1481 Announcement Protocol", RFC 2974, October 2000. 1483 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1484 Types", RFC 3023, January 2001. 1486 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1487 Floyd, S., and M. Luby, "Reliable Multicast Transport 1488 Building Blocks for One-to-Many Bulk-Data Transfer", 1489 RFC 3048, January 2001. 1491 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 1492 Reliable Multicast Transport (RMT) Building Blocks and 1493 Protocol Instantiation documents", RFC 3269, April 2002. 1495 [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, 1496 M., and J. Crowcroft, "Layered Coding Transport (LCT) 1497 Building Block", RFC 3451, December 2002. 1499 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1500 M., and J. Crowcroft, "Forward Error Correction (FEC) 1501 Building Block", RFC 3452, December 2002. 1503 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1504 M., and J. Crowcroft, "The Use of Forward Error Correction 1505 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1507 Authors' Addresses 1509 Michael Luby 1510 Digital Fountain 1511 39141 Civic Center Dr. 1512 Suite 300 1513 Fremont, CA 94538 1514 US 1516 Email: luby@digitalfountain.com 1517 Jim Gemmell 1518 Microsoft Research 1519 455 Market St. #1690 1520 San Francisco, CA 94105 1521 US 1523 Email: jgemmell@microsoft.com 1525 Lorenzo Vicisano 1526 Cisco Systems, Inc. 1527 510 McCarthy Blvd. 1528 Milpitas, CA 95035 1529 US 1531 Email: lorenzo@cisco.com 1533 Luigi Rizzo 1534 Univ. di Pisa 1535 Dip. Ing. dell'Informazione, 1536 via Diotisalvi 2 1537 Pisa, PI 56126 1538 Italy 1540 Email: luigi@iet.unipi.it 1542 Jon Crowcroft 1543 University of Cambridge 1544 Computer Laboratory 1545 William Gates Building 1546 J J Thomson Avenue 1547 Cambridge, CB3 0FD 1548 United Kingdom 1550 Email: Jon.Crowcroft@cl.cam.ac.uk 1552 Intellectual Property Statement 1554 The IETF takes no position regarding the validity or scope of any 1555 Intellectual Property Rights or other rights that might be claimed to 1556 pertain to the implementation or use of the technology described in 1557 this document or the extent to which any license under such rights 1558 might or might not be available; nor does it represent that it has 1559 made any independent effort to identify any such rights. Information 1560 on the procedures with respect to rights in RFC documents can be 1561 found in BCP 78 and BCP 79. 1563 Copies of IPR disclosures made to the IETF Secretariat and any 1564 assurances of licenses to be made available, or the result of an 1565 attempt made to obtain a general license or permission for the use of 1566 such proprietary rights by implementers or users of this 1567 specification can be obtained from the IETF on-line IPR repository at 1568 http://www.ietf.org/ipr. 1570 The IETF invites any interested party to bring to its attention any 1571 copyrights, patents or patent applications, or other proprietary 1572 rights that may cover technology that may be required to implement 1573 this standard. Please address the information to the IETF at 1574 ietf-ipr@ietf.org. 1576 Disclaimer of Validity 1578 This document and the information contained herein are provided on an 1579 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1580 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1581 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1582 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1583 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1584 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1586 Copyright Statement 1588 Copyright (C) The Internet Society (2005). This document is subject 1589 to the rights, licenses and restrictions contained in BCP 78, and 1590 except as set forth therein, the authors retain all their rights. 1592 Acknowledgment 1594 Funding for the RFC Editor function is currently provided by the 1595 Internet Society.