RFC 3451
Layered Coding Transport (LCT) Building Block
RFC 3451: Layered Coding Transport (LCT) Building Block 🦋
Okay bestie, this is RFC 3451, and it's an Experimental doc 🧪, which means it's a trial run, not a finished standard. It came from the Network Working Group in December 2002 📅. The authors are M. Luby (Digital Fountain), J. Gemmell (Microsoft), L. Vicisano (Cisco), L. Rizzo (Univ. Pisa), M. Handley (ICIR), and J. Crowcroft (Cambridge Univ.) 👑. The header doesn't list any RFCs that this one obsoletes or updates, so nothing gets replaced or patched here ✨.
Status of This Memo 📝
This memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind. They're literally asking for discussion and suggestions for improvement 💬. Distribution of this memo is unlimited 🌈.
Copyright Notice ©️
Copyright (C) The Internet Society (2002). All Rights Reserved. 💅
Abstract 🌸
Layered Coding Transport (LCT) gives transport level support for reliable content delivery and stream delivery protocols 🚀. It's specifically built for protocols that use IP multicast, but it also supports protocols that use unicast 📡. LCT works with congestion control that gives receivers multiple delivery rates, and it also plays nicely with coding techniques that deliver content reliably 🫶.
Table of Contents 🗂️
1. Introduction...................................................2
2. Rationale......................................................3
3. Functionality..................................................4
4. Applicability..................................................7
4.1 Environmental Requirements and Considerations...............8
4.2 Delivery service models....................................10
4.3 Congestion Control.........................................11
5. Packet Header Fields..........................................12
5.1 Default LCT header format..................................12
5.2 Header-Extension Fields....................................17
6. Operations....................................................20
6.1 Sender Operation...........................................20
6.2 Receiver Operation.........................................22
7. Requirements from Other Building Blocks.......................23
8. Security Considerations.......................................24
9. IANA Considerations...........................................25
10. Acknowledgments..............................................25
11. References...................................................25
Authors' Addresses...............................................28
Full Copyright Statement.........................................291. Introduction ✨
Layered Coding Transport gives transport level support for reliable content delivery and stream delivery protocols 💖. It's specifically designed for protocols using IP multicast, and it also supports protocols that use unicast 🦋. It's compatible with congestion control that gives receivers multiple delivery rates, and it's also compatible with coding techniques that deliver content reliably 🎀.
This document describes a building block as defined in RFC 3048 [26]. It's a product of the IETF RMT WG and follows the general guidelines in RFC 3269 [24] 🧚.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2] 📚.
Statement of Intent 🎯
This memo contains part of the definitions needed to fully specify a Reliable Multicast Transport protocol, following RFC 2357 🌟. As RFC 2357 says, using any reliable multicast protocol on the Internet requires an adequate congestion control scheme 🚦.
While they wait for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) is publishing this Request for Comments in the "Experimental" category 🧪.
RMT intends to resubmit this specification as an IETF Proposed Standard as soon as the above condition is met 👑.
2. Rationale 💭
LCT gives transport level support for massively scalable protocols that use the IP multicast network service 🌐. That support is shared by a bunch of very important apps, including reliable content delivery and streaming 🔥.
An LCT session is made up of multiple channels from a single sender 📦. They're used for some period of time to carry packets about transmitting one or more objects that receivers might be interested in 💌. A session comes from one sender because that's the right granularity for regulating packet traffic with congestion control 🚦. One reason to use multiple channels in the same session is that there are massively scalable congestion control protocols that do exactly that 🧅. Those protocols count as layered because a receiver joins and leaves channels in layered order while it's in the session 🍰. Layered channels are also useful for streaming 🎬.
There are coding techniques that provide massively scalable reliability and asynchronous delivery, and they work with both layered congestion control and LCT 💜. Put it all together and you get a massively scalable, reliable, asynchronous content delivery protocol that's network friendly 🤝. LCT also has functionality other apps can use, like layered streaming apps 🌈.
LCT avoids functionality that isn't massively scalable 🙅♀️. For example, LCT doesn't provide any mechanisms for sending information from receivers back to senders. That doesn't rule out protocols that use LCT and do need to send information from receivers to senders, though 💀.
LCT includes general support for congestion control that must be used 🚨. It doesn't specify which congestion control should be used, though 🤷♀️. The reason is that any network friendly protocol must provide congestion control, but the different apps that can use LCT don't all have the same congestion control requirements 💅. For example, a content delivery protocol may strive to use all the available bandwidth between receivers and the sender. It must, therefore, drastically back off its rate when there's competing traffic 📉. A streaming delivery protocol, on the other hand, may strive to keep a constant rate instead of grabbing all the bandwidth, and it may not back off its rate as fast when there's competing traffic 🎀.
Beyond congestion control, LCT provides a bunch of fields and supports functionality that lots of protocols need 🧰. For example, LCT provides a Transmission Session ID that identifies which session each received packet belongs to. This matters because a receiver may be joined to many sessions at once, so being able to demultiplex packets as they arrive, based on their session, is super useful 🙌. As another example, LCT optionally supports identifying which object each packet carries information about 🧩. So yeah, LCT gives you lots of the commonly used fields and support for functionality that many protocols require 👑.
3. Functionality ✨
Okay so an LCT session is basically a bundle of logically grouped LCT channels 🎀 all coming from one single sender, and the packets carry LCT headers for one or more objects. An LCT channel is defined by the combo of a sender and an address that the sender attaches to that channel 💅. Receivers join a channel to start getting the data packets sent there, and they leave when they want to stop. That's the whole vibe 🦋
LCT is meant to be combined with other building blocks so the overall protocol is massively scalable 🌈 Scalability is about how the protocol behaves as the number of receivers and network paths grows, how different those receivers and paths are from each other, and whether it can handle a set of receivers that keeps changing 🧚 Scalability limits can come from memory or processing needs, or from all the feedback control and redundant data packet traffic the protocol generates. And those limits can show up because of the features a complete reliable content delivery or stream delivery protocol is expected to have anyway 💀
The LCT header has a bunch of fields that are super useful for sending in-band session info to receivers 🍓 One of the required fields is the Transmission Session ID (TSI), which lets a receiver uniquely identify received packets as part of the session. Another required field is the Congestion Control Information (CCI), which lets the receiver do the required congestion control on the packets it gets within the session. Other LCT fields are optional but often really helpful. For example, the Transport Object Identifier (TOI) tells you which object the packet has data for. Some more examples: the Sender Current Time (SCT) shows when the packet was sent from the sender to the receiver, the Expected Residual Time (ERT) shows how much longer the session will keep going, there are flags for closing the session and for closing the sending of packets for an object, and there are header extensions for fields that can be used for things like packet authentication 🔐
LCT supports congestion control, and this part is non-negotiable 😤 Congestion control MUST be used that conforms to RFC 2357 [13] between receivers and the sender for each LCT session. Congestion control is about adapting throughput to the available bandwidth on the path from the sender to a receiver, and sharing bandwidth fairly with competing flows like TCP. So the total flow of packets heading to each receiver in an LCT session MUST NOT compete unfairly with existing flow adaptive protocols such as TCP 🫶
A multiple rate or a single rate congestion control protocol can be used with LCT. For multiple rate protocols, a session usually has more than one channel, and the sender sends packets to those channels at rates that don't depend on the receivers. Each receiver adjusts its reception rate while it's in the session by joining and leaving channels dynamically, depending on the available bandwidth to the sender, independent of all the other receivers. So with multiple rate protocols, each receiver's reception rate can change dynamically on its own, separate from everyone else 🦋
For single rate protocols, a session usually has one channel, and the sender sends packets to that channel at variable rates over time, depending on feedback from receivers. Each receiver stays joined to the channel the whole time it's in the session. So with single rate protocols, each receiver's reception rate can change dynamically, but it's all in coordination with every receiver 👯♀️
Generally, a multiple rate protocol is preferable to a single rate protocol in a heterogeneous receiver environment, because it more easily achieves scalability to many receivers and gives higher throughput to each individual receiver 👑 Some possible multiple rate congestion control protocols are described in [22], [3], and [25]. A possible single rate congestion control protocol is described in [19] 📚
Layered coding is the ability to produce a coded stream of packets that can be split into an ordered set of layers 🥞 The coding is meant to provide some form of reliability, and the layering is meant to let the receiver experience (in terms of quality of playout, or overall transfer speed) change in a predictable way, depending on how many consecutive layers of packets the receiver is getting 💖
The idea of layered coding was first introduced with audio and video streams. For example, the info for a TV broadcast could be split into three layers: black and white, color, and HDTV quality. Receivers can experience different quality without the sender having to copy the information into each of the different layers 📺
The concept of layered coding can be naturally extended to reliable content delivery protocols when Forward Error Correction (FEC) techniques are used to code the data stream. You can read about this in [20], [18], [7], [22] and [4]. With FEC, the data stream gets transformed so that rebuilding a data object doesn't depend on getting specific data packets, only on how many different packets arrive 🧩 So by increasing the number of layers a receiver is pulling from, the receiver can cut down the transfer time accordingly. Using FEC for reliability can increase scalability dramatically compared to other ways of providing reliability 🚀 More details on using FEC for reliable content delivery are in [11].
Reliable protocols aim to guarantee reliable delivery of data from the sender to the intended recipients. Those guarantees can range from simple packet data integrity all the way to reliable delivery of a precise copy of an object to every intended recipient. Several reliable content delivery protocols have been built on top of IP multicast using methods other than FEC, but scalability wasn't the main design goal for many of them 🙈
Two of the biggest difficulties in scaling reliable content delivery over IP multicast are dealing with the amount of data flowing from receivers back to the sender, and the response from the sender (usually data retransmissions) 😭 Protocols that avoid that kind of feedback and minimize retransmissions can be massively scalable 🌸 LCT can be used together with FEC codes or a layered codec to get reliability with little or no feedback 💜
Protocol instantiations MAY be built by combining the LCT framework with other components. A complete protocol instantiation that uses LCT MUST include a congestion control protocol that is compatible with LCT and that conforms to RFC 2357 [13]. A complete protocol instantiation that uses LCT MAY include a scalable reliability protocol that is compatible with LCT, it MAY include a session control protocol that is compatible with LCT, and it MAY include other protocols such as security protocols 🎀
4. Applicability 🌷
An LCT session is a logically related set of one or more LCT channels, all coming from a single sender 💅 The channels are used for some period of time to carry packets containing LCT headers, and those headers relate to sending one or more objects that receivers might be interested in 👀
LCT is most applicable for delivering objects or streams in a session of substantial length. That means objects or streams that add up to anywhere from hundreds of kilobytes to many gigabytes, where the session lasts on the order of tens of seconds or more ⏳
Here's an example: an LCT session could deliver a TV program using three LCT channels 📺 Receiving packets from the first LCT channel could allow black and white reception. Receiving the first two LCT channels could also permit color reception. Receiving all three channels could allow HDTV quality reception. In this example, the objects would be the individual TV programs being transmitted 🍿
Another example: a reliable LCT session could be used to reliably deliver hourly-updated weather maps (objects) using ten LCT channels at different rates, with FEC coding ⛅ A receiver may join a subset of these channels and receive from them at the same time until it has enough packets in total to recover the object. Then it can leave the session (or stay connected and only listen for session description information) until it's time to get the next object. In this case, the quality metric is the time it takes to receive each object 🌤️
Before joining a session, receivers MUST obtain enough of the session description to start the session. This MUST include the relevant session parameters a receiver needs to take part in the session, including all information relevant to congestion control 🔥 The sender decides the session description, and it's usually communicated to the receivers out-of-band. In some cases, as described later, parts of the session description that aren't needed to start a session MAY be included in the LCT header, or communicated to a receiver out-of-band after it has joined the session 🧚
An encoder MAY be used to generate the data that goes in the packet payload, in order to provide reliability. A suitable decoder is used to reproduce the original information from the packet payload 🧠 There MAY be a reliability header that follows the LCT header if such an encoder and decoder is used. The reliability header helps describe the encoded data carried in the packet's payload. The format of the reliability header depends on the coding used, and this is negotiated out-of-band. As an example, one of the FEC headers described in [12] could be used 💖
For LCT, when multiple rate congestion control is used, congestion control is achieved by sending packets for a given session to several LCT channels. Individual receivers dynamically join one or more of these channels, according to the network congestion they see 🦋 LCT headers include an opaque field which MUST be used to convey congestion control information to the receivers. The actual congestion control scheme to use with LCT is negotiated out-of-band. Some examples of congestion control protocols that may be suitable for content delivery are described in [22], [3], and [25]. Other congestion controls may be suitable when LCT is used for a streaming application 🌊
This document doesn't specify or restrict the type of exchanges between LCT (or any PI built on top of LCT) and an upper application. Some upper APIs may use an object-oriented approach, where the only possible unit of data exchanged between LCT (or any PI built on top of LCT) and an application, either at a source or at a receiver, is an object. Other APIs may let a sending or receiving application exchange a subset of an object with LCT (or any PI built on top of LCT), or may even follow a streaming model. These considerations are outside the scope of this document 🫧
4.1. Environmental Requirements and Considerations 🌸
okay bestie, let's talk about the environment LCT lives in 🦋 LCT is built for congestion controlled delivery of objects and streams, so both reliable content delivery AND streaming multimedia. it's giving versatile ✨
LCT works with both multicast and unicast delivery. it needs connectivity from a sender to its receivers, but it does NOT need connectivity going back from receivers to the sender (no cap, that's a lot of freedom 💅). it works with basically every network: LANs, WANs, intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. so the raw scalability is literally unlimited 😭 BUT, and this is a big but, when other apps get built on top of LCT, those apps can limit scalability by their very nature. like if receivers need out of band info to join a session, or if the app lets receivers send reception statistics back to the sender, then the app's scalability is capped by how well everyone can send, receive, and process that extra data 🙈
LCT needs receivers to be able to uniquely identify and demux packets that belong to an LCT session 🔍 so there MUST be a Transport Session Identifier (TSI) for every LCT session. the TSI is scoped by the sender's IP address, and the sender's IP address together with the TSI MUST uniquely identify the session. if the transport is UDP as described in RFC 768 [16], then the 16 bit UDP source port number MAY serve as the TSI 🧚 the TSI value MUST be the same in every place it shows up within a packet. and if there's no underlying TSI from the network, transport, or any other layer, then the TSI MUST be included in the LCT header 💜
LCT is presumed to run on top of a "best effort" service, one that doesn't guarantee packet reception or packet order and has no support for flow or congestion control 🌊 the Any-Source Multicast (ASM) model of IP multicast, as defined in RFC 1112 [5], is a perfect example of that. the basic service from RFC 1112 is largely scalable, but providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially when the receivers are heterogeneous. be careful bestie 🫶
there are currently two multicast delivery models: ASM, defined in RFC 1112 [5], and Source-Specific Multicast (SSM), defined in [10]. LCT works with both, just in slightly different ways and with different environmental concerns 🎀 with ASM, a sender S sends packets to a multicast group G, and the LCT channel address is the pair (S,G), where S is the sender's IP address and G is a multicast group address. with SSM, a sender S sends packets to an SSM channel (S,G), and the LCT channel address is exactly the SSM channel address.
a sender can locally allocate unique SSM channel addresses, which makes LCT channel address allocation easy with SSM ✨ with ASM, the sender must uniquely choose the ASM multicast group address across the scope of the group, which makes allocation harder 😩
LCT channels and SSM channels coincide, so a receiver will only get packets sent to the LCT channel it asked for. with ASM, the receiver joins an LCT channel by joining a multicast group G, and every packet sent to G can reach the receiver no matter who the sender is. so SSM has compelling security advantages over ASM when it comes to preventing denial of service attacks 🛡️ in either case, receivers SHOULD use mechanisms to filter out packets from unwanted sources. filtering is a must, periodt 💅
some networks don't play nicely with every congestion control protocol LCT could use 🛰️ especially for satellite or wireless networks, where receivers might have no way to effectively reduce their reception rate, since there may be a fixed transmission rate allocated to the session. not ideal, bestie 😭
4.2. Delivery service models 🧁
LCT can support several different delivery service models 💜 two examples are briefly described here.
Push service model.
one way a push service model can be used for reliable content delivery is to deliver a series of objects. for example, a receiver could join the session and dynamically adapt how many LCT channels it's joined to, until it has received enough packets to rebuild an object 🎁 after reconstructing the object, the receiver can stay in the session and wait for the next object to come through.
the push model is especially attractive in satellite and wireless networks 🛰️ in those cases, a session may consist of one fixed rate LCT channel.
On-demand content delivery model.
for an on-demand content delivery service, senders typically transmit for some given time period, picked to be long enough for all the intended receivers to join the session and recover the object 🕰️ for example, a popular software update might be sent over LCT for several days, even though a receiver may be able to finish the download in one hour total of connection time, maybe spread over several intervals of time. the main character of time management 💅
in this case the receivers join the session and dynamically adapt how many LCT channels they subscribe to, based on available bandwidth. then they drop from the session once they've received enough packets to recover the object 👑
let's do some math, because it's giving engineer 🤓 assume an object is 50 MB. the sender could send 1 KB packets to the first LCT channel at 50 packets per second, so receivers using just that LCT channel could finish the object in 1,000 seconds without loss. they'd even be able to finish with some substantial amount of loss, thanks to coding for reliability 🔥 furthermore, the sender could use a number of LCT channels so the aggregate rate of 1 KB packets across all of them is 1,000 packets per second. then a receiver could finish the object in as little 50 seconds (assuming no loss and that the congestion control mechanism immediately converges to using all the LCT channels) 🚀
Other service models.
there are lots of other delivery service models LCT can be used for that aren't covered above 🌈 as examples, a live streaming service or an on-demand archival content streaming service. describing all the potential applications, the right delivery service model, and the extra mechanisms needed to support those functions when combined with LCT is beyond the scope of this document 🙃 this document only tries to describe the minimal common scalable elements these diverse applications need when they use LCT as their delivery transport.
4.3. Congestion Control ⚡
the specific congestion control protocol for an LCT session depends on the type of content being delivered 🍓 the general behavior is to reduce throughput when there's congestion and gradually increase it when there isn't. the actual dynamic behavior, like how it responds to single losses, can vary though 🙈
some possible congestion control protocols for reliable content delivery using LCT are described in [22], [3], and [25]. different delivery service models might need different congestion control protocols 🦋
5. Packet Header Fields 🎀
okay this part is where the packet layout gets real 🧚 packets sent to an LCT session MUST include an "LCT header". the format described below is the default one, and it's the one recommended for protocol instantiations so everything stays uniform across them 💖 other LCT header formats MAY be used by protocol instantiations. but if a protocol instantiation that uses LCT doesn't use the default LCT header format, then that instantiation MUST specify the lengths and positions, within the LCT header it uses, of all the fields described in the default LCT header 📋
other building blocks MAY describe some of the same fields as the LCT header. it is RECOMMENDED that protocol instantiations using multiple building blocks include shared fields at most once in each packet 🫶 so, for example, if another building block is used with LCT that includes the optional Expected Residual Time field, then the Expected Residual Time field SHOULD be carried in each packet at most once.
the position of the LCT header within a packet MUST be specified by any protocol instantiation that uses LCT 📍
5.1. Default LCT header format 🌷
the default LCT header is variable in size, which is specified by a length field in the third byte of the header 📏 in the LCT header, every integer field is carried in "big-endian" or "network order" format, meaning the most significant byte (octet) goes first. bits designated as "padding" or "reserved" (r) MUST by set to 0 by senders and ignored by receivers 🙈 unless noted otherwise, numeric constants in this spec are in decimal (base 10).
the format of the default LCT header is shown in Figure 1 ✨
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*(C+1) bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32*O+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if T = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if R = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1 - Default LCT header format
the function and length of each field in the default LCT header are as follows 📝 fields marked as "1" mean the corresponding bits MUST be set to "1" by the sender 💖 fields marked as "r" or "0" mean the corresponding bits MUST be set to "0" by the sender.
LCT version number (V): 4 bits
indicates the LCT version number. the LCT version number for this specification is 1 🌸
Congestion control flag (C): 2 bits
C=0 indicates the Congestion Control Information (CCI) field is 32-bits in length. C=1 indicates the CCI field is 64-bits in length. C=2 indicates the CCI field is 96-bits in length. C=3 indicates the CCI field is 128-bits in length. 💅
Reserved (r): 2 bits
Reserved for future use, bestie 🌸 A sender MUST set these bits to zero and a receiver MUST ignore these bits. No drama, no exceptions 💅
Transport Session Identifier flag (S): 1 bit
So S tells you how many full 32-bit words are in the TSI field 🎀 The TSI field is 32*S + 16*H bits long, i.e. it's either 0 bits, 16 bits, 32 bits, or 48 bits.
Transport Object Identifier flag (O): 2 bits
Same energy, but for the TOI field 🦋 O is how many full 32-bit words are in it. The TOI field is 32*O + 16*H bits long, i.e., it's either 0 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 bits. Iconic range 👑
Half-word flag (H): 1 bit
Okay this one is so clever ✨ The TSI and TOI fields are both multiples of 32 bits plus 16*H bits. That lets the TSI and TOI lengths be multiples of a half-word (16 bits), while the total length of TSI and TOI together still lands on a multiple of 32 bits. Math that slaps 🫶
Sender Current Time present flag (T): 1 bit
T = 0 means the Sender Current Time (SCT) field is not there. T = 1 means it is there. Senders drop the SCT in so receivers can tell how long the session has been going 🕰️
Expected Residual Time present flag (R): 1 bit
R = 0 means the Expected Residual Time (ERT) field is not there. R = 1 means it is. Senders put the ERT in so receivers know how much longer the session or object transmission will keep going 🧚
Senders MUST NOT set R = 1 when the ERT for the session is more than 2^32-1 time units (approximately 49 days), where time is measured in units of milliseconds. That's the cap, babe 🍓
Close Session flag (A): 1 bit
Normally A is set to 0 🌈 The sender MAY set A to 1 when stopping transmission of packets for the session is coming up soon. A MAY be set to 1 in just the last packet sent for the session, or A MAY be set to 1 in the last few seconds of packets sent for the session. Once the sender flips A to 1 in one packet, the sender SHOULD keep A at 1 in all later packets until transmission for the session stops. When a receiver gets a packet with A set to 1, it knows the sender is about to stop sending packets for the session right now. The receiver SHOULD then assume that no more packets are coming to the session 🚪✨
Close Object flag (B): 1 bit
Same vibe as A, but for objects 🎀 Normally B is set to 0. The sender MAY set B to 1 when stopping transmission of packets for an object is coming up soon. If the TOI field is in use and B is set to 1, then stopping transmission for the object identified by the TOI field is imminent. If the TOI field is not in use and B is set to 1, then stopping transmission for the one object in the session identified by out-of-band information is imminent. B MAY be set to 1 in just the last packet transmitted for the object, or B MAY be set to 1 in the last few seconds packets transmitted for the object. Once the sender sets B to 1 in one packet for a particular object, the sender SHOULD set B to 1 in all subsequent packets for that object until transmission of packets for the object stops. When a receiver gets a packet with B set to 1, the sender is about to stop sending packets for that object right now. When a receiver receives a packet with B set to 1, it SHOULD assume that no more packets will be sent for the object to the session 💀
LCT header length (HDR_LEN): 8 bits
This is the total length of the LCT header in units of 32-bit words 📏 The LCT header length MUST be a multiple of 32 bits. HDR_LEN is what lets you jump straight to the part of the packet after the LCT header. That's the first other header if one exists, or the packet payload if there's a payload and no other header, or the end of the packet if there are no other headers or payload. Direct access, no detours 🏃♀️
Codepoint (CP): 8 bits
CP is an opaque identifier that gets handed to the packet payload decoder so it knows which codec is being used for the payload 🎶 The mapping between the codepoint and the actual codec is defined per session and shared out-of-band as part of the session description information. CP works kinda like the Payload Type (PT) field in RTP headers, as described in RFC 1889 [21] 💜
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
CCI carries congestion control info 🚦 For example, it could hold layer numbers, logical channel numbers, and sequence numbers. For this spec, the field is opaque, so we don't poke around inside it 🙈 The length depends on C:
- This field MUST be 32 bits if
C=0. - This field MUST be 64 bits if
C=1. - This field MUST be 96 bits if
C=2. - This field MUST be 128 bits if
C=3.
Transport Session Identifier (TSI): 0, 16, 32 or 48 bits
Okay, the TSI is the bestie who uniquely identifies a session among all sessions from one particular sender 👯♀️ It's scoped by the sender's IP address, so the IP address plus the TSI together uniquely identify the session. A TSI plus the sender's IP always identifies a session, but whether the TSI actually shows up in the LCT header depends on what's being used as the TSI value. If the underlying transport is UDP, then the 16-bit UDP source port number MAY serve as the TSI for the session. If the TSI value shows up multiple times in a packet, every occurrence MUST be the same value. If no TSI is provided by the network, transport, or any other layer, then the TSI MUST be included in the LCT header.
The TSI MUST be unique among all sessions the sender serves while the session is active, and for a long time before and after it's active. Its main job is stopping receivers from accidentally grabbing packets from a sender that belong to other sessions they didn't sign up for. Picture this: a session gets deactivated, then the sender activates a new session that uses some of the same channels. A receiver that stays connected to the first session through all that could mistakenly accept packets from the second session as part of the first one, if the two TSIs match. Yikes 😭 The mapping of TSI values to sessions is outside the scope of this document and is handled out-of-band.
The length of the TSI field is 32*S + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits 🫧
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 bits.
The TOI tells you which object within the session this packet is about 📦 For example, a sender could send a bunch of files in the same session, using TOI=0 for the first file, TOI=1 for the second one, and so on. Another option: the TOI could be a unique global identifier for an object being sent from several senders at once, and its value could be a hash of the object. The mapping of TOI values to objects is outside the scope of this document and is handled out-of-band. The TOI field MUST be used in all packets if more than one object is going to be sent in a session. In other words, the TOI field is either present in all the packets of a session or never present at all 🎀
The length of the TOI field is 32*O + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits 💖
Sender Current Time (SCT): 0 or 32 bits
SCT is the sender's current clock at the moment this packet was sent 🕐 It's measured in units of 1ms and computed modulo 2^32 units from the start of the session.
This field MUST NOT be present if T=0 and MUST be present if T=1.
Expected Residual Time (ERT): 0 or 32 bits
ERT is the sender's expected remaining transmission time for the current session, or for the transmission of the current object, measured in units of 1ms ⏳ If the packet with the ERT field also has the TOI field, then ERT refers to the object that the TOI points to. Otherwise, it refers to the session.
This field MUST NOT be present if R=0 and MUST be present if R=1. 🌸
5.2. Header-Extension Fields 🎀
okay so Header Extensions are how LCT fits in optional fields that aren't always there or that come in different sizes 🧚 two big examples: extended-size versions of fields that already exist, and sender and receiver authentication info 🔐
you can tell an extension is there from the LCT header length (HDR_LEN). if HDR_LEN is bigger than the standard header, whatever room is left over is filled with Header Extension fields ✨
if extensions are present, they MUST be processed so they get recognized before you do any congestion control stuff or accept the packet at all. no skipping this step, bestie 💅 if you don't recognize an extension, the default is to ignore it. that's what lets LCT get backward-compatible upgrades without bumping the LCT version number 🦋 non backward-compatible extensions CANNOT be added without changing the version number, so don't even try 💀
a protocol instantiation MAY override that default for its PI-specific extensions (more on that below) 🫶
there are two formats. the first is for variable-length extensions, with HET values from 0 to 127. the second is for fixed-length extensions that are one 32-bit word, using HET values from 127 to 255 🌈
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Format of additional headershere's the breakdown of each sub-field, it's giving organized 📋
Header Extension Type (HET): 8 bits 🍓
this is the type of the Header Extension. this doc defines a bunch of types, and more can show up in future versions of the spec. HET values 0 to 127 are for variable-length extensions, and HET values 128 to 255 are for fixed-length 32-bit extensions.
Header Extension Length (HEL): 8 bits 📏
this is the length of the whole Header Extension field, measured in multiples of 32-bit words. HEL MUST be present for variable-length extensions (HET between 0 and 127) and MUST NOT be present for fixed-length extensions (HET between 128 and 255). so only one of these formats gets it, and it's not a vibe you can ignore 🙈
Header Extension Content (HEC): variable length 💜
this is the actual content of the extension. its format depends on the Header Extension type. for fixed-length extensions, the HEC is 24 bits. for variable-length extensions, the HEC has a variable size, which is set by the HEL field. also, the length of each Header Extension field MUST be a multiple of 32 bits, and the total size of the LCT header (all Header Extensions and all optional header fields together) cannot go over 255 32-bit words. that's the ceiling, no exceptions 🚫
Header Extensions are split up into general LCT extensions and Protocol Instantiation specific extensions (PI-specific). general LCT extensions use HET in the ranges 0:63 and 128:191 inclusive. PI-specific extensions use HET in the ranges 64:127 and 192:255 inclusive. the PI-specific ones are the protocol-instantiation-specific ones, so keep them straight, iykyk 🧠
general LCT extensions are meant to let backward-compatible enhancements happen without changing the LCT version number. again, non backward-compatible header extensions CANNOT be introduced without changing the LCT version number ⚠️
PI-specific extensions are reserved for PI-specific use, with semantic and default parsing actions that the PI defines ✨
these are the general LCT Header Extension types that are defined, periodt 👑
EXT_NOP=0: No-Operation extension. the information in this extension field MUST be ignored by receivers. 💤EXT_AUTH=1: Packet authentication extension. this carries information used to authenticate the sender of the packet. the format of this Header Extension and how it gets processed is outside the scope of this document, and it gets communicated out-of-band as part of the session description 🔑
it is RECOMMENDED that senders provide some form of packet authentication. if EXT_AUTH is present, whatever packet authentication checks can be done right away when the packet is received SHOULD be done before accepting the packet and before performing any congestion control-related action on it 🛡️
some packet authentication schemes add a delay of several seconds between when a packet is received and when it's fully authenticated. any congestion control related action that's appropriate MUST NOT be postponed by that full packet authentication. no waiting around for auth to finish before you do the congestion stuff, no cap 😤
all senders and receivers implementing LCT MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but they MAY NOT be able to parse its content. so recognizing it is required, but parsing it is optional, and that's the whole tea ☕
6. Operations 💅
6.1. Sender Operation ✨
before joining an LCT session, a receiver MUST obtain a session description. the session description MUST include:
- the sender IP address;
- the number of LCT channels;
- the addresses and port numbers used for each LCT channel;
- the Transport Session ID (TSI) to be used for the session;
- enough information to determine the congestion control protocol being used;
- enough information to determine the packet authentication scheme being used, if it is being used.
the session description could also include, but isn't limited to:
- the data rates used for each LCT channel;
- the length of the packet payload;
- the mapping of TOI value(s) to objects for the session;
- any information that's relevant to each object being transported, such as when it will be available within the session, for how long, and the length of the object.
protocol instantiations using LCT MAY place additional requirements on what has to be included in the session description. for example, a protocol instantiation might require the data rates for each channel, or the mapping of TOI value(s) to objects for the session, or other information related to other headers that might need to be in the session description 🎀
the session description could be in a form like SDP as defined in RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], etc. it might be carried in a session announcement protocol like SAP as defined in RFC 2974 [9], obtained using a proprietary session control protocol, located on a Web page with scheduling info, or conveyed via E-mail or other out-of-band methods. discussion of session description format and how session descriptions get distributed is beyond the scope of this document 📬
within an LCT session, a sender using LCT transmits a sequence of packets, each in the format defined above. packets are sent from a sender using one or more LCT channels, and together those channels make up a session. transmission rates can be different across channels and can vary over time 🌊 the specification of the other building block headers and the packet payload used by a complete protocol instantiation using LCT is beyond the scope of this document. this document does not specify the order in which packets are transmitted, or how a session gets organized into multiple channels. those things affect the efficiency of the protocol, but they don't affect the correctness or the inter-operability of LCT between senders and receivers 🫶
several objects can be carried within the same LCT session. in that case, each object MUST be identified by a unique TOI. objects MAY be transmitted sequentially, or they MAY be transmitted concurrently. it's good practice to only send objects concurrently in the same session if the receivers taking part in that part of the session are interested in receiving all of the objects. the reason is that it wastes bandwidth and networking resources to have receivers get data for objects they don't care about 🗑️
typically, the sender(s) keep sending packets in a session until the transmission is considered complete. the transmission may be considered complete when some time has expired, a certain number of packets have been sent, or some out-of-band signal (possibly from a higher level protocol) has indicated completion by a sufficient number of receivers 🏁
for the reasons above, this document does not put any restriction on packet sizes. however, for network efficiency, it's recommended that the sender uses as large a packet payload as possible, but in a way that packets do not exceed the network's maximum transmission unit size (MTU), or when fragmentation coupled with packet loss might cause severe inefficiency in the transmission 📦
it is recommended that all packets have the same or very similar sizes, because this can have a severe impact on how well congestion control schemes work, like the ones described in [22], [3], and [25] 📉
a sender of packets using LCT MUST implement the sender-side part of one of the congestion control schemes that is in accordance with RFC 2357 [13], using the Congestion Control Information field provided in the LCT header. the corresponding receiver congestion control scheme is to be communicated out-of-band and MUST be implemented by any receivers participating in the session 🌸
6.2. Receiver Operation ✨
okay so receivers can totally operate differently depending on the delivery service model 💅 for an on demand service model, receivers may join a session, grab the packets they need to rebuild the object, and then leave the session 🦋 for a streaming service model, though, a receiver may be continuously joined to a set of LCT channels so it can download all the objects in a session 🌊
To be able to participate in a session, a receiver MUST obtain the relevant session description information as listed in Section 6.1 📜
If packet authentication information is in an LCT header, it SHOULD be used as specified in Section 5.2 🔐 to be a receiver in a session, you MUST be able to process the LCT header 🫶 the receiver MUST be able to discard, forward, store or process the other headers and the packet payload 🎀 and if a receiver can't process an LCT header, it MUST drop from the session 💀
To be able to participate in a session, a receiver MUST implement the congestion control protocol specified in the session description, using the Congestion Control Information field in the LCT header 🌸 if a receiver can't implement the congestion control protocol used in the session, it MUST NOT join the session 🙈 when the session is sent over multiple LCT channels, receivers MUST initially join channels according to the specified startup behavior of the congestion control protocol ⭐ for a multiple rate congestion control protocol that uses multiple channels, this typically means a receiver starts by joining only a minimal set of LCT channels (possibly just one) that together carry packets at a low rate 🐢 the whole point of this rule is to stop receivers from starting out at high data rates 🛑
Several objects can be carried either one after another or at the same time within the same LCT session 🍓 in that case, each object is identified by a unique TOI 🔑 even if a server stops sending packets for an old object before it starts sending packets for a new one, the network and the underlying protocol layers can still cause some reordering of packets, especially when things are sent over different LCT channels 🌀 so receivers SHOULD NOT assume that getting a packet for a new object means there are no more packets in transit for the previous one, at least for some amount of time ⏳
A receiver MAY be concurrently joined to multiple LCT sessions from one or more senders 🧚 the receiver MUST perform congestion control on each such LCT session 👑 if the congestion control protocol gives the receiver some flexibility in what it does within a session, then the receiver MAY make choices to optimize packet flow performance across the multiple LCT sessions, as long as it still follows the congestion control rules for each LCT session individually 💖
7. Requirements from Other Building Blocks 🧩
as described in RFC 3048 [23], LCT is a building block that's meant to be used together with other building blocks to help specify a protocol instantiation 🫧 a congestion control building block that uses the Congestion Control information field within the LCT header MUST be used by any protocol instantiation that uses LCT, and other building blocks MAY also be used, such as a reliability building block 🛠️
the congestion control MUST be applied to the LCT session as an entity, i.e., over the aggregate of the traffic carried by all of the LCT channels associated with the LCT session 🌈 some possible schemes are specified in [22], [3], and [25] 📚 the Congestion Control Information field in the LCT header is an opaque field that's reserved to carry information related to congestion control 🔒 there MAY also be congestion control Header Extension fields that carry additional information related to congestion control ✨
the particular layered encoder and congestion control protocols used with LCT have an impact on the performance and applicability of LCT 📊 for example, some layered encoders used for video and audio streams can produce only a very limited number of layers, which means very coarse control over the rate at which receivers in a session get packets 🎬 and when LCT is used for reliable data transfer, some FEC codecs are inherently limited in the size of the object they can encode, and for objects bigger than that size the reception overhead on the receivers can grow a lot 📈😭
a more in-depth description of the use of FEC in Reliable Multicast Transport (RMT) protocols is given in [11] 🔍 some of the FEC codecs that MAY be used in conjunction with LCT for reliable content delivery are specified in [12] 🧁 the Codepoint field in the LCT header is an opaque field that can be used to carry information related to the encoding of the packet payload 🫶
LCT also requires receivers to obtain a session description, as described in Section 6.1 🗂️ the session description could be in a form such as SDP as defined in RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], and distributed with SAP as defined in RFC 2974 [9], using HTTP, or in other ways 🌸 it is RECOMMENDED that an authentication protocol such as IPSEC [11] be used to deliver the session description to receivers, so the correct session description actually arrives 🔐
it is recommended that LCT implementors use some packet authentication scheme to protect the protocol from attacks 🛡️ an example of a possibly suitable scheme is described in [15] 💜
some protocol instantiations that use LCT MAY use building blocks that require the generation of feedback from the receivers to the sender 🗣️ however, the mechanism for doing this is outside the scope of LCT 🙃
8. Security Considerations 🚨
okay this section is seriously important, bestie, so read it carefully 😭 these are real attack risks for real networks
LCT can be subject to denial-of-service attacks by attackers who try to confuse the congestion control mechanism, or who send forged packets to the session that would prevent successful reconstruction or cause inaccurate reconstruction of large portions of an object by receivers 💀 LCT is especially affected by this kind of attack, since many receivers may receive the same forged packet 🫠 it is therefore RECOMMENDED that an integrity check be made on received objects before they're delivered to an application, e.g., by appending an MD5 hash [17] to an object before it's sent and then computing the MD5 hash once the object is reconstructed, to make sure it's the same as the sent object 🔎 moreover, to get strong cryptographic integrity protection, a digital signature verifiable by the receiver SHOULD be computed on top of that hash value ✍️ it is also RECOMMENDED that protocol instantiations that use LCT implement some form of packet authentication, such as TESLA [15], to protect against these attacks 🛡️ finally, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to the receivers, to limit the chance of a bad agent injecting forged packets into the multicast tree data path 🌲
another vulnerability of LCT is the chance that receivers get an incorrect session description for the session 😬 the consequences could be that legitimate receivers with the wrong session description can't correctly receive the session content, or that receivers accidentally try to receive at a much higher rate than they can handle, which disrupts traffic in parts of the network 🌪️ to avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions, e.g., by using source authentication so receivers only accept legitimate Session Descriptions from authorized senders 🧾
a receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect the health of the network along the path between the sender and that receiver, and may also affect the reception rates of other receivers joined to the session 🥀 it is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session 🪪 how receivers identify themselves as legitimate is outside the scope of this document 🙏
9. IANA Considerations 📋
no information in this specification is subject to IANA registration 🌷
building blocks used in conjunction with LCT MAY introduce additional IANA considerations 🎈
10. Acknowledgments 💌
thanks to Vincent Roca and Roger Kermode for detailed comments and contributions to this document 🫶 thanks also to Bruce Lueckenhoff, Hayder Radha and Justin Chapweske for detailed comments on this document 🙌
11. References ✨
okay bestie, these are the receipts 🧾💅 every source the spec leans on, all listed so you can go check them yourself 🔍
- [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [3] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Roetter, A. and W. Shaver, "FLID-DL: Congestion Control for Layered Multicast", Proceedings of Second International Workshop on Networked Group Communications (NGC 2000), Palo Alto, CA, November 2000.
- [4] Byers, J.W., Luby, M., Mitzenmacher, M. and A. Rege, "A Digital Fountain Approach to Reliable Distribution of Bulk Data", Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
- [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
- [6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, January 1997.
- [7] Gemmell, J., Schooler, E. and J. Gray, "Fcast Multicast File Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.
- [8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
- [10] Holbrook, H. W., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
- [11] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
- [12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
- [13] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
- [14] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
- [15] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
- [16] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- [17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [18] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, Apr 1997.
- [19] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast congestion control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.
- [20] Rizzo, L and L. Vicisano, "Reliable Multicast Data Distribution protocol based on software FEC techniques", Proceedings of the Fourth IEEES Workshop on the Architecture and Implementation of High Performance Communication Systems, HPCS'97, Chalkidiki Greece, June 1997.
- [21] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
- [22] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", IEEE Infocom'98, San Francisco, CA, Mar.28-Apr.1 1998.
- [23] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
- [24] Kermode, R., Vicisano, L., "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
- [25] Luby, M., Goyal V. K, Skaria S., Horn, G., "Wave and Equation Based Rate Control using Multicast Round-trip Time", Proceedings of ACM SIGCOMM 2002, Pittsburgh PA, August, 2002.
Authors' Addresses 🎀
these are the people who wrote it, with their contact details 💌
Michael Luby
Digital Fountain
39141 Civic Center Dr.
Suite 300
Fremont, CA, USA, 94538
EMail: luby@digitalfountain.com
Jim Gemmell
Microsoft Research
455 Market St. #1690
San Francisco, CA, 94105
EMail: jgemmell@microsoft.com
Lorenzo Vicisano
cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA, USA, 95134
EMail: lorenzo@cisco.com
Luigi Rizzo
Dip. Ing. dell'Informazione,
Univ. di Pisa
via Diotisalvi 2, 56126 Pisa, Italy
EMail: luigi@iet.unipi.it
Mark Handley
ICIR
1947 Center St.
Berkeley, CA, USA, 94704
EMail: mjh@icir.org
Jon Crowcroft
Marconi Professor of Communications Systems
University of Cambridge
Computer Laboratory
William Gates Building
J J Thomson Avenue
Cambridge CB3 0FD, UK
EMail: Jon.Crowcroft@cl.cam.ac.ukFull Copyright Statement 🌈
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 💜
📦 where this page comes from
- ietf: rfc3451 2002-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms