Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen
Document: draft-ietf-ipdvb-ar-01.txt Marie-Jose Montpetit
IETF ipdvb WG Motorola
Category: Internet Draft Expires March 2006
Address Resolution for IP datagrams over MPEG-2 networks
Status of this Draft
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes the process of binding/associating IPv4/IPv6
addresses with MPEG-2 Transport Streams (TS). This procedure is
known as Address Resolution (AR), or Neighbour Discovery (ND). Such
address resolution complements the higher layer resource discovery
tools that are used to advertise IP sessions.
In MPEG-2 networks, an IP address must be associated with a Packet
ID (PID) and a specific Transmission Multiplex. The document reviews
current methods. It also describes the interaction with well-known
protocols for address management including DHCP, ARP, and NDP, and
provides guidance on usage.
Expires March 2006 [page 1]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
Table of Contents
1. Introduction
2. Convention used in the document
3. Address Resolution Requirement
3.1 Unicast Support
3.2 Multicast Support
4. MPEG-2 Address Resolution
4.1 Static configuration.
4.1.1 MPEG-2 Cable Networks
4.2 MPEG-2 Table-Based Address Resolution
4.2.1 IP/MAC Notification Table (INT) and its usage
4.2.2 Multicast Mapping Table (MMT) and its usage
4.2.3 Application Information Table (AIT) and its usage
4.2.4 Comparison of SI/PSI table approaches
4.3 IP-based resolution of TS Logical Channels
4.3.1 IP-based multicast resolution of TS Logical Channels
5. Mapping IP addresses to NPA/MAC addresses
5.1 Uni-directional links supporting uni-directional
connectivity
5.2 Uni-directional links with bi-directional connectivity
5.3 Bi-directional links
5.4 IP Multicast AR
6. Link Layer Support
6.1 ULE without a destination MAC/NPA address (D=1)
6.2 ULE with a destination NPA/MAC address (D=0)
6.3 MPE without LLC/SNAP Encapsulation
6.4 MPE with LLC/SNAP Encapsulation
6.5 ULE with Bridging Header Extension (D=1)
6.6 ULE with Bridging Header Extension and NPA Address (D=0)
6.7 MPE with LLC/SNAP and Bridging
7. Conclusions
8. Security Considerations
9. Acknowledgements
10. References
11. Author's Addresses
12. IPR Notices
13. Copyright Statements
14. IANA Considerations
Appendices
Expires December 2005 [page 2]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
1. Introduction
The MPEG-2 Transport Stream (TS) provides a time-division
multiplexed (TDM) stream that may contain audio, video and data
information, including encapsulated IP datagrams. It is defined in
specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer-2 frame, known
as a TS Packet, contains a 4 byte header and a 184 byte payload.
Each TS Packet is associated with a single TS Logical Channel,
identified by a 13 bit Packet ID (PID) value that is carried in the
MPEG-2 TS Packet header.
The MPEG-2 standard also defines a control plane that may be used to
transmit control information to Receivers using System Information
(SI) Tables [ETSI-SI, ETSI-SI1], or Program Specific Information
(PSI) Tables.
To utilise the MPEG-2 TS as an IP link, a sender must associate an
IP address with a particular Transmission Multiplex, and within the
multiplex identify the specific PID to be used. This document calls
this mapping Address Resolution (AR) [ID-IPDVB-ARCH]. In some AR
schemes, the MPEG-2 TS address space is sub-divided into logical
contexts known as Platforms. Each Platform associates an IP service
provider with a separate context that share a common MPEG-2 TS (use
the same PID value).
MPEG-2 Receivers may use a Network Point of Attachment (NPA) [ID-
IPDVB-ARCH] to uniquely identify the L2 node within the MPEG-2
transmission network. An example of an NPA is the IEEE Medium Access
Control (MAC) address. Where such addresses are used, these must
also be signalled by the AR procedure. Finally, address resolution
may need to signal the format of the data being transmitted, for
example, the encapsulation, any L2 encryption method and any
compression scheme [ID-IPDVB-ARCH].
The numbers of Receivers connected via a single link may be much
larger than found in other common LAN technologies, (e.g. Ethernet).
This has implications on design/configuration of the address
resolution mechanisms. Current routing protocols, and some multicast
application protocols also do not scale to arbitrary large numbers
of participants. Such networks do not by themselves introduce an
appreciable subnetwork round trip delay, however many practical
MPEG-2 transmission networks are built using links that may
introduce significant path delay (Satellite links, use of dial-up
modem return, cellular return, etc). This higher delay may need to
be accommodated for in the design of protocols that use this
service.
The remainder of the document describes current mechanisms and their
use to associate an IP address with the corresponding TS Multiplex,
PID value, the NPA/MAC address and/or Platform ID. A range of
approaches is described, including Layer-2 methods (utilising MPEG-2
Expires December 2005 [page 3]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
SI tables), and protocols at the IP level (including the IPv4
Address Resolution Protocol, ARP [RFC826] and the IPv6 Neighbor
Discovery Protocol, NDP [RFC2461]). Interactions and dependencies
between these methods and the encapsulation methods are described.
Expires December 2005 [page 4]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
2. Conventions used in this document
AIT: Application Information Table specified by the Multimedia
Home Platform (MHP) specifications [ETSI-MHP]. This table may
carry IPv4/IPv6 to MPEG-2 TS address resolution information.
ATSC: Advanced Television Systems Committee [ATSC]. A framework and
a set of associated standards for the transmission of video, audio,
and data using the ISO MPEG-2 standard.
b: bit. For example, one byte consists of 8b.
B: Byte. Groups of bytes are represented in Internet byte order.
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A
format for transmission of data and control information in an MPEG-2
Private Section, defined by the ISO MPEG-2 standard.
DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of
associated standards published by the European Telecommunications
Standards Institute (ETSI) for the transmission of video, audio, and
data, using the ISO MPEG-2 Standard.
DVB-RCS: Digital Video Broadcast Return Channel via Satellite.
A bi-directional IPv4/IPv6 service employing low-cost Receivers.
Encapsulator: A network device that receives PDUs and formats these
into Payload Units (known here as SNDUs) for output as a stream of
TS Packets.
INT: Internet/MAC Notification Table. A uni-directional
addressing resolution mechanism using SI and/or PSI Tables.
MAC: Medium Access Control [IEEE-802.3]. A link layer protocol
defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).
MAC Header: The link layer header of the IEEE 802.3 standard [IEEE-
802.3] or Ethernet v2 [DIX]. It consists of a 6B destination
address, 6B source address, and 2B type field (see also NPA, LLC).
MAC: Medium Access and Control of the Ethernet IEEE 802 standard
of protocols (see also NPA).
MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia
receiver, that may (in some cases) support IPv4/IPv6 services.
MMT: Multicast Mapping Table (proprietary extension to DVB-RCS
defining an AR table that maps IPv4 multicast addresses to PID
values).
MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT; ATSC-DATG]. A
scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each
Section is sent in a series of TS Packets using a single TS Logical
Expires December 2005 [page 5]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
Channel.
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards
Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
NPA: Network Point of Attachment. In this document, refers to a 6
byte destination address (resembling an IEEE MAC address) within the
MPEG-2 transmission network that is used to identify individual
Receivers or groups of Receivers.
PAT: Program Association Table. An MPEG-2 PSI control table. It
associates each program with the PID value that is used to send the
associated PMT, [ISO-MPEG2]. This table is sent using the well-known
PID value of 0x000 and is required for an MPEG-2 compliant TS.
PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the
header of TS Packets. This is used to identify the TS Logical
Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets
forming the parts of a Table Section, PES, or other Payload Unit
must all carry the same PID value. The all ones PID value indicates
a Null TS Packet introduced to maintain a constant bit rate of a TS
Multiplex. There is no required relationship between the PID values
used for TS Logical Channels transmitted using different TS
Multiplexes.
PMT: Program Map Table. An MPEG-2 PSI control table that associates
the PID values used by the set of TS Logical Channels/ Streams that
comprise a program [ISO-MPEG2]. The PID value which is used to send
the PMT for a specific program is defined by an entry in the PAT.
Private Section: A syntactic structure constructed in accordance
with Table 2-30 of [ISO-MPEG2]. The structure may be used to
identify private information (i.e. not defined by [ISO-MPEG2])
relating to one or more elementary streams, or a specific MPEG-2
program, or the entire Transport Stream. Other Standards bodies,
e.g. ETSI, ATSC, have defined sets of table structures using the
private_section structure. A Private Section is transmitted as a
sequence of TS Packets using a TS Logical Channel. A TS Logical
Channel may carry sections from more than one set of tables.
PSI: Program Specific Information [ISO-MPEG2]. PSI is used to
convey information about services carried in a TS Multiplex.
It is carried in one of four specifically identified table
section constructs [ISO-MPEG2], see also SI Table.
Receiver: Equipment that processes the signal from a TS Multiplex
and performs filtering and forwarding of encapsulated PDUs to the
network-layer service (or bridging module when operating at the link
layer).
SI Table: Service Information Table [ISO-MPEG2]. In this document,
Expires December 2005 [page 6]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
this term describes a table that is been defined by another
standards body to convey information about the services carried in a
TS Multiplex. A Table may consist of one or more Table Sections,
however, all sections of a particular SI Table must be carried over
a single TS Logical Channel [ISO-MPEG2].
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2
Payload Unit.
Table Section: A Payload Unit carrying all or a part of an SI or PSI
Table [ISO-MPEG2].
TS: Transport Stream [ISO-MPEG2], a method of transmission at the
MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI
reference model. See also TS Logical Channel and TS Multiplex.
to two terrestrial TV transmission cells.
TS Logical Channel: Transport Stream Logical Channel. In this
document, this term identifies a channel at the MPEG-2 level
[ISO-MPEG2]. This exists at level 2 of the ISO/OSI reference model.
All packets sent over a TS Logical Channel carry the same PID
value (this value is unique within a specific TS Multiplex). The
term "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the
content carried by a specific TS Logical Channel (see, ULE Stream).
Some PID values are reserved (by MPEG-2) for specific signalling.
Other standards (e.g., ATSC, DVB) also reserve specific PID values.
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 (i.e. a transmission at a specified symbol
rate, FEC setting, and transmission frequency) or an encapsulation
provided by another protocol layer (e.g. Ethernet, or RTP over IP).
The same TS Logical Channel may be repeated over more than one TS
Multiplex (possibly associated with a different PID value) [ID-
ipdvb-arch], for example to 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-MPEG2]. Each TS Packet carries a 4B header, plus optional
overhead including an Adaptation Field, encryption details and time
stamp information to synchronise a set of related TS Logical
Channels.
UDL: Unidirectional link: A one-way transmission IP over DVB link,
e.g., a broadcast satellite link.
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE
encapsulated PDUs. ULE Streams may be identified by definition of
a stream_type in SI/PSI [ISO_MPEG2].
Expires December 2005 [page 7]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
3. Address Resolution Requirements
The MPEG IP address resolution process is independent of the choice
of encapsulation and needs to support a set of IP over MPEG-2
encapsulation formats, including MPE [ETSI-DAT,ETSI-DAT1, ATSC-DAT])
and the IETF-defined Ultra Lightweight Encapsulation (ULE) [ID-
ARCH,ID-ULE].
The general IP over MPEG-2 AR requirements are summarized below:
- A protocol version, to indicate the specific protocol in use.
- A method to represent IPv4/IPv6 AR information.
- Support for scoping of addresses.
- Scalable and efficient method for transmission
(link local multicast, is preferable to IP broadcast).
- Incremental update of clients with AR information.
- Procedures for purging stale client AR information.
- A method to identify the Server sourcing AR information.
- Security associations to authenticate the AR information.
- A method to install AR information at the AR server
(unsolicited registration).
An MPEG-2 Transmission Network may support multiple IP networks.
If this is the case, it is important to recognise the context
(scope) within which an address is resolved, to prevent packets from
one addressed scope leaking into other scopes. Examples of
overlapping IP address assignments include:
(i) Private unicast addresses (e.g. in IPv4, 10/8 prefix;
172.16/12 prefix; 192.168/16 prefix) should be confined to
one addressed area. IPv6 also defines link-local addresses that
must not be forwarded beyond the link on which they were first
sent.
(ii) Some multicast addresses. For example, scoped multicast
addresses sometimes used in private networks. These are
only valid within an addressed area, examples for IPv4
include; 224.0.0/24; 224.0.1/24. Similar cases
exist for some IPv6 multicast addresses.
(iii)Scoped multicast addresses. Forwarding of these addresses
is controlled by the scope associated with the address.
Overlapping address assignments may also occur at L2, where the same
NPA/MAC address is used to identify multiple Receivers [ID-IPDVB-
ARCH]:
(i) An NPA unicast address must be unique within the addressed
area. The IEEE assigned MAC addresses used in Ethernet LANs are
Globally unique. If the NPA addresses are not globally unique,
an NPA address must only be re-used by Receivers in
Expires December 2005 [page 8]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
different addressed (scoped) areas.
(ii) The NPA broadcast address (all 1 MAC address). Traffic
with this address should be confined to one addressed area.
(iii) IP and other protocols may view sets of MAC multicast
addresses as link-local, and may produce unexpected results if
frames with these address are distributed across several
private networks.
Reception of unicast packets destined for another addressed area
will lead to an increase in the rate of received packets by systems
connected via the network. Reception of the additional network
traffic may contribute to processing load, but should not lead to
unexpected protocol behaviour. It does however introduce a potential
Denial of Service (DoS) opportunity. When the Receiver operates as
an IP router, the receipt of such a packet can lead to unexpected
protocol behaviour.
3.1 Unicast Support
Unicast address resolution is required at two levels. At the upper
level, the AR procedure needs to associate an IP address with a
specific NPA/MAC address. At the lower level, the IP (or MAC)
address needs to be associated with a specific TS Logical Channel
(PID value) and the corresponding TS Multiplex.
The same unicast IP address may be associated with more than one TS
Logical Channel within the same scope [DVB-DAT]. These may have
different content, but there is also the possibility of a Receiver
receiving duplicated copies of packets.
3.2 Multicast Support
Multicast is an important application for MPEG-2 Transmission
Networks, since it exploits the advantages of native support for
link broadcast.
Multicast address resolution occurs at the network level in
associating a specific L2 address with an IP Group Destination
Address (section 5). In IPv4 and IPv6 over Ethernet, this
association is normally a direct mapping, and this is the default
method also specified in both ULE [ID-IPDVB-ULE] and in MPE [ETSI-
DAT].
Address resolution must also occur at the MPEG-2 level (section 4).
The goal of this multicast address resolution is the association of
an IPv4 or IPv6 multicast address with a specific TS Logical Channel
(PID value) and the corresponding TS Multiplex. This association
Expires December 2005 [page 9]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
needs to permit a large number of active multicast groups, and
should minimise the processing load at the Receiver when filtering
and forwarding IP multicast packets (e.g. by distributing the
multicast traffic over a number of TS Logical Channels). For
example, schemes that may exploit hardware filtering can be
beneficial, since these may relieve the drivers and operating
systems from discarding unwanted multicast traffic.
There are specific issues concerning IPv4 and IPv6 multicast over
MPEG-2 Transmission Networks:
(i) Mapping IP multicast groups to the underlying MPEG-2 TS
Logical Channel (PID) and the MPEG-2 TS Multiplex at the
encapsulation gateway.
(ii) Provide signalling information to allow a Receiver to
locate an IP multicast flow within an MPEG-2 TS Multiplex.
Methods are required to identify the scope of an address when an
MPEG-2 transmission network supports several logical IP network and
carries groups within different multicast scopes.
Appropriate procedures need to specify the correct action when the
same multicast group is available on separate TS Logical Channels.
This could arise when different end hosts act as senders to
contribute IP packets with the same IP Group Destination Address in
the ASM address range.
Another different case arises when a Receiver could receive more
than one copy of the same packet (e.g. when packets are replicated
across different TS Logical Channels, or even different TS
Multiplexes, a method known as Simulcasting [DVB-DAT]). At the IP
level, the host/router may be unaware of this duplication and it
needs to be detected by other means.
In some scenarios, a predefined number of IP multicast group
destination addresses may be in use within a MPEG-2 transmission
network. Prior knowledge of the active set of addresses would allow
the source of AR information to construct appropriate AR records for
each address, and pre-assign the corresponding PID value (e.g.,
selected to optimise Receiver processing; to group related addresses
to the same PID value; and/or to reflect a policy for usage of
specific ranges of PID values).
When the MPEG-2 transmission network is peered to the multicast-
enabled Internet, an arbitrarily large number of IP multicast group
destination addresses may be in use and the set forwarded on the
transmission network may be expected to vary significantly with
time. Note that some uses of IP multicast employ a range of
addresses to support a single application (e.g., NDP [RFC2461], LCT
[RFC3451], WEBRC [RFC3738]). The current set of active addresses
Expires December 2005 [page 10]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
may be determined dynamically via a multicast group membership
protocol (e.g., IGMP [RFC3376], MLD [RFC3810]), via multicast
routing (e.g., PIM [RFC2362]) and/or other means (e.g. [RFC3819]),
however each active address requires a binding provided by the AR
method. There are advantages in using a method that does not need to
explicitly advertise AR binding for each IP traffic flow, but is
able to distribute traffic across a number of L2 TS Logical Channels
(e.g., using a hash/mapping that resembles the mapping from IP
addresses to MAC addresses [RFC1112, RFC2464]). Such methods can
reduce the volume of AR information that needs to be distributed,
and reduce the AR processing.
Expires December 2005 [page 11]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
4. MPEG-2 Address Resolution
The first part of this section describes the role of MPEG-2
signalling to identify streams (TS Logical Channels [ID-IPDVB-ARCH])
within the L2 infrastructure.
The MPEG-2 TS in ISO 13818-1 [ISO-MPEG2] identifies the existence
and format of a stream, using a combination of the Programme
Association Table (PAT) and entries in the program element loop of a
Programme Map Table (PMT). These PMT tables are sent infrequently,
and are typically small in size.
In addition to signalling the Receiver with the PID value assigned
to a stream, PMT entries are required to indicate the presence of
streams using ULE and MPE to the variety devices that may operate in
the MPEG-2 transmission network (multiplexers, remultiplexers, rate
shapers, advertisement insertion equipment, etc). The value to be
used to identify streams using the current specification of ULE is
specified in [ID-IPDVB-ULE].
A (re)multiplexor may also change the PID values associated with a
stream during the multiplexing process, the new value being
reflected in an updated PMT. TS Packets that carry a PID value which
is not associated with a PMT entry (an orphan PID), may, and usually
will, be dropped by ISO 13818-1 compliant L2 (re)multiplexors,
resulting in the TS Logical Channel not being forwarded across the
transmission network. In networks that do not employ any
intermediate devices (examples exist in scenarios C,E,F of [ID-
IPDVB-ARCH]), or where devices have other means to determine the set
of PID values in use, the PMT table may still be sent (but is not
required for this purpose).
Although the basic PMT information may be used to identify the
existence of IP traffic, it does not associate a stream with an IP
prefix/address. The remainder of the section describes IP addresses
resolution mechanisms relating to MPEG-2.
4.1 Static configuration.
The static mapping option, where IP addresses or flows are
statically mapped to specific PIDs is the equivalent to signalling
"out-of-band". The application programmer, installing engineer, or
user receives the mapping via some outside means, not in the MPEG-2
TS. This is useful for testing, experimental networks, small
subnetworks and closed domains.
A single "well-known" PID is a specialisation of this. This scheme
is used by current DOCSIS cable modems [DOCSIS], where all IP
traffic is placed into the specified TS stream. Section or MAC
filtering may be used to differentiate subnetworks.
Expires December 2005 [page 12]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
4.1.1 MPEG-2 Cable Networks
Cable networks use a different transmission schemes for downstream,
(headend to cable modem/STB) and upstream (cablemodem/STB to
headend) transmission.
The information is sent (on the downstream) to the STBs as
IP/Ethernet packets encapsulated in MPEG-2 TS Packets sent on a
single well-known TS Logical Channel (PID); there is no use of
inband tables. On the upstream, the common approach is to use
Ethernet framing, rather than IP/Ethernet over MPEG-2, although
other proprietary schemes also continue to be used.
Until the deployment of DOCSIS and EuroDOCSIS, most address
resolution schemes in cable networks for IP traffic were
proprietary, and did not usually employ a table-based address
resolution method. Proprietary methods continue to be used in some
cases where STBs require interaction. In this case, equipment at the
headend may act as gateways between the cablemodem/STB and the
Internet. These gateways receive L2 information and allocate an IP
address.
DOCSIS utilises DHCP for IP client configuration. The Cable Modem
Terminal System (CMTS) provides a DHCP server that allocates IP
addresses to DOCSIS cable modems and STBs. The MPEG-2 Transmission
Network provides a L2 bridged network to the cable modem. This
usually acts as a DHCP relay for IP devices [RFC2131, RFC3256].
Issues in deployment of IPv6 are described in [ID-V6OPS-DEPLOY].
Expires December 2005 [page 13]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
4.2 MPEG-2 Table-Based Address Resolution
The information about the set of MPEG-2 TS streams carried over a TS
Multiplex can be distributed via tables that are assigned a specific
and well-known set of PID values. This design requires access to and
processing of the SI Table information [ETSI-SI, ETSI-SI1]. This
scheme reflects the complexity of delivering and co-ordinating the
various TS associated with multimedia TV. A TS Multiplex may provide
AR information for IP services by integrating additional information
into the existing MPEG-2 tables or by transmitting additional SI
Tables specific to the IP service.
Examples of MPEG-2 Table usage to allow an MPEG-2 Receiver to
identify the appropriate PID and multiplex associated with a
specific IP address include:
(i) IP/MAC Notification Table (INT) in the DVB Data standard
[ETSI-DAT]. This provides uni-directional address resolution of
IPv4/IPv6 multicast addresses to MPEG-2 TS.
(ii) Application Information Table (AIT) in the Multimedia
Home Platform (MHP) specifications [ETSI-MHP].
(iii)Multicast Mapping Table (MMT) an MPEG-2 Table employed by some
DVB-RCS systems to provide uni-directional address resolution
of IPv4 multicast addresses to MPEG-2 TS.
The MMT and AIT are used for specific applications. The INT [DVB-
DAT] is a more general DVB method, that supports MAC, IPv4, and IPv6
AR when used in combination with the other MPEG-2 tables (see
section 4).
4.2.1 IP/MAC Notification Table (INT) and its usage
The INT provides a method for carrying information about the
location of IP/L2 flows within a DVB network. A Platform_ID,
identifies the addressing scope for a set of IP/L2 streams and/or
Receivers. A Platform may span several transport streams within one
or multiple TS multiplexes and represents a single IP network with a
harmonized address space (scope). This allows for the coexistence of
several non-harmonized IP/MAC address spaces on the same MPEG-2
transmission network.
The INT allows both fully-specified IP addresses and prefix
matching, to reduce the size of table (and hence enhance signalling
efficiency). An IPv4/IPv6 "subnet mask" may be given in full form or
in slash notation (e.g. /127). IP multicast addresses can be
specified with or without a source (address or range), although if a
source address is specified, then only the slash notation may be
used for prefixes.
Expires December 2005 [page 14]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
In addition to identification and security descriptors, the
following descriptors are defined for address binding in INT tables:
(i) target_MAC_address_descriptor: The descriptor used to
describe a single or set of MAC addresses (and their mask).
(ii) target_MAC_address_range_descriptor: May be used to set
filters.
(iii)target_IP_address_descriptor: The descriptor describing a
single or set of IPv4 unicast or multicast addresses (and
their mask).
(iv) target_IP_slash_descriptor: Allows definition and announcement
of an IPv4 prefix.
(v) target_IP_source_slash_descriptor: Uses source and destination
addresses to target a single or set of systems.
(vi) IP/MAC stream_location_descriptor: This descriptor locates an
IP/MAC stream in a DVB network.
The following descriptors provide corresponding functions for IPv6
addresses:
target_IPv6_address_descriptor
target_IPv6_slash_descriptor
and target_IPv6_source_slash_descriptor
The ISP_access_mode_descriptor allows specification of a second
address descriptor to access an ISP via an alternative non-DVB
(possibly non-IP) network.
The INT provides a set of descriptors to specify addressing in a DVB
network. One key benefit is that the approach follows the MPEG-2
signalling methods and is integrated with the other signalling
information. This allows the INT to operate in the presence of
(re)multiplexors [ID-IPDVB-ARCH] and refer to PID values that are
carried within a number of different TS Multiplexes. This makes it
well-suited to a Broadcast TV Scenario [ID-IPDVB-ARCH].
The principle drawback is a need for a Gateway to introduce
associated PSI/SI MPEG-2 control information. This control
information also needs to be processed at a Receiver, and requires
access to information below the IP layer. The position of this
processing within the protocol stack makes it hard to associate the
results with IP Policy, management and security functions. The use
of centralized management prevents the implementation of a more
dynamic scheme. The method is currently defined only for Multi-
Protocol Encapsulation (MPE) and would need extension to support
other schemes (e.g. ULE).
Expires December 2005 [page 15]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
4.2.2 Multicast Mapping Table (MMT) and its usage
The Multicast Mapping Table (MMT) is an MPEG-2 level control table
that associates a set of multicast addresses with the corresponding
PID values. This table allows a DVB-RCS Forward Link Subsystem
(FLSS) to specify the mapping of IPv4 addresses to PID values within
a specific TS Multiplex. Receivers (DVB-RCS Return Channel Satellite
Terminals, RCSTs) may use this table to determine the PID values
associated with an IP multicast flow that it requires to receive.
The MMT is not currently a part of the DVB-RCS specification.
4.2.3 Application Information Table (AIT) and its usage
The DVB Multimedia Home Platform (MHP) specification does not define
a specific AR function. However, an Application Information Table
(AIT) is defined that allows MHP Receivers to receive a variety of
control information. The AIT uses a DSMCC format table providing
information about data broadcasts, the required activation state of
applications carried by a broadcast stream, etc. This information
allows a broadcaster to request that a Receiver change the
activation state of an application, and to direct applications to
receive specific multicast packet flows (using IPv4 or IPv6
descriptors). In MHP, AR is not seen as a specific function, but as
a part of a wider configuration and control function.
4.2.4 Comparison of SI/PSI table approaches
The MPEG-2 methods based on SI/PSI meet the specified requirements
of the groups that created them and all have their strength: the
INT in terms of flexibility and extensibility, the MMT in its
simplicity, the AIT in its extensibility. However, they exhibit
scalability constraints, represent technology specific solutions and
do not fully adopt IP-centric approaches that would enable easier
use of the MPEG-2 bearer as a link technology within the wider
Internet.
4.3 IP-based resolution of TS Logical Channels
As MPEG-2 transmission networks evolve to become multiservice
networks, the use of IP protocols is becoming more prevalent.
Most MPEG-2 networks now use some IP protocols for operations,
control and data delivery, transmission using IP packets could
also be used for address resolution. The advantages of using a
IP-based address resolution for TS streams include:
Expires December 2005 [page 16]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
(i) Simplicity:
The AR mechanism does not require interpretation of Layer 2
tables; this is an advantage especially in the growing market
share for home network and audio video networked entities.
(ii) Uniformity:
An IP-based protocol can provide a common method across
different network scenarios for IP/MAC address mappings to TS
Logical Channels (PID Values).
(iii) Extensibility:
IP-based AR mechanisms allow an independent evolution of the AR
protocol. This includes dynamic methods to request address
resolution and the ability to include other L2 information
(e.g. Encryption keys).
(iv) Integration
The information exchanged by IP-based AR protocols can easily
be integrated as a a part of the IP network layer, simplifying
support for AAA, policy, OAM, mobility, configuration control,
etc. that combine AR with security.
Drawbacks of an IP-based method include:
One drawback of IP-based AR is that it can not operate over an
MPEG-2 Transmission Network that uses MPEG-2 remultiplexors
[ID-IPDVB-ARCH] to modify the PID values of the TS Logical
Channels during the multiplexing operation. This makes the
method unsuitable for use in deployed broadcast TV networks
[ID-IPDVB-ARCH].
IP-based methods can also introduce concerns about the
integrity of the information and authentication of the sender
[ID-IPDVB-ARCH]. (These concerns are also applicable to MPEG-2
table methods, but in this case the information is confined to
the L2 network, or parts of the network where gateway devices
isolate the MPEG-2 devices from the larger Internet creating
virtual MPEG-2 private networks.) IP-based solutions should
therefore implement security mechanisms that may be used to
authenticate the sender and verify the integrity of the AR
information, as a part of a larger security framework.
4.3.1 IP-based multicast resolution of TS Logical Channels
AR resolution must also be performed to associate the IP multicast
Group Destination Address with an MPEG-2 layer TS Logical Channel
(PID) and TS Multiplex. Solutions have been described in 4.2 that
perform this below the IP layer using MPEG-2 Tables. Such methods
currently perform a direct mapping (where a single address or set of
addresses are associated with a specific PID value).
Expires December 2005 [page 17]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
There is an opportunity to define an IP-level method that could use
an IP multicast protocol over a well-known IP multicast address.
Scalability is an important feature of any multicast AR protocol,
methods that employ prefix matching (e.g. where a range of
source/destination addresses are matched to a single entry are
desirable), but so also are methods that allow a range of addresses
to mapped to a set of TS Logical Channels (similar to the mapping of
IP Group Destination Addresses to Ethernet MAC addresses).
Expires December 2005 [page 18]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
5. Mapping IP addresses to NPA/MAC addresses
This section reviews IETF protocols that may be used to assign and
manage the mapping of IP addresses to/from NPA/MAC addresses over
MPEG-2 networks.
IP Encapsulation Gateways may require AR information to select an
appropriate MAC/NPA address in the SNDU header [ID-IPDVB-ARCH] (see
also section 6). The information to complete this header may be
taken directly from a neighbour/arp cache, or may require the
Gateway to retrieve the information using an AR protocol. The way in
which this information is collected will depend upon whether the
Gateway functions as a Router (at L3) or a Bridge (at L2).
Two IETF-defined protocols for mapping IP addresses to NPA/MAC
addresses are ARP [RFC-ARP] and NDP [RFC2461] for IPv4 and IPv6
respectively. Both protocols are normally used in a bi-directional
mode, although both also permit unsolicited transmission of
mappings. The mapping defined in [RFC2464] may result in use of a
large number of L2 MAC addresses.
ARP requires support for L2 broadcast packets.
<< inputs requested on ARP scalability to large Receiver groups >>
<< inputs requested on ARP security for wireless networks >>
<< inputs requested on ARP scoping when supporting multiple ISPs >>
The NDP uses a set of IP multicast addresses. In large networks,
many multicast addresses are likely to be used, although little
traffic is likely to be sent in each group. The AR multicast
mechanism therefore needs to be able to support this in a scalable
manner.
<< inputs requested on NDP scalability to large Receiver groups >>
<< inputs requested on NDP security for wireless networks >>
<< inputs requested on NDP scoping when supporting multiple ISPs >>
DHCP [RFC2131] may also be used over MPEG-2 transmission networks.
DHCP consists of two components: a protocol for delivering host-
specific configuration parameters from a DHCP server to a host
(default gateway, DNS server) and a mechanism for allocation of
network addresses to hosts. DHCP defines a set of transactions
between a DHCP server and a DHCP client to afford/request a valid
network address, configuration parameters or both. These
transactions are constructed by DHCP messages defined in RFC2131
Expires December 2005 [page 19]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
(DHCPDISCOVER, DHCPREQUEST, DHCPOFFER) that could include DHCP
options defined in RFC2132.
5.1 Uni-directional links supporting uni-directional connectivity
MPEG-2 Transmission Networks may provide a Uni-Directional broadcast
Link (UDL), with no return path. Such links may be used for unicast
applications that do not require a return path (e.g. based on UDP),
but are more commonly used for IP multicast content distribution.
,-----.
MPEG-2 uplink /MPEG-2 \
*##################( Network )
# \ /
+----*------+ `--.--'
| Network | |
| Provider + v MPEG-2 downlink
+-----------+ |
+-----v------+
| MPEG-2 |
| Receiver |
+------------+
Figure XX: Uni-directional connectivity
Although ARP and NDP may both operate in an unsolicited/promiscuous
mode where they advertise information to the remote nodes, this does
not provide an appropriate method to resolve the remote
(destination) address in a uni-directional environment. To perform
this task, these protocols require bi-directional L2/L3
connectivity.
<< inputs required on Receiver address assignment in this case >>
5.2 Uni-directional links with bi-directional connectivity
Bi-directional connectivity may be realised using a pair of uni-
directional in combination with another network path. Common
combinations are a Feed link using MPEG-2 satellite transmission and
a return link using terrestrial network infrastructure. This
topology is often known as a Hybrid network, and has asymmetric
network routing. It also often exhibits asymmetric network capacity
[RFC-ASYM].
Expires December 2005 [page 20]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
,-----.
MPEG-2 uplink /MPEG-2 \
*##################( Network )
# \ /
+----*------+ `--.--'
| Network | |
| Provider +-<-+ v MPEG-2 downlink
+-----------+ | |
| +-----v------+
+--<<--+ MPEG-2 |
uplink | Receiver |
+------------+
Figure XX: Bi-directional connectivity
The Uni-Directional Link Routing, UDLR [RFC3077] protocol may be
used to overcome the routing issues associated with asymmetric
routing. UDLR provides a L2 tunnelling mechanism that emulates a bi-
directional broadcast link at L2. That is a network using UDLR has a
topology in which the Feed and all Receivers form a logical Local
Area Network. Encapsulating layer-two frames allow them to be sent
in unicast and broadcast through Internet and UDL. The uni-
directional routing is hidden from IP and upper layer protocols.
Since many uni-directional links employ wireless technology for the
forward (Feed) link (e.g., [ETSI-DAT]), there may be an appreciable
cost associated with forwarding traffic on the Feed link. This leads
to a desire to prevent forwarding unnecessary traffic, (e.g. for
multicast this implies control which groups are forwarded). The
implications of forwarding on the return link must also be
considered (e.g., asymmetric links, and asymmetric loss
environment), suggest a need to minimise the volume and frequency of
control messages.
The remainder of this section introduces how UDLR link-layer
tunnelling mechanisms may use ARP and ND on Uni-Directional DVB
links. Three different AR cases may be identified when a UDL Feed
serves a number of Receivers:
i) Case 1: A Feed needs a Receiver NPA/MAC address.
This occurs when a Feed must send an IP packet to a Receiver whose
NPA/MAC address is unknown. In IPv4, a Feed sends an ARP REQUEST
over the UDL with the IP address of the Receiver. The Receiver that
recognises its IP address replies with an ARP RESPONSE to the
NPA/MAC address of the Feed (e.g. using a UDLR tunnel). The Feed may
then address IP packets to the unicast NPA/MAC address associated
with the Receiver. (The ULE packet format permits packets to be sent
without specifying a NPA/MAC address, in cases were this is
desirable.)
Expires December 2005 [page 21]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
ii) Case 2: A Receiver needs the Feed NPA/MAC address.
This occurs when a Receiver must send an IP packet to a Feed whose
NPA/MAC address is unknown. In IPv4, the Receiver sends an ARP
REQUEST with the IP address of the Feed (e.g. using a UDLR tunnel).
The Feed replies with an ARP RESPONSE. The Receiver may then address
IP packets to the NPA/MAC address of the recipient.
iii) Case 3: A Receiver needs another Receiver NPA/MAC address.
This occurs when a Receiver must send an IP packet to a Receiver
whose NPA/MAC address is unknown. In IPv4, the Receiver sends an ARP
REQUEST with the IP address of the remote Receiver (e.g. using a
UDLR tunnel). The Feed forwards this on the UDL. The target
Receiver replies with an ARP RESPONSE (e.g. using a UDLR tunnel to
the Feed). The Feed forwards the response on the UDL. The Receiver
may then address IP packets to the NPA/MAC address of the recipient.
These 3 cases allow any node connected to the UDL to obtain the MAC
address of any other node.
A long round trip (via the UDL and UDLR tunnel) impacts the
performance of reactive address resolution procedures. In contrast
to Ethernet, during the interval when resolution is taking place,
many IP packets may be received addressed to the Target address,
these may be discarded. An appropriately sized buffer may prevent
this loss. The time to complete address resolution may also be
reduced by use of an AR server at the Feed, which may learn MAC
addresses from ARP RESPONSES and would (proxy) publish them in
response to Receiver ARP REQUESTS.
Using DHCP with UDLR requires prior establishment of the L2
connectivity to a DHCP server. Therefore, when UDLR networks use
DHCP, the DTCP HELLO message periodicity may need to be tuned to
effectively support DHCP.
Appropriate configuration of the DHCP lease duration and address
pool width, are also required based on the expected round trip time.
The configuration of DHCP servers and clients should also take into
account this delay when assigning timer values: DHCP messages
retransmission timeout, maximum delay that a DHCP server waits
before deciding that the absence of an ICMP echo response means that
the relevant address is free.
DHCP clients may also retransmit DHCP messages if they do not
receive a response. Some client implementations specify a timeout
for the DHCPDISCOVER message that is small (e.g. suited to Ethernet
delay) providing insufficient time for a DHCP server to respond to
DHCPDISCOVER retransmission before expiry of the check on the lease
availability (by an ICMP echo request), resulting in potential
address conflict.
Expires December 2005 [page 22]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
5.3 Bi-directional links
Bi-directional IP networks can be and are constructed by a
combination of two MPEG-2 transmission links. The combined link
functions as a full duplex interface. Examples of this use include
two-way DVB-S satellite links and the DVB-RCS system.
<<< text on DHCP, L2TP, PPoE, etc to be added by
other volunteers >>>
5.4 IP Multicast AR
This section describes the case where the destination network layer
address is an IP multicast Group Destination Address.
In MPE [DVB-DAT], the mapping of IP multicast addresses to MAC/NPA
addresses follows normal practice for IEEE MAC Addresses when using
IPv4 and IPv6. (A variant of DVB (DVB-H) uses a modified MAC header
[DVB_DAT]).
In ULE [ID-IPDVB-ULE], the L2 NPA address is optional, and is not
necessarily required when the Receiver is able to perform efficient
L3 multicast address filtering. When present, it follows the mapping
of MPE and many other L2 link technologies.
Expires December 2005 [page 23]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
6. Link Layer Support
This section considers layer 2 (L2) support for address resolution.
It considers two issues that need to be considered. One is the code-
point to be used at L2 and the other is the efficiency of
encapsulation for transmission to utilise the AR method. The table
below summarises the options for both MPE [ETSI-DAT] and ULE [ID-
IPDVB-ULE] encapsulations.
+-------------------------------+--------+----------------------+
| | PDU |L2 Frame Header Fields|
| L2 Encapsulation |overhead+----------------------+
| |[bytes] |src mac|dst mac| type |
+-------------------------------+--------+-------+-------+------+
|6.1 ULE without dst MAC address| 8 | - | - | x |
|6.2 ULE with dst MAC address | 14 | - | x | x |
|6.3 MPE without LLC/SNAP | 16 | - | x | - |
|6.4 MPE with LLC/SNAP | 24 | - | x | x |
|6.5 ULE with Bridging extension| 22 | x | x | x |
|6.6 ULE with Bridging & NPA | 28 | x | x | x |
|6.7 MPE+LLC/SNAP+Bridging | 38 | x | x | x |
+-------------------------------+--------+-------+-------+------+
Table of L2 support and overhead (x=supported, -=not supported)
The remainder of the section describes IETF-specified AR methods for
use with these encapsulation formats.
6.1 ULE without a destination MAC/NPA address (D=1)
The ULE encapsulation supports a mode (D=1) where the NPA/MAC
address is not present in the encapsulated frame. This mode may be
used with both IPv4 and IPv6. When this mode is used, the Receiver
is expected to perform network-layer filtering of packets based on
their IP destination address. Encapsulation Gateways must ensure
that packets are associated with a TS Logical Channel (PID value)
that uniquely identifies the intended recipient [ID-IPDVB-ULE]. This
requires careful consideration of the network topology when used as
a link between IP routers (a simple case where this is permitted is
the connection of stub networks).
Since there is no MAC/NPA address in the SNDU, ARP and NDP are not
required.
Note, since IPv6 systems can (and usually do) automatically
configure their IPv6 network address based upon a local MAC address,
the IP driver at the Receiver may still need to access the MAC/NPA
address of the receiving interface.
Expires December 2005 [page 24]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
6.2 ULE with a destination NPA/MAC address (D=0)
The IPv4 Address Resolution Protocol (ARP) [RFC826] uses an IANA-
assigned EtherType and may be used over a link that supports ULE
[IP-IPDVB-ULE]. Although no MAC source address is present in the ULE
SNDU, the ARP protocol still communicates the source MAC address in
the ARP record payload of any query messages that it generates.
The ND protocol of IPv6 [RFC2461] may be used. The protocol uses a
block of IPv6 addresses, which need to be carried by the L2 network.
NDP does not require specification of a MAC source address, although
this is required for a node to participate in Duplicate Address
Detection (DAD) [RFC2462].
<< More info on use of ND is required, also on usage of DAD and
SEND>>
6.3 MPE without LLC/SNAP Encapsulation
This is the default (and sometimes only) mode specified by most MPE
Encapsulation Gateways.
MPE does not provide an IANA-assigned EtherType and therefore can
not support the Address Resolution Protocol (ARP) [RFC826].
IPv6 is not supported in this encapsulation format, and therefore it
is not appropriate to consider the NDP.
6.4 MPE with LLC/SNAP Encapsulation
The LLC/SNAP format of MPE provides an IANA-assigned EtherType and
therefore may support the Address Resolution Protocol (ARP)
[RFC826]. There is no specification to define how this is performed.
No MAC source address is present in the SNDU, although the protocol
still communicates the source MAC address in the ARP record payload
of any query messages that it generates.
The ND protocol of IPv6 [RFC2461] may be used with The LLC/SNAP
format of MPE. The protocol uses a block of IPv6 addresses, which
need to be carried by the L2 network. It does not require
specification of a MAC source address, although this is required for
a node to participate in Duplicate Address Detection (DAD).
<< More info on use of ND is required, also on usage of DAD and
SEND>>
6.5 ULE with Bridging Header Extension (D=1)
Expires December 2005 [page 25]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
The ULE encapsulation supports a bridging extension header that
supplies both a source and destination MAC address. This can be
used without an NPA address (D=1). When no other Extension Headers
are present, the MAC destination address has the same position in
the ULE SNDU as that used for an NPA destination address. The
Receiver may optionally be configured so that MAC destination
address value is identical to the Receiver NPA address.
At the Encapsulation Gateway, the ULE NPA/MAC destination address is
determined by a L2 forwarding decision. Received frames may be
forwarded or may be addressed to the Receiver itself. As in other L2
LANs, the Receiver may choose to filter received frames based on a
configured MAC destination address filter.
ARP messages may be carried within a PDU that is bridged by this
encapsulation format.
The NDP messages may be carried within an IPv6 PDU that is bridged
by this encapsulation format.
6.6 ULE with Bridging Header Extension and NPA Address (D=0)
The combination of a NPA address (D=0) and a bridging extension
header are allowed in ULE. This SNDU format supplies both a source
and destination MAC address and a NPA destination address (i.e.
Receiver NPA/MAC address).
At the Encapsulation Gateway, the ULE NPA/MAC destination address is
determined by a L2 forwarding decision. Received frames may be
forwarded or may be addressed to the Receiver itself. As in other L2
LANs, the Receiver may choose to filter received frames based on a
configured MAC destination address filter.
An ARP message may be carried within a PDU that is bridged by this
encapsulation format.
An NDP message may be carried within an IPv6 PDU that is bridged by
this encapsulation format.
6.7 MPE+LLC/SNAP+Bridging
The LLC/SNAP format MPE frames may optionally support an IEEE
bridging header [LLC]. This header supplies both a source and
destination MAC address, at the expense of larger encapsulation
overhead. This format defines two MAC destination addresses, one
associated with the MPE SNDU (i.e. Receiver MAC address) and one
with the bridged MAC frame (i.e. the MAC address of the intended
recipient in the remote LAN). At the Encapsulation Gateway, the MPE
MAC destination address is determined by a L2 forwarding decision.
Expires December 2005 [page 26]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
As in other L2 LANs, the Receiver may choose to filter received
frames based on a configured MAC destination address filter.
At the Encapsulation Gateway, the MPE MAC destination address is
determined by a L2 forwarding decision. Received frames may be
forwarded or may be addressed to the Receiver itself. As in other L2
LANs, the Receiver may choose to filter received frames based on a
configured MAC destination address filter.
An ARP message may be carried within a PDU that is bridged by this
encapsulation format.
An NDP message may be carried within an IPv6 PDU that is bridged by
this encapsulation format. The MPE MAC destination address is
determined by a L2 forwarding decision.
Expires December 2005 [page 27]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
7. Conclusions
This document has described addressing and address resolution issues
concerning the use of IP protocols over MPEG-2 transmission
networks. A number of specific IETF protocols are discussed along
with their expected behaviour over MPEG-2 transmission networks.
Recommendations for their usage are provided.
In MPEG-2 networks, a static binding can be configured for IP
addresses and PIDs (as in some cable networks). In broadcast
networks, this information is normally provided by the
Gateway/Multiplexor and carried in tables (e.g. AIT in MHP, the IP
Notification Table, INT, of DVB and the DVB-RCS Multicast Mapping
Table, MMT). This document has reviewed the status of these current
address resolution mechanisms in MPEG-2 transmission networks,
defined their usage and provided information to identify what would
be needed to improve their support for IP protocols.
8. Security Considerations
The normal security issues relating to the use of wireless links for
transport Internet traffic should be considered. It is recommended
that future AR protocols support authentication of the source of AR
messages and the integrity of the AR information, this avoids known
security vulnerabilities resulting from insertion of unauthorised AR
messages within a L2 infrastructure. Readers are also referred to
the known security issues associated with ARP [RFC826] and NDP
[RFC2461].
9. Acknowledgments
The authors wish to thank Rod Walsh, Jun Takei, Michael Mercurio and
the ipdvb WG members for their inputs. The authors would also like
to acknowledge the support of the European Space Agency. The authors
also thank Martin Stiemerling, for contributions of scenarios and
configuration, and Hidetaka Izumiyama for his contributions on UDLR
and IPv6 issues. A number of issues discussed in the UDLR working
group (summarised in draft-ietf-udlr-experiments-01.txt) have also
provided valuable inputs to this document.
Expires December 2005 [page 28]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
10. References
10.1 Normative References
[ETSI-DAT] EN 301 192, "Specifications for Data
Broadcasting", v1.3.1, European Telecommunications Standards
Institute (ETSI), May 2003. http://www.etsi/org/
[ETSI-MHP] ETSI TS 101 812, "Digital Video Broadcasting (DVB);
Multimedia Home Platform (MHP) Specification", v1.2.1, European
Telecommunications Standards Institute (ETSI), June 2002.
http://www.etsi/org/
[ETSI-SI] ETSI EN 300 468: "Digital Video Broadcasting (DVB);
Specification for Service Information (SI) in DVB systems".
[ISO-DSMCC] ISO/IEC IS 13818-6 "Information technology -- Generic
coding of moving pictures and associated audio information -- Part
6: Extensions for DSM-CC is a full software implementation",
International Standards Organisation (ISO).
[ISO-MPEG2] ISO/IEC IS 13818-1 "Information technology -- Generic
coding of moving pictures and associated audio information -- Part
1: Systems", International Standards Organisation (ISO), 2000.
[RFC826] Plummer, D. "An Ethernet Address Resolution Protocol",
RFC 826, IETF, November 1982.
[RFC1112] Deering, S.E., "Host Extensions for IP Multicasting",
RFC1112, (STD05), IETF. August 1989.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6), RFC 2461, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y.
Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links",
RFC 3077, March 2001.
10.2 Informative References
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53C, 2004.
[DOCSIS]>>> Missing Reference <<<
Expires December 2005 [page 29]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
[ETSI-SI1] ETSI TR 101 162: "Digital Video Broadcasting (DVB);
Allocation of Service Information (SI) codes for DVB systems".
[ID-IPDVB-ARCH] Montpetit, M.J., Fairhurst, G., Clausen, H.D.,
Collini-Nocker, B., and H. Linder, "Architecture for IP transport
over MPEG-2 Networks", Internet Draft, draft-ipdvb-arch-00.txt,
February 2005, Work in Progress, IPDVB WG.
[ID-IPDVB-ULE] Fairhurst, G., Collini-Nocker, B. "Ultra Lightweight
Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2
Transport Stream", February 2005, Work in Progress, IPDVB WG.
[ID-V6OPS-DEPLOY] Asadullah, S., Ahmed, A., Popoviciu, C.,
"ISP IPv6 Deployment Scenarios in Broadband Access Networks"
draft-ietf-v6ops-bb-deployment-scenarios-00.txt, Work in Progress,
v6ops WG
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D.,
Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", RFC
3376, October 2002.
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley,
M., and J. Crowcroft, "Layered Coding Transport (LCT) Building
Block", RFC 3451, December 2002.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3256] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable
Service Interface Specifications) Device Class DHCP (Dynamic Host
Configuration Protocol) Relay Agent Information Sub-option", RFC
3256, April 2002.
[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.
Expires December 2005 [page 30]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
10.3 Un-cited references (to be used or removed in final edit):
[RFC1122] B. Braden, ed., "Requirements for Internet Hosts -
Communication Layers", RFC 1122.
[ATSC-REG] http://www.atsc.org/standards/Code_Point_Registry.pdf
[ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.
Schulzrinne, "Protocol Requirements for Internet Media Guides",
Internet Draft, draft-ietf-mmusic-img-req-07.txt, June 2004, Work
in Progress, MMUSIC WG.
[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.
[ETSI-DAT1] EN 101 202, "Implementation Guide for Data", v1.2.1,
European Telecommunications Standards Institute (ETSI), May 2003.
http://www.etsi/org/
11. Authors' Addresses
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
Marie-Jose Montpetit
MJMontpetit.com
Email: marie@mjmontpetit.com
Expires December 2005 [page 31]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
12. IPR Notices
12.1 Intellectual Property Statement
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; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to 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.
12.2 Disclaimer of Validity
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.
13. 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.
14. IANA Considerations
This document does not define a protocol or protocol extension. No
action is required by the IANA.
Expires December 2005 [page 32]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
APPENDICES
[>>> NOTE to RFC Editor: Please remove this appendix prior to
publication]
APPENDIX A: Document History
-00 This draft is intended as a study item for proposed future
work by the IETF in this area.
-01 Review of initial content, major edit and refinement of
concepts
-02 fairly important review; took out all new protocol reference;
added one author; added contribution on real implementation
-02 Added content to respond to 61st IETF comments;
refined ID goals; rewrote section 4.2 and 4.3; added cable
information.
-03 Major reorganise to align with Charter, and clearly identify
IP issues.
-04 restructured the draft (major rewrite) and added discussion of
arp and ND related to specific cases for use.
WG -00
Reformatted as WG Draft.
Added inputs from UDLR working group on UDLR, DHCP, etc.
WG-01
This rev. included a number of changes:
* Added the case for large no. of groups/dynamic join to 3.2
* ISO MPEG-2 table requirements added to section 4, following
discussion on the list.
* Security vulnerabilities of ARP:
<< inputs requested on ARP security for wireless networks >>
- do you know of any text motivating the work on SEND?
* Scoping problems of ARP:
<< inputs requested on ARP scoping when supporting multiple ISPs
>>
- do you know any text about L2 VPNs and address leakage, etc?
* Reference for DOCSIS to be resolved - [DOCSIS]
* Added AR Authentication note to security considerations.
[>>> NOTE to RFC Editor: End of appendix]
Expires December 2005 [page 33]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
Expires December 2005 [page 34]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
APPENDIX B: Candidate IP-based L2 AR Protocols
This appendix contains a list of candidate protocols for "above IP"
AR. None of these protocols currently support the AR methods
required for MPEG-2 Transmission Networks. Specifically they do not
all support:
(i) Resolution of Addresses to TS Logical Channels
(ii) Resolution of multiple addresses in a single AR update message
(table-based).
(iii) Multicast transport.
Candidate protocols include:
ARP <extension required>
- IPv4 only.
- No table support <could be added>
- Support for versioning within current implementations not clear.
- Broadcast mode has drawbacks.
- No obvious support for scoping to multiple addressing domains.
ND <extension required>
- IPv6 only.
- No table support <could be added>
- Use multicast address.
- No obvious support for scoping to multiple addressing domains.
DTCP [RFC3077] <extension required>
- IPv4 and IPv6.
- Table support seems natural.
- Uses multicast address.
- Need to consider scoping for multiple addressing domains.
- Not really an IP AR protocol
- Already used on some (UDLR) links - and this new use seems
complementary.
AR/IP <new protocol required>
- IPv4 and IPv6.
- Based on UDP or at network-layer.
- Could use multicast address.
- Table support possible.
- New protocol format.
- Could add scoping for multiple addressing domains.
XML/foo/IP <new protocol required>
- IPv4 and IPv6.
- Based on UDP or at network-layer or an XML transport (which?).
- Could use multicast address.
- Table support seems natural.
- New protocol format.
- Could add scoping for multiple addressing domains.
- Extensible/flexible to other configuration data (if required).
Expires December 2005 [page 35]
INTERNET DRAFT AR for IP over MPEG-2 networks Sept 2005
- Compression of XML required to achieve efficiency comparable with
other methods.
<<<<
Expires December 2005 [page 36]
