idnits 2.17.1 draft-ietf-rmt-bb-lct-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** There are 91 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (19 July 2001) is 8314 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 section? '7' on line 994 looks like a reference -- Missing reference section? '9' on line 1002 looks like a reference -- Missing reference section? '12' on line 1015 looks like a reference -- Missing reference section? '10' on line 1006 looks like a reference -- Missing reference section? '3' on line 978 looks like a reference -- Missing reference section? '14' on line 1027 looks like a reference -- Missing reference section? '15' on line 1031 looks like a reference -- Missing reference section? '1' on line 970 looks like a reference -- Missing reference section? '6' on line 989 looks like a reference -- Missing reference section? '13' on line 1021 looks like a reference -- Missing reference section? '11' on line 1011 looks like a reference -- Missing reference section? '5' on line 985 looks like a reference -- Missing reference section? '4' on line 982 looks like a reference -- Missing reference section? '8' on line 998 looks like a reference -- Missing reference section? '2' on line 974 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force RMT WG 2 INTERNET-DRAFT M.Luby/Digital Fountain 3 draft-ietf-rmt-bb-lct-01.txt J.Gemmell/Microsoft 4 L.Vicisano/Cisco 5 L.Rizzo/ACIRI and Univ. Pisa 6 M.Handley/ACIRI 7 J. Crowcroft/UCL 8 19 July 2001 9 Expires: January 2002 11 Layered Coding Transport: 12 A massively scalable content delivery transport 14 Status of this Document 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are valid for a maximum of six months and MAY be 24 updated, replaced, or obsoleted by other documents at any time. It is 25 inappropriate to use Internet-Drafts as reference material or to cite 26 them other than as a "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 To view the list Internet-Draft Shadow Directories, see 32 http://www.ietf.org/shadow.html. 34 This document is a product of the IETF RMT WG. Comments should be 35 addressed to the authors, or the WG's mailing list at rmt@lbl.gov. 37 Abstract 39 This document describes Layered Coding Transport, a massively 40 scalable reliable content delivery and stream delivery 42 ^L 43 transport, hereafter referred to as LCT. LCT can be used for 44 multi-rate delivery to large sets of receivers. In LCT, 45 scalability and congestion control are supported through the 46 use of layered coding techniques. Coding techniques can be 47 combined with LCT to provide support for reliability. 49 Congestion control is receiver driven, and is achieved by 50 sending packets in the session to multiple ``LCT channels'', 51 and having receivers join and leave LCT channels (thus 52 adjusting their reception rate) in reaction to network 53 conditions in a manner that is network friendly. 55 ^L 57 Table of Contents 59 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Related Documents. . . . . . . . . . . . . . . . . . 6 61 1.2. Environmental Requirements and Considerations. . . . 6 62 2. General Architecture. . . . . . . . . . . . . . . . . . 8 63 2.1. Delivery service models. . . . . . . . . . . . . . . 10 64 2.2. Congestion Control . . . . . . . . . . . . . . . . . 11 65 3. LCT packets . . . . . . . . . . . . . . . . . . . . . . 11 66 3.1. LCT packet format. . . . . . . . . . . . . . . . . . 12 67 3.2. LCT packet header fields . . . . . . . . . . . . . . 13 68 3.3. Header-Extension Fields. . . . . . . . . . . . . . . 16 69 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 19 70 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 19 71 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 21 72 5. Security Considerations . . . . . . . . . . . . . . . . 22 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . 22 74 7. Intellectual Property Issues. . . . . . . . . . . . . . 22 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 23 76 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 24 77 10. Full Copyright Statement . . . . . . . . . . . . . . . 26 79 ^L 81 1. Introduction 83 This document describes a massively scalable reliable content delivery 84 and stream delivery transport, Layered Coding Transport (LCT), for 85 multi-rate content delivery primarily designed to be used with the IP 86 multicast network service, but MAY also be used with other basic 87 underlying network or transport services such as unicast UDP. LCT 88 supports both reliable and unreliable delivery, and supports congestion 89 control mechanisms which conform to RFC2357. 91 LCT is a building block as defined in RFC3048. Complete protocol 92 instantiations MAY be built by combining the LCT framework with other 93 components. A complete protocol instantiation that uses LCT MUST 94 include a congestion control protocol that is compatible with LCT and 95 that conforms to RFC2357. A complete protocol instantiation that uses 96 LCT MAY include a scalable reliability protocol that is compatible with 97 LCT, it MAY include an session control protocol that is compatible with 98 LCT, and it MAY include other protocols such as security protocols. 100 LCT is presumed to be used with an underlying network or transport 101 service that is a "best effort" service that does not guarantee packet 102 reception, packet reception order, and which does not have any support 103 for flow or congestion control. For example, the Any-Source Multicast 104 (ASM) model of IP multicast as defined in RFC1112 is such a "best 105 effort" network service. While the basic service provided by RFC1112 is 106 largely scalable, providing congestion control or reliability should be 107 done carefully to avoid severe scalability limitations, especially in 108 presence of heterogeneous sets of receivers. 110 Scalability refers to the behavior of the protocol in relation to the 111 number of receivers and network paths, their heterogeneity, and the 112 ability to accommodate dynamically variable sets of receivers. 113 Scalability limitations can come from memory or processing requirements, 114 or from the amount of packet traffic generated by the protocol. In 115 turn, such limitations may be a consequence of the features that a 116 complete reliable content delivery or stream delivery protocol is 117 expected to provide. 119 Congestion control refers to the ability of the protocol to adapt its 120 throughput to the available bandwidth on the path to the receivers, and 121 to share bandwidth fairly with competing flows such as TCP. It is 122 REQUIRED that protocols implement some form of congestion control on 123 each session so that they not compete unfairly with existing and 124 adaptive protocols such as TCP. 126 For multi-rate protocols, the sender typically sends packets at a 127 constant aggregate rate to multiple channels, but individual receivers 128 adjust which portion of these packets they attempt to receive by 130 ^L 131 adjusting which set of channels they are joined to at each point in time 132 depending on the available bandwidth between the receiver and the 133 sender, but independent of all other receivers. Thus, for multi-rate 134 protocols, the packet reception rate of each receiver may vary 135 dynamically according to the available bandwidth between each receiver 136 and the sender, independent of the other receivers. For single-rate 137 protocols, the sender typically sends packets to one channel at variable 138 rates over time depending on feedback from receivers, and all receivers 139 attempt to receive all packets transmitted by the sender at all points 140 in time. Thus, for single-rate protocols, the packet reception rate of 141 all receivers may vary dynamically over time in exactly the same way 142 dependent on the feedback of other receivers to the sender. Generally, 143 a multi-rate protocol is preferable to a single-rate protocol in a 144 heterogeneous receiver environment, but only if it can be achieved 145 without sacrificing scalability. 147 Layered coding refers to the ability to produce a coded stream that can 148 be split into multiple layers that can be sent to different channels. 149 The coded stream can be generated either from a fixed piece of content, 150 or from an ongoing data stream, and has the property that the quality 151 experienced by a receiver (in terms of quality of playout, or overall 152 transfer speed) is proportional to how many of the layers the receiver 153 is joined to. LCT MAY be combined with a reliability protocol such as 154 the general class of protocols described in [7]. LCT MUST be combined 155 with a congestion control protocol that is compliant with RFC2357, and 156 this MAY be either single-rate or multi-rate congestion control over the 157 entire session. It is most compelling to use LCT in conjunction with a 158 layered congestion control protocol such as the class of protocols 159 described in [9], and specified in [9], which are multi-rate congestion 160 control protocols. 162 The concept of layered coding was first introduced with reference to 163 audio and video streams. For example, the information associated with a 164 TV broadcast can be partitioned into three layers, corresponding to 165 black and white, color, and HDTV quality. Receivers can experience 166 different quality without the need for the sender to replicate 167 information in the different layers. 169 The concept of layered coding can be naturally extended to reliable 170 content delivery protocols when Forward Error Correction (FEC) 171 techniques are used for coding the data stream [12] [10] [3] [14] [15] 172 [1]. By using FEC, the data stream is transformed in such a way that 173 reconstruction of a data object does not depend on the reception of 174 specific data packets, but only on the number of different packets 175 received. As a result, by increasing the number of layers a receiver is 176 receiving from, the receiver can reduce the transfer time accordingly. 177 More details on the use of FEC for reliable content delivery can be 178 found in [6]. Reliable protocols aim at giving guarantees on the 180 ^L 181 reliable delivery of data from the sender to the intended recipients. 182 Guarantees vary from simple packet data integrity to reliable delivery 183 of a precise copy of a data object to all intended recipients. Several 184 reliable content delivery protocols have been built on top of IP 185 multicast, but scalability was not a design goal for many of them. In 186 some cases, scalability is achieved by introducing changes to routers or 187 other infrastructure (see for example [13] ), an approach which has an 188 impact on near term deployment across the Internet. 190 Two of the key difficulties in scaling reliable content delivery using 191 IP multicast are dealing with the amount of data that flows from 192 receivers back to the sender, and the associated response (generally 193 data retransmissions) from the sender. Protocols that avoid any such 194 feedback, and minimize the amount of retransmissions, can be massively 195 scalable. LCT relies on the availability of FEC codes or a layered 196 codec to achieve reliability with little or no feedback. 198 In this document we present the architecture and abstract LCT packet 199 structure, and illustrate its support for multi-rate layered congestion 200 control. 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in RFC2119. 206 1.1. Related Documents 208 A more in-depth description of the use of FEC in Reliable Multicast 209 Transport (RMT) protocols is given in [6]. Some of the FEC codecs that 210 MAY be used by LCT for reliable content delivery are specified in [7]. 211 LCT reserves opaque header fields that can be used to transport 212 information related to the payload encoding. 214 Implementors of LCT MUST also implement congestion control in accordance 215 to RFC2357, where the congestion control is over the entire session. 216 Some possible schemes are specified in [9]. LCT reserves opaque header 217 fields that can be used by the congestion control scheme to transport 218 information related to congestion control. 220 It is RECOMMENDED that LCT implementors use some authentication scheme 221 to protect the protocol from attacks. An example of a possibly suitable 222 scheme is described in [11]. 224 1.2. Environmental Requirements and Considerations 226 LCT is intended for congestion controlled, multi-rate delivery of 227 objects and streams (both reliable content delivery and streaming of 229 ^L 230 multimedia information). 232 LCT is most applicable for delivery of objects or streams of substantial 233 length, i.e., objects or streams that range in length from hundreds of 234 kilobytes to many gigabytes, and whose transfer time is in the order of 235 tens of seconds or more. 237 LCT is directly applicable to all multicast enabled networks, including 238 asymmetric networks, wireless networks, and satellite networks. Thus, 239 the inherent raw scalability of LCT is unlimited. However, when other 240 specific applications are built on top of LCT, then these applications 241 by their very nature may limit scalability. For example, if an 242 application requires receivers to retrieve out of band information in 243 order to join a session, or an application allows receivers to send 244 requests back to the sender in order to extend an ongoing session, then 245 the scalability of the application is limited by the ability to send, 246 receive, and process this additional data. 248 LCT requires that the underlying network or transport layer can deliver 249 and demultiplex LCT packets for a given LCT session, and supply packet 250 length information to the LCT receiver. In IP networks, this is often 251 achieved by using UDP, or any protocol that can provide an equivalent 252 service, as the underlying transport protocol. 254 In this document, we refer to the original multicast service model 255 defined in RFC1112 as Any-Source Multicast, or ASM for short. We refer 256 to the multicast service model defined in [5] as Source-Specific 257 Multicast, or SSM for short. LCT does not require reverse multicast 258 connectivity, i.e. LCT receivers do not send multicast traffic. As 259 such, LCT works with both ASM and SSM. 261 The definition of an LCT channel used throughout this document is 262 slightly different with ASM and with SSM. When using ASM, a sender S 263 sends LCT packets to a multicast group G, and the LCT channel address 264 consists of the pair (S,G), where S is the IP address of the sender and 265 G is a multicast group address. When using SSM, a sender S sends LCT 266 packets to an SSM channel (S,G), and the LCT channel address coincides 267 with the SSM channel address. 269 SSM is more attractive to deployment of LCT than ASM for several 270 reasons. First, a sender may allocate and use several LCT channels in a 271 session, sessions may come and go dynamically. A sender can locally 272 allocate unique SSM channel addresses, and this makes allocation of LCT 273 channel addresses easy with SSM. To allocate LCT channel addresses 274 using ASM, the sender must uniquely chose the ASM multicast group 275 address across the scope of the group, and this makes allocation of LCT 276 channel addresses more difficult with ASM. 278 ^L 279 In general SSM performs well even in presence of very large and 280 dynamically changing receiver sets. Changes in the multicast tree 281 topology with SSM are light weight operations (a new branch from the 282 receiver towards S grows when a receiver joins, and the branch is 283 deleted when the receiver leaves), whereas with ASM changes can be 284 heavier weight (involving transitions from a (*,G)-tree rooted at an RP 285 to the tree rooted at S). This efficiency is important when a 286 congestion control protocol is used with LCT that relies upon joining 287 and leaving channels to nimbly increase and decrease reception rate. 289 LCT channels and SSM channels coincide, and thus the receiver will only 290 receive packets sent to the requested LCT channel. With ASM, the 291 receiver joins an LCT channel by joining a multicast group G, and all 292 packets sent to G, regardless of the sender, may be received by the 293 receiver. In either case, receivers should use mechanisms to filter out 294 packets from unwanted sources. Thus, SSM has compelling security 295 advantages over ASM for prevention of denial of service attacks. 297 LCT also requires receivers to obtain Session Description Information 298 before joining a session, as described in Section 4.1. The session 299 description could be in a form such as SDP as defined in RFC2327, or XML 300 metadata, or HTTP/Mime headers as defined in RFC2068, and distributed 301 with SAP [4], using RCCP [8], HTTP, or in other ways. 303 The particular layered encoder and congestion control protocols used 304 with LCT have an impact on the performance and applicability of LCT. 305 For example, some layered encoders used for video and audio streams can 306 produce a very limited number of substreams, thus providing a very 307 coarse control in the reception rate of packets by receivers in a 308 session. When LCT is used for reliable data transfer, some FEC codecs 309 are inherently limited in the size of the object they can encode, and 310 for objects larger than this size the reception overhead on the 311 receivers can grow substantially. 313 As another example, some networks are not amenable to some congestion 314 control protocols that could be used with LCT. In particular, for a 315 satellite or wireless network, there may be no mechanism for receivers 316 to effectively reduce their reception rate since there may be a fixed 317 transmission rate allocated to the session. 319 2. General Architecture 321 An LCT session comprises all LCT packets sent to one or more LCT 322 channels from a single sender, and pertaining to the transmission of one 323 or more objects that can be of interest for the receivers. 325 For example, an LCT session could be used to deliver a TV channel using 327 ^L 328 three channels. Receiving the first channel could allow black and white 329 reception, receiving the first two channels would permit color 330 reception, whereas receiving the set of three channels delivers HDTV 331 quality images. Objects in this example could correspond to individual 332 programs (movies, news, commercial) being transmitted. 334 As another example, a reliable LCT session could be used to reliably 335 deliver hourly-updated weather maps (objects) using ten LCT channels at 336 different rates, using FEC coding. A receiver MAY join and concurrently 337 receive LCT packets from subsets of these channels, until it has enough 338 packets in total to recover the object, then leave the session (or 339 remain there listening to control information only) until it is time to 340 receive the next object. In this case, the quality metric is the time 341 required to receive each object. 343 Before joining a session, the receivers MUST obtain a session 344 description, which MUST include the relevant session parameters needed 345 by a receiver to participate in the session. The session description is 346 determined and agreed upon by the senders, and typically communicated to 347 the receivers out of band. In some cases, part of the session 348 description MAY be included in the LCT packet. 350 An encoder MAY be used to generate the data that is placed in the LCT 351 packet payload in order to provide reliability. A suitable decoder is 352 used to reproduce the original information from the payload. There MAY 353 be a reliability packet header that follows the LCT packet header if 354 such an encoder and decoder is used. The reliability packet header 355 helps to describe the encoding data carried in the payload of the 356 packet. The format of the reliability packet header depends on the 357 coding used, and this is negotiated out-of-band. As an example, one of 358 the FEC packet headers described in [7] could be used. 360 For LCT, when layered congestion control is used, congestion control is 361 achieved by sending LCT packets associated with a given session to 362 several LCT channels. Individual receivers dynamically join one or more 363 of these channels, according to the network congestion as seen by the 364 receiver. LCT packet headers include an opaque field which MUST be used 365 to convey congestion control information to the receivers. The actual 366 congestion control scheme to use with LCT is negotiated out-of-band. 367 Some examples of congestion control protocols that MAY be suitable for 368 content delivery are described in [9]. Other congestion controls MAY be 369 suitable when LCT is used for a streaming application. 371 LCT can be used with other congestion control protocols such as the one 372 described in [14], or router-assisted schemes where the selection of 373 which packets to forward is performed by routers. This latter approach 374 potentially allows for finer grain congestion control and a faster 375 reaction to network congestion, but requires changes to the router 377 ^L 378 infrastructure. See [2] for a preliminary design description. We do 379 not discuss this approach further in this document. 381 2.1. Delivery service models 383 LCT can support several different delivery service models. Two examples 384 are briefly described here. 386 Push service model. 388 One way a push service model can be used for reliable content delivery 389 is to deliver a series of objects. For example, a receiver could join 390 the session and dynamically adapt the number of LCT channels the 391 receiver is joined to until enough packets have been received to 392 reconstruct an object. After reconstructing the object the receiver may 393 stay in the session and wait for the transmission of the next object. 395 The push model is particularly attractive in satellite networks and 396 wireless networks. In these cases, a session may consist of one fixed 397 rate LCT channel. 399 On-demand content delivery model. 401 For an on-demand content delivery service model, senders typically 402 transmit for some given time period selected to be long enough to allow 403 all the intended receivers to join the session and recover the object. 404 For example a popular software update might be transmitted using LCT for 405 several days, even though a receiver may be able to complete the 406 download in one hour total of connection time, perhaps spread over 407 several intervals of time. 409 In this case the receivers join the session, and dynamically adapt the 410 number of LCT channels they subscribe to (and the reception quality) 411 according to the available bandwidth. Receivers then drop from the 412 session when they have received enough packets to recover the object. 414 As an example, assume that an object is 50 MB. The sender could set the 415 data rate on the lowest LCT channel to 50 1KB packets per second, so 416 that receivers using just this LCT channel could complete reception of 417 the object in 1,000 seconds in absence of loss, and would be able to 418 complete reception even in presence of some substantial amount of losses 419 with the use of coding for reliability. Furthermore, the sender could 420 use a number of LCT channels such that the aggregate data rate when 421 using all LCT channels is 1,000 1KB packets per second, so that a 422 receiver could be able to complete reception of the object in as little 424 ^L 425 50 seconds (assuming no loss and that the congestion control mechanism 426 immediately converges to the use of all LCT channels). 428 Other service models. 430 There are many other delivery service models that LCT can be used for 431 that are not covered above. As examples, a live streaming or an on- 432 demand archival content streaming service model. The description of the 433 many potential applications, the appropriate delivery service model, and 434 the additional mechanisms to support such functionalities when combined 435 with LCT is beyond the scope of this document. This document only 436 attempts to describe the minimal common scalable elements to these 437 diverse applications using LCT as the delivery transport. 439 2.2. Congestion Control 441 The specific congestion control protocol to be used for LCT sessions 442 depends on the type of content to be delivered. While the general 443 behavior of the congestion control protocol is to reduce the throughput 444 in presence of congestion and gradually increase it in the absence of 445 congestion, the actual dynamic behavior (e.g. response to single losses) 446 can vary. 448 Some possible congestion control protocols for reliable content delivery 449 using LCT are described in [9]. Different delivery service models might 450 require a different congestion control protocols. 452 3. LCT packets 454 The type of packet used by LCT sessions is "LCT Packet". LCT packets 455 are sent by senders to LCT channels. 457 Some instances of LCT sessions MAY require the generation of feedback 458 from the receivers to the sender. However, the mechanism for doing this 459 is outside the scope of LCT. 461 The LCT packet format described in this document is intended to be used 462 in conjunction with the UDP transport protocol as defined in RFC768 or 463 other transport protocols that satisfy the requirements stated in 464 Section 1.2, specifically about demultiplexing and delivery of packet 465 size information. 467 LCT packets consist of an LCT packet header and an OPTIONAL LCT packet 468 payload, as shown in Figure 1. When present, the LCT packet payload 470 ^L 471 immediately follows the LCT packet header. The LCT packet payload MAY 472 contain headers for other protocols, such as reliability protocols. 474 LCT packet headers have variable size, which is specified by a length 475 field in the third byte of the header. In the LCT packet header, all 476 integer fields are carried in "big-endian" or "network order" format, 477 that is, most significant byte (octet) first. Bits designated as 478 "padding" or "reserved" (r) MUST by set to 0 by senders and ignored by 479 receivers. Unless otherwise noted, numeric constants in this 480 specification are in decimal (base 10). 482 3.1. LCT packet format 484 The format of LCT packets is depicted in Figure 1. 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | V | r | I |S|E|X|A|B| HDR_LEN | Codepoint (CP)| 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Congestion Control Information (CCI) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Transport Object Identifier (TOI, if I >= 1) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | TOI continued (if I >= 2) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | TOI continued (if I = 3) | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | TOI continued (if I = 3) | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Sender Current Time (SCT, if S = 1) | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Expected Residual Time (ERT, if E = 1) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Header Extensions (if X = 1 ) | 506 | | 507 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 508 | | 509 | Payload | 510 | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure 1 - LCT packet format 515 ^L 516 3.2. LCT packet header fields 518 The function each field in LCT packet headers is the following. Fields 519 marked as "1" mean that the corresponding bits MUST be set to "1" by the 520 generating agent. Fields marked as "r" or "0" mean that the 521 corresponding bits MUST be set to "0" by the generating agent. 523 LCT version number (V): 4 bits 525 Indicates the LCT protocol version. The LCT version number for 526 this specification is 0. 528 Reserved (r): 5 bits 530 Reserved for future use. A sender MUST set these bits to zero and 531 a receiver MUST ignore these bits. 533 Transport Object Identifier flag (I): 2 bits 535 I=0 indicates no Transport Object Identifier (TOI) field is 536 present. 537 I=1 indicates that a 32-bit TOI field is present. 538 I=2 indicates that a 64-bit TOI field is present. 539 I=3 indicates that a 128-bit TOI field is present. 540 The TOI field indicates which object within the session this LCT 541 packet pertains to. 543 Sender Current Time present flag (S): 1 bit 545 S = 0 indicates that the Sender Current Time (SCT) field is not 546 present. 547 S = 1 indicates that the SCT field is present. 548 The SCT is inserted by senders to indicate to receivers how long 549 the session has been in progress. 551 Expected Residual Time present flag (E): 1 bit 553 E = 0 indicates that the Expected Residual Time (ERT) field is not 554 present. 555 E = 1 indicates that the ERT field is present. 556 The ERT is inserted by senders to indicate to receivers how much 557 longer the session will continue. 558 Senders MUST NOT set E = 1 when the ERT for the session is more 560 ^L 561 than 2^32-1 time units (approximately 49 days), where time is 562 measured in units of milliseconds. 564 Header extension present flag (X): 1 bit 566 X = 0 indicates no Header Extensions are present. 567 X = 1 indicates that Header Extensions are present. 568 Header Extensions are used in LCT to accommodate OPTIONAL header 569 fields which are not always used or have variable size. 571 Close TOI flag (A): 1 bit 573 Normally, the Close TOI flag is set to 0. The sender MAY set the 574 Close TOI flag to 1 when termination of transmission of LCT 575 packets for the object identified by the TOI is imminent. The 576 Close TOI flag MAY be set to 1 in just the last LCT packet 577 transmitted for the object, or it MAY be set to 1 in the last 578 couple of seconds LCT packets transmitted for the object. Once 579 the sender sets the Close TOI flag to 1 in one packet for a 580 particular object, the sender SHOULD set the Close TOI flag to 1 581 in all subsequent packets for the object until termination of 582 transmission of LCT packets for the object. A received packet 583 with the Close TOI flag set to 1 indicates to a receiver that the 584 sender will immediately stop sending LCT packets for the object 585 identified by the TOI. When a receiver receives a packet with the 586 Close TOI flag set to 1 then it should assume that no more LCT 587 packets will be sent to the session for this object. 589 Close Session flag (B): 1 bit 591 Normally, the Close Session flag is set to 0. The sender MAY set 592 the Close Session flag to 1 when termination of transmission of 593 LCT packets for the session is imminent. The Close Session flag 594 MAY be set to 1 in just the last LCT packet transmitted for the 595 session, or it MAY be set to 1 in the last couple of seconds LCT 596 packets transmitted for the session. Once the sender sets the 597 Close Session flag to 1 in one packet, the sender SHOULD set the 598 Close Session flag to 1 in all subsequent packets until 599 termination of transmission of LCT packets for the session. A 600 received packet with the Close Session flag set to 1 indicates to 601 a receiver that the sender will immediately stop sending LCT 602 packets for the session. When a receiver receives a packet with 603 the Close Session flag set to 1 then it should assume that no more 604 LCT packets will be sent to the session. 606 ^L 608 LCT packet header length (HDR_LEN): 8 bits 610 Length of the LCT packet header in units of 32-bit words 611 (excluding IP or UDP headers). 612 This field can be used for direct access to the beginning of the 613 LCT packet payload. 615 Codepoint (CP): 8 bits 617 An opaque identifier which is passed to the payload decoder to 618 convey information on the codec being used for the payload. The 619 mapping between the codepoint and the actual codec is defined on a 620 per session basis and communicated out-of-band as part of the 621 session description information. The use of the CP field is 622 similar to the Payload Type (PT) field in RTP headers as described 623 in RFC1889. 625 Congestion Control Information (CCI): 32 bits 627 Used to carry congestion control information, e.g. for the 628 congestion control specified in [9] or other congestion control 629 schemes. This field is opaque for the purpose of this 630 specification. 632 Transport Object Identifier (TOI): 32, 64 or 128 bits (OPTIONAL) 634 This field indicates which object within the session this LCT 635 packet pertains to. For example, a sender might send a number of 636 files in the same session, using TOI=0 for the first file, TOI=1 637 for the second one, etc. The mapping of TOI field values to 638 objects MUST be done out of band. 639 This field MUST NOT be present if I=0. 640 This field MUST be 32 bits if I=1. 641 This field MUST be 64 bits if I=2. 642 This field MUST be 128 bits if I=3. 644 Sender Current Time (SCT): 32 bits (OPTIONAL) 646 This field represents the current clock at the sender at the time 647 this packet was transmitted, measured in units of 1ms and computed 648 modulo 2^32 units from the start of the session. 649 This field MUST NOT be present if S=0 and MUST be present if S=1. 651 ^L 653 Expected Residual Time (ERT): 32 bits (OPTIONAL) 655 This field represents the sender expected residual transmission 656 time for the current session, measured in units of 1ms. 657 This field MUST NOT be present if E=0 and MUST be present if E=1. 659 3.3. Header-Extension Fields 661 To allow for additional header fields and to extend the size of some of 662 the predefined fields, the LCT packet header contains an additional 663 header field flag, "X". If "X" is set to 0 then no additional header 664 fields are included within the LCT packet header beyond the predefined 665 fields. When additional headers beyond the predefined fields are used, 666 the value of "X" within the LCT packet header MUST be set to 1. 668 Examples of use of Header Extensions include: 670 o Extended-size version of already existing header fields. 672 o Sender and Receiver authentication information. 674 If present, Header Extensions MUST be processed to ensure that they are 675 recognized before performing any congestion control procedure or 676 otherwise accepting an LCT packet. LCT packets with unrecognised Header 677 Extensions MUST be discarded by the receiving agent, hence the expected 678 use of extensions SHOULD be signaled out-of-band before session startup. 680 There are two formats for Header Extension fields, as depicted below. 681 The first format is used for variable-length extensions, with Header 682 Extension Type (HET) values between 0 and 63. The second format is used 683 for fixed length (one word) extension, using HET values from 64 to 127. 685 ^L 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 |L| HET (<=63) | HEL | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 691 . . 692 . Header Extension Content (HEC) . 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |L| HET (>=64) | Header Extension Content (HEC) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Figure 5 - Format of additional headers 703 The explanation of each sub-field is the following. 705 Last Header Extension (L): 1 bit 707 MUST be set to 1 in the last Header Extension field present in an 708 LCT packet header, MUST be set to 0 in all the others. 710 Header Extension Type (HET): 7 bits 712 The type of the Header Extension. This document defines a number 713 of possible types. Additional types may be defined in future 714 version of this specification. HET values from 0 to 63 are used 715 for variable-length Header Extensions. HET values from 64 to 127 716 are used for fixed-length Header Extensions. 718 Header Extension Length (HEL): 8 bits 720 The length of the whole Header Extension field, expressed in 721 multiples of 32-bit words. This field MUST be present for 722 variable-length extensions (HET between 0 and 63) and MUST NOT be 723 present for fixed-length extensions (HET between 64 and 127). 725 Header Extension Content (HEC): variable length 727 ^L 728 The content of the Header Extension. The format of this sub-field 729 depends on the Header Extension type. For fixed-length Header 730 Extensions, the HEC is 24 bits. For variable-length Header 731 Extensions, the HEC field has variable size, as specified by the 732 HEL field. Note that the length of each Header Extension field 733 MUST be a multiple of 32 bits. Also note that the total size of 734 the LCT packet header, including all Header Extensions and all 735 OPTIONAL header fields, cannot exceed 255 32-bit words. 737 An LCT packet with Header Extensions MUST NOT have space between the end 738 of the last Header Extension and the beginning of the LCT packet 739 payload. 741 All senders and receivers of LCT packets MUST support the EXT_NOP Header 742 Extension. 744 The following Header Extension types are defined: 746 EXT_NOP=0 No-Operation extension. 747 The information present in this extension field MUST be 748 ignored by receivers. 750 EXT_CCI_V=1 Congestion Control Information extension, variable length. 751 This extension field extends the CCI field present in the 752 fixed part of the header. It is used when the congestion 753 control information does not fit in the 32-bit CCI field. 754 When this option is present, the concatenation of the 755 32-bit CCI field in the fixed part of the header together 756 with the variable length value provided in this option is 757 used as the congestion control information. The 758 interpretation of the data contained in EXT_CCI_V MUST be 759 negotiated out-of-band. The use of EXT_CCI_V and 760 EXT_CCI_F is mutually exclusive. 762 EXT_AUTH=2 Authentication extension 763 Information used to authenticate the sender of the LCT 764 packet. If present, the format of this Header Extension 765 and its processing MUST be communicated out-of-band as 766 part of the session description. 767 It is RECOMMENDED that senders provide some form of 768 authentication on the LCT packets they transmit. If 769 EXT_AUTH is present, whatever authentication checks that 770 can be performed immediately upon reception of the packet 771 MUST be performed before accepting the packet and 773 ^L 774 performing any congestion control-related action on it. 775 Some authentication schemes impose a delay of several 776 seconds between when a packet is received and when the 777 packet is fully authenticated. Any congestion control 778 related action that is appropriate MUST NOT be delayed by 779 any such full authentication delay. 781 EXT_CCI_F=65 Congestion Control Information extension, fixed length. 782 This extension field extends the CCI field present in the 783 fixed part of the header. It is used when the congestion 784 control information does not fit in the 32-bit CCI field. 785 When this option is present, the concatenation of the 786 32-bit CCI field in the fixed part of the header together 787 with the 24-bit fixed length value provided in this option 788 is used as the congestion control information. The 789 interpretation of the data contained in EXT_CCI_F MUST be 790 negotiated out-of-band. The use of EXT_CCI_V and 791 EXT_CCI_F is mutually exclusive. 793 4. Procedures 795 4.1. Sender Operation 797 Before a session starts, an LCT sender MUST make available all 798 applicable information regarding the session. This information could 799 include, but is not limited to: 801 o The number of LCT channels; 803 o The addresses, port numbers and data rates used for each LCT 804 channel; 806 o The format of the payload. For example, the payload could contain 807 other protocol headers such as an FEC header. Then for example the 808 information could include the mapping of codepoints used in the 809 session to FEC codec types and parameters; 811 o The congestion control scheme being used; 813 o The possible Header Extensions that could be used in the session; 815 o The mapping of TOI value(s) to objects for the session; 817 o The authentication scheme being used, and all relevant information 818 which is necessary for sender authentication purposes; 820 ^L 822 The session description could be in a form such as SDP as defined in 823 RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a 824 session announcement protocol such as SAP [4], obtained using RCCP 825 session control as described in [8], located on a Web page with 826 scheduling information, or conveyed via E-mail or other out of band 827 methods. Discussion of session description format, and distribution of 828 session descriptions is beyond the scope of this document. 830 Within an LCT session, an LCT sender transmits a sequence of LCT packets 831 each containing a payload encoded according to one of the codecs defined 832 in the session description. LCT packets are sent over one or more LCT 833 channels which together constitute a session. Transmission rates MAY be 834 different in different channels. This document does not specify the LCT 835 packet payload, nor the order in which LCT packets are transmitted, nor 836 the organization of a session into multiple channels. Although these 837 issues affect the efficiency of the protocol, they do not affect the 838 correctness nor the inter-operability between senders and receivers. 840 Multiple objects can be carried within the same LCT session. In this 841 case, each object is identified by a unique TOI. Objects MAY be 842 transmitted sequentially, or they MAY be transmitted concurrently. 844 Typically, the sender(s) continues to send LCT packets in a session 845 until the transmission is considered complete. The transmission MAY be 846 considered complete when some time has expired, a certain number of 847 packets have been sent, or some out of band signal (possibly from a 848 higher level protocol) has indicated completion by a sufficient number 849 of receivers. 851 The specification of the processing of the payload carried in LCT 852 packets is beyond the scope of this document. LCT will act as a 853 transport layer and convey payload and associated information (Codepoint 854 and TOI) to the receivers and any complete protocol using LCT will 855 implement congestion control . 857 For the reasons mentioned above, this document does not pose any 858 restriction on LCT packet sizes. However, network efficiency 859 considerations recommend that the sender uses as large as possible 860 payload size, but in such a way that LCT packets do not exceed the 861 network's maximum transmission unit size (MTU), or fragmentation coupled 862 with packet loss might introduce severe inefficiency in the 863 transmission. 865 It is also RECOMMENDED that all LCT packets have the same or very 866 similar sizes, as this can have a severe impact on the effectiveness of 867 congestion control schemes such as the ones described in [9]. A sender 868 of LCT packets MUST implement the sender-side part of one of the 869 congestion control schemes that is in accordance with RFC2357, and the 871 ^L 872 corresponding receiver congestion control scheme MUST be communicated 873 out of band and implemented by any receivers participating in the 874 session. 876 4.2. Receiver Operation 878 Receivers can operate differently depending on the delivery service 879 model. For example, for an on demand service model receivers MAY join a 880 session, obtain the necessary encoding symbols to reproduce the object, 881 and then leave the session. As another example, for a streaming service 882 model a receiver MAY be continuously joined to a set of LCT channels to 883 download all objects in a session. 885 To be able to participate in a session, a receiver MUST first obtain the 886 relevant session description information as listed in Section 4.1. 888 To be able to participate in a session, a receiver MUST implement the 889 congestion control protocol specified in the session description. If a 890 receiver is not able to implement the congestion control protocol used 891 in the session, it MUST NOT join the session. 893 If sender authentication information is present in an LCT packet header, 894 it MUST be used as specified in Section 3.3. If a receiver is unable to 895 implement the authentication mechanism used by the session, it MUST NOT 896 join the session. 898 To be able to be a receiver in a session, the receiver MUST be able to 899 process the LCT packet header. The receiver MUST be able to discard, 900 forward, store or process the LCT packet payload. If a receiver is not 901 able to process a LCT packet header, it MUST either drop from the 902 session, or reduce the receive bandwidth to the minimum value allowed by 903 the congestion control protocol being used. 905 When the session is transmitted on multiple LCT channels, receivers MUST 906 do it according to the specified startup behavior of the congestion 907 control protocol itself. For a layered transmission on multiple 908 channels, this typically means that a receiver will initially join only 909 a minimal set of LCT channels, possibly a single one. This rule has the 910 purpose of preventing receivers from starting at high data rates. 912 Multiple objects can be carried within the same LCT session. In this 913 case, each object is identified by a unique TOI. Note that even if a 914 server stops sending LCT packets for an old object before starting to 915 transmit LCT packets for a new object, both the network and the 916 underlying protocol layers can cause some reordering of packets, 917 especially when sent over different LCT channels, and thus receivers 919 ^L 920 MUST NOT assume that the reception of an LCT packet for a new object 921 means that there are no more LCT packets in transit for the previous 922 one, at least for some amount of time. 924 A receiver MAY be concurrently joined to multiple LCT sessions. The 925 receiver MUST perform congestion control on each such LCT session. If 926 the congestion control protocol allows the receiver some flexibility in 927 terms of its actions within a session then the receiver MAY make choices 928 to optimize the packet flow performance across the multiple LCT 929 sessions, as long as the receiver still adheres to the congestion 930 control rules for each LCT session individually. 932 5. Security Considerations 934 LCT can be subject to denial-of-service attacks by attackers which try 935 to confuse the congestion control mechanism, or send forged packets to 936 the session which would prevent successful reconstruction of large 937 portions of the data stream. 939 The same exact problems are present in TCP, where an attacker can forge 940 packets and either slow down or increase the throughput of the session, 941 or replace parts of the data stream with forged data. If the stream is 942 carrying compressed or otherwise coded data, even a single forged packet 943 could also cause incorrect reconstruction of the rest of the data 944 stream. 946 It is therefore RECOMMENDED that LCT agents implement some form of 947 authentication to protect themselves against such attacks. 949 6. IANA Considerations 951 No information in this specification is subject to IANA registration. 953 Building blocks components used by LCT may introduce additional IANA 954 considerations. 956 7. Intellectual Property Issues 958 No specific reliability protocol or congestion control protocol is 959 specified or referenced as mandatory in this document. 961 LCT MAY be used with congestion control protocols and other protocols 962 which are proprietary, or have pending or granted patents. 964 ^L 965 8. Acknowledgments 967 Thanks to Vincent Roca, Bruce Lueckenhoff and Hayder Radha for detailed 968 comments on this document. 970 [1] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital 971 Fountain Approach to Reliable Distribution of Bulk Data", Proceedings 972 ACM SIGCOMM '98, Vancouver, Canada, Sept 1998. 974 [2] Cain, B., Speakman, T., and Towsley, D., "Generic Router Assist 975 (GRA) Building Block, Motivation and Architecture", Internet Draft 976 draft-ietf-rmt-gra-arch-00.txt, a work in progress. 978 [3] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable Multicast 979 File Distribution: Caching and Parameters Optimizations", Technical 980 Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999. 982 [4] Handley, M., "SAP: Session Announcement Protocol", Internet Draft, 983 IETF MMUSIC Working Group, Nov 1996, a work in progress. 985 [5] Holbrook, H., Cain, B., "Source-Specific Multicast for IP", Internet 986 Draft, SSM Working Group, March 2001, draft-holbrook-ssm-arch-02.txt, a 987 work in progress. 989 [6] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M., 990 Crowcroft, J., "The use of Forward Error Correction in Reliable 991 Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November 992 2000, a work in progress. 994 [7] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., 995 Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft 996 draft-ietf-rmt-bb-fec-03.txt, July 2001. 998 [8] Luby, M., Hernek, D., Kushi, D., Rasmussen, L., Simu, S., Vainish, 999 R., "Rich Content Control Protocol: A session control protocol 1000 instantiation", Digital Fountain document, a work in progress. 1002 [9] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion 1003 control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in 1004 progress. 1006 [10] Rizzo, L., "Effective Erasure Codes for Reliable Computer 1007 Communication Protocols", ACM SIGCOMM Computer Communication Review, 1008 Vol.27, No.2, pp.24-36, Apr 1997. 1010 ^L 1011 [11] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA: 1012 Multicast Source Authentication Transform", draft-irtf-smug- 1013 tesla-00.txt, November, 2000, a work in progress. 1015 [12] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution 1016 protocol based on software FEC techniques", Proceedings of the Fourth 1017 IEEES Workshop on the Architecture and Implementation of High 1018 Performance Communication Systems, HPCS'97, Chalkidiki, Greece, June 1019 1997. 1021 [13] Speakman, T., Farinacci, D., Crowcroft, J., Gemmell, J., Lin, S., 1022 Tweedly, A., Leshchiner, D., Luby, M., Bhaskar, N., Edmonstone, R., 1023 Johnson, K., Montgomery, T., Rizzo, L., Sumanasekera, R., Vicisano, L., 1024 "PGM Reliable Transport Protocol", draft-speakman-pgm-spec-06.txt, a 1025 work in progress. 1027 [14] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion 1028 Control for Layered Multicast Data Transfer", IEEE Infocom '98, San 1029 Francisco, CA, Mar.28-Apr.1 1998. 1031 [15] Vicisano, L., "Notes On a Cumulative Layered Organization of Data 1032 Packets Across Multiple groups with Different Rates", University College 1033 London Computer Science Research Note RN/98/25, Work in Progress (May 1034 1998). 1036 9. Authors' Addresses 1038 Michael Luby 1039 luby@digitalfountain.com 1040 Digital Fountain 1041 39141 Civic Center Drive 1042 Suite 300 1043 Fremont, CA, USA, 94538 1045 Jim Gemmell 1046 jgemmell@microsoft.com 1047 Microsoft Research 1048 301 Howard St., #830 1049 San Francisco, CA, USA, 94105 1051 Lorenzo Vicisano 1052 lorenzo@cisco.com 1053 cisco Systems, Inc. 1054 170 West Tasman Dr., 1055 San Jose, CA, USA, 95134 1057 ^L 1058 Luigi Rizzo 1059 luigi@iet.unipi.it 1060 ACIRI/ICSI, 1061 1947 Center St, Berkeley, CA, USA, 94704 1062 and 1063 Dip. Ing. dell'Informazione, 1064 Univ. di Pisa 1065 via Diotisalvi 2, 56126 Pisa, Italy 1067 Mark Handley 1068 mjh@aciri.org 1069 ACIRI, 1070 1947 Center St, 1071 Berkeley, CA, USA, 94704 1073 Jon Crowcroft 1074 J.Crowcroft@cs.ucl.ac.uk 1075 Department of Computer Science 1076 University College London 1077 Gower Street, 1078 London WC1E 6BT, UK 1080 ^L 1082 10. Full Copyright Statement 1084 Copyright (C) The Internet Society (2000). All Rights Reserved. 1086 This document and translations of it may be copied and furnished to 1087 others, and derivative works that comment on or otherwise explain it or 1088 assist in its implementation may be prepared, copied, published and 1089 distributed, in whole or in part, without restriction of any kind, 1090 provided that the above copyright notice and this paragraph are included 1091 on all such copies and derivative works. However, this document itself 1092 may not be modified in any way, such as by removing the copyright notice 1093 or references to the Internet Society or other Internet organizations, 1094 except as needed for the purpose of developing Internet standards in 1095 which case the procedures for copyrights defined in the Internet 1096 languages other than English. 1098 The limited permissions granted above are perpetual and will not be 1099 revoked by the Internet Society or its successors or assigns. 1101 This document and the information contained herein is provided on an "AS 1102 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1103 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1104 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1105 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1106 FITNESS FOR A PARTICULAR PURPOSE." 1108 ^L