[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

     Internet Engineering Task Force                    Gorry Fairhurst
     Internet Draft                        University of Aberdeen, U.K.
     Document: draft-fair-ipdvb-ar-01.txt          Marie-Jose Montpetit
     July 2004                                          MJMontpetit.com
    
     Category: Informational                      Expires November 2004
    
     Address Resolution for IP datagrams over MPEG-2 networks
    
     Status of this Memo
    
     By submitting this Internet-Draft, we certify that any applicable
     patent or other IPR claims of which we am aware have been
     disclosed, or will be disclosed, and any of which we become aware
     will be disclosed, in accordance with RFC 3668.
    
    
     By submitting this Internet-Draft, we accept the provisions of
     Section 3 of RFC 3667 (BCP 78).
    
    
     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
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     Expires November 2004                                          [page 1]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks  July 2004
    
    
    
     Abstract
    
     This document describes mechanisms to bind IPv4/IPv6 addresses
     and flows to MPEG-2 Transport Streams (TS). While methods
     currently exist to perform these bindings, for MPEG-2 systems to
     become true subnetworks of the general Internet, protocols 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. MPEG-2 transmission networks often utilize broadcast
     media (e.g. satellite or cable) where the mapping may take into
     account issues related to network operations and traffic
     engineering. In MPEG-2 networks, an IP address must be
     associated with a Packet ID (PID) and 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 guidelines for future
     developments of efficient schemes are given.
    
    
     Table of Contents
    
        Document History
        1. Introduction
        2. Convention used in the document
        3. Address Resolution Requirement
        4. MPEG-2 Address Resolution Operation
        5. Conclusions and Recommendations
        6. Security Considerations
        7. Acknowledgements
        8. References
        9. Author's Addresses
        10. IPR Notices
        11. Copyright Statements
        12. IANA Considerations
    
    
     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
    
    
    
    
    
    
    
    Expires November 2004                                      [page 2]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
     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).
    
     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 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.
    
    
    
     Expires November 2004                                     [page 3]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
     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.
    
     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.
    
     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].
    
    
    
    
    
    
      Expires November 2004                                    [page 4]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
    
    
     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.
    
     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.
    
    
    
    
    
    
    
    
    
    
    
    
    
     Expires November 2004                                     [page 5]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
     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].
    
    
     <<< more requirements to be added >>>
    
     In some case, 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.
    
     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Æs 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!
    
    
     2.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.
    
    
     Expires November 2004                                     [page 6]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
    
     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.
    
     2.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.
    
     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.
    
    
    
    
    
    
    
    
    
    
     Expires November 2004                                     [page 7]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
    
     4. MPEG-2 Address Resolution Operation
    
     In this section, the 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.
    
     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.
    
    
    
     Expires November 2004                                     [page 8]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
     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.
    
      (iv)    >>> AuthorÆs Note: Please send details of experience
              using the above schemes (and any others) to authors. <<<
    
     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.
    
     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.
    
    
    
    
    
    
    
    
     Expires November 2004                                     [page 9]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
     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.
    
     4.3 IP Address Resolution Protocol
    
     Another possible approach is to design a query/response protocol
     (similar to, or based on the neighbour advertisements of the IPv6
     ND protocol), which operates over an MPEG-2 TS Logical Channel
     using a previously agreed PID (e.g. configured, or communicated
     using a SI table).
    
    
    
    
    
     Expires November 2004                                    [page 10]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
    
     While the Neighbour Advertisement Protocol [RFC2461] could be used
     as a basis for such a design for IPv6 addresses, the extensive use
     of broadcast messages to request and transmit layer 2 addresses
     would prove inefficient for systems using a wireless physical
     layer.
    
     Both ARP and ND allow unsolicited advertisements of bindings by a
     sender that are broadcast/multicast to the network, without
     requiring the overhead of a client request.  However, both ND and
     ARP are currently restricted to advertising a single association
     per message. To achieve efficient transmission and receiver
     processing over broadcast physical layer, a method needs to be
     found that advertises several associations in a single message
     (e.g., following the method used in MPEG-2 Tables).
    
     The development of IP_layer address resolution would have several
     merits, particularly for IP-only services and two-way MPEG-2
     transmission networks.  Not only would may release a Receiver from
     performing MPEG-2 table processing, it would also allow much more
     dynamic association of PIDs to traffic. Examples of dynamic
     associations include: association/freeing of PIDs in response to
     join or prune actions taken by multicast routing protocols, or on
     assignment of new IP addresses using DHCP/DHCPv6.  Implementing
     such protocols above the IP layer (e.g. using multicast IP
     transport, as used by ND), would allow this protocol to be
     implemented in a portable way not dependent on specific receiver
     hardware/drivers and would allow future integration of the
     functions within IP routers.
    
     The nature of an MPEG-2 transport network and the need to maintain
     flexibility for the operator, means that a protocol would need to
     use operator specifics for address resolution. Adding to this
     complexity, 2-way MPEG-2 services (e.g. DVB-RCS) employ a pair of
     logically separate unidirectional TS, requiring separate return
     and forward resolution. No address resolution protocol has yet
     been defined for MPEG-2 transmission networks.
    
     5. 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 identify what would be needed to improve their
     conformity to standard IP practices.
    
    
     Expires November 2004                                         [page 11]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
    
     Current limitations of the current methods include the dynamics of
     the table refresh support for IP scoping of addresses, 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. The
     specification and definition of address resolution mechanisms
     relating to MPEG-2 PID to/from IP address mapping function, QoS
     association and other mapping functions (e.g. parameters
     associated with a PID/Multiplex) could be supported using a table-
     based protocol to be extensible to ensure a wide applicability
     to different types of MPEG-2 networks and intended applications.
    
     It is expected to be possible to re-use existing protocol
     machinery. For example, XML schemas could be defined and used to
     fetch the required information from the tables. Because XML
     implements standard grammar and syntax this address resolution
     information would be common to all MPEG-2 networks. XML/SOAP
     protocol exchanges may be a suitable method to transfer the
     tables.
    
     6. 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.
    
     7. 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 November 2004                                    [page 12]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
    
     8. References
    
     8.1 Normative 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".
    
     [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,
     July 2004, Work in Progress, IPDVB WG.
    
    
    
     Expires November 2004                                    [page 13]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
    
    
    
     [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.
    
     [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).
    
     [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.
    
     8.2 Informative References
    
     [ETSI-DAT] EN 301 192 Specifications for Data Broadcasting,
     European Telecommunications Standards Institute (ETSI).
    
     [ETSI-DVBC] EN 300 800 Digital Video Broadcasting (DVB); DVB
     interaction channel for Cable TV distribution systems (CATV),
     European Telecommunications Standards Institute (ETSI).
    
     [ISO-MPEG] ISO/IEC DIS 13818-1:2000 "Information technology ¡
     Generic coding of  moving  pictures  and  associated  audio
     information: Systems", International Standards Organisation (ISO).
    
     [ETSI-DAT] EN 301 192 Specifications for Data Broadcasting,
     European Telecommunications Standards Institute (ETSI).
    
     http://www.atsc.org/standards/Code_Point_Registry.pdf
    
    
    
    
    
    
    
    
    
     Expires November 2004                                    [page 14]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
     9. 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
    
    
    
     10. IPR Notices
    
    
     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.
    
    
    
    
    
    
    
    
    
    
     Expires November 2004                                    [page 15]
    

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
     networks July 2004
    
    
    
    
     11. 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.
    
    
     This document and the information contained herein are provided
     on an "AS IS" basis and THE CONTRIBUTORS, THE ORGANIZATIONS THEY
     REPRESENT OR ARE 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. IANA Considerations
    
    
     NOT KNOWN AT THIS TIME.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     Expires November 2004                                    [page 16]
    

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/