Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen, U.K.
Document: draft-fair-ipdvb-ar-02.txt Marie-Jose Montpetit
October 2004 MJMontpetit.com, USA
Hidetaka Izumiyama
Wishnet, Japan
Category: Informational Expires March 2005
Address Resolution for IP datagrams over MPEG-2 networks
Status of this Memo
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
RFC 3668.
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/ietf/1id-abstracts.txt. The list of Internet
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (2004), All Rights Reserved
Abstract
This document describes the current mechanisms to bind IPv4/IPv6
addresses and flows to MPEG-2 Transport Streams (TS). For MPEG-2
systems to become true subnetworks of the general Internet,
methods are required to signal IPv4/v6 addresses to the link
receivers and transmitters; this is known as Address Resolution
(AR), or Neighbour Discovery (ND). Although AR is often associated
with Ethernet [RFC803], it is essential to the operation of any
L2 network. In MPEG-2 networks, address resolution is a three level
process: the IP address is resolved to a NPA/MAC address, then
associated with a Packet ID (PID) and finally to a specific
transmission multiplex. Address resolution complements the higher
layer resource discovery tools that are used to advertise IP
sessions. In this document the different mechanisms used for
address resolution for MPEG-2 are reviewed and their compliance
to AR requirements established.
Expires March 2005 [page 1]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
Table of Contents
Document History
1. Introduction
2. Convention used in the document
3. Address Resolution Requirement
4. MPEG-2 Address Resolution Operation
5. Mapping of IP addresses to NPA/MAC addresses
6. Conclusions and Recommendations
7. Security Considerations
8. Acknowledgements
9. References
10. Author's Addresses
11. IPR Notices
12. Copyright Statements
13. IANA Considerations
Expires March 2005 [page 2]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
[RFC EDITOR NOTE: this section must be deleted 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 references
and moved to a configuration draft; added one author Hidetaka
Izumiyama who has contributions on UDLR experiments;
added a section on AR in UDLR; reworked the bibliography.
[END OF RFC EDITOR NOTE]
1. Introduction
The MPEG-2 stream is defined in the specification ISO/IEC 138181.
It provides a time-division multiplexed (TDM) stream that may
contain audio, video and other information. Each frame, known as
an MPEG-2 TS Packet, contains 4 bytes of header and 188 bytes of
data. The standard also defines the PES packet (Packetized
Elementary Stream) and the Section or Transport Stream (TS)
packet. The PES packet can carry video, audio, private data and
was originally used for some data streaming applications; this
usage is now historical. Each MPEG-2 TS Packet is associated with
one Transport Stream (TS) logical channel, which is identified by
a 13 bit Packet ID (PID) carried in the MPEG-2 TS Packet header.
The standard also defines a MPEG-2 control plane that may be used
to transmit control information. For example, using System
Information (SI) Tables (ETSI-SI, ETSI-SI1], or Program Specific
Information (PSI) Tables. The Tables can be used to carry PID
information about the transported stream. MPEG-2 address
resolution assigns IP addresses to particular transmission
multiplexes, and within a multiplex to a specific PID.
The protocol signals this mapping to the other communicating
devices (Gateways and Receivers). In some address resolution
schemes, this address space is sub-divided into logical contexts
known as Platforms or Sections. One use of this sub-division is
to associate a separate context with each IP service provider that
shares a common MPEG-2 TS (uses the same PID).
Expires March 2005 [page 3]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
MPEG-2 Receivers may optionally be assigned a Network Point of
Attachment (NPA) 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 address resolution
procedure. Finally, address resolution may need to signal the
format of the data being transmitted. For example, the
encapsulation used or any compression scheme that was used at
the sender [ID-IPDVB-ARCH].
This document describes current mechanisms to signal the TS
Multiplex, the PID, and (if used) the MAC address or platform ID
associated with each IP address or flow to the network layer at the
sender and receiver. As will be seen below this can, for example, be
implemented via descriptors sent in MPEG-2 SI tables (using the
MPEG-2 control plane), via one or more new SI tables, or in-band
by a protocol using a data channel similarly to the IPv4 Address
Resolution Protocol, ARP, or IPv6 Neighbour Discovery (ND) protocol.
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 set of
framework and associated standards for the transmission of video,
audio, and data, using the ISO MPEG-2 standard.
DVB: Digital Video Broadcast [ETSI-DVB]. A set of framework and
associated standards 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.
Feed: A router or host that has send-only connectivity to a UDL.
INT: Internet/MAC Notification Table. A uni-directional
addressing resolution mechanism using SI and/or PSI Tables.
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.
Expires March 2005 [page 4]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
MMT: Multicast Mapping Table (proprietary extension to DVB-RCS).
MPE: Multiprotocol Encapsulation [ETSI-DAT, ETSI-DAT1]. A scheme
that encapsulates Ethernet frames or IP Packets, creating a
DSM-CC Section. The Section will be sent in a series of TS Packets
over a TS Logical Channel.
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards
Organisation (ISO) [ISO-MPEG].
NPA: Network Point of Attachment. Addresses primarily used for
station (receiver) identification within a local network (e.g.
IEEE MAC address).
PES: Packetized Elementary Stream. A format of MPEG-2 TS packet
payload usually used for video or audio information in MPEG-2
[ISO-MPEG].
Receiver (in the UDL context): A router or a host that has receive
only connectivity to a UDL. A receiver may have connectivity via an
alternate interface, allowing possible transmission on this second
interface.
UDL: Unidirectional link: A one-way transmission IP over DVB link,
e.g., a broadcast satellite link.
PID: Packet Identifier. A 13-bit field carried in the header of
all MPEG-2 Transport Stream packets [ISO-MPEG]. This is used to
identify the TS Logical Channel to which it belongs.
PRIVATE SECTION: A syntactic structure used for mapping all
service information (e.g. an SI table) into TS Packets. A table
may be divided into a number of sections. All sections of a table
must be carried over a single TS Logical Channel.
PSI: Programme Specific Information: In this document, the term is
used to describe any table used to convey information about a
subset of services carried in a TS Multiplex (e.g. [ISO-MPEG]).
PSI tables are carried in MPEG-2 private sections.
SI TABLE: Service Information Table. In this document, the term is
used to describe any table used to convey information about the
service carried in a TS Multiplex (e.g. [ISO-MPEG]). SI tables are
carried in MPEG-2 private sections.
TS: Transport Stream [ISO-MPEG], a method of transmission at the
MPEG-2 level using TS Packets; it represents level 2 of the
ISO/OSI
reference model. See also TS Logical Channel and TS Multiplex.
Expires March 2005 [page 5]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
TS LOGICAL CHANNEL: A channel identified at the MPEG-2 level; it
represents level 2 of the ISO/OSI reference model. All packets
sent over a channel carry the same PID value.
TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a
single common physical bearer (i.e. a link transmitting at a
specified symbol rate, FEC setting, and transmission frequency).
TS PACKET: A fixed-length 188B unit of data sent over an MPEG-2
multiplex [ISO-MPEG]; it corresponds to the cells, of e.g. ATM
networks, and is frequently also referred to as a TS_cell.
Each TS Packet carries a 4B header, plus optional overhead. Each
TS packet carries a PID value to associate it with a single TS
Logical Channel.
3. Address Resolution Requirements
The IP address resolution support should support both existing IP
over MPEG-2 encapsulations (e.g., MPE [ETSI-DAT, ETSI-DAT1]), and
also any IETF encapsulation that may be defined [ID-IPDVB-ARCH].
AR requirements are summarized below:
- Use of a table based approach to promote AR scaling.
- Mechanisms to install AR information at the server (unsolicited
registration).
- Incremental table updates or purging of stale information.
- Support to scoping.
- Security associations to authenticate the AR information.
In particular, 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.
(ii) Some multicast addresses, (e.g., the scoped multicast
addresses sometimes used in private networks). These are
only valid within an addressed area (examples for IPv4
include; 239/8; 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.
IP packets with these addresses must not be allowed to travel
outside their intended scope, and may cause unexpected behaviour
if allowed to do so.
Expires March 2005 [page 6]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
In addition, overlapping address assignments can arise when using
Level 2 Network Point of Attachment (NPA) addresses [ID-IPDVB-
ARCH]:
(i) The NPA address must be unique within the addressed area.
IEEE MAC addresses used in Ethernet LANs are globally
unique. If the NPA addresses are not globally unique,
the same NPA address may be re-used by receivers in
different addressed areas.
(ii) The NPA broadcast address (all 1 MAC address). Traffic
with this address should be confined to one addressed area.
(iii) Other non-IP protocols may also view sets of MAC multicast
addresses as link-local, and may produce unexpected results
if distributed across several private networks.
3.1 Unicast Support
Reception of unicast packets destined for another addressed area
may lead to an increase in the rate of received packets by systems
connected via the network. IP end hosts normally filter received
unicast IP packets based on their assigned IP address.
Reception of the additional network traffic may contribute to
Processing load but should not lead to unexpected protocol
behaviour. It does however introduce a potential Denial of Service
(DoS) opportunity.
When the Receiver acts as an IP router, the receipt of such packet
may lead to unexpected protocol behaviour. This also provides a
security vulnerability since arbitrary packets may be passed to
the IP layer.
3.2 Multicast Support
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.
(ii) Provide signalling information to allow a receiver to
locate an IP multicast flow within an MPEG-2 TS Multiplex.
(iii) Determining group membership (e.g. utilising IGMP/MLD).
Appropriate procedures need to be specified to identify 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.
Expires March 2005 [page 7]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
Another different case arises when a receiver may potentially
receive more than one copy of the same packet. In some cases,
these may be sent in different TS Logical Channels, or even
different TS Multiplexes. In this case, at the IP level, the
host/router may be unaware of this duplication.
The primary goal of multicast support will be efficient filtering
of IP-multicast packets by the receiver, and the mapping of IPv4
and IPv6 multicast addresses onto the associated PID value and TS
Multiplex. The design should permit a large number of active
multicast groups, and should minimise the processing load at the
receiver when filtering and forwarding IP multicast packets. For
example, schemes that may be easily implemented in hardware would
be beneficial, since these may relieve the drivers and operating
systems from discarding unwanted multicast traffic.
4. MPEG-2 Address Resolution Operations
In this section, current MPEG-2 address resolution mechanisms are
reviewed. In MPEG-2, the information about the set of MPEG-2 TS
Logical Channels carried over a TS Multiplex is usually
distributed via tables (service information, SI) sent using
channels assigned a specific (well-known) set of PIDs. This system
was originally designed for audio/video distribution. The design
requires access to and processing of the SI table information
[ETSI-SI, ETSI-SI1]. This scheme is complex, and reflects the
complexity of delivering and co-ordinating the various TS Logical
Channels associated with a multimedia TV programme. Because of its
historical usage, there is no direct support for IP mechanisms for
identification of the TS multiplex and PID in use for a particular
IP address. It is also important to highlight that a PID value is
associated with a unidirectional channel, also a result of its
initial usage.
4.1 Static configuration.
The static mapping option (IP addresses or flows statically mapped
to 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, but
requires all IP traffic to be placed into the specified TS logical
channel. Section filtering may be used to differentiate
subnetworks at the expense of added complexity and potential
performance penalties.
Expires March 2005 [page 8]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
4.2 Table-Based Address Resolution
MPEG-2 associates multimedia MPEG information with PIDs, using
MPEG-2 Tables. A TS multiplex may provide PID information for IP
services by integrating additional information into the existing
MPEG-2 tables, or to define additional tables specific to the IP
service. This has a dual advantage:
(i) IP specific information can be obtained directly.
(ii) The mechanism uses an already standardised mechanism.
A large number of methods exist within the standards and current
implementations of systems for allowing a MPEG-2 receiver to
identify the appropriate PID and multiplex using to transmit
traffic to a specific IP address.
Examples include:
(i) IP/MAC Notification Table (INT) in the DVB Data standard
[ETS_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 is
DVB standardised and more general purpose. It supports both IPv4
and IPv6 and can be used in combination with the other tables. It
is the favoured choice of some members of the DVB community for
address management and is briefly described below.
4.2.1 Description of the IP/MAC Notification Table (INT) and its
usage.
The INT provides a mechanism for carrying information about the
location of IP/MAC flows within DVB networks. An IP/MAC Platform
represents a set of IP/MAC streams and/or receiver devices. Such a
Platform may span several transport streams within one or multiple
DVB networks and represents a single IP network with a harmonized
address space (i.e. one without address conflicts). The IP/MAC
Platform concept allows for the coexistence of several
non-harmonized IP/MAC address spaces on the same DVB network.
Expires March 2005 [page 9]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
The INT allows "subnets" and fully specified single destination
addresses to make signalling bandwidth efficient and flexible as
required. The "subnet mask" (also for IPv6) can be given in full
form or in slash notation (e.g. /127), this supports IPv6
prefixes.
Multicast addresses can be given with or without source (address
or range), although if source address is given then only the slash
notation can be used for prefixes/subnets.
In addition to identification and security descriptors the
following descriptors are used for address binding in INT tables:
(i) target_MAC_address_descriptor: The descriptor used to
describe a single or group of MAC addresses (and
their mask).
(ii) target_MAC_address_range_descriptor: May be used to
setup filters.
(iii) target_IP_address_descriptor: The descriptor
describing a single or group of IPv4 unicast or
multicast addresses (and their mask).
(iv) target_IP_slash_descriptor: Allows definition and
announcement of an IPv4 subnet.
(v) target_IP_source_slash_descriptor: Uses source and
destination addresses to target a single or group of
devices; could be used to define flows.
(vi) IP/MAC stream_location_descriptor: This descriptor
directly locates the 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
In addition, the ISP_access_mode_descriptor allows definition if
the access to the ISP is done via an alternative non-DVB network
(hence another address is necessary).
The INT provides a set of descriptors to manage addressing in a
DVB network. Its drawbacks are that while the IP/MAC concept is
general enough there is still a need to manage the addressing
(and the traffic) at the PID level. It currently is defined only
for Multi-Protocol Encapsulation (MPE) and would need extension to
support other schemes. In addition the use of a centralized
management prevents the implementation of a more dynamic
scheme.
Expires March 2005 [page 10]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
4.2.2 Description of the Multicast Mapping Table and its usage
The Multicast Mapping Table (MMT) is an example employing an MPEG-2
level control table to communicate a set of multicast addresses and
their associated PID value. This table allows a DVB-RCS Forward
Link Subsystem (FLSS) to specify the mapping and Return Channel
Satellite Terminals (RCSTs) to determine the PID values are being
used by the traffic that need to be received. The MMT is not
currently a part of the DVB-RCS specification.
4.2.3 Description of the Application Information Table and its usage
The DVB Multimedia Home Platform (MHP) specification does not define
a specific AR function. However, the MHP Standard specifies an
Application Information Table (AIT) that each MHP Receiver monitors
to receive a variety of control information. The AIT is a DSMCC
format table that provides information about data broadcasts, the
required activation state of applications carried by a broadcast
stream, etc. This information allows the broadcaster to request that
the receiver change the activation state of an application, and to
direct applications to receive specific multicast packet flows
(using IPv4 or IPv6 routing descriptors. In MHP, AR is not seen as
specific function, but a part of a wider configuration and control
function.
4.2.4 Comparison of table based approached and compliance to
requirements
All tables 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,
encourage the development of 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.
<<< more specifics to be added later >>>
5. Mapping of IP addresses to NPA/MAC addresses
This section reviews the mechanisms to assign IP addresses to
NPA/MAC addresses. This means millions of potential mappings and
raises the issues of scaling. It is obvious that in this case the
un-solicited distribution of addresses by tables that carry
single mappings needs to be avoided.
<<< specific examples to be added >>>
5.1 Bi-directional case
<<< To be added >>>
Expires March 2005 [page 11]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
5.2 Uni-directional case
This section introduces how to use UDLR link layer tunneling
mechanisms to use ARP and ND on Uni-Directional DVB links
and shows the results of the evaluation of the combinations
of UDLR and various IP over DB encapsulation protocols.
5.2.1 Issues
In order to use ARP and ND on IP over a DVB link, there are 2
issues that need to be considered. One is uni-directional
functionality, and the other is the efficiency of encapsulation for
IP over DVB transmission which is not AR related.
The IP over DVB link is basically a Uni-Directional Link (UDL), so
ARP and ND do not work as is, because these protocols assume the
link to be bi-directional. The UDL receiver cannot send any response
to a querier over the UDL link.
In order to solve this, we propose to use the UDLR (RFC3077)
link layer tunneling mechanism. UDLR emulates the UDL as a
bi-directional broadcast type link at the datalink layer. The
uni-directional functionality is hidden to IP and upper layer
protocols.
5.2.2 Evaluation
(i)Candidate of IP over DVB encapsulation protocols
In order to evaluate the functionality of ARP and ND on the IP over
DVB with UDLR environment, we select major IP over DVB encapsulation
protocols as candidates namely ULE and MPE.
Field on Ethernet frame
Total OH src mac dst mac type
[bytes]
a. ULE without dst MAC address 8 x x o
b. ULE with dst MAC address 14 x o o
c. MPE without LLC/SNAP 16 x o x
d. MPE with LLC/SNAP 24 x o o
e. ULE with Bridging extension
(8+2+6+6 B)
f. MPE+LLC/SNAP+Bridging
(24+2+6+6)
(ii)Results of evaluation
a. ULE without dst MAC address
<< To be added>>
Expires March 2005 [page 12]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
b. ULE with dst MAC address
<< To be added>>
c. MPE without LLC/SNAP
For IPv4, the ARP request packet cannot be transmitted
on the UDL (for either feed or receiver query) because of
the lack of Ethertype field. As result, the ARP protocol
does not work on the UDL.
ND works fine. Because ND uses ICMP6 on IPv6, the datalink
Protocol does not need to carry non-IPv6 packets.
It is worth noting that this is not an issue with the ULE
encapsulation [ID-IPDVB-ULE].
d. MPE with LLC/SNAP
There is no specification to carry ARP packets using LLC/SNAP.
However LLC effectively bridges therefore there is no need for
a specific address.
<<< others to be added when appropriate>>>
5.2.3 Discussion
(i)ULE
<<To be added>>
(ii)MPE
The data link driver of Feed and Receiver must see the IP
version field on the IP header to identify the IP version.
There is no such field on the MPE header if LLC/SNAP is
not used.
<< More discussions to be added >>>
<<< Other real implementations requested: DHCP etc. >>>
Expires March 2005 [page 13]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
6. Conclusions and Recommendations
In current MPEG-2 networks, the bindings between IP addresses and
PIDs are usually either done statically (such as in the cable
networks) or carried in tables such at the standard AIT in MHP and
the IP Notification Tables (INT) of DVB. In addition, the DVB-RCS
community has defined a Multicast Mapping Tables (MMT) to improve
the efficiency of multicast address mappings in DVB-RCS networks.
This brief document has reviewed the status of these current
address resolution mechanisms in MPEG-2 networks to clearly define
their usage and allow to identify what would be needed to improve
their conformity to standard IP practices.
Current limitations of the current methods include the dynamics of
the table refresh support for IP scoping of addresses, a generic
access method for ARP and ND using the ULE encapsulation and the
lack of a universal and generic table access methodology.
The authors recommend that standards track activity is needed
in the IPDVB WG to define an IP-oriented alternative to allow link
configuration of a ULE/MPE link above the IP layer.
7. Security Considerations
The normal security issues relating to the use of wireless links
for transport Internet traffic should be considered. Readers are
also referred to the known security issues associated with ARP
RFC826] and ND. Consideration will be given to those methods that
will ensure that usage of MPEG-2 network resources will be
restricted to IP addresses that are not a threat to those
resources or other resources in the Internet.
8. Acknowledgments
The authors wish to thank Rod Walsh, Jun Takei, Alexander Adolf
and the ipdvb WG members for their inputs. The authors would also
like to acknowledge the support of the European Space Agency
Expires March 2005 [page 14]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
9. References
9.1 Normative References
[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).
9.2 Informative References
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced Television Systems
Committee (ATSC),Doc. A/91, 2001.
[ATSC-A92] A/92 "Delivery of IP Multicast Sessions over ATSC Data
Broadcast", Advanced Television Systems Committee (ATSC),
Doc. A/92, 2002.
[ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee (ATSC),
Doc. A/54A, 2003.
[ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television Systems
Committee (ATSC), Doc. A/65B, 2003.
[ETSI-DAT] EN 301 192, "Specifications for Data
Broadcasting", v1.3.1, European Telecommunications Standards
Institute (ETSI), May 2003. http://www.etsi/org/
[ETSI-DAT1] EN 101 202, "Implementation Guide for Data", v1.2.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".
[ETSI-SI1] ETSI TR 101 162: "Digital Video Broadcasting (DVB);
Allocation of Service Information (SI) codes for DVB systems".
Expires March 2005 [page 15]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
[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,
October 2004, Work in Progress, IPDVB WG.
[IP-IPDVB-ULE] Fairhurst, G., Collini-Nocker, B., and H. Linder,
"Ultra Light Encapsulation", Internet Draft, draft-ipdvb-ule-02.txt,
October 2004, Work in Progress, IPDVB WG.
[ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.
Schulzrinne, "Protocol Requirements for Internet Media Guides",
nternet Draft, draft-ietf-mmusic-img-req-07.txt, June 2004, Work
in Progress,MMUSIC WG.
[RFC826] Plummer, D. "An Ethernet Address Resolution Protocol",
RFC 826, IETF, November 1982.
[RFC1122] B. Braden, ed., "Requirements for Internet Hosts -
Communication Layers", RFC 1122.
[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", RFC2464, IETF December 1998.
10. 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
Hidetaka Izumiyama
President CEO, Wishnet Inc.
5-15-5-001 Shirokanedai, Minato-ku
Tokyo, 108-0071, Japan
Email: izu@wishnet.co.jp
Expires March 2005 [page 16]
INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
networks October 2004
11. IPR Notices
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.
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.
12. Copyright Statement
Copyright (C) The Internet Society (2004). 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.
13. IANA Considerations
NOT KNOWN AT THIS TIME.
Expires March 2005 [page 17]