idnits 2.17.1 draft-ietf-rmt-bb-lct-revised-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1481. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: All senders and receivers implementing LCT 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 (October 21, 2005) is 6762 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) -- Looks like a reference, but probably isn't: '0' on line 1217 -- Looks like a reference, but probably isn't: '63' on line 1217 -- Looks like a reference, but probably isn't: '128' on line 1217 -- Looks like a reference, but probably isn't: '191' on line 1217 -- Looks like a reference, but probably isn't: '64' on line 1212 -- Looks like a reference, but probably isn't: '127' on line 1212 -- Looks like a reference, but probably isn't: '255' on line 1212 -- Looks like a reference, but probably isn't: '192' on line 1212 == Unused Reference: 'RFC2026' is defined on line 1293, but no explicit reference was found in the text == Unused Reference: 'RIZ1997' is defined on line 1371, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-02 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast Transport (RMT) Luby 3 Working Group Watson 4 Internet-Draft Digital Fountain 5 Expires: April 24, 2006 Gemmell 6 Microsoft Research 7 Vicisano 8 Cisco Systems, Inc. 9 Rizzo 10 Univ. di Pisa 11 Handley 12 University College London 13 Crowcroft 14 University of Cambridge 15 October 21, 2005 17 Layered Coding Transport (LCT) Building Block 18 draft-ietf-rmt-bb-lct-revised-01 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 24, 2006. 45 Copyright Notice 47 Copyright (C) The Internet Society (2005). 49 Abstract 51 Layered Coding Transport (LCT) provides transport level support for 52 reliable content delivery and stream delivery protocols. LCT is 53 specifically designed to support protocols using IP multicast, but 54 also provides support to protocols that use unicast. LCT is 55 compatible with congestion control that provides multiple rate 56 delivery to receivers and is also compatible with coding techniques 57 that provide reliable delivery of content. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Environmental Requirements and Considerations . . . . . . 10 66 4.2. Delivery service models . . . . . . . . . . . . . . . . . 12 67 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 14 68 5. Packet Header Fields . . . . . . . . . . . . . . . . . . . . . 16 69 5.1. LCT header format . . . . . . . . . . . . . . . . . . . . 16 70 5.2. Header-Extension Fields . . . . . . . . . . . . . . . . . 22 71 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 25 72 6.1. Sender Operation . . . . . . . . . . . . . . . . . . . . . 25 73 6.2. Receiver Operation . . . . . . . . . . . . . . . . . . . . 27 74 7. Requirements from Other Building Blocks . . . . . . . . . . . 29 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 77 9.1. Namespace declaration for LCT Header Extension Types . . . 32 78 9.2. LCT Header Extension Type registration . . . . . . . . . . 32 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 80 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 34 81 11.1. RFC3451 to draft-ietf-rmt-bb-lct-revised-00 . . . . . . . 34 82 11.2. draft-ietf-rmt-bb-lct-revised-00 to -01 . . . . . . . . . 34 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 85 12.2. Informative References . . . . . . . . . . . . . . . . . . 35 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 87 Intellectual Property and Copyright Statements . . . . . . . . . . 40 89 1. Introduction 91 Layered Coding Transport provides transport level support for 92 reliable content delivery and stream delivery protocols. Layered 93 Coding Transport is specifically designed to support protocols using 94 IP multicast, but also provides support to protocols that use 95 unicast. Layered Coding Transport is compatible with congestion 96 control that provides multiple rate delivery to receivers and is also 97 compatible with coding techniques that provide reliable delivery of 98 content. 100 This document describes a building block as defined in [RFC3048]. 101 This document is a product of the IETF RMT WG and follows the general 102 guidelines provided in [RFC3269]. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Rationale 110 LCT provides transport level support for massively scalable protocols 111 using the IP multicast network service. The support that LCT 112 provides is common to a variety of very important applications, 113 including reliable content delivery and streaming applications. 115 An LCT session comprises multiple channels originating at a single 116 sender that are used for some period of time to carry packets 117 pertaining to the transmission of one or more objects that can be of 118 interest to receivers. The logic behind defining a session as 119 originating from a single sender is that this is the right 120 granularity to regulate packet traffic via congestion control. One 121 rationale for using multiple channels within the same session is that 122 there are massively scalable congestion control protocols that use 123 multiple channels per session. These congestion control protocols 124 are considered to be layered because a receiver joins and leaves 125 channels in a layered order during its participation in the session. 126 The use of layered channels is also useful for streaming 127 applications. 129 There are coding techniques that provide massively scalable 130 reliability and asynchronous delivery which are compatible with both 131 layered congestion control and with LCT. When all are combined the 132 result is a massively scalable reliable asynchronous content delivery 133 protocol that is network friendly. LCT also provides functionality 134 that can be used for other applications as well, e.g., layered 135 streaming applications. 137 LCT avoids providing functionality that is not massively scalable. 138 For example, LCT does not provide any mechanisms for sending 139 information from receivers to senders, although this does not rule 140 out protocols that both use LCT and do require sending information 141 from receivers to senders. 143 LCT includes general support for congestion control that must be 144 used. It does not, however, specify which congestion control should 145 be used. The rationale for this is that congestion control must be 146 provided by any protocol that is network friendly, and yet the 147 different applications that can use LCT will not have the same 148 requirements for congestion control. For example, a content delivery 149 protocol may strive to use all available bandwidth between receivers 150 and the sender. It must, therefore, drastically back off its rate 151 when there is competing traffic. On the other hand, a streaming 152 delivery protocol may strive to maintain a constant rate instead of 153 trying to use all available bandwidth, and it may not back off its 154 rate as fast when there is competing traffic. 156 Beyond support for congestion control, LCT provides a number of 157 fields and supports functionality commonly required by many 158 protocols. For example, LCT provides a Transmission Session ID that 159 can be used to identify which session each received packet belongs 160 to. This is important because a receiver may be joined to many 161 sessions concurrently, and thus it is very useful to be able to 162 demultiplex packets as they arrive according to which session they 163 belong to. As another example, LCT provides optional support for 164 identifying which object each packet is carrying information about. 165 Therefore, LCT provides many of the commonly used fields and support 166 for functionality required by many protocols. 168 3. Functionality 170 An LCT session consists of a set of logically grouped LCT channels 171 associated with a single sender carrying packets with LCT headers for 172 one or more objects. An LCT channel is defined by the combination of 173 a sender and an address associated with the channel by the sender. A 174 receiver joins a channel to start receiving the data packets sent to 175 the channel by the sender, and a receiver leaves a channel to stop 176 receiving data packets from the channel. 178 LCT is meant to be combined with other building blocks so that the 179 resulting overall protocol is massively scalable. Scalability refers 180 to the behavior of the protocol in relation to the number of 181 receivers and network paths, their heterogeneity, and the ability to 182 accommodate dynamically variable sets of receivers. Scalability 183 limitations can come from memory or processing requirements, or from 184 the amount of feedback control and redundant data packet traffic 185 generated by the protocol. In turn, such limitations may be a 186 consequence of the features that a complete reliable content delivery 187 or stream delivery protocol is expected to provide. 189 The LCT header provides a number of fields that are useful for 190 conveying in-band session information to receivers. One of the 191 required fields is the Transmission Session ID (TSI), which allows 192 the receiver of a session to uniquely identify received packets as 193 part of the session. Another required field is the Congestion 194 Control Information (CCI), which allows the receiver to perform the 195 required congestion control on the packets received within the 196 session. Other LCT fields provide optional but often very useful 197 additional information for the session. For example, the Transport 198 Object Identifier (TOI) identifies which object the packet contains 199 data for. As other examples, the Sender Current Time (SCT) conveys 200 the time when the packet was sent from the sender to the receiver, 201 the Expected Residual Time (ERT) conveys the amount of time the 202 session will be continued for, flags for indicating the close of the 203 session and the close of sending packets for an object, and header 204 extensions for fields that for example can be used for packet 205 authentication. 207 LCT provides support for congestion control. Congestion control MUST 208 be used that conforms to [RFC2357] between receivers and the sender 209 for each LCT session. Congestion control refers to the ability to 210 adapt throughput to the available bandwidth on the path from the 211 sender to a receiver, and to share bandwidth fairly with competing 212 flows such as TCP. Thus, the total flow of packets flowing to each 213 receiver participating in an LCT session MUST NOT compete unfairly 214 with existing flow adaptive protocols such as TCP. 216 A multiple rate or a single rate congestion control protocol can be 217 used with LCT. For multiple rate protocols, a session typically 218 consists of more than one channel and the sender sends packets to the 219 channels in the session at rates that do not depend on the receivers. 220 Each receiver adjusts its reception rate during its participation in 221 the session by joining and leaving channels dynamically depending on 222 the available bandwidth to the sender independent of all other 223 receivers. Thus, for multiple rate protocols, the reception rate of 224 each receiver may vary dynamically independent of the other 225 receivers. 227 For single rate protocols, a session typically consists of one 228 channel and the sender sends packets to the channel at variable rates 229 over time depending on feedback from receivers. Each receiver 230 remains joined to the channel during its participation in the 231 session. Thus, for single rate protocols, the reception rate of each 232 receiver may vary dynamically but in coordination with all receivers. 234 Generally, a multiple rate protocol is preferable to a single rate 235 protocol in a heterogeneous receiver environment, since generally it 236 more easily achieves scalability to many receivers and provides 237 higher throughput to each individual receiver. Some possible 238 multiple rate congestion control protocols are described in 239 [VIC1998], [BYE2000], and [LUB2002]. A possible single rate 240 congestion control protocol is described in [RIZ2000]. 242 Layered coding refers to the ability to produce a coded stream of 243 packets that can be partitioned into an ordered set of layers. The 244 coding is meant to provide some form of reliability, and the layering 245 is meant to allow the receiver experience (in terms of quality of 246 playout, or overall transfer speed) to vary in a predictable way 247 depending on how many consecutive layers of packets the receiver is 248 receiving. 250 The concept of layered coding was first introduced with reference to 251 audio and video streams. For example, the information associated 252 with a TV broadcast could be partitioned into three layers, 253 corresponding to black and white, color, and HDTV quality. Receivers 254 can experience different quality without the need for the sender to 255 replicate information in the different layers. 257 The concept of layered coding can be naturally extended to reliable 258 content delivery protocols when Forward Error Correction (FEC) 259 techniques are used for coding the data stream. Descriptions of this 260 can be found in [RIZ1997a], [RIZ1997b], [GEM2000], [VIC1998] and 261 [BYE1998]. By using FEC, the data stream is transformed in such a 262 way that reconstruction of a data object does not depend on the 263 reception of specific data packets, but only on the number of 264 different packets received. As a result, by increasing the number of 265 layers a receiver is receiving from, the receiver can reduce the 266 transfer time accordingly. Using FEC to provide reliability can 267 increase scalability dramatically in comparison to other methods for 268 providing reliability. More details on the use of FEC for reliable 269 content delivery can be found in [RFC3453]. 271 Reliable protocols aim at giving guarantees on the reliable delivery 272 of data from the sender to the intended recipients. Guarantees vary 273 from simple packet data integrity to reliable delivery of a precise 274 copy of an object to all intended recipients. Several reliable 275 content delivery protocols have been built on top of IP multicast 276 using methods other than FEC, but scalability was not the primary 277 design goal for many of them. 279 Two of the key difficulties in scaling reliable content delivery 280 using IP multicast are dealing with the amount of data that flows 281 from receivers back to the sender, and the associated response 282 (generally data retransmissions) from the sender. Protocols that 283 avoid any such feedback, and minimize the amount of retransmissions, 284 can be massively scalable. LCT can be used in conjunction with FEC 285 codes or a layered codec to achieve reliability with little or no 286 feedback. 288 Protocol instantiations MAY be built by combining the LCT framework 289 with other components. A complete protocol instantiation that uses 290 LCT MUST include a congestion control protocol that is compatible 291 with LCT and that conforms to [RFC2357]. A complete protocol 292 instantiation that uses LCT MAY include a scalable reliability 293 protocol that is compatible with LCT, it MAY include an session 294 control protocol that is compatible with LCT, and it MAY include 295 other protocols such as security protocols. 297 4. Applicability 299 An LCT session comprises a logically related set of one or more LCT 300 channels originating at a single sender. The channels are used for 301 some period of time to carry packets containing LCT headers, and 302 these headers pertain to the transmission of one or more objects that 303 can be of interest to receivers. 305 LCT is most applicable for delivery of objects or streams in a 306 session of substantial length, i.e., objects or streams that range in 307 aggregate length from hundreds of kilobytes to many gigabytes, and 308 where the duration of the session is on the order of tens of seconds 309 or more. 311 As an example, an LCT session could be used to deliver a TV program 312 using three LCT channels. Receiving packets from the first LCT 313 channel could allow black and white reception. Receiving the first 314 two LCT channels could also permit color reception. Receiving all 315 three channels could allow HDTV quality reception. Objects in this 316 example could correspond to individual TV programs being transmitted. 318 As another example, a reliable LCT session could be used to reliably 319 deliver hourly-updated weather maps (objects) using ten LCT channels 320 at different rates, using FEC coding. A receiver may join and 321 concurrently receive packets from subsets of these channels, until it 322 has enough packets in total to recover the object, then leave the 323 session (or remain connected listening for session description 324 information only) until it is time to receive the next object. In 325 this case, the quality metric is the time required to receive each 326 object. 328 Before joining a session, the receivers MUST obtain enough of the 329 session description to start the session. This MUST include the 330 relevant session parameters needed by a receiver to participate in 331 the session, including all information relevant to congestion 332 control. The session description is determined by the sender, and is 333 typically communicated to the receivers out-of-band. In some cases, 334 as described later, parts of the session description that are not 335 required to initiate a session MAY be included in the LCT header or 336 communicated to a receiver out-of-band after the receiver has joined 337 the session. 339 An encoder MAY be used to generate the data that is placed in the 340 packet payload in order to provide reliability. A suitable decoder 341 is used to reproduce the original information from the packet 342 payload. There MAY be a reliability header that follows the LCT 343 header if such an encoder and decoder is used. The reliability 344 header helps to describe the encoding data carried in the payload of 345 the packet. The format of the reliability header depends on the 346 coding used, and this is negotiated out-of-band. As an example, one 347 of the FEC headers described in [I-D.ietf-rmt-fec-bb-revised] could 348 be used. 350 For LCT, when multiple rate congestion control is used, congestion 351 control is achieved by sending packets associated with a given 352 session to several LCT channels. Individual receivers dynamically 353 join one or more of these channels, according to the network 354 congestion as seen by the receiver. LCT headers include an opaque 355 field which MUST be used to convey congestion control information to 356 the receivers. The actual congestion control scheme to use with LCT 357 is negotiated out-of-band. Some examples of congestion control 358 protocols that may be suitable for content delivery are described in 359 [VIC1998], [BYE2000], and [LUB2002]. Other congestion controls may 360 be suitable when LCT is used for a streaming application. 362 This document does not specify and restrict the type of exchanges 363 between LCT (or any PI built on top of LCT) and an upper application. 364 Some upper APIs may use an object-oriented approach, where the only 365 possible unit of data exchanged between LCT (or any PI built on top 366 of LCT) and an application, either at a source or at a receiver, is 367 an object. Other APIs may enable a sending or receiving application 368 to exchange a subset of an object with LCT (or any PI built on top of 369 LCT), or may even follow a streaming model. These considerations are 370 outside the scope of this document. 372 4.1. Environmental Requirements and Considerations 374 LCT is intended for congestion controlled delivery of objects and 375 streams (both reliable content delivery and streaming of multimedia 376 information). 378 LCT can be used with both multicast and unicast delivery. LCT 379 requires connectivity between a sender and receivers but does not 380 require connectivity from receivers to a sender. LCT inherently 381 works with all types of networks, including LANs, WANs, Intranets, 382 the Internet, asymmetric networks, wireless networks, and satellite 383 networks. Thus, the inherent raw scalability of LCT is unlimited. 384 However, when other specific applications are built on top of LCT, 385 then these applications by their very nature may limit scalability. 386 For example, if an application requires receivers to retrieve out of 387 band information in order to join a session, or an application allows 388 receivers to send requests back to the sender to report reception 389 statistics, then the scalability of the application is limited by the 390 ability to send, receive, and process this additional data. 392 LCT requires receivers to be able to uniquely identify and 393 demultiplex packets associated with an LCT session. In particular, 394 there MUST be a Transport Session Identifier (TSI) associated with 395 each LCT session. The TSI is scoped by the IP address of the sender, 396 and the IP address of the sender together with the TSI MUST uniquely 397 identify the session. If the underlying transport is UDP as 398 described in [RFC0768], then the 16 bit UDP source port number MAY 399 serve as the TSI for the session. The TSI value MUST be the same in 400 all places it occurs within a packet. If there is no underlying TSI 401 provided by the network, transport or any other layer, then the TSI 402 MUST be included in the LCT header. 404 LCT is presumed to be used with an underlying network or transport 405 service that is a "best effort" service that does not guarantee 406 packet reception or packet reception order, and which does not have 407 any support for flow or congestion control. For example, the Any- 408 Source Multicast (ASM) model of IP multicast as defined in [RFC1112] 409 is such a "best effort" network service. While the basic service 410 provided by [RFC1112] is largely scalable, providing congestion 411 control or reliability should be done carefully to avoid severe 412 scalability limitations, especially in presence of heterogeneous sets 413 of receivers. 415 There are currently two models of multicast delivery, the Any-Source 416 Multicast (ASM) model as defined in [RFC1112] and the Source- 417 Specific Multicast (SSM) model as defined in [HOL2001]. LCT works 418 with both multicast models, but in a slightly different way with 419 somewhat different environmental concerns. When using ASM, a sender 420 S sends packets to a multicast group G, and the LCT channel address 421 consists of the pair (S,G), where S is the IP address of the sender 422 and G is a multicast group address. When using SSM, a sender S sends 423 packets to an SSM channel (S,G), and the LCT channel address 424 coincides with the SSM channel address. 426 A sender can locally allocate unique SSM channel addresses, and this 427 makes allocation of LCT channel addresses easy with SSM. To allocate 428 LCT channel addresses using ASM, the sender must uniquely chose the 429 ASM multicast group address across the scope of the group, and this 430 makes allocation of LCT channel addresses more difficult with ASM. 432 LCT channels and SSM channels coincide, and thus the receiver will 433 only receive packets sent to the requested LCT channel. With ASM, 434 the receiver joins an LCT channel by joining a multicast group G, and 435 all packets sent to G, regardless of the sender, may be received by 436 the receiver. Thus, SSM has compelling security advantages over ASM 437 for prevention of denial of service attacks. In either case, 438 receivers SHOULD use mechanisms to filter out packets from unwanted 439 sources. 441 Some networks are not amenable to some congestion control protocols 442 that could be used with LCT. In particular, for a satellite or 443 wireless network, there may be no mechanism for receivers to 444 effectively reduce their reception rate since there may be a fixed 445 transmission rate allocated to the session. 447 LCT is compatible with either IPv4 or IPv6 as no part of the packet 448 is IP version specific. 450 4.2. Delivery service models 452 LCT can support several different delivery service models. Two 453 examples are briefly described here. 455 Push service model 457 One way a push service model can be used for reliable content 458 delivery is to deliver a series of objects. For example, a 459 receiver could join the session and dynamically adapt the number 460 of LCT channels the receiver is joined to until enough packets 461 have been received to reconstruct an object. After reconstructing 462 the object the receiver may stay in the session and wait for the 463 transmission of the next object. 465 The push model is particularly attractive in satellite networks 466 and wireless networks. In these cases, a session may consist of 467 one fixed rate LCT channel. 469 A push service model can be used for example for reliable delivery 470 of a large object such as a 100 GB file. The sender could send a 471 Session Description announcement to a control channel and 472 receivers could monitor this channel and join a session whenever a 473 Session Description of interest arrives. Upon receipt of the 474 Session Description, each receiver could join the session to 475 receive packets until enough packets have arrived to reconstruct 476 the object, at which point the receiver could report back to the 477 sender that its reception was completed successfully. The sender 478 could decide to continue sending packets for the object to the 479 session until all receivers have reported successful 480 reconstruction or until some other condition has been satisfied. 482 There are several features ALC provides to support the push model. 483 For example, the sender can optionally include an Expected 484 Residual Time (ERT) in the packet header that indicates the 485 expected remaining time of packet transmission for either the 486 single object carried in the session or for the object identified 487 by the Transmission Object Identifier (TOI) if there are multiple 488 objects carried in the session. This can be used by receivers to 489 determine if there is enough time remaining in the session to 490 successfully receive enough additional packets to recover the 491 object. If for example there is not enough time, then the push 492 application may have receivers report back to the sender to extend 493 the transmission of packets for the object for enough time to 494 allow the receivers to obtain enough packets to reconstruct the 495 object. The sender could then include an ERT based on the 496 extended object transmission time in each subsequent packet header 497 for the object. As other examples, the LCT header optionally can 498 contain a Close Session flag that indicates when the sender is 499 about to end sending packet to the session and a Close Object flag 500 that indicates when the sender is about to end sending packets to 501 the session for the object identified by the Transmission Object 502 ID. However, these flags are not a completely reliable mechanism 503 and thus the Close Session flag should only be used as a hint of 504 when the session is about to close and the Close Object flag 505 should only be used as a hint of when transmission of packets for 506 the object is about to end. 508 On-demand content delivery model 510 For an on-demand content delivery service model, senders typically 511 transmit for some given time period selected to be long enough to 512 allow all the intended receivers to join the session and recover 513 the object. For example a popular software update might be 514 transmitted using LCT for several days, even though a receiver may 515 be able to complete the download in one hour total of connection 516 time, perhaps spread over several intervals of time. In this case 517 the receivers join the session at any point in time when it is 518 active. Receivers leave the session when they have received 519 enough packets to recover the object. The receivers, for example, 520 obtain a Session Description by contacting a web server. 522 In this case the receivers join the session, and dynamically adapt 523 the number of LCT channels they subscribe to according to the 524 available bandwidth. Receivers then drop from the session when 525 they have received enough packets to recover the object. 527 As an example, assume that an object is 50 MB. The sender could 528 send 1 KB packets to the first LCT channel at 50 packets per 529 second, so that receivers using just this LCT channel could 530 complete reception of the object in 1,000 seconds in absence of 531 loss, and would be able to complete reception even in presence of 532 some substantial amount of losses with the use of coding for 533 reliability. Furthermore, the sender could use a number of LCT 534 channels such that the aggregate rate of 1 KB packets to all LCT 535 channels is 1,000 packets per second, so that a receiver could be 536 able to complete reception of the object in as little 50 seconds 537 (assuming no loss and that the congestion control mechanism 538 immediately converges to the use of all LCT channels). 540 Other service models 542 There are many other delivery service models that LCT can be used 543 for that are not covered above. As examples, a live streaming or 544 an on- demand archival content streaming service model. A 545 description of the many potential applications, the appropriate 546 delivery service model, and the additional mechanisms to support 547 such functionalities when combined with LCT is beyond the scope of 548 this document. This document only attempts to describe the 549 minimal common scalable elements to these diverse applications 550 using LCT as the delivery transport. 552 4.3. Congestion Control 554 The specific congestion control protocol to be used for LCT sessions 555 depends on the type of content to be delivered. While the general 556 behavior of the congestion control protocol is to reduce the 557 throughput in presence of congestion and gradually increase it in the 558 absence of congestion, the actual dynamic behavior (e.g. response to 559 single losses) can vary. 561 Some possible congestion control protocols for reliable content 562 delivery using LCT are described in [VIC1998], [BYE2000], and 564 [LUB2002]. Different delivery service models might require different 565 congestion control protocols. 567 5. Packet Header Fields 569 Packets sent to an LCT session MUST include an "LCT header". The LCT 570 header format is described below. 572 Other building blocks MAY describe some of the same fields as 573 described for the LCT header. It is RECOMMENDED that protocol 574 instantiations using multiple building blocks include shared fields 575 at most once in each packet. Thus, for example, if another building 576 block is used with LCT that includes the optional Expected Residual 577 Time field, then the Expected Residual Time field SHOULD be carried 578 in each packet at most once. 580 The position of the LCT header within a packet MUST be specified by 581 any protocol instantiation that uses LCT. 583 5.1. LCT header format 585 The LCT header is of variable size, which is specified by a length 586 field in the third byte of the header. In the LCT header, all 587 integer fields are carried in "big-endian" or "network order" format, 588 that is, most significant byte (octet) first. Bits designated as 589 "padding" or "reserved" (r) MUST by set to 0 by senders and ignored 590 by receivers. Unless otherwise noted, numeric constants in this 591 specification are in decimal (base 10). 593 The format of the default LCT header is depicted in Figure 1. 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | V | C |PSI|S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)| 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Congestion Control Information (CCI, length = 32*(C+1) bits) | 601 | ... | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Transport Session Identifier (TSI, length = 32*S+16*H bits) | 604 | ... | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Transport Object Identifier (TOI, length = 32*O+16*H bits) | 607 | ... | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Sender Current Time (SCT, if T = 1) | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Expected Residual Time (ERT, if R = 1) | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Header Extensions (if applicable) | 614 | ... | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Figure 1: Default LCT header format 619 The function and length of each field in the default LCT header is 620 the following. Fields marked as "1" mean that the corresponding bits 621 MUST be set to "1" by the sender. Fields marked as "r" or "0" mean 622 that the corresponding bits MUST be set to "0" by the sender. 624 LCT version number (V): 4 bits 626 Indicates the LCT version number. The LCT version number for this 627 specification is 1. 629 Congestion control flag (C): 2 bits 631 C=0 indicates the Congestion Control Information (CCI) field is 632 32-bits in length. C=1 indicates the CCI field is 64-bits in 633 length. C=2 indicates the CCI field is 96-bits in length. C=3 634 indicates the CCI field is 128-bits in length. 636 Protocol Specific Indication (PSI): 2 bits 638 The usage of these bits, if any, is specific to each Protocol 639 Instantiation that uses the LCT Building Block. If no Protocol 640 Instantiation-specific usage of these bits is defined, then a 641 sender MUST set them to zero and a receiver MUST ignore these 642 bits. 644 Transport Session Identifier flag (S): 1 bit 646 This is the number of full 32-bit words in the TSI field. The TSI 647 field is 32*S + 16*H bits in length, i.e. the length is either 0 648 bits, 16 bits, 32 bits, or 48 bits. 650 Transport Object Identifier flag (O): 2 bits 652 This is the number of full 32-bit words in the TOI field. The TOI 653 field is 32*O + 16*H bits in length, i.e., the length is either 0 654 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 655 bits. 657 Half-word flag (H): 1 bit 659 The TSI and the TOI fields are both multiples of 32-bits plus 16*H 660 bits in length. This allows the TSI and TOI field lengths to be 661 multiples of a half-word (16 bits), while ensuring that the 662 aggregate length of the TSI and TOI fields is a multiple of 32- 663 bits. 665 Sender Current Time present flag (T): 1 bit 667 T = 0 indicates that the Sender Current Time (SCT) field is not 668 present. T = 1 indicates that the SCT field is present. The SCT 669 is inserted by senders to indicate to receivers how long the 670 session has been in progress. 672 Expected Residual Time present flag (R): 1 bit 674 R = 0 indicates that the Expected Residual Time (ERT) field is not 675 present. R = 1 indicates that the ERT field is present. The ERT 676 is inserted by senders to indicate to receivers how much longer 677 the session / object transmission will continue. 679 Senders MUST NOT set R = 1 when the ERT for the session is more 680 than 2^32-1 time units (approximately 49 days), where time is 681 measured in units of milliseconds. 683 Close Session flag (A): 1 bit 685 Normally, A is set to 0. The sender MAY set A to 1 when 686 termination of transmission of packets for the session is 687 imminent. A MAY be set to 1 in just the last packet transmitted 688 for the session, or A MAY be set to 1 in the last few seconds of 689 packets transmitted for the session. Once the sender sets A to 1 690 in one packet, the sender SHOULD set A to 1 in all subsequent 691 packets until termination of transmission of packets for the 692 session. A received packet with A set to 1 indicates to a 693 receiver that the sender will immediately stop sending packets for 694 the session. When a receiver receives a packet with A set to 1 695 the receiver SHOULD assume that no more packets will be sent to 696 the session. 698 Close Object flag (B): 1 bit 700 Normally, B is set to 0. The sender MAY set B to 1 when 701 termination of transmission of packets for an object is imminent. 702 If the TOI field is in use and B is set to 1 then termination of 703 transmission for the object identified by the TOI field is 704 imminent. If the TOI field is not in use and B is set to 1 then 705 termination of transmission for the one object in the session 706 identified by out-of-band information is imminent. B MAY be set 707 to 1 in just the last packet transmitted for the object, or B MAY 708 be set to 1 in the last few seconds packets transmitted for the 709 object. Once the sender sets B to 1 in one packet for a 710 particular object, the sender SHOULD set B to 1 in all subsequent 711 packets for the object until termination of transmission of 712 packets for the object. A received packet with B set to 1 713 indicates to a receiver that the sender will immediately stop 714 sending packets for the object. When a receiver receives a packet 715 with B set to 1 then it SHOULD assume that no more packets will be 716 sent for the object to the session. 718 LCT header length (HDR_LEN): 8 bits 720 Total length of the LCT header in units of 32-bit words. The 721 length of the LCT header MUST be a multiple of 32-bits. This 722 field can be used to directly access the portion of the packet 723 beyond the LCT header, i.e., to the first other header if it 724 exists, or to the packet payload if it exists and there is no 725 other header, or to the end of the packet if there are no other 726 headers or packet payload. 728 Codepoint (CP): 8 bits 730 An opaque identifier which is passed to the packet payload decoder 731 to convey information on the codec being used for the packet 732 payload. The mapping between the codepoint and the actual codec 733 is defined on a per session basis and communicated out-of-band as 734 part of the session description information. The use of the CP 735 field is similar to the Payload Type (PT) field in RTP headers as 736 described in [RFC1889]. 738 Congestion Control Information (CCI): 32, 64, 96 or 128 bits 740 Used to carry congestion control information. For example, the 741 congestion control information could include layer numbers, 742 logical channel numbers, and sequence numbers. This field is 743 opaque for the purpose of this specification. 745 This field MUST be 32 bits if C=0. 747 This field MUST be 64 bits if C=1. 749 This field MUST be 96 bits if C=2. 751 This field MUST be 128 bits if C=3. 753 Transport Session Identifier (TSI): 0, 16, 32 or 48 bits 755 The TSI uniquely identifies a session among all sessions from a 756 particular sender. The TSI is scoped by the IP address of the 757 sender, and thus the IP address of the sender and the TSI together 758 uniquely identify the session. Although a TSI in conjunction with 759 the IP address of the sender always uniquely identifies a session, 760 whether or not the TSI is included in the LCT header depends on 761 what is used as the TSI value. If the underlying transport is 762 UDP, then the 16 bit UDP source port number MAY serve as the TSI 763 for the session. If the TSI value appears multiple times in a 764 packet then all occurrences MUST be the same value. If there is 765 no underlying TSI provided by the network, transport or any other 766 layer, then the TSI MUST be included in the LCT header. 768 The TSI MUST be unique among all sessions served by the sender 769 during the period when the session is active, and for a large 770 period of time preceding and following when the session is active. 771 A primary purpose of the TSI is to prevent receivers from 772 inadvertently accepting packets from a sender that belong to 773 sessions other than the sessions receivers are subscribed to. For 774 example, suppose a session is deactivated and then another session 775 is activated by a sender and the two sessions use an overlapping 776 set of channels. A receiver that connects and remains connected 777 to the first session during this sender activity could possibly 778 accept packets from the second session as belonging to the first 779 session if the TSI for the two sessions were identical. The 780 mapping of TSI field values to sessions is outside the scope of 781 this document and is to be done out-of-band. 783 The length of the TSI field is 32*S + 16*H bits. Note that the 784 aggregate lengths of the TSI field plus the TOI field is a 785 multiple of 32 bits. 787 Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 788 bits. 790 This field indicates which object within the session this packet 791 pertains to. For example, a sender might send a number of files 792 in the same session, using TOI=0 for the first file, TOI=1 for the 793 second one, etc. As another example, the TOI may be a unique 794 global identifier of the object that is being transmitted from 795 several senders concurrently, and the TOI value may be the output 796 of a hash function applied to the object. The mapping of TOI 797 field values to objects is outside the scope of this document and 798 is to be done out-of-band. The TOI field MUST be used in all 799 packets if more than one object is to be transmitted in a session, 800 i.e. the TOI field is either present in all the packets of a 801 session or is never present. 803 The length of the TOI field is 32*O + 16*H bits. Note that the 804 aggregate lengths of the TSI field plus the TOI field is a 805 multiple of 32 bits. 807 Sender Current Time (SCT): 0 or 32 bits 809 This field represents the current clock at the sender and at the 810 time this packet was transmitted, measured in units of 1ms and 811 computed modulo 2^32 units from the start of the session. 813 OR 815 This field represents the current clock at the sender expressed as 816 the 32 most significant bits of a 64 bit Network Time Protocol 817 (NTP) [RFC1305] time value. These 32 bits provide an unsigned 818 integer representing the time in seconds relative to 0 hours 1 819 January 1900. Handling of wraparound of the 32 bit time is 820 outside the scope of NTP and LCT. 822 This field MUST NOT be present if T=0 and MUST be present if T=1. 824 Expected Residual Time (ERT): 0 or 32 bits 826 This field represents the sender expected residual transmission 827 time for the current session or for the transmission of the 828 current object, measured in units of 1ms. If the packet 829 containing the ERT field also contains the TOI field, then ERT 830 refers to the object corresponding to the TOI field, otherwise it 831 refers to the session. 833 This field MUST NOT be present if R=0 and MUST be present if R=1. 835 5.2. Header-Extension Fields 837 Header Extensions are used in LCT to accommodate optional header 838 fields that are not always used or have variable size. Examples of 839 the use of Header Extensions include: 841 o Extended-size versions of already existing header fields. 843 o Sender and Receiver authentication information. 845 The presence of Header Extensions can be inferred by the LCT header 846 length (HDR_LEN): if HDR_LEN is larger than the length of the 847 standard header then the remaining header space is taken by Header 848 Extension fields. 850 If present, Header Extensions MUST be processed to ensure that they 851 are recognized before performing any congestion control procedure or 852 otherwise accepting a packet. The default action for unrecognized 853 header extensions is to ignore them. This allows the future 854 introduction of backward-compatible enhancements to LCT without 855 changing the LCT version number. Non backward-compatible header 856 extensions CANNOT be introduced without changing the LCT version 857 number. 859 There are two formats for Header Extension fields, as depicted in 860 Figure 2. The first format is used for variable-length extensions, 861 with Header Extension Type (HET) values between 0 and 127. The 862 second format is used for fixed length (one 32-bit word) extensions, 863 using HET values from 127 to 255. 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | HET (<=127) | HEL | | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 870 . . 871 . Header Extension Content (HEC) . 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | HET (>=128) | Header Extension Content (HEC) | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 Figure 2: Format of additional headers 882 The explanation of each sub-field is the following: 884 Header Extension Type (HET): 8 bits 886 The type of the Header Extension. This document defines a number 887 of possible types. Additional types may be defined in future 888 versions of this specification. HET values from 0 to 127 are used 889 for variable-length Header Extensions. HET values from 128 to 255 890 are used for fixed-length 32-bit Header Extensions. 892 Header Extension Length (HEL): 8 bits 894 The length of the whole Header Extension field, expressed in 895 multiples of 32-bit words. This field MUST be present for 896 variable-length extensions (HET between 0 and 127) and MUST NOT be 897 present for fixed-length extensions (HET between 128 and 255). 899 Header Extension Content (HEC): variable length 901 The content of the Header Extension. The format of this sub- 902 field depends on the Header Extension type. For fixed-length 903 Header Extensions, the HEC is 24 bits. For variable-length Header 904 Extensions, the HEC field has variable size, as specified by the 905 HEL field. Note that the length of each Header Extension field 906 MUST be a multiple of 32 bits. Also note that the total size of 907 the LCT header, including all Header Extensions and all optional 908 header fields, cannot exceed 255 32-bit words. 910 LCT Header Extensions with general applicability to any protocol 911 which makes use of LCT SHOULD be defined in the ranges [0,63] or 913 [128,191] inclusive. LCT Header Extensions with narrower 914 applicability (for example to a singe Protocol Instantiation) SHOULD 915 be defined in the ranges [64,127] or [191,255] inclusive. 917 The following LCT Header Extensions are defined by this 918 specification: 920 EXT_NOP, HET=0 No-Operation extension. The information present in 921 this extension field MUST be ignored by receivers. 923 EXT_AUTH, HET=1 Packet authentication extension Information used to 924 authenticate the sender of the packet. The format of 925 this Header Extension and its processing is outside the 926 scope of this document and is to be communicated out- 927 of-band as part of the session description. 929 It is RECOMMENDED that senders provide some form of 930 packet authentication. If EXT_AUTH is present, 931 whatever packet authentication checks that can be 932 performed immediately upon reception of the packet 933 SHOULD be performed before accepting the packet and 934 performing any congestion control-related action on it. 936 Some packet authentication schemes impose a delay of 937 several seconds between when a packet is received and 938 when the packet is fully authenticated. Any congestion 939 control related action that is appropriate MUST NOT be 940 postponed by any such full packet authentication. 942 All senders and receivers implementing LCT MUST support the EXT_NOP 943 Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to 944 parse its content. 946 6. Operations 948 6.1. Sender Operation 950 Before joining an LCT session a receiver MUST obtain a session 951 description. The session description MUST include: 953 o The sender IP address; 955 o The number of LCT channels; 957 o The addresses and port numbers used for each LCT channel; 959 o The Transport Session ID (TSI) to be used for the session; 961 o Enough information to determine the congestion control protocol 962 being used; 964 o Enough information to determine the packet authentication scheme 965 being used if it is being used. 967 The session description could also include, but is not limited to: 969 o The data rates used for each LCT channel; 971 o The length of the packet payload; 973 o The mapping of TOI value(s) to objects for the session; 975 o Any information that is relevant to each object being transported, 976 such as when it will be available within the session, for how 977 long, and the length of the object; 979 Protocol instantiations using LCT MAY place additional requirements 980 on what must be included in the session description. For example, a 981 protocol instantiation might require that the data rates for each 982 channel, or the mapping of TOI value(s) to objects for the session, 983 or other information related to other headers that might be required 984 to be included in the session description. 986 The session description could be in a form such as SDP as defined in 987 [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime 988 headers as defined in [RFC2616], etc. It might be carried in a 989 session announcement protocol such as SAP as defined in [RFC2974], 990 obtained using a proprietary session control protocol, located on a 991 Web page with scheduling information, or conveyed via E-mail or other 992 out-of-band methods. Discussion of session description format, and 993 distribution of session descriptions is beyond the scope of this 994 document. 996 Within an LCT session, a sender using LCT transmits a sequence of 997 packets, each in the format defined above. Packets are sent from a 998 sender using one or more LCT channels which together constitute a 999 session. Transmission rates may be different in different channels 1000 and may vary over time. The specification of the other building 1001 block headers and the packet payload used by a complete protocol 1002 instantiation using LCT is beyond the scope of this document. This 1003 document does not specify the order in which packets are transmitted, 1004 nor the organization of a session into multiple channels. Although 1005 these issues affect the efficiency of the protocol, they do not 1006 affect the correctness nor the inter-operability of LCT between 1007 senders and receivers. 1009 Several objects can be carried within the same LCT session. In this 1010 case, each object MUST be identified by a unique TOI. Objects MAY be 1011 transmitted sequentially, or they MAY be transmitted concurrently. 1012 It is good practice to only send objects concurrently in the same 1013 session if the receivers that participate in that portion of the 1014 session have interest in receiving all the objects. The reason for 1015 this is that it wastes bandwidth and networking resources to have 1016 receivers receive data for objects that they have no interest in. 1018 Typically, the sender(s) continues to send packets in a session until 1019 the transmission is considered complete. The transmission may be 1020 considered complete when some time has expired, a certain number of 1021 packets have been sent, or some out-of-band signal (possibly from a 1022 higher level protocol) has indicated completion by a sufficient 1023 number of receivers. 1025 For the reasons mentioned above, this document does not pose any 1026 restriction on packet sizes. However, network efficiency 1027 considerations recommend that the sender uses an as large as possible 1028 packet payload size, but in such a way that packets do not exceed the 1029 network's maximum transmission unit size (MTU), or when fragmentation 1030 coupled with packet loss might introduce severe inefficiency in the 1031 transmission. 1033 It is recommended that all packets have the same or very similar 1034 sizes, as this can have a severe impact on the effectiveness of 1035 congestion control schemes such as the ones described in [VIC1998], 1036 [BYE2000], and [LUB2002]. A sender of packets using LCT MUST 1037 implement the sender- side part of one of the congestion control 1038 schemes that is in accordance with [RFC2357] using the Congestion 1039 Control Information field provided in the LCT header, and the 1040 corresponding receiver congestion control scheme is to be 1041 communicated out-of-band and MUST be implemented by any receivers 1042 participating in the session. 1044 6.2. Receiver Operation 1046 Receivers can operate differently depending on the delivery service 1047 model. For example, for an on demand service model, receivers may 1048 join a session, obtain the necessary packets to reproduce the object, 1049 and then leave the session. As another example, for a streaming 1050 service model, a receiver may be continuously joined to a set of LCT 1051 channels to download all objects in a session. 1053 To be able to participate in a session, a receiver MUST obtain the 1054 relevant session description information as listed in Section 6.1. 1056 If packet authentication information is present in an LCT header, it 1057 SHOULD be used as specified in Section 5.2. To be able to be a 1058 receiver in a session, the receiver MUST be able to process the LCT 1059 header. The receiver MUST be able to discard, forward, store or 1060 process the other headers and the packet payload. If a receiver is 1061 not able to process a LCT header, it MUST drop from the session. 1063 To be able to participate in a session, a receiver MUST implement the 1064 congestion control protocol specified in the session description 1065 using the Congestion Control Information field provided in the LCT 1066 header. If a receiver is not able to implement the congestion 1067 control protocol used in the session, it MUST NOT join the session. 1068 When the session is transmitted on multiple LCT channels, receivers 1069 MUST initially join channels according to the specified startup 1070 behavior of the congestion control protocol. For a multiple rate 1071 congestion control protocol that uses multiple channels, this 1072 typically means that a receiver will initially join only a minimal 1073 set of LCT channels, possibly a single one, that in aggregate are 1074 carrying packets at a low rate. This rule has the purpose of 1075 preventing receivers from starting at high data rates. 1077 Several objects can be carried either sequentially or concurrently 1078 within the same LCT session. In this case, each object is identified 1079 by a unique TOI. Note that even if a server stops sending packets 1080 for an old object before starting to transmit packets for a new 1081 object, both the network and the underlying protocol layers can cause 1082 some reordering of packets, especially when sent over different LCT 1083 channels, and thus receivers SHOULD NOT assume that the reception of 1084 a packet for a new object means that there are no more packets in 1085 transit for the previous one, at least for some amount of time. 1087 A receiver MAY be concurrently joined to multiple LCT sessions from 1088 one or more senders. The receiver MUST perform congestion control on 1089 each such LCT session. If the congestion control protocol allows the 1090 receiver some flexibility in terms of its actions within a session 1091 then the receiver MAY make choices to optimize the packet flow 1092 performance across the multiple LCT sessions, as long as the receiver 1093 still adheres to the congestion control rules for each LCT session 1094 individually. 1096 7. Requirements from Other Building Blocks 1098 As described in [RFC3048], LCT is a building block that is intended 1099 to be used, in conjunction with other building blocks, to help 1100 specify a protocol instantiation. A congestion control building 1101 block that uses the Congestion Control information field within the 1102 LCT header MUST be used by any protocol instantiation that uses LCT, 1103 and other building blocks MAY also be used, such as a reliability 1104 building block. 1106 The congestion control MUST be applied to the LCT session as an 1107 entity, i.e., over the aggregate of the traffic carried by all of the 1108 LCT channels associated with the LCT session. The Congestion Control 1109 Information field in the LCT header is an opaque field that is 1110 reserved to carry information related to congestion control. There 1111 MAY also be congestion control Header Extension fields that carry 1112 additional information related to congestion control. 1114 The particular layered encoder and congestion control protocols used 1115 with LCT have an impact on the performance and applicability of LCT. 1116 For example, some layered encoders used for video and audio streams 1117 can produce a very limited number of layers, thus providing a very 1118 coarse control in the reception rate of packets by receivers in a 1119 session. When LCT is used for reliable data transfer, some FEC 1120 codecs are inherently limited in the size of the object they can 1121 encode, and for objects larger than this size the reception overhead 1122 on the receivers can grow substantially. 1124 A more in-depth description of the use of FEC in Reliable Multicast 1125 Transport (RMT) protocols is given in [RFC3453]. Some of the FEC 1126 codecs that MAY be used in conjunction with LCT for reliable content 1127 delivery are specified in [I-D.ietf-rmt-fec-bb-revised]. The 1128 Codepoint field in the LCT header is an opaque field that can be used 1129 to carry information related to the encoding of the packet payload. 1131 LCT also requires receivers to obtain a session description, as 1132 described in Section 6.1 The session description could be in a form 1133 such as SDP as defined in [RFC2327], or XML metadata as defined in 1134 [RFC3023], or HTTP/Mime headers as defined in [RFC2616], and 1135 distributed with SAP as defined in [RFC2974], using HTTP, or in other 1136 ways. It is RECOMMENDED that an authentication protocol be used to 1137 deliver the session description to receivers to ensure the correct 1138 session description arrives. 1140 It is RECOMMENDED that LCT implementors use some packet 1141 authentication scheme to protect the protocol from attacks. An 1142 example of a possibly suitable scheme is described in [RIZ1997a]. 1144 Some protocol instantiations that use LCT MAY use building blocks 1145 that require the generation of feedback from the receivers to the 1146 sender. However, the mechanism for doing this is outside the scope 1147 of LCT. 1149 8. Security Considerations 1151 LCT can be subject to denial-of-service attacks by attackers which 1152 try to confuse the congestion control mechanism, or send forged 1153 packets to the session which would prevent successful reconstruction 1154 or cause inaccurate reconstruction of large portions of an object by 1155 receivers. LCT is particularly affected by such an attack since many 1156 receivers may receive the same forged packet. It is therefore 1157 RECOMMENDED that an integrity check be made on received objects 1158 before delivery to an application, e.g., by appending an MD5 hash 1159 [RFC1321] to an object before it is sent and then computing the MD5 1160 hash once the object is reconstructed to ensure it is the same as the 1161 sent object. Moreover, in order to obtain strong cryptographic 1162 integrity protection a digital signature verifiable by the receiver 1163 SHOULD be computed on top of such a hash value. It is also 1164 RECOMMENDED that protocol instantiations that use LCT implement some 1165 form of packet authentication such as TESLA [PER2001] to protect 1166 against such attacks. Finally, it is RECOMMENDED that Reverse Path 1167 Forwarding checks be enabled in all network routers and switches 1168 along the path from the sender to receivers to limit the possibility 1169 of a bad agent injecting forged packets into the multicast tree data 1170 path. 1172 Another vulnerability of LCT is the potential of receivers obtaining 1173 an incorrect session description for the session. The consequences 1174 of this could be that legitimate receivers with the wrong session 1175 description are unable to correctly receive the session content, or 1176 that receivers inadvertently try to receive at a much higher rate 1177 than they are capable of, thereby disrupting traffic in portions of 1178 the network. To avoid these problems, it is RECOMMENDED that 1179 measures be taken to prevent receivers from accepting incorrect 1180 Session Descriptions, e.g., by using source authentication to ensure 1181 that receivers only accept legitimate Session Descriptions from 1182 authorized senders. 1184 A receiver with an incorrect or corrupted implementation of the 1185 multiple rate congestion control building block may affect health of 1186 the network in the path between the sender and the receiver, and may 1187 also affect the reception rates of other receivers joined to the 1188 session. It is therefore RECOMMENDED that receivers be required to 1189 identify themselves as legitimate before they receive the Session 1190 Description needed to join the session. How receivers identify 1191 themselves as legitimate is outside the scope of this document. 1193 9. IANA Considerations 1195 9.1. Namespace declaration for LCT Header Extension Types 1197 This document defines two name-spaces for registration of LCT Header 1198 Extensions Types named: 1199 ietf:rmt:lct:headerExtensionTypes:variableLength 1200 and 1201 ietf:rmt:lct:headerExtensionTypes:fixedLength 1203 The values that can be assigned within the "ietf:rmt:lct: 1204 headerExtensionTypes:variableLength" name-space are numeric indexes 1205 in the range [0, 127] inclusive. The values that can be assigned 1206 within the "ietf:rmt:lct:headerExtensionTypes:fixedLength" name-space 1207 are numeric indexes in the range [128, 255] inclusive. Assignment 1208 requests for both namespaces shall be granted on a "IETF Consensus" 1209 basis as defined in [RFC2434]. 1211 Note that the previous Experimental version of this specification 1212 reserved values in the ranges [64, 127] and [192, 255] for Protocol 1213 Instantiation-specific LCT Header Extensions. In the interests of 1214 simplification and since there were no overlapping allocations of 1215 these LCT Header Extension Type values by Protocol Inatntiations, 1216 this document specifies a single flat space for LCT Header Extension 1217 Types. Values in the range [0,63] and [128,191] SHOULD be used for 1218 Header Extensions which are expected to have broad applicability over 1219 all users of the LCT Building Block. Values outside this range 1220 SHOULD be used for Header Extensions with more limited applicability. 1221 However, these Header Extension Type values are global in scope and 1222 are NOT Protocol-Instantiation specific. 1224 9.2. LCT Header Extension Type registration 1226 This document registers two values in the namespace "ietf:rmt:lct: 1227 headerExtensionTypes:variableLength" as follows: 1229 +-------+----------+--------------------+ 1230 | Value | Name | Reference | 1231 +-------+----------+--------------------+ 1232 | 0 | EXT_NOP | This specification | 1233 | | | | 1234 | 1 | EXT_AUTH | This specification | 1235 +-------+----------+--------------------+ 1237 10. Acknowledgments 1239 Thanks to Vincent Roca and Roger Kermode for detailed comments and 1240 contributions to this document. Thanks also to Bruce Lueckenhoff, 1241 Hayder Radha and Justin Chapweske for detailed comments on this 1242 document. 1244 11. Change Log 1246 11.1. RFC3451 to draft-ietf-rmt-bb-lct-revised-00 1248 Update all references to the obsoleted RFC 2068 to RFC 2616 1250 Removed the 'Statement of Intent' from the introduction 1252 The statement of intent was meant to clarify the "Experimental" 1253 status of RFC3451. It does not apply to this draft that is 1254 intended for "Standard Track" submission. 1256 11.2. draft-ietf-rmt-bb-lct-revised-00 to -01 1258 o Inclusion of material from ALC which is applicable in the more 1259 general LCT context 1261 o Creation of an IANA registry for LCT Header Extension 1263 o Allocation of the 2 'reserved' bits in the LCT header as "Protocol 1264 Specific Indication" - usage to be defined by protocol 1265 instantiations 1267 o Proposal added to redefine the Sender Current Time as an NTP 1268 timestamp. Decision on this is tbd as it is non-backwards 1269 compatible. 1271 o Update references from Experimental RFCs to new drafts 1273 o Split references into normative and informative 1275 12. References 1277 12.1. Normative References 1279 [I-D.ietf-rmt-fec-bb-revised] 1280 Watson, M., "Forward Error Correction (FEC) Building 1281 Block", draft-ietf-rmt-fec-bb-revised-02 (work in 1282 progress), October 2005. 1284 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1285 August 1980. 1287 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1288 RFC 1112, August 1989. 1290 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1291 Specification, Implementation", RFC 1305, March 1992. 1293 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1294 3", BCP 9, RFC 2026, October 1996. 1296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1297 Requirement Levels", BCP 14, RFC 2119, March 1997. 1299 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1300 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1301 October 1998. 1303 12.2. Informative References 1305 [BYE1998] Byers, J., Luby, M., Mitzenmacher, M., and A. Rege, 1306 "Fountain Approach to Reliable Distribution of Bulk Data", 1307 Proceedings ACM SIGCOMM'98, Vancouver, Canada , 1308 September 1998. 1310 [BYE2000] Byers, J., Frumin, M., Horn, G., Luby, M., Mitzenmacher, 1311 M., Rotter, A., and W. Shaver, "FLID-DL: Congestion 1312 Control for Layered Multicast", Proceedings of Second 1313 International Workshop on Networked Group Communications 1314 (NGC 2000), Palo Alto, CA , November 2000. 1316 [GEM2000] Gemmell, J., Schooler, E., and J. Gray, "Fcast Multicast 1317 File Distribution", IEEE Network, Vol. 14, No. 1, pp. 1318 58-68 , January 2000. 1320 [HOL2001] Holbrook, H., "A Channel Model for Multicast", Ph.D. 1321 Dissertation, Stanford University, Department of Computer 1322 Science, Stanford, CA , August 2001. 1324 [LUB2002] Luby, M., Goyal, V., Skaria, S., and G. Horn, "Wave and 1325 Equation Based Rate Control using Multicast Round-trip 1326 Time", Proceedings of ACM SIGCOMM 2002, Pittsburgh PA , 1327 August 2002. 1329 [PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, 1330 "Efficient and Secure Source Authentication for 1331 Multicast", Network and Distributed System Security 1332 Symposium, NDSS 2001, pp. 35-46 , February 2001. 1334 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1335 April 1992. 1337 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 1338 Jacobson, "RTP: A Transport Protocol for Real-Time 1339 Applications", RFC 1889, January 1996. 1341 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1342 Protocol", RFC 2327, April 1998. 1344 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1345 Criteria for Evaluating Reliable Multicast Transport and 1346 Application Protocols", RFC 2357, June 1998. 1348 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1349 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1350 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1352 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1353 Announcement Protocol", RFC 2974, October 2000. 1355 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1356 Types", RFC 3023, January 2001. 1358 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1359 Floyd, S., and M. Luby, "Reliable Multicast Transport 1360 Building Blocks for One-to-Many Bulk-Data Transfer", 1361 RFC 3048, January 2001. 1363 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 1364 Reliable Multicast Transport (RMT) Building Blocks and 1365 Protocol Instantiation documents", RFC 3269, April 2002. 1367 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1368 M., and J. Crowcroft, "The Use of Forward Error Correction 1369 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1371 [RIZ1997] Rizzo, L., "Effective Erasure Codes for Reliable Computer 1372 Communication Protocols", ACM SIGCOMM Computer 1373 Communication Review, Vol.27, No.2, pp.24-36 , April 1997. 1375 [RIZ1997a] 1376 Rizzo, L., "Effective Erasure Codes for Reliable Computer 1377 Communication Protocols", ACM SIGCOMM Computer 1378 Communication Review, Vol.27, No.2, pp.24-36 , April 1997. 1380 [RIZ1997b] 1381 Rizzo, L. and L. Vicisano, "Reliable Multicast Data 1382 Distribution protocol based on software FEC techniques", 1383 Proceedings of the Fourth IEEE Workshop on the 1384 Architecture and Implementation of High Performance 1385 Communication Systems, HPCS'97, Chalkidiki Greece , 1386 June 1997. 1388 [RIZ2000] Rizzo, L., "PGMCC: A TCP-friendly single-rate multicast 1389 congestion control scheme", Proceedings of SIGCOMM 2000, 1390 Stockholm Sweden , August 2000. 1392 [VIC1998] Vicisano, L., Rizzo, L., and J. Crowcroft, "TCP-like 1393 Congestion Control for Layered Multicast Data Transfer", 1394 IEEE Infocom'98, San Francisco, CA , March 1998. 1396 Authors' Addresses 1398 Michael Luby 1399 Digital Fountain 1400 39141 Civic Center Dr. 1401 Suite 300 1402 Fremont, CA 94538 1403 US 1405 Email: luby@digitalfountain.com 1407 Mark Watson 1408 Digital Fountain 1409 39141 Civic Center Dr. 1410 Suite 300 1411 Fremont, CA 94538 1412 US 1414 Email: mark@digitalfountain.com 1416 Jim Gemmell 1417 Microsoft Research 1418 455 Market St. #1690 1419 San Francisco, CA 94105 1420 US 1422 Email: jgemmell@microsoft.com 1424 Lorenzo Vicisano 1425 Cisco Systems, Inc. 1426 510 McCarthy Blvd. 1427 Milpitas, CA 95035 1428 US 1430 Email: lorenzo@cisco.com 1431 Luigi Rizzo 1432 Univ. di Pisa 1433 Dip. Ing. dell'Informazione, 1434 via Diotisalvi 2 1435 Pisa, PI 56126 1436 Italy 1438 Email: luigi@iet.unipi.it 1440 Mark Handley 1441 University College London 1442 Dept. of Computer Science 1443 Gower Street 1444 London, WC1E 6BT 1445 United Kingdom 1447 Email: M.Handley@cs.ucl.ac.uk 1449 Jon Crowcroft 1450 University of Cambridge 1451 Computer Laboratory 1452 William Gates Building 1453 J J Thomson Avenue 1454 Cambridge, CB3 0FD 1455 United Kingdom 1457 Email: Jon.Crowcroft@cl.cam.ac.uk 1459 Intellectual Property Statement 1461 The IETF takes no position regarding the validity or scope of any 1462 Intellectual Property Rights or other rights that might be claimed to 1463 pertain to the implementation or use of the technology described in 1464 this document or the extent to which any license under such rights 1465 might or might not be available; nor does it represent that it has 1466 made any independent effort to identify any such rights. Information 1467 on the procedures with respect to rights in RFC documents can be 1468 found in BCP 78 and BCP 79. 1470 Copies of IPR disclosures made to the IETF Secretariat and any 1471 assurances of licenses to be made available, or the result of an 1472 attempt made to obtain a general license or permission for the use of 1473 such proprietary rights by implementers or users of this 1474 specification can be obtained from the IETF on-line IPR repository at 1475 http://www.ietf.org/ipr. 1477 The IETF invites any interested party to bring to its attention any 1478 copyrights, patents or patent applications, or other proprietary 1479 rights that may cover technology that may be required to implement 1480 this standard. Please address the information to the IETF at 1481 ietf-ipr@ietf.org. 1483 Disclaimer of Validity 1485 This document and the information contained herein are provided on an 1486 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1487 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1488 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1489 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1490 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1491 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1493 Copyright Statement 1495 Copyright (C) The Internet Society (2005). This document is subject 1496 to the rights, licenses and restrictions contained in BCP 78, and 1497 except as set forth therein, the authors retain all their rights. 1499 Acknowledgment 1501 Funding for the RFC Editor function is currently provided by the 1502 Internet Society.