idnits 2.17.1 draft-ietf-rmt-bb-lct-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 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1353. ** 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: 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 (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) -- Looks like a reference, but probably isn't: '22' on line 1058 -- Looks like a reference, but probably isn't: '3' on line 1058 -- Looks like a reference, but probably isn't: '25' on line 1058 -- Looks like a reference, but probably isn't: '13' on line 987 -- Looks like a reference, but probably isn't: '23' on line 1047 -- Looks like a reference, but probably isn't: '11' on line 1087 -- Looks like a reference, but probably isn't: '12' on line 1077 -- Looks like a reference, but probably isn't: '8' on line 1083 -- Looks like a reference, but probably isn't: '14' on line 1084 -- Looks like a reference, but probably isn't: '6' on line 1084 -- Looks like a reference, but probably isn't: '9' on line 1085 -- Looks like a reference, but probably isn't: '15' on line 1115 -- Looks like a reference, but probably isn't: '17' on line 1109 == Unused Reference: 'PER2001' is defined on line 1194, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1205, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 1212, but no explicit reference was found in the text == Unused Reference: 'RIZ1997' is defined on line 1252, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BYE1998' -- Possible downref: Non-RFC (?) normative reference: ref. 'BYE2000' -- Possible downref: Non-RFC (?) normative reference: ref. 'GEM2000' -- Possible downref: Non-RFC (?) normative reference: ref. 'HOL2001' -- Possible downref: Non-RFC (?) normative reference: ref. 'LUB2002' -- Possible downref: Non-RFC (?) normative reference: ref. 'PER2001' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** 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 3452 (Obsoleted by RFC 5052, RFC 5445) ** Downref: Normative reference to an Informational RFC: RFC 3453 -- Possible downref: Non-RFC (?) normative reference: ref. 'RIZ1997' -- Possible downref: Non-RFC (?) normative reference: ref. 'RIZ1997a' -- Possible downref: Non-RFC (?) normative reference: ref. 'RIZ1997b' -- Possible downref: Non-RFC (?) normative reference: ref. 'RIZ2000' -- Possible downref: Non-RFC (?) normative reference: ref. 'VIC1998' Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 32 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 Handley 11 University College London 12 Crowcroft 13 University of Cambridge 14 July 6, 2005 16 Layered Coding Transport (LCT) Building Block 17 draft-ietf-rmt-bb-lct-revised-00 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 7, 2006. 44 Copyright Notice 46 Copyright (C) The Internet Society (2005). 48 Abstract 49 Layered Coding Transport (LCT) provides transport level support for 50 reliable content delivery and stream delivery protocols. LCT is 51 specifically designed to support protocols using IP multicast, but 52 also provides support to protocols that use unicast. LCT is 53 compatible with congestion control that provides multiple rate 54 delivery to receivers and is also compatible with coding techniques 55 that provide reliable delivery of content. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Functionality . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.1 Environmental Requirements and Considerations . . . . . . 10 64 4.2 Delivery service models . . . . . . . . . . . . . . . . . 12 65 4.3 Congestion Control . . . . . . . . . . . . . . . . . . . . 13 66 5. Packet Header Fields . . . . . . . . . . . . . . . . . . . . 14 67 5.1 Default LCT header format . . . . . . . . . . . . . . . . 14 68 5.2 Header-Extension Fields . . . . . . . . . . . . . . . . . 19 69 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 23 70 6.1 Sender Operation . . . . . . . . . . . . . . . . . . . . . 23 71 6.2 Receiver Operation . . . . . . . . . . . . . . . . . . . . 25 72 7. Requirements from Other Building Blocks . . . . . . . . . . 27 73 8. Security Considerations . . . . . . . . . . . . . . . . . . 29 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 76 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 32 77 11.1 RFC3451 to draft-ietf-rmt-bb-lct-revised-00 . . . . . . 32 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 80 Intellectual Property and Copyright Statements . . . . . . . 36 82 1. Introduction 84 Layered Coding Transport provides transport level support for 85 reliable content delivery and stream delivery protocols. Layered 86 Coding Transport is specifically designed to support protocols using 87 IP multicast, but also provides support to protocols that use 88 unicast. Layered Coding Transport is compatible with congestion 89 control that provides multiple rate delivery to receivers and is also 90 compatible with coding techniques that provide reliable delivery of 91 content. 93 This document describes a building block as defined in [RFC3048]. 94 This document is a product of the IETF RMT WG and follows the 95 general guidelines provided in [RFC3269]. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Rationale 103 LCT provides transport level support for massively scalable protocols 104 using the IP multicast network service. The support that LCT 105 provides is common to a variety of very important applications, 106 including reliable content delivery and streaming applications. 108 An LCT session comprises multiple channels originating at a single 109 sender that are used for some period of time to carry packets 110 pertaining to the transmission of one or more objects that can be of 111 interest to receivers. The logic behind defining a session as 112 originating from a single sender is that this is the right 113 granularity to regulate packet traffic via congestion control. One 114 rationale for using multiple channels within the same session is that 115 there are massively scalable congestion control protocols that use 116 multiple channels per session. These congestion control protocols 117 are considered to be layered because a receiver joins and leaves 118 channels in a layered order during its participation in the session. 119 The use of layered channels is also useful for streaming 120 applications. 122 There are coding techniques that provide massively scalable 123 reliability and asynchronous delivery which are compatible with both 124 layered congestion control and with LCT. When all are combined the 125 result is a massively scalable reliable asynchronous content delivery 126 protocol that is network friendly. LCT also provides functionality 127 that can be used for other applications as well, e.g., layered 128 streaming applications. 130 LCT avoids providing functionality that is not massively scalable. 131 For example, LCT does not provide any mechanisms for sending 132 information from receivers to senders, although this does not rule 133 out protocols that both use LCT and do require sending information 134 from receivers to senders. 136 LCT includes general support for congestion control that must be 137 used. It does not, however, specify which congestion control should 138 be used. The rationale for this is that congestion control must be 139 provided by any protocol that is network friendly, and yet the 140 different applications that can use LCT will not have the same 141 requirements for congestion control. For example, a content delivery 142 protocol may strive to use all available bandwidth between receivers 143 and the sender. It must, therefore, drastically back off its rate 144 when there is competing traffic. On the other hand, a streaming 145 delivery protocol may strive to maintain a constant rate instead of 146 trying to use all available bandwidth, and it may not back off its 147 rate as fast when there is competing traffic. 149 Beyond support for congestion control, LCT provides a number of 150 fields and supports functionality commonly required by many 151 protocols. For example, LCT provides a Transmission Session ID that 152 can be used to identify which session each received packet belongs 153 to. This is important because a receiver may be joined to many 154 sessions concurrently, and thus it is very useful to be able to 155 demultiplex packets as they arrive according to which session they 156 belong to. As another example, LCT provides optional support for 157 identifying which object each packet is carrying information about. 158 Therefore, LCT provides many of the commonly used fields and support 159 for functionality required by many protocols. 161 3. Functionality 163 An LCT session consists of a set of logically grouped LCT channels 164 associated with a single sender carrying packets with LCT headers for 165 one or more objects. An LCT channel is defined by the combination of 166 a sender and an address associated with the channel by the sender. A 167 receiver joins a channel to start receiving the data packets sent to 168 the channel by the sender, and a receiver leaves a channel to stop 169 receiving data packets from the channel. 171 LCT is meant to be combined with other building blocks so that the 172 resulting overall protocol is massively scalable. Scalability refers 173 to the behavior of the protocol in relation to the number of 174 receivers and network paths, their heterogeneity, and the ability to 175 accommodate dynamically variable sets of receivers. Scalability 176 limitations can come from memory or processing requirements, or from 177 the amount of feedback control and redundant data packet traffic 178 generated by the protocol. In turn, such limitations may be a 179 consequence of the features that a complete reliable content delivery 180 or stream delivery protocol is expected to provide. 182 The LCT header provides a number of fields that are useful for 183 conveying in-band session information to receivers. One of the 184 required fields is the Transmission Session ID (TSI), which allows 185 the receiver of a session to uniquely identify received packets as 186 part of the session. Another required field is the Congestion 187 Control Information (CCI), which allows the receiver to perform the 188 required congestion control on the packets received within the 189 session. Other LCT fields provide optional but often very useful 190 additional information for the session. For example, the Transport 191 Object Identifier (TOI) identifies which object the packet contains 192 data for. As other examples, the Sender Current Time (SCT) conveys 193 the time when the packet was sent from the sender to the receiver, 194 the Expected Residual Time (ERT) conveys the amount of time the 195 session will be continued for, flags for indicating the close of the 196 session and the close of sending packets for an object, and header 197 extensions for fields that for example can be used for packet 198 authentication. 200 LCT provides support for congestion control. Congestion control MUST 201 be used that conforms to [RFC2357] between receivers and the sender 202 for each LCT session. Congestion control refers to the ability to 203 adapt throughput to the available bandwidth on the path from the 204 sender to a receiver, and to share bandwidth fairly with competing 205 flows such as TCP. Thus, the total flow of packets flowing to each 206 receiver participating in an LCT session MUST NOT compete unfairly 207 with existing flow adaptive protocols such as TCP. 209 A multiple rate or a single rate congestion control protocol can be 210 used with LCT. For multiple rate protocols, a session typically 211 consists of more than one channel and the sender sends packets to the 212 channels in the session at rates that do not depend on the receivers. 213 Each receiver adjusts its reception rate during its participation in 214 the session by joining and leaving channels dynamically depending on 215 the available bandwidth to the sender independent of all other 216 receivers. Thus, for multiple rate protocols, the reception rate of 217 each receiver may vary dynamically independent of the other 218 receivers. 220 For single rate protocols, a session typically consists of one 221 channel and the sender sends packets to the channel at variable rates 222 over time depending on feedback from receivers. Each receiver 223 remains joined to the channel during its participation in the 224 session. Thus, for single rate protocols, the reception rate of each 225 receiver may vary dynamically but in coordination with all receivers. 227 Generally, a multiple rate protocol is preferable to a single rate 228 protocol in a heterogeneous receiver environment, since generally it 229 more easily achieves scalability to many receivers and provides 230 higher throughput to each individual receiver. Some possible 231 multiple rate congestion control protocols are described in 232 [VIC1998], [BYE2000], and [LUB2002]. A possible single rate 233 congestion control protocol is described in [RIZ2000]. 235 Layered coding refers to the ability to produce a coded stream of 236 packets that can be partitioned into an ordered set of layers. The 237 coding is meant to provide some form of reliability, and the layering 238 is meant to allow the receiver experience (in terms of quality of 239 playout, or overall transfer speed) to vary in a predictable way 240 depending on how many consecutive layers of packets the receiver is 241 receiving. 243 The concept of layered coding was first introduced with reference to 244 audio and video streams. For example, the information associated 245 with a TV broadcast could be partitioned into three layers, 246 corresponding to black and white, color, and HDTV quality. Receivers 247 can experience different quality without the need for the sender to 248 replicate information in the different layers. 250 The concept of layered coding can be naturally extended to reliable 251 content delivery protocols when Forward Error Correction (FEC) 252 techniques are used for coding the data stream. Descriptions of this 253 can be found in [RIZ1997a], [RIZ1997b], [GEM2000], [VIC1998] and 254 [BYE1998]. By using FEC, the data stream is transformed in such a 255 way that reconstruction of a data object does not depend on the 256 reception of specific data packets, but only on the number of 257 different packets received. As a result, by increasing the number of 258 layers a receiver is receiving from, the receiver can reduce the 259 transfer time accordingly. Using FEC to provide reliability can 260 increase scalability dramatically in comparison to other methods for 261 providing reliability. More details on the use of FEC for reliable 262 content delivery can be found in [RFC3453]. 264 Reliable protocols aim at giving guarantees on the reliable delivery 265 of data from the sender to the intended recipients. Guarantees vary 266 from simple packet data integrity to reliable delivery of a precise 267 copy of an object to all intended recipients. Several reliable 268 content delivery protocols have been built on top of IP multicast 269 using methods other than FEC, but scalability was not the primary 270 design goal for many of them. 272 Two of the key difficulties in scaling reliable content delivery 273 using IP multicast are dealing with the amount of data that flows 274 from receivers back to the sender, and the associated response 275 (generally data retransmissions) from the sender. Protocols that 276 avoid any such feedback, and minimize the amount of retransmissions, 277 can be massively scalable. LCT can be used in conjunction with FEC 278 codes or a layered codec to achieve reliability with little or no 279 feedback. 281 Protocol instantiations MAY be built by combining the LCT framework 282 with other components. A complete protocol instantiation that uses 283 LCT MUST include a congestion control protocol that is compatible 284 with LCT and that conforms to [RFC2357]. A complete protocol 285 instantiation that uses LCT MAY include a scalable reliability 286 protocol that is compatible with LCT, it MAY include an session 287 control protocol that is compatible with LCT, and it MAY include 288 other protocols such as security protocols. 290 4. Applicability 292 An LCT session comprises a logically related set of one or more LCT 293 channels originating at a single sender. The channels are used for 294 some period of time to carry packets containing LCT headers, and 295 these headers pertain to the transmission of one or more objects that 296 can be of interest to receivers. 298 LCT is most applicable for delivery of objects or streams in a 299 session of substantial length, i.e., objects or streams that range in 300 aggregate length from hundreds of kilobytes to many gigabytes, and 301 where the duration of the session is on the order of tens of seconds 302 or more. 304 As an example, an LCT session could be used to deliver a TV program 305 using three LCT channels. Receiving packets from the first LCT 306 channel could allow black and white reception. Receiving the first 307 two LCT channels could also permit color reception. Receiving all 308 three channels could allow HDTV quality reception. Objects in this 309 example could correspond to individual TV programs being transmitted. 311 As another example, a reliable LCT session could be used to reliably 312 deliver hourly-updated weather maps (objects) using ten LCT channels 313 at different rates, using FEC coding. A receiver may join and 314 concurrently receive packets from subsets of these channels, until it 315 has enough packets in total to recover the object, then leave the 316 session (or remain connected listening for session description 317 information only) until it is time to receive the next object. In 318 this case, the quality metric is the time required to receive each 319 object. 321 Before joining a session, the receivers MUST obtain enough of the 322 session description to start the session. This MUST include the 323 relevant session parameters needed by a receiver to participate in 324 the session, including all information relevant to congestion 325 control. The session description is determined by the sender, and is 326 typically communicated to the receivers out-of-band. In some cases, 327 as described later, parts of the session description that are not 328 required to initiate a session MAY be included in the LCT header or 329 communicated to a receiver out-of-band after the receiver has joined 330 the session. 332 An encoder MAY be used to generate the data that is placed in the 333 packet payload in order to provide reliability. A suitable decoder 334 is used to reproduce the original information from the packet 335 payload. There MAY be a reliability header that follows the LCT 336 header if such an encoder and decoder is used. The reliability 337 header helps to describe the encoding data carried in the payload of 338 the packet. The format of the reliability header depends on the 339 coding used, and this is negotiated out-of-band. As an example, one 340 of the FEC headers described in [RFC3452] could be used. 342 For LCT, when multiple rate congestion control is used, congestion 343 control is achieved by sending packets associated with a given 344 session to several LCT channels. Individual receivers dynamically 345 join one or more of these channels, according to the network 346 congestion as seen by the receiver. LCT headers include an opaque 347 field which MUST be used to convey congestion control information to 348 the receivers. The actual congestion control scheme to use with LCT 349 is negotiated out-of-band. Some examples of congestion control 350 protocols that may be suitable for content delivery are described in 351 [VIC1998], [BYE2000], and [LUB2002]. Other congestion controls may 352 be suitable when LCT is used for a streaming application. 354 This document does not specify and restrict the type of exchanges 355 between LCT (or any PI built on top of LCT) and an upper application. 356 Some upper APIs may use an object-oriented approach, where the only 357 possible unit of data exchanged between LCT (or any PI built on top 358 of LCT) and an application, either at a source or at a receiver, is 359 an object. Other APIs may enable a sending or receiving application 360 to exchange a subset of an object with LCT (or any PI built on top of 361 LCT), or may even follow a streaming model. These considerations are 362 outside the scope of this document. 364 4.1 Environmental Requirements and Considerations 366 LCT is intended for congestion controlled delivery of objects and 367 streams (both reliable content delivery and streaming of multimedia 368 information). 370 LCT can be used with both multicast and unicast delivery. LCT 371 requires connectivity between a sender and receivers but does not 372 require connectivity from receivers to a sender. LCT inherently 373 works with all types of networks, including LANs, WANs, Intranets, 374 the Internet, asymmetric networks, wireless networks, and satellite 375 networks. Thus, the inherent raw scalability of LCT is unlimited. 376 However, when other specific applications are built on top of LCT, 377 then these applications by their very nature may limit scalability. 378 For example, if an application requires receivers to retrieve out of 379 band information in order to join a session, or an application allows 380 receivers to send requests back to the sender to report reception 381 statistics, then the scalability of the application is limited by the 382 ability to send, receive, and process this additional data. 384 LCT requires receivers to be able to uniquely identify and 385 demultiplex packets associated with an LCT session. In particular, 386 there MUST be a Transport Session Identifier (TSI) associated with 387 each LCT session. The TSI is scoped by the IP address of the sender, 388 and the IP address of the sender together with the TSI MUST uniquely 389 identify the session. If the underlying transport is UDP as 390 described in [RFC0768], then the 16 bit UDP source port number MAY 391 serve as the TSI for the session. The TSI value MUST be the same in 392 all places it occurs within a packet. If there is no underlying TSI 393 provided by the network, transport or any other layer, then the TSI 394 MUST be included in the LCT header. 396 LCT is presumed to be used with an underlying network or transport 397 service that is a "best effort" service that does not guarantee 398 packet reception or packet reception order, and which does not have 399 any support for flow or congestion control. For example, the Any- 400 Source Multicast (ASM) model of IP multicast as defined in RFC 1112 401 [RFC1112] is such a "best effort" network service. While the basic 402 service provided by RFC 1112 is largely scalable, providing 403 congestion control or reliability should be done carefully to avoid 404 severe scalability limitations, especially in presence of 405 heterogeneous sets of receivers. 407 There are currently two models of multicast delivery, the Any-Source 408 Multicast (ASM) model as defined in [RFC1112] and the Source- 409 Specific Multicast (SSM) model as defined in [HOL2001]. LCT works 410 with both multicast models, but in a slightly different way with 411 somewhat different environmental concerns. When using ASM, a sender 412 S sends packets to a multicast group G, and the LCT channel address 413 consists of the pair (S,G), where S is the IP address of the sender 414 and G is a multicast group address. When using SSM, a sender S sends 415 packets to an SSM channel (S,G), and the LCT channel address 416 coincides with the SSM channel address. 418 A sender can locally allocate unique SSM channel addresses, and this 419 makes allocation of LCT channel addresses easy with SSM. To allocate 420 LCT channel addresses using ASM, the sender must uniquely chose the 421 ASM multicast group address across the scope of the group, and this 422 makes allocation of LCT channel addresses more difficult with ASM. 424 LCT channels and SSM channels coincide, and thus the receiver will 425 only receive packets sent to the requested LCT channel. With ASM, 426 the receiver joins an LCT channel by joining a multicast group G, and 427 all packets sent to G, regardless of the sender, may be received by 428 the receiver. Thus, SSM has compelling security advantages over ASM 429 for prevention of denial of service attacks. In either case, 430 receivers SHOULD use mechanisms to filter out packets from unwanted 431 sources. 433 Some networks are not amenable to some congestion control protocols 434 that could be used with LCT. In particular, for a satellite or 435 wireless network, there may be no mechanism for receivers to 436 effectively reduce their reception rate since there may be a fixed 437 transmission rate allocated to the session. 439 4.2 Delivery service models 441 LCT can support several different delivery service models. Two 442 examples are briefly described here. 444 Push service model 446 One way a push service model can be used for reliable content 447 delivery is to deliver a series of objects. For example, a 448 receiver could join the session and dynamically adapt the number 449 of LCT channels the receiver is joined to until enough packets 450 have been received to reconstruct an object. After reconstructing 451 the object the receiver may stay in the session and wait for the 452 transmission of the next object. 454 The push model is particularly attractive in satellite networks 455 and wireless networks. In these cases, a session may consist of 456 one fixed rate LCT channel. 458 On-demand content delivery model 460 For an on-demand content delivery service model, senders typically 461 transmit for some given time period selected to be long enough to 462 allow all the intended receivers to join the session and recover 463 the object. For example a popular software update might be 464 transmitted using LCT for several days, even though a receiver may 465 be able to complete the download in one hour total of connection 466 time, perhaps spread over several intervals of time. 468 In this case the receivers join the session, and dynamically adapt 469 the number of LCT channels they subscribe to according to the 470 available bandwidth. Receivers then drop from the session when 471 they have received enough packets to recover the object. 473 As an example, assume that an object is 50 MB. The sender could 474 send 1 KB packets to the first LCT channel at 50 packets per 475 second, so that receivers using just this LCT channel could 476 complete reception of the object in 1,000 seconds in absence of 477 loss, and would be able to complete reception even in presence of 478 some substantial amount of losses with the use of coding for 479 reliability. Furthermore, the sender could use a number of LCT 480 channels such that the aggregate rate of 1 KB packets to all LCT 481 channels is 1,000 packets per second, so that a receiver could be 482 able to complete reception of the object in as little 50 seconds 483 (assuming no loss and that the congestion control mechanism 484 immediately converges to the use of all LCT channels). 486 Other service models 488 There are many other delivery service models that LCT can be used 489 for that are not covered above. As examples, a live streaming or 490 an on- demand archival content streaming service model. A 491 description of the many potential applications, the appropriate 492 delivery service model, and the additional mechanisms to support 493 such functionalities when combined with LCT is beyond the scope of 494 this document. This document only attempts to describe the 495 minimal common scalable elements to these diverse applications 496 using LCT as the delivery transport. 498 4.3 Congestion Control 500 The specific congestion control protocol to be used for LCT sessions 501 depends on the type of content to be delivered. While the general 502 behavior of the congestion control protocol is to reduce the 503 throughput in presence of congestion and gradually increase it in the 504 absence of congestion, the actual dynamic behavior (e.g. response to 505 single losses) can vary. 507 Some possible congestion control protocols for reliable content 508 delivery using LCT are described in [VIC1998], [BYE2000], and 509 [LUB2002]. Different delivery service models might require different 510 congestion control protocols. 512 5. Packet Header Fields 514 Packets sent to an LCT session MUST include an "LCT header". The LCT 515 header format described below is the default format, and this is the 516 format that is recommended for use by protocol instantiations to 517 ensure a uniform format across different protocol instantiations. 518 Other LCT header formats MAY be used by protocol instantiations, but 519 if the default LCT header format is not used by a protocol 520 instantiation that uses LCT, then the protocol instantiation MUST 521 specify the lengths and positions within the LCT header it uses of 522 all fields described in the default LCT header. 524 Other building blocks MAY describe some of the same fields as 525 described for the LCT header. It is RECOMMENDED that protocol 526 instantiations using multiple building blocks include shared fields 527 at most once in each packet. Thus, for example, if another building 528 block is used with LCT that includes the optional Expected Residual 529 Time field, then the Expected Residual Time field SHOULD be carried 530 in each packet at most once. 532 The position of the LCT header within a packet MUST be specified by 533 any protocol instantiation that uses LCT. 535 5.1 Default LCT header format 537 The default LCT header is of variable size, which is specified by a 538 length field in the third byte of the header. In the LCT header, all 539 integer fields are carried in "big-endian" or "network order" format, 540 that is, most significant byte (octet) first. Bits designated as 541 "padding" or "reserved" (r) MUST by set to 0 by senders and ignored 542 by receivers. Unless otherwise noted, numeric constants in this 543 specification are in decimal (base 10). 545 The format of the default LCT header is depicted in Figure 1. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)| 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Congestion Control Information (CCI, length = 32*(C+1) bits) | 553 | ... | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Transport Session Identifier (TSI, length = 32*S+16*H bits) | 556 | ... | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Transport Object Identifier (TOI, length = 32*O+16*H bits) | 559 | ... | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Sender Current Time (SCT, if T = 1) | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Expected Residual Time (ERT, if R = 1) | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Header Extensions (if applicable) | 566 | ... | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 1: Default LCT header format 571 The function and length of each field in the default LCT header is 572 the following. Fields marked as "1" mean that the corresponding bits 573 MUST be set to "1" by the sender. Fields marked as "r" or "0" mean 574 that the corresponding bits MUST be set to "0" by the sender. 576 LCT version number (V): 4 bits 578 Indicates the LCT version number. The LCT version number for this 579 specification is 1. 581 Congestion control flag (C): 2 bits 583 C=0 indicates the Congestion Control Information (CCI) field is 584 32-bits in length. C=1 indicates the CCI field is 64-bits in 585 length. C=2 indicates the CCI field is 96-bits in length. C=3 586 indicates the CCI field is 128-bits in length. 588 Reserved (r): 2 bits 590 Reserved for future use. A sender MUST set these bits to zero and 591 a receiver MUST ignore these bits. 593 Transport Session Identifier flag (S): 1 bit 595 This is the number of full 32-bit words in the TSI field. The TSI 596 field is 32*S + 16*H bits in length, i.e. the length is either 0 597 bits, 16 bits, 32 bits, or 48 bits. 599 Transport Object Identifier flag (O): 2 bits 601 This is the number of full 32-bit words in the TOI field. The TOI 602 field is 32*O + 16*H bits in length, i.e., the length is either 0 603 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 604 bits. 606 Half-word flag (H): 1 bit 608 The TSI and the TOI fields are both multiples of 32-bits plus 16*H 609 bits in length. This allows the TSI and TOI field lengths to be 610 multiples of a half-word (16 bits), while ensuring that the 611 aggregate length of the TSI and TOI fields is a multiple of 32- 612 bits. 614 Sender Current Time present flag (T): 1 bit 616 T = 0 indicates that the Sender Current Time (SCT) field is not 617 present. T = 1 indicates that the SCT field is present. The SCT 618 is inserted by senders to indicate to receivers how long the 619 session has been in progress. 621 Expected Residual Time present flag (R): 1 bit 623 R = 0 indicates that the Expected Residual Time (ERT) field is not 624 present. R = 1 indicates that the ERT field is present. The ERT 625 is inserted by senders to indicate to receivers how much longer 626 the session / object transmission will continue. 628 Senders MUST NOT set R = 1 when the ERT for the session is more 629 than 2^32-1 time units (approximately 49 days), where time is 630 measured in units of milliseconds. 632 Close Session flag (A): 1 bit 634 Normally, A is set to 0. The sender MAY set A to 1 when 635 termination of transmission of packets for the session is 636 imminent. A MAY be set to 1 in just the last packet transmitted 637 for the session, or A MAY be set to 1 in the last few seconds of 638 packets transmitted for the session. Once the sender sets A to 1 639 in one packet, the sender SHOULD set A to 1 in all subsequent 640 packets until termination of transmission of packets for the 641 session. A received packet with A set to 1 indicates to a 642 receiver that the sender will immediately stop sending packets for 643 the session. When a receiver receives a packet with A set to 1 644 the receiver SHOULD assume that no more packets will be sent to 645 the session. 647 Close Object flag (B): 1 bit 649 Normally, B is set to 0. The sender MAY set B to 1 when 650 termination of transmission of packets for an object is imminent. 651 If the TOI field is in use and B is set to 1 then termination of 652 transmission for the object identified by the TOI field is 653 imminent. If the TOI field is not in use and B is set to 1 then 654 termination of transmission for the one object in the session 655 identified by out-of-band information is imminent. B MAY be set 656 to 1 in just the last packet transmitted for the object, or B MAY 657 be set to 1 in the last few seconds packets transmitted for the 658 object. Once the sender sets B to 1 in one packet for a 659 particular object, the sender SHOULD set B to 1 in all subsequent 660 packets for the object until termination of transmission of 661 packets for the object. A received packet with B set to 1 662 indicates to a receiver that the sender will immediately stop 663 sending packets for the object. When a receiver receives a packet 664 with B set to 1 then it SHOULD assume that no more packets will be 665 sent for the object to the session. 667 LCT header length (HDR_LEN): 8 bits 669 Total length of the LCT header in units of 32-bit words. The 670 length of the LCT header MUST be a multiple of 32-bits. This 671 field can be used to directly access the portion of the packet 672 beyond the LCT header, i.e., to the first other header if it 673 exists, or to the packet payload if it exists and there is no 674 other header, or to the end of the packet if there are no other 675 headers or packet payload. 677 Codepoint (CP): 8 bits 679 An opaque identifier which is passed to the packet payload decoder 680 to convey information on the codec being used for the packet 681 payload. The mapping between the codepoint and the actual codec 682 is defined on a per session basis and communicated out-of-band as 683 part of the session description information. The use of the CP 684 field is similar to the Payload Type (PT) field in RTP headers as 685 described in [RFC1889]. 687 Congestion Control Information (CCI): 32, 64, 96 or 128 bits 689 Used to carry congestion control information. For example, the 690 congestion control information could include layer numbers, 691 logical channel numbers, and sequence numbers. This field is 692 opaque for the purpose of this specification. 694 This field MUST be 32 bits if C=0. 696 This field MUST be 64 bits if C=1. 698 This field MUST be 96 bits if C=2. 700 This field MUST be 128 bits if C=3. 702 Transport Session Identifier (TSI): 0, 16, 32 or 48 bits 704 The TSI uniquely identifies a session among all sessions from a 705 particular sender. The TSI is scoped by the IP address of the 706 sender, and thus the IP address of the sender and the TSI together 707 uniquely identify the session. Although a TSI in conjunction with 708 the IP address of the sender always uniquely identifies a session, 709 whether or not the TSI is included in the LCT header depends on 710 what is used as the TSI value. If the underlying transport is 711 UDP, then the 16 bit UDP source port number MAY serve as the TSI 712 for the session. If the TSI value appears multiple times in a 713 packet then all occurrences MUST be the same value. If there is 714 no underlying TSI provided by the network, transport or any other 715 layer, then the TSI MUST be included in the LCT header. 717 The TSI MUST be unique among all sessions served by the sender 718 during the period when the session is active, and for a large 719 period of time preceding and following when the session is active. 720 A primary purpose of the TSI is to prevent receivers from 721 inadvertently accepting packets from a sender that belong to 722 sessions other than the sessions receivers are subscribed to. For 723 example, suppose a session is deactivated and then another session 724 is activated by a sender and the two sessions use an overlapping 725 set of channels. A receiver that connects and remains connected 726 to the first session during this sender activity could possibly 727 accept packets from the second session as belonging to the first 728 session if the TSI for the two sessions were identical. The 729 mapping of TSI field values to sessions is outside the scope of 730 this document and is to be done out-of-band. 732 The length of the TSI field is 32*S + 16*H bits. Note that the 733 aggregate lengths of the TSI field plus the TOI field is a 734 multiple of 32 bits. 736 Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 737 bits. 739 This field indicates which object within the session this packet 740 pertains to. For example, a sender might send a number of files 741 in the same session, using TOI=0 for the first file, TOI=1 for the 742 second one, etc. As another example, the TOI may be a unique 743 global identifier of the object that is being transmitted from 744 several senders concurrently, and the TOI value may be the output 745 of a hash function applied to the object. The mapping of TOI 746 field values to objects is outside the scope of this document and 747 is to be done out-of-band. The TOI field MUST be used in all 748 packets if more than one object is to be transmitted in a session, 749 i.e. the TOI field is either present in all the packets of a 750 session or is never present. 752 The length of the TOI field is 32*O + 16*H bits. Note that the 753 aggregate lengths of the TSI field plus the TOI field is a 754 multiple of 32 bits. 756 Sender Current Time (SCT): 0 or 32 bits 758 This field represents the current clock at the sender and at the 759 time this packet was transmitted, measured in units of 1ms and 760 computed modulo 2^32 units from the start of the session. 762 This field MUST NOT be present if T=0 and MUST be present if T=1. 764 Expected Residual Time (ERT): 0 or 32 bits 766 This field represents the sender expected residual transmission 767 time for the current session or for the transmission of the 768 current object, measured in units of 1ms. If the packet 769 containing the ERT field also contains the TOI field, then ERT 770 refers to the object corresponding to the TOI field, otherwise it 771 refers to the session. 773 This field MUST NOT be present if R=0 and MUST be present if R=1. 775 5.2 Header-Extension Fields 777 Header Extensions are used in LCT to accommodate optional header 778 fields that are not always used or have variable size. Examples of 779 the use of Header Extensions include: 781 o Extended-size versions of already existing header fields. 783 o Sender and Receiver authentication information. 785 The presence of Header Extensions can be inferred by the LCT header 786 length (HDR_LEN): if HDR_LEN is larger than the length of the 787 standard header then the remaining header space is taken by Header 788 Extension fields. 790 If present, Header Extensions MUST be processed to ensure that they 791 are recognized before performing any congestion control procedure or 792 otherwise accepting a packet. The default action for unrecognized 793 header extensions is to ignore them. This allows the future 794 introduction of backward-compatible enhancements to LCT without 795 changing the LCT version number. Non backward-compatible header 796 extensions CANNOT be introduced without changing the LCT version 797 number. 799 Protocol instantiation MAY override this default behavior for PI- 800 specific extensions (see below). 802 There are two formats for Header Extension fields, as depicted in 803 Figure 2. The first format is used for variable-length extensions, 804 with Header Extension Type (HET) values between 0 and 127. The 805 second format is used for fixed length (one 32-bit word) extensions, 806 using HET values from 127 to 255. 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | HET (<=127) | HEL | | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 813 . . 814 . Header Extension Content (HEC) . 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | HET (>=128) | Header Extension Content (HEC) | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 Figure 2: Format of additional headers 825 The explanation of each sub-field is the following: 827 Header Extension Type (HET): 8 bits 829 The type of the Header Extension. This document defines a number 830 of possible types. Additional types may be defined in future 831 versions of this specification. HET values from 0 to 127 are used 832 for variable-length Header Extensions. HET values from 128 to 255 833 are used for fixed-length 32-bit Header Extensions. 835 Header Extension Length (HEL): 8 bits 837 The length of the whole Header Extension field, expressed in 838 multiples of 32-bit words. This field MUST be present for 839 variable-length extensions (HET between 0 and 127) and MUST NOT be 840 present for fixed-length extensions (HET between 128 and 255). 842 Header Extension Content (HEC): variable length 844 The content of the Header Extension. The format of this sub- 845 field depends on the Header Extension type. For fixed-length 846 Header Extensions, the HEC is 24 bits. For variable-length Header 847 Extensions, the HEC field has variable size, as specified by the 848 HEL field. Note that the length of each Header Extension field 849 MUST be a multiple of 32 bits. Also note that the total size of 850 the LCT header, including all Header Extensions and all optional 851 header fields, cannot exceed 255 32-bit words. 853 Header Extensions are further divided between general LCT extensions 854 and Protocol Instantiation specific extensions (PI-specific). 855 General LCT extensions have HET in the ranges 0:63 and 128:191 856 inclusive. PI-specific extensions have HET in the ranges 64:127 and 857 192:255 inclusive. 859 General LCT extensions are intended to allow the introduction of 860 backward-compatible enhancements to LCT without changing the LCT 861 version number. Non backward-compatible header extensions CANNOT be 862 introduced without changing the LCT version number. 864 PI-specific extensions are reserved for PI-specific use with semantic 865 and default parsing actions defined by the PI. 867 The following general LCT Header Extension types are defined: 869 EXT_NOP=0 No-Operation extension. The information present in 870 this extension field MUST be ignored by receivers. 872 EXT_AUTH=1 Packet authentication extension Information used to 873 authenticate the sender of the packet. The format of 874 this Header Extension and its processing is outside the 875 scope of this document and is to be communicated out- 876 of-band as part of the session description. 878 It is RECOMMENDED that senders provide some form of 879 packet authentication. If EXT_AUTH is present, 880 whatever packet authentication checks that can be 881 performed immediately upon reception of the packet 882 SHOULD be performed before accepting the packet and 883 performing any congestion control-related action on it. 885 Some packet authentication schemes impose a delay of 886 several seconds between when a packet is received and 887 when the packet is fully authenticated. Any congestion 888 control related action that is appropriate MUST NOT be 889 postponed by any such full packet authentication. 891 All senders and receivers implementing LCT MUST support the EXT_NOP 892 Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to 893 parse its content. 895 6. Operations 897 6.1 Sender Operation 899 Before joining an LCT session a receiver MUST obtain a session 900 description. The session description MUST include: 902 o The sender IP address; 904 o The number of LCT channels; 906 o The addresses and port numbers used for each LCT channel; 908 o The Transport Session ID (TSI) to be used for the session; 910 o Enough information to determine the congestion control protocol 911 being used; 913 o Enough information to determine the packet authentication scheme 914 being used if it is being used. 916 The session description could also include, but is not limited to: 918 o The data rates used for each LCT channel; 920 o The length of the packet payload; 922 o The mapping of TOI value(s) to objects for the session; 924 o Any information that is relevant to each object being transported, 925 such as when it will be available within the session, for how 926 long, and the length of the object; 928 Protocol instantiations using LCT MAY place additional requirements 929 on what must be included in the session description. For example, a 930 protocol instantiation might require that the data rates for each 931 channel, or the mapping of TOI value(s) to objects for the session, 932 or other information related to other headers that might be required 933 to be included in the session description. 935 The session description could be in a form such as SDP as defined in 936 [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime 937 headers as defined in [RFC2616], etc. It might be carried in a 938 session announcement protocol such as SAP as defined in [RFC2974], 939 obtained using a proprietary session control protocol, located on a 940 Web page with scheduling information, or conveyed via E-mail or other 941 out-of-band methods. Discussion of session description format, and 942 distribution of session descriptions is beyond the scope of this 943 document. 945 Within an LCT session, a sender using LCT transmits a sequence of 946 packets, each in the format defined above. Packets are sent from a 947 sender using one or more LCT channels which together constitute a 948 session. Transmission rates may be different in different channels 949 and may vary over time. The specification of the other building 950 block headers and the packet payload used by a complete protocol 951 instantiation using LCT is beyond the scope of this document. This 952 document does not specify the order in which packets are transmitted, 953 nor the organization of a session into multiple channels. Although 954 these issues affect the efficiency of the protocol, they do not 955 affect the correctness nor the inter-operability of LCT between 956 senders and receivers. 958 Several objects can be carried within the same LCT session. In this 959 case, each object MUST be identified by a unique TOI. Objects MAY be 960 transmitted sequentially, or they MAY be transmitted concurrently. 961 It is good practice to only send objects concurrently in the same 962 session if the receivers that participate in that portion of the 963 session have interest in receiving all the objects. The reason for 964 this is that it wastes bandwidth and networking resources to have 965 receivers receive data for objects that they have no interest in. 967 Typically, the sender(s) continues to send packets in a session until 968 the transmission is considered complete. The transmission may be 969 considered complete when some time has expired, a certain number of 970 packets have been sent, or some out-of-band signal (possibly from a 971 higher level protocol) has indicated completion by a sufficient 972 number of receivers. 974 For the reasons mentioned above, this document does not pose any 975 restriction on packet sizes. However, network efficiency 976 considerations recommend that the sender uses an as large as possible 977 packet payload size, but in such a way that packets do not exceed the 978 network's maximum transmission unit size (MTU), or when fragmentation 979 coupled with packet loss might introduce severe inefficiency in the 980 transmission. 982 It is recommended that all packets have the same or very similar 983 sizes, as this can have a severe impact on the effectiveness of 984 congestion control schemes such as the ones described in [22], [3], 985 and [25]. A sender of packets using LCT MUST implement the sender- 986 side part of one of the congestion control schemes that is in 987 accordance with RFC 2357 [13] using the Congestion Control 988 Information field provided in the LCT header, and the corresponding 989 receiver congestion control scheme is to be communicated out-of-band 990 and MUST be implemented by any receivers participating in the 991 session. 993 6.2 Receiver Operation 995 Receivers can operate differently depending on the delivery service 996 model. For example, for an on demand service model, receivers may 997 join a session, obtain the necessary packets to reproduce the object, 998 and then leave the session. As another example, for a streaming 999 service model, a receiver may be continuously joined to a set of LCT 1000 channels to download all objects in a session. 1002 To be able to participate in a session, a receiver MUST obtain the 1003 relevant session description information as listed in Section 6.1. 1005 If packet authentication information is present in an LCT header, it 1006 SHOULD be used as specified in Section 5.2. To be able to be a 1007 receiver in a session, the receiver MUST be able to process the LCT 1008 header. The receiver MUST be able to discard, forward, store or 1009 process the other headers and the packet payload. If a receiver is 1010 not able to process a LCT header, it MUST drop from the session. 1012 To be able to participate in a session, a receiver MUST implement the 1013 congestion control protocol specified in the session description 1014 using the Congestion Control Information field provided in the LCT 1015 header. If a receiver is not able to implement the congestion 1016 control protocol used in the session, it MUST NOT join the session. 1017 When the session is transmitted on multiple LCT channels, receivers 1018 MUST initially join channels according to the specified startup 1019 behavior of the congestion control protocol. For a multiple rate 1020 congestion control protocol that uses multiple channels, this 1021 typically means that a receiver will initially join only a minimal 1022 set of LCT channels, possibly a single one, that in aggregate are 1023 carrying packets at a low rate. This rule has the purpose of 1024 preventing receivers from starting at high data rates. 1026 Several objects can be carried either sequentially or concurrently 1027 within the same LCT session. In this case, each object is identified 1028 by a unique TOI. Note that even if a server stops sending packets 1029 for an old object before starting to transmit packets for a new 1030 object, both the network and the underlying protocol layers can cause 1031 some reordering of packets, especially when sent over different LCT 1032 channels, and thus receivers SHOULD NOT assume that the reception of 1033 a packet for a new object means that there are no more packets in 1034 transit for the previous one, at least for some amount of time. 1036 A receiver MAY be concurrently joined to multiple LCT sessions from 1037 one or more senders. The receiver MUST perform congestion control on 1038 each such LCT session. If the congestion control protocol allows the 1039 receiver some flexibility in terms of its actions within a session 1040 then the receiver MAY make choices to optimize the packet flow 1041 performance across the multiple LCT sessions, as long as the receiver 1042 still adheres to the congestion control rules for each LCT session 1043 individually. 1045 7. Requirements from Other Building Blocks 1047 As described in RFC 3048 [23], LCT is a building block that is 1048 intended to be used, in conjunction with other building blocks, to 1049 help specify a protocol instantiation. A congestion control building 1050 block that uses the Congestion Control information field within the 1051 LCT header MUST be used by any protocol instantiation that uses LCT, 1052 and other building blocks MAY also be used, such as a reliability 1053 building block. 1055 The congestion control MUST be applied to the LCT session as an 1056 entity, i.e., over the aggregate of the traffic carried by all of the 1057 LCT channels associated with the LCT session. Some possible schemes 1058 are specified in [22], [3], and [25]. The Congestion Control 1059 Information field in the LCT header is an opaque field that is 1060 reserved to carry information related to congestion control. There 1061 MAY also be congestion control Header Extension fields that carry 1062 additional information related to congestion control. 1064 The particular layered encoder and congestion control protocols used 1065 with LCT have an impact on the performance and applicability of LCT. 1066 For example, some layered encoders used for video and audio streams 1067 can produce a very limited number of layers, thus providing a very 1068 coarse control in the reception rate of packets by receivers in a 1069 session. When LCT is used for reliable data transfer, some FEC 1070 codecs are inherently limited in the size of the object they can 1071 encode, and for objects larger than this size the reception overhead 1072 on the receivers can grow substantially. 1074 A more in-depth description of the use of FEC in Reliable Multicast 1075 Transport (RMT) protocols is given in [11]. Some of the FEC codecs 1076 that MAY be used in conjunction with LCT for reliable content 1077 delivery are specified in [12]. The Codepoint field in the LCT 1078 header is an opaque field that can be used to carry information 1079 related to the encoding of the packet payload. 1081 LCT also requires receivers to obtain a session description, as 1082 described in Section 6.1. The session description could be in a form 1083 such as SDP as defined in RFC 2327 [8], or XML metadata as defined in 1084 RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2616 [6], and 1085 distributed with SAP as defined in RFC 2974 [9], using HTTP, or in 1086 other ways. It is RECOMMENDED that an authentication protocol such 1087 as IPSEC [11] be used to deliver the session description to receivers 1088 to ensure the correct session description arrives. 1090 It is recommended that LCT implementors use some packet 1091 authentication scheme to protect the protocol from attacks. An 1092 example of a possibly suitable scheme is described in [15]. 1094 Some protocol instantiations that use LCT MAY use building blocks 1095 that require the generation of feedback from the receivers to the 1096 sender. However, the mechanism for doing this is outside the scope 1097 of LCT. 1099 8. Security Considerations 1101 LCT can be subject to denial-of-service attacks by attackers which 1102 try to confuse the congestion control mechanism, or send forged 1103 packets to the session which would prevent successful reconstruction 1104 or cause inaccurate reconstruction of large portions of an object by 1105 receivers. LCT is particularly affected by such an attack since many 1106 receivers may receive the same forged packet. It is therefore 1107 RECOMMENDED that an integrity check be made on received objects 1108 before delivery to an application, e.g., by appending an MD5 hash 1109 [17] to an object before it is sent and then computing the MD5 hash 1110 once the object is reconstructed to ensure it is the same as the sent 1111 object. Moreover, in order to obtain strong cryptographic integrity 1112 protection a digital signature verifiable by the receiver SHOULD be 1113 computed on top of such a hash value. It is also RECOMMENDED that 1114 protocol instantiations that use LCT implement some form of packet 1115 authentication such as TESLA [15] to protect against such attacks. 1116 Finally, it is RECOMMENDED that Reverse Path Forwarding checks be 1117 enabled in all network routers and switches along the path from the 1118 sender to receivers to limit the possibility of a bad agent injecting 1119 forged packets into the multicast tree data path. 1121 Another vulnerability of LCT is the potential of receivers obtaining 1122 an incorrect session description for the session. The consequences 1123 of this could be that legitimate receivers with the wrong session 1124 description are unable to correctly receive the session content, or 1125 that receivers inadvertently try to receive at a much higher rate 1126 than they are capable of, thereby disrupting traffic in portions of 1127 the network. To avoid these problems, it is RECOMMENDED that 1128 measures be taken to prevent receivers from accepting incorrect 1129 Session Descriptions, e.g., by using source authentication to ensure 1130 that receivers only accept legitimate Session Descriptions from 1131 authorized senders. 1133 A receiver with an incorrect or corrupted implementation of the 1134 multiple rate congestion control building block may affect health of 1135 the network in the path between the sender and the receiver, and may 1136 also affect the reception rates of other receivers joined to the 1137 session. It is therefore RECOMMENDED that receivers be required to 1138 identify themselves as legitimate before they receive the Session 1139 Description needed to join the session. How receivers identify 1140 themselves as legitimate is outside the scope of this document. 1142 9. IANA Considerations 1144 No information in this specification is subject to IANA registration. 1146 Building blocks used in conjunction with LCT MAY introduce additional 1147 IANA considerations. 1149 10. Acknowledgments 1151 Thanks to Vincent Roca and Roger Kermode for detailed comments and 1152 contributions to this document. Thanks also to Bruce Lueckenhoff, 1153 Hayder Radha and Justin Chapweske for detailed comments on this 1154 document. 1156 11. Change Log 1158 11.1 RFC3451 to draft-ietf-rmt-bb-lct-revised-00 1160 Update all references to the obsoleted RFC 2068 to RFC 2616 1162 Removed the 'Statement of Intent' from the introduction 1164 The statement of intent was meant to clarify the "Experimental" 1165 status of RFC3451. It does not apply to this draft that is 1166 intended for "Standard Track" submission. 1168 12. References 1170 [BYE1998] Byers, J., Luby, M., Mitzenmacher, M., and A. Rege, 1171 "Fountain Approach to Reliable Distribution of Bulk Data", 1172 Proceedings ACM SIGCOMM'98, Vancouver, Canada , 1173 September 1998. 1175 [BYE2000] Byers, J., Frumin, M., Horn, G., Luby, M., Mitzenmacher, 1176 M., Rotter, A., and W. Shaver, "FLID-DL: Congestion 1177 Control for Layered Multicast", Proceedings of Second 1178 International Workshop on Networked Group Communications 1179 (NGC 2000), Palo Alto, CA , November 2000. 1181 [GEM2000] Gemmell, J., Schooler, E., and J. Gray, "Fcast Multicast 1182 File Distribution", IEEE Network, Vol. 14, No. 1, pp. 1183 58-68 , January 2000. 1185 [HOL2001] Holbrook, H., "A Channel Model for Multicast", Ph.D. 1186 Dissertation, Stanford University, Department of Computer 1187 Science, Stanford, CA , August 2001. 1189 [LUB2002] Luby, M., Goyal, V., Skaria, S., and G. Horn, "Wave and 1190 Equation Based Rate Control using Multicast Round-trip 1191 Time", Proceedings of ACM SIGCOMM 2002, Pittsburgh PA , 1192 August 2002. 1194 [PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, 1195 "Efficient and Secure Source Authentication for 1196 Multicast", Network and Distributed System Security 1197 Symposium, NDSS 2001, pp. 35-46 , February 2001. 1199 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1200 August 1980. 1202 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1203 RFC 1112, August 1989. 1205 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1206 April 1992. 1208 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 1209 Jacobson, "RTP: A Transport Protocol for Real-Time 1210 Applications", RFC 1889, January 1996. 1212 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1213 3", BCP 9, RFC 2026, October 1996. 1215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1216 Requirement Levels", BCP 14, RFC 2119, March 1997. 1218 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1219 Protocol", RFC 2327, April 1998. 1221 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1222 Criteria for Evaluating Reliable Multicast Transport and 1223 Application Protocols", RFC 2357, June 1998. 1225 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1226 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1227 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1229 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1230 Announcement Protocol", RFC 2974, October 2000. 1232 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1233 Types", RFC 3023, January 2001. 1235 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1236 Floyd, S., and M. Luby, "Reliable Multicast Transport 1237 Building Blocks for One-to-Many Bulk-Data Transfer", 1238 RFC 3048, January 2001. 1240 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 1241 Reliable Multicast Transport (RMT) Building Blocks and 1242 Protocol Instantiation documents", RFC 3269, April 2002. 1244 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1245 M., and J. Crowcroft, "Forward Error Correction (FEC) 1246 Building Block", RFC 3452, December 2002. 1248 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1249 M., and J. Crowcroft, "The Use of Forward Error Correction 1250 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1252 [RIZ1997] Rizzo, L., "Effective Erasure Codes for Reliable Computer 1253 Communication Protocols", ACM SIGCOMM Computer 1254 Communication Review, Vol.27, No.2, pp.24-36 , April 1997. 1256 [RIZ1997a] 1257 Rizzo, L., "Effective Erasure Codes for Reliable Computer 1258 Communication Protocols", ACM SIGCOMM Computer 1259 Communication Review, Vol.27, No.2, pp.24-36 , April 1997. 1261 [RIZ1997b] 1262 Rizzo, L. and L. Vicisano, "Reliable Multicast Data 1263 Distribution protocol based on software FEC techniques", 1264 Proceedings of the Fourth IEEE Workshop on the 1265 Architecture and Implementation of High Performance 1266 Communication Systems, HPCS'97, Chalkidiki Greece , 1267 June 1997. 1269 [RIZ2000] Rizzo, L., "PGMCC: A TCP-friendly single-rate multicast 1270 congestion control scheme", Proceedings of SIGCOMM 2000, 1271 Stockholm Sweden , August 2000. 1273 [VIC1998] Vicisano, L., Rizzo, L., and J. Crowcroft, "TCP-like 1274 Congestion Control for Layered Multicast Data Transfer", 1275 IEEE Infocom'98, San Francisco, CA , March 1998. 1277 Authors' Addresses 1279 Michael Luby 1280 Digital Fountain 1281 39141 Civic Center Dr. 1282 Suite 300 1283 Fremont, CA 94538 1284 US 1286 Email: luby@digitalfountain.com 1288 Jim Gemmell 1289 Microsoft Research 1290 455 Market St. #1690 1291 San Francisco, CA 94105 1292 US 1294 Email: jgemmell@microsoft.com 1295 Lorenzo Vicisano 1296 Cisco Systems, Inc. 1297 510 McCarthy Blvd. 1298 Milpitas, CA 95035 1299 US 1301 Email: lorenzo@cisco.com 1303 Luigi Rizzo 1304 Univ. di Pisa 1305 Dip. Ing. dell'Informazione, 1306 via Diotisalvi 2 1307 Pisa, PI 56126 1308 Italy 1310 Email: luigi@iet.unipi.it 1312 Mark Handley 1313 University College London 1314 Dept. of Computer Science 1315 Gower Street 1316 London, WC1E 6BT 1317 United Kingdom 1319 Email: M.Handley@cs.ucl.ac.uk 1321 Jon Crowcroft 1322 University of Cambridge 1323 Computer Laboratory 1324 William Gates Building 1325 J J Thomson Avenue 1326 Cambridge, CB3 0FD 1327 United Kingdom 1329 Email: Jon.Crowcroft@cl.cam.ac.uk 1331 Intellectual Property Statement 1333 The IETF takes no position regarding the validity or scope of any 1334 Intellectual Property Rights or other rights that might be claimed to 1335 pertain to the implementation or use of the technology described in 1336 this document or the extent to which any license under such rights 1337 might or might not be available; nor does it represent that it has 1338 made any independent effort to identify any such rights. Information 1339 on the procedures with respect to rights in RFC documents can be 1340 found in BCP 78 and BCP 79. 1342 Copies of IPR disclosures made to the IETF Secretariat and any 1343 assurances of licenses to be made available, or the result of an 1344 attempt made to obtain a general license or permission for the use of 1345 such proprietary rights by implementers or users of this 1346 specification can be obtained from the IETF on-line IPR repository at 1347 http://www.ietf.org/ipr. 1349 The IETF invites any interested party to bring to its attention any 1350 copyrights, patents or patent applications, or other proprietary 1351 rights that may cover technology that may be required to implement 1352 this standard. Please address the information to the IETF at 1353 ietf-ipr@ietf.org. 1355 Disclaimer of Validity 1357 This document and the information contained herein are provided on an 1358 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1359 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1360 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1361 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1362 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1363 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1365 Copyright Statement 1367 Copyright (C) The Internet Society (2005). This document is subject 1368 to the rights, licenses and restrictions contained in BCP 78, and 1369 except as set forth therein, the authors retain all their rights. 1371 Acknowledgment 1373 Funding for the RFC Editor function is currently provided by the 1374 Internet Society.