idnits 2.17.1 draft-ietf-rmt-bb-lct-00.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 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** There are 83 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The originator of a packet with header extensions MUST not leave additional space between the end of the last Header Extension and the beginning of the LCT payload. -- 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 (17 November 2000) is 8558 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? '5' on line 1019 looks like a reference -- Missing reference section? '15' on line 1056 looks like a reference -- Missing reference section? '16' on line 1062 looks like a reference -- Missing reference section? '7' on line 1026 looks like a reference -- Missing reference section? '17' on line 1066 looks like a reference -- Missing reference section? '18' on line 1070 looks like a reference -- Missing reference section? '3' on line 1011 looks like a reference -- Missing reference section? '11' on line 1039 looks like a reference -- Missing reference section? 'PGM' on line 154 looks like a reference -- Missing reference section? '2' on line 1008 looks like a reference -- Missing reference section? '12' on line 1044 looks like a reference -- Missing reference section? '13' on line 1050 looks like a reference -- Missing reference section? '1' on line 1005 looks like a reference -- Missing reference section? '10' on line 1036 looks like a reference -- Missing reference section? '8' on line 1030 looks like a reference -- Missing reference section? '6' on line 1022 looks like a reference -- Missing reference section? '4' on line 1015 looks like a reference -- Missing reference section? '14' on line 1054 looks like a reference -- Missing reference section? '9' on line 1033 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 21 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-00.txt J.Gemmell/Microsoft 4 L.Vicisano/Cisco 5 L.Rizzo/ACIRI and Univ. Pisa 6 M.Handley/ACIRI 7 J. Crowcroft/UCL 8 17 November 2000 9 Expires: May 2001 11 Layered Coding Transport: 12 A massively scalable multicast protocol 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 multicast protocol, hereafter referred to as LCT. 42 ^L 43 LCT can be used for multi-rate content delivery (for both 44 reliable bulk data transfer and unreliable data streams) to 45 large sets of receivers. In LCT, scalability and congestion 46 control are supported through the use of layered coding 47 techniques. When LCT is used for reliable data transfer, the 48 coding also provides support for reliability. 50 Congestion control is receiver driven, and is achieved by 51 sending packets in the session to multiple ``LCT groups'', and 52 having receivers join and leave LCT groups (thus adjusting 53 their reception rate) in reaction to network conditions in a 54 manner that is network friendly. 56 ^L 58 Table of Contents 60 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Related Documents. . . . . . . . . . . . . . . . . . 5 62 1.2. Environmental Requirements . . . . . . . . . . . . . 6 63 2. General Architecture. . . . . . . . . . . . . . . . . . 8 64 2.1. Delivery service models. . . . . . . . . . . . . . . 9 65 2.2. Congestion Control . . . . . . . . . . . . . . . . . 10 66 3. Packet Formats. . . . . . . . . . . . . . . . . . . . . 11 67 3.1. Data-Packet format . . . . . . . . . . . . . . . . . 11 68 3.2. Request-Packet format. . . . . . . . . . . . . . . . 12 69 3.3. LCT Packet header fields . . . . . . . . . . . . . . 13 70 3.4. Transmission Extensions. . . . . . . . . . . . . . . 15 71 3.5. Header-Extension Fields. . . . . . . . . . . . . . . 16 72 4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 19 73 4.1. Sender Operation . . . . . . . . . . . . . . . . . . 19 74 4.2. Receiver Operation . . . . . . . . . . . . . . . . . 21 75 5. Security Considerations . . . . . . . . . . . . . . . . 23 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . 23 77 7. Intellectual Property Issues. . . . . . . . . . . . . . 23 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 24 79 9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 25 80 10. Full Copyright Statement . . . . . . . . . . . . . . . 27 82 ^L 84 1. Introduction 86 This document describes a massively scalable protocol, Layered Coding 87 Transport (LCT), for multi-rate content delivery using IP multicast. LCT 88 supports both reliable and unreliable data transfer, and supports a 89 congestion control mechanism which conformings to RFC2357. 91 IP multicast [5] is a "best effort" service and does not guarantee 92 packet reception, or reception order. Also it does not provide any 93 support for flow or congestion control. While the basic service provided 94 by IP multicast is largely scalable, adding features such as congestion 95 control or reliability on top of it might cause severe scalability 96 limitations, especially in presence of heterogeneous sets of receivers. 98 Scalability refers to the behaviour of the protocol in relation to the 99 number of receivers and network paths, their heterogeneity, and the 100 ability to accommodate dynamically variable groups. Scalability 101 limitations can come from memory or processing requirement, or from the 102 amount of traffic generated by the protocol. In turn, such limitations 103 derive from the features that a multicast transport protocol is expected 104 to provide. 106 Congestion control refers to the ability of the protocol to adapt its 107 throughput to the available bandwidth on the path to the receivers, and 108 to share bandwidth fairly with competing flows such as TCP. It is 109 required that protocols implement some form of congestion control so 110 that they not compete unfairly with existing and adaptive protocols such 111 as TCP. 113 Multi-rate protocols aim at splitting the set of receivers into multiple 114 subsets, according to the available bandwidth each one has to the 115 source. Conversely, single-rate multicast protocols make all receivers 116 in a session experience the same throughput. The partitioning of 117 receivers can be done statically or adaptively. 119 Layered coding refers to the ability to produce a coded stream that can 120 be split into multiple substreams (transmitted over different multicast 121 groups). The coded stream can be generated either from a fixed piece of 122 content, or from an ongoing data stream, and has the property that the 123 quality experienced by a receiver (in terms of quality of playout, or 124 overall transfer speed) is proportional to how many of the substreams 125 the receiver is joined. Layered congestion control that is compliant 126 with RFC 2357 must be used by receivers to dynamically adjust their 127 reception rate by appropriately joining and or leaving groups carrying 128 the substreams. 130 The concept of layered coding was first introduced with reference to 131 audio and video streams. For example, the information associated with a 133 ^L 134 TV broadcast can be thought as made of three layers, corresponding to 135 black and white, color, and HDTV quality. Receivers can experience 136 different quality without the need for the sender to replicate 137 information in the different layers. 139 The concept of layered coding can be naturally extended to reliable bulk 140 data transfer protocols when Forward Error Correction (FEC) techniques 141 are used for coding the data stream [15] [16] [7] [17] [18] [3]. By 142 using FEC, the data stream is transformed in such a way that 143 reconstruction of a data object does not depend on the reception of 144 specific data packets, but only on the number of different packets 145 received. As a result, by increasing the number of groups it is 146 receiving from, a receiver can reduce the transfer time accordingly. 147 More details on the use of FEC for reliable multicast can be found in 148 [11]. Reliable protocols aim at giving guarantees on the reliable 149 delivery of data from the source to the intended recipients. Guarantees 150 vary from simple data integrity to strict ordering and atomic delivery. 151 Several reliable multicast protocols have been built on top of IP 152 multicast, but scalability was not a design goal for many of them. In 153 some cases, scalability is achieved by introducing changes to routers or 154 other infrastructure [PGM], an approach which has an impact on near term 155 deployment. 157 Two of the key difficulties in scaling reliable multicast are dealing 158 with the amount of data that flows from receivers back to the sender, 159 and the associated response (generally data retransmissions) from the 160 sender. Protocols that avoid any such feedback, and minimize the amount 161 of retransmissions, can be massively scalable. LCT relies on the 162 availability of a layered codec to achieve reliability with little or no 163 feedback. 165 In this document we present the architecture of LCT, and illustrate its 166 support for multi-rate congestion control. 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC2119 [2]. 172 1.1. Related Documents 174 A more in-depth description of the use of FEC in Reliable Multicast 175 Transport (RMT) protocols is given in [11]. Some of the FEC codecs that 176 may be used by LCT for reliable bulk data transfer are specified in 177 [12]. LCT reserves opaque header fields that can be used to transport 178 information related to the payload encoding. 180 Implementors of LCT MUST also implement congestion control in accordance 181 to RFC2357 [13]. One possible scheme is specified in [1]. LCT reserves 183 ^L 184 opaque header fields that can be used by the congestion control scheme 185 to transport information related to congestion control. 187 It is recommended that LCT implementors use some authentication scheme 188 to protect the protocol from attacks. Suitable schemes are discussed in 189 [] 191 1.2. Environmental Requirements 193 LCT is intended for congestion controlled, multi-rate delivery of 194 objects (both reliable bulk data transfer and unreliable streaming of 195 multimedia information). 197 LCT is most applicable for delivery of objects of substantial length, 198 i.e., objects that range in length from hundreds of kilobytes to many 199 gigabytes, and whose transfer time is in the order of tens of seconds or 200 more. 202 LCT is directly applicable to all multicast enabled networks, including 203 asymmetric networks, wireless networks, and satellite networks. Thus, 204 the inherent raw scalability of LCT is unlimited. However, when other 205 specific applications are built on top of LCT, then these applications 206 by their very nature may limit scalability. For example, if an 207 application requires receivers to retrieve out of band information in 208 order to join a session, or an application allows receivers to send 209 requests back to the sender in order to extend an ongoing session, then 210 the scalability of the application is limited by the ability to send, 211 receive, and process this additional data. 213 LCT requires that the underlying network layer can deliver and 214 demultiplex packets for a given LCT session, and supply packet length 215 information to the LCT receiver. In IP networks, this is normally 216 achieved by using UDP, or any protocol that can provide an equivalent 217 service, as the underlying transport protocol. 219 LCT does not require reverse multicast connectivity, i.e. LCT receivers 220 do not send multicast traffic. As such, LCT works with both the 221 original multicast model introduced in [5], which we call Internet 222 Standard Multicast (ISM) in this document, and with the Source Specific 223 Multicast (SSM) model that is based on [10]. The definition of an LCT 224 group used throughout this document is slightly different with ISM and 225 with SSM. When using ISM, packets of an LCT group are sent to a 226 multicast group address G. When using SSM, packets of an LCT group are 227 sent to a channel address (S,G), where S is the IP address of the sender 228 and G is a multicast group address. 230 SSM is more attractive to LCT than ISM for a few reasons. First, LCT 231 may use several LCT groups in a session, and the large, local namespace 233 ^L 234 for allocating multicast groups in SSM greatly simplifies the address 235 allocation problem. 237 Second, LCT over SSM performs well even in presence of very large and 238 dynamically changing receiver sets. Changes in the multicast tree 239 topology with SSM are light weight operations (a new branch from the 240 receiver towards S grows when a receiver joins, and the branch is 241 deleted when the receiver leaves), whereas with ISM changes can be 242 heavier weight (involving transitions from a (*,G)-tree rooted at an RP 243 to the tree rooted at S). 245 Third, LCT over SSM scales well even when receivers span the global 246 Internet, as the light weight mechanisms that SSM uses to cross ISP 247 boundaries (standard BGP+ routing tables) is distinct advantage over the 248 heavier weight mechanisms used by ISM (the MSDP and BGMP protocols, both 249 of which are not needed by SSM). 251 Finally, a receiver joins an LCT group by joining a channel (S,G) with 252 SSM, and thus the receiver will only receive packets sent from the 253 sender S. With ISM, the receiver joins an LCT group by joining a 254 multicast group G, and all packets sent to G, regardless of their origin 255 sender, will be received by the receiver. Thus, SSM has compelling 256 security advantages over ISM for prevention of denial of service 257 attacks. 259 LCT also requires receivers to obtain Session Description Information 260 before joining a session, as described in Section 4.1. The session 261 description could be in a form such as SDP [8], or XML metadata, or 262 HTTP/Mime headers [6], and distributed with SAP, HTTP or in other ways. 264 The particular layered encoder and congestion control protocols used by 265 LCT to provide a complete protocol have an impact on the performance and 266 applicability of LCT. For example, some layered encoders used for video 267 and audio streams can produce a very limited number of substreams, thus 268 providing a very coarse control in the throughput of a session. When 269 LCT is used for reliable data transfer, some FEC coders are inherently 270 limited in the size of the object they can encode, and for objects 271 larger than this size the reception overhead on the receivers can grow 272 substantially. 274 As another example, some networks are not amenable to some congestion 275 control protocols that could be used with LCT. In particular, for a 276 satellite or wireless network, there may be no mechanism for receivers 277 to effectively reduce their reception rate since there may be a fixed 278 transmission rate allocated to the session. 280 ^L 281 2. General Architecture 283 An LCT session comprises all packets sent to one or more LCT groups from 284 a single sender, and pertaining to the transmission of one or more 285 objects that can be of interest for the receivers. 287 For example, an LCT session could be used to deliver a TV channel on 288 three groups. The first group would allow black and white reception, 289 the first two groups would permit color reception, whereas the set of 290 three groups delivers HDTV quality images. Objects in this example 291 would correspond to individual programs (movies, news, commercial) being 292 transmitted. 294 As another example, a reliable LCT session could be used to reliably 295 deliver hourly-updated weather maps (objects) using ten LCT groups at 296 different rates, using FEC coding. A receiver may join and concurrently 297 receive packets from subsets of these groups, until it has enough 298 packets in total to recover the object, then leave the session (or 299 remain there listening to control information only) until it is time to 300 receive the next object. In this case, the quality metric is the time 301 required to receive each object. 303 Before joining a session, the receivers MUST obtain a session 304 description, which MUST include the relevant session parameters needed 305 by a receiver to participate in the session. The session description is 306 determined and agreed upon by the senders, and typically communicated to 307 the receivers out of band. In some cases, part of the session 308 description MAY be included in the header of each packet. 310 A layered encoder is used to generate the data that is placed in the 311 payload of LCT packets. A suitable decoder is used to extract the 312 original information from the payload. 314 LCT congestion control is achieved by sending packets associated with a 315 given session to several LCT groups. Individual receivers dynamically 316 join to one or more of these groups, according to the network congestion 317 as seen by the receiver. LCT packet headers include an opaque field 318 which MUST be used to convey congestion control information to the 319 receivers. The actual congestion control scheme to use with LCT is 320 negotiated out-of-band. One of the algorithms that can be used to 321 achieve congestion control in LCT is described in [1]. LCT can be used 322 with other congestion control algorithms such as the one described in 323 [17], or router-assisted scheme where the selection of which packets to 324 forward is performed by routers. This latter approach potentially allows 325 for finer grain congestion control and a faster reaction to network 326 congestion, but requires changes to the router infrastructure. See [4] 327 for a preliminary design description. We do not discuss this approach 329 ^L 330 further in this document. 332 Depending on the service model in use, receiver can generate LCT request 333 packets, which have no payload, and are used to request an extension of 334 the duration of the session. 336 2.1. Delivery service models 338 LCT can support several different delivery service models. Two examples 339 are briefly described here. 341 Streaming service model. 343 This is the basic service model for the delivery of unreliable streams, 344 such as the TV example of Section 1. In this case the receivers join the 345 session, and dynamically adapt the number of LCT groups they subscribe 346 to (and the reception quality) according to the available bandwidth. 347 Receivers then drop from the session when they are not interested in the 348 stream anymore. 350 This service model can also be used for reliable data transfer, in case 351 of objects that need periodic updates such as the weather maps example 352 mentioned in Section 1. In this case, receivers join the session and 353 dynamically adapt the number of LCT groups they subscribe to until they 354 have accumulated a sufficient number of packets to reconstruct the 355 object. Afterwards, they drop from the session (or listen to the lowest 356 LCT group only) and wait for the transmission of the next object to 357 resubscribe or restart bandwidth adaptation according to the congestion 358 control scheme. 360 As an example, assume that each object to be transmitted has a size of 361 5000 1KB packets, and objects are updated every hour. The sender could 362 set the data rate on the lowest LCT group to 5 1KB packets/s, so that 363 receivers using just this LCT group could complete reception in 1000 364 seconds in absence of loss, and would be able to complete reception even 365 in presence of some substantial amount of losses or because they join 366 the session after the start of a transmission. Furthermore, the sender 367 could use a number of LCT groups such that the aggregate data rate when 368 using all LCT groups is 100 1KB packets/s, so that a receiver could be 369 able to complete reception of a single object in as little 50 seconds 370 (assuming no loss and that the congestion control mechanism immediately 371 converges to the use of all LCT groups). 373 ^L 374 On demand delivery model. 376 This service model is mostly relevant for reliable LCT session, where 377 the same object is made available by the sender for a sufficiently long 378 amount of time (typically much larger than the download time for the 379 object) to make it convenient for receivers to enact the download at 380 their discretion. 382 Receivers may join the ongoing object transmission session at their 383 discretion, obtain the necessary encoding symbols to reproduce the 384 object, and then leave the session. 386 For an on demand service model, senders typically transmit for some 387 given time period selected to be long enough to allow all the intended 388 receivers to join the session and recover the object. For example a 389 popular software update might be transmitted using LCT for several days, 390 even though a receiver may be able to complete the download in one hour 391 total of connection time, perhaps spread over several intervals of time. 393 Other service models. 395 There are many other delivery service models that LCT can be used for 396 that are not covered above. The description of the many potential 397 applications, the appropriate delivery service model, and the additional 398 mechanisms to support such functionalities is beyond the scope of this 399 document. This document only attempts to describe the minimal common 400 scalable elements to these diverse applications using LCT as the 401 delivery mechanism. 403 2.2. Congestion Control 405 The specific congestion control algorithm to be used for LCT sessions 406 depends on the type of data delivered. While the general behaviour of 407 the congestion control algorithm is to reduce the throughput in presence 408 of congestion and gradually increase it in the absence of congestion, 409 the actual dynamic behaviour (e.g. response to single losses) can vary. 411 A possible congestion control algorithm for reliable LCT sessions is 412 specified in [1]. Different session types might require a different 413 congestion control algorithm. 415 ^L 416 3. Packet Formats 418 The primary type of packets used by LCT sessions is "Data Packet". Data 419 packets are sent by the data sender(s) to an LCT group. 421 Some instances of LCT sessions may require the generation of feedback 422 from the receivers to the sender. Such information is carried in 423 Request packets, which are OPTIONAL and have the sole purpose of 424 implementing the "transmission extension" mechanism described in Section 425 3.4. The LCT packet format described in this document is intended to be 426 used in conjunction to the UDP transport protocol [14], or other 427 transport protocols that satisfy the requirements stated in Section 1.2, 428 specifically about demultiplexing and delivery of packet size 429 information. 431 LCT Data packets consist of an LCT header and an optional payload, as 432 shown in Figure 1. When present, the LCT payload immediately follows 433 the LCT header. 435 LCT Request Packets only consist of an LCT header, as shown in Figure 2. 437 LCT Packet Headers have variable size, which is specified by a length 438 field in the 3dr byte of the header. In the LCT Packet Header, all 439 integer fields are carried in "big-endian" or "network order" format, 440 that is, most significant byte (octet) first. Bits designated as 441 "padding" or "reserved" (r) MUST by set to 0 by senders and ignored by 442 receivers. Unless otherwise noted, numeric constants in this 443 specification are in decimal (base 10). 445 3.1. Data-Packet format 447 The format of LCT Data Packets is depicted in Figure 1. 449 ^L 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | V |D|r|T|X|Trans.Obj.Id.(TOI) | HDR_LEN | Codepoint (CP)| 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Congestion Control Information (CCI) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Demux Label (DL, if D = 1) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Sender Current Time (SCT, if T = 1) | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Expected Residual Time (ERT, if T = 1) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Header Extensions (only present if X = 1 ) | 464 | | 465 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 466 | | 467 | Payload | 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 1 - LCT Data Packet format 473 3.2. Request-Packet format 475 When using on-demand service, LCT receivers MAY request that the sender 476 extend the transmission of the packets pertaining to a given object. 477 Requests should only be sent in response to data packets which are 478 carrying the TEI field (have the T bit set). Request packets MUST be 479 unicast to the node (designated out of band) in charge of receiving 480 Request packets. 482 The format of Request Packets is shown in Figure 2. 484 ^L 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | V |D|r|1|X| Trans.Obj.Id.(TOI)| HDR_LEN | 0 | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Desired End Time (DET) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Demux Label (DL, if D = 1) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Header Extensions (only present if X = 1 ) | 495 | | 496 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 498 Figure 2: LCT Request Packet format 500 3.3. LCT Packet header fields 502 The function each field in LCT packet headers is the following. Fields 503 marked as "1" mean that the corresponding bits MUST be set to "1" by the 504 generating agent. Fields marked as "r" or "0" mean that the 505 corresponding bits MUST be set to "0" by the generating agent. 507 LCT version number (V): 2 bits 509 Indicates the LCT protocol version. The LCT version number for 510 this specification is 0. 512 Demux Label Present flag (D): 1 bit 514 D = 1 indicates that the Demux Label (DL) field is present. D = 0 515 indicates "no DL field". The DL field contains a 32-bit 516 identifier which can be used to filter packets belonging to the 517 session. 519 Transmission Extension Information Present flag (T): 1 bit 521 T = 1 indicates that the Transmission Extension Information (TEI) 522 field is present. T = 0 indicates "no TEI field". The TEI field 523 is inserted by senders when they are willing to accept 524 Transmission Extension Request packets from the receivers. 526 Header Extension Present flag (X): 1 bit 528 X = 1 indicates that Header Extensions are present. X = 0 529 indicates "no Header Extensions". Header Extensions are used in 531 ^L 532 LCT to accommodate optional header fields which are not always 533 used or have variable size. 535 Transport Object Identifier (TOI): 10 bits 537 The Transport Object Identifier (TOI) field indicates which 538 Transport Object within the session this Data packet or Request 539 packet pertains to. For example, a source might send a number of 540 files in the same session, using TOI=0 for the first file, TOI=1 541 for the second one, etc. 543 LCT Header Length (HDR_LEN): 8 bits 545 Length of the variable portion of the LCT header in units of 546 32-bit words (excluding IP or UDP headers). The total LCT header 547 length is (HDR_LEN+2) 32-bit words. 548 This field can be used for direct access to the beginning of the 549 LCT payload. 551 Codepoint (CP): 8 bits 553 An opaque identifier which is passed to the payload decoder to 554 convey information on the codec being used for the payload. The 555 mapping between the codepoint and the actual codec is defined on a 556 per session basis and communicated out-of-band as part of the 557 session description information. 559 The use of the CP field is similar to the Payload Type (PT) field 560 in RTP headers []. 562 Congestion Control Information (CCI): 32 bits 564 Used to carry Congestion Control Information, e.g. for the scheme 565 described in [1] or other congestion control schemes. This field 566 is opaque for the purpose of this specification. 568 Demux Label (DL): 32 bits (OPTIONAL) 570 Used to carry a 32-bit identifier to be used for filtering 571 purposes. All LCT packets belonging to the same LCT group MUST 572 have the same DL value that has been communicated out of band to 573 receivers as part of the session description information. 574 Receivers MUST discard packets with a non-matching DL. 575 In order to minimize the amount of information to be supplied out 576 of band, it is suggested that the same DL is used for all LCT 577 layers in the same session. 579 ^L 581 Sender Current Time (SCT): 32 bits (OPTIONAL) 583 This field represents the current clock at the sender at the time 584 this packet was transmitted, measured in units of 1ms and computed 585 modulo 2^32 units. 586 SCT is used, in conjunction with the ERT and DET fields, to 587 support receiver request generation as described in Section 3.4. 588 This field is only present in Data Packets when T=1. 590 Expected Residual Time (ERT): 32 bits (OPTIONAL) 592 This field represents the expected residual transmission time for 593 the current object, measured in units of 1ms. Senders MUST NOT 594 include SCT and ERT if the transmission of the current object is 595 expected to last for more than 2^32-1 time units (approximately 49 596 days). See Section 3.4 for a detailed description on the use of 597 this field. This field is only present in Data Packets when T=1. 599 Desired End Time (DET): 32 bits 601 This field represents the desired finish time for the transmission 602 of the object, measured in units of 1ms and computed modulo 2^32 603 time units. See Section 3.4 for a detailed description on the use 604 of this field. This field is only present in Request Packets when 605 T=1. 607 3.4. Transmission Extensions 609 Four fields in the packet headers are used to support the Transmission 610 Extension mechanism: T, SCT, ERT, DET. These fields have the following 611 purposes: 613 o to communicate to receivers the expected finish time for the 614 transmission of the current object 616 o to let receivers produce requests to extend transmission which are 617 idempotent. 619 When a sender is willing to accept extension requests, it will set T=1 620 in the data packets, and also include the SCT and ERT fields as follows: 622 o SCT is set to the current time known at the sender, measured in 623 units of 1ms, and computed modulo 2^32 units. 625 ^L 627 o ERT is set to the expected residual transmission time, as known to 628 the sender, and measured in units of 1ms. The maximum value that 629 can be accommodated in this field is approximately 49 days. A 630 sender MUST NOT generate these fields if the residual transmission 631 time is larger than this maximum value. 633 The Expected Finish Time (EFT) of the transmission at the sender site 634 can be computed as 635 EFT = SCT + ERT. 637 A receiver can determine the Desired Residual Time (DRT) based on 638 external information, such as the amount of missing data and the 639 incoming data rate. DRT is the (estimated) transmission extention 640 needed, measured from the time of estimation to the time of the desired 641 end of transmission. The maximum value for DRT is 2^32-1 units of 1ms 642 each. Higher values must be upper bounded to 2^32-1. 643 A receiver MUST NOT generate Request packets if the reception is likely 644 to complete before the expected end of the session, i.e. if DRT << ERT . 646 If a receiver needs to extend the transmission, they compute the Desired 647 End Time value to be put into Request packets as 649 DET = SCT + DRT. 651 The above procedures make requests idempotent. 653 3.5. Header-Extension Fields 655 To allow for additional header fields and to extend the size of some of 656 the predefined fields, the LCT header contains an additional header 657 field flag, "X". If "X" is set to 0 then no additional header fields are 658 included within the LCT header beyond the predefined fields. When 659 additional headers beyond the predefined fields are used, the value of 660 "X" within the LCT header MUST be set to 1. 662 Examples of use of header extensions include: 664 o extended-size version of already existing header fields. 666 o Sender and Receiver authentication information. 668 If present, Header Extensions must be processed before performing any 669 congestion control procedure or otherwise accepting the packet. Packets 670 with unrecognised Header Extensions MUST be discarded by the receiving 672 ^L 673 agent, hence the expected use of extentions should be signalled out-of- 674 band before session startup. 676 There are two formats for Header Extension fields, as depicted below. 677 The first format is used for variable-length extensions, with HET values 678 between 0 and 63. The second format is used for fixed length (one word) 679 extension, using HET values from 64 to 127. 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 |L| HET (<=63) | HEL | | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 686 . . 687 . Header Extension Content (HEC) . 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 |L| HET (>=64) | Header Extension Content (HEC) | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Figure 5 - format of additional headers 698 The explanation of each sub-field is the following. 700 Last Header Extension (L): 1 bit 702 MUST be set to 1 in the last Header Extension field present in a 703 packet header, MUST be set to 0 in all the others. 705 Header Extension Type (HET): 7 bits 707 The type of the header extension. This document defines a number 708 of possible types. Additional types may be defined in future 709 version of this specification. HET values from 0 to 63 are used 710 for variable-length Header Extensions. HET values from 64 to 127 711 are used for fixed-length Header Extensions. 713 Header Extension Length (HEL): 8 bits (OPTIONAL) 715 The length of the whole Header Extension field, expressed in 716 multiples of 32-bit words. This field is only present for 718 ^L 719 variable-length extension (HET between 0 and 63). 721 Header Extension Content (HEC): variable length 723 The content of the Header Extension. The format of this sub-field 724 depends on the header extension type. For fixed-length header 725 extensions, the HEC is 24 bits. For variable-length header 726 extensions, the HEC field has variable size, as specified by the 727 HEL field. Note that the length of each Header Extension field 728 MUST be a multiple of 32-bit. Also note that the total size of 729 all header extensions plus optional header fields cannot exceed 730 255 32-bit words. 732 The originator of a packet with header extensions MUST not leave 733 additional space between the end of the last Header Extension and the 734 beginning of the LCT payload. 736 All LCT agents MUST support the EXT_NOP header extension. 738 The following header extension types are defined: 740 EXT_NOP=0 No-Operation extension. 741 The information present in this extension field MUST be 742 ignored by receivers. 744 EXT_CCI=1 Congestion Control Information extension. 745 This extension field extends the CCI field present in the 746 fixed part of the header. It is used when the congestion 747 control information does not fit in the 32 bits CCI field. 748 When this option is present, receivers MUST ignore the CCI 749 field and use the value provided in this option instead. 750 The interpretation of the data contained in EXT_CCI MUST 751 be negotiated out-of-band. 753 EXT_TOI=2 Tranport Object Identifier extension. 754 This extension field extends the TOI field of the fixed 755 header. It is used when the Tranport Object Identifier 756 does not fit in 10 bits. When this option is present, 757 receivers MUST ignore the TOI field in the fixed header 758 and use the value provided in this option instead. The 759 interpretation of the data contained in EXT_TOI MUST be 760 negotiated out-of-band. 762 EXT_AUTH=3 Authentication Extension 763 Information used to authenticate the source of the packet. 765 ^L 766 If present, the format of this header extension and its 767 processing must be communicated out-of-band as part of the 768 session description. 769 It is recommended that senders and receivers provide some 770 form of authentication on the packet they transmit. If 771 EXT_AUTH is present, whatever authentication checks that 772 can be performed immediately upon reception of the packet 773 must be performed before accepting the packet and 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 4. Procedures 783 4.1. Sender Operation 785 Before a session starts, an LCT sender MUST make available all 786 applicable information regarding the session, including but not limited 787 to: 789 o number of LCT groups; 791 o addresses, port numbers and data rates used for each LCT group; 793 o the format of the payload (for example, the mapping of codepoints 794 used in the session to FEC codec types and parameters); 796 o the congestion control scheme being used; 798 o the Demux Label (DL) value(s) used for the session; 800 o the authentication scheme being used, and all relevant information 801 which is necessary for sender authentication purposes; 803 o the address of the node in charge of receiving Request packets; 805 The session description could be in a form such as SDP [8], XML 806 metadata, HTTP/Mime headers, etc. It might be carried in a session 807 announcement protocol such as SAP [9], located on a Web page with 809 ^L 810 scheduling information, or conveyed via E-mail or other out of band 811 methods. Discussion of session description format, and distribution of 812 session descriptions is beyond the scope of this document. 814 Within an LCT session, an LCT sender transmits a sequence of data 815 packets each containing a payload encoded according to one of the codecs 816 defined in the session description. Data packets are sent over one or 817 more LCT groups which together constitute a session. Transmission rates 818 may be different in different groups. This document does not specify the 819 policy used to place symbols into packets, nor the order in which 820 packets are transmitted, nor the scheduling of packets in multiple 821 groups. Although these issues affect the efficiency of the protocol, 822 they do not affect the correctness nor the inter-operability between 823 senders and receivers. 825 Multiple transport objects can be carried within the same LCT session. 826 Each object is identified by a unique Transport Object Identifier (TOI). 827 Objects MUST be transmitted sequentially, and the TOIs MUST be used in 828 strict sequential order. A sender is not allowed to transmit packets for 829 old objects after starting the transmission of packets for a new one. 830 Note that despite this restriction, both the network and the underlying 831 protocol layers can cause some reordering of packets, especially when 832 sent over different LCT groups, and thus receivers MUST NOT assume that 833 the reception of a packet for a new object means that there are no more 834 packets in transit for the previous one, at least for some amount of 835 time. 837 Typically, the sender(s) continues to send data packets in a session 838 until the transmission is considered complete. The transmission may be 839 considered complete when some time has expired, a certain number of 840 packets have been sent, or some out of band signal (possibly from a 841 higher level protocol) has indicated completion by a sufficient number 842 of receivers. Feedback through LCT Request packets MAY also be used to 843 determine the end of the session. 845 The specification of the processing of the payload carried in LCT 846 packets is beyond the scope of this document. LCT will only act as a 847 transport layer and will merely implement congestion control and convey 848 payload and associated information (Codepoint and TOI) to the receivers. 850 For the reasons mentioned above, this document does not pose any 851 restriction on packet sizes. However, network efficiency considerations 852 recommend that the sender uses as large as possible payload size, but in 853 such a way that packets do not exceed the network's maximum transmission 854 unit size (MTU), or fragmentation coupled with packet loss might 855 introduce severe inefficiency in the transmission. 857 It is also recommended that all packets have the same or very similar 859 ^L 860 sizes, as this can have a severe impact on the effectiveness of 861 congestion control schemes such as the one described in [1]. An LCT 862 sender MUST implement the sender-side part of one of the congestion 863 control schemes that is in accordance with RFC 2357, and the 864 corresponding receiver congestion control scheme MUST be communicated 865 out of band and implemented by any receivers participating in the 866 session. 868 If a Sender implements the Transmission Extensions, then it MUST operate 869 as described in Section 3.4. 871 4.2. Receiver Operation 873 Receivers can operate differently depending on the delivery service 874 model. For example, for an on demand service model receivers may join a 875 session, obtain the necessary encoding symbols to reproduce the object, 876 and then leave the session. As another example, for a streaming service 877 model a receiver may be continuously joined to a set of multicast groups 878 to download all objects in a session. 880 To be able to participate in a session, a receiver MUST first obtain the 881 relevant session description information as listed in Section 4.1. 883 To be able to participate in a session, a receiver MUST implement the 884 congestion control algorithm specified in the session description. If a 885 receiver is not able to implement the congestion control algorithm used 886 in the session, it MUST NOT join the session. 888 If source authentication information is present in data packets, it must 889 be used as specified in Section 3.5. If a receiver is unable to 890 implement the authentication mechanism used by the session, it MUST NOT 891 join the session. 893 To be able to participate in a session, receivers MUST be able to 894 process the payload of the packets. At a minimum this involves the 895 ability to forward or store the payload, and possibly (in case of 896 reliable LCT session) determine when an object can be successfully 897 recovered. If a receiver is not able to process the payload of packets, 898 it MUST either drop from the session, or reduce the receive bandwidth to 899 the minimum value allowed by the congestion control algorithm being 900 used. 902 When the session is transmitted on multiple LCT groups, receivers MUST 903 do it according to the specified startup behaviour of the congestion 904 control algorithm itself. For a layered transmission on multiple groups, 905 this typically means that a receiver will only join a minimal set of LCT 906 groups, possibly a single one. This rule has the purpose of preventing 908 ^L 909 receivers from starting at high data rates. 911 If the Transmission Extension Information field is present in data 912 packets, receivers MAY originate Request packets to extend the 913 transmission of an object as specified in Section 3.4. Receivers MUST 914 NOT originate transmission extension request if the T flag in incoming 915 data packets is set to 0. 917 Receivers which generate Request packets MUST implement feedback- 918 implosion avoidance procedures as follows: 920 o Receivers must use the Expected Finishing Time advertised by the 921 sender(s) to predict whether or not they will be able to recover the 922 object from the packets they have already received and from the 923 packets they can expect to receive in the future. This prediction 924 SHOULD also consider data-rate fluctuations caused by congestion 925 control adaptations. 927 o When a receiver predicts that the residual object transmission time 928 is not sufficient to successfully recover the object, it MAY 929 schedule the transmission of an extension request at a random time 930 in the future, before the scheduled end of the transmission. 932 o When a receiver has a pending extension request scheduled for 933 transmission, it must keep monitoring the progress of the reception 934 and cancel the pending request if either of the following happens: 936 - 937 The residual object transmission time becomes larger the predicted 938 time needed to complete the reception. 940 - 941 A Data packet for the object of interest is received with the T 942 flag set to 0. 944 o A receiver MUST cancel pending extension-requests when the 945 transmission time of an object is over. 947 The rules stated above are not sufficient to obtain a good implosion 948 prevention in all the cases. For improved performance the following 949 guidelines SHOULD be followed: 951 o Extension requests should be *scheduled* only when the reception of 952 the object is in an advanced status of completion (e.g. more than 953 50%). This improves the accuracy of the receivers' prediction 955 ^L 956 reducing the chance that an extension is requested uselessly. 958 o The time needed for a Request to suppress pending Request from other 959 receivers is approximatively a packet round trip time (unicast 960 request to the sender and multicast data packets to the receivers). 961 Using random-time scheduling for requests is an effective 962 suppression mechanism only if the length of the interval from which 963 the transmission time is selected is much larger than a round trip 964 time. For this reason extension requests should be *scheduled* at 965 least a few seconds before the end of transmission. 967 5. Security Considerations 969 LCT can be subject to denial-of-service attacks by attackers which try 970 to confuse the congestion control mechanism, or send forged packets to 971 the session which would prevent successful reconstruction of large 972 portions of the data stream. 974 The same exact problems are present in TCP, where an attacker can forge 975 packets and either slow down or increase the throughput of the session, 976 or replace parts of the data stream with forged data. If the stream is 977 carrying compressed or otherwise coded data, even a single forged packet 978 could also cause incorrect reconstruction of the rest of the data 979 stream. 981 It is therefore recommended that LCT agents implement some form of 982 authentication to protect themselves against such attacks. 984 6. IANA Considerations 986 No information in this specification is subject to IANA registration. 988 Building blocks components used by LCT may introduce additional IANA 989 considerations. 991 7. Intellectual Property Issues 993 No specific codec or congestion control scheme are specified or 994 referenced as mandatory in this document. 996 LCT may be used with congestion control protocols and codecs which are 997 proprietary, or have pending or granted patents. 999 ^L 1000 8. Acknowledgments 1002 Thanks to Bruce Lueckenhoff, Hayder Radha and Vincent Roca for detailed 1003 comments on this document. 1005 [1] Luby, M., Vicisano, L., Haken, A., "Layered congestion control 1006 building block", draft-ietf-rmt-bb-lcc-00.txt, November 2000. 1008 [2] Bradner, S., Key words for use in RFCs to Indicate Requirement 1009 Levels (IETF RFC 2119) http://www.rfc-editor.org/rfc/rfc2119.txt 1011 [3] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital 1012 Fountain Approach to Reliable Distribution of Bulk Data", Proceedings 1013 ACM SIGCOMM '98, Vancouver, Canada, Sept 1998. 1015 [4] Cain, B., Speakman, T., and Towsley, D., "Generic Router Assist 1016 (GRA) Building Block, Motivation and Architecture", Internet Draft 1017 draft-ietf-rmt-gra-arch-00.txt, a work in progress. 1019 [5] Deering, S., "Host Extensions for IP Multicasting", RFC 1058, 1020 Stanford University, Stanford, CA, 1988. 1022 [6] Fielding, R., Gettys, J., Mogul, J. Frystyk, H., Berners-Lee, T., 1023 Hypertext Transfer Protocol - HTTP/1.1 (IETF RFC2068) http://www.rfc- 1024 editor.org/rfc/rfc2068.txt 1026 [7] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable Multicast 1027 File Distribution: Caching and Parameters Optimizations", Technical 1028 Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999. 1030 [8] Handley, M., and Jacobson, V., "SDP: Session Description Protocol", 1031 RFC 2327, April 1998. 1033 [9] Handley, M., "SAP: Session Announcement Protocol", Internet Draft, 1034 IETF MMUSIC Working Group, Nov 1996. 1036 [10] Holbrook, H., Cheriton, D., "IP Multicast Channels: Experss Support 1037 for Large-scale Single-source Applications", ACM SIGCOMM'99 1039 [11] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M., 1040 Crowcroft, J., "The use of Forward Error Correction in Reliable 1041 Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November 1042 2000. 1044 [12] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., 1046 ^L 1047 Crowcroft, J., "RMT BB: Forward Error Correction Codes", Internet Draft 1048 draft-ietf-rmt-bb-fec-01.txt, November 2000. 1050 [13] Mankin, A., Romanow, A., Brander, S., Paxson, V., "IETF Criteria 1051 for Evaluating Reliable Multicast Transport and Application Protocols," 1052 RFC2357, June 1998. 1054 [14] J. Postel, "User Datagram Protocol", RFC768, August 1980. 1056 [15] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution 1057 protocol based on software FEC techniques", Proceedings of the Fourth 1058 IEEES Workshop on the Architecture and Implementation of High 1059 Performance Communication Systems, HPCS'97, Chalkidiki, Greece, June 1060 1997. 1062 [16] Rizzo, L., "Effective Erasure Codes for Reliable Computer 1063 Communication Protocols", ACM SIGCOMM Computer Communication Review, 1064 Vol.27, No.2, pp.24-36, Apr 1997. 1066 [17] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion 1067 Control for Layered Multicast Data Transfer", IEEE Infocom '98, San 1068 Francisco, CA, Mar.28-Apr.1 1998. 1070 [18] Vicisano, L., "Notes On a Cumulative Layered Organization of Data 1071 Packets Across Multiple groups with Different Rates", University College 1072 London Computer Science Research Note RN/98/25, Work in Progress (May 1073 1998). 1075 9. Authors' Addresses 1077 Michael Luby 1078 luby@digitalfountain.com 1079 Digital Fountain 1080 600 Alabama Street 1081 San Francisco, CA, USA, 94110 1083 Jim Gemmell 1084 jgemmell@microsoft.com 1085 Microsoft Research 1086 301 Howard St., #830 1087 San Francisco, CA, USA, 94105 1089 Lorenzo Vicisano 1090 lorenzo@cisco.com 1091 cisco Systems, Inc. 1092 170 West Tasman Dr., 1094 ^L 1095 San Jose, CA, USA, 95134 1097 Luigi Rizzo 1098 luigi@iet.unipi.it 1099 ACIRI/ICSI, 1100 1947 Center St, Berkeley, CA, USA, 94704 1101 and 1102 Dip. Ing. dell'Informazione, 1103 Univ. di Pisa 1104 via Diotisalvi 2, 56126 Pisa, Italy 1106 Mark Handley 1107 mjh@aciri.org 1108 ACIRI, 1109 1947 Center St, 1110 Berkeley, CA, USA, 94704 1112 Jon Crowcroft 1113 J.Crowcroft@cs.ucl.ac.uk 1114 Department of Computer Science 1115 University College London 1116 Gower Street, 1117 London WC1E 6BT, UK 1119 ^L 1121 10. Full Copyright Statement 1123 Copyright (C) The Internet Society (2000). All Rights Reserved. 1125 This document and translations of it may be copied and furnished to 1126 others, and derivative works that comment on or otherwise explain it or 1127 assist in its implementation may be prepared, copied, published and 1128 distributed, in whole or in part, without restriction of any kind, 1129 provided that the above copyright notice and this paragraph are included 1130 on all such copies and derivative works. However, this document itself 1131 may not be modified in any way, such as by removing the copyright notice 1132 or references to the Internet Society or other Internet organizations, 1133 except as needed for the purpose of developing Internet standards in 1134 which case the procedures for copyrights defined in the Internet 1135 languages other than English. 1137 The limited permissions granted above are perpetual and will not be 1138 revoked by the Internet Society or its successors or assigns. 1140 This document and the information contained herein is provided on an "AS 1141 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1142 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1143 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1144 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1145 FITNESS FOR A PARTICULAR PURPOSE." 1147 ^L