idnits 2.17.1 draft-ietf-rmt-bb-lct-revised-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1574. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The 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 and EXT_TIME, but MAY NOT be able to parse their 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 (April 18, 2006) is 6582 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1340 -- Looks like a reference, but probably isn't: '63' on line 1340 -- Looks like a reference, but probably isn't: '128' on line 1340 -- Looks like a reference, but probably isn't: '191' on line 1340 -- Looks like a reference, but probably isn't: '64' on line 1335 -- Looks like a reference, but probably isn't: '127' on line 1335 -- Looks like a reference, but probably isn't: '255' on line 1335 -- Looks like a reference, but probably isn't: '192' on line 1335 == Unused Reference: 'RFC2026' is defined on line 1417, but no explicit reference was found in the text == Unused Reference: 'RIZ1997' is defined on line 1499, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-rmt-fec-bb-revised-03 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 3451 (Obsoleted by RFC 5651) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast Transport (RMT) Luby 3 Working Group Watson 4 Internet-Draft Digital Fountain 5 Expires: October 20, 2006 Vicisano 6 Cisco Systems, Inc. 7 April 18, 2006 9 Layered Coding Transport (LCT) Building Block 10 draft-ietf-rmt-bb-lct-revised-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 20, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Layered Coding Transport (LCT) provides transport level support for 44 reliable content delivery and stream delivery protocols. LCT is 45 specifically designed to support protocols using IP multicast, but 46 also provides support to protocols that use unicast. LCT is 47 compatible with congestion control that provides multiple rate 48 delivery to receivers and is also compatible with coding techniques 49 that provide reliable delivery of content. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 57 4.1. Environmental Requirements and Considerations . . . . . . 10 58 4.2. Delivery service models . . . . . . . . . . . . . . . . . 12 59 4.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 14 60 5. Packet Header Fields . . . . . . . . . . . . . . . . . . . . . 16 61 5.1. LCT header format . . . . . . . . . . . . . . . . . . . . 16 62 5.2. Header-Extension Fields . . . . . . . . . . . . . . . . . 21 63 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 21 64 5.2.2. EXT_TIME Header Extension . . . . . . . . . . . . . . 23 65 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 27 66 6.1. Sender Operation . . . . . . . . . . . . . . . . . . . . . 27 67 6.2. Receiver Operation . . . . . . . . . . . . . . . . . . . . 29 68 7. Requirements from Other Building Blocks . . . . . . . . . . . 31 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 71 9.1. Namespace declaration for LCT Header Extension Types . . . 35 72 9.2. LCT Header Extension Type registration . . . . . . . . . . 35 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 74 11. Changes from RFC3451 . . . . . . . . . . . . . . . . . . . . . 37 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 76 12.1. Normative References . . . . . . . . . . . . . . . . . . . 38 77 12.2. Informative References . . . . . . . . . . . . . . . . . . 38 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 79 Intellectual Property and Copyright Statements . . . . . . . . . . 42 81 1. Introduction 83 Layered Coding Transport provides transport level support for 84 reliable content delivery and stream delivery protocols. Layered 85 Coding Transport is specifically designed to support protocols using 86 IP multicast, but also provides support to protocols that use 87 unicast. Layered Coding Transport is compatible with congestion 88 control that provides multiple rate delivery to receivers and is also 89 compatible with coding techniques that provide reliable delivery of 90 content. 92 This document describes a building block as defined in [RFC3048]. 93 This document is a product of the IETF RMT WG and follows the general 94 guidelines provided in [RFC3269]. 96 RFC3451 [RFC3451] contained a previous versions of the protocol 97 defined in this specification. RFC3451 was published in the 98 "Experimental" category. It was the stated intent of the RMT working 99 group to re-submit these specifications as an IETF Proposed Standard 100 in due course. 102 This Proposed Standard specification is thus based on and backwards 103 compatible with the protocol defined in RFC3450 [RFC3451] updated 104 according to accumulated experience and growing protocol maturity 105 since its original publication. Said experience applies both to this 106 specification itself and to congestion control strategies related to 107 the use of this specification. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Rationale 115 LCT provides transport level support for massively scalable protocols 116 using the IP multicast network service. The support that LCT 117 provides is common to a variety of very important applications, 118 including reliable content delivery and streaming applications. 120 An LCT session comprises multiple channels originating at a single 121 sender that are used for some period of time to carry packets 122 pertaining to the transmission of one or more objects that can be of 123 interest to receivers. The logic behind defining a session as 124 originating from a single sender is that this is the right 125 granularity to regulate packet traffic via congestion control. One 126 rationale for using multiple channels within the same session is that 127 there are massively scalable congestion control protocols that use 128 multiple channels per session. These congestion control protocols 129 are considered to be layered because a receiver joins and leaves 130 channels in a layered order during its participation in the session. 131 The use of layered channels is also useful for streaming 132 applications. 134 There are coding techniques that provide massively scalable 135 reliability and asynchronous delivery which are compatible with both 136 layered congestion control and with LCT. When all are combined the 137 result is a massively scalable reliable asynchronous content delivery 138 protocol that is network friendly. LCT also provides functionality 139 that can be used for other applications as well, e.g., layered 140 streaming applications. 142 LCT avoids providing functionality that is not massively scalable. 143 For example, LCT does not provide any mechanisms for sending 144 information from receivers to senders, although this does not rule 145 out protocols that both use LCT and do require sending information 146 from receivers to senders. 148 LCT includes general support for congestion control that must be 149 used. It does not, however, specify which congestion control should 150 be used. The rationale for this is that congestion control must be 151 provided by any protocol that is network friendly, and yet the 152 different applications that can use LCT will not have the same 153 requirements for congestion control. For example, a content delivery 154 protocol may strive to use all available bandwidth between receivers 155 and the sender. It must, therefore, drastically back off its rate 156 when there is competing traffic. On the other hand, a streaming 157 delivery protocol may strive to maintain a constant rate instead of 158 trying to use all available bandwidth, and it may not back off its 159 rate as fast when there is competing traffic. 161 Beyond support for congestion control, LCT provides a number of 162 fields and supports functionality commonly required by many 163 protocols. For example, LCT provides a Transmission Session ID that 164 can be used to identify which session each received packet belongs 165 to. This is important because a receiver may be joined to many 166 sessions concurrently, and thus it is very useful to be able to 167 demultiplex packets as they arrive according to which session they 168 belong to. As another example, LCT provides optional support for 169 identifying which object each packet is carrying information about. 170 Therefore, LCT provides many of the commonly used fields and support 171 for functionality required by many protocols. 173 3. Functionality 175 An LCT session consists of a set of logically grouped LCT channels 176 associated with a single sender carrying packets with LCT headers for 177 one or more objects. An LCT channel is defined by the combination of 178 a sender and an address associated with the channel by the sender. A 179 receiver joins a channel to start receiving the data packets sent to 180 the channel by the sender, and a receiver leaves a channel to stop 181 receiving data packets from the channel. 183 LCT is meant to be combined with other building blocks so that the 184 resulting overall protocol is massively scalable. Scalability refers 185 to the behavior of the protocol in relation to the number of 186 receivers and network paths, their heterogeneity, and the ability to 187 accommodate dynamically variable sets of receivers. Scalability 188 limitations can come from memory or processing requirements, or from 189 the amount of feedback control and redundant data packet traffic 190 generated by the protocol. In turn, such limitations may be a 191 consequence of the features that a complete reliable content delivery 192 or stream delivery protocol is expected to provide. 194 The LCT header provides a number of fields that are useful for 195 conveying in-band session information to receivers. One of the 196 required fields is the Transmission Session ID (TSI), which allows 197 the receiver of a session to uniquely identify received packets as 198 part of the session. Another required field is the Congestion 199 Control Information (CCI), which allows the receiver to perform the 200 required congestion control on the packets received within the 201 session. Other LCT fields provide optional but often very useful 202 additional information for the session. For example, the Transport 203 Object Identifier (TOI) identifies which object the packet contains 204 data for and flags are included for indicating the close of the 205 session and the close of sending packets for an object. Header 206 extensions can carry additional fields that for example can be used 207 for packet authentication or to convey various kinds of timing 208 information: the Sender Current Time (SCT) conveys the time when the 209 packet was sent from the sender to the receiver, the Expected 210 Residual Time (ERT) conveys the amount of time the session or 211 transmission object will be continued for, and Session Last Change 212 conveys the time when objects have been added, modified or removed 213 from the session. 215 LCT provides support for congestion control. Congestion control MUST 216 be used that conforms to [RFC2357] between receivers and the sender 217 for each LCT session. Congestion control refers to the ability to 218 adapt throughput to the available bandwidth on the path from the 219 sender to a receiver, and to share bandwidth fairly with competing 220 flows such as TCP. Thus, the total flow of packets flowing to each 221 receiver participating in an LCT session MUST NOT compete unfairly 222 with existing flow adaptive protocols such as TCP. 224 A multiple rate or a single rate congestion control protocol can be 225 used with LCT. For multiple rate protocols, a session typically 226 consists of more than one channel and the sender sends packets to the 227 channels in the session at rates that do not depend on the receivers. 228 Each receiver adjusts its reception rate during its participation in 229 the session by joining and leaving channels dynamically depending on 230 the available bandwidth to the sender independent of all other 231 receivers. Thus, for multiple rate protocols, the reception rate of 232 each receiver may vary dynamically independent of the other 233 receivers. 235 For single rate protocols, a session typically consists of one 236 channel and the sender sends packets to the channel at variable rates 237 over time depending on feedback from receivers. Each receiver 238 remains joined to the channel during its participation in the 239 session. Thus, for single rate protocols, the reception rate of each 240 receiver may vary dynamically but in coordination with all receivers. 242 Generally, a multiple rate protocol is preferable to a single rate 243 protocol in a heterogeneous receiver environment, since generally it 244 more easily achieves scalability to many receivers and provides 245 higher throughput to each individual receiver. Some possible 246 multiple rate congestion control protocols are described in 247 [VIC1998], [BYE2000], and [LUB2002]. A possible single rate 248 congestion control protocol is described in [RIZ2000]. 250 Layered coding refers to the ability to produce a coded stream of 251 packets that can be partitioned into an ordered set of layers. The 252 coding is meant to provide some form of reliability, and the layering 253 is meant to allow the receiver experience (in terms of quality of 254 playout, or overall transfer speed) to vary in a predictable way 255 depending on how many consecutive layers of packets the receiver is 256 receiving. 258 The concept of layered coding was first introduced with reference to 259 audio and video streams. For example, the information associated 260 with a TV broadcast could be partitioned into three layers, 261 corresponding to black and white, color, and HDTV quality. Receivers 262 can experience different quality without the need for the sender to 263 replicate information in the different layers. 265 The concept of layered coding can be naturally extended to reliable 266 content delivery protocols when Forward Error Correction (FEC) 267 techniques are used for coding the data stream. Descriptions of this 268 can be found in [RIZ1997a], [RIZ1997b], [GEM2000], [VIC1998] and 270 [BYE1998]. By using FEC, the data stream is transformed in such a 271 way that reconstruction of a data object does not depend on the 272 reception of specific data packets, but only on the number of 273 different packets received. As a result, by increasing the number of 274 layers a receiver is receiving from, the receiver can reduce the 275 transfer time accordingly. Using FEC to provide reliability can 276 increase scalability dramatically in comparison to other methods for 277 providing reliability. More details on the use of FEC for reliable 278 content delivery can be found in [RFC3453]. 280 Reliable protocols aim at giving guarantees on the reliable delivery 281 of data from the sender to the intended recipients. Guarantees vary 282 from simple packet data integrity to reliable delivery of a precise 283 copy of an object to all intended recipients. Several reliable 284 content delivery protocols have been built on top of IP multicast 285 using methods other than FEC, but scalability was not the primary 286 design goal for many of them. 288 Two of the key difficulties in scaling reliable content delivery 289 using IP multicast are dealing with the amount of data that flows 290 from receivers back to the sender, and the associated response 291 (generally data retransmissions) from the sender. Protocols that 292 avoid any such feedback, and minimize the amount of retransmissions, 293 can be massively scalable. LCT can be used in conjunction with FEC 294 codes or a layered codec to achieve reliability with little or no 295 feedback. 297 Protocol instantiations MAY be built by combining the LCT framework 298 with other components. A complete protocol instantiation that uses 299 LCT MUST include a congestion control protocol that is compatible 300 with LCT and that conforms to [RFC2357]. A complete protocol 301 instantiation that uses LCT MAY include a scalable reliability 302 protocol that is compatible with LCT, it MAY include an session 303 control protocol that is compatible with LCT, and it MAY include 304 other protocols such as security protocols. 306 4. Applicability 308 An LCT session comprises a logically related set of one or more LCT 309 channels originating at a single sender. The channels are used for 310 some period of time to carry packets containing LCT headers, and 311 these headers pertain to the transmission of one or more objects that 312 can be of interest to receivers. 314 LCT is most applicable for delivery of objects or streams in a 315 session of substantial length, i.e., objects or streams that range in 316 aggregate length from hundreds of kilobytes to many gigabytes, and 317 where the duration of the session is on the order of tens of seconds 318 or more. 320 As an example, an LCT session could be used to deliver a TV program 321 using three LCT channels. Receiving packets from the first LCT 322 channel could allow black and white reception. Receiving the first 323 two LCT channels could also permit color reception. Receiving all 324 three channels could allow HDTV quality reception. Objects in this 325 example could correspond to individual TV programs being transmitted. 327 As another example, a reliable LCT session could be used to reliably 328 deliver hourly-updated weather maps (objects) using ten LCT channels 329 at different rates, using FEC coding. A receiver may join and 330 concurrently receive packets from subsets of these channels, until it 331 has enough packets in total to recover the object, then leave the 332 session (or remain connected listening for session description 333 information only) until it is time to receive the next object. In 334 this case, the quality metric is the time required to receive each 335 object. 337 Before joining a session, the receivers MUST obtain enough of the 338 session description to start the session. This MUST include the 339 relevant session parameters needed by a receiver to participate in 340 the session, including all information relevant to congestion 341 control. The session description is determined by the sender, and is 342 typically communicated to the receivers out-of-band. In some cases, 343 as described later, parts of the session description that are not 344 required to initiate a session MAY be included in the LCT header or 345 communicated to a receiver out-of-band after the receiver has joined 346 the session. 348 An encoder MAY be used to generate the data that is placed in the 349 packet payload in order to provide reliability. A suitable decoder 350 is used to reproduce the original information from the packet 351 payload. There MAY be a reliability header that follows the LCT 352 header if such an encoder and decoder is used. The reliability 353 header helps to describe the encoding data carried in the payload of 354 the packet. The format of the reliability header depends on the 355 coding used, and this is negotiated out-of-band. As an example, one 356 of the FEC headers described in [I-D.ietf-rmt-fec-bb-revised] could 357 be used. 359 For LCT, when multiple rate congestion control is used, congestion 360 control is achieved by sending packets associated with a given 361 session to several LCT channels. Individual receivers dynamically 362 join one or more of these channels, according to the network 363 congestion as seen by the receiver. LCT headers include an opaque 364 field which MUST be used to convey congestion control information to 365 the receivers. The actual congestion control scheme to use with LCT 366 is negotiated out-of-band. Some examples of congestion control 367 protocols that may be suitable for content delivery are described in 368 [VIC1998], [BYE2000], and [LUB2002]. Other congestion controls may 369 be suitable when LCT is used for a streaming application. 371 This document does not specify and restrict the type of exchanges 372 between LCT (or any PI built on top of LCT) and an upper application. 373 Some upper APIs may use an object-oriented approach, where the only 374 possible unit of data exchanged between LCT (or any PI built on top 375 of LCT) and an application, either at a source or at a receiver, is 376 an object. Other APIs may enable a sending or receiving application 377 to exchange a subset of an object with LCT (or any PI built on top of 378 LCT), or may even follow a streaming model. These considerations are 379 outside the scope of this document. 381 4.1. Environmental Requirements and Considerations 383 LCT is intended for congestion controlled delivery of objects and 384 streams (both reliable content delivery and streaming of multimedia 385 information). 387 LCT can be used with both multicast and unicast delivery. LCT 388 requires connectivity between a sender and receivers but does not 389 require connectivity from receivers to a sender. LCT inherently 390 works with all types of networks, including LANs, WANs, Intranets, 391 the Internet, asymmetric networks, wireless networks, and satellite 392 networks. Thus, the inherent raw scalability of LCT is unlimited. 393 However, when other specific applications are built on top of LCT, 394 then these applications by their very nature may limit scalability. 395 For example, if an application requires receivers to retrieve out of 396 band information in order to join a session, or an application allows 397 receivers to send requests back to the sender to report reception 398 statistics, then the scalability of the application is limited by the 399 ability to send, receive, and process this additional data. 401 LCT requires receivers to be able to uniquely identify and 402 demultiplex packets associated with an LCT session. In particular, 403 there MUST be a Transport Session Identifier (TSI) associated with 404 each LCT session. The TSI is scoped by the IP address of the sender, 405 and the IP address of the sender together with the TSI MUST uniquely 406 identify the session. If the underlying transport is UDP as 407 described in [RFC0768], then the 16 bit UDP source port number MAY 408 serve as the TSI for the session. The TSI value MUST be the same in 409 all places it occurs within a packet. If there is no underlying TSI 410 provided by the network, transport or any other layer, then the TSI 411 MUST be included in the LCT header. 413 LCT is presumed to be used with an underlying network or transport 414 service that is a "best effort" service that does not guarantee 415 packet reception or packet reception order, and which does not have 416 any support for flow or congestion control. For example, the Any- 417 Source Multicast (ASM) model of IP multicast as defined in [RFC1112] 418 is such a "best effort" network service. While the basic service 419 provided by [RFC1112] is largely scalable, providing congestion 420 control or reliability should be done carefully to avoid severe 421 scalability limitations, especially in presence of heterogeneous sets 422 of receivers. 424 There are currently two models of multicast delivery, the Any-Source 425 Multicast (ASM) model as defined in [RFC1112] and the Source- 426 Specific Multicast (SSM) model as defined in [HOL2001]. LCT works 427 with both multicast models, but in a slightly different way with 428 somewhat different environmental concerns. When using ASM, a sender 429 S sends packets to a multicast group G, and the LCT channel address 430 consists of the pair (S,G), where S is the IP address of the sender 431 and G is a multicast group address. When using SSM, a sender S sends 432 packets to an SSM channel (S,G), and the LCT channel address 433 coincides with the SSM channel address. 435 A sender can locally allocate unique SSM channel addresses, and this 436 makes allocation of LCT channel addresses easy with SSM. To allocate 437 LCT channel addresses using ASM, the sender must uniquely chose the 438 ASM multicast group address across the scope of the group, and this 439 makes allocation of LCT channel addresses more difficult with ASM. 441 LCT channels and SSM channels coincide, and thus the receiver will 442 only receive packets sent to the requested LCT channel. With ASM, 443 the receiver joins an LCT channel by joining a multicast group G, and 444 all packets sent to G, regardless of the sender, may be received by 445 the receiver. Thus, SSM has compelling security advantages over ASM 446 for prevention of denial of service attacks. In either case, 447 receivers SHOULD use mechanisms to filter out packets from unwanted 448 sources. 450 Some networks are not amenable to some congestion control protocols 451 that could be used with LCT. In particular, for a satellite or 452 wireless network, there may be no mechanism for receivers to 453 effectively reduce their reception rate since there may be a fixed 454 transmission rate allocated to the session. 456 LCT is compatible with both IPv4 and IPv6 as no part of the packet is 457 IP version specific. 459 4.2. Delivery service models 461 LCT can support several different delivery service models. Two 462 examples are briefly described here. 464 Push service model 466 One way a push service model can be used for reliable content 467 delivery is to deliver a series of objects. For example, a 468 receiver could join the session and dynamically adapt the number 469 of LCT channels the receiver is joined to until enough packets 470 have been received to reconstruct an object. After reconstructing 471 the object the receiver may stay in the session and wait for the 472 transmission of the next object. 474 The push model is particularly attractive in satellite networks 475 and wireless networks. In these cases, a session may consist of 476 one fixed rate LCT channel. 478 A push service model can be used for example for reliable delivery 479 of a large object such as a 100 GB file. The sender could send a 480 Session Description announcement to a control channel and 481 receivers could monitor this channel and join a session whenever a 482 Session Description of interest arrives. Upon receipt of the 483 Session Description, each receiver could join the session to 484 receive packets until enough packets have arrived to reconstruct 485 the object, at which point the receiver could report back to the 486 sender that its reception was completed successfully. The sender 487 could decide to continue sending packets for the object to the 488 session until all receivers have reported successful 489 reconstruction or until some other condition has been satisfied. 491 There are several features ALC provides to support the push model. 492 For example, the sender can optionally include an Expected 493 Residual Time (ERT) in the packet header extension that indicates 494 the expected remaining time of packet transmission for either the 495 single object carried in the session or for the object identified 496 by the Transmission Object Identifier (TOI) if there are multiple 497 objects carried in the session. This can be used by receivers to 498 determine if there is enough time remaining in the session to 499 successfully receive enough additional packets to recover the 500 object. If for example there is not enough time, then the push 501 application may have receivers report back to the sender to extend 502 the transmission of packets for the object for enough time to 503 allow the receivers to obtain enough packets to reconstruct the 504 object. The sender could then include an ERT based on the 505 extended object transmission time in each subsequent packet header 506 for the object. As other examples, the LCT header optionally can 507 contain a Close Session flag that indicates when the sender is 508 about to end sending packet to the session and a Close Object flag 509 that indicates when the sender is about to end sending packets to 510 the session for the object identified by the Transmission Object 511 ID. However, these flags are not a completely reliable mechanism 512 and thus the Close Session flag should only be used as a hint of 513 when the session is about to close and the Close Object flag 514 should only be used as a hint of when transmission of packets for 515 the object is about to end. 517 On-demand content delivery model 519 For an on-demand content delivery service model, senders typically 520 transmit for some given time period selected to be long enough to 521 allow all the intended receivers to join the session and recover 522 the object. For example a popular software update might be 523 transmitted using LCT for several days, even though a receiver may 524 be able to complete the download in one hour total of connection 525 time, perhaps spread over several intervals of time. In this case 526 the receivers join the session at any point in time when it is 527 active. Receivers leave the session when they have received 528 enough packets to recover the object. The receivers, for example, 529 obtain a Session Description by contacting a web server. 531 In this case the receivers join the session, and dynamically adapt 532 the number of LCT channels they subscribe to according to the 533 available bandwidth. Receivers then drop from the session when 534 they have received enough packets to recover the object. 536 As an example, assume that an object is 50 MB. The sender could 537 send 1 KB packets to the first LCT channel at 50 packets per 538 second, so that receivers using just this LCT channel could 539 complete reception of the object in 1,000 seconds in absence of 540 loss, and would be able to complete reception even in presence of 541 some substantial amount of losses with the use of coding for 542 reliability. Furthermore, the sender could use a number of LCT 543 channels such that the aggregate rate of 1 KB packets to all LCT 544 channels is 1,000 packets per second, so that a receiver could be 545 able to complete reception of the object in as little 50 seconds 546 (assuming no loss and that the congestion control mechanism 547 immediately converges to the use of all LCT channels). 549 Other service models 551 There are many other delivery service models that LCT can be used 552 for that are not covered above. As examples, a live streaming or 553 an on- demand archival content streaming service model. A 554 description of the many potential applications, the appropriate 555 delivery service model, and the additional mechanisms to support 556 such functionalities when combined with LCT is beyond the scope of 557 this document. This document only attempts to describe the 558 minimal common scalable elements to these diverse applications 559 using LCT as the delivery transport. 561 4.3. Congestion Control 563 The specific congestion control protocol to be used for LCT sessions 564 depends on the type of content to be delivered. While the general 565 behavior of the congestion control protocol is to reduce the 566 throughput in presence of congestion and gradually increase it in the 567 absence of congestion, the actual dynamic behavior (e.g. response to 568 single losses) can vary. 570 Some possible congestion control protocols for reliable content 571 delivery using LCT are described in [VIC1998], [BYE2000], and 573 [LUB2002]. Different delivery service models might require different 574 congestion control protocols. 576 5. Packet Header Fields 578 Packets sent to an LCT session MUST include an "LCT header". The LCT 579 header format is described below. 581 Other building blocks MAY describe some of the same fields as 582 described for the LCT header. It is RECOMMENDED that protocol 583 instantiations using multiple building blocks include shared fields 584 at most once in each packet. Thus, for example, if another building 585 block is used with LCT that includes the optional Expected Residual 586 Time field, then the Expected Residual Time field SHOULD be carried 587 in each packet at most once. 589 The position of the LCT header within a packet MUST be specified by 590 any protocol instantiation that uses LCT. 592 5.1. LCT header format 594 The LCT header is of variable size, which is specified by a length 595 field in the third byte of the header. In the LCT header, all 596 integer fields are carried in "big-endian" or "network order" format, 597 that is, most significant byte (octet) first. Bits designated as 598 "padding" or "reserved" (r) MUST by set to 0 by senders and ignored 599 by receivers in this version of the specification. Unless otherwise 600 noted, numeric constants in this specification are in decimal (base 601 10). 603 The format of the default LCT header is depicted in Figure 1. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | V | C |PSI|S| O |H|Res|A|B| HDR_LEN | Codepoint (CP)| 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Congestion Control Information (CCI, length = 32*(C+1) bits) | 611 | ... | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Transport Session Identifier (TSI, length = 32*S+16*H bits) | 614 | ... | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Transport Object Identifier (TOI, length = 32*O+16*H bits) | 617 | ... | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Sender Current Time (SCT, if T = 1) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Expected Residual Time (ERT, if R = 1) | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Header Extensions (if applicable) | 624 | ... | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 1: Default LCT header format 629 The function and length of each field in the default LCT header is 630 the following. Fields marked as "1" mean that the corresponding bits 631 MUST be set to "1" by the sender. Fields marked as "r" or "0" mean 632 that the corresponding bits MUST be set to "0" by the sender. 634 LCT version number (V): 4 bits 636 Indicates the LCT version number. The LCT version number for this 637 specification is 1. 639 Congestion control flag (C): 2 bits 641 C=0 indicates the Congestion Control Information (CCI) field is 642 32-bits in length. C=1 indicates the CCI field is 64-bits in 643 length. C=2 indicates the CCI field is 96-bits in length. C=3 644 indicates the CCI field is 128-bits in length. 646 Protocol Specific Indication (PSI): 2 bits 648 The usage of these bits, if any, is specific to each Protocol 649 Instantiation that uses the LCT Building Block. If no Protocol 650 Instantiation-specific usage of these bits is defined, then a 651 sender MUST set them to zero and a receiver MUST ignore these 652 bits. 654 Transport Session Identifier flag (S): 1 bit 656 This is the number of full 32-bit words in the TSI field. The TSI 657 field is 32*S + 16*H bits in length, i.e. the length is either 0 658 bits, 16 bits, 32 bits, or 48 bits. 660 Transport Object Identifier flag (O): 2 bits 662 This is the number of full 32-bit words in the TOI field. The TOI 663 field is 32*O + 16*H bits in length, i.e., the length is either 0 664 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 665 bits. 667 Half-word flag (H): 1 bit 669 The TSI and the TOI fields are both multiples of 32-bits plus 16*H 670 bits in length. This allows the TSI and TOI field lengths to be 671 multiples of a half-word (16 bits), while ensuring that the 672 aggregate length of the TSI and TOI fields is a multiple of 32- 673 bits. 675 Reserved (Res): 2 bits 677 These bits are reserved. In this version of the specification, 678 they MUST be set to zero by senders and MUST be ignored by 679 receivers. 681 Close Session flag (A): 1 bit 683 Normally, A is set to 0. The sender MAY set A to 1 when 684 termination of transmission of packets for the session is 685 imminent. A MAY be set to 1 in just the last packet transmitted 686 for the session, or A MAY be set to 1 in the last few seconds of 687 packets transmitted for the session. Once the sender sets A to 1 688 in one packet, the sender SHOULD set A to 1 in all subsequent 689 packets until termination of transmission of packets for the 690 session. A received packet with A set to 1 indicates to a 691 receiver that the sender will immediately stop sending packets for 692 the session. When a receiver receives a packet with A set to 1 693 the receiver SHOULD assume that no more packets will be sent to 694 the session. 696 Close Object flag (B): 1 bit 697 Normally, B is set to 0. The sender MAY set B to 1 when 698 termination of transmission of packets for an object is imminent. 699 If the TOI field is in use and B is set to 1 then termination of 700 transmission for the object identified by the TOI field is 701 imminent. If the TOI field is not in use and B is set to 1 then 702 termination of transmission for the one object in the session 703 identified by out-of-band information is imminent. B MAY be set 704 to 1 in just the last packet transmitted for the object, or B MAY 705 be set to 1 in the last few seconds packets transmitted for the 706 object. Once the sender sets B to 1 in one packet for a 707 particular object, the sender SHOULD set B to 1 in all subsequent 708 packets for the object until termination of transmission of 709 packets for the object. A received packet with B set to 1 710 indicates to a receiver that the sender will immediately stop 711 sending packets for the object. When a receiver receives a packet 712 with B set to 1 then it SHOULD assume that no more packets will be 713 sent for the object to the session. 715 LCT header length (HDR_LEN): 8 bits 717 Total length of the LCT header in units of 32-bit words. The 718 length of the LCT header MUST be a multiple of 32-bits. This 719 field can be used to directly access the portion of the packet 720 beyond the LCT header, i.e., to the first other header if it 721 exists, or to the packet payload if it exists and there is no 722 other header, or to the end of the packet if there are no other 723 headers or packet payload. 725 Codepoint (CP): 8 bits 727 An opaque identifier which is passed to the packet payload decoder 728 to convey information on the codec being used for the packet 729 payload. The mapping between the codepoint and the actual codec 730 is defined on a per session basis and communicated out-of-band as 731 part of the session description information. The use of the CP 732 field is similar to the Payload Type (PT) field in RTP headers as 733 described in [RFC1889]. 735 Congestion Control Information (CCI): 32, 64, 96 or 128 bits 737 Used to carry congestion control information. For example, the 738 congestion control information could include layer numbers, 739 logical channel numbers, and sequence numbers. This field is 740 opaque for the purpose of this specification. 742 This field MUST be 32 bits if C=0. 744 This field MUST be 64 bits if C=1. 746 This field MUST be 96 bits if C=2. 748 This field MUST be 128 bits if C=3. 750 Transport Session Identifier (TSI): 0, 16, 32 or 48 bits 752 The TSI uniquely identifies a session among all sessions from a 753 particular sender. The TSI is scoped by the IP address of the 754 sender, and thus the IP address of the sender and the TSI together 755 uniquely identify the session. Although a TSI in conjunction with 756 the IP address of the sender always uniquely identifies a session, 757 whether or not the TSI is included in the LCT header depends on 758 what is used as the TSI value. If the underlying transport is 759 UDP, then the 16 bit UDP source port number MAY serve as the TSI 760 for the session. If the TSI value appears multiple times in a 761 packet then all occurrences MUST be the same value. If there is 762 no underlying TSI provided by the network, transport or any other 763 layer, then the TSI MUST be included in the LCT header. 765 The TSI MUST be unique among all sessions served by the sender 766 during the period when the session is active, and for a large 767 period of time preceding and following when the session is active. 768 A primary purpose of the TSI is to prevent receivers from 769 inadvertently accepting packets from a sender that belong to 770 sessions other than the sessions receivers are subscribed to. For 771 example, suppose a session is deactivated and then another session 772 is activated by a sender and the two sessions use an overlapping 773 set of channels. A receiver that connects and remains connected 774 to the first session during this sender activity could possibly 775 accept packets from the second session as belonging to the first 776 session if the TSI for the two sessions were identical. The 777 mapping of TSI field values to sessions is outside the scope of 778 this document and is to be done out-of-band. 780 The length of the TSI field is 32*S + 16*H bits. Note that the 781 aggregate lengths of the TSI field plus the TOI field is a 782 multiple of 32 bits. 784 Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 785 bits. 787 This field indicates which object within the session this packet 788 pertains to. For example, a sender might send a number of files 789 in the same session, using TOI=0 for the first file, TOI=1 for the 790 second one, etc. As another example, the TOI may be a unique 791 global identifier of the object that is being transmitted from 792 several senders concurrently, and the TOI value may be the output 793 of a hash function applied to the object. The mapping of TOI 794 field values to objects is outside the scope of this document and 795 is to be done out-of-band. The TOI field MUST be used in all 796 packets if more than one object is to be transmitted in a session, 797 i.e. the TOI field is either present in all the packets of a 798 session or is never present. 800 The length of the TOI field is 32*O + 16*H bits. Note that the 801 aggregate lengths of the TSI field plus the TOI field is a 802 multiple of 32 bits. 804 5.2. Header-Extension Fields 806 5.2.1. General 808 Header Extensions are used in LCT to accommodate optional header 809 fields that are not always used or have variable size. Examples of 810 the use of Header Extensions include: 812 o Extended-size versions of already existing header fields. 814 o Sender and Receiver authentication information. 816 o Transmission of timing information. 818 The presence of Header Extensions can be inferred by the LCT header 819 length (HDR_LEN): if HDR_LEN is larger than the length of the 820 standard header then the remaining header space is taken by Header 821 Extension fields. 823 If present, Header Extensions MUST be processed to ensure that they 824 are recognized before performing any congestion control procedure or 825 otherwise accepting a packet. The default action for unrecognized 826 header extensions is to ignore them. This allows the future 827 introduction of backward-compatible enhancements to LCT without 828 changing the LCT version number. Non backward-compatible header 829 extensions CANNOT be introduced without changing the LCT version 830 number. 832 There are two formats for Header Extension fields, as depicted in 833 Figure 2. The first format is used for variable-length extensions, 834 with Header Extension Type (HET) values between 0 and 127. The 835 second format is used for fixed length (one 32-bit word) extensions, 836 using HET values from 127 to 255. 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | HET (<=127) | HEL | | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 843 . . 844 . Header Extension Content (HEC) . 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | HET (>=128) | Header Extension Content (HEC) | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 Figure 2: Format of additional headers 855 The explanation of each sub-field is the following: 857 Header Extension Type (HET): 8 bits 859 The type of the Header Extension. This document defines a number 860 of possible types. Additional types may be defined in future 861 versions of this specification. HET values from 0 to 127 are used 862 for variable-length Header Extensions. HET values from 128 to 255 863 are used for fixed-length 32-bit Header Extensions. 865 Header Extension Length (HEL): 8 bits 867 The length of the whole Header Extension field, expressed in 868 multiples of 32-bit words. This field MUST be present for 869 variable-length extensions (HET between 0 and 127) and MUST NOT be 870 present for fixed-length extensions (HET between 128 and 255). 872 Header Extension Content (HEC): variable length 874 The content of the Header Extension. The format of this sub- 875 field depends on the Header Extension type. For fixed-length 876 Header Extensions, the HEC is 24 bits. For variable-length Header 877 Extensions, the HEC field has variable size, as specified by the 878 HEL field. Note that the length of each Header Extension field 879 MUST be a multiple of 32 bits. Also note that the total size of 880 the LCT header, including all Header Extensions and all optional 881 header fields, cannot exceed 255 32-bit words. 883 LCT Header Extensions with general applicability to any protocol 884 which makes use of LCT SHOULD be defined in the ranges [0,63] or 885 [128,191] inclusive. LCT Header Extensions with narrower 886 applicability (for example to a singe Protocol Instantiation) SHOULD 887 be defined in the ranges [64,127] or [191,255] inclusive. 889 The following LCT Header Extensions are defined by this 890 specification: 892 EXT_NOP, HET=0 No-Operation extension. The information present in 893 this extension field MUST be ignored by receivers. 895 EXT_AUTH, HET=1 Packet authentication extension Information used to 896 authenticate the sender of the packet. The format of 897 this Header Extension and its processing is outside the 898 scope of this document and is to be communicated out- 899 of-band as part of the session description. 901 It is RECOMMENDED that senders provide some form of 902 packet authentication. If EXT_AUTH is present, 903 whatever packet authentication checks that can be 904 performed immediately upon reception of the packet 905 SHOULD be performed before accepting the packet and 906 performing any congestion control-related action on it. 908 Some packet authentication schemes impose a delay of 909 several seconds between when a packet is received and 910 when the packet is fully authenticated. Any congestion 911 control related action that is appropriate MUST NOT be 912 postponed by any such full packet authentication. 914 EXT_TIME, HET=2 Time Extension. This extension is used to carry 915 several types of timing information. It includes 916 general purpose timing information, namely the Sender 917 Current Time (SCT), Expected Residual Time (ERT) and 918 Sender Last Change (SLC) time extensions described in 919 the present document. It can also be used for timing 920 information with narrower applicability (e.g. defined 921 for a single Protocol Instantiation); in this case it 922 will be described in a separate document. 924 All senders and receivers implementing LCT MUST support the EXT_NOP 925 Header Extension and MUST recognize EXT_AUTH and EXT_TIME, but MAY 926 NOT be able to parse their content. 928 5.2.2. EXT_TIME Header Extension 930 This section defines the timing header extensions with general 931 applicability. The time values carried in this header extension are 932 related to the server's wall clock. The server MUST maintain 933 consistent relative time during a session (i.e. insignificant clock 934 drift). For some applications, system or even global synchronization 935 of server wall clock may be desirable, such as using the Network Time 936 Protocol (NTP) [RFC1305] to ensure actual time relative to 00:00 937 hours GMT, January 1st 1900. Such session-external synchronization 938 is outside the scope of this document. 940 The EXT_TIME Header Extension uses the format depicted in Figure 3 942 0 1 2 3 943 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 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | HET = 2 | HEL >= 1 | Use (bit field) | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | first time value | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 ... (other time values (optional) ... 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 Figure 3: EXT_TIME Header Extension format 954 The "Use" bit field indicates the semantic of the following 32 bit 955 time value(s). 957 It is divided into two parts: 959 o 8 bits are reserved for general purpose timing information. These 960 information are applicable to any protocol which makes use of LCT. 962 o 8 bits are reserved for PI specific timing information. These 963 information are out of the scope of this document. 965 The format of the "Use" bit field is depicted in Figure 4. 967 2 3 968 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 969 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 970 |SCT|SCT|ERT|SLC| reserved | PI-specific | 971 |Hi |Low| | | by LCT | use | 972 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 974 Figure 4: "Use" bit field format 976 The fields for the general purpose EXT_TIME timing information are: 978 Sender Current Time (SCT): SCT High flag, SCT Low flag, corresponding 979 time value (one or two 32 bit words) 981 This timing information represents the current time at the sender 982 at the time this packet was transmitted. 984 When the SCT-High flag is set, the associated 32 bit time value 985 provides an unsigned integer representing the time in seconds of 986 the sender's wall clock. In the particular case where NTP is 987 used, these 32 bits provide an unsigned integer representing the 988 time in seconds relative to 00:00 hours GMT, January 1st 1900, 989 (i.e. the most significant 32 bits of a full 64 bit NTP time 990 value). In that case, handling of wraparound of the 32 bit time 991 is outside the scope of NTP and LCT. 993 When the SCT-Low flag is set, the associated 32 bit time value 994 provides an unsigned integer representing a multiple of 1/2^^32 of 995 a second, in order to allow sub-second precision. When the SCT- 996 Low flag is set, the SCT-High flag MUST be set too. In the 997 particular case where NTP is used, these 32 bits provide the 32 998 least significant bits of a 64 bit NTP timestamp. 1000 Expected Residual Time (ERT): ERT flag, corresponding 32 bit time 1001 value 1003 This timing information represents the sender expected residual 1004 transmission time for the current session or for the transmission 1005 of the current object. If the packet containing the ERT timing 1006 information also contains the TOI field, then ERT refers to the 1007 object corresponding to the TOI field, otherwise it refers to the 1008 session. 1010 When the ERT flag is set, it it expressed as a number of seconds. 1011 The 32 bits provide an unsigned integer representing this number 1012 of seconds. 1014 Session Last Changed (SLC): SLC flag, corresponding 32 bit time value 1016 The Session Last Changed time value is the server wall clock time, 1017 in seconds, at which the last change to session data occurred. 1018 That is, it expresses the time at which the last (most recent) 1019 Transport Object addition, modification or removal was made for 1020 the delivery session. In the case of modifications and additions 1021 it indicates that new data will be transported which was not 1022 transported prior to this time. In the case of removals, SLC 1023 indicates that some prior data will no longer be transported. 1025 When the SLC flag is set, the associated 32 bit time value 1026 provides an unsigned integer representing a time in second. In 1027 the particular case where NTP is used, these 32 bits provide an 1028 unsigned integer representing the time in seconds relative to 1029 00:00 hours GMT, January 1st 1900, (i.e. the most significant 32 1030 bits of a full 64 bit NTP time value). In that case, handling of 1031 wraparound of the 32 bit time is outside the scope of NTP and LCT. 1033 In some cases, it may be appropriate that a packet containing a 1034 EXT_TIME Header Extension with an SLC information also contain a 1035 SCT-High information. 1037 Reserved by LCT for future use (4 bits): 1039 In this version of the specification, these bits MUST be set to 1040 zero by senders and MUST be ignored by receivers. 1042 PI-specific use (8 bits): 1044 These bits are out of the scope of this document. The bits that 1045 are not specified by the PI built on top of LCT SHOULD be set to 1046 zero. 1048 Several "time value" fields MAY be present in a given EXT_TIME Header 1049 Extension, as specified in the "Use-field". When several "time 1050 value" fields are present, they MUST appear in the order specified by 1051 the associated flag position in the "Use-field": first SCT-High (if 1052 present), then SCT-Low (if present), then ERT (if present), then SLC 1053 (if present). Receivers SHOULD ignore additional fields within the 1054 EXT_TIME Header Extension which they do not support. 1056 The total EXT_TIME length is carried in the HEL, since this Header 1057 Extension is of variable length. It also enables clients to skip 1058 this Header Extension altogether if not supported (but recognized). 1060 6. Operations 1062 6.1. Sender Operation 1064 Before joining an LCT session a receiver MUST obtain a session 1065 description. The session description MUST include: 1067 o The sender IP address; 1069 o The number of LCT channels; 1071 o The addresses and port numbers used for each LCT channel; 1073 o The Transport Session ID (TSI) to be used for the session; 1075 o Enough information to determine the congestion control protocol 1076 being used; 1078 o Enough information to determine the packet authentication scheme 1079 being used if it is being used. 1081 The session description could also include, but is not limited to: 1083 o The data rates used for each LCT channel; 1085 o The length of the packet payload; 1087 o The mapping of TOI value(s) to objects for the session; 1089 o Any information that is relevant to each object being transported, 1090 such as when it will be available within the session, for how 1091 long, and the length of the object; 1093 Protocol instantiations using LCT MAY place additional requirements 1094 on what must be included in the session description. For example, a 1095 protocol instantiation might require that the data rates for each 1096 channel, or the mapping of TOI value(s) to objects for the session, 1097 or other information related to other headers that might be required 1098 to be included in the session description. 1100 The session description could be in a form such as SDP as defined in 1101 [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime 1102 headers as defined in [RFC2616], etc. It might be carried in a 1103 session announcement protocol such as SAP as defined in [RFC2974], 1104 obtained using a proprietary session control protocol, located on a 1105 Web page with scheduling information, or conveyed via E-mail or other 1106 out-of-band methods. Discussion of session description format, and 1107 distribution of session descriptions is beyond the scope of this 1108 document. 1110 Within an LCT session, a sender using LCT transmits a sequence of 1111 packets, each in the format defined above. Packets are sent from a 1112 sender using one or more LCT channels which together constitute a 1113 session. Transmission rates may be different in different channels 1114 and may vary over time. The specification of the other building 1115 block headers and the packet payload used by a complete protocol 1116 instantiation using LCT is beyond the scope of this document. This 1117 document does not specify the order in which packets are transmitted, 1118 nor the organization of a session into multiple channels. Although 1119 these issues affect the efficiency of the protocol, they do not 1120 affect the correctness nor the inter-operability of LCT between 1121 senders and receivers. 1123 Several objects can be carried within the same LCT session. In this 1124 case, each object MUST be identified by a unique TOI. Objects MAY be 1125 transmitted sequentially, or they MAY be transmitted concurrently. 1126 It is good practice to only send objects concurrently in the same 1127 session if the receivers that participate in that portion of the 1128 session have interest in receiving all the objects. The reason for 1129 this is that it wastes bandwidth and networking resources to have 1130 receivers receive data for objects that they have no interest in. 1132 Typically, the sender(s) continues to send packets in a session until 1133 the transmission is considered complete. The transmission may be 1134 considered complete when some time has expired, a certain number of 1135 packets have been sent, or some out-of-band signal (possibly from a 1136 higher level protocol) has indicated completion by a sufficient 1137 number of receivers. 1139 For the reasons mentioned above, this document does not pose any 1140 restriction on packet sizes. However, network efficiency 1141 considerations recommend that the sender uses an as large as possible 1142 packet payload size, but in such a way that packets do not exceed the 1143 network's maximum transmission unit size (MTU), or when fragmentation 1144 coupled with packet loss might introduce severe inefficiency in the 1145 transmission. 1147 It is recommended that all packets have the same or very similar 1148 sizes, as this can have a severe impact on the effectiveness of 1149 congestion control schemes such as the ones described in [VIC1998], 1150 [BYE2000], and [LUB2002]. A sender of packets using LCT MUST 1151 implement the sender- side part of one of the congestion control 1152 schemes that is in accordance with [RFC2357] using the Congestion 1153 Control Information field provided in the LCT header, and the 1154 corresponding receiver congestion control scheme is to be 1155 communicated out-of-band and MUST be implemented by any receivers 1156 participating in the session. 1158 6.2. Receiver Operation 1160 Receivers can operate differently depending on the delivery service 1161 model. For example, for an on demand service model, receivers may 1162 join a session, obtain the necessary packets to reproduce the object, 1163 and then leave the session. As another example, for a streaming 1164 service model, a receiver may be continuously joined to a set of LCT 1165 channels to download all objects in a session. 1167 To be able to participate in a session, a receiver MUST obtain the 1168 relevant session description information as listed in Section 6.1. 1170 If packet authentication information is present in an LCT header, it 1171 SHOULD be used as specified in Section 5.2. To be able to be a 1172 receiver in a session, the receiver MUST be able to process the LCT 1173 header. The receiver MUST be able to discard, forward, store or 1174 process the other headers and the packet payload. If a receiver is 1175 not able to process a LCT header, it MUST drop from the session. 1177 To be able to participate in a session, a receiver MUST implement the 1178 congestion control protocol specified in the session description 1179 using the Congestion Control Information field provided in the LCT 1180 header. If a receiver is not able to implement the congestion 1181 control protocol used in the session, it MUST NOT join the session. 1182 When the session is transmitted on multiple LCT channels, receivers 1183 MUST initially join channels according to the specified startup 1184 behavior of the congestion control protocol. For a multiple rate 1185 congestion control protocol that uses multiple channels, this 1186 typically means that a receiver will initially join only a minimal 1187 set of LCT channels, possibly a single one, that in aggregate are 1188 carrying packets at a low rate. This rule has the purpose of 1189 preventing receivers from starting at high data rates. 1191 Several objects can be carried either sequentially or concurrently 1192 within the same LCT session. In this case, each object is identified 1193 by a unique TOI. Note that even if a server stops sending packets 1194 for an old object before starting to transmit packets for a new 1195 object, both the network and the underlying protocol layers can cause 1196 some reordering of packets, especially when sent over different LCT 1197 channels, and thus receivers SHOULD NOT assume that the reception of 1198 a packet for a new object means that there are no more packets in 1199 transit for the previous one, at least for some amount of time. 1201 A receiver MAY be concurrently joined to multiple LCT sessions from 1202 one or more senders. The receiver MUST perform congestion control on 1203 each such LCT session. If the congestion control protocol allows the 1204 receiver some flexibility in terms of its actions within a session 1205 then the receiver MAY make choices to optimize the packet flow 1206 performance across the multiple LCT sessions, as long as the receiver 1207 still adheres to the congestion control rules for each LCT session 1208 individually. 1210 7. Requirements from Other Building Blocks 1212 As described in [RFC3048], LCT is a building block that is intended 1213 to be used, in conjunction with other building blocks, to help 1214 specify a protocol instantiation. A congestion control building 1215 block that uses the Congestion Control information field within the 1216 LCT header MUST be used by any protocol instantiation that uses LCT, 1217 and other building blocks MAY also be used, such as a reliability 1218 building block. 1220 The congestion control MUST be applied to the LCT session as an 1221 entity, i.e., over the aggregate of the traffic carried by all of the 1222 LCT channels associated with the LCT session. The Congestion Control 1223 Information field in the LCT header is an opaque field that is 1224 reserved to carry information related to congestion control. There 1225 MAY also be congestion control Header Extension fields that carry 1226 additional information related to congestion control. 1228 The particular layered encoder and congestion control protocols used 1229 with LCT have an impact on the performance and applicability of LCT. 1230 For example, some layered encoders used for video and audio streams 1231 can produce a very limited number of layers, thus providing a very 1232 coarse control in the reception rate of packets by receivers in a 1233 session. When LCT is used for reliable data transfer, some FEC 1234 codecs are inherently limited in the size of the object they can 1235 encode, and for objects larger than this size the reception overhead 1236 on the receivers can grow substantially. 1238 A more in-depth description of the use of FEC in Reliable Multicast 1239 Transport (RMT) protocols is given in [RFC3453]. Some of the FEC 1240 codecs that MAY be used in conjunction with LCT for reliable content 1241 delivery are specified in [I-D.ietf-rmt-fec-bb-revised]. The 1242 Codepoint field in the LCT header is an opaque field that can be used 1243 to carry information related to the encoding of the packet payload. 1245 LCT also requires receivers to obtain a session description, as 1246 described in Section 6.1 The session description could be in a form 1247 such as SDP as defined in [RFC2327], or XML metadata as defined in 1248 [RFC3023], or HTTP/Mime headers as defined in [RFC2616], and 1249 distributed with SAP as defined in [RFC2974], using HTTP, or in other 1250 ways. It is RECOMMENDED that an authentication protocol be used to 1251 deliver the session description to receivers to ensure the correct 1252 session description arrives. 1254 It is RECOMMENDED that LCT implementors use some packet 1255 authentication scheme to protect the protocol from attacks. An 1256 example of a possibly suitable scheme is described in [RIZ1997a]. 1258 Some protocol instantiations that use LCT MAY use building blocks 1259 that require the generation of feedback from the receivers to the 1260 sender. However, the mechanism for doing this is outside the scope 1261 of LCT. 1263 8. Security Considerations 1265 LCT can be subject to denial-of-service attacks by attackers which 1266 try to confuse the congestion control mechanism, or send forged 1267 packets to the session which would prevent successful reconstruction 1268 or cause inaccurate reconstruction of large portions of an object by 1269 receivers. LCT is particularly affected by such an attack since many 1270 receivers may receive the same forged packet. It is therefore 1271 RECOMMENDED that an integrity check be made on received objects 1272 before delivery to an application, e.g., by appending an MD5 hash 1273 [RFC1321] to an object before it is sent and then computing the MD5 1274 hash once the object is reconstructed to ensure it is the same as the 1275 sent object. Moreover, in order to obtain strong cryptographic 1276 integrity protection a digital signature verifiable by the receiver 1277 SHOULD be computed on top of such a hash value. It is also 1278 RECOMMENDED that protocol instantiations that use LCT implement some 1279 form of packet authentication such as TESLA [PER2001] to protect 1280 against such attacks. Finally, it is RECOMMENDED that Reverse Path 1281 Forwarding checks be enabled in all network routers and switches 1282 along the path from the sender to receivers to limit the possibility 1283 of a bad agent injecting forged packets into the multicast tree data 1284 path. 1286 Another vulnerability of LCT is the potential of receivers obtaining 1287 an incorrect session description for the session. The consequences 1288 of this could be that legitimate receivers with the wrong session 1289 description are unable to correctly receive the session content, or 1290 that receivers inadvertently try to receive at a much higher rate 1291 than they are capable of, thereby disrupting traffic in portions of 1292 the network. To avoid these problems, it is RECOMMENDED that 1293 measures be taken to prevent receivers from accepting incorrect 1294 Session Descriptions, e.g., by using source authentication to ensure 1295 that receivers only accept legitimate Session Descriptions from 1296 authorized senders. 1298 A receiver with an incorrect or corrupted implementation of the 1299 multiple rate congestion control building block may affect health of 1300 the network in the path between the sender and the receiver, and may 1301 also affect the reception rates of other receivers joined to the 1302 session. It is therefore RECOMMENDED that receivers be required to 1303 identify themselves as legitimate before they receive the Session 1304 Description needed to join the session. How receivers identify 1305 themselves as legitimate is outside the scope of this document. 1307 The rudimentary time synchronization features made possible by the 1308 SCT mechanism, or the ERT signaling feature can both be subject to 1309 attacks. Indeed an attacker can easily de-synchronize clients, 1310 sending erroneous SCT information, or mount a DoS attack by informing 1311 all clients that the session (resp. a particular object) is about to 1312 be closed. It is therefore RECOMMENDED that measures be taken to 1313 prevent receivers from accepting incorrect packets, e.g. by using a 1314 source authentication and content integrity mechanism. 1316 9. IANA Considerations 1318 9.1. Namespace declaration for LCT Header Extension Types 1320 This document defines two name-spaces for registration of LCT Header 1321 Extensions Types named: 1322 ietf:rmt:lct:headerExtensionTypes:variableLength 1323 and 1324 ietf:rmt:lct:headerExtensionTypes:fixedLength 1326 The values that can be assigned within the "ietf:rmt:lct: 1327 headerExtensionTypes:variableLength" name-space are numeric indexes 1328 in the range [0, 127] inclusive. The values that can be assigned 1329 within the "ietf:rmt:lct:headerExtensionTypes:fixedLength" name-space 1330 are numeric indexes in the range [128, 255] inclusive. Assignment 1331 requests for both namespaces shall be granted on a "IETF Consensus" 1332 basis as defined in [RFC2434]. 1334 Note that the previous Experimental version of this specification 1335 reserved values in the ranges [64, 127] and [192, 255] for Protocol 1336 Instantiation-specific LCT Header Extensions. In the interests of 1337 simplification and since there were no overlapping allocations of 1338 these LCT Header Extension Type values by Protocol Inatntiations, 1339 this document specifies a single flat space for LCT Header Extension 1340 Types. Values in the range [0,63] and [128,191] SHOULD be used for 1341 Header Extensions which are expected to have broad applicability over 1342 all users of the LCT Building Block. Values outside this range 1343 SHOULD be used for Header Extensions with more limited applicability. 1344 However, these Header Extension Type values are global in scope and 1345 are NOT Protocol-Instantiation specific. 1347 9.2. LCT Header Extension Type registration 1349 This document registers two values in the namespace "ietf:rmt:lct: 1350 headerExtensionTypes:variableLength" as follows: 1352 +-------+----------+--------------------+ 1353 | Value | Name | Reference | 1354 +-------+----------+--------------------+ 1355 | 0 | EXT_NOP | This specification | 1356 | | | | 1357 | 1 | EXT_AUTH | This specification | 1358 | | | | 1359 | 2 | EXT_TIME | This specification | 1360 +-------+----------+--------------------+ 1362 10. Acknowledgments 1364 This specification is substantially based on RFC3451 [RFC3451] and 1365 thus credit for the authorship of this document is primarily due to 1366 the authors of RFC3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, 1367 Luigi Rizzo and Jon Crowcroft. Bruce Lueckenhoff, Hayder Radha and 1368 Justin Chapweske also contributed to RFC3451. Additional thanks are 1369 due to Vincent Roca, Rod Walsh and Toni Paila for contributions to 1370 this update to Proposed Standard. 1372 11. Changes from RFC3451 1374 This section summarises the changes that were made from the 1375 Experimental version of this specification published as RFC3451 1376 [RFC3451]: 1378 o Update all references to the obsoleted RFC 2068 to RFC 2616 1380 o Removed the 'Statement of Intent' from the introduction (The 1381 statement of intent was meant to clarify the "Experimental" status 1382 of RFC3451.) 1384 o Inclusion of material from ALC which is applicable in the more 1385 general LCT context 1387 o Creation of an IANA registry for LCT Header Extensions 1389 o Allocation of the 2 'reserved' bits in the LCT header as "Protocol 1390 Specific Indication" - usage to be defined by protocol 1391 instantiations 1393 o Removal of the Sender Current Time and Expected Residual Time LCT 1394 header fields. 1396 o Inclusion of a new Header Extension, EXT_TIME, to replace the SCT 1397 and ERT and provide for future extension of timing capabilities. 1399 12. References 1401 12.1. Normative References 1403 [I-D.ietf-rmt-fec-bb-revised] 1404 Watson, M., "Forward Error Correction (FEC) Building 1405 Block", draft-ietf-rmt-fec-bb-revised-03 (work in 1406 progress), January 2006. 1408 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1409 August 1980. 1411 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1412 RFC 1112, August 1989. 1414 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1415 Specification, Implementation", RFC 1305, March 1992. 1417 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1418 3", BCP 9, RFC 2026, October 1996. 1420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1421 Requirement Levels", BCP 14, RFC 2119, March 1997. 1423 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1424 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1425 October 1998. 1427 12.2. Informative References 1429 [BYE1998] Byers, J., Luby, M., Mitzenmacher, M., and A. Rege, 1430 "Fountain Approach to Reliable Distribution of Bulk Data", 1431 Proceedings ACM SIGCOMM'98, Vancouver, Canada , 1432 September 1998. 1434 [BYE2000] Byers, J., Frumin, M., Horn, G., Luby, M., Mitzenmacher, 1435 M., Rotter, A., and W. Shaver, "FLID-DL: Congestion 1436 Control for Layered Multicast", Proceedings of Second 1437 International Workshop on Networked Group Communications 1438 (NGC 2000), Palo Alto, CA , November 2000. 1440 [GEM2000] Gemmell, J., Schooler, E., and J. Gray, "Fcast Multicast 1441 File Distribution", IEEE Network, Vol. 14, No. 1, pp. 1442 58-68 , January 2000. 1444 [HOL2001] Holbrook, H., "A Channel Model for Multicast", Ph.D. 1445 Dissertation, Stanford University, Department of Computer 1446 Science, Stanford, CA , August 2001. 1448 [LUB2002] Luby, M., Goyal, V., Skaria, S., and G. Horn, "Wave and 1449 Equation Based Rate Control using Multicast Round-trip 1450 Time", Proceedings of ACM SIGCOMM 2002, Pittsburgh PA , 1451 August 2002. 1453 [PER2001] Perrig, A., Canetti, R., Song, D., and J. Tygar, 1454 "Efficient and Secure Source Authentication for 1455 Multicast", Network and Distributed System Security 1456 Symposium, NDSS 2001, pp. 35-46 , February 2001. 1458 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1459 April 1992. 1461 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 1462 Jacobson, "RTP: A Transport Protocol for Real-Time 1463 Applications", RFC 1889, January 1996. 1465 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1466 Protocol", RFC 2327, April 1998. 1468 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 1469 Criteria for Evaluating Reliable Multicast Transport and 1470 Application Protocols", RFC 2357, June 1998. 1472 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1473 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1474 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1476 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 1477 Announcement Protocol", RFC 2974, October 2000. 1479 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1480 Types", RFC 3023, January 2001. 1482 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1483 Floyd, S., and M. Luby, "Reliable Multicast Transport 1484 Building Blocks for One-to-Many Bulk-Data Transfer", 1485 RFC 3048, January 2001. 1487 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 1488 Reliable Multicast Transport (RMT) Building Blocks and 1489 Protocol Instantiation documents", RFC 3269, April 2002. 1491 [RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, 1492 M., and J. Crowcroft, "Layered Coding Transport (LCT) 1493 Building Block", RFC 3451, December 2002. 1495 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 1496 M., and J. Crowcroft, "The Use of Forward Error Correction 1497 (FEC) in Reliable Multicast", RFC 3453, December 2002. 1499 [RIZ1997] Rizzo, L., "Effective Erasure Codes for Reliable Computer 1500 Communication Protocols", ACM SIGCOMM Computer 1501 Communication Review, Vol.27, No.2, pp.24-36 , April 1997. 1503 [RIZ1997a] 1504 Rizzo, L., "Effective Erasure Codes for Reliable Computer 1505 Communication Protocols", ACM SIGCOMM Computer 1506 Communication Review, Vol.27, No.2, pp.24-36 , April 1997. 1508 [RIZ1997b] 1509 Rizzo, L. and L. Vicisano, "Reliable Multicast Data 1510 Distribution protocol based on software FEC techniques", 1511 Proceedings of the Fourth IEEE Workshop on the 1512 Architecture and Implementation of High Performance 1513 Communication Systems, HPCS'97, Chalkidiki Greece , 1514 June 1997. 1516 [RIZ2000] Rizzo, L., "PGMCC: A TCP-friendly single-rate multicast 1517 congestion control scheme", Proceedings of SIGCOMM 2000, 1518 Stockholm Sweden , August 2000. 1520 [VIC1998] Vicisano, L., Rizzo, L., and J. Crowcroft, "TCP-like 1521 Congestion Control for Layered Multicast Data Transfer", 1522 IEEE Infocom'98, San Francisco, CA , March 1998. 1524 Authors' Addresses 1526 Michael Luby 1527 Digital Fountain 1528 39141 Civic Center Dr. 1529 Suite 300 1530 Fremont, CA 94538 1531 US 1533 Email: luby@digitalfountain.com 1535 Mark Watson 1536 Digital Fountain 1537 39141 Civic Center Dr. 1538 Suite 300 1539 Fremont, CA 94538 1540 US 1542 Email: mark@digitalfountain.com 1544 Lorenzo Vicisano 1545 Cisco Systems, Inc. 1546 510 McCarthy Blvd. 1547 Milpitas, CA 95035 1548 US 1550 Email: lorenzo@cisco.com 1552 Intellectual Property Statement 1554 The IETF takes no position regarding the validity or scope of any 1555 Intellectual Property Rights or other rights that might be claimed to 1556 pertain to the implementation or use of the technology described in 1557 this document or the extent to which any license under such rights 1558 might or might not be available; nor does it represent that it has 1559 made any independent effort to identify any such rights. Information 1560 on the procedures with respect to rights in RFC documents can be 1561 found in BCP 78 and BCP 79. 1563 Copies of IPR disclosures made to the IETF Secretariat and any 1564 assurances of licenses to be made available, or the result of an 1565 attempt made to obtain a general license or permission for the use of 1566 such proprietary rights by implementers or users of this 1567 specification can be obtained from the IETF on-line IPR repository at 1568 http://www.ietf.org/ipr. 1570 The IETF invites any interested party to bring to its attention any 1571 copyrights, patents or patent applications, or other proprietary 1572 rights that may cover technology that may be required to implement 1573 this standard. Please address the information to the IETF at 1574 ietf-ipr@ietf.org. 1576 Disclaimer of Validity 1578 This document and the information contained herein are provided on an 1579 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1580 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1581 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1582 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1583 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1584 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1586 Copyright Statement 1588 Copyright (C) The Internet Society (2006). This document is subject 1589 to the rights, licenses and restrictions contained in BCP 78, and 1590 except as set forth therein, the authors retain all their rights. 1592 Acknowledgment 1594 Funding for the RFC Editor function is currently provided by the 1595 Internet Society.