Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen
Document: draft-ietf-ipdvb-ar-03.txt Marie-Jose Montpetit
Motorola Connected
Home Solutions
Category: Draft April 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) value 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
the ND protocol, and provides guidance on usage.
Expires October 2006 [page 1]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
Table of Contents
1. Introduction
1.1 Bridging and Routing
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 Address Resolution in ATSC
4.2.5 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 MAC/NPA 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 AR Server
5.5 DHCP Tuning
5.6 IP Multicast AR
6. Link Layer Support
6.1 ULE without a destination MAC/NPA address (D=1)
6.2 ULE with a destination MAC/NPA 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
Appendix
Expires October 2006 [page 2]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
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 [RFC4259], defined
in specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer-2 (L2)
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 in the form of System
Information (SI) Tables [ETSI-SI, ETSI-SI1], or Program Specific
Information (PSI) Tables.
To utilize the MPEG-2 TS as an Layer-2 (L3) 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 an Address Resolution (AR) function. In
some AR schemes, the MPEG-2 TS address space is sub-divided into
logical contexts known as Platforms [ETSI-DAT]. 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)
[RFC4259] to uniquely identify a L2 node within an 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
could signal the format of the data being transmitted, for example,
the encapsulation, any L2 encryption method and any compression
scheme [RFC4259].
The numbers of Receivers connected via a single MPEG-2 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 by address resolution protocols that use this
service.
1.1 Bridging and Routing
The following two figures illustrate the use of AR for a routed and
bridged subnetwork. Various other combinations of L2 and L3
forwarding may also be used over MPEG-2 links (including Receivers
Expires October 2006 [page 3]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
that are IP end hosts and end hosts directly connected to bridged
LAN segments).
Broadcast Link AR
- - - - - - - - -
| |
\/
1a 2b 2a
+--------+ +--------+
----+ R1 +----------+---+ R2 +----
+--------+ MPEG-2 | +--------+
Link |
| +--------+
+---+ R3 +----
| +--------+
|
| +--------+
+---+ R4 +----
| +--------+
|
|
Figure 1: A routed MPEG-2 link feeding 3 downstream routers (R2-R4).
AR takes place at the Encapsulator (R1) to identify the each
Receiver at L2 within the IP subnetwork (R2, etc).
When considering unicast communication from R1 to R2, several L2
addresses are involved:
1a is the L2 interface address of R1 on the link
2b is the L2 interface address of R2 on the link
2a is the L2 interface address of R2 on the next hop link
AR for the MPEG-2 link allows R1 to determine the L2 address (2b)
corresponding to the next hop Receiver, router R2.
Figure 2 shows a bridged topology. The Encapsulator associates a
destination MAC/NPA address with each bridged PDU sent on an MPEG-2
link. Two methods are defined by ULE [RFC4326]:
The simplest method uses the L2 address of the frame being
transmitted. This address is the MAC/NPA address corresponding to
the destination within the L2 subnetwork (the next hop router, 2b of
R2). This requires each Receiver (B4) to associate the receiving
MPEG-2 interface with the set of MAC/NPA addresses that exist on the
L2 subnetworks that it feeds. Similar considerations apply when IP-
based tunnels support L1/L2 services (including the use of UDLR
[RFC3077]).
It is also possible for a bridging Encapsulator (B1) to encapsulate
a PDU with a link-specific header that contains the MAC/NPA address
associated with a Receiver L2 interface. In this case, the
Expires October 2006 [page 4]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
destination MAC/NPA address of the encapsulated frame is set to the
Receiver MAC/NPA address (y), rather than the address of the final
L2 destination. At a different level, an AR binding is also required
for R1 to associate the destination L2 address 2b with R2. In a
subnetwork using bridging, the systems R1, R2 will normally use
standard IETF-defined AR mechanisms (e.g. ARP [RFC826], ND [RFC2461)
edge-to-edge across the IP subnetwork.
Subnetwork AR
- - - - - - - - - - - - - - - -
| |
| MPEG-2 Link AR |
- - - - - - - - -
| | | |
\/ \/
1a x y 2b 2a
+--------+ +----+ +----+ +--------+
----+ R1 +--| B1 +----------+---+ B2 +--+ R2 +----
+--------+ +----+ MPEG-2 | +----+ +--------+
Link |
| +----+
+---+ B3 +--
| +----+
|
| +----+
+---+ B4 +--
| +----+
|
Figure 2: A bridged MPEG-2 link feeding 3 downstream bridges (B2-
B4). AR takes place at the Encapsulator (B1) to identify each
Receiver at L2 (B2-B4). AR also takes place across the IP subnetwork
allowing the feed router (R1) to identify the downstream Routers at
L2 (R2, etc).
Methods also exist to assign IP addresses to Receivers within a
network (e.g. DHCP [RFC2131], DHC [RFC3736]). Receivers may also
participate in remote configuration of the L3 IP addresses used in
connected equipment (e.g. using DHCP-Relay [RFC3046]).
The remainder of the document describes current mechanisms and their
use to associate an IP address with the corresponding TS Multiplex,
PID value, the MAC/NPA address and/or Platform ID. A range of
approaches is described, including Layer-2 methods (using MPEG-2 SI
tables), and protocols at the IP level (including the IPv4 Address
Resolution Protocol, ARP [RFC826] and the IPv6 Neighbor Discovery
Protocol, ND [RFC2461]). Interactions and dependencies between
these methods and the encapsulation methods are described.
Expires October 2006 [page 5]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
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 [ISO-MPEG].
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 carried 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.
Feed Router: The router delivering the IP service over a
Unidirectional Link.
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).
MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia
receiver, that may (in some cases) support IPv4/IPv6 services [ETSI-
MHP].
MMT: Multicast Mapping Table (proprietary extension to DVB-RCS
[ETSI-RCS] defining an AR table that maps IPv4 multicast addresses
to PID values).
MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT; ATSC-DATG]. A
Expires October 2006 [page 6]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
method that encapsulates PDUs, forming a DSM-CC Table Section. Each
Section is sent in a series of TS Packets using a single Stream (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/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 [RFC4259].
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. The table is sent using the well-known PID value of
0x000, and is required for an MPEG-2 compliant Transport Stream.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
IPv4 or IPv6 Datagrams, and other network packets.
PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the
header of each TS Packet. This identifies the TS Logical Channel to
which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the
parts of a Table Section, 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 used to send the PMT
for a specific program is defined by an entry in the PAT.
Private Section: A syntactic structure constructed according to
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
Expires October 2006 [page 7]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
network-layer service (or bridging module when operating at the
link-layer).
SI Table: Service Information Table [ISO-MPEG2]. In this document,
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.
STB: Set-Top Box. A consumer equipment (Receiver) for reception of
digital TV services.
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.
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 signaling.
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)
[RFC4259], 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.
UDL: Unidirectional link: A one-way transmission link. For example,
and IP over DVB link using a broadcast satellite link.
ULE: Unidirectional Lightweight Encapsulation (ULE). A
scheme that encapsulates PDUs, into SNDUs that are sent in a series
of TS Packets using a single TS Logical Channel [RFC4326].
Expires October 2006 [page 8]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
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 [RFC4326, ISO-MPEG2].
Expires October 2006 [page 9]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
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 Unidirectional Lightweight Encapsulation
(ULE) [RFC4326].
The general IP over MPEG-2 AR requirements are summarized below:
A protocol version, to indicate the specific AR protocol in use
and which may include the supported encapsulation method.
A method (e.g. well-known L2/L3 address/addresses) to identify
the AR Server sourcing the AR information.
A method to represent IPv4/IPv6 AR information (including
security associations to authenticate the AR information that
will prevent address masquerading [RFC3756]).
A method to install AR information associated with clients at
the AR Server (registration).
Scalable and efficient method for transmission of AR
information from an AR Server to clients (link local multicast,
is preferable to subnet broadcast).
Incremental update of the AR information held by clients.
Procedures for purging clients of stale AR information.
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 [RFC4259]. 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). Packets with these
addresses 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) 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].
(iii) 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]).
Expires October 2006 [page 10]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
Overlapping address assignments may also occur at L2, where the same
NPA address is used to identify multiple Receivers [RFC4259]:
(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
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 addresses are distributed across
more than one private network.
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, providing that systems can be
uniquely addressed. 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 MAC/NPA 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.
Within a specific scope, the same unicast IP address may be
associated with more than one TS [ETSI-DAT] Logical Channel (PID
value). These may have different content (e.g. when several
different IP Encapsulators contribute IP flows destined to the same
Receiver), but there is also the possibility of receiving duplicated
copies of IP 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.6). In IPv4 and IPv6 over Ethernet,
this association is normally a direct mapping, and this is the
Expires October 2006 [page 11]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
default method also specified in both ULE [RFC4326] and 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
and the corresponding TS Multiplex. This association 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). Schemes that allow
hardware filtering can be beneficial, since these may relieve the
drivers and operating systems from discarding unwanted multicast
traffic.
There are specific issues concerning IP 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 Encapsulator.
(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 Network supports several logical IP networks 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 Encapsulators contribute IP packets
with the same IP Group Destination Address in the ASM address range.
Another 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 this needs to be
detected by other means.
In some scenarios, a pre-defined set of IP multicast group
destination addresses may be used within a MPEG-2 transmission
network. Prior knowledge of the active set of addresses allows
appropriate AR records to be constructed for each address, and to
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). This presumes that the PID values are not modified
during transmission (section 4).
When the MPEG-2 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
Expires October 2006 [page 12]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
network may be expected to vary significantly with time. Some uses
of IP multicast employ a range of addresses to support a single
application (e.g., ND [RFC2461], LCT [RFC3451], WEBRC [RFC3738]).
The current set of active addresses 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 by the AR method. There are therefore 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.
Section 5.6 describes the binding of IP multicast addresses to
MAC/NPA addresses.
Expires October 2006 [page 13]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
4. MPEG-2 Address Resolution
The first part of this section describes the role of MPEG-2
signalling to identify streams (TS Logical Channels [RFC4259])
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 two PSI tables: the
Programme Association Table (PAT) and entries in the program element
loop of a Programme Map Table (PMT). PMT Tables are sent
infrequently, and are typically small in size. The PAT is sent using
the well-known PID value of 0X000. This table provides the
correspondence between a program_number and a PID value. (The
program_number is the numeric label associated with a program.) Each
program in the Table is associated with a specific PID value, used
to identify a TS Logical Channel (i.e. a TS). The identified TS is
used to send the PMT, which associates a set of PID values with the
individual components of the programme. This approach de-references
the PID values when the MPEG-2 Network includes multiplexors or re-
multiplexors that renumber the PID values of the TS Logical Channels
that they process.
In addition to signalling the Receiver with the PID value assigned
to a stream, PMT entries indicate the presence of Streams using ULE
and MPE to the variety of devices that may operate in the MPEG-2
transmission network (multiplexors, remultiplexors, rate shapers,
advertisement insertion equipment, etc).
A multiplexor or remultiplexor 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 that is not associated with a PMT entry (an orphan PID), may,
and usually will, be dropped by ISO 13818-1 compliant L2 equipment,
resulting in the Transport Stream not being forwarded across the
transmission network. In networks that do not employ any
intermediate devices (e.g. scenarios C,E,F of [RFC4259]), 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
Expires October 2006 [page 14]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
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.
4.1.1 MPEG-2 Cable Networks
Cable networks use a different transmission scheme for downstream,
(head-end to cable modem) and upstream (cable modem to head-end)
transmission.
IP/Ethernet packets are sent (on the downstream) to the cable
modem(s) encapsulated in MPEG-2 TS Packets sent on a single well-
known TS Logical Channel (PID). There is no use of in-band
signalling 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 for IP traffic in cable networks were
proprietary, and did not usually employ a table-based address
resolution method. Proprietary methods continue to be used in some
cases where cable modems require interaction. In this case,
equipment at the head-end may act as gateways between the cable
modem and the Internet. These gateways receive L2 information and
allocate an IP address.
DOCSIS uses DHCP for IP client configuration. The Cable Modem
Terminal System (CMTS) provides a DHCP server that allocates IP
addresses to DOCSIS cable modems. The MPEG-2 Transmission Network
provides a L2 bridged network to the cable modem (section 1). This
usually acts as a DHCP Relay for IP devices [RFC2131, RFC3046,
RFC3256]. Issues in deployment of IPv6 are described in [ID-V6OPS-
DEPLOY].
4.2 MPEG-2 Table-Based Address Resolution
The information about the set of MPEG-2 Transport Streams carried
over a TS Multiplex can be distributed via SI/PSI Tables. These
tables are usually sent periodically (section 4). This design
requires access to and processing of the SI Table information by
each Receiver [ETSI-SI, ETSI-SI1]. This scheme reflects the
complexity of delivering and co-ordinating the various Transport
Streams associated with multimedia TV. A TS Multiplex may provide AR
information for IP services by integrating additional information
into the existing control tables or by transmitting additional SI
Tables that are specific to the IP service.
Expires October 2006 [page 15]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
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 an 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 an MPEG-2 TS.
The MMT and AIT are used for specific applications, whereas 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 carried by
one or multiple TS Multiplexes and represents a single IP network
with a harmonized address space (scope). This allows for the
coexistence of several independent IP/MAC address scopes within an
MPEG-2 Network.
The INT allows both fully-specified IP addresses and prefix
matching, to reduce the size of the table (and hence enhance
signalling efficiency). An IPv4/IPv6 "subnet mask" may be specified
in full form or using a 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.
In addition to identification and security descriptors, the
following descriptors are defined for address binding in INT tables:
(i) target_MAC_address_descriptor: A descriptor to describe a
single or set of MAC addresses (and their mask).
(ii) target_MAC_address_range_descriptor: A descriptor that may be
used to set filters.
(iii) target_IP_address_descriptor: A descriptor describing a
single or set of IPv4 unicast or multicast addresses (and
their mask).
Expires October 2006 [page 16]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
(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: A descriptor that 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. Use of this method is specified for Multi-Protocol
Encapsulation (MPE) [ETSI-DAT].
One key benefit is that the approach employs MPEG-2 signalling
methods (section 4) and is integrated with other signalling
information. This allows the INT to operate in the presence of
(re)multiplexors [RFC4259] and to refer to PID values that are
carried within a number of different TS Multiplexes. This makes it
well-suited to a Broadcast TV Scenario [RFC4259].
The principle drawback is a need for an Encapsulator to introduce
associated PSI/SI MPEG-2 control information. This control
information needs to be processed at a Receiver. This 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.
4.2.2 Multicast Mapping Table (MMT) and its usage
In DVB-RCS, unicast AR is seen as a part of a wider configuration
and control function and does not employ a specific protocol.
The Multicast Mapping Table (MMT) is carried in an MPEG-2 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 multicast 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
Expires October 2006 [page 17]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
it requires to receive. The MMT is not specified as a part of the
DVB-RCS specification.
4.2.3 Application Information Table (AIT) and its usage
The DVB Multimedia Home Platform (MHP) specification [ETSI-MHP] 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 Address Resolution in ATSC
ATSC defines a system that allows transmission of IP packets within
an MPEG-2 Network. An MPEG-2 Program (defined by the PMT) may
contain one or more applications [ATSC-A90] that include IP
multicast streams [ATSC-A92]. IP multicast data are signalled in the
PMT using a stream_type indicator of value 0x0D. A MAC address list
descriptor [SCTE-1] may also be included in the PMT.
The approach focuses on applications that serve the transmission
network. A method is defined that uses MPEG-2 SI tables to bind the
IP multicast media streams and the corresponding Session Description
Protocol (SDP) announcement streams to particular MPEG-2 Program
Elements. Each application constitutes an independent network. The
MPEG-2 Network boundaries establish the IP addressing scope.
4.2.5 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
Address resolution must be performed to associate the IP multicast
Group Destination Address with an MPEG-2 layer TS Logical Channel
Expires October 2006 [page 18]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
(and ultimately PID value) 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).
As MPEG-2 Networks evolve to become multi-service 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,
address resolution information could also be sent using IP
transport. There is an opportunity to define an IP-level method that
could use an IP multicast protocol over a well-known IP multicast
address. The advantages of using an IP-based address resolution for
Transport Streams include:
(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 part of the IP network layer, simplifying support
for AAA, policy, OAM, mobility, configuration control, etc. that
combine AR with security.
The drawbacks of an IP-based method include:
(i) It can not operate over an MPEG-2 Network that uses MPEG-2
remultiplexors [RFC4259] that 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
[RFC4259].
(ii) IP-based methods can introduce concerns about the integrity of
the information and authentication of the sender [RFC4259]. (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
Expires October 2006 [page 19]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
used to authenticate the sender and verify the integrity of the AR
information, as a part of a larger security framework.
An IP-level method may use an IP multicast protocol running over a
well-known (or discovered) 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), as also are methods
that allow a range of IP addresses to mapped to a set of TS Logical
Channels (similar to the mapping of IP Group Destination Addresses
to Ethernet MAC addresses).
Expires October 2006 [page 20]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
5. Mapping IP addresses to MAC/NPA addresses
This section reviews IETF protocols that may be used to assign and
manage the mapping of IP addresses to/from MAC/NPA addresses over
MPEG-2 Networks.
An IP Encapsulator requires AR information to select an appropriate
MAC/NPA address in the SNDU header [RFC 4259] (section 6). The
information to complete this header may be taken directly from a
neighbour/arp cache, or may require the Encapsulator to retrieve the
information using an AR protocol. The way in which this information
is collected will depend upon whether the Encapsulator functions as
a Router (at L3) or a Bridge (at L2) (section 1.1).
Two IETF-defined protocols for mapping IP addresses to MAC/NPA
addresses are the Address Resolution Protocol, ARP [RFC-ARP], and
the Neighbor Discovery protocol, ND [RFC2461], respectively for IPv4
and IPv6. Both protocols are normally used in a bi-directional mode,
although both also permit unsolicited transmission of mappings. The
IPv6 mapping defined in [RFC4624] can result in a large number of
active MAC multicast addresses (e.g. one for each end host).
ARP requires support for L2 broadcast packets. A large number of
Receivers can lead to a proportional increase in ARP traffic, a
concern for bandwidth-limited networks. Transmission delay can also
impact protocol performance.
ARP also has a number of security vulnerabilities. ARP spoofing is
where a system can be fooled by a rogue device that sends a
fictitious ARP response that includes the IP address of a legitimate
network system, and the MAC of a rogue system. This causes
legitimate systems on the network to update their ARP tables with
the false mapping and then send future packets to the rogue system
instead of the legitimate system. Using this method, a rogue system
can see (and modify) packets sent through the network.
Secure ARP (SARP) uses a secure tunnel (e.g. between each client and
a server at a wireless access point or router) [RFC2246]. The router
ignores any ARP responses not associated with clients using the
secure tunnels. Therefore, only legitimate ARP Responses are used
for updating ARP tables. SARP requires the installation of software
at each client. It suffers from the same scalability issues as the
standard ARP.
The ND protocol uses a set of IP multicast addresses. In large
networks, many multicast addresses are used, but clients typically
only listen to a restricted set of group destination addresses and
little traffic is usually sent in each group. Layer-2 AR for MPEG-2
Networks therefore must support this in a scalable manner.
A large number of ND Router Solicitation messages may cause a large
demand for performing asymmetric operations. The base ND protocol
Expires October 2006 [page 21]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
limits the rate at which multicast responses to solicitations can be
sent.
ND has similar security vulnerabilities to ARP. The Secure Neighbor
Discovery, SEND [RFC3917] was developed to address known security
vulnerabilities in ND [RFC3756]. It can also reduce the AR traffic
compared to ND. SEND also does not impact the IPSec architecture and
implementations, and provides improved support for security
decisions based on application state. This allows co-existence of
SEND and insecure ND on the same link.
5.1 Uni-directional links supporting uni-directional connectivity
MPEG-2 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 commonly
are used for IP multicast content distribution.
/-----\
MPEG-2 Uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider + v MPEG-2 downlink
+-----------+ |
+-----v------+
| MPEG-2 |
| Receiver |
+------------+
Figure 3: Uni-directional connectivity
The ARP and ND protocols require bi-directional L2/L3 connectivity.
They do not provide an appropriate method to resolve the remote
(destination) address in a uni-directional environment.
Unidirectional links therefore require a separate out-of-band
configuration method to establish the appropriate AR information at
the Encapsulator and Receivers. ULE [RFC4326] defines a mode in
which the MAC/NPA address is omitted from the SNDU. In some
scenarios, this may relieve an Encapsulator of the need for L2 AR.
5.2 Uni-directional links with bi-directional connectivity
Bi-directional connectivity may be realised using a uni-directional
link 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.
Expires October 2006 [page 22]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
/-----\
MPEG-2 uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider +-<-+ v MPEG-2 downlink
+-----------+ | |
| +-----v------+
+--<<--+ MPEG-2 |
Return | Receiver |
Path +------------+
Figure 4: Bi-directional connectivity
The Uni-Directional Link Routing, UDLR [RFC3077] protocol may be
used to overcome issues associated with asymmetric routing. The
Dynamic Tunnel Configuration Protocol (DTCP) enables automatic
configuration of the return path. UDLR hides the uni-directional
routing is hidden from the IP and upper layer protocols, by
providing a L2 tunnelling mechanism that emulates a bi-directional
broadcast link at L2. A network using UDLR has a topology where a
Feed Router and all Receivers form a logical Local Area Network.
Encapsulating L2 frames allows them to be sent through an Internet
Path (i.e. bridging).
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. Therefore,
it is often desirable to prevent forwarding unnecessary traffic,
(e.g. for multicast this implies control of which groups are
forwarded). The implications of forwarding in the return direction
must also be considered (e.g., asymmetric capacity and loss
[RFC3449]). This suggests a need to minimise the volume and
frequency of control messages.
Three different AR cases may be identified (each considers sending
an IP packet to a next-hop IP address that is not currently cached
by the sender):
(i) A Feed Router needs a Receiver MAC/NPA address.
This occurs when a Feed Router sends an IP packet using the Feed UDL
to a Receiver whose MAC/NPA address is unknown. In IPv4, the Feed
Router sends an ARP REQUEST with the IP address of the Receiver. The
Receiver that recognises its IP address replies with an ARP RESPONSE
to the MAC/NPA address of the Feed Router (e.g. using a UDLR
tunnel). The Feed Router may then address IP packets to the unicast
MAC/NPA address associated with the Receiver. The ULE packet format
also permits packets to be sent without specifying a MAC/NPA
address, where this is desirable (section 6.1, 6.5).
(ii) A Receiver needs the Feed Router MAC/NPA address.
Expires October 2006 [page 23]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
This occurs when a Receiver sends an IP packet to a Feed Router
whose MAC/NPA address is unknown. In IPv4, the Receiver sends an ARP
REQUEST with the IP address of the Feed Router (e.g. using a UDLR
tunnel). The Feed Router replies with an ARP RESPONSE using the Feed
UDL. The Receiver may then address IP packets to the MAC/NPA address
of the recipient.
(iii) A Receiver needs another Receiver MAC/NPA address.
This occurs when a Receiver sends an IP packet to another Receiver
whose MAC/NPA 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 to the Feed Router). The request is forwarded over the
Feed UDL. The target Receiver replies with an ARP RESPONSE (e.g.
using a UDLR tunnel). The Feed Router forwards the response on the
UDL. The Receiver may then address IP packets to the MAC/NPA address
of the recipient.
These 3 cases allow any system connected to the UDL to obtain the
MAC/NPA address of any other system. Similar exchanges may be
performed using the ND protocol for IPv6.
A long round trip delay (via the UDL and UDLR tunnel) impacts the
performance of the reactive address resolution procedures provided
by ARP, ND and SEND. In contrast to Ethernet, during the interval
when resolution is taking place, many IP packets may be received
that are addressed to the AR Target address. The arp specification
allows an interface to discard these packets while awaiting the
response to the resolution request. An appropriately sized buffer
would however prevent this loss.
In case (iii), the time to complete address resolution may be
reduced by use of an AR Server at the Feed (section 5.4).
Using DHCP requires prior establishment of the L2 connectivity to a
DHCP server. The delay in establishing return connectivity in UDLR
networks that use DHCP, may make it beneficial to increase the
frequency of the DTCP HELLO message. Further information about
tuning DHCP is provided in section 5.5.
5.3 Bi-directional Links
Bi-directional IP networks can be and are constructed by a
combination of two MPEG-2 transmission links. One link is usually a
broadcast link that usually feeds a set of remote Receivers. Links
are also provided from Receivers so that 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.
Expires October 2006 [page 24]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
5.4 AR Server
An AR Server can be used to distribute AR information to Receivers
in an MPEG-2 Network. In some topologies this may significantly
reduce the time taken for Receivers to discover AR information.
The AR Server can operate as a proxy responding on behalf of
Receivers to received AR requests. When an IPv4 AR request is
received (e.g. Receiver ARP REQUEST), an AR Server responds by
(proxy) sending an AR response providing the appropriate IP4 to
MAC/NPA binding.
Information may also be sent unsolicited by the AR Server using
multicast/broadcast to update the arp/neighbor cache at the
Receivers without the need for explicit requests. The unsolicited
method can improve scaling in large networks. Scaling could be
further improved by distributing a single broadcast/multicast AR
message that binds multiple IP and MAC/NPA addresses. This reduces
the network capacity consumed and simplifies client
processing/server in networks with large numbers of clients.
AR Servers can be implemented using non-IETF AR protocols to provide
the AR information required by Receivers.
An AR Server can be implemented using IETF-defined Protocols by
configuring the subnetwork so that AR Requests from Receivers are
intercepted rather than forwarded to the Feed/broadcast link. The
intercepted messages are sent to an AR Server. The AR Server
maintains a set of MAC/NPA address bindings. These may be configured
or may learned by monitoring ARP messages sent by Receivers.
Currently defined IETF protocols only allow one binding per message,
(i.e. there is no optimisation to conserve L2 bandwidth).
Equivalent methods could provide IPv6 AR. Procedures for
intercepting ND messages are defined in [ID-ND-PROXY]. To perform an
AR Server function, the AR information must also be cached.
Interactions with SEND are described in [ID-SP-ND].
Current IETF-defined methods provide bindings of IP addresses to
MAC/NPA, but do not allow the bindings to other L2 information
pertinent to MPEG-2 Networks, requiring the use of other methods for
this function (section 4).
5.5 DHCP Tuning
DHCP [RFC2131] may be used over MPEG-2 Networks. DHCP consists of
two components: a protocol for delivering system-specific
configuration parameters from a DHCP server to a DHCP client (e.g.
default router, DNS server) and a mechanism for allocation of
network addresses to systems. DHCP messages (e.g. DHCPDISCOVER,
DHCPREQUEST, DHCPOFFER) may include options [RFC2132].
Expires October 2006 [page 25]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
The configuration of DHCP Servers and Clients should take into
account the local link round trip delay (possibly including the
additional delay from bridging, e.g. using UDLR). A larger delay may
make it desirable to tune the DHCP lease duration and the size of
the address pool. Appropriate timer values should also be selected:
the DHCP messages retransmission timeout, and the maximum delay that
a DHCP Server waits before deciding that the absence of an ICMP echo
response indicates that the relevant address is free.
DHCP Clients may 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
rather than appropriate to a MPEG-2 Network) providing insufficient
time for a DHCP Server to respond to a DHCPDISCOVER retransmission
before expiry of the check on the lease availability (by an ICMP
echo request), resulting in potential address conflict.
5.6 IP Multicast AR
Section 3.2 describes multicast address resolution requirements.
This section describes L3 address bindings when the destination
network layer address is an IP multicast Group Destination Address.
In MPE [DVB-DAT], a mapping is specified for the MAC Address based
on the IP multicast address for IPv4 [RFC1112] and IPv6 [RFC2464].
(A variant of DVB (DVB-H) uses a modified MAC header [DVB_DAT]).
In ULE [RFC4326], 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, a mapping is defined
based on the IP multicast address for IPv4 [RFC1112] and IPv6
[RFC2464].
The L2 group addressing method specified in [RFC1112] and [RFC2464]
can result in more than one IP destination addresses mapping to the
same L2 address. In Source-Specific Multicast, SSM [RFC3569],
multicast groups are identified by the combination of the IP source
and IP destination addresses. Systems may therefore independently
select their IP Group Destination Address that could map to the same
L2 address if forwarded onto the same L2 link. These considerations
are the same as for Ethernet LANs, and may not be of concern to
Receivers that can perform efficient L3 filtering. Separation of the
different groups into different Transport Streams could be a remedy
(with signalling of IP to PID value mappings). Another approach is
to employ alternate mappings to those defined in [RFC1112] and
[RFC2464], but such mappings need to be consistently bound at the
Encapsulator and Receiver using AR procedures in a scalable manner.
Expires October 2006 [page 26]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
6. Link Layer Support
This section considers link-layer (L2) support for address
resolution in MPEG-2 Networks. It considers two issues: The code-
point used at L2 and the efficiency of encapsulation for
transmission required to support the AR method. The table below
summarises the options for both MPE [ETSI-DAT] and ULE [RFC4326]
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 showing 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 MAC/NPA
address is not present in the encapsulated frame. This mode may be
used with both IPv4 and IPv6. When used, the Receiver is expected
to perform network-layer filtering of packets based on their IP
destination address. Encapsulators must ensure that packets are
associated with a TS Logical Channel (PID value) that uniquely
identifies the intended recipient [RFC4326]. This requires careful
consideration of the network topology when a receiver acts is, or
delivers data to an IP router (a simple case where this is permitted
is the connection of stub networks that have no connectivity to
other networks). Since there is no MAC/NPA address in the SNDU, ARP
and NDP are not required.
IPv6 systems can automatically configure their IPv6 network address
based upon a local MAC address [RFC2462]. To use auto-configuration,
the IP driver at the Receiver may need to access the MAC/NPA address
of the receiving interface, even though this value is not being used
to filter received SNDUs.
Expires October 2006 [page 27]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
6.2 ULE with a destination MAC/NPA address (D=0)
The IPv4 Address Resolution Protocol (ARP) [RFC826] uses an IANA-
assigned EtherType and may be used over ULE [RFC4326]. 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 IPv6 ND protocol is supported. The protocol uses a block of IPv6
addresses, which need to be carried by the L2 network. The protocol
does not require specification of a MAC source address, although
this is required for a node to participate in Duplicate Address
Detection (DAD) [RFC2462].
6.3 MPE without LLC/SNAP Encapsulation
This is the default (and sometimes only) mode specified by most MPE
Encapsulators. 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 ND protocol.
6.4 MPE with LLC/SNAP Encapsulation
The LLC/SNAP format of MPE provides an IANA-assigned EtherType and
therefore may support the 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 IPv6 ND protocol is supported using The LLC/SNAP format of MPE.
This requires specific multicast address to be carried by the L2
network. A MAC source address is required for a node to participate
in DAD [RFC2462].
6.5 ULE with Bridging Header Extension (D=1)
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 Encapsulator, the ULE MAC/NPA destination address is
determined by a L2 forwarding decision. Received frames may be
Expires October 2006 [page 28]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
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 and ND messages may
be carried within a 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 MAC/NPA address).
At the Encapsulator, the value of the ULE MAC/NPA destination
address is determined by a L2 forwarding decision. At the Receiver,
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 and
ND messages may be carried within a 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. The 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 Encapsulator, the MPE MAC
destination address is determined by a L2 forwarding decision. As in
other L2 LANs, the Receiver may choose to filter received frames
based on a configured MAC destination address filter.
At the Encapsulator, the MPE MAC destination address is determined
by a L2 forwarding decision. A Receiver may forward frames or they
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 and ND messages may be carried
within a PDU that is bridged by this encapsulation format. The MPE
MAC destination address is determined by a L2 forwarding decision.
Expires October 2006 [page 29]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
7. Conclusions
This document has described addressing and address resolution issues
for the using IP protocols over MPEG-2 transmission networks using
both wired and wireless technologies. 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
Encapsulator/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
transmission of Internet traffic should be considered.
L2 signalling in MPEG-2 transmission networks is currently provided
by (periodic) broadcasting information in the control plane using
PSI/SI tables (section 4). A loss or modification of the SI
information may result in an inability to identify the TS Logical
Channel (PID) that is used for a service. This will prevent
reception of the intended IP packet stream.
There are known security issues relating to the use of unsecured
address resolution [RFC3756].
Readers are also referred to the known security issues when mapping
IP addresses to MAC/NPA addresses using ARP [RFC826] and ND
[RFC2461]. It is recommended that 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. For IPv6, the SEND protocol [RFC3971] may be used
in place of ND. This defines security mechanisms that can protect
AR.
AR Servers (section 5.4) are susceptible to the same kind of
security issues as hosts using unsecured AR. These issues include
hijacking traffic and denial-of-service within the subnet. Malicious
nodes within the subnet can take advantage of this property, and
hijack traffic. In addition, an AR Server is essentially a
legitimate man-in-the-middle, which implies that there is a need to
distinguish such proxies from unwanted man-in- the-middle attackers.
This document does not introduce any new mechanisms for the
Expires October 2006 [page 30]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
protection of these AR functions (e.g. authenticating servers, or
defining AR Servers that interoperate with the SEND protocol [ID-SP-
ND]).
9. Acknowledgments
The authors wish to thank Rod Walsh, Jun Takei, Michael Mercurio and
the ipdvb WG members for their inputs. The authors also acknowledge
the support of the European Space Agency; 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 October 2006 [page 31]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
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.
[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-SI] EN 300 468, "Digital Video Broadcasting (DVB);
Specification for Service Information (SI) in DVB systems", v1.7.1,
European Telecommunications Standards Institute (ETSI), December
2005.
[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.
[RFC2246] T. Dierks, C. Allen, The TLS Protocol Version 1.0,
RFC2246, January 1999.
[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.
[RFC4326] Fairhurst, G., Collini-Nocker, B., "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP datagrams
over an MPEG-2 Transport Stream", December 2005.
10.2 Informative References
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53C, 2004.
Expires October 2006 [page 32]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
[ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A,
2003.
[ATSC-A90] A/90, "ATSC Data Broadcast Standard", Advanced Television
Systems Committee (ATSC), Doc. A/90, 2000.
[ATSC-A92] A/92, "Delivery of IP Multicast Sessions over ATSC Data
Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92,
2002.
[DOCSIS] Data-Over-Cable Service Interface Specifications, DOCSIS
2.0, Radio Frequency Interface Specification, CableLabs, document
CM-SP-RFIv2.0-I10-051209, 2005.
[ETSI-SI1] TR 101 162, "Digital Video Broadcasting (DVB); Allocation
of Service Information (SI) codes for DVB systems", European
Telecommunications Standards Institute (ETSI).
[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), 2002.
[ID-V6OPS-DEPLOY] Asadullah, S., Ahmed, A., Popoviciu, C., "ISP IPv6
Deployment Scenarios in Broadband Access Networks"
draft-ietf-v6ops-bb-deployment-scenarios-04.txt, Work in Progress,
v6ops WG. XXX Publication Requested XX
[ID-ND-PROXY] Thaler, D. Talwar, M., Patel, C., "Neighbor Discovery
Proxies (ND Proxy)", Work in Progress, draft-ietf-ipv6-ndproxy-
04.txt, 2006.
[ID-SP-ND] Daley, G., "Securing Proxy Neighbour Discovery Problem
Statement", Work in progress, draft-daley-send-spnd-prob-01.txt,
February 2005.
[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.
[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.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Expires October 2006 [page 33]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[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.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", RFC
3376, October 2002.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network Path
Asymmetry", BCP 69, RFC 3449, December 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.
RFC3569 Bhattacharyya, S., "An Overview of Source-Specific Multicast
(SSM)", RFC 3569, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[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.
[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.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4259] Montpetit, M.J., Fairhurst, G., Clausen, H.D.,
Collini-Nocker, B., and H. Linder, "Architecture for IP transport
over MPEG-2 Networks".
[SCTE-1] "IP Multicast for Digital MPEG Networks", SCTE DVS 311r6,
March 2002.
Expires October 2006 [page 34]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
11. Authors' Addresses
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
gorry@erg.abdn.ac.uk
http://www.erg.abdn.ac.uk/users/gorry
Marie-Jose Montpetit
Motorola Connected Home Solutions
Advanced Technology
55 Hayden Avenue , 3rd Floor
Lexington
Massachusetts
02421
USA
mmontpetit@motorola.com
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
Expires October 2006 [page 35]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
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 (2006).
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 October 2006 [page 36]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
>>> NOTE to RFC Editor: Please remove this appendix prior to
publication]
APPENDIX: Candidate IP-based L2 AR Protocols
This appendix contains a list of candidate protocols that could be
used to define "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>
- Uses 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.
- Could use some SIP-based signaling
- Table support possible.
- New protocol format.
- Could add scoping for multiple addressing domains.
XML/SIP/IP <new protocol required>
- IPv4 and IPv6.
- Based on UDP or at network-layer or an XML transport/SIP
for compatibility with DVB and 3GPP/3GPP2.
Expires October 2006 [page 37]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
- 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).
- Compression of XML required to achieve efficiency comparable with
other methods.
Expires October 2006 [page 38]
INTERNET DRAFT AR for IP over MPEG-2 Networks May 2006
>>> NOTE to RFC Editor: Please remove this appendix prior to
publication]
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.
* Added AR Authentication note to security considerations.
[>>> NOTE to RFC Editor: End of appendix]
WG-02
* Major editorial work to bring this up tro DRAFT RFC format
* Removed duplication of scoping discussion with ipdvb-arch
* Reworded UDLR section to separate protocol issues from UDLR
specifics.
* Added SI security discussion.
* Minor corrections
* Added text from A/92 on scoping.
* Aligned definitions with ipdvb-arch.
* Fixed Reference format
* Removed markers for additional contributions
* No contributions received on PPPoE (removed).
WG-03
* Sections restructured to offer clearer advice on IETF-defined
protocols.
* Section added on bridging v routing cases
* Section added on AR Server and use with arp and ND.
* Section added to collect issues relating to DHCP
* English improved to prepare for WGLC.
<<<<<
Expires October 2006 [page 39]
