[Docs] [txt|pdf] [Tracker] [Email] [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-00.txt               Marie-Jos® Montpetit
                                                       Expires December 2003
     Category: Informational                                       June 2003
     Address Resolution for IP datagrams over MPEG-2 networks
     Status of this Memo
        This document is an Internet-Draft and is in full conformance with
           all provisions of Section 10 of RFC2026.
        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
        The list of current Internet-Drafts can be accessed at
        The list of Internet-Draft Shadow Directories can be accessed at
        This document describes mechanisms to bind IPv4/IPv6 addresses with
        MPEG-2 Transport Streams (TS). Protocols are required to signal
        these addresses to the link receivers and transmitters, known as
        Address Resolution, or Neighbour Discovery. Although this is often
        associated with Ethernet [RFC803], these processes are essential to
        the operation of any L2 network. MPEG-2 transmission networks often
        utilize broadcast media (e.g., satellite and cable) where the
        mapping may take into account issues related to network operations
        and traffic engineering.
        In MPEG-2 transmission 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, such as SDP, and IMG. In
        this document the different mechanisms used for address resolution
        are reviewed and guidelines for future developments of efficient
        schemes are given.
     Expires December 2003                                         [page 1]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
     Table of Contents
             >>> AuthorsÌ Note: To be completed. <<<
        Document History
        -00 This draft is intended as a study item for proposed future work
        by the IETF in this area.
     Expires December 2003                                         [page 2]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
     1. Introduction
        The MPEG-2 stream is defined in the specification ISO/IEC 138181.
        MPEG-2 provides a time-division multiplexed stream that may contains
        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 Packet or Transport Stream (TS). 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 System Information (SI) PSI
        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 (i.e., 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
        (together with any compression scheme that was used at the sender)
        This document describes mechanisms to signal the TS Multiplex, the
        PID, and (if used) the MAC address / platform ID associated with
        each IP flow to the network layer at the sender and receiver
        (address resolution). This could, 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 (e.g. similar to the IPv4 Address Resolution
        Protocol, ARP, or IPv6 Neighbour Discovery (ND) protocol).
     Expires December 2003                                         [page 3]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
     1.1 Address Resolution Issues
        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-REQ].
        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-REQ]:
        (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
        (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!
        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
     Expires December 2003                                         [page 4]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
        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.
     1.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
        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 December 2003                                         [page 5]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
     2. Conventions used in this document
        ACK: A cumulative TCP acknowledgment. In this document, this term
        refers to a TCP segment (packet) that carries a cumulative
        acknowledgement (ACK), but no data.
        Adaptation Field: Option control overhead or padding associated with
        an MPEG-2 TS Packet. Examples of overhead are: TS Logical Channel
        encryption details and clock (PCR) information to synchronise a set
        of TS Logical Channels.
        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.
        DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC].
        A formatting defined by the ISO MPEG-2 standard, which is carried in
        an MPEG-2 private section.
        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.
        ENCAPSULATOR: A network device that receives Ethernet frames or IP
        packets, and formats these for output as a transport stream of TS
        FORWARD DIRECTION: The dominant direction of data transfer over a
        network path. Data transfer in the forward direction is called
        "forward transfer".  Packets travelling in the forward direction
        follow the forward path through the IP network.
        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).
     Expires December 2003                                         [page 6]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
     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: Programme Elementary Stream. A format of MPEG-2 TS packet
        payload usually used for video or audio information in MPEG-2 [ISO-
        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. A PID of 8191 indicates
        a null packet that must be discarded by a receiver.
        REVERSE DIRECTION: The direction in which feedback control messages
        generally flow (e.g. acknowledgments of a forward TCP transfer
        flow). Data transfer could also happen in this direction (and it is
        termed "reverse transfer").
        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.
        STB: Set Top Box. A consumer equipment (Receiver) for reception of
        digital TV services.
        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 December 2003                                         [page 7]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
        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 including a
        pointer to the next payload header (PUSI), and an adaptation field.
        Each TS packet carries a PID value to associate it with a single TS
        Logical Channel.
     Expires December 2003                                         [page 8]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
     3. 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 to set-top-boxes.  The design
        requires access to and processing of the SI table information [ETSI-
        SI, ETSI-SI1] (which is carried in MPEG-2 section format
        [ISO_DSMCC]).  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.
        >>> AuthorÌs Note: Input requested from ATSC, and users/vendors of
        other non-DVB systems <<<
     3.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.
     3.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.
     Expires December 2003                                         [page 9]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
        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
             (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
             (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 more
        general purpose, and 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.
        3.2.1 Description of the IP/MAC Notification Table (INT) and its
        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.
        In addition to identification and security descriptors the following
        descriptors are used for address binding in INT tables:
     Expires December 2003                                        [page 10]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
             (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
                       announment 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
                  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 (e.g. [IPDVB-REQ]). In addition the use of a
        centralized management prevents the implementation of a more dynamic
     3.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
     Expires December 2003                                        [page 11]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
        previously agreed PID (e.g. configured, or communicated using a SI
        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 DVB 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
        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 (such as 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.
     4. Recommendations
        >>> AuthorÌs note: Input required, please send to ip-dvb mailing
        list <<<
        >>> AuthorÌs note: Input requested from operators <<<
     5. Security Considerations
     Expires December 2003                                        [page 12]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
        The normal security issues relating to the use of wire-less links
        for transport Internet traffic should be considered.  Readers are
        also refered to the known security issues associated with ARP
        [RFC826] and ND.
     6. Acknowledgments
        The authors wish to thank Rod Walsh, Jun Takei, and Alexander Adolf
        for their inputs.
     Expires December 2003                                        [page 13]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
     7. References
        >>> AuthorÌs note: This list may need to be pruned <<<
        [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television
        Systems Committee (ATSC), Doc. A/53, 1995.
        [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
        Systems Committee (ATSC), Doc. A/090, 26 July 00
        [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
        for the ATSC Data Broadcast Standard", Advanced Television Systems
        Committee (ATSC),Doc. A/91. 10 June 2001
        [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for
        Terrestrial Broadcast and Cable", Advanced Television Systems
        Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A € 31, May 2000.
        [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.
        [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.
        [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-REQ] Fairhurst, G., Clausen, H.D., Collini-Nocker, B., and
        H. Liner, "Requirements for transmission of IP datagrams over DVB
        networks", Internet Draft, Work in Progress, IETF.
        [ID-IPDVB-Enc] H. D. Clausen, B. Collini-Nocker, H. Linder, G.
        Fairhurst, "Simple Encapsulation for transmission of IP Datagrams
        over MPEG-2/DVB networks‚, draft-unisal-ipdvb-enc-xx.txt, Internet
        Draft, Work in Progress, IETF.
        [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).
     Expires December 2003                                        [page 14]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
        [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.
        [RFC1122] B. Braden, ed., "Requirements for Internet Hosts  -
        Communication Layers", RFC 1122.
        [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.
        [RFC3077] Duros, E., W. Dabbous, H. Izumiyama, Y. Zhang, "A Link
        Layer Tunneling Mechanism for Unidirectional Links", RFC3077.
     8.Authors' Addresses
        Godred Fairhurst
        Department of Engineering
        University of Aberdeen
        Aberdeen, AB24 3UE
        Email: gorry@erg.abdn.ac.uk
        Web: http://www.erg.abdn.ac.uk/users/gorry
        Marie-Jos® Montpetit
        168 Mystic Valley Parkway
        Arlington, MA, USA
        Email: marie@mjmontpetit.com
     Full Copyright Statement
        "Copyright (C) The Internet Society (date). All Rights Reserved.
        This document and translations of it may be copied and furnished to
        others, and derivative works that comment on or otherwise explain it
        or assist in its implementation may be prepared, copied, published
        and distributed, in whole or in part, without restriction of any
        kind, provided that the above copyright notice and this paragraph
        are included on all such copies and derivative works. However, this
        document itself may not be modified in any way, such as by removing
        the copyright notice or references to the Internet Society or other
        Internet organizations, except as needed for the purpose of
        developing Internet standards in which case the procedures for
        copyrights defined in the Internet Standards process must be
     Expires December 2003                                        [page 15]

     INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2 networks
     June 2003
        followed, or as required to translate it into languages other than
        The limited permissions granted above are perpetual and will not be
        revoked by the Internet Society or its successors or assigns.
     9. IANA Considerations
     Expires December 2003                                        [page 16]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/