RFC 5651
Layered Coding Transport (LCT) Building Block
RFC 5651: Layered Coding Transport (LCT) Building Block 🎀
Part 1 of 9, more coming bestie 💅
okay so this is RFC 5651, published in October 2009 🗓️ by M. Luby, M. Watson, and L. Vicisano, all from Qualcomm, Inc. 💜 It came out of the Network Working Group and is a Standards Track document, which means it's an actual Internet standard, not an experiment. ✨ It obsoletes RFC 3451 (the older version) and doesn't update anything else. 🦋
Abstract ✨
LCT, the Layered Coding Transport Building Block, gives transport-level support for reliable content delivery and stream delivery protocols. 💖 It's built mainly for protocols that use IP multicast, but unicast protocols can use it too. 🌸 It plays nicely with congestion control that gives receivers multiple delivery rates, and it also works with coding techniques that reliably deliver content. 🔥 This document obsoletes RFC 3451. 💅
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. 🫶 If you want to know where this protocol stands officially, check the current edition of "Internet Official Protocol Standards" (STD 1). 📜 Distribution of this memo is unlimited. 🌈
Copyright Notice ✨
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as they stood on the date this document was published. 📚 Please read those carefully, because they spell out your rights and restrictions for this document. 💅 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the BSD License describes. 🧚
This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. 🙈 Some of that material's copyright holders may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. 💀
So, without an adequate license from whoever controls the copyright in that material, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. 🔥 The one exceptions are formatting it for publication as an RFC and translating it into languages other than English. 🫶
Table of Contents ✨
1. Introduction ....................................................3
2. Rationale .......................................................3
3. Functionality ...................................................4
4. Applicability ...................................................7
4.1. Environmental Requirements and Considerations ..............9
4.2. Delivery Service Models ...................................10
4.3. Congestion Control ........................................13
5. Packet Header Fields ...........................................13
5.1. LCT Header Format .........................................13
5.2. Header-Extension Fields ...................................18
5.2.1. General ............................................18
5.2.2. EXT_TIME Header Extension ..........................20
6. Operations .....................................................23
6.1. Sender Operation ..........................................23
6.2. Receiver Operation ........................................25
7. Requirements from Other Building Blocks ........................26
8. Security Considerations ........................................28
8.1. Session and Object Multiplexing and Termination ...........28
8.2. Time Synchronization ......................................29
8.3. Data Transport ............................................29
9. IANA Considerations ............................................29
9.1. Namespace Declaration for LCT Header Extension Types ......29
9.2. LCT Header Extension Type Registration ....................30
10. Acknowledgments ...............................................30
11. Changes from RFC 3451 .........................................31
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................321. Introduction ✨
okay so LCT gives transport-level support for reliable content delivery and stream delivery protocols. 💖 It's specifically designed for protocols using IP multicast, but unicast protocols get support too. 🌸 It's compatible with congestion control that gives receivers multiple delivery rates, and it also works with coding techniques that give reliable content delivery. 🦋
This document describes a building block as defined in [RFC3048]. 🧚 It's a product of the IETF RMT WG and follows the general guidelines in [RFC3269]. 💅
[RFC3451] was published in the "Experimental" category, and this document obsoletes it. 🙈 That earlier document was a previous version of the protocol. 🍓
So this Proposed Standard spec is based on [RFC3451] and backwards compatible with it. ✨ It's been updated based on accumulated experience and the protocol maturing since it was first published. 💜 That experience applies both to this specification itself and to the congestion control strategies used with it. 🔥
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 [RFC2119]. 👑
2. Rationale ✨
LCT gives transport-level support for massively scalable protocols that run on 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 of multiple channels, all coming from a single sender. 🦋 Those channels are used for some period of time to carry packets about transmitting one or more objects that receivers might be interested in. 🧚 Why one sender per session? Because that's the right granularity for regulating packet traffic with congestion control. 🔥 Why multiple channels in one session? Because there are massively scalable congestion control protocols that use multiple channels per session. ✨ Those protocols count as layered, since a receiver joins and leaves channels in a layered order while it's in the session. 💅
Layered channels are also useful for streaming apps. 🎀
There are coding techniques that give massively scalable reliability and asynchronous delivery, and they're compatible 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 for other apps, like layered streaming apps. 🌸
LCT avoids anything that isn't massively scalable. 🙈 For example, it has no mechanisms for sending info from receivers back to senders. 💀 That doesn't stop protocols that use LCT from sending info from receivers to senders when they need to. 🍓
LCT includes general support for congestion control, and that support must be used. 🔥 It doesn't, however, pick which congestion control to use. 💅 The reason is that every protocol has to be network friendly and provide congestion control, but the apps that can use LCT don't all want the same thing. 🦋 A content delivery protocol might want to use all the available bandwidth between receivers and the sender, so it has to back off its rate hard when there's competing traffic. 😭 A streaming protocol might want a constant rate instead of grabbing all the bandwidth, so it may not back off as fast when there's competing traffic. 🌈
Past congestion control, LCT has a bunch of fields and supports functionality that lots of protocols need. ✨ For example, it has a Transmission Session ID that tells you which session each received packet belongs to. 💜 That matters because a receiver can be joined to many sessions at once, so being able to demultiplex packets as they arrive by session is super useful. 🎀 Another example: there are optional fields in the LCT packet header that identify the object the packet payload is carrying info about. 🧚
3. Functionality ✨
okay so an LCT session is basically a bunch of LCT channels grouped together 🎀, all coming from ONE sender. The packets carry LCT headers for one or more objects. A channel is defined by the combo of a sender and an address that the sender attaches to it 🦋. Receivers join a channel to start getting the data packets the sender sends there, and they leave when they want to stop getting them 💅.
LCT is meant to be mixed with other building blocks so the whole protocol ends up 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 receivers joining and leaving all the time 🌈. Limits can come from memory or processing needs, or from the amount of feedback control and redundant data packet traffic the protocol makes 💀. Those limits can also be a side effect of the features a full reliable content or stream delivery protocol is expected to have 🙈.
The LCT header has a bunch of fields that pass session info to receivers in-band 🧚. One of the required fields is the Transmission Session ID (TSI), which lets a receiver figure out that a packet belongs to its session 🍓. Another required field is the Congestion Control Information (CCI), which gives the receiver what it needs to do the required congestion control on packets in the session 💜. The other LCT fields are optional, but they're often super useful 👑. For example, the Transport Object Identifier (TOI) tells you which object the packet has data for, and there are flags for closing the session and for closing the sending of packets for an object ✨. Header extensions can carry extra fields, like for packet authentication or timing info 🌸. The Sender Current Time (SCT) shows when the sender sent the packet, the Expected Residual Time (ERT) shows how much longer the session or transmission object will keep going, and the Session Last Change (SLC) shows when objects were added, modified, or removed from the session 🫶.
LCT supports congestion control ⭐. Congestion control MUST be used that conforms to [RFC2357] between receivers and the sender for each LCT session. Congestion control is the ability to adapt throughput to the bandwidth that's actually available on the path from the sender to a receiver, while sharing bandwidth fairly with competing flows like TCP 🦋. So the total flow of packets going 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 🎀.
With multiple rate protocols, a session usually has more than one channel, and the sender sends to those channels at rates that don't depend on the receivers 🌸. Each receiver adjusts its reception rate by joining and leaving channels on its own, based on the bandwidth it has to the sender, and it doesn't care what the other receivers are doing 💅. So with multiple rate protocols, each receiver's reception rate can change dynamically, totally independent of everyone else 🔥.
With single rate protocols, a session usually has one channel, and the sender varies its sending rate over time based on feedback from receivers 🧚. Each receiver stays joined to that channel for its whole time in the session 🍓. So with single rate protocols, each receiver's reception rate can change dynamically too, but it moves in coordination with all of the other receivers 🫶.
Generally, a multiple rate protocol is better than a single rate protocol in a heterogeneous receiver environment 👑. That's because it usually scales to lots of receivers more easily and gives each individual receiver higher throughput ✨. Using the multiple rate congestion control scheme defined in [RFC3738] is RECOMMENDED 💜. Other multiple rate congestion control protocols are described in [VIC1998] and [BYE2000] 🌈. A possible single rate congestion control protocol is described in [RIZ2000] ⭐.
Layered coding means you can make a coded stream of packets and split it into an ordered set of layers 🦋. The coding is there to provide some kind of reliability, and the layering lets the receiver's experience (like playout quality 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 first showed up with audio and video streams 🌸. For example, the info in a TV broadcast could be split into three layers: black and white, color, and HDTV quality 📺💅. Receivers can get different quality levels without the sender having to copy the same info into each layer 🔥.
Layered coding can also be extended to reliable content delivery protocols when Forward Error Correction (FEC) is used to code the data stream 🧚. You can read about this in [RIZ1997a], [RIZ1997b], [GEM2000], [VIC1998], and [BYE1998] 🍓. With FEC, the data stream is transformed so that rebuilding a data object doesn't depend on getting specific data packets, only on how many different packets were received 🫶. So when a receiver gets more layers, it can cut down its transfer time accordingly 👑. Using FEC for reliability can boost scalability a LOT compared to other ways of doing reliability ✨. More details on using FEC for reliable content delivery are in [RFC3453] 💜.
Reliable protocols aim to guarantee that data gets delivered reliably from the sender to the intended recipients 🌈. Those guarantees go all the way from simple packet data integrity to reliable delivery of an exact copy of an object to every intended recipient ⭐. Several reliable content delivery protocols have been built on top of IP multicast without using FEC, but for a lot of them, scalability wasn't the main design goal 🦋.
Two of the big challenges in scaling reliable content delivery over IP multicast are dealing with the amount of data flowing from receivers back to the sender, and the sender's response to it, which is usually data retransmissions 😭. Protocols that avoid that feedback and keep retransmissions to a minimum can be massively scalable 🎀. LCT can be combined with FEC codes or a layered codec to get reliability with little or no feedback 🌸.
Protocol instantiations (PIs) 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 conforms to [RFC2357] 🔥. 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 ✨
okay so an LCT session is a logically related bundle of one or more LCT channels, all coming from a single sender 🎀. The channels get used for some stretch of time to carry packets with LCT headers, and those headers are about sending one or more objects that receivers might actually care about 💖.
LCT is most applicable for delivering objects or streams in a session of substantial length 🦋. We're talking stuff that adds up to anywhere from hundreds of kilobytes to many gigabytes, in a session that lasts on the order of tens of seconds or more ✨. It's built for the big stuff, bestie.
As 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, and receiving all three could allow HDTV quality reception 🤩. In this example, the objects could be the individual TV programs being transmitted.
As 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 and concurrently receive packets from subsets of these channels until it has enough packets in total to recover the object 🧚. Then it can leave the session, or stay connected listening for session description information only, until it's time to receive the next object. In this case, the quality metric is the time required to receive each object ⏱️.
Before joining a session, receivers must obtain enough of the session description to start the session 🫶. This includes the relevant session parameters a receiver needs to take part in the session, plus all information relevant to congestion control. The sender decides the session description, and it's typically communicated to receivers out-of-band. In some cases, as described later, parts of the session description that aren't required to initiate a session MAY be included in the LCT header, or communicated to a receiver out-of-band after the receiver has joined the session 👀.
An encoder MAY be used to generate the data that goes in the packet payload, so you get reliability 💅. A suitable decoder is then 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 encoding data carried in the payload of the packet. 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 [RFC5052] could be used.
For LCT, when multiple rate congestion control is used, congestion control is achieved by sending packets associated with a given session to several LCT channels 🌈. Individual receivers dynamically join one or more of these channels, depending on the network congestion as the receiver sees it. LCT headers include an opaque field that 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 [VIC1998], [BYE2000], and [RFC3738]. 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 protocol instantiation 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 protocol instantiation built on top of LCT) and an application, whether 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. Those considerations are outside the scope of this document 🌸.
4.1. Environmental Requirements and Considerations
LCT is intended for congestion controlled delivery of objects and streams, covering both reliable content delivery and streaming of multimedia information 🎬.
LCT can be used with both multicast and unicast delivery 📡. It requires connectivity between a sender and receivers, but it does not require connectivity from receivers back to a sender. LCT inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks 🛰️. So the inherent raw scalability of LCT is unlimited ✨. However, when other specific applications are built on top of LCT, those applications, by their very nature, may limit scalability 🥲. For example, if an application requires receivers to retrieve out-of-band information in order to join a session, or an application allows receivers to send requests back to the sender to report reception statistics, then the scalability of the application is limited by the ability to send, receive, and process this additional data.
LCT requires receivers to be able to uniquely identify and demultiplex packets associated with an LCT session 🔍. In particular, there MUST be a Transport Session Identifier (TSI) associated with each LCT session. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI MUST uniquely identify the session. If the underlying transport is UDP, as described in [RFC0768], then the 16-bit UDP source port number MAY serve as the TSI for the session 🎀. The TSI value MUST be the same in all places it occurs within a packet. If there is no underlying TSI provided by the network, transport, or any other layer, then the TSI MUST be included in the LCT header 💅.
LCT is presumed to be used with an underlying network or transport service that is a "best effort" service 🌪️. That means it doesn't guarantee packet reception or packet reception order, and it has no support for flow or congestion control. For example, the Any-Source Multicast (ASM) model of IP multicast as defined in [RFC1112] is such a "best effort" network service. While the basic service provided by [RFC1112] is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in the presence of heterogeneous sets of receivers 🧐.
There are currently two models of multicast delivery: the Any-Source Multicast (ASM) model as defined in [RFC1112], and the Source-Specific Multicast (SSM) model as defined in [RFC4607]. LCT works with both multicast models, but in slightly different ways with somewhat different environmental concerns 🙌. When using ASM, a sender S sends packets to a multicast group G, and the LCT channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the LCT channel address coincides with the SSM channel address.
A sender can locally allocate unique SSM channel addresses, which makes allocating LCT channel addresses easy with SSM 🍓. To allocate LCT channel addresses using ASM, the sender must uniquely chose the ASM multicast group address across the scope of the group, and this makes allocating LCT channel addresses more difficult with ASM 😭.
LCT channels and SSM channels coincide, so the receiver will only receive packets sent to the requested LCT channel 🔒. With ASM, the receiver joins an LCT channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by the receiver 🚨. That's why SSM has compelling security advantages over ASM for preventing denial-of-service (DoS) attacks 🛡️. In either case, receivers SHOULD use packet authentication mechanisms to mitigate such attacks (see Sections 6.2 and 7) 🔐.
Some networks aren't amenable to some congestion control protocols that could be used with LCT 🙃. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate, since there may be a fixed transmission rate allocated to the session 📉.
LCT is compatible with both IPv4 and IPv6, since no part of the packet is IP version specific 💜.
4.2. Delivery Service Models 🚀
LCT can power a bunch of different delivery service models. We're only peeking at two of them here, bestie 🦋
Push service model
One way a push service model can do reliable content delivery is by sending a series of objects 📦. Picture a receiver who joins the session and keeps adjusting how many LCT channels it's subscribed to until it has collected enough packets to rebuild an object ✨. Once the object is reconstructed, the receiver may stay in the session and wait for the next object to arrive 💖.
The push model is super giving in satellite networks and wireless networks 🛰️. In those cases, a session may consist of one fixed rate LCT channel 🎀.
A push service model works for reliable delivery of a big object, like a 100 GB file 💾. The sender can post a Session Description announcement to a control channel 📢, and receivers can keep an eye on that channel and join a session whenever a Session Description they care about shows up 👀. When a receiver gets the Session Description, it joins the session and receives packets until it has enough to reconstruct the object. At that point, the receiver can report back to the sender that its reception was completed successfully 🥳. The sender can keep sending packets for the object to the session until every receiver has reported successful reconstruction, or until some other condition is met 💅.
ALC (Asynchronous Layered Coding) has several features that support the push model, and they're honestly iconic 👑. For example, the sender can optionally include an Expected Residual Time (ERT) in the packet header extension 🧚. The ERT shows the expected remaining time of packet transmission, either for the single object in the session or for the object identified by the Transmission Object Identifier (TOI) if the session carries multiple objects 📊. Receivers can use this to figure out whether there's enough time left in the session to grab enough extra packets to recover the object ⏳. If there isn't enough time, the push application may have receivers report back to the sender so it can extend the transmission of packets for the object long enough for receivers to collect what they need 🙏. The sender can then include an ERT based on that extended object transmission time in each later packet header for the object 🌈.
There are more examples too! The LCT header can optionally contain a Close Session flag, which says when the sender is about to stop sending packets to the session 🚪. It can also have a Close Object flag, which says when the sender is about to stop sending packets for the object identified by the Transmission Object ID 🔚. Real talk though, these flags aren't a completely reliable mechanism 😭. So the Close Session flag should only be used as a hint of when the session is about to close, and the Close Object flag should only be used as a hint of when transmission of packets for the object is about to end 🫶.
On-demand content delivery model
For an on-demand content delivery service model, senders usually transmit for a set period of time 🕰️. That period is picked to be long enough for every intended receiver to join the session and recover the object 🙌. For instance, a popular software update might get transmitted using LCT for several days 📅, even though a receiver might finish the download in one hour total of connection time 😮, possibly spread over several intervals of time ⏰. In this setup, receivers can join the session at any point while it's active 🚶♀️. They leave the session once they've received enough packets to recover the object 🎉. To get a Session Description, receivers can contact a web server 🌐.
Here, receivers join the session and dynamically adjust how many LCT channels they subscribe to, based on the available bandwidth 📶. Then they drop from the session once they've received enough packets to recover the object 💜.
Let's do an example! Say an object is 50 MB 📁. The sender could send 1 KB packets to the first LCT channel at 50 packets per second 🐢. Receivers using just that one channel could finish getting the object in 1,000 seconds if there's no loss, and they'd still be able to finish even with a good amount of losses thanks to coding for reliability 🛟. The sender could also use a bunch of LCT channels so that the total rate of 1 KB packets across all of them is 1,000 packets per second 🚀. Then a receiver could finish getting the object in as little 50 seconds (assuming there's no loss, and that the congestion control mechanism immediately converges to using all the LCT channels) ⚡.
Other service models
There are tons of other delivery service models LCT can be used for that we didn't cover above 🌟. Some examples are a live streaming service model or an on-demand archival content streaming service model 📺. Describing all the potential applications, the right delivery service model for each, and the extra mechanisms needed to support those features when combined with LCT is beyond the scope of this document 🙅♀️. This document only tries to describe the minimal common scalable elements that these diverse applications use with LCT as the delivery transport 🧩.
4.3. Congestion Control 🌊
The congestion control protocol used for LCT sessions depends on the type of content being delivered 🎁. Generally, the congestion control protocol reduces throughput when there's congestion and gradually increases it when there isn't 📉📈. The actual dynamic behavior can vary, though (for example, how it responds to single losses) 🤷♀️.
It is RECOMMENDED that the congestion control mechanism specified in [RFC3738] be used 💅. Some other possible congestion control protocols for reliable content delivery using LCT are described in [VIC1998] and [BYE2000] 📚. Different delivery service models might need different congestion control protocols 🔥.
5. Packet Header Fields 🎀
Packets sent to an LCT session MUST include an "LCT header" 📬. The LCT header format is described below 👇.
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 and 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. LCT Header Format 🎀
okay so the LCT header is variable size 💅, and the third byte has a length field that tells you how big it is 🧚. Every integer field is carried in "big-endian" aka "network order" 🌐, which just means the most significant byte (octet) goes first ✨. Bits marked "padding" or "reserved" (r) MUST be set to 0 by senders and ignored by receivers in this version of the spec 🔒. Unless noted otherwise, the numbers in this spec are decimal (base 10) 🔢.
Here's the default LCT header layout 🦋:
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 |PSI|S| O |H|Res|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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Default LCT Header FormatNow let's go field by field, bestie 🫶
LCT version number (V): 4 bits 🌸 This tells you which LCT version it is. For this spec, the version number is 1 ✨.
Congestion control flag (C): 2 bits 📊
- C=0 means the Congestion Control Information (CCI) field is 32 bits long.
- C=1 means CCI is 64 bits long.
- C=2 means CCI is 96 bits long.
- C=3 means CCI is 128 bits long.
Protocol-Specific Indication (PSI): 2 bits 🧩 What these bits mean depends on each protocol that uses the LCT building block 🫠. If no protocol-specific use is defined, then a sender MUST set them to zero and a receiver MUST ignore them 🙈.
Transport Session Identifier flag (S): 1 bit 🍓 This is the number of full 32-bit words in the TSI field. The TSI field is 32*S + 16*H bits long, so it's either 0 bits, 16 bits, 32 bits, or 48 bits 💖.
Transport Object Identifier flag (O): 2 bits 🦄 This is the number of full 32-bit words in the TOI field. The TOI field is 32*O + 16*H bits long, so it's 0, 16, 32, 48, 64, 80, 96, or 112 bits 🌈.
Half-word flag (H): 1 bit ✂️ TSI and TOI are both multiples of 32 bits plus 16*H bits. This lets TSI and TOI each be a multiple of a half-word (16 bits), while the total length of TSI and TOI together is still a multiple of 32 bits. Iconic balancing act 👑.
Reserved (Res): 2 bits 🔒 These bits are reserved. In this version, senders MUST set them to zero and receivers MUST ignore them 💅.
Close Session flag (A): 1 bit 🚪 Normally A is 0. A sender MAY set A to 1 when it's about to stop sending packets for the session. 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 sets A to 1 in one packet, it SHOULD keep A set to 1 in all subsequent packets until it stops sending for the session 🔁. When a receiver gets a packet with A set to 1, that means the sender is about to stop sending packets for the session right now 🛑. When a receiver sees A set to 1, it SHOULD assume no more packets are coming for the session 💀.
Close Object flag (B): 1 bit 📦 Normally B is 0. A sender MAY set B to 1 when it's about to stop sending packets for an object. If the TOI field is in use and B is 1, then the object identified by the TOI is about to finish sending 🎯. If the TOI field is not in use and B is 1, then the one object in the session (identified by out-of-band info) is about to finish sending ✨. B MAY be set to 1 in just the last packet for the object, or B MAY be set to 1 in the last few seconds of packets for the object ⏳. Once a sender sets B to 1 in one packet for a particular object, it SHOULD set B to 1 in all subsequent packets for that object until it stops sending them 🔁. A received packet with B set to 1 tells the receiver the sender will immediately stop sending packets for that object 🛑. When a receiver gets a packet with B set to 1, it SHOULD assume 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 32-bit words. The LCT header length MUST be a multiple of 32 bits 💖. This field lets you jump straight to whatever comes after the LCT header: the first other header if there is one, the payload if there's a payload and no other header, or the end of the packet if there's neither 🧭.
Codepoint (CP): 8 bits 🎶 An opaque identifier passed to the payload decoder so it knows which codec the payload uses 🎧. The mapping between the codepoint and the codec is defined per session and shared out-of-band as part of the session description 📝. The CP field works a lot like the Payload Type (PT) field in RTP headers, as described in [RFC3550] 🔗.
Congestion Control Information (CCI): 32, 64, 96, or 128 bits 🚦 This carries congestion control info. For example, it could hold layer numbers, logical channel numbers, and sequence numbers 🔢. For this spec, the field is opaque 🫥.
- 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 🪪 The TSI uniquely identifies a session among all the sessions from one particular sender 🧑💻. The TSI is scoped by the sender's IP address, so the IP address plus the TSI together uniquely identify the session 🌍. Whether the TSI shows up in the LCT header depends on what value is used as the TSI 🤔. If the transport is UDP, the 16-bit UDP source port number MAY serve as the TSI for the session 🔌. If the TSI value appears multiple times in a packet, all occurrences 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 also for a long stretch before and after it's active ⏰. The main job of the TSI is to stop receivers from accidentally accepting packets from a sender that belong to sessions they didn't sign up for 🚫. Picture this: one session gets deactivated, then the sender activates another session that uses some of the same channels 🎭. A receiver that stays connected to the first session during that switch could accept packets from the second session as if they were from the first, if the two TSIs match 😱. How TSI values map to sessions is outside this document's scope and is handled out-of-band 📮.
The TSI field is 32*S + 16*H bits long. The total length 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 📁 This says which object within the session the packet belongs to 🗂️. For example, a sender might send several files in one session, using TOI=0 for the first file, TOI=1 for the second, and so on 📂. The TOI could also be a globally unique ID for an object being sent from several senders at once, where the TOI is a hash of the object 🔐. How TOI values map to objects is outside this document's scope and is handled out-of-band 🫶. The TOI field MUST be used in all packets if more than one object is sent in a session. In other words, the TOI field is either in all the packets of a session or in none of them 🙌.
The TOI field is 32*O + 16*H bits long. The total length of the TSI field plus the TOI field is a multiple of 32 bits ✨.
5.2. Header-Extension Fields 🧚♀️
5.2.1. General ✨
okay so header extensions are the optional bits of the LCT header 🎀 the ones that aren't always there or come in different sizes. some examples:
- extended-size versions of header fields that already exist 💅
- sender and receiver authentication info 🔐
- timing info ⏰
you can tell if extensions are even there by checking the LCT header length (HDR_LEN) 🔍 if HDR_LEN is bigger than the standard header, whatever space is left over gets filled up with Header Extension fields 🧚
now the big rule 👑 if extensions are present, they MUST be processed so they get recognized before you do any congestion control stuff or accept the packet. the default for unrecognized extensions is to ignore them 🙈 which is what lets LCT get backward-compatible upgrades without bumping the LCT version number ✨ but non-backward-compatible extensions cannot be added without changing the version number 💀 not me trying to sneak a breaking change in lol
there are two formats for these fields, shown in Figure 2 🦋 the first one is for variable-length extensions, using HET values between 0 and 127. the second one 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 Headersheads up bestie 🚨 the intro says fixed-length HETs run from 127 to 255, but the field definitions below say 128 to 255 (and the figure says >=128). the text is kept exactly as the original wrote it, so just be aware of the mismatch.
here's how the sub-fields work 🌸
- Header Extension Type (HET): 8 bits. this is the type of the Header Extension. this document 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 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, counted in 32-bit words. HEL MUST be present for variable-length extensions (HETs between 0 and 127) and MUST NOT be present for fixed-length extensions (HETs between 128 and 255) 🙅♀️
- Header Extension Content (HEC): variable length. this is the actual content, and its format depends on the HET. fixed-length extensions have a 24-bit HEC. variable-length ones have an HEC size set by HEL. the length of each Header Extension field MUST be a multiple of 32 bits 📏 and the total size of the LCT header, with all Header Extensions and optional header fields included, cannot go over 255 32-bit words 💜
this spec defines the following LCT Header Extensions 🎀
EXT_NOP, HET=0 No-Operation extension. The information present in
this extension field MUST be ignored by receivers.
EXT_AUTH, HET=1 Packet authentication extension. Information used to
authenticate the sender of the packet. The format of
this Header Extension and its processing is outside
the scope of this document and is to be 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 that can be performed
immediately upon reception of the packet SHOULD be
performed before accepting the packet and performing
any congestion-control-related action on it.
Some packet authentication schemes impose a delay of several seconds
between when a packet is received and when the packet
is fully authenticated. Any congestion control
related action that is appropriate SHOULD NOT be
postponed by any such full packet authentication.
EXT_TIME, HET=2 Time Extension. This extension is used to carry
several types of timing information. It includes
general purpose timing information, namely the Sender
Current Time (SCT), Expected Residual Time (ERT), and
Sender Last Change (SLC) time extensions described in
the present document. It can also be used for timing
information with narrower applicability (e.g.,
defined for a single protocol instantiation); in this
case, it will be described in a separate document.so EXT_NOP is the "do nothing" one 😴 its info MUST be ignored by receivers. EXT_AUTH is for proving who sent the packet 🔐 how it works and gets processed is outside this document, and it's communicated out-of-band as part of the session description. senders are RECOMMENDED to provide some form of packet authentication 🫶 and if EXT_AUTH is there, whatever checks can be done right when the packet arrives SHOULD happen before accepting it and before any congestion-control-related action. some auth schemes take several seconds to fully authenticate a packet, so any appropriate congestion control action SHOULD NOT be postponed by that full authentication. it's giving "don't make the packet wait for the slow stuff" 🏃♀️💨
EXT_TIME is the timing one ⏰ it carries several kinds of timing info: the Sender Current Time (SCT), Expected Residual Time (ERT), and Sender Last Change (SLC) time extensions described in this document. it can also carry narrower timing info, like stuff for a single protocol instantiation, and that would be described in a separate document 🧚
finally, the main requirement 👑 all senders and receivers implementing LCT MUST support EXT_NOP and MUST recognize EXT_AUTH and EXT_TIME, but they are not required to parse their content. iconic, periodt 💖
5.2.2. EXT_TIME Header Extension ✨
Okay bestie, this section is all about the timing Header Extensions that are useful for pretty much any app 🕰️💖. The time values in here are tied to the server's wall clock. The server MUST maintain consistent relative time during a session, so the clock drift has to be insignificant 🫶. Some apps want the server clock synced up system-wide or even globally, like with the Network Time Protocol (NTP) [RFC1305] so everything lines up with 00:00 hours GMT, January 1st 1900 🌸. But that session-external syncing is outside the scope of this doc, so we're not going there today 💅.
The EXT_TIME Header Extension uses the format shown in Figure 3 🦋.
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 = 2 | HEL >= 1 | Use (bit field) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first time value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (other time values (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: EXT_TIME Header Extension Format
The "Use" bit field tells you what the following 32-bit time value(s) mean 🧚. It's split into two parts:
- 8 bits are reserved for general purpose timing information. This information is applicable to any protocol that makes use of LCT.
- 8 bits are reserved for PI-specific timing information. This information is out of the scope of this document.
The format of the "Use" bit field is shown in Figure 4 🌈.
2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|SCT|SCT|ERT|SLC| reserved | PI-specific |
|Hi |Low| | | by LCT | use |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+Figure 4: "Use" Bit Field Format
Several "time value" fields MAY be present in a given EXT_TIME Header Extension, as specified in the "Use-field" 🎀. When several "time value" fields are present, they MUST appear in the order given by the associated flag position in the "Use-field": first SCT-High (if present), then SCT-Low (if present), then ERT (if present), then SLC (if present). Receivers SHOULD ignore additional fields within the EXT_TIME Header Extension that they do not support 🙈.
The fields for the general purpose EXT_TIME timing information are:
Sender Current Time (SCT): SCT-High flag, SCT-Low flag, corresponding time value (one or two 32-bit words).
This timing information represents the current time at the sender at the time this packet was transmitted ⏰.
When the SCT-High flag is set, the associated 32-bit time value provides an unsigned integer representing the time in seconds of the sender's wall clock. In the particular case where NTP is used, these 32 bits provide an unsigned integer representing the time in seconds relative to 00:00 hours GMT, January 1st 1900, (i.e., the most significant 32 bits of a full 64-bit NTP time value). In that case, handling of wraparound of the 32-bit time is outside the scope of NTP and LCT.
When the SCT-Low flag is set, the associated 32-bit time value provides an unsigned integer representing a multiple of 1/2^^32 of a second, so you get sub-second precision 🔥. When the SCT-Low flag is set, the SCT-High flag MUST be set, too. In the particular case where NTP is used, these 32 bits provide the 32 least significant bits of a 64-bit NTP timestamp.
Expected Residual Time (ERT): ERT flag, corresponding 32-bit time value.
This timing information represents the sender expected residual transmission time for the transmission of the current object 🦋. If the packet containing the ERT timing information also contains the TOI field, then ERT refers to the object corresponding to the TOI field. Otherwise, it refers to the only object in the session.
When the ERT flag is set, it is expressed as a number of seconds. The 32 bits provide an unsigned integer representing this number of seconds ⭐.
Session Last Changed (SLC): SLC flag, corresponding 32-bit time value.
The Session Last Changed time value is the server wall clock time, in seconds, at which the last change to session data occurred 👑. That is, it marks when the most recent Transport Object addition, modification, or removal was made for the delivery session. For modifications and additions, it means new data will be transported that was not transported before this time. For removals, SLC means some prior data will no longer be transported 💀.
When the SLC flag is set, the associated 32-bit time value provides an unsigned integer representing a time in seconds. In the particular case where NTP is used, these 32 bits provide an unsigned integer representing the time in seconds relative to 00:00 hours GMT, January 1st 1900, (i.e., the most significant 32 bits of a full 64-bit NTP time value). In that case, handling of wraparound of the 32-bit time is outside the scope of NTP and LCT.
In some cases, it may be appropriate for a packet containing an EXT_TIME Header Extension with SLC information to also contain SCT-High information 💜.
Reserved by LCT for future use (4 bits):
In this version of the specification, these bits MUST be set to zero by senders and MUST be ignored by receivers 🔒.
PI-specific use (8 bits):
These bits are out of the scope of this document. The bits that are not specified by the PI built on top of LCT SHOULD be set to zero 🌸.
The total EXT_TIME length is carried in the HEL, since this Header Extension is of variable length. That also lets clients skip this Header Extension altogether if it's not supported (but recognized) 🫶.
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 one is being used).
The session description could also include, but is not 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 is 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 must be included in the session description 🧚. For example, a protocol instantiation might require that 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 be required be included in the session description.
The session description could be in a form such as SDP as defined in [RFC4566], or another format that suits a particular application. It might be carried in a session announcement protocol such as SAP as defined in [RFC2974], obtained using a proprietary session control protocol, located on a Web page with scheduling information, or conveyed via email or other out-of-band methods 💌. Discussion of session description format, and distribution of session descriptions, 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, which together constitute a session. Transmission rates may be different in different channels and may 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, nor the organization of a session into multiple channels. Although these issues affect the efficiency of the protocol, they do not affect the correctness nor the inter-operability of LCT between senders and receivers 🦋.
Several objects can be carried within the same LCT session. In this case, each object MUST be identified by a unique TOI. Objects MAY be transmitted sequentially, or they MAY be transmitted concurrently 🌈. It is good practice to only send objects concurrently in the same session if the receivers that participate in that portion of the session have interest in receiving all the objects. The reason is that it wastes bandwidth and networking resources to have receivers receive data for objects they have no interest in 💅.
Typically, the sender(s) continues to send 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 mentioned above, this document does not pose any restriction on packet sizes. However, network efficiency considerations recommend that the sender uses as large a packet payload size as possible, but in such a way that packets do not exceed the network's maximum transmission unit size (MTU), or when fragmentation coupled with packet loss might introduce severe inefficiency in the transmission 📦.
It is recommended that all packets have the same or very similar sizes, as this can have a severe impact on the effectiveness of congestion control schemes such as the ones described in [VIC1998], [BYE2000], and [RFC3738] 🎀. A sender of packets using LCT MUST implement the sender-side part of one of the congestion control schemes that is in accordance with [RFC2357], 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, 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. no session description, no session, bestie 🙅♀️
If packet authentication information is present in an LCT header, it SHOULD be used as specified in Section 5.2. To be able to be a receiver in a session, the receiver 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. If a receiver is not able to 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 provided in the LCT header. If a receiver is not able to implement the congestion control protocol used in the session, it MUST NOT join the session 🚫. When the session is transmitted on 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 that a receiver will initially join only a minimal set of LCT channels, possibly a single one, that in aggregate are carrying packets at a low rate. This rule exists to stop receivers from starting at high data rates 🐢 it's giving patience 🌸
Several objects can be carried either sequentially or concurrently within the same LCT session. In this case, each object is identified by a unique TOI. Note that even if a server stops sending packets for an old object before starting to transmit packets for a new object, both the network and the underlying protocol layers can cause some reordering of packets, especially when sent over different LCT channels. So receivers SHOULD NOT assume that the reception of a packet for a new object means that there are no more packets in transit for the previous one, at least for some amount of time 👀 packets arrive whenever they want, lol
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 allows the receiver some flexibility in terms of its actions within a session, then the receiver MAY make choices to optimize the packet flow performance across the multiple LCT sessions, as long as the receiver still adheres to the congestion control rules for each LCT session individually 🧠✨
7. Requirements from Other Building Blocks 🧩
As described in [RFC3048], LCT is a building block that is intended to be used, in conjunction 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. 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. The Congestion Control Information field in the LCT header is an opaque field that is 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 a very limited number of layers, thus providing a very coarse control in the reception rate of packets by receivers in a session. 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 larger than this size the reception overhead on the receivers can grow substantially 😬
A more in-depth description of the use of FEC in Reliable Multicast Transport (RMT) protocols is given in [RFC3453]. Some of the FEC codecs that MAY be used in conjunction with LCT for reliable content delivery are specified in [RFC5052]. 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 [RFC4566], or another format appropriate to a particular application. It may be distributed with SAP as defined in [RFC2974], using HTTP, or in other ways 🦋 It is RECOMMENDED that an authentication protocol be used to deliver the session description to receivers, to ensure the correct session description 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 [Perrig2001] 🛡️
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 serious bestie, read it slowly 😭
LCT is a building block as defined in [RFC3048] and as such does not define a complete protocol. Protocol instantiations that use the LCT building block MUST address the potential vulnerabilities described in the following sections. For an example, see [ALC-PI] 📚
Protocol instantiations could address the vulnerabilities described below by taking measures to prevent receivers from accepting incorrect packets, for example, by using a source authentication and content integrity mechanism. See also Sections 6.2 and 7 for discussion of packet authentication requirements 🔍
Note that for correct operation, LCT assumes availability of session description information (see Sections 4 and 7). Incorrect or maliciously modified session description information may result in receivers being unable to correctly receive the session content, or in receivers inadvertently trying to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. Protocol instantiations MUST address this potential vulnerability, for example, by providing source authentication and integrity mechanisms for the session description. Additionally, these mechanisms MUST allow the receivers to securely verify the correspondence between session description and LCT data packets 🚧
The following sections consider further each of the services provided by LCT 🧐
8.1. Session and Object Multiplexing and Termination 🌀
The Transport Session Identifier and the Transport Object Identifier in the LCT header provide for multiplexing of sessions and objects. Modification of these fields by an attacker could have the effect of depriving a session or object of data and potentially directing incorrect data to another session or object, in both cases effecting a denial-of-service attack 😱
Additionally, injection of forged packets with fake TSI or TOI values may cause receivers to allocate resources for additional sessions or objects, again potentially effecting a DoS attack 🥀
The Close Object and Close Session bits in the LCT header provide for signaling of the end of a session or object. Modification of these fields by an attacker could cause receivers to incorrectly behave as if the session or object had ended, resulting in a denial-of-service attack, or conversely to continue to unnecessarily utilize resources after the session or object has ended (although resource utilization in this case is largely an implementation issue) 🫠
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms) protect the fields!! 🌈
8.2. Time Synchronization ⏰
The SCT and ERT mechanisms provide rudimentary time synchronization features, which can both be subject to attacks. Indeed, an attacker can easily de-synchronize clients by sending erroneous SCT information, or mount a DoS attack by informing all clients that the session (respectively, a particular object) is about to be closed 🙈
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms) 🔒
8.3. Data Transport 📦
The LCT protocol provides for transport of information for other building blocks: specifically the PSI field for the protocol instantiation, the Congestion Control field for the Congestion Control building block, the Codepoint field for the FEC building block, the EXT-AUTH Header Extension (used by the protocol instantiation), and the packet payload itself.
Modification of any of these fields by an attacker may result in a denial-of-service attack. In particular, modification of the Codepoint or packet payload may prevent successful reconstruction or cause inaccurate reconstruction of large portions of an object by receivers. Modification of the Congestion Control field may cause receivers to attempt to receive at an incorrect rate, potentially worsening or causing a congestion situation and thereby effecting a DoS attack 💀
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms) 🫶
9. IANA Considerations 📝
9.1. Namespace Declaration for LCT Header Extension Types 🗂️
This document defines a new namespace for "LCT Header Extension Types". Values in this namespace are integers between 0 and 255 (inclusive) 🔢
Values in the range 0 to 63 (inclusive) are reserved for use for variable-length LCT Header Extensions, and assignments shall be made through "IETF Review" as defined in [RFC5226] 📋
Values in the range 64 to 127 (inclusive) are reserved for variable-length LCT Header Extensions, and assignments shall be made on the "Specification Required" basis as defined in [RFC5226] ✍️
Values in the range 128 to 191 (inclusive) are reserved for use for fixed-length LCT Header Extensions, and assignments shall be made through "IETF Review" as defined in [RFC5226] 🧾
Values in the range 192 to 255 (inclusive) are reserved for fixed-length LCT Header Extensions, and assignments shall be made on the "Specification Required" basis as defined in [RFC5226] 🦋
Initial values for the LCT Header Extension Type registry are defined in Section 9.2 🌸
Note that the previous Experimental version of this specification reserved values in the ranges [64, 127] and [192, 255] for PI-specific LCT Header Extensions. In the interest of simplification, and since there were no overlapping allocations of these LCT Header Extension Type values by PIs, this document specifies a single flat space for LCT Header Extension Types 💜✨
9.2. LCT Header Extension Type Registration 🎀
okay so this bit is basically the IANA paperwork for the header extension types. this document registers three values in the LCT Header Extension Type namespace, and they're all coming from this spec 💅
+-------+----------+--------------------+
| Value | Name | Reference |
+-------+----------+--------------------+
| 0 | EXT_NOP | This specification |
| | | |
| 1 | EXT_AUTH | This specification |
| | | |
| 2 | EXT_TIME | This specification |
+-------+----------+--------------------+so 0 is EXT_NOP, 1 is EXT_AUTH, and 2 is EXT_TIME ✨
10. Acknowledgments 🫶
this spec is pretty much built on RFC 3451 [RFC3451], so the main credit goes to its authors: Mike Luby, Jim Gemmel, Lorenzo Vicisano, Luigi Rizzo, Mark Handley, and Jon Crowcroft 👑 Bruce Lueckenhoff, Hayder Radha, and Justin Chapweske also helped out with RFC 3451. and extra thanks to Vincent Roca, Rod Walsh, and Toni Paila for their work on this update to Proposed Standard 🌸
11. Changes from RFC 3451 🦋
this section is the glow-up recap from the Experimental version, RFC 3451 [RFC3451]. here's what changed:
- removed the 'Statement of Intent' from the introduction. (that statement was there to explain the "Experimental" status of RFC 3451, so it's gone now 🙈)
- added material from ALC that applies in the more general LCT context 🧚
- created an IANA registry for LCT Header Extensions 📚
- allocated the 2 'reserved' bits in the LCT header as "Protocol-Specific Indication", with usage to be defined by protocol instantiations 💜
- removed the Sender Current Time and Expected Residual Time LCT header fields 💀
- added a new Header Extension, EXT_TIME, to replace the SCT and ERT and to make room for future timing capabilities ⭐
12. References 🌈
12.1. Normative References
[RFC0768]Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.[RFC1112]Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC5052]Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
12.2. Informative References
[ALC-PI]Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, September 2009.[BYE1998]Byers, J., Luby, M., Mitzenmacher, M., and A. Rege, "Fountain Approach to Reliable Distribution of Bulk Data", Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.[BYE2000]Byers, J., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Rotter, 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.[GEM2000]Gemmell, J., Schooler, E., and J. Gray, "Fcast Multicast File Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.[Perrig2001]Perrig, A., Canetti, R., Song, D., and J. Tyger, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.[RFC1305]Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.[RFC2357]Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.[RFC2974]Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.[RFC3048]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.[RFC3269]Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.[RFC3451]Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.[RFC3453]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.[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.[RFC3738]Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.[RFC4566]Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.[RFC4607]Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.[RIZ1997a]Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, April 1997.[RIZ1997b]Rizzo, L. and L. Vicisano, "Reliable Multicast Data Distribution protocol based on software FEC techniques", Proceedings of the Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems, HPCS'97, Chalkidiki Greece, June 1997.[RIZ2000]Rizzo, L., "PGMCC: A TCP-friendly single-rate multicast congestion control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.[VIC1998]Vicisano, L., Rizzo, L., and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", IEEE Infocom'98, San Francisco, CA, March 1998.
Authors' Addresses 💖
Michael Luby
Qualcomm, Inc.
3165 Kifer Rd.
Santa Clara, CA 95051
US
EMail: luby@qualcomm.com
Mark Watson
Qualcomm, Inc.
3165 Kifer Rd.
Santa Clara, CA 95051
US
EMail: watson@qualcomm.com
Lorenzo Vicisano
Qualcomm, Inc.
3165 Kifer Rd.
Santa Clara, CA 95051
US
EMail: vicisano@qualcomm.com📦 where this page comes from
- ietf: rfc5651 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms