RFC 4259
A Framework for Transmission of IP Datagrams over MPEG-2 Networks
RFC 4259: A Framework for Transmission of IP Datagrams over MPEG-2 Networks 🎀
Okay bestie, here's the title block tea ☕:
- Number: RFC 4259 💖
- Stream: Network Working Group
- Authors: M.-J. Montpetit (Motorola Connected Home Solutions), G. Fairhurst (University of Aberdeen), H. Clausen (TIC Systems), B. Collini-Nocker (University of Salzburg), and H. Linder (University of Salzburg) 👑
- Category: Informational ✨
- Date: November 2005 🦋
- Obsoletes / Updates: The header doesn't have an Obsoletes or Updates line, so it doesn't list anything it replaces or updates. 🙈
Status of This Memo 🌸
This memo gives information to the Internet community. It isn't an Internet standard of any kind, so don't go looking for a spec here 💅. Distribution of this memo is unlimited, so share the love 🫶.
Copyright Notice 📜
Copyright (C) The Internet Society (2005).
Abstract 🧚
Okay so this doc is about how to carry IP datagrams over ISO MPEG-2 Transport Streams (TS) 🦋. MPEG-2 TS is seriously iconic. It's not only used for digital TV, it's also a subnetwork technology for building IP networks 🔥. Digital Video Broadcast (DVB) and the Advanced Television Systems Committee (ATSC) Standards for Digital Television are both examples of systems that use MPEG-2 💜.
The doc points out that we need a set of Internet standards that define the interface between the MPEG-2 Transport Stream and an IP subnetwork 👑. It suggests a brand new encapsulation method for IP datagrams ✨. It also proposes protocols for IPv6/IPv4 address resolution, and for linking IP packets to the properties of the Logical Channels that an MPEG-2 TS provides 💅.
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Salient Features of the Architecture .......................4
2. Conventions Used in This Document ...............................4
3. Architecture ....................................................8
3.1. MPEG-2 Transmission Networks ...............................8
3.2. TS Logical Channels .......................................10
3.3. Multiplexing and Re-Multiplexing ..........................12
3.4. IP Datagram Transmission ..................................13
3.5. Motivation ................................................14
4. Encapsulation Protocol Requirements ............................16
4.1. Payload Unit Delimitation .................................17
4.2. Length Indicator ..........................................18
4.3. Next Level Protocol Type ..................................19
4.4. L2 Subnet Addressing ......................................19
4.5. Integrity Check ...........................................21
4.6. Identification of Scope. ..................................21
4.7. Extension Headers .........................................21
4.8. Summary of Requirements for Encapsulation .................22
5. Address Resolution Functions ...................................22
5.1. Address Resolution for MPEG-2 .............................23
5.2. Scenarios for MPEG AR .....................................25
5.2.1. Table-Based AR over MPEG-2 .........................25
5.2.2. Table-Based AR over IP .............................26
5.2.3. Query/Response AR over IP ..........................26
5.3. Unicast Address Scoping ...................................26
5.4. AR Authentication .........................................27
5.5. Requirements for Unicast AR over MPEG-2 ...................28
6. Multicast Support ..............................................28
6.1. Multicast AR Functions ....................................29
6.2. Multicast Address Scoping .................................30
6.3. Requirements for Multicast over MPEG-2 ....................31
7. Summary ........................................................31
8. Security Considerations ........................................32
8.1. Link Encryption ...........................................33
9. IANA Considerations ............................................34
10. Acknowledgements ..............................................34
11. References ....................................................34
11.1. Normative References .....................................34
11.2. Informative References ...................................34
Appendix A ........................................................391. Introduction 💖
This doc lays out the requirements and an architecture for moving IP Datagrams over ISO MPEG-2 Transport Streams [ISO-MPEG] 🎀. The main goal is delivering IP services over subnetworks that use the MPEG-2 Transport Stream (TS), and doing it efficiently and flexibly ✨.
The architecture is built to be compatible with MPEG-2 based services, like the Digital Video Broadcast (DVB) architecture, the Advanced Television Systems Committee (ATSC) system [ATSC, ATSC-G], and other similar MPEG-2 based transmission systems 🦋. These systems usually give you unidirectional (simplex) physical and link layer standards, and they've been defined for a whole bunch of physical media 🌈. That includes Terrestrial TV [ETSI-DVBT, ATSC-PSIP-TC], Satellite TV [ETSI-DVBS, ETSI-DVBS2, ATSC-S], Cable Transmission [ETSI-DVBC, ATSC-PSIP-TC, OPEN-CABLE], and data transmission over MPEG-2 [ETSI-MHP] 💅.
Here's the stack, bestie 👀:
+-+-+-+-+------+------------+---+--+--+---------+
|T|V|A|O| O | | O |S |O | |
|e|i|u|t| t | | t |I |t | |
|l|d|d|h| h | IP | h | |h | Other |
|e|e|i|e| e | | e |T |e |protocols|
|t|o|o|r| r | | r |a |r | native |
|e| | | | | | |b | | over |
|x| | | | | +---+----+-+ |l | |MPEG-2 TS|
|t| | | | | | | MPE | |e | | |
| | | | | +--+---+ +------+ | | | |
| | | | | | AAL5 |ULE|Priv. | | | | |
+-+-+-+-+---+------+ | +-+--+--+ |
| PES | ATM | |Sect. |Section| |
+-------+----------+---+------+-------+---------+
| MPEG-2 TS |
+---------+-------+----------------+------------+
|Satellite| Cable | Terrestrial TV | Other PHY |
+---------+-------+----------------+------------+Figure 1: Overview of the MPEG-2 protocol stack
Lowkey, a lot of MPEG-2 systems carry a mix of data types 🍓. But MPEG-2 parts can also be, and are, used to build IP-only networks 💜. Using standard system components gives you better interoperability and wider deployment 🫶. Some MPEG-2 networks don't implement every part of a DVB / ATSC system, though. They might, for instance, support minimal signalling of Service Information (SI) tables, or none at all 🙈.
1.1. Salient Features of the Architecture 🌟
The architecture in this doc describes a set of protocols that support transmitting IP packets over the MPEG-2 TS 👑. The key things about these networks are that they may provide link-level broadcast capability, and that a lot of the apps they support need access to a very large number of subnetwork nodes 🔥.
Some, or all, of these protocols might also work for other subnetworks, like other MPEG-2 transmission networks, regenerative satellite links [ETSI-BSM], and some kinds of broadcast wireless links 🛰️. The big goals of the architecture are to reduce complexity when you're using the system, improve performance, increase flexibility for IP services, and create chances for better integration with IP services 💖.
Since most MPEG-2 transmission networks are bandwidth-limited, encapsulation protocols need to add minimal overhead so the link stays efficient and still gives you solid network services 🦋. They also need to be simple so processing stays light, robust against errors and security threats, and extensible to a wide range of services 💅.
In MPEG-2 systems, TS Logical Channels are identified by their PID, and they handle multiplexing, addressing, and error reporting ✨. A TS Logical Channel may also be used to provide Quality of Service (QoS) 🎀. Mapping functions are required to relate TS Logical Channels to IP addresses, to map TS Logical Channels to IP-level QoS, and to associate IP flows with specific subnetwork capabilities 🧚. The cool part is that these functions can be provided in a dynamic way, which allows transparent integration with other IP-layer protocols 🌈. Together, these will form an MPEG-2 TS Address Resolution (AR) protocol suite [IPDVB-AR] 💜.
2. Conventions Used in This Document ✨
Okay bestie, this is the glossary section, and it's where all the acronyms get explained so we're all on the same page 🎀
Adaptation Field 🦋: An optional variable-length extension field of the fixed-length TS Packet header. It's meant to carry clock references, timing and synchronization information, and stuffing over an MPEG-2 Multiplex [ISO-MPEG]. Main character energy, honestly.
ATSC 📺: Advanced Television Systems Committee [ATSC]. It's a framework plus a set of standards for sending video, audio, and data using the ISO MPEG-2 standard [ISO-MPEG].
DSM-CC 💜: Digital Storage Media Command and Control [ISO-DSMCC]. It's a format for sending data and control information. It's defined by the ISO MPEG-2 standard and carried in an MPEG-2 Private Section.
DVB 🌸: Digital Video Broadcast [ETSI-DVBC, ETSI-DVBRCS, ETSI-DVBS]. It's a framework and set of standards published by the European Telecommunications Standards Institute (ETSI) for video, audio, and data transmission, using the ISO MPEG-2 Standard [ISO-MPEG]. Iconic.
Encapsulator 🎁: A network device that receives PDUs and formats them into Payload Units (called SNDUs here) so they can go out as a stream of TS Packets.
Forward Direction ➡️: The dominant direction of data transfer over a network path. Data moving this way is called "forward transfer". Packets travelling forward follow the forward path through the IP network.
MAC 🔐: Medium Access and Control. This is the link layer header of the Ethernet IEEE 802 standard of protocols. It's made up of a 6B destination address, a 6B source address, and a 2B type field (see also NPA).
MPE 🧚: Multiprotocol Encapsulation [ETSI-DAT, ATSC-DAT, ATSC-DATG]. It's a scheme that encapsulates PDUs and forms a DSM-CC Table Section. Each Section is sent in a series of TS Packets using a single TS Logical Channel.
MPEG-2 🎬: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organisation (ISO) [ISO-MPEG].
NPA 📍: Network Point of Attachment. These addresses are mainly used to identify a station (Receiver) within a local network, for example an IEEE MAC address. An address may identify individual Receivers or groups of Receivers.
PAT 🗂️: Program Association Table [ISO-MPEG]. It's an MPEG-2 PSI control table that links program numbers to the PID value used to send the corresponding PMT. The PAT is sent using the well-known PID value of zero.
PDU 💌: Protocol Data Unit. Examples include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PES 🎵: Packetized Elementary Stream [ISO-MPEG]. It's a format of MPEG-2 TS packet payload, usually used for video or audio information.
PID 🔢: Packet Identifier [ISO-MPEG]. This is a 13 bit field in the header of TS Packets, used to identify which TS Logical Channel a TS Packet belongs to [ISO-MPEG]. The TS Packets that form the parts of a Table Section, PES, or other Payload Unit must all carry the same PID value. The all 1s PID value marks a Null TS Packet, which is introduced to keep a constant bit rate for a TS Multiplex. There's no required relationship between the PID values used for TS Logical Channels sent over different TS Multiplexes.
PMT 🗺️: Program Map Table. This is an MPEG-2 PSI control table that links the PID values used by the set of TS Logical Channels/Streams that make up a program [ISO-MPEG]. The PID value used to send the PMT for a specific program is defined by an entry in the PAT.
PP 📌: Payload Pointer [ISO-MPEG]. This is an optional one byte pointer that sits right after the TS Packet header. It holds the number of bytes between the end of the TS Packet header and the start of a Payload Unit. Whether the Payload Pointer is there depends on the value of the PUSI bit in the TS Packet header. It's present in DSM-CC and Table Sections, but not in TS Logical Channels that use the PES-format.
Private Section 🔒: A syntactic structure built according to Table 2-30 of [ISO-MPEG]. It can be used to identify private information (so, not defined by [ISO-MPEG]) about one or more elementary streams, a specific MPEG-2 program, or the entire TS. Other standards bodies (for example ETSI and ATSC) have defined sets of table structures using the private_section structure. A Private Section is sent as a sequence of TS Packets over a TS Logical Channel, and a TS Logical Channel may carry sections from more than one set of tables.
PSI 📚: Program Specific Information [ISO-MPEG]. PSI is used to convey information about the services carried in a TS Multiplex. It's carried in one of four specifically identified table section constructs [ISO-MPEG]; see also SI Table.
PU 📦: Payload Unit. A sequence of bytes sent using a TS. Examples include an MPEG-2 Table Section or a ULE SNDU.
PUSI 🚩: Payload_Unit_Start_Indicator [ISO-MPEG]. This is a single bit flag in the TS Packet header. A PUSI value of zero means the TS Packet does not carry the start of a new Payload Unit. A PUSI value of one means it does. In ULE, a PUSI bit set to 1 also signals that a one byte Payload Pointer (PP) is present.
Receiver 📡: A piece of equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or to the bridging module when operating at the link layer).
SI Table 🗒️: Service Information Table [ISO-MPEG]. In this document, this term describes a table that conveys information about the services carried in a TS Multiplex, and that has been defined by another standards body. A Table may consist of one or more Table Sections, but all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG].
SNDU 💫: Sub-Network Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
STB 📺: Set-Top Box. A consumer equipment (Receiver) for receiving digital TV services.
Table Section 🧩: A Payload Unit carrying all or part of an SI or PSI Table [ISO-MPEG].
TS 🚀: Transport Stream [ISO-MPEG]. It's a method of transmission at the MPEG-2 level, using TS Packets, and it represents level 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex.
TS Header 🏷️: The 4-byte header of a TS Packet [ISO-MPEG].
TS Logical Channel 🛤️: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value, and that value is unique within a specific TS Multiplex. According to MPEG-2, some TS Logical Channels are reserved for specific signalling. Other standards (for example ATSC and DVB) also reserve specific TS Logical Channels.
TS Multiplex 🧃: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower layer connection. This may be a common physical link (meaning a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (for example Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex, possibly with a different PID value. For example, this could redistribute the same multicast content to two terrestrial TV transmission cells.
TS Packet 🎀: A fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG]. Each TS Packet carries a 4B header, plus optional overhead including an Adaptation Field, encryption details, and time stamp information to synchronize a set of related TS Logical Channels. It's also referred to as a TS_cell. Each TS Packet carries a PID value that associates it with a single TS Logical Channel.
ULE 🌈: Unidirectional Lightweight Encapsulation (ULE) [IPDVB-ULE]. It's a scheme that encapsulates PDUs into SNDUs, which are sent in a series of TS Packets using a single TS Logical Channel.
3. Architecture ✨
Alright, let's get into the big picture 💖 The following sections introduce the components of the MPEG-2 Transmission Network and relate them to a networking framework. Buckle up, it's about to get so satisfying 🫶
3.1. MPEG-2 Transmission Networks
okay so MPEG-2 Transmission Networks can be set up in a LOT of different ways 🌈 we're gonna walk through a few example scenarios real quick, and then the rest of this section connects the functions to each one 💅
A) Broadcast TV and Radio Delivery
this one is the classic 📺 the main service is Digital TV and/or Radio plus their associated data [MMUSIC-IMG, ETSI-IPDC]. these networks usually have two parts: the contribution feed and the broadcast part 🎀 the contribution feeds carry stuff from a usually small number of individual sites (typically at high quality) back to the Hub of a broadcast network. the traffic on those feeds is typically encrypted, and it's usually processed before it gets resent on the Broadcast part of the network. the Broadcast part is a star topology centered on the Hub, reaching a typically large number of down-stream Receivers 🌸 these networks might do IP transmission, but they don't necessarily give you access to the public Internet 🙈
B) Broadcast Networks used as an ISP
this is giving "similar vibes to A, but with a twist" ✨ it also includes IP services that give you access to the public Internet. the IP traffic here is typically not related to the digital TV/Radio content, and the service might be run by an independent operator, doing things like unidirectional file delivery or bidirectional ISP access 🦋 the IP service has to follow the full system specification used for the broadcast transmission, including allocation of PIDs and generation of appropriate MPEG-2 control information (e.g., DVB and ATSC SI tables). no skipping the paperwork, bestie 📋
C) Unidirectional Star IP Scenario
the Unidirectional Star IP Scenario uses a Hub station to run a data network that delivers a common bit stream to typically medium-sized groups of Receivers 🧚 MPEG-2 transmission tech handles the forward direction physical and link layers here, and the return link (if one is needed) is handled some other way. IP services usually make up the main chunk of the transmission traffic 💜 these networks don't necessarily implement the MPEG-2 control plane, aka the PSI/SI tables, and that's totally fine 🫶
D) Datacast Overlay
the Datacast Overlay scenario uses MPEG-2 physical and link layers to add extra connectivity, like unidirectional multicast, on top of an existing IP-based Internet service ⭐ an example is IP Datacast to mobile wireless receivers [MMUSIC-IMG] 📱
E) Point-to-Point Links
point-to-point connectivity can be set up with a pair of transmit and receive interfaces that support the MPEG-2 physical and link layers 💖 usually a transmission from a sender only reaches one Receiver, or a small number of them. one example is using transmit/receive DVB-S terminals to make satellite links between ISPs that use BGP routing 🛰️
F) Two-Way IP Networks
two-way IP networks are typically satellite-based and star-based, using a Hub station to deliver a common bit stream to medium-sized groups of receivers 🔥 a bidirectional service runs over a common air-interface. the forward direction at the physical and link layers is MPEG-2, which can also be used in the return direction. these systems also usually include a control plane element to manage the (shared) return link capacity 👑 a concrete example is the DVB-RCS system [ETSI-DVBRCS]. IP services usually make up the main chunk of the traffic here too 🍓
so basically, Scenarios A-D use unidirectional MPEG-2 Transmission Networks 🌈 for the satellite ones, these usually look like a star topology, with a central Hub serving large numbers of down-stream Receivers. terrestrial networks can use several transmission Hubs, each serving its own coverage cell with a community of Receivers 🗼
from an IP point of view, the service is usually either unidirectional multicast, or a bidirectional service where some complementary link technology (like a modem, Local Multipoint Distribution Service (LMDS), or General Packet Radio Service (GPRS)) provides the return path from Receivers to the Internet 🔁 in that case, routing could be handled with UniDirectional Link Routing (UDLR) [RFC3077] 🧭
note that only Scenarios A-B actually carry MPEG-2 video and audio as the primary traffic 📺 that content is meant for digital Set Top Boxes (STBs). the other scenarios are IP-based data networks, and they don't need to implement the MPEG-2 control plane 💀
Scenarios E-F give you two-way connectivity over the MPEG-2 Transmission Network 💫 these networks directly support bidirectional protocols both above and below the IP layer 🎀
the whole MPEG-2 transmission network might be managed by a transmission service operator 👑 when that happens, the assignment of addresses and TS Logical Channels at Receivers is usually under the service operator's control. examples are a TV operator (Scenario A) or an ISP (Scenarios B-F) 🌸 MPEG-2 transmission networks are also used for private networks. these usually have a smaller number of Receivers and don't need the same level of centralized control 🦋 one example is companies that want to connect DVB-capable routers to form links within the Internet (Scenario B) 🫶
3.2. TS Logical Channels
an MPEG-2 Transport Multiplex offers a bunch of parallel channels, which we're calling TS Logical Channels 🧚 each TS Logical Channel is uniquely identified by the Packet ID (PID) value carried in the header of each MPEG-2 TS Packet. the PID value is a 13 bit field, so the number of available channels runs from 0 to 8191 decimal, or 0x1FFF in hexadecimal. some of those are reserved for transmitting SI tables 💅 non-reserved TS Logical Channels can carry audio [ISO-AUD], video [ISO-VID], IP packets [ISO-DSMCC, ETSI-DAT, ATSC-DAT], or other data [ISO-DSMCC, ETSI-DAT, ATSC-DAT] ✨ the value 8191 decimal (0x1FFF) marks a null packet, which keeps the physical bearer bit rate going when there are no other MPEG-2 TS packets to send 🌈
here's the diagram, it's so pretty 😭
TS-LC-A-1 /---\--------------------/---\
\ / \ / \
\ | | | |
TS-LC-A-2 ----------- | | -------------
-------------------- | | -------------
| | | |
/-------- / | -------------
/ \----/-------------------\----/
TS-LC-A-3/ MPEG-2 TS MUX A
/
TS-LC /
------------X
\ TS-LC-B-3 /---\------------------------/---\
\ / \ / \
\ | | | |
TS-LC-B-2 \----------- | | ---------
-------------------- | | ---------
| | | |
/-------- / | ---------
/ \----/-----------------------\----/
/ MPEG-2 TS MUX B
TS-LC-B-1
Figure 2: Example showing MPEG-2 TS Logical Channels carried
Over 2 MPEG-2 TS Multiplexes.TS Logical Channels are numbered independently on each MPEG-2 TS Multiplex (MUX) 🔢 most of the time, the data sent over the TS Logical Channels will be different for each multiplex. Figure 2 shows a set of TS Logical Channels sent over two MPEG-2 TS Multiplexes (A and B) 🎀
sometimes the same data gets distributed over two or more multiplexes 👀 for example: some SI tables, multicast content that needs to be received by Receivers tuned to either MPEG-2 TS, or unicast data where the Receiver might be in either or both of two potentially overlapping MPEG-2 transmission cells. in Figure 2, each multiplex carries 3 MPEG-2 TS Logical Channels 🦋 those can be different (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or they can be shared by both MPEG-2 TS Multiplexes (so TS-LC-A-3 and TS-LC-B-3 carry identical content) 💜
and yes, there are similarities between how PIDs are used and how virtual channels work in ATM 🧠 but ATM is different, because a PID defines a unidirectional broadcast channel, not a point-to-point link 💅 unlike ATM, there is, as yet, no specified standard interface for MPEG-2 connection setup, for signaling mappings of IP flows to PIDs, or for setting the Quality of Service (QoS) assigned to a TS Logical Channel 😭🫶
3.3. Multiplexing and Re-Multiplexing ✨
okay so in the simple version, one or more TS Logical Channels go into an MPEG-2 multiplexor and it spits out a TS Multiplex 🎀. That TS Multiplex gets forwarded over a physical bearer to one or more Receivers (Figure 3).
the more complex version is where it gets spicy 🌶️ The same TS can be fed into multiple MPEG-2 multiplexors, and those multiplexors can feed other MPEG-2 multiplexors too. That's called remultiplexing 🧚 It can happen in a few places and it's super common in Scenarios A and B of Section 3.1. One example is a satellite that does on-board processing of the TS packets. It takes the TS Logical Channels coming in from one or more uplink physical bearers (TS Multiplex) and multiplexes them out to one down-link physical bearer (TS Multiplex), or to more than one if it's doing broadcast/multicast. During remultiplexing, a remultiplexor may renumber the PID values on one or more TS Logical Channels so that two input TS Logical Channels with the same PID (coming from different input multiplexes) don't clash 🙈 It may also modify and/or insert new SI data into the control plane.
no matter which route it takes, the end result is a "TS Multiplex" that gets transmitted over the physical bearer to the Receiver 💜
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ IP | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexor | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexor | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS Mux
Figure 3: An example configuration for a unidirectional
Service for IP transport over MPEG-23.4. IP Datagram Transmission ✨
packet data that's headed for an MPEG-2 Transport Multiplex gets passed to an Encapsulator, which is sometimes called a Gateway 🎁 It takes in Protocol Data Units, PDUs, like Ethernet frames or IP packets. Each one gets turned into a Sub-Network Data Unit, SNDU, by adding an encapsulation header and trailer (see Section 4). After that, the SNDUs get chopped up into a series of TS Packets ✂️
so to receive IP packets over an MPEG-2 TS Multiplex, a Receiver needs to figure out the specific TS Multiplex (that's the physical link) and also the TS Logical Channel (the PID value, which is the logical link) 🦋 Lots of MPEG-2 TS Logical Channels end up carrying SNDUs, so a Receiver has to filter (accept) IP packets sent on a bunch of different PID values, and it has to reassemble each SNDU independently. literally a lot of work, bestie 💅
a Receiver that's listening to several TS Logical Channels at the same time has to filter out the ones it doesn't want, and it might use something like specific hardware support to do it 🔥 Packets for one IP flow (that's a specific combination of IP source and destination addresses) must be sent using the same PID. It should not be assumed that all IP packets are carried on a single PID, like in some cable modem implementations, because multiple PIDs must be allowed in the architecture 🌈 Plenty of current hardware filters cap the number of active PIDs (for example, 32), though future systems may reasonably be expected to support more ⭐
sometimes a Receiver needs to pick TS Logical Channels from several TS Multiplexes that are active at once. To do that, it needs multiple physical receive interfaces (for example, radio frequency (RF) front-ends and demodulators) 🫶 Some applications also imagine receiving IP Packets at the same time over other media that don't necessarily use MPEG-2 transmission.
bidirectional (duplex) transmission can work over an MPEG-2 Transmission Network by using one of several alternate return channel schemes [ETSI-RC] 🍓 Duplex IP paths may also be supported using non-MPEG-2 return links (for example, in Scenarios B-D of section 3.1). One example of this is UniDirectional Link Routing, UDLR [RFC3077] 👑
3.5. Motivation ✨
these are the network layer protocols this architecture is supposed to support 👀
- (i) IPv4 Unicast packets, destined for a single end host
- (ii) IPv4 Broadcast packets, sent to all end systems in an IP network
- (iii) IPv4 Multicast packets
- (iv) IPv6 Unicast packets, destined for a single end host
- (v) IPv6 Multicast packets
- (vi) Packets with compressed IPv4 / IPv6 packet headers (for example, [RFC2507, RFC3095])
- (vii) Bridged Ethernet frames
- (viii) Other network protocol packets (MPLS, potential new protocols)
the architecture will provide the following 💖
- (i) Guidance on which MPEG-2 features are pre-requisites for the IP service, and identification of any optional fields that impact performance/correct operation.
- (ii) Standards to provide an efficient and flexible encapsulation scheme that may be easily implemented in an Encapsulator or Receiver. The payload encapsulation requires a type field for the SNDU to indicate the type of packet and a mechanism to signal which encapsulation is used on a certain PID.
- (iii) Standards to associate a particular IP address with a Network Point of Attachment (NPA) that could or may not be a MAC Address. This process resembles the IPv4 Address Resolution Protocol, ARP, or IPv6 Neighbor Discovery, ND, protocol [IPDVB-AR]. In addition, the standard will be compatible with IPv6 autoconfiguration.
- (iv) Standards to associate an MPEG-2 TS interface with one or more specific TS Logical Channels (PID, TS Multiplex). Bindings are required for both unicast transmission and multicast reception. In the case of IPv4, this must also support network broadcast. To make the schemes robust to loss and state changes within the MPEG-2 transmission network, a soft-state approach may prove desirable.
- (v) Standards to associate the capabilities of an MPEG-2 TS Logical Channel with IP flows. This includes mapping of QoS functions, such as IP QoS/DSCP and RSVP, to underlying MPEG-2 TS QoS, multi-homing and mobility. This capability could be associated by the AR standard proposed above.
- (vi) Guidance on Security for IP transmission over MPEG-2. The framework must permit use of IPsec and clearly identify any security issues concerning the specified protocols. The security issues need to consider two cases: unidirectional transfer (in which communication is only from the sending IP end host to the receiving IP end host) and bidirectional transfer. Consideration should also be given to security of the TS Multiplex: the need for closed user groups and the use of MPEG-2 TS encryption. 🔐
- (vii) Management of the IP transmission, including standardized SNMP MIBs and error reporting procedures. The need for and scope of this is to be determined.
the specified architecture and techniques should be suited to a range of systems that use the MPEG-2 TS, and they may also suit other (sub)networks that offer similar transfer capabilities 🦋
the next section, 4, covers encapsulation issues, and Sections 5 and 6 cover address resolution issues for unicast and multicast, respectively 🧚
4. Encapsulation Protocol Requirements ✨
okay so this section is the what do we actually need part 💅 It lists requirements and gives examples of mechanisms that could be used to encapsulate IPv4/v6 unicast and multicast packets over MPEG-2 Transmission Networks 🫶
A network device called an Encapsulator receives PDUs (like IP Packets or Ethernet frames) and formats them into Subnetwork Data Units, SNDUs. Then an encapsulation (or convergence) protocol carries each SNDU over the MPEG-2 TS service and provides the right mechanisms to deliver the encapsulated PDU to the Receiver IP interface ✨
When forming an SNDU, the encapsulation protocol typically adds header fields that carry protocol control information, like the length of SNDU, Receiver address, multiplexing information, payload type, sequence numbers, etc. The SNDU payload is usually followed by a trailer, which carries an Integrity Check (e.g., Cyclic Redundancy Check, CRC). Some protocols also add extra control information and/or padding to or after the trailer (figure 4) 🎀
+--------+-------------------------+-----------------+
| Header | PDU | Integrity Check |
+--------+-------------------------+-----------------+
<--------------------- SNDU ------------------------->
Figure 4: Encapsulation of a subnetwork PDU (e.g., IPv4 or IPv6
packet) to form an MPEG-2 Payload Unit.Examples of existing encapsulation/convergence protocols include ATM AAL5 [ITU-AAL5] and MPEG-2 MPE [ETSI-DAT] 🦋
When required, an SNDU may be fragmented across a number of TS Packets (figure 5) 🧚
+-----------------------------------------+
|Encap Header|SubNetwork Data Unit (SNDU) |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
Figure 5: Encapsulation of a PDU (e.g., IP packet) into a
Series of MPEG-2 TS Packets. Each TS Packet carries
a header with a common Packet ID (PID) value denoting
the MPEG-2 TS Logical Channel.The DVB family of standards currently defines a mechanism for transporting an IP packet, or Ethernet frame, using Multi-Protocol Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme is also supported in ATSC [ATSC-DAT, ATSC-DATG]. It allows transmission of IP packets or (by using LLC) Ethernet frames by encapsulation within a Table Section (with the format used by the control plane associated with the MPEG-2 transmission). The MPE specification includes a set of optional header components and requires decoding of the control headers. This processing is suboptimal for Internet traffic, since it incurs significant receiver processing overhead and some extra link overhead [CLC99] 😭
The existing standards carry heritage from legacy implementations. These reflected the limitations of technology at the time of their deployment (e.g., design decisions driven by audio/video considerations rather than IP networking requirements). IPv6, MPLS, and other network-layer protocols are not natively supported. Together, these justify the development of a new encapsulation that will be truly IP-centric. Carrying IP packets over a TS Logical Channel involves several convergence protocol functions. This section briefly describes these functions and highlights the requirements for a new encapsulation 👑
4.1. Payload Unit Delimitation
MPEG-2 indicates the start of a Payload Unit (PU) in a new TS Packet with a "payload_unit_start_indicator" (PUSI) [ISO-MPEG] carried in the 4B TS Packet header. The PUSI is a 1 bit flag that has normative meaning [ISO-MPEG] for TS Packets that carry PES Packets or PSI/SI data 🌸
When the payload of a TS Packet contains PES data, a PUSI value of '1' indicates the TS Packet payload starts with the first byte of a PES Packet. A value of '0' indicates that no PES Packet starts in the TS Packet. If the PUSI is set to '1', then one, and only one, PES Packet starts in the TS Packet.
When the payload of the TS Packet contains PSI data, a PUSI value of '1' indicates the first byte of the TS Packet payload carries a Payload Pointer (PP) that indicates the position of the first byte of the Payload Unit (Table Section) being carried. If the TS Packet does not carry the first byte of a Table Section, the PUSI is set to '0', indicating that no Payload Pointer is present.
Using this PUSI bit, the start of the first Payload Unit in a TS Packet is exactly known by the Receiver, unless that TS Packet has been corrupted or lost in the transmission. In which case, the payload is discarded until the next TS Packet is received with a PUSI value of '1' 🙈
The encapsulation should allow packing of more than one SNDU into the same TS Packet and should not limit the number of SNDUs that can be sent in a TS Packet. In addition, it should allow an IP Encapsulator to insert padding when there is an incomplete TS Packet payload. A mechanism needs to be identified to differentiate this padding from the case where another encapsulated SNDU follows 🍓
A combination of the PUSI and a Length Indicator (see below) allows an efficient MPEG-2 convergence protocol to receive accurate delineation of packed SNDUs. The MPEG-2 standard [ISO-MPEG] does not specify how private data should use the PUSI bit 💜
4.2. Length Indicator
Most services using MPEG-2 include a length field in the Payload Unit header to allow the Receiver to identify the end of a Payload Unit (e.g., PES Packet, Section, or an SNDU) 🌈
When parts of more than two Payload Units are carried in the same TS Packet, only the start of the first is indicated by the Payload Pointer. Placement of a Length Indicator in the encapsulation header allows a Receiver to determine the number of bytes until the start of the next encapsulated SNDU. This placement also gives the Receiver the chance to pre-allocate an appropriately sized memory buffer to receive the reassembled SNDU ✨
A Length Indicator is required, and should be carried in the encapsulation header. This should support SNDUs of at least the MTU size offered by Ethernet (currently 1500 bytes). Although the IPv4 and IPv6 packet format permits an IP packet of size up to 64 KB, such packets are seldom seen on the current Internet. Since high speed links are often limited by the packet forwarding rate of routers, there has been a tendency for Internet core routers to support MTU values larger than 1500 bytes. A value of 16 KB is not uncommon in the core of the current Internet. This would seem a suitable maximum size for an MPEG-2 transmission network 🔥
4.3. Next Level Protocol Type
Any IETF-defined encapsulation protocol should identify the payload type being transported (e.g., to differentiate IPv4, IPv6, etc). Most protocols use a type field to identify a specific process at the next higher layer that is the originator or the recipient of the payload (SNDU). This method is used by IPv4, IPv6, and also by the original Ethernet protocol (DIX). OSI uses the concept of a 'Selector' for this (e.g., in the IEEE 802/ISO 8802 standards for CSMA/CD [LLC]), although in this case, a SNAP (subnetwork access protocol) header is also required for IP packets 🦋
A Next Level Protocol Type field is also required if compression (e.g., Robust Header Compression [RFC3095]) is supported. No compression method has currently been defined that is directly applicable to this architecture, however the ROHC framework defines a number of header compression techniques that may yield considerable improvement in throughput on links that have a limited capacity. Since many MPEG-2 Transmission Networks are wireless, the ROHC framework will be directly applicable for many applications. The benefit of ROHC is greatest for smaller SNDUs, but it does imply the need for additional processing at the Receiver to expand the received compressed packets. The selected type field should contain sufficient code points to support this technique this part is giving main character energy 🎀
It is thus a requirement to include a Next Level Protocol Type field in the encapsulation header. Such a field should specify values for at least IPv4 and IPv6, and must allow for other values (e.g., MAC-level bridging) 💖
4.4. L2 Subnet Addressing ✨
okay so in MPEG-2, the PID in the TS Packet header is what tells you which service a packet belongs to, with some help from the SI tables 📺. this was mainly built as a one-way (simplex) broadcast system, so a TS Packet stream carries either tables or one PES Packet stream (compressed video or audio). individual Receivers are not addressable at this level 💀 nobody's getting their own DM in a broadcast 😭
IPv4 and IPv6 give addresses to end hosts and intermediate systems (routers) 🌍. each system (or interface) is identified by a globally assigned address. ISO has its own idea, a hierarchically structured Network Service Access Point (NSAP) address, which identifies an end host user process in an Internet environment 🧚
Within a local network, there's a totally different set of addresses for the Network Point of Attachment (NPA) 🎀. frequently these NPA addresses are referred to as Medium Access Control, MAC-level addresses. in the Internet they're also called hardware addresses. the main difference is that network layer addresses are used for routing, while NPA addresses are primarily used for Receiver identification 💖
Receivers may use the NPA of a received SNDU to reject unwanted unicast packets inside the (software) interface driver at the Receiver, but they must also perform forwarding checks based on the IP address 👀 IP multicast and broadcast may also filter using the NPA, but Receivers must also filter unwanted packets at the network layer based on source and destination IP addresses. this does not imply that each IP address must map to a unique NPA (more than one IP address may map to the same NPA). if a separate NPA address is not required, the IP address is sufficient for both functions 🦋
if you need to address an individual Receiver in an MPEG-2 transport system, you can do that either at the network level (IP address) or via a hardware-level NPA address (MAC-address) 🌸 if both addresses are used, they must be mapped in either a static or a dynamic way (e.g., by an address resolution process). a similar requirement may also exist to identify the PID and TS multiplex on which services are carried.
⚠️ using an NPA address in an MPEG-2 TS may enhance security, because a particular PDU can be targeted at a particular Receiver by specifying the corresponding Receiver NPA address. however, this is only a weak form of security. NPA filtering is often reconfigurable (frequently performed in software) and may be modified by a user to allow reception of specified (or all) packets, similar to promiscuous mode operation in Ethernet. if security is required, it should be applied at another place (e.g., link encryption, authentication of address resolution, IPsec, transport level security and/or application level security). don't rely on the NPA for this 🙅♀️
there are also cases where the use of an NPA is required (e.g., where a system operates as a router). if present, it should be carried in an encapsulation header where Receivers can use it as a pre-filter to discard unwanted SNDUs 🍓 the addresses allocated do not need to conform to the IEEE MAC address format. there are many cases where an NPA is not required, and network layer filtering may be used. therefore, a new encapsulation protocol should support an optional NPA. ✨
4.5. Integrity Check 🔥
for the IP service, the probability of undetected packet error should be small (or negligible) [RFC3819]. so there's a need for a strong integrity check (e.g., Cyclic Redundancy Check or CRC) to verify the correctness of a received PDU [RFC3819]. these checks should be sufficient to detect incorrect operation of the encapsulator and Receiver (including reassembly errors following loss or corruption of TS Packets), in addition to protecting against loss and/or corruption by the transmission network (e.g., multiplexors and links) 🛡️
MPEG-2 Transmission Networks have mechanisms that can help detect loss, like the 4-bit continuity counter in the MPEG-2 TS Packet header 🔢
an encapsulation must provide a strong integrity check for each IP packet 💅 the requirements for using a link CRC are in [RFC3819]. to make hardware implementation easier, this check should be carried in a trailer following the SNDU. a CRC-32 is sufficient for operation with up to a 12 KB payload, and may still provide adequate protection for larger payloads. ✨
4.6. Identification of Scope. 🎀
the MPE section header has information the Receiver could use to identify the scope of the (MAC) address carried as an NPA. it can also stop TS Packets intended for one scope from being received by another 🙈 similar functionality may be achieved by making sure that only IP packets that do not have overlapping scope are sent on the same TS Logical Channel. in some cases, this may mean using multiple TS Logical Channels. 🌈
4.7. Extension Headers 🧚
the Internet service will keep evolving, so it may need extra functions later on 🚀 a flexible protocol should therefore provide a way to introduce new features when required, without needing extra out-of-band configuration. main character energy 👑
IPv6 introduced extension headers that carry extra information which is necessary or desirable for certain subnetworks 💜 the DOCSIS cable specification also lets a MAC header carry extension headers to build operator-specific services. so it's a requirement that the new encapsulation allows extension headers. obsessed 😭
4.8. Summary of Requirements for Encapsulation 📋
the main requirements for an IP-centric encapsulation include:
- support of IPv4 and IPv6 packets
- support for Ethernet encapsulated packets
- flexibility to support other IP formats and protocols (e.g., ROHC, MPLS)
- easy implementation using either hardware or software processing
- low overhead/managed overhead
- a fully specified algorithm that allows a sender to pack multiple packets per SNDU and to easily locate packet fragments
- extensibility
- compatibility with legacy deployments
- ability to allow link encryption, when required
- capability to support a full network architecture including data, control, and management planes 💖
5. Address Resolution Functions 🦋
Address Resolution (AR) provides a mechanism that associates layer 2 (L2) information with the IP address of a system [IPDVB-AR]. many L2 technologies use unicast AR at the sender: an IP system that wants to send an IP packet encapsulates it and places it into an L2 frame. then it identifies the appropriate L3 adjacency (e.g., next hop router, end host) and figures out the right L2 adjacency (e.g., the MAC address in Ethernet) to send the frame to, so the packet gets across the L2 link 🚚
the L2 addresses found using AR are normally recorded in a data structure known as the arp/neighbor cache 🗂️ results of previous AR requests are usually cached. more AR protocol exchanges may be required as communication goes on, to update or re-initialize the client cache contents (i.e., purge/refresh them). for stability, and so the network can handle topology changes and client faults, the cache contents are normally "soft state". that means they age with time and old entries get removed ⏳
in some cases (e.g., ATM, X.25, MPEG-2 and many more), AR involves finding other information besides the MAC address. this includes identifying other parameters needed for L2 transmission, like channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2 TS) 🌟
address resolution has different purposes for unicast and multicast. multicast address resolution is not required for many L2 networks, but it is required where MPEG-2 transmission networks carry IP multicast packets using more than one TS Logical Channel. 💅✨
5.1. Address Resolution for MPEG-2 ✨
okay bestie, before an IP packet can get sent over an MPEG-2 TS you need three bits of L2 info 💖
- (i) A Receiver ID (e.g., a 6B MAC/NPA address).
- (ii) A PID or index to find a PID.
- (iii) Tuner information (e.g., Transmit Frequency of the physical layer of a satellite/broadcast link
elements (ii) and (iii) need to get de-referenced when the MPEG-2 Transmission Network has (re)multiplexors that renumber the PID values of the TS Logical Channels they process 🔁 in MPEG-2 [ISO-MPEG], that dereferencing happens through indexes to the info (aka the Program Map Table, PMT, which is itself indexed via the Program Association Table, PAT). (fyi PIDs are not meant to be end-to-end identifiers 🙈) but tbh remultiplexing is super common in broadcast TV networks (scenarios A and B), while lots of private networks don't need multiplexors that renumber PIDs (see Section 3.3) ✨
the third element (iii) lets an AR client resolve to a different MPEG TS Multiplex 🦋 this comes in handy when there are several channels it could use for comms (i.e., multiple outbound/inbound links). in a mesh system, it could be used to figure out connectivity. this AR info gets used in two ways at a Receiver:
- (i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG TS Multiplex, PID, MAC/NPA address). this lets the Receiver set L2 filters so traffic can pass up to the IP layer. it's used for unicast and IPv4 subnet broadcast 💅
- (ii) AR resolves an IP multicast address to the (MPEG TS Multiplex, PID, MAC/NPA address), and lets the Receiver set L2 filters so traffic can pass to the IP layer. a Receiver in an MPEG-2 TS Transmission Network needs to resolve the PID value and the tuning (if present) tied to a TS Logical Channel and (at least for unicast) the destination Receiver NPA address 🫶
a star topology MPEG-2 TS transmission network is shown below, with two Receivers catching a forward broadcast channel sent by a Hub 🌸 (a mesh system has some extra cases.) the forward broadcast channel is a "TS Multiplex" (a single physical bearer) that lets the Hub talk to the terminals. they talk back over a set of return channels 📡
Forward broadcast
MPEG-2 TS \
----------------X /-----\
/ / \
| Receiver|
/----------+ A |
/ \ /
/-----\ / \-----/
/ \ /
| Hub |/
| +\ /-----\
\ / \ / \
\-----/ \ | Receiver|
\-----------+ B |
\ /
\-----/Figure 6: MPEG-2 Transmission Network with 2 Receivers
there are three possibilities for unicast AR 👑
- (1) A system at a Receiver, A, needs to resolve an address of a system that is at the Hub.
- (2) A system at a Receiver, A, needs to resolve an address that is at another Receiver, B.
- (3) A host at the Hub needs to resolve an address that is at a Receiver. The sender (encapsulation gateway) uses AR to provide the MPEG TS Multiplex, PID, MAC/NPA address for sending unicast, IPv4 subnet broadcast and multicast packets.
if the Hub is an IP router, then case (1) and (2) are the same 🧚 the host at the Receiver doesn't know the difference. in these cases the address to determine is the L2 address of the device at the Hub that the IP packet should be forwarded to, which then relays the IP packet back to the forward (broadcast) MPEG-2 channel after AR (case 3).
if the Hub is an L2 bridge, then case 2 still has to relay the IP packet back to the outbound MPEG-2 channel. the AR protocol needs to resolve the specific Receiver L2 MAC address of B, but it has to send this on an L2 channel to the Hub. that means Receivers have to be told the L2 addresses of other Receivers 😭
an end host connected to the Hub needs to use the AR protocol to resolve the Receiver terminal MAC/NPA address. that requires the AR server at the Hub to know the L2 addresses of other Receivers 💀
5.2. Scenarios for MPEG AR 🌈
an AR protocol can send AR info in three distinct ways 🎀
- (i) An MPEG-2 signalling table sent at the MPEG-2 level (e.g., within the control plane using a Table).
- (ii) An MPEG-2 signalling table sent at the IP level (no implementations of this are known).
- (iii) An address resolution protocol carried over IP (as in ND for IPv6).
there are three distinct cases where AR might be used 💖
- (i) Multiple TS-Muxes and the use of re-multiplexors, e.g., Digital Terrestrial and Satellite TV broadcast multiplexes. lots of these systems use remultiplexors that change the PID values tied to TS Logical Channels as they pass through the MPEG-2 transmission network (as in Scenario A of Section 3.1).
- (ii) Tuner configuration(s) that are fixed or controlled by some other process. in these systems the Sender may already know the PID value tied to a TS Logical Channel.
- (iii) A service run over one TS Mux (i.e., using only one PID, for example DOCSIS and some current DVB-RCS multicast systems). in these systems the Sender may already know the PID value of a TS Logical Channel.
5.2.1. Table-Based AR over MPEG-2 📋
in current MPEG-2 deployments, info about the set of MPEG-2 TS Logical Channels carried over a TS Multiplex is usually shared through tables (service information, SI). those get sent on channels that use a specific (well-known) set of PIDs. this was originally designed for audio/video distribution to STBs. this design needs access to the control plane so it can process the SI table info (carried in MPEG-2 section format [ISO-DSMCC]). the whole scheme reflects how complicated it is to deliver and coordinate all the TS Logical Channels that go with a multimedia TV program 📺
one possible requirement for providing TS multiplex and PID info for IP services is to add extra info to the existing MPEG-2 tables, or to define new tables specific to the IP service. the DVB INT and the A/92 Specification from ATSC [ATSC-A92] are examples of this kind of solution ✨
5.2.2. Table-Based AR over IP 🦋
AR info could be carried over a TS data channel (e.g., using an IP protocol similar to the Service Announcement Protocol, SAP). doing this apart from the SI tables would make implementation easier, since it can run on systems where IP processing happens in a software driver. it might also make the technique easier to adapt to other similar delivery networks. it's also a win for networks that use the MPEG-2 TS but don't necessarily support audio/video services, so they don't need to stay interoperable with TV equipment (e.g., links used only for connecting IP (sub)networks) 🌸
5.2.3. Query/Response AR over IP 🔍
a query/response protocol could be used at the IP level (similar to, or based on, IPv6 Neighbor Advertisements of the ND protocol). the AR protocol might run over an MPEG-2 TS Logical Channel using a previously agreed PID (e.g., configured, or communicated using a SI table). in this case the AR could be handled by the target system itself (as in ARP and ND). this has good soft-state properties and is very tolerant to failures 💪 to find an address, a system sends a "query" to the network, and the "target" (or its proxy) replies 🫶
5.3. Unicast Address Scoping 🚧
sometimes an MPEG-2 Transmission Network supports multiple IP networks. when that's the case, it's important to recognize the context (scope) in which an address gets resolved, so packets from one addressed scope don't leak into other scopes 🙅♀️
an example of overlapping IP address assignments is the use of private unicast addresses (e.g., in IPv4, 10/8 prefix; 172.16/12 prefix; 192.168/16 prefix). these should stay confined to the area they're addressed to 🏠
there's also a requirement for multicast address scoping (Section 6.2) ✨
IP packets with these addresses must not be allowed to travel outside their intended scope, and they may cause unexpected behaviour if they're allowed to do so. this is serious bestie 😱 on top of that, overlapping address assignments can come up when using level 2 NPA addresses:
- (i) The NPA address must be unique within the TS Logical Channel. Universal IEEE MAC addresses used in Ethernet LANs are globally unique. if the NPA addresses aren't globally unique, the same NPA address might get re-used by Receivers in different addressed areas.
- (ii) The NPA broadcast address (all 1s MAC address). Traffic with this address should be confined to one addressed area.
receiving unicast packets meant for another addressed area can increase the rate of received packets for systems connected to the network. IP end hosts normally filter received unicast IP packets based on their assigned IP address. receiving that extra traffic can add to processing load, but it should not lead to unexpected protocol behaviour. however, it does open up a potential Denial of Service (DoS) opportunity 💀🚨
when the Receiver acts as an IP router, getting one of these IP packets may lead to unexpected protocol behaviour. this is also a security vulnerability, since arbitrary packets might get passed up to the IP layer 🔐
5.4. AR Authentication 🔐
in lots of AR designs, authentication has been overlooked because most existing IP networks are wired, which makes it easy to control hosts that are physically connected [RFC3819]. with wireless connections this is changing 📶 unauthorized hosts actually can claim L2 resources now. the address resolution client (i.e., Receiver) may also need to verify the integrity and authenticity of the AR info it receives. trust goes both ways: clients need to know they have a valid server and that the resolution is valid. servers should do authorisation before they let an L2 address be used 🫡
the MPEG-2 Transmission Network might also need access control to stop unauthorized use of the TS Multiplex. however, that's an orthogonal issue to address resolution 🧩
5.5. Requirements for Unicast AR over MPEG-2 📝
the requirements for AR over MPEG-2 networks include 💅
- (i) Use of a table-based approach to promote AR scaling. This requires defining the frequency of update and the volume of AR traffic generated.
- (ii) Mechanisms to install AR info at the server (unsolicited registration).
- (iii) Mechanisms to verify AR info held at the server (solicited responses). Appropriate timer values need to be defined.
- (iv) An ability to purge client AR info (after IP network renumbering, etc.).
- (v) Support of IP subnetwork scoping.
- (vi) Appropriate security associations to authenticate the sender.
6. Multicast Support ✨
okay so this section is all about IPv4 and IPv6 multicast [RFC1112] over MPEG-2 Transmission Networks 📡. The big goal is efficient filtering of IP multicast packets at the Receiver, plus mapping IPv4 and IPv6 multicast addresses [RFC3171] to the right PID value and TS Multiplex 🎀
The design should allow a large number of active multicast groups and keep the processing load at the Receiver low when it filters and forwards multicast packets 💅 Schemes that are easy to build in hardware would be a total win, since they could spare drivers and operating systems from having to throw away unwanted multicast traffic [RFC3819] 🫶
Multicast mechanisms show up at more than one protocol level 🦋 The upstream router feeding the MPEG-2 Encapsulator may forward multicast traffic on the MPEG-2 TS Multiplex using a static or dynamic set of groups. With static forwarding, the set of IP multicast groups may also be configured or set using SNMP, Telnet, etc. A Receiver normally uses either an IP group management protocol (IGMP [RFC3376] for IPv4 or MLD [RFC2710][RFC3810] for IPv6) or a multicast routing protocol to build the tables it uses to dynamically enable local forwarding of received groups 🧚 In the dynamic case, this group membership info gets fed back to the sender so it can start sending new groups and (if required) update the tables it makes for multicast AR 💜
Procedures need to figure out the correct action when the same multicast group is available on more than one TS Logical Channel 👀 This can happen when different end hosts act as senders contributing IP packets with the same IP group destination address. The correct behaviour for SSM [RFC3569] addresses must also be considered 🔥 It can also happen when a sender duplicates the same IP group over several TS Logical Channels (or even different TS Multiplexes). In that case a Receiver may potentially receive more than one copy of the same packet 😭 At the IP level, the host/router may be unaware of this duplication 🙈
6.1. Multicast AR Functions
The functions required for multicast AR may be summarized as:
(i) The Sender needs to know the L2 mapping of a multicast group. (ii) The Receiver needs to know the L2 mapping of a multicast group.
ngl this is the part where it clicks 💡 In the Internet, multicast AR is normally a mapping function rather than a one-to-one association using a protocol. In Ethernet, the sender maps an IP address to an L2 MAC address, and the Receiver uses the same mapping to figure out the L2 address to set its L2 hardware/software filter entry 🌸
A typical sequence of actions for the dynamic case looks like this:
L3) Populate the IP L3 membership tables at the Receiver.
L3) Receivers send/forward IP L3 membership tables to the Hub
L3) Dynamic/static forwarding at hub/upstream router of IP L3
groups
L2) Populate the IP AR tables at the encapsulator gateway
(i.e., Map IP L3 mcast groups to L2 PIDs)
L2) Distribute the AR information to Receivers
L2) Set Receiver L2 multicast filters for IP groups in the
membership table.To be flexible, AR must associate a TS Logical Channel (PID) not only with a group address, but possibly also with a QoS class and other appropriate MPEG-2 TS attributes 🎀 Explicit per group AR to individual L2 addresses is to be avoided 🙅♀️
\
|
+---+----+ +---------+
| Tuner |---+TS Table | . . . .
+---+----+ +---------+ .
| - .
+--------+ +---------+ .
| deMux |---+PID Table|........
+---+----+ +---------+ :
| - :
+--------+ +---------+ +------------+
|MPE/ULE |---+AR Cache-|---+ L2 Table |
+---+----+ +---------+ +------------+
| | |
+---+----+ +---+-----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+-----+ +---+----+
| | |
*------------+------------+Figure 7: Receiver Processing Architecture 🧩
6.2. Multicast Address Scoping
same energy as unicast 🫶 It's important to recognize the context (scope) a multicast IP address is resolved in, so packets from one addressed scope don't leak into other scopes 🚫
Examples of overlapping IP multicast address assignments include:
(i) Local scope multicast addresses. These are only valid within the local area (examples for IPv4 include: 224.0.0/24; 224.0.1/24). Similar cases exist for some IPv6 multicast addresses [RFC2375].
(ii) Scoped multicast addresses [RFC2365] [RFC 2375]. Forwarding of these addresses is controlled by the scope associated with the address. The addresses are only valid within an addressed area (e.g. the 239/8 [RFC2365]).
(iii) Other non-IP protocols may also view sets of MAC multicast addresses as link-local, and may produce unexpected results if distributed across several private networks 👀
IP packets with these addresses must not be allowed to travel outside their intended scope (see Section 5.3). Performing multicast AR at the IP level can enable providers to offer independently scoped addresses, and would need to use multiple Multicast AR servers, one per multicast domain 🌈
6.3. Requirements for Multicast over MPEG-2
The requirements for supporting multicast include, but are not restricted to:
(i) Encapsulating multicast packets for transmission using an MPEG-2 TS.
(ii) Mapping IP multicast groups to the underlying MPEG-2 TS Logical Channel (PID) and the MPEG-2 TS Multiplex.
(iii) Providing AR information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex.
(iv) Error Reporting.
7. Summary 🎀
This document describes the architecture for a set of protocols to perform efficient and flexible support for IP network services over networks built upon the MPEG-2 Transport Stream (TS) 🌸 It also describes existing approaches. The focus is on IP networking, the mechanisms that are used, and how they apply to supporting IP unicast and multicast services 💖
The requirements for a new encapsulation of IPv4 and IPv6 packets are described, outlining the limitations of current methods and the need for a streamlined IP-centric approach ✨
The architecture also describes MPEG-2 Address Resolution (AR) procedures that allow dynamic configuration of the sender and Receiver using an MPEG-2 transmission link/network 🦋 These support IPv4 and IPv6 services in both unicast and multicast modes. Resolution protocols will support IP packet transmission using both the Multiprotocol Encapsulation (MPE), which is currently widely deployed, and any IETF-defined encapsulation (e.g., ULE [IPDVB-ULE]) 🧚
8. Security Considerations 🔐
okay this one is SERIOUS bestie 😭 When the MPEG-2 transmission network is not using a wireline network, the normal security issues relating to the use of wireless links for transporting Internet traffic should be considered [RFC3819] 📡
End-to-end security (including confidentiality, authentication, integrity and access control) is closely tied to the end user assets that are protected. That tie can't be guaranteed when security mechanisms are provided only within a subnetwork (e.g., an MPEG-2 Transmission Network). Several end-to-end security mechanisms have already been deployed across the general Internet and are seeing more and more use. Important examples include:
- Transport Layer Security (TLS), which is primarily used to protect web commerce;
- Pretty Good Privacy (PGP) and S/MIME, primarily used to protect and authenticate email and software distributions;
- Secure Shell (SSH), used to secure remote access and file transfer;
- IPsec, a general purpose encryption and authentication mechanism above IP that can be used by any IP application.
However, subnetwork security is also important [RFC3819] and should be encouraged, on the principle that it is better than the default situation, which all too often is no security at all 🙃 Users of especially vulnerable subnets (such as radio/broadcast networks and/or shared media Internet access) often have control over, at most, one endpoint (usually a client), and therefore cannot enforce the use of end-to-end mechanisms 🥺
A related role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties (by IP or MAC address) and determining their communication patterns, even when their actual contents are protected by strong end-to-end security mechanisms. (This is important for networks such as broadcast/radio, where eavesdropping is easy 👂)
Encryption performed at the Transport Stream level (encrypting the payload of all TS-Packets with the same PID) encrypts/scrambles all parts of the SNDU, including the layer 2 MAC/NPA address. Encryption at the section level in MPE may also optionally encrypt the layer 2 MAC/NPA address in addition to the PDU data [ETSI-DAT]. In both cases, encryption of the MAC/NPA address requires a Receiver to decrypt all encrypted data before it can filter the PDUs with the set of MAC/NPA addresses it wishes to receive. This method also has the drawback that all Receivers must share a common encryption key 🔑 Encryption of the MPE MAC address is therefore not permitted in some systems (e.g., [ETSI-DVBRCS]) 🚫
Where it is possible for an attacker to inject traffic into the subnetwork control plane, subnetwork security can additionally protect the subnetwork assets. This threat must specifically be considered for the protocols used for subnetwork control functions (e.g., address resolution, management, configuration). Possible threats include theft of service and denial of service, and shared media subnets tend to be especially vulnerable to such attacks [RFC3819] 💀
Appropriate security functions must therefore be provided for IPDVB control protocols [RFC3819], particularly when the control functions are provided above the IP layer using IP-based protocols. Internet level security mechanisms (e.g., IPsec) can mitigate such threats. 🛡️
In general, End-to-End security is recommended for users of any communication path, especially when it includes a wireless/radio or broadcast link, where a range of security techniques already exist 🫶 Specification of security mechanisms at the application layer, or within the MPEG-2 transmission network, is the concern of organisations beyond the IETF. The complexity of any such security mechanisms should be considered carefully so that it does not unduly impact IP operations 🌈
8.1. Link Encryption ✨
okay so bestie, link-level encryption of IP traffic is super common on broadcast and radio links 📡 💖 It's basically a bonus layer on top of end-to-end security like TLS, SSH, Open PGP, S/MIME, or IPsec. 🔐 The encryption and key exchange methods vary a LOT depending on what you're using it for. Like, DVB-S/DVB-RCS run by Access Network Operators might want to give their customers (Internet Service Providers, ISP) some security services 🛰️ The common ones are terminal authentication and data confidentiality, for both unicast and multicast, between an encapsulation gateway and Receivers. 🫶 The goal is giving you the same level of privacy you'd get on terrestrial links. 🌸 An ISP might also want to offer end-to-end security to its end-users, using well-known stuff like IPsec. 🔥
So it's important to get that both of these security setups (Access Network Operators to ISP, and ISP to end-users) can totally coexist. 👑 Two layers, one vibe. 💅
MPE supports optional link encryption [ETSI-DAT]. ✨ A pair of bits in the MPE protocol header tells you whether encryption (scrambling) is being used. 🎀 For encrypted PDUs, those header bits show which of two previously selected encryption keys to use. 🗝️
It is recommended that any new encapsulation defined by the IETF allows Transport Stream encryption and also supports optional link level encryption/authentication of the SNDU payload. 🦋 In ULE [IPDVB-ULE], this can be handled really flexibly with Extension Headers. 🧚 That does mean defining a mandatory header extension, but the upside is it decouples the security functions from the encapsulation functions, which is so iconic. 💜 This method also supports encryption of the NPA/MAC addresses. 🙈
9. IANA Considerations 🍓
Okay, so any set of protocols that meets these requirements will need IANA to make assignments. 📋 This document by itself, though, doesn't need any IANA involvement at all. ✨
10. Acknowledgements 🫶
The authors want to thank Isabel Amonou, Torsten Jaekel, Pierre Loyer, Luoma Juha-Pekka, and Rod Walsh for their detailed inputs. 💖 They also want to acknowledge the input from the members of the IETF ipdvb WG. 🌈
11. References 📚
11.1. Normative References
[ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio
Information Systems", International Standards
Organisation (ISO).
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB
Specifications for Data Broadcasting", European
Telecommunications Standards Institute (ETSI).11.2. Informative References
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/91, 2001.
[ATSC-A92] A/92, "Delivery of IP Multicast Sessions over ATSC
Data Broadcast", Advanced Television Systems Committee
(ATSC), Doc. A/92, 2002.
[ATSC-G] A/54A, "Guide to the use of the ATSC Digital
Television Standard", Advanced Television Systems
Committee (ATSC), Doc. A/54A, 2003.
[ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television
Systems Committee (ATSC), Doc. A/65B, 2003.
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital
TV (DTV) Applications over Satellite", Advanced
Television Systems Committee (ATSC), Doc. A/80, 1999.
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B.,
"Internet over Broadcast Satellites", IEEE Commun.
Mag. 1999, pp.146-151.
[ETSI-BSM] TS 102 292, "Satellite Earth Stations and Systems
(SES); Broadband Satellite Multimedia Services and
Architectures; Functional Architecture for IP
Interworking with BSM networks", European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems
(CATV)", European Telecommunications Standards
Institute (ETSI).
[ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB);
Interaction channel for satellite distribution
systems", European Telecommunications Standards
Institute (ETSI).
[ETSI-DVBS] EN 301 421,"Digital Video Broadcasting (DVB);
Modulation and Coding for DBS satellite systems at
11/12 GHz", European Telecommunications Standards
Institute (ETSI).
[ETSI-DVBS2] EN 302 207, "Second generation framing structure,
channel coding and modulation systems for
Broadcasting, Interactive Services,News Gathering and
Other Broadband Satellite Applications", European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBT] EN 300 744, "Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital
terrestrial television (DVB-T)", European
Telecommunications Standards Institute (ETSI).
[ETSI-IPDC] "IP Datacast Specification", DVB Interim Specification
CNMS 1026 v1.0.0,(Work in Progress), April 2004.
[ETSI-MHP] TS 101 812, "Digital Video Broadcasting (DVB);
Multimedia Home Platform (MHP) Specification", v1.2.1,
European Telecommunications Standards Institute
(ETSI), June 2002.
[ETSI-RC] ETS 300 802, "Digital Video Broadcasting (DVB);
Network-independent protocols for DVB interactive
services", European Telecommunications Standards
Institute (ETSI).
[ETSI-SI] EN 300 468, "Digital Video Broadcasting (DVB);
Specification for Service Information (SI) in DVB
systems", European Telecommunications Standards
Institute (ETSI).
[IPDVB-ULE] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP
datagrams over an MPEG-2 Transport Stream", Work in
Progress, June 2005.
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution
for IP datagrams over MPEG-2 networks", Work in
Progress, 2005.
[ISO-AUD] ISO/IEC 13818-3:1995, "Information technology; Generic
coding of moving pictures and associated audio
information; Part 3: Audio", International Standards
Organisation (ISO).
[ISO-DSMCC] ISO/IEC IS 13818-6, "Information technology; Generic
coding of moving pictures and associated audio
information; Part 6: Extensions for DSM-CC",
International Standards Organisation (ISO).
[ISO-VID] ISO/IEC DIS 13818-2:1998, "Information technology;
Generic coding of moving pictures and associated audio
information; Video", International Standards
Organisation (ISO).
[ITU-AAL5] ITU-T I.363.5, "B-ISDN ATM Adaptation Layer
Specification Type AAL5", International Standards
Organisation (ISO), 1996.
[LLC] ISO/IEC 8802.2, "Information technology;
Telecommunications and information exchange between
systems; Local and metropolitan area networks;
Specific requirements; Part 2: Logical Link Control",
International Standards Organisation (ISO), 1998.
[MMUSIC-IMG] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H.
Schulzrinne, "Requirements for Internet Media Guides",
Work in Progress, June 2004.
[OPEN-CABLE] "Open Cable Application Platform Specification; OCAP
2.0 Profile", OC-SP-OCAP2.0-I01-020419, Cable Labs,
April 2002.
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
Y. Zhang, "A Link-Layer Tunneling Mechanism for
Unidirectional Links", RFC 3077, March 2001.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren,
T., Le, K., Liu, Z., Martensson, A., Miyazaki, A.,
Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng,
"RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
July 2001.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address
Assignments", BCP 51, RFC 3171, August 2001.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
and L. Wood, "Advice for Internet Subnetwork
Designers", BCP 89, RFC 3819, July 2004 .Appendix A: MPEG-2 Encapsulation Mechanisms ✨
Okay bestie, so sending packet data over an MPEG-2 transmission network 📡 means every PDU (think IPv4 packets, IPv6 packets, or bridged Ethernet Frames) has to get wrapped up using a convergence protocol 🎀. These are the encapsulations that are currently standardized for MPEG-2 transmission networks, and they're all lowkey iconic 💅:
(i) Multi-Protocol Encapsulation (MPE).
The MPE spec of DVB [ETSI-DAT] carries IP packets inside private Sections 🌸. The encapsulation is similar to the IEEE LAN/MAN standards [LLC]. Data packets get tucked into datagram sections that follow the DSMCC section format for private data. Some Receivers can use section processing hardware to do a first-level filtering of the packets that arrive at the Receiver, which is so efficient 🧚.
This encapsulation uses a MAC-level Network Point of Attachment address 🦋. The address format follows the ISO/IEEE standards for LAN/MAN [LLC]. The 48-bit MAC address field holds the MAC address of the destination, and it's split across six 8-bit fields labelled MAC_address_1 to MAC_address_6. MAC_address_1 holds the most significant byte of the MAC address, and MAC_address_6 holds the least significant byte. How many of these bytes are significant is optional, and it's defined by the value of the broadcast descriptor table [ETSI-DAT]. That table gets sent separately over another MPEG-2 TS within the TS multiplex 🍓.
MPE is currently a widely deployed scheme, and honestly it's giving staying power 👑. Because of investments in existing systems, usage is likely to continue in current and future MPEG-2 Transmission Networks. ATSC provides a scheme similar to MPE [ATSC-DAT] with some small differences 💜.
(ii) Data Piping.
The Data Piping profile [ETSI-DAT] is a minimum overhead, simple and flexible profile 🫶. It makes no assumptions about the format of the data being sent, so it's super chill like that 😌. In this profile, the Receiver is intended to provide PID filtering, packet reassembly according to [ETSI-SI], error detection, and optional Conditional Access (link encryption) 🔒.
The specification lets the user data stream be unstructured or organized into packets 🌈. The specific structure is transparent to the Receiver, so it doesn't care. It may conform to any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc. Literally anything can ride along ✨.
(iii) Data Streaming.
The data broadcast spec profile [ETSI-DAT] for PES tunnels (Data Streaming) supports unicast and multicast data services that need a stream-oriented delivery of data packets 🎀. This encapsulation maps an IP packet into a single PES Packet payload 💖.
Two different types of PES headers can be picked via the stream_id values [ISO-MPEG]. The private_stream_2 value allows the short PES header with limited overhead 🦋. The private_stream_1 value gives you the scrambling control and the timing and clock reference features of the PES layer 🔥. Choices, choices 🙈.
Authors' Addresses
Marie J. Montpetit
Motorola Connected Home Solutions
45 Hayden Avenue 4th Floor
Lexington MA 02130
USA
EMail: mmontpetit@motorola.com
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Horst D. Clausen
TIC Systems
Lawrence, Kansas
EMail: h.d.clausen@ieee.org
Bernhard Collini-Nocker
Department of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
EMail: bnocker@cosy.sbg.ac.at
Web: http://www.network-research.org
Hilmar Linder
Department of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
EMail: hlinder@cosy.sbg.ac.at
Web: http://www.network-research.orgFull Copyright Statement 💅
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🧚
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📚.
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 💌.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶💜
📦 where this page comes from
- ietf: rfc4259 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms