idnits 2.17.1 draft-ietf-rmt-bb-lct-revised-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1484 has weird spacing: '...shop on the...' -- 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 (March 27, 2009) is 5503 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) == Missing Reference: 'RFC1305' is mentioned on line 934, but not defined ** Obsolete undefined reference: RFC 1305 (Obsoleted by RFC 5905) -- Looks like a reference, but probably isn't: '64' on line 1338 -- Looks like a reference, but probably isn't: '127' on line 1338 -- Looks like a reference, but probably isn't: '192' on line 1338 -- Looks like a reference, but probably isn't: '255' on line 1338 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 3451 (Obsoleted by RFC 5651) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast Transport (RMT) Luby 3 Working Group Watson 4 Internet-Draft Vicisano 5 Obsoletes: 3451 (if approved) Qualcomm Inc. 6 Intended status: Standards Track March 27, 2009 7 Expires: September 28, 2009 9 Layered Coding Transport (LCT) Building Block 10 draft-ietf-rmt-bb-lct-revised-08 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 28, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Layered Coding Transport (LCT) provides transport level support for 49 reliable content delivery and stream delivery protocols. LCT is 50 specifically designed to support protocols using IP multicast, but 51 also provides support to protocols that use unicast. LCT is 52 compatible with congestion control that provides multiple rate 53 delivery to receivers and is also compatible with coding techniques 54 that provide reliable delivery of content. This document obsoletes 55 RFC3451 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 . . . . . . . . . . . . . . . . . . . . 14 66 5. Packet Header Fields . . . . . . . . . . . . . . . . . . . . . 16 67 5.1. LCT header format . . . . . . . . . . . . . . . . . . . . 16 68 5.2. Header-Extension Fields . . . . . . . . . . . . . . . . . 20 69 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 20 70 5.2.2. EXT_TIME Header Extension . . . . . . . . . . . . . . 23 71 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 26 72 6.1. Sender Operation . . . . . . . . . . . . . . . . . . . . . 26 73 6.2. Receiver Operation . . . . . . . . . . . . . . . . . . . . 28 74 7. Requirements from Other Building Blocks . . . . . . . . . . . 30 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 76 8.1. Denial-of-service attacks . . . . . . . . . . . . . . . . 32 77 8.2. Forged session description attacks . . . . . . . . . . . . 32 78 8.3. Congestion control issues . . . . . . . . . . . . . . . . 32 79 8.4. Time synchronizartion . . . . . . . . . . . . . . . . . . 32 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 81 9.1. Namespace declaration for LCT Header Extension Types . . . 34 82 9.2. LCT Header Extension Type registration . . . . . . . . . . 34 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 84 11. Changes from RFC3451 . . . . . . . . . . . . . . . . . . . . . 36 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 37 87 12.2. Informative References . . . . . . . . . . . . . . . . . . 37 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 90 1. Introduction 92 Layered Coding Transport provides transport level support for 93 reliable content delivery and stream delivery protocols. Layered 94 Coding Transport is specifically designed to support protocols using 95 IP multicast, but also provides support to protocols that use 96 unicast. Layered Coding Transport is compatible with congestion 97 control that provides multiple rate delivery to receivers and is also 98 compatible with coding techniques that provide reliable delivery of 99 content. 101 This document describes a building block as defined in [RFC3048]. 102 This document is a product of the IETF RMT WG and follows the general 103 guidelines provided in [RFC3269]. 105 RFC3451 [RFC3451], which is obsoleted by this document, contained a 106 previous versions of the protocol. RFC3451 was published in the 107 "Experimental" category. It was the stated intent of the RMT working 108 group to re-submit these specifications as an IETF Proposed Standard 109 in due course. 111 This Proposed Standard specification is thus based on and backwards 112 compatible with the protocol defined in RFC3450 [RFC3451] updated 113 according to accumulated experience and growing protocol maturity 114 since its original publication. Said experience applies both to this 115 specification itself and to congestion control strategies related to 116 the use of this specification. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. Rationale 124 LCT provides transport level support for massively scalable protocols 125 using the IP multicast network service. The support that LCT 126 provides is common to a variety of very important applications, 127 including reliable content delivery and streaming applications. 129 An LCT session comprises multiple channels originating at a single 130 sender that are used for some period of time to carry packets 131 pertaining to the transmission of one or more objects that can be of 132 interest to receivers. The logic behind defining a session as 133 originating from a single sender is that this is the right 134 granularity to regulate packet traffic via congestion control. One 135 rationale for using multiple channels within the same session is that 136 there are massively scalable congestion control protocols that use 137 multiple channels per session. These congestion control protocols 138 are considered to be layered because a receiver joins and leaves 139 channels in a layered order during its participation in the session. 140 The use of layered channels is also useful for streaming 141 applications. 143 There are coding techniques that provide massively scalable 144 reliability and asynchronous delivery which are compatible with both 145 layered congestion control and with LCT. When all are combined the 146 result is a massively scalable reliable asynchronous content delivery 147 protocol that is network friendly. LCT also provides functionality 148 that can be used for other applications as well, e.g., layered 149 streaming applications. 151 LCT avoids providing functionality that is not massively scalable. 152 For example, LCT does not provide any mechanisms for sending 153 information from receivers to senders, although this does not rule 154 out protocols that both use LCT and do require sending information 155 from receivers to senders. 157 LCT includes general support for congestion control that must be 158 used. It does not, however, specify which congestion control should 159 be used. The rationale for this is that congestion control must be 160 provided by any protocol that is network friendly, and yet the 161 different applications that can use LCT will not have the same 162 requirements for congestion control. For example, a content delivery 163 protocol may strive to use all available bandwidth between receivers 164 and the sender. It must, therefore, drastically back off its rate 165 when there is competing traffic. On the other hand, a streaming 166 delivery protocol may strive to maintain a constant rate instead of 167 trying to use all available bandwidth, and it may not back off its 168 rate as fast when there is competing traffic. 170 Beyond support for congestion control, LCT provides a number of 171 fields and supports functionality commonly required by many 172 protocols. For example, LCT provides a Transmission Session ID that 173 can be used to identify which session each received packet belongs 174 to. This is important because a receiver may be joined to many 175 sessions concurrently, and thus it is very useful to be able to 176 demultiplex packets as they arrive according to which session they 177 belong to. As another example, LCT provides optional support for 178 identifying which object each packet is carrying information about. 179 Therefore, LCT provides many of the commonly used fields and support 180 for functionality required by many protocols. 182 3. Functionality 184 An LCT session consists of a set of logically grouped LCT channels 185 associated with a single sender carrying packets with LCT headers for 186 one or more objects. An LCT channel is defined by the combination of 187 a sender and an address associated with the channel by the sender. A 188 receiver joins a channel to start receiving the data packets sent to 189 the channel by the sender, and a receiver leaves a channel to stop 190 receiving data packets from the channel. 192 LCT is meant to be combined with other building blocks so that the 193 resulting overall protocol is massively scalable. Scalability refers 194 to the behavior of the protocol in relation to the number of 195 receivers and network paths, their heterogeneity, and the ability to 196 accommodate dynamically variable sets of receivers. Scalability 197 limitations can come from memory or processing requirements, or from 198 the amount of feedback control and redundant data packet traffic 199 generated by the protocol. In turn, such limitations may be a 200 consequence of the features that a complete reliable content delivery 201 or stream delivery protocol is expected to provide. 203 The LCT header provides a number of fields that are useful for 204 conveying in-band session information to receivers. One of the 205 required fields is the Transmission Session ID (TSI), which allows 206 the receiver of a session to uniquely identify received packets as 207 part of the session. Another required field is the Congestion 208 Control Information (CCI), which allows the receiver to perform the 209 required congestion control on the packets received within the 210 session. Other LCT fields provide optional but often very useful 211 additional information for the session. For example, the Transport 212 Object Identifier (TOI) identifies which object the packet contains 213 data for and flags are included for indicating the close of the 214 session and the close of sending packets for an object. Header 215 extensions can carry additional fields that for example can be used 216 for packet authentication or to convey various kinds of timing 217 information: the Sender Current Time (SCT) conveys the time when the 218 packet was sent from the sender to the receiver, the Expected 219 Residual Time (ERT) conveys the amount of time the session or 220 transmission object will be continued for, and Session Last Change 221 conveys the time when objects have been added, modified or removed 222 from the session. 224 LCT provides support for congestion control. Congestion control MUST 225 be used that conforms to [RFC2357] between receivers and the sender 226 for each LCT session. Congestion control refers to the ability to 227 adapt throughput to the available bandwidth on the path from the 228 sender to a receiver, and to share bandwidth fairly with competing 229 flows such as TCP. Thus, the total flow of packets flowing to each 230 receiver participating in an LCT session MUST NOT compete unfairly 231 with existing flow adaptive protocols such as TCP. 233 A multiple rate or a single rate congestion control protocol can be 234 used with LCT. For multiple rate protocols, a session typically 235 consists of more than one channel and the sender sends packets to the 236 channels in the session at rates that do not depend on the receivers. 237 Each receiver adjusts its reception rate during its participation in 238 the session by joining and leaving channels dynamically depending on 239 the available bandwidth to the sender independent of all other 240 receivers. Thus, for multiple rate protocols, the reception rate of 241 each receiver may vary dynamically independent of the other 242 receivers. 244 For single rate protocols, a session typically consists of one 245 channel and the sender sends packets to the channel at variable rates 246 over time depending on feedback from receivers. Each receiver 247 remains joined to the channel during its participation in the 248 session. Thus, for single rate protocols, the reception rate of each 249 receiver may vary dynamically but in coordination with all receivers. 251 Generally, a multiple rate protocol is preferable to a single rate 252 protocol in a heterogeneous receiver environment, since generally it 253 more easily achieves scalability to many receivers and provides 254 higher throughput to each individual receiver. Use of the multiple 255 rate congestion control scheme defined in [RFC3738] is RECOMMENDED. 256 Alternative multiple rate congestion control protocols are described 257 in [VIC1998],and[BYE2000]. A possible single rate congestion control 258 protocol is described in [RIZ2000]. 260 Layered coding refers to the ability to produce a coded stream of 261 packets that can be partitioned into an ordered set of layers. The 262 coding is meant to provide some form of reliability, and the layering 263 is meant to allow the receiver experience (in terms of quality of 264 playout, or overall transfer speed) to vary in a predictable way 265 depending on how many consecutive layers of packets the receiver is 266 receiving. 268 The concept of layered coding was first introduced with reference to 269 audio and video streams. For example, the information associated 270 with a TV broadcast could be partitioned into three layers, 271 corresponding to black and white, color, and HDTV quality. Receivers 272 can experience different quality without the need for the sender to 273 replicate information in the different layers. 275 The concept of layered coding can be naturally extended to reliable 276 content delivery protocols when Forward Error Correction (FEC) 277 techniques are used for coding the data stream. Descriptions of this 278 can be found in [RIZ1997a], [RIZ1997b], [GEM2000], [VIC1998] and 279 [BYE1998]. By using FEC, the data stream is transformed in such a 280 way that reconstruction of a data object does not depend on the 281 reception of specific data packets, but only on the number of 282 different packets received. As a result, by increasing the number of 283 layers a receiver is receiving from, the receiver can reduce the 284 transfer time accordingly. Using FEC to provide reliability can 285 increase scalability dramatically in comparison to other methods for 286 providing reliability. More details on the use of FEC for reliable 287 content delivery can be found in [RFC3453]. 289 Reliable protocols aim at giving guarantees on the reliable delivery 290 of data from the sender to the intended recipients. Guarantees vary 291 from simple packet data integrity to reliable delivery of a precise 292 copy of an object to all intended recipients. Several reliable 293 content delivery protocols have been built on top of IP multicast 294 using methods other than FEC, but scalability was not the primary 295 design goal for many of them. 297 Two of the key difficulties in scaling reliable content delivery 298 using IP multicast are dealing with the amount of data that flows 299 from receivers back to the sender, and the associated response 300 (generally data retransmissions) from the sender. Protocols that 301 avoid any such feedback, and minimize the amount of retransmissions, 302 can be massively scalable. LCT can be used in conjunction with FEC 303 codes or a layered codec to achieve reliability with little or no 304 feedback. 306 Protocol instantiations MAY be built by combining the LCT framework 307 with other components. A complete protocol instantiation that uses 308 LCT MUST include a congestion control protocol that is compatible 309 with LCT and that conforms to [RFC2357]. A complete protocol 310 instantiation that uses LCT MAY include a scalable reliability 311 protocol that is compatible with LCT, it MAY include an session 312 control protocol that is compatible with LCT, and it MAY include 313 other protocols such as security protocols. 315 4. Applicability 317 An LCT session comprises a logically related set of one or more LCT 318 channels originating at a single sender. The channels are used for 319 some period of time to carry packets containing LCT headers, and 320 these headers pertain to the transmission of one or more objects that 321 can be of interest to receivers. 323 LCT is most applicable for delivery of objects or streams in a 324 session of substantial length, i.e., objects or streams that range in 325 aggregate length from hundreds of kilobytes to many gigabytes, and 326 where the duration of the session is on the order of tens of seconds 327 or more. 329 As an example, an LCT session could be used to deliver a TV program 330 using three LCT channels. Receiving packets from the first LCT 331 channel could allow black and white reception. Receiving the first 332 two LCT channels could also permit color reception. Receiving all 333 three channels could allow HDTV quality reception. Objects in this 334 example could correspond to individual TV programs being transmitted. 336 As another example, a reliable LCT session could be used to reliably 337 deliver hourly-updated weather maps (objects) using ten LCT channels 338 at different rates, using FEC coding. A receiver may join and 339 concurrently receive packets from subsets of these channels, until it 340 has enough packets in total to recover the object, then leave the 341 session (or remain connected listening for session description 342 information only) until it is time to receive the next object. In 343 this case, the quality metric is the time required to receive each 344 object. 346 Before joining a session, the receivers MUST obtain enough of the 347 session description to start the session. This MUST include the 348 relevant session parameters needed by a receiver to participate in 349 the session, including all information relevant to congestion 350 control. The session description is determined by the sender, and is 351 typically communicated to the receivers out-of-band. In some cases, 352 as described later, parts of the session description that are not 353 required to initiate a session MAY be included in the LCT header or 354 communicated to a receiver out-of-band after the receiver has joined 355 the session. 357 An encoder MAY be used to generate the data that is placed in the 358 packet payload in order to provide reliability. A suitable decoder 359 is used to reproduce the original information from the packet 360 payload. There MAY be a reliability header that follows the LCT 361 header if such an encoder and decoder is used. The reliability 362 header helps to describe the encoding data carried in the payload of 363 the packet. The format of the reliability header depends on the 364 coding used, and this is negotiated out-of-band. As an example, one 365 of the FEC headers described in [RFC5052] could be used. 367 For LCT, when multiple rate congestion control is used, congestion 368 control is achieved by sending packets associated with a given 369 session to several LCT channels. Individual receivers dynamically 370 join one or more of these channels, according to the network 371 congestion as seen by the receiver. LCT headers include an opaque 372 field which MUST be used to convey congestion control information to 373 the receivers. The actual congestion control scheme to use with LCT 374 is negotiated out-of-band. Some examples of congestion control 375 protocols that may be suitable for content delivery are described in 376 [VIC1998], [BYE2000], and [RFC3738]. Other congestion controls may 377 be suitable when LCT is used for a streaming application. 379 This document does not specify and restrict the type of exchanges 380 between LCT (or any PI built on top of LCT) and an upper application. 381 Some upper APIs may use an object-oriented approach, where the only 382 possible unit of data exchanged between LCT (or any PI built on top 383 of LCT) and an application, either at a source or at a receiver, is 384 an object. Other APIs may enable a sending or receiving application 385 to exchange a subset of an object with LCT (or any PI built on top of 386 LCT), or may even follow a streaming model. These considerations are 387 outside the scope of this document. 389 4.1. Environmental Requirements and Considerations 391 LCT is intended for congestion controlled delivery of objects and 392 streams (both reliable content delivery and streaming of multimedia 393 information). 395 LCT can be used with both multicast and unicast delivery. LCT 396 requires connectivity between a sender and receivers but does not 397 require connectivity from receivers to a sender. LCT inherently 398 works with all types of networks, including LANs, WANs, Intranets, 399 the Internet, asymmetric networks, wireless networks, and satellite 400 networks. Thus, the inherent raw scalability of LCT is unlimited. 401 However, when other specific applications are built on top of LCT, 402 then these applications by their very nature may limit scalability. 403 For example, if an application requires receivers to retrieve out of 404 band information in order to join a session, or an application allows 405 receivers to send requests back to the sender to report reception 406 statistics, then the scalability of the application is limited by the 407 ability to send, receive, and process this additional data. 409 LCT requires receivers to be able to uniquely identify and 410 demultiplex packets associated with an LCT session. In particular, 411 there MUST be a Transport Session Identifier (TSI) associated with 412 each LCT session. The TSI is scoped by the IP address of the sender, 413 and the IP address of the sender together with the TSI MUST uniquely 414 identify the session. If the underlying transport is UDP as 415 described in [RFC0768], then the 16 bit UDP source port number MAY 416 serve as the TSI for the session. The TSI value MUST be the same in 417 all places it occurs within a packet. If there is no underlying TSI 418 provided by the network, transport or any other layer, then the TSI 419 MUST be included in the LCT header. 421 LCT is presumed to be used with an underlying network or transport 422 service that is a "best effort" service that does not guarantee 423 packet reception or packet reception order, and which does not have 424 any support for flow or congestion control. For example, the Any- 425 Source Multicast (ASM) model of IP multicast as defined in [RFC1112] 426 is such a "best effort" network service. While the basic service 427 provided by [RFC1112] is largely scalable, providing congestion 428 control or reliability should be done carefully to avoid severe 429 scalability limitations, especially in presence of heterogeneous sets 430 of receivers. 432 There are currently two models of multicast delivery, the Any-Source 433 Multicast (ASM) model as defined in [RFC1112] and the Source- 434 Specific Multicast (SSM) model as defined in [RFC4607]. LCT works 435 with both multicast models, but in a slightly different way with 436 somewhat different environmental concerns. When using ASM, a sender 437 S sends packets to a multicast group G, and the LCT channel address 438 consists of the pair (S,G), where S is the IP address of the sender 439 and G is a multicast group address. When using SSM, a sender S sends 440 packets to an SSM channel (S,G), and the LCT channel address 441 coincides with the SSM channel address. 443 A sender can locally allocate unique SSM channel addresses, and this 444 makes allocation of LCT channel addresses easy with SSM. To allocate 445 LCT channel addresses using ASM, the sender must uniquely chose the 446 ASM multicast group address across the scope of the group, and this 447 makes allocation of LCT channel addresses more difficult with ASM. 449 LCT channels and SSM channels coincide, and thus the receiver will 450 only receive packets sent to the requested LCT channel. With ASM, 451 the receiver joins an LCT channel by joining a multicast group G, and 452 all packets sent to G, regardless of the sender, may be received by 453 the receiver. Thus, SSM has compelling security advantages over ASM 454 for prevention of denial of service attacks. In either case, 455 receivers SHOULD use mechanisms to filter out packets from unwanted 456 sources. 458 Some networks are not amenable to some congestion control protocols 459 that could be used with LCT. In particular, for a satellite or 460 wireless network, there may be no mechanism for receivers to 461 effectively reduce their reception rate since there may be a fixed 462 transmission rate allocated to the session. 464 LCT is compatible with both IPv4 and IPv6 as no part of the packet is 465 IP version specific. 467 4.2. Delivery service models 469 LCT can support several different delivery service models. Two 470 examples are briefly described here. 472 Push service model 474 One way a push service model can be used for reliable content 475 delivery is to deliver a series of objects. For example, a 476 receiver could join the session and dynamically adapt the number 477 of LCT channels the receiver is joined to until enough packets 478 have been received to reconstruct an object. After reconstructing 479 the object the receiver may stay in the session and wait for the 480 transmission of the next object. 482 The push model is particularly attractive in satellite networks 483 and wireless networks. In these cases, a session may consist of 484 one fixed rate LCT channel. 486 A push service model can be used for example for reliable delivery 487 of a large object such as a 100 GB file. The sender could send a 488 Session Description announcement to a control channel and 489 receivers could monitor this channel and join a session whenever a 490 Session Description of interest arrives. Upon receipt of the 491 Session Description, each receiver could join the session to 492 receive packets until enough packets have arrived to reconstruct 493 the object, at which point the receiver could report back to the 494 sender that its reception was completed successfully. The sender 495 could decide to continue sending packets for the object to the 496 session until all receivers have reported successful 497 reconstruction or until some other condition has been satisfied. 499 There are several features ALC provides to support the push model. 500 For example, the sender can optionally include an Expected 501 Residual Time (ERT) in the packet header extension that indicates 502 the expected remaining time of packet transmission for either the 503 single object carried in the session or for the object identified 504 by the Transmission Object Identifier (TOI) if there are multiple 505 objects carried in the session. This can be used by receivers to 506 determine if there is enough time remaining in the session to 507 successfully receive enough additional packets to recover the 508 object. If for example there is not enough time, then the push 509 application may have receivers report back to the sender to extend 510 the transmission of packets for the object for enough time to 511 allow the receivers to obtain enough packets to reconstruct the 512 object. The sender could then include an ERT based on the 513 extended object transmission time in each subsequent packet header 514 for the object. As other examples, the LCT header optionally can 515 contain a Close Session flag that indicates when the sender is 516 about to end sending packet to the session and a Close Object flag 517 that indicates when the sender is about to end sending packets to 518 the session for the object identified by the Transmission Object 519 ID. However, these flags are not a completely reliable mechanism 520 and thus the Close Session flag should only be used as a hint of 521 when the session is about to close and the Close Object flag 522 should only be used as a hint of when transmission of packets for 523 the object is about to end. 525 On-demand content delivery model 527 For an on-demand content delivery service model, senders typically 528 transmit for some given time period selected to be long enough to 529 allow all the intended receivers to join the session and recover 530 the object. For example a popular software update might be 531 transmitted using LCT for several days, even though a receiver may 532 be able to complete the download in one hour total of connection 533 time, perhaps spread over several intervals of time. In this case 534 the receivers join the session at any point in time when it is 535 active. Receivers leave the session when they have received 536 enough packets to recover the object. The receivers, for example, 537 obtain a Session Description by contacting a web server. 539 In this case the receivers join the session, and dynamically adapt 540 the number of LCT channels they subscribe to according to the 541 available bandwidth. Receivers then drop from the session when 542 they have received enough packets to recover the object. 544 As an example, assume that an object is 50 MB. The sender could 545 send 1 KB packets to the first LCT channel at 50 packets per 546 second, so that receivers using just this LCT channel could 547 complete reception of the object in 1,000 seconds in absence of 548 loss, and would be able to complete reception even in presence of 549 some substantial amount of losses with the use of coding for 550 reliability. Furthermore, the sender could use a number of LCT 551 channels such that the aggregate rate of 1 KB packets to all LCT 552 channels is 1,000 packets per second, so that a receiver could be 553 able to complete reception of the object in as little 50 seconds 554 (assuming no loss and that the congestion control mechanism 555 immediately converges to the use of all LCT channels). 557 Other service models 559 There are many other delivery service models that LCT can be used 560 for that are not covered above. As examples, a live streaming or 561 an on- demand archival content streaming service model. A 562 description of the many potential applications, the appropriate 563 delivery service model, and the additional mechanisms to support 564 such functionalities when combined with LCT is beyond the scope of 565 this document. This document only attempts to describe the 566 minimal common scalable elements to these diverse applications 567 using LCT as the delivery transport. 569 4.3. Congestion Control 571 The specific congestion control protocol to be used for LCT sessions 572 depends on the type of content to be delivered. While the general 573 behavior of the congestion control protocol is to reduce the 574 throughput in presence of congestion and gradually increase it in the 575 absence of congestion, the actual dynamic behavior (e.g. response to 576 single losses) can vary. 578 It is RECOMMENDED that the congestion control mechanism specified in 579 [RFC3738] be used. Some alternative possible congestion control 580 protocols for reliable content delivery using LCT are described in 581 [VIC1998] and [BYE2000]. Different delivery service models might 582 require different congestion control protocols. 584 5. Packet Header Fields 586 Packets sent to an LCT session MUST include an "LCT header". The LCT 587 header format is described below. 589 Other building blocks MAY describe some of the same fields as 590 described for the LCT header. It is RECOMMENDED that protocol 591 instantiations using multiple building blocks include shared fields 592 at most once in each packet. Thus, for example, if another building 593 block is used with LCT that includes the optional Expected Residual 594 Time field, then the Expected Residual Time field SHOULD be carried 595 in each packet at most once. 597 The position of the LCT header within a packet MUST be specified by 598 any protocol instantiation that uses LCT. 600 5.1. LCT header format 602 The LCT header is of variable size, which is specified by a length 603 field in the third byte of the header. In the LCT header, all 604 integer fields are carried in "big-endian" or "network order" format, 605 that is, most significant byte (octet) first. Bits designated as 606 "padding" or "reserved" (r) MUST by set to 0 by senders and ignored 607 by receivers in this version of the specification. Unless otherwise 608 noted, numeric constants in this specification are in decimal (base 609 10). 611 The format of the default LCT header is depicted in Figure 1. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | V | C |PSI|S| O |H|Res|A|B| HDR_LEN | Codepoint (CP)| 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Congestion Control Information (CCI, length = 32*(C+1) bits) | 619 | ... | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Transport Session Identifier (TSI, length = 32*S+16*H bits) | 622 | ... | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Transport Object Identifier (TOI, length = 32*O+16*H bits) | 625 | ... | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Header Extensions (if applicable) | 628 | ... | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 1: Default LCT header format 632 The function and length of each field in the default LCT header is 633 the following. Fields marked as "1" mean that the corresponding bits 634 MUST be set to "1" by the sender. Fields marked as "r" or "0" mean 635 that the corresponding bits MUST be set to "0" by the sender. 637 LCT version number (V): 4 bits 639 Indicates the LCT version number. The LCT version number for this 640 specification is 1. 642 Congestion control flag (C): 2 bits 644 C=0 indicates the Congestion Control Information (CCI) field is 645 32-bits in length. C=1 indicates the CCI field is 64-bits in 646 length. C=2 indicates the CCI field is 96-bits in length. C=3 647 indicates the CCI field is 128-bits in length. 649 Protocol Specific Indication (PSI): 2 bits 651 The usage of these bits, if any, is specific to each Protocol 652 Instantiation that uses the LCT Building Block. If no Protocol 653 Instantiation-specific usage of these bits is defined, then a 654 sender MUST set them to zero and a receiver MUST ignore these 655 bits. 657 Transport Session Identifier flag (S): 1 bit 659 This is the number of full 32-bit words in the TSI field. The TSI 660 field is 32*S + 16*H bits in length, i.e. the length is either 0 661 bits, 16 bits, 32 bits, or 48 bits. 663 Transport Object Identifier flag (O): 2 bits 665 This is the number of full 32-bit words in the TOI field. The TOI 666 field is 32*O + 16*H bits in length, i.e., the length is either 0 667 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 668 bits. 670 Half-word flag (H): 1 bit 672 The TSI and the TOI fields are both multiples of 32-bits plus 16*H 673 bits in length. This allows the TSI and TOI field lengths to be 674 multiples of a half-word (16 bits), while ensuring that the 675 aggregate length of the TSI and TOI fields is a multiple of 32- 676 bits. 678 Reserved (Res): 2 bits 680 These bits are reserved. In this version of the specification, 681 they MUST be set to zero by senders and MUST be ignored by 682 receivers. 684 Close Session flag (A): 1 bit 686 Normally, A is set to 0. The sender MAY set A to 1 when 687 termination of transmission of packets for the session is 688 imminent. A MAY be set to 1 in just the last packet transmitted 689 for the session, or A MAY be set to 1 in the last few seconds of 690 packets transmitted for the session. Once the sender sets A to 1 691 in one packet, the sender SHOULD set A to 1 in all subsequent 692 packets until termination of transmission of packets for the 693 session. A received packet with A set to 1 indicates to a 694 receiver that the sender will immediately stop sending packets for 695 the session. When a receiver receives a packet with A set to 1 696 the receiver SHOULD assume that no more packets will be sent to 697 the session. 699 Close Object flag (B): 1 bit 701 Normally, B is set to 0. The sender MAY set B to 1 when 702 termination of transmission of packets for an object is imminent. 703 If the TOI field is in use and B is set to 1 then termination of 704 transmission for the object identified by the TOI field is 705 imminent. If the TOI field is not in use and B is set to 1 then 706 termination of transmission for the one object in the session 707 identified by out-of-band information is imminent. B MAY be set 708 to 1 in just the last packet transmitted for the object, or B MAY 709 be set to 1 in the last few seconds packets transmitted for the 710 object. Once the sender sets B to 1 in one packet for a 711 particular object, the sender SHOULD set B to 1 in all subsequent 712 packets for the object until termination of transmission of 713 packets for the object. A received packet with B set to 1 714 indicates to a receiver that the sender will immediately stop 715 sending packets for the object. When a receiver receives a packet 716 with B set to 1 then it SHOULD assume that no more packets will be 717 sent for the object to the session. 719 LCT header length (HDR_LEN): 8 bits 721 Total length of the LCT header in units of 32-bit words. The 722 length of the LCT header MUST be a multiple of 32-bits. This 723 field can be used to directly access the portion of the packet 724 beyond the LCT header, i.e., to the first other header if it 725 exists, or to the packet payload if it exists and there is no 726 other header, or to the end of the packet if there are no other 727 headers or packet payload. 729 Codepoint (CP): 8 bits 731 An opaque identifier which is passed to the packet payload decoder 732 to convey information on the codec being used for the packet 733 payload. The mapping between the codepoint and the actual codec 734 is defined on a per session basis and communicated out-of-band as 735 part of the session description information. The use of the CP 736 field is similar to the Payload Type (PT) field in RTP headers as 737 described in [RFC1889]. 739 Congestion Control Information (CCI): 32, 64, 96 or 128 bits 741 Used to carry congestion control information. For example, the 742 congestion control information could include layer numbers, 743 logical channel numbers, and sequence numbers. This field is 744 opaque for the purpose of this specification. 746 This field MUST be 32 bits if C=0. 748 This field MUST be 64 bits if C=1. 750 This field MUST be 96 bits if C=2. 752 This field MUST be 128 bits if C=3. 754 Transport Session Identifier (TSI): 0, 16, 32 or 48 bits 756 The TSI uniquely identifies a session among all sessions from a 757 particular sender. The TSI is scoped by the IP address of the 758 sender, and thus the IP address of the sender and the TSI together 759 uniquely identify the session. Although a TSI in conjunction with 760 the IP address of the sender always uniquely identifies a session, 761 whether or not the TSI is included in the LCT header depends on 762 what is used as the TSI value. If the underlying transport is 763 UDP, then the 16 bit UDP source port number MAY serve as the TSI 764 for the session. If the TSI value appears multiple times in a 765 packet then all occurrences MUST be the same value. If there is 766 no underlying TSI provided by the network, transport or any other 767 layer, then the TSI MUST be included in the LCT header. 769 The TSI MUST be unique among all sessions served by the sender 770 during the period when the session is active, and for a large 771 period of time preceding and following when the session is active. 772 A primary purpose of the TSI is to prevent receivers from 773 inadvertently accepting packets from a sender that belong to 774 sessions other than the sessions receivers are subscribed to. For 775 example, suppose a session is deactivated and then another session 776 is activated by a sender and the two sessions use an overlapping 777 set of channels. A receiver that connects and remains connected 778 to the first session during this sender activity could possibly 779 accept packets from the second session as belonging to the first 780 session if the TSI for the two sessions were identical. The 781 mapping of TSI field values to sessions is outside the scope of 782 this document and is to be done out-of-band. 784 The length of the TSI field is 32*S + 16*H bits. Note that the 785 aggregate lengths of the TSI field plus the TOI field is a 786 multiple of 32 bits. 788 Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 789 bits. 791 This field indicates which object within the session this packet 792 pertains to. For example, a sender might send a number of files 793 in the same session, using TOI=0 for the first file, TOI=1 for the 794 second one, etc. As another example, the TOI may be a unique 795 global identifier of the object that is being transmitted from 796 several senders concurrently, and the TOI value may be the output 797 of a hash function applied to the object. The mapping of TOI 798 field values to objects is outside the scope of this document and 799 is to be done out-of-band. The TOI field MUST be used in all 800 packets if more than one object is to be transmitted in a session, 801 i.e. the TOI field is either present in all the packets of a 802 session or is never present. 804 The length of the TOI field is 32*O + 16*H bits. Note that the 805 aggregate lengths of the TSI field plus the TOI field is a 806 multiple of 32 bits. 808 5.2. Header-Extension Fields 810 5.2.1. General 812 Header Extensions are used in LCT to accommodate optional header 813 fields that are not always used or have variable size. Examples of 814 the use of Header Extensions include: 816 o Extended-size versions of already existing header fields. 818 o Sender and Receiver authentication information. 820 o Transmission of timing information. 822 The presence of Header Extensions can be inferred by the LCT header 823 length (HDR_LEN): if HDR_LEN is larger than the length of the 824 standard header then the remaining header space is taken by Header 825 Extension fields. 827 If present, Header Extensions MUST be processed to ensure that they 828 are recognized before performing any congestion control procedure or 829 otherwise accepting a packet. The default action for unrecognized 830 header extensions is to ignore them. This allows the future 831 introduction of backward-compatible enhancements to LCT without 832 changing the LCT version number. Non backward-compatible header 833 extensions CANNOT be introduced without changing the LCT version 834 number. 836 There are two formats for Header Extension fields, as depicted in 837 Figure 2. The first format is used for variable-length extensions, 838 with Header Extension Type (HET) values between 0 and 127. The 839 second format is used for fixed length (one 32-bit word) extensions, 840 using HET values from 127 to 255. 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | HET (<=127) | HEL | | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 847 . . 848 . Header Extension Content (HEC) . 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | HET (>=128) | Header Extension Content (HEC) | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Figure 2: Format of additional headers 859 The explanation of each sub-field is the following: 861 Header Extension Type (HET): 8 bits 863 The type of the Header Extension. This document defines a number 864 of possible types. Additional types may be defined in future 865 versions of this specification. HET values from 0 to 127 are used 866 for variable-length Header Extensions. HET values from 128 to 255 867 are used for fixed-length 32-bit Header Extensions. 869 Header Extension Length (HEL): 8 bits 871 The length of the whole Header Extension field, expressed in 872 multiples of 32-bit words. This field MUST be present for 873 variable-length extensions (HET between 0 and 127) and MUST NOT be 874 present for fixed-length extensions (HET between 128 and 255). 876 Header Extension Content (HEC): variable length 878 The content of the Header Extension. The format of this sub- 879 field depends on the Header Extension type. For fixed-length 880 Header Extensions, the HEC is 24 bits. For variable-length Header 881 Extensions, the HEC field has variable size, as specified by the 882 HEL field. Note that the length of each Header Extension field 883 MUST be a multiple of 32 bits. Also note that the total size of 884 the LCT header, including all Header Extensions and all optional 885 header fields, cannot exceed 255 32-bit words. 887 The following LCT Header Extensions are defined by this 888 specification: 890 EXT_NOP, HET=0 No-Operation extension. The information present in 891 this extension field MUST be ignored by receivers. 893 EXT_AUTH, HET=1 Packet authentication extension Information used to 894 authenticate the sender of the packet. The format of 895 this Header Extension and its processing is outside the 896 scope of this document and is to be communicated out- 897 of-band as part of the session description. 899 It is RECOMMENDED that senders provide some form of 900 packet authentication. If EXT_AUTH is present, 901 whatever packet authentication checks that can be 902 performed immediately upon reception of the packet 903 SHOULD be performed before accepting the packet and 904 performing any congestion control-related action on it. 906 Some packet authentication schemes impose a delay of 907 several seconds between when a packet is received and 908 when the packet is fully authenticated. Any congestion 909 control related action that is appropriate MUST NOT be 910 postponed by any such full packet authentication. 912 EXT_TIME, HET=2 Time Extension. This extension is used to carry 913 several types of timing information. It includes 914 general purpose timing information, namely the Sender 915 Current Time (SCT), Expected Residual Time (ERT) and 916 Sender Last Change (SLC) time extensions described in 917 the present document. It can also be used for timing 918 information with narrower applicability (e.g. defined 919 for a single Protocol Instantiation); in this case it 920 will be described in a separate document. 922 All senders and receivers implementing LCT MUST support the EXT_NOP 923 Header Extension and MUST recognize EXT_AUTH and EXT_TIME, but are 924 not required to be able to parse their content. 926 5.2.2. EXT_TIME Header Extension 928 This section defines the timing header extensions with general 929 applicability. The time values carried in this header extension are 930 related to the server's wall clock. The server MUST maintain 931 consistent relative time during a session (i.e. insignificant clock 932 drift). For some applications, system or even global synchronization 933 of server wall clock may be desirable, such as using the Network Time 934 Protocol (NTP) [RFC1305] to ensure actual time relative to 00:00 935 hours GMT, January 1st 1900. Such session-external synchronization 936 is outside the scope of this document. 938 The EXT_TIME Header Extension uses the format depicted in Figure 3 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | HET = 2 | HEL >= 1 | Use (bit field) | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | first time value | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 ... (other time values (optional) ... 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 Figure 3: EXT_TIME Header Extension format 952 The "Use" bit field indicates the semantic of the following 32 bit 953 time value(s). 955 It is divided into two parts: 957 o 8 bits are reserved for general purpose timing information. These 958 information are applicable to any protocol which makes use of LCT. 960 o 8 bits are reserved for PI specific timing information. These 961 information are out of the scope of this document. 963 The format of the "Use" bit field is depicted in Figure 4. 965 2 3 966 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 967 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 968 |SCT|SCT|ERT|SLC| reserved | PI-specific | 969 |Hi |Low| | | by LCT | use | 970 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 972 Figure 4: "Use" bit field format 974 Several "time value" fields MAY be present in a given EXT_TIME Header 975 Extension, as specified in the "Use-field". When several "time 976 value" fields are present, they MUST appear in the order specified by 977 the associated flag position in the "Use-field": first SCT-High (if 978 present), then SCT-Low (if present), then ERT (if present), then SLC 979 (if present). Receivers SHOULD ignore additional fields within the 980 EXT_TIME Header Extension which they do not support. 982 The fields for the general purpose EXT_TIME timing information are: 984 Sender Current Time (SCT): SCT High flag, SCT Low flag, corresponding 985 time value (one or two 32 bit words) 987 This timing information represents the current time at the sender 988 at the time this packet was transmitted. 990 When the SCT-High flag is set, the associated 32 bit time value 991 provides an unsigned integer representing the time in seconds of 992 the sender's wall clock. In the particular case where NTP is 993 used, these 32 bits provide an unsigned integer representing the 994 time in seconds relative to 00:00 hours GMT, January 1st 1900, 995 (i.e. the most significant 32 bits of a full 64 bit NTP time 996 value). In that case, handling of wraparound of the 32 bit time 997 is outside the scope of NTP and LCT. 999 When the SCT-Low flag is set, the associated 32 bit time value 1000 provides an unsigned integer representing a multiple of 1/2^^32 of 1001 a second, in order to allow sub-second precision. When the SCT- 1002 Low flag is set, the SCT-High flag MUST be set too. In the 1003 particular case where NTP is used, these 32 bits provide the 32 1004 least significant bits of a 64 bit NTP timestamp. 1006 Expected Residual Time (ERT): ERT flag, corresponding 32 bit time 1007 value 1009 This timing information represents the sender expected residual 1010 transmission time for the current session or for the transmission 1011 of the current object. If the packet containing the ERT timing 1012 information also contains the TOI field, then ERT refers to the 1013 object corresponding to the TOI field, otherwise it refers to the 1014 session. 1016 When the ERT flag is set, it it expressed as a number of seconds. 1017 The 32 bits provide an unsigned integer representing this number 1018 of seconds. 1020 Session Last Changed (SLC): SLC flag, corresponding 32 bit time value 1022 The Session Last Changed time value is the server wall clock time, 1023 in seconds, at which the last change to session data occurred. 1024 That is, it expresses the time at which the last (most recent) 1025 Transport Object addition, modification or removal was made for 1026 the delivery session. In the case of modifications and additions 1027 it indicates that new data will be transported which was not 1028 transported prior to this time. In the case of removals, SLC 1029 indicates that some prior data will no longer be transported. 1031 When the SLC flag is set, the associated 32 bit time value 1032 provides an unsigned integer representing a time in second. In 1033 the particular case where NTP is used, these 32 bits provide an 1034 unsigned integer representing the time in seconds relative to 1035 00:00 hours GMT, January 1st 1900, (i.e. the most significant 32 1036 bits of a full 64 bit NTP time value). In that case, handling of 1037 wraparound of the 32 bit time is outside the scope of NTP and LCT. 1039 In some cases, it may be appropriate that a packet containing a 1040 EXT_TIME Header Extension with an SLC information also contain a 1041 SCT-High information. 1043 Reserved by LCT for future use (4 bits): 1045 In this version of the specification, these bits MUST be set to 1046 zero by senders and MUST be ignored by receivers. 1048 PI-specific use (8 bits): 1050 These bits are out of the scope of this document. The bits that 1051 are not specified by the PI built on top of LCT SHOULD be set to 1052 zero. 1054 The total EXT_TIME length is carried in the HEL, since this Header 1055 Extension is of variable length. It also enables clients to skip 1056 this Header Extension altogether if not supported (but recognized). 1058 6. Operations 1060 6.1. Sender Operation 1062 Before joining an LCT session a receiver MUST obtain a session 1063 description. The session description MUST include: 1065 o The sender IP address; 1067 o The number of LCT channels; 1069 o The addresses and port numbers used for each LCT channel; 1071 o The Transport Session ID (TSI) to be used for the session; 1073 o Enough information to determine the congestion control protocol 1074 being used; 1076 o Enough information to determine the packet authentication scheme 1077 being used if it is being used. 1079 The session description could also include, but is not limited to: 1081 o The data rates used for each LCT channel; 1083 o The length of the packet payload; 1085 o The mapping of TOI value(s) to objects for the session; 1087 o Any information that is relevant to each object being transported, 1088 such as when it will be available within the session, for how 1089 long, and the length of the object; 1091 Protocol instantiations using LCT MAY place additional requirements 1092 on what must be included in the session description. For example, a 1093 protocol instantiation might require that the data rates for each 1094 channel, or the mapping of TOI value(s) to objects for the session, 1095 or other information related to other headers that might be required 1096 to be included in the session description. 1098 The session description could be in a form such as SDP as defined in 1099 [RFC4566], or another format appropriate to a particular application. 1100 It might be carried in a session announcement protocol such as SAP as 1101 defined in [RFC2974], obtained using a proprietary session control 1102 protocol, located on a Web page with scheduling information, or 1103 conveyed via E-mail or other out-of-band methods. Discussion of 1104 session description format, and distribution of session descriptions 1105 is beyond the scope of this document. 1107 Within an LCT session, a sender using LCT transmits a sequence of 1108 packets, each in the format defined above. Packets are sent from a 1109 sender using one or more LCT channels which together constitute a 1110 session. Transmission rates may be different in different channels 1111 and may vary over time. The specification of the other building 1112 block headers and the packet payload used by a complete protocol 1113 instantiation using LCT is beyond the scope of this document. This 1114 document does not specify the order in which packets are transmitted, 1115 nor the organization of a session into multiple channels. Although 1116 these issues affect the efficiency of the protocol, they do not 1117 affect the correctness nor the inter-operability of LCT between 1118 senders and receivers. 1120 Several objects can be carried within the same LCT session. In this 1121 case, each object MUST be identified by a unique TOI. Objects MAY be 1122 transmitted sequentially, or they MAY be transmitted concurrently. 1123 It is good practice to only send objects concurrently in the same 1124 session if the receivers that participate in that portion of the 1125 session have interest in receiving all the objects. The reason for 1126 this is that it wastes bandwidth and networking resources to have 1127 receivers receive data for objects that they have no interest in. 1129 Typically, the sender(s) continues to send packets in a session until 1130 the transmission is considered complete. The transmission may be 1131 considered complete when some time has expired, a certain number of 1132 packets have been sent, or some out-of-band signal (possibly from a 1133 higher level protocol) has indicated completion by a sufficient 1134 number of receivers. 1136 For the reasons mentioned above, this document does not pose any 1137 restriction on packet sizes. However, network efficiency 1138 considerations recommend that the sender uses an as large as possible 1139 packet payload size, but in such a way that packets do not exceed the 1140 network's maximum transmission unit size (MTU), or when fragmentation 1141 coupled with packet loss might introduce severe inefficiency in the 1142 transmission. 1144 It is recommended that all packets have the same or very similar 1145 sizes, as this can have a severe impact on the effectiveness of 1146 congestion control schemes such as the ones described in [VIC1998], 1147 [BYE2000], and [RFC3738]. A sender of packets using LCT MUST 1148 implement the sender- side part of one of the congestion control 1149 schemes that is in accordance with [RFC2357] using the Congestion 1150 Control Information field provided in the LCT header, and the 1151 corresponding receiver congestion control scheme is to be 1152 communicated out-of-band and MUST be implemented by any receivers 1153 participating in the session. 1155 6.2. Receiver Operation 1157 Receivers can operate differently depending on the delivery service 1158 model. For example, for an on demand service model, receivers may 1159 join a session, obtain the necessary packets to reproduce the object, 1160 and then leave the session. As another example, for a streaming 1161 service model, a receiver may be continuously joined to a set of LCT 1162 channels to download all objects in a session. 1164 To be able to participate in a session, a receiver MUST obtain the 1165 relevant session description information as listed in Section 6.1. 1167 If packet authentication information is present in an LCT header, it 1168 SHOULD be used as specified in Section 5.2. To be able to be a 1169 receiver in a session, the receiver MUST be able to process the LCT 1170 header. The receiver MUST be able to discard, forward, store or 1171 process the other headers and the packet payload. If a receiver is 1172 not able to process a LCT header, it MUST drop from the session. 1174 To be able to participate in a session, a receiver MUST implement the 1175 congestion control protocol specified in the session description 1176 using the Congestion Control Information field provided in the LCT 1177 header. If a receiver is not able to implement the congestion 1178 control protocol used in the session, it MUST NOT join the session. 1179 When the session is transmitted on multiple LCT channels, receivers 1180 MUST initially join channels according to the specified startup 1181 behavior of the congestion control protocol. For a multiple rate 1182 congestion control protocol that uses multiple channels, this 1183 typically means that a receiver will initially join only a minimal 1184 set of LCT channels, possibly a single one, that in aggregate are 1185 carrying packets at a low rate. This rule has the purpose of 1186 preventing receivers from starting at high data rates. 1188 Several objects can be carried either sequentially or concurrently 1189 within the same LCT session. In this case, each object is identified 1190 by a unique TOI. Note that even if a server stops sending packets 1191 for an old object before starting to transmit packets for a new 1192 object, both the network and the underlying protocol layers can cause 1193 some reordering of packets, especially when sent over different LCT 1194 channels, and thus receivers SHOULD NOT assume that the reception of 1195 a packet for a new object means that there are no more packets in 1196 transit for the previous one, at least for some amount of time. 1198 A receiver MAY be concurrently joined to multiple LCT sessions from 1199 one or more senders. The receiver MUST perform congestion control on 1200 each such LCT session. If the congestion control protocol allows the 1201 receiver some flexibility in terms of its actions within a session 1202 then the receiver MAY make choices to optimize the packet flow 1203 performance across the multiple LCT sessions, as long as the receiver 1204 still adheres to the congestion control rules for each LCT session 1205 individually. 1207 7. Requirements from Other Building Blocks 1209 As described in [RFC3048], LCT is a building block that is intended 1210 to be used, in conjunction with other building blocks, to help 1211 specify a protocol instantiation. A congestion control building 1212 block that uses the Congestion Control information field within the 1213 LCT header MUST be used by any protocol instantiation that uses LCT, 1214 and other building blocks MAY also be used, such as a reliability 1215 building block. 1217 The congestion control MUST be applied to the LCT session as an 1218 entity, i.e., over the aggregate of the traffic carried by all of the 1219 LCT channels associated with the LCT session. The Congestion Control 1220 Information field in the LCT header is an opaque field that is 1221 reserved to carry information related to congestion control. There 1222 MAY also be congestion control Header Extension fields that carry 1223 additional information related to congestion control. 1225 The particular layered encoder and congestion control protocols used 1226 with LCT have an impact on the performance and applicability of LCT. 1227 For example, some layered encoders used for video and audio streams 1228 can produce a very limited number of layers, thus providing a very 1229 coarse control in the reception rate of packets by receivers in a 1230 session. When LCT is used for reliable data transfer, some FEC 1231 codecs are inherently limited in the size of the object they can 1232 encode, and for objects larger than this size the reception overhead 1233 on the receivers can grow substantially. 1235 A more in-depth description of the use of FEC in Reliable Multicast 1236 Transport (RMT) protocols is given in [RFC3453]. Some of the FEC 1237 codecs that MAY be used in conjunction with LCT for reliable content 1238 delivery are specified in [RFC5052]. The Codepoint field in the LCT 1239 header is an opaque field that can be used to carry information 1240 related to the encoding of the packet payload. 1242 LCT also requires receivers to obtain a session description, as 1243 described in Section 6.1 The session description could be in a form 1244 such as SDP as defined in [RFC4566], or another format appropriate to 1245 a particular application and may be distributed with SAP as defined 1246 in [RFC2974], using HTTP, or in other ways. It is RECOMMENDED that 1247 an authentication protocol be used to deliver the session description 1248 to receivers to ensure the correct session description arrives. 1250 It is RECOMMENDED that LCT implementors use some packet 1251 authentication scheme to protect the protocol from attacks. An 1252 example of a possibly suitable scheme is described in [RIZ1997a]. 1254 Some protocol instantiations that use LCT MAY use building blocks 1255 that require the generation of feedback from the receivers to the 1256 sender. However, the mechanism for doing this is outside the scope 1257 of LCT. 1259 8. Security Considerations 1261 LCT is a Building Block as defined in [RFC3048] and as such does not 1262 define a complete protocol. Protocol Instantiations which use the 1263 LCT building block MUST address the security requirements described 1264 in the following sections. For an example, see 1265 [I-D.ietf-rmt-pi-alc-revised] 1267 8.1. Denial-of-service attacks 1269 Protocol Instantiations using the LCT Building Block are especially 1270 vulnerable to denial-of-service attacks by attackers which try to 1271 confuse any congestion control mechanism, or send forged packets to 1272 the session which would prevent successful reconstruction or cause 1273 inaccurate reconstruction of large portions of an object by 1274 receivers. 1276 LCT is particularly affected by such an attack since many receivers 1277 may receive the same forged packet. 1279 8.2. Forged session description attacks 1281 Another vulnerability of Protocol Instantiations based on LCT is the 1282 potential of receivers obtaining an incorrect session description for 1283 the session. The consequences of this could be that legitimate 1284 receivers with the wrong session description are unable to correctly 1285 receive the session content, or that receivers inadvertently try to 1286 receive at a much higher rate than they are capable of, thereby 1287 disrupting traffic in portions of the network. 1289 8.3. Congestion control issues 1291 A receiver with an incorrect implementation of a multiple rate 1292 congestion control building block may affect health of the network in 1293 the path between the sender and the receiver, and may also affect the 1294 reception rates of other receivers joined to the session. 1296 Protocol Instantiations could address this issue by requiring 1297 receivers to identify themselves as legitimate before they receive 1298 the Session Description needed to join the session. 1300 8.4. Time synchronizartion 1302 The rudimentary time synchronization features made possible by the 1303 SCT mechanism, or the ERT signaling feature can both be subject to 1304 attacks. Indeed an attacker can easily de-synchronize clients, 1305 sending erroneous SCT information, or mount a DoS attack by informing 1306 all clients that the session (resp. a particular object) is about to 1307 be closed. 1309 Protocol Instantiations could address this issue by taking measures 1310 to prevent receivers from accepting incorrect packets, e.g. by using 1311 a source authentication and content integrity mechanism. 1313 9. IANA Considerations 1315 9.1. Namespace declaration for LCT Header Extension Types 1317 This document defines four name-spaces for registration of LCT Header 1318 Extensions Types named: 1319 ietf:rmt:lct:headerExtensionTypes:variableLength:ietf 1320 ietf:rmt:lct:headerExtensionTypes:variableLength:any 1321 ietf:rmt:lct:headerExtensionTypes:fixedLength:ietf 1322 and 1323 ietf:rmt:lct:headerExtensionTypes:fixedLength:any 1325 The values which can be assigned in each namespace and the assignment 1326 requirements as per [RFC5226] are shown in the following table: 1328 +----------------------------------+-----------+----------------------+ 1329 |ietf:rmt:lct:headerExtensionTypes:|Value range| Assignment | 1330 +----------------------------------+-----------+----------------------+ 1331 | variableLength:ietf | 0-63 |IETF Review | 1332 | variableLength:any | 64-127 |Specification required| 1333 | fixedLength:ietf | 128-191 |IETF Review | 1334 | fixedLength:any | 192-255 |Specification required| 1335 +----------------------------------+-----------+----------------------+ 1337 Note that the previous Experimental version of this specification 1338 reserved values in the ranges [64, 127] and [192, 255] for Protocol 1339 Instantiation-specific LCT Header Extensions. In the interests of 1340 simplification and since there were no overlapping allocations of 1341 these LCT Header Extension Type values by Protocol Instantiations, 1342 this document specifies a single flat space for LCT Header Extension 1343 Types. 1345 9.2. LCT Header Extension Type registration 1347 This document registers two values in the namespace "ietf:rmt:lct: 1348 headerExtensionTypes:variableLength" as follows: 1350 +-------+----------+--------------------+ 1351 | Value | Name | Reference | 1352 +-------+----------+--------------------+ 1353 | 0 | EXT_NOP | This specification | 1354 | | | | 1355 | 1 | EXT_AUTH | This specification | 1356 | | | | 1357 | 2 | EXT_TIME | This specification | 1358 +-------+----------+--------------------+ 1360 10. Acknowledgments 1362 This specification is substantially based on RFC3451 [RFC3451] and 1363 thus credit for the authorship of this document is primarily due to 1364 the authors of RFC3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, 1365 Luigi Rizzo and Jon Crowcroft. Bruce Lueckenhoff, Hayder Radha and 1366 Justin Chapweske also contributed to RFC3451. Additional thanks are 1367 due to Vincent Roca, Rod Walsh and Toni Paila for contributions to 1368 this update to Proposed Standard. 1370 11. Changes from RFC3451 1372 This section summarises the changes that were made from the 1373 Experimental version of this specification published as RFC3451 1374 [RFC3451]: 1376 o Update all references to the obsoleted RFC 2068 to RFC 2616 1378 o Removed the 'Statement of Intent' from the introduction (The 1379 statement of intent was meant to clarify the "Experimental" status 1380 of RFC3451.) 1382 o Inclusion of material from ALC which is applicable in the more 1383 general LCT context 1385 o Creation of an IANA registry for LCT Header Extensions 1387 o Allocation of the 2 'reserved' bits in the LCT header as "Protocol 1388 Specific Indication" - usage to be defined by protocol 1389 instantiations 1391 o Removal of the Sender Current Time and Expected Residual Time LCT 1392 header fields. 1394 o Inclusion of a new Header Extension, EXT_TIME, to replace the SCT 1395 and ERT and provide for future extension of timing capabilities. 1397 12. References 1399 12.1. Normative References 1401 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1402 August 1980. 1404 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1405 RFC 1112, August 1989. 1407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1408 Requirement Levels", BCP 14, RFC 2119, March 1997. 1410 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 1411 Correction (FEC) Building Block", RFC 5052, August 2007. 1413 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1414 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1415 May 2008. 1417 12.2. Informative References 1419 [BYE1998] Byers, J., Luby, M., Mitzenmacher, M., and A. Rege, 1420 "Fountain Approach to Reliable Distribution of Bulk Data", 1421 Proceedings ACM SIGCOMM'98, Vancouver, Canada , 1422 September 1998. 1424 [BYE2000] Byers, J., Frumin, M., Horn, G., Luby, M., Mitzenmacher, 1425 M., Rotter, A., and W. Shaver, "FLID-DL: Congestion 1426 Control for Layered Multicast", Proceedings of Second 1427 International Workshop on Networked Group 1428 Communications (NGC 2000), Palo Alto, CA , 1429 November 2000. 1431 [GEM2000] Gemmell, J., Schooler, E., and J. Gray, "Fcast Multicast 1432 File Distribution", IEEE Network, Vol. 14, No. 1, pp. 1433 58-68 , January 2000. 1435 [I-D.ietf-rmt-pi-alc-revised] 1436 "". 1438 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 1439 Jacobson, "RTP: A Transport Protocol for Real-Time 1440 Applications", RFC 1889, January 1996. 1442 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1443 Criteria for Evaluating Reliable Multicast Transport and 1444 Application Protocols", RFC 2357, June 1998. 1446 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1447 Announcement Protocol", RFC 2974, October 2000. 1449 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1450 Floyd, S., and M. Luby, "Reliable Multicast Transport 1451 Building Blocks for One-to-Many Bulk-Data Transfer", 1452 RFC 3048, January 2001. 1454 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 1455 Reliable Multicast Transport (RMT) Building Blocks and 1456 Protocol Instantiation documents", RFC 3269, April 2002. 1458 [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, 1459 M., and J. Crowcroft, "Layered Coding Transport (LCT) 1460 Building Block", RFC 3451, December 2002. 1462 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1463 M., and J. Crowcroft, "The Use of Forward Error Correction 1464 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1466 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 1467 Control (WEBRC) Building Block", RFC 3738, April 2004. 1469 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1470 Description Protocol", RFC 4566, July 2006. 1472 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1473 IP", RFC 4607, August 2006. 1475 [RIZ1997a] 1476 Rizzo, L., "Effective Erasure Codes for Reliable Computer 1477 Communication Protocols", ACM SIGCOMM Computer 1478 Communication Review, Vol.27, No.2, pp.24-36 , 1479 April 1997. 1481 [RIZ1997b] 1482 Rizzo, L. and L. Vicisano, "Reliable Multicast Data 1483 Distribution protocol based on software FEC techniques", 1484 Proceedings of the Fourth IEEE Workshop on the 1485 Architecture and Implementation of High Performance 1486 Communication Systems, HPCS'97, Chalkidiki Greece , 1487 June 1997. 1489 [RIZ2000] Rizzo, L., "PGMCC: A TCP-friendly single-rate multicast 1490 congestion control scheme", Proceedings of SIGCOMM 2000, 1491 Stockholm Sweden , August 2000. 1493 [VIC1998] Vicisano, L., Rizzo, L., and J. Crowcroft, "TCP-like 1494 Congestion Control for Layered Multicast Data Transfer", 1495 IEEE Infocom'98, San Francisco, CA , March 1998. 1497 Authors' Addresses 1499 Michael Luby 1500 Qualcomm Inc. 1501 3165 Kifer Rd. 1502 Santa Clara, CA 95051 1503 US 1505 Email: luby@qualcomm.com 1507 Mark Watson 1508 Qualcomm Inc. 1509 3165 Kifer Rd. 1510 Santa Clara, CA 95051 1511 US 1513 Email: watson@qualcomm.com 1515 Lorenzo Vicisano 1516 Qualcomm Inc. 1517 3165 Kifer Rd. 1518 Santa Clara, CA 95051 1519 US 1521 Email: vicisano@qualcomm.com