’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 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.
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, IPv6, and must allow for other values (e.g., MAC-level
bridging).
4.4. L2 Subnet Addressing
In MPEG-2, the PID carried in the TS Packet header is used to
identify individual services with the help of SI tables. This was
primarily intended as a unidirectional (simplex) broadcast system. A
TS Packet stream carries either tables or one PES Packet stream
(i.e., compressed video or audio). Individual Receivers are not
addressable at this level.
IPv4 and IPv6 allocate addresses to end hosts and intermediate
systems (routers). Each system (or interface) is identified by a
globally assigned address. ISO uses the concept of a hierarchically
structured Network Service Access Point (NSAP) address to identify an
end host user process in an Internet environment.
Within a local network, a completely different set of addresses for
the Network Point of Attachment (NPA) is used; frequently these NPA
addresses are referred to as Medium Access Control, MAC-level
addresses. In the Internet they are also called hardware addresses.
Whereas network layer addresses are used for routing, NPA addresses
are primarily used for Receiver identification.
Receivers may use the NPA of a received SNDU to reject unwanted
unicast packets within the (software) interface driver at the
Receiver, but 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 it is required to address an individual Receiver in an MPEG-2
transport system, this can be achieved 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, in that a
particular PDU may be targeted for a particular Receiver by
specifying the corresponding Receiver NPA address. However, this is
only a weak form of security, since the 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).
There are also cases where the use of an NPA is required (e.g., where
a system operates as a router) and, if present, this should be
carried in an encapsulation header where it may be used by Receivers
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]. Therefore, there is a need for a
strong integrity check (e.g., Cyclic Redundancy Check or CRC) to
verify correctness of a received PDU [RFC3819]. Such checks should
be sufficient to detect incorrect operation of the encapsulator and
Receiver (including reassembly errors following loss/corruption of TS
Packets), in addition to protecting from loss and/or corruption by
the transmission network (e.g., multiplexors and links).
Mechanisms exist in MPEG-2 Transmission Networks that may assist in
detecting loss (e.g., the 4-bit continuity counter included in the
MPEG-2 TS Packet header).
An encapsulation must provide a strong integrity check for each IP
packet. The requirements for usage of a link CRC are provided in
[RFC3819]. To ease hardware implementation, 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 contains information that could be used by the
Receiver to identify the scope of the (MAC) address carried as an
NPA, and to prevent TS Packets intended for one scope from being
received by another. Similar functionality may be achieved by
ensuring that only IP packets that do not have overlapping scope are
sent on the same TS Logical Channel. In some cases, this may imply
the use of multiple TS Logical Channels.
4.7. Extension Headers
The evolution of the Internet service may require additional
functions in the future. A flexible protocol should therefore
provide a way to introduce new features when required, without having
to provide additional out-of-band configuration.
IPv6 introduced the concept of extension headers that carry extra
information necessary/desirable for certain subnetworks. The DOCSIS
cable specification also allows a MAC header to carry extension
headers to build operator-specific services. Thus, it is a
requirement for the new encapsulation to allow extension headers.
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 employ unicast AR at the sender: an IP system wishing to
send an IP packet encapsulates it and places it into an L2 frame. It
then identifies the appropriate L3 adjacency (e.g., next hop router,
end host) and determines the appropriate L2 adjacency (e.g., MAC
address in Ethernet) to which the frame should be sent so that the
packet gets across the L2 link.
The L2 addresses discovered using AR are normally recorded in a data
structure known as the arp/neighbor cache. The results of previous
AR requests are usually cached. Further AR protocol exchanges may be
required as communication proceeds to update or re-initialize the
client cache state contents (i.e., purge/refresh the contents). For
stability, and to allow network topology changes and client faults,
the cache contents are normally "soft state"; that is, they are aged
with respect to time and old entries are removed.
In some cases (e.g., ATM, X.25, MPEG-2 and many more), AR involves
finding other information than the MAC address. This includes
identifying other parameters required for L2 transmission, such as
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 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
There are three elements to the L2 information required to perform AR
before an IP packet is sent over an MPEG-2 TS. These are:
(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 be de-referenced when the MPEG-2
Transmission Network includes (re)multiplexors that renumber the PID
values of the TS Logical Channels that they process. In MPEG-2
[ISO-MPEG], this dereferencing is via indexes to the information
(i.e., the Program Map Table, PMT, which is itself indexed via the
Program Association Table, PAT). (Note that PIDs are not intended to
be end-to-end identifiers.) However, although remultiplexing is
common in broadcast TV networks (scenarios A and B), many private
networks do not need to employ multiplexors that renumber PIDs (see
Section 3.3).
The third element (iii) allows an AR client to resolve to a different
MPEG TS Multiplex. This is used when there are several channels that
may be used for communication (i.e., multiple outbound/inbound
links). In a mesh system, this could be used to determine
connectivity. This AR information is 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 allows the Receiver
to set L2 filters to let traffic pass to the IP layer. This is
used for unicast, and IPv4 subnet broadcast.
(ii) AR resolves an IP multicast address to the (MPEG TS Multiplex,
PID, MAC/NPA address), and allows the Receiver to set L2 filters
enabling traffic to 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) associated with a TS Logical Channel
and (at least for unicast) the destination Receiver NPA address.
A star topology MPEG-2 TS transmission network is illustrated below,
with two Receivers receiving a forward broadcast channel sent by a
Hub. (A mesh system has some additional cases.) The forward
broadcast channel consists of a "TS Multiplex" (a single physical
bearer) allowing communication with the terminals. These communicate
using 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 does not know the difference. In these cases,
the address to be determined is the L2 address of the device at the
Hub to which the IP packet should be forwarded, 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 needs to send
this on an L2 channel to the Hub. This requires Receivers to be
informed of the L2 address of other Receivers.
An end host connected to the Hub needs to use the AR protocol to
resolve the Receiver terminal MAC/NPA address. This requires the AR
server at the Hub to be informed of the L2 addresses of other
Receivers.
5.2. Scenarios for MPEG AR
An AR protocol may transmit AR information in three distinct ways:
(i) An MPEG-2 signalling table transmitted at the MPEG-2 level
(e.g., within the control plane using a Table);
(ii) An MPEG-2 signalling table transmitted at the IP level (no
implementations of this are known);
(iii) An address resolution protocol transported over IP (as in ND
for IPv6)
There are three distinct cases in which AR may be used:
(i) Multiple TS-Muxes and the use of re-multiplexors, e.g., Digital
Terrestrial, Satellite TV broadcast multiplexes. Many such
systems employ remultiplexors that modify the PID values
associated with 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 PID value associated with
a TS Logical Channel may be known by the Sender.
(iii) A service run over one TS Mux (i.e., uses only one PID, for
example DOCSIS and some current DVB-RCS multicast systems). In
these systems, the PID value of a TS Logical Channel may be
known by the Sender.
5.2.1. Table-Based AR over MPEG-2
In current deployments of MPEG-2 networks, information about the set
of MPEG-2 TS Logical Channels carried over a TS Multiplex is usually
distributed via tables (service information, SI) sent using channels
assigned a specific (well-known) set of PIDs. This was originally
designed for audio/video distribution to STBs. This design requires
access to the control plane by processing the SI table information
(carried in MPEG-2 section format [ISO-DSMCC]). The scheme reflects
the complexity of delivering and coordinating the various TS Logical
Channels associated with a multimedia TV program.
One possible requirement to provide TS multiplex and PID information
for IP services is to integrate additional information into the
existing MPEG-2 tables, or to define additional tables specific to
the IP service. The DVB INT and the A/92 Specification from ATSC
[ATSC-A92] are examples of the realization of such a solution.
5.2.2. Table-Based AR over IP
AR information could be carried over a TS data channel (e.g., using
an IP protocol similar to the Service Announcement Protocol, SAP).
Implementing this independently of the SI tables would ease
implementation, by allowing it to operate on systems where IP
processing is performed in a software driver. It may also allow the
technique to be more easily adapted to other similar delivery
networks. It also is advantageous for networks that use the MPEG-2
TS, but do not necessarily support audio/video services and therefore
do not need to provide interoperability with TV equipment (e.g.,
links used solely for connecting IP (sub)networks).
5.2.3. Query/Response AR over IP
A query/response protocol may be used at the IP level (similar to, or
based on IPv6 Neighbor Advertisements of the ND protocol). The AR
protocol may operate 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 performed 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
In some cases, an MPEG-2 Transmission Network may support multiple IP
networks. When this is the case, it is important to recognize the
context (scope) within which an address is resolved, to prevent
packets from one addressed scope from leaking 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 be confined to the area to
which they are addressed.
There is 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 may cause unexpected behaviour if allowed
to do so. In addition, overlapping address assignments can arise
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 are not globally
unique, the same NPA address may be 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.
Reception of unicast packets destined for another addressed area may
lead to an increase in the rate of received packets by systems
connected via the network. IP end hosts normally filter received
unicast IP packets based on their assigned IP address. Reception of
the additional network traffic may contribute to processing load but
should not lead to unexpected protocol behaviour. However, it does
introduce a potential Denial of Service (DoS) opportunity.
When the Receiver acts as an IP router, the receipt of such an IP
packet may lead to unexpected protocol behaviour. This also provides
a security vulnerability since arbitrary packets may be passed to the
IP layer.
5.4. AR Authentication
In many AR designs, authentication has been overlooked because of the
wired nature of most existing IP networks, 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. The address resolution client (i.e., Receiver) may
also need to verify the integrity and authenticity of the AR
information that it receives. There are trust relationships both
ways: clients need to know they have a valid server and that the
resolution is valid. Servers should perform authorisation before
they allow an L2 address to be used.
The MPEG-2 Transmission Network may also require access control to
prevent unauthorized use of the TS Multiplex; however, this is an
orthogonal issue to address resolution.
5.5. Requirements for Unicast AR over MPEG-2
The requirement for AR over MPEG-2 networks include:
(i) Use of a table-based approach to promote AR scaling. This
requires definition of the frequency of update and volume of
AR traffic generated.
(ii) Mechanisms to install AR information at the server
(unsolicited registration).
(iii) Mechanisms to verify AR information held at the server
(solicited responses). Appropriate timer values need to be
defined.
(iv) An ability to purge client AR information (after IP network
renumbering, etc.).
(v) Support of IP subnetwork scoping.
(vi) Appropriate security associations to authenticate the sender.
6. Multicast Support
This section addresses specific issues concerning IPv4 and IPv6
multicast [RFC1112] over MPEG-2 Transmission Networks. The primary
goal of multicast support will be efficient filtering of IP multicast
packets by the Receiver, and the mapping of IPv4 and IPv6 multicast
addresses [RFC3171] to the associated PID value and TS Multiplex.
The design should permit a large number of active multicast groups,
and should minimize the processing load at the Receiver when
filtering and forwarding IP multicast packets. For example, schemes
that may be easily implemented in hardware would be beneficial, since
these may relieve drivers and operating systems from discarding
unwanted multicast traffic [RFC3819].
Multicast mechanisms are used 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. When static forwarding is used, 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 establish tables that it uses to dynamically
enable local forwarding of received groups. In a dynamic case, this
group membership information is fed back to the sender to enable it
to start sending new groups and (if required) to update the tables
that it produces for multicast AR.
Appropriate procedures need to identify the correct action when the
same multicast group is available on more than one TS Logical
Channel. This could arise when different end hosts act as senders to
contribute IP packets with the same IP group destination address.
The correct behaviour for SSM [RFC3569] addresses must also be
considered. It may also arise when a sender duplicates the same IP
group over several TS Logical Channels (or even different TS
Multiplexes), and in this 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.
In the Internet, multicast AR is normally a mapping function rather