[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
   Document: draft-fair-ipdvb-ar-03.txt            Marie-Jose Montpetit
   June 2005                                                   Motorola
                                                     Hidetaka Izumiyama
                                                                Wishnet
   
   
   
   Category: Informational                            Expires June 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/1id-abstracts.html
   
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html
   
   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
    Expires June 2005                                           [page 1]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks  February 2005
   
   Abstract
   
     This document describes the current mechanisms to bind IPv4/IPv6
     addresses and flows to MPEG-2 Transport Streams (TS)and how these
     methods interact with well known protocols for address management
     like DHCP, ARP, NAT and DNS. For MPEG-2 subnetworks like any
     other IP networks 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, an IP
     address must be associated with a Packet ID (PID) and specific
     transmission multiplex either statically or via the use of some
     specific tables. Address resolution complements the higher
     layer resource discovery tools that are used to advertise
     IP sessions. In this document the different mechanisms for
     address resolution for MPEG-2 networking as well as their usage
     are reviewed.
   
   
   Table of Contents
   
        1. Introduction
        2. Convention used in the document
        3. Address Resolution Requirement
        4. MPEG-2 Address Resolution
        5. Mapping 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
   
   
   Document History
   
     -00 This draft is intended as a study item for proposed future
         work by the IETF in this area.
     -01 Review of initial content, major edit and refinement of
         concepts
     -02 fairly important review; took out all new protocol reference;
         added one author; added contribution on real implementation
     -02 Added content to respond to 61st IETF comments;
         refined ID goals; rewrote section 4.2 and 4.3; added cable
         information.
   
   
   
   
    Expires June 2005                                           [page 2]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
   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 data 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 Transport Stream (TS)
    packet. Each MPEG-2 TS Packet is associated with one Transport
    Stream (TS) and 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, specific
    transmission information is sent to the senders/receivers using
    System Information (SI) Tables (ETSI-SI, ETSI-SI1], or Program
    Specific Information (PSI)Tables. The standard also allows
    Defining tables that can be used to carry IP and 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. 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 current mechanisms and their usage 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 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 June 2005                                          [page 3]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
   2. Conventions used in this document
   
    AIT: Application Information Table specified by the Multimedia
    Home Platform (MHP) specifications [ETSI-MHP]. This table may
    carry IPv4/IPv6 to MPEG-2 TS address resolution information.
   
    ATSC: Advanced Television Systems Committee [ATSC]. A 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/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
   
    NPA: Network Point of Attachment. Addresses primarily used for
    station (receiver) identification within a local network (e.g.
    IEEE MAC address).
   
    NPA: Network Point of Attachment. In this document, refers to a 6
    byte destination address (resembling an IEEE MAC address) within
    the MPEG-2 transmission network that is used to identify individual
    Receivers or groups of Receivers.
   
    PID: Packet Identifier[ISO-MPEG2]. A 13 bit field carried in the
    header of TS Packets. This is used to identify the TS Logical
    Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets
    forming the parts of a Table Section, PES, or other Payload Unit
    must all carry the same PID value.
   
    Expires June 2005                                          [page 4]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
    The all 1s PID value indicates a Null TS Packet introduced
    to maintain a constant bit rate of a TS Multiplex. There is no
    required relationship between the PID values used for TS Logical
    Channels transmitted using different TS Multiplexes.
   
    PRIVATE SECTION: A syntactic structure constructed in accordance
    with Table 2-30 of [ISO-MPEG2]. The structure may be used to
    identify private information (i.e. not defined by [ISO-MPEG2])
    relating to one or more elementary streams, or a specific MPEG-2
    program, or the entire Transport Stream. Other Standards bodies,
    e.g. ETSI, ATSC, have defined sets of table structures using the
    private_section structure. A Private Section is transmitted as a
    sequence of TS Packets using a TS Logical Channel. A TS Logical
    Channel may carry sections from more than one set of tables.
   
    PSI: Program Specific Information [ISO-MPEG2]. PSI is used to
    convey information about services carried in a TS Multiplex.
    It is carried in one of four specifically identified table
    section constructs [ISO-MPEG2], see also SI Table.
   
    RECEIVER (in the UDL context): A router or a host that has receive
    only connectivity to a UDL.
   
    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: Transport Stream Logical Channel. In this
    document, this term identifies a channel at the MPEG-2 level [ISO-
    MPEG2]. It exists at level 2 of the ISO/OSI reference model. All
    packets sent over a TS Logical Channel carry the same PID value
    (this value is unique within a specific TS Multiplex). According to
    MPEG-2, some TS Logical Channels are reserved for specific
    signalling. Other standards (e.g., ATSC, DVB) also reserve specific
    TS Logical Channels.
   
    TS MULTIPLEX: In this document, this term defines a set of MPEG-2 TS
    Logical Channels sent over a single lower layer connection. This may
    be a common physical link (i.e. a transmission at a specified symbol
    rate, FEC setting, and transmission frequency) or an encapsulation
    provided by another protocol layer (e.g. Ethernet, or RTP over IP).
    The same TS Logical Channel may be repeated over more than one TS
    Multiplex (possibly associated with a different PID value) [ID-
    ipdvb-arch], for example to redistribute the same multicast content
    to two terrestrial TV transmission cells.
   
   
    Expires June 2005                                      [page 5]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
    TS PACKET: A fixed-length 188B unit of data sent over a TS
    Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header,
    plus optional overhead including an Adaptation Field, encryption
    details and time stamp information to synchronise a set of
    related TS Logical Channels.
   
    UDL: Unidirectional link: A one-way transmission IP over DVB link,
    e.g., a broadcast satellite link.
   
   
   3. Address Resolution Requirements
   
    The general IP over MPEG-2 AR requirements are summarized below;
    These requirements are generic, enable the usage of network layer
    protocols and will be used to evaluate existing approaches:
    - Use SI tables for non-static allocation to promote AR scaling.
    - Provide mechanisms to install AR information at the server
     (unsolicited registration).
    - Provide incremental table updates or purging of stale information.
    - Support address scoping.
    - Provide security associations to authenticate the AR information.
   
    The MPEG IP address resolution is independent of encapsulation
    and supports existing IP over MPEG-2 (e.g., MPE [ETSI-DAT,
    ETSI-DAT1]) and also any IETF encapsulation that may be defined
    [ID-IPDVB-ARCH].
   
    A 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 June 2005                                          [page 6]


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


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
    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
   
    In this section, current MPEG-2 address resolution mechanisms are
    reviewed.
   
    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. This is the
    scheme used by the well known DOCSIS protocol in cable modems.
    This results in all IP traffic to be placed into the specified TS
    stream. Section or MAC filtering may be used to differentiate
    subnetworks.
   
    4.2 Table-Based Address Resolution
   
    The information about the set of MPEG-2 TS streams carried
    over a TS Multiplex can be distributed via tables that are
    assigned a specific and well-known set of PIDs. This design
    requires access to and processing of the SI table
    information [ETSI-SI, ETSI-SI1].  This scheme reflects
    the complexity of delivering and co-ordinating the various TS
    stream associated with multimedia TV. 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
    unidirectional and does not define a virtual channel in the
    ATM sense.
   
   
   
   
   
    Expires June 2005                                           [page 8]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
    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.
   
    Examples of current implementations of systems for allowing
    a MPEG-2 receiver to identify the appropriate PID and multiplex
    used to transmit traffic to a specific IP address 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 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 June 2005                                           [page 9]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
    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.2.2 Multicast Mapping Table (MMT) 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.
   
   
   
   
   
    Expires June 2005                                      [page 10]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
    4.2.3 Application Information Table (AIT) and its usage
   
    The DVB Multimedia Home Platform (MHP) specification does not define
    a specific AR function. However, 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 approaches
   
    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.
   
   
    5. Mapping IP addresses to NPA/MAC addresses
   
    This section reviews IETF protocols that may be used to assign and
    manage the mapping of IP addresses to/from NPA/MAC addresses.
   
    Two IETF-defined protocols for mapping IP addresses to NPA/MAC
    addresses are ARP and ND for IPv4 and IPv6 respectively. Both
    protocols are normally used in a bi-directional mode, although
    both also permit unsolicited transmission of mappings, which could
    potentially be used in a uni-directional environment.
   
    The use of ARP does not raise specific issues with the MPEG-2
    Table-based AR for MPEG-2 Transmission Network Virtual Logical
    Channels, since ARP uses only broadcast and unicast addresses.
   
    The use of ND requires a multicast mapping of the set of
    addresses used by ND to one or more MPEG-2 Transmission Network
    Virtual Logical Channels.
   
    <<< Some text is required to describe operational experience >>>
   
   
   
   
   
    Expires June 2005                                         [page 11]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
   5.1 Link Layer Support
   
    This section considers two layer 2 issues that need to be
    considered. One is the code-point to be used at L2 and the
    other is the efficiency of encapsulation for transmission
    to utilise the AR method. The table below summarises the
    options for both MPE and ULE encapsulations.
   
   +------------------------------+--------+----------------------+
   |                              | PDU    |L2 Frame Header Fields|
   | L2 Encapsulation             |overhead+----------------------+
   |                              |[bytes] |src mac|dst mac| type |
   +------------------------------+--------+-------+-------+------+
   |a. ULE without dst MAC address| 8      |   -   |  -    | x    |
   |b. ULE with dst MAC address   | 14     |   -   |  x    | x    |
   |c. MPE without LLC/SNAP       | 16     |   -   |  x    | -    |
   |d. MPE with LLC/SNAP          | 24     |   -   |  x    | x    |
   |e. ULE with Bridging extension| 22     |   x   |  x    | x    |
   |f. ULE with Bridging & NPA    | 28     |   x   |  x    | x    |
   |g. MPE+LLC/SNAP+Bridging      | 38     |   x   |  x    | x    |
   +------------------------------+--------+-------+-------+------+
   Table of L2 support and overhead (x=supported, -=not supported)
   
    a. ULE with no dst MAC/NPA address
   
    << to be written>>
   
    b. ULE with dst MAC/NPA address
   
   
    The IPv4 Address Resolution Protocol (ARP) [RFC826] uses
    an IANA-assigned EtherType and is supported with ULE [IP-IPDVB-ULE].
   
    The ND protocol of IPv6 [RFC2461] may be used.
   
    << More info on use of ND is required, noting that in one
    form of header there is no MAC src address>>
   
   
   
    c. MPE without LLC/SNAP
   
    MPE does not provide an IANA-assigned EtherType and therefore
    can not support the Address Resolution Protocol (ARP) [RFC826].
   
    The ND protocol of IPv6 [RFC2461] may be used.
   
    << More info on use of ND is required, noting that in one form
    of header there is no MAC src address>>
   
   
   
   Expires June 2005                                         [page 12]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
    d. MPE with LLC/SNAP
   
    The LLC/SNAP format of MPE provides an IANA-assigned EtherType and
    therefore may support the Address Resolution Protocol (ARP)
    [RFC826]. There is no specification to define how this is
    performed. In its simplest form, no MAC source address is present
    in the L2 frame.
   
    LLC/SNAP format MPE frames may optionally carry and IEEE bridging
    header [LLC]. This header supplies both a MAC source and destination
    address, at the expense of larger encapsulation overhead.
   
    The ND protocol of IPv6 [RFC2461] may be used.
   
    << More info on the use of ND is required, noting that in one form
    of header there is no MAC src address>>
   
   
    5.2 Impact on Network Protocols when using Bi-directional
        Transmission
   
    <<< Other real implementation experience is requested: >>>
   
    <<< Please send any experience to ipdvb list >>>
   
    <<< text on DHCP, L2TP, PPoE, etc to be added by
    other volunteers >>>
   
   
    5.3 Impact on Network Protocols when using Uni-directional
        Transmission
   
    The IP over DVB link is basically a Uni-Directional broadcast
    (UDL). ARP and ND do not work in their normal form over
    such links, because these protocols assume the bi-directional
    layer 2 connectivity. The UDL receiver cannot send any response
    to a querier over the UDL link.
   
    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.
   
    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 DVB encapsulation protocols.
   
    <<< Will be completed later, inputs required from WG >>>
   
   
    Expires June 2005                                          [page 13]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
   
    5.4 Cable Networks
   
   Cable networks use different transmission schemes for the upstream
   and downstream transmission. They do not usually employ table based
   approaches for address resolution. Until the deployment of DOCSIS
   and EuroDOCSIS most address resolution schemes in cable networks
   for IP traffic have been proprietary and are still used for
   some STB requiring interaction. In last case it is the role of
   specific headend equipment to act as gateways between
   cable set-top boxes and the Internet. These gateways receive STB
   layer 2 information and allocate IP addresses; there is no
   use of inband tables.
   
   The information is sent (on the downstream) to the STBs as
   IP/Ethernet encapsulated as MPEG frames on a well known PID.
   DOCSIS uses only one PID. On the upstream, traffic is handled
   just like any  Ethernet frames and not as IP/Ethernet over MPEG-2.
   While this approach is widespread, other roprietary schemes are
   still used.
   
   In the DOCSIS world, Cable Modem Terminal Systems (CMTSs) act as
   DHCP servers and allocate IP addresses to DOCSIS modems and STBs.
   DOCSIS acts as an Ethernet bridge between the Cable Modem and the
   CMTS. The CMTS transparently proxies DHCP requests on behalf of a
   DHCP server on the network. The DHCP option is "giadd" (Gateway
   Internet Address)also called a "helper address", which is usually
   the address of a real DHCP server. From the point of view of
   modems and attached devices, it appears that the CMTS (default
   gateway/router)is also the DHCP server.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
    Expires June 2005                                          [page 14]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
   
   6. Conclusions and Recommendations
   
    This document has examined addressing and address resolution
    issues concerning the use of IP protocols over MPEG-2 transmission
    networks. A number of specific IETF protocols are discussed along
    with their expected behaviour over MPEG-2 transmission networks
    and recommendations for usage.
   
    In current MPEG-2 networks, the bindings between IP addresses and
    PIDs can be done statically (such as in the cable
    networks) or carried in tables such at the standard AIT in MHP,
    the IP Notification Tables (INT) of DVB and the DVB-RCS
    Multicast Mapping Tables (MMT). This document has reviewed
    the status of these current address resolution mechanisms
    in MPEG-2 networks, defined their usage and proved information
    to identify what would be needed to improve their conformity
    to standard IP practices.
   
    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.
   
   
   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,
    Michael Mercurio and the ipdvb WG members for their inputs.
    The authors would also like to acknowledge the support of the
    European Space Agency.
   
   
   
   
   
   
   
   
   
   
    Expires June 2005                                          [page 15]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
   9. References
   
    9.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".
   
   
   
   
   
   
   
   
    Expires June 2005                                          [page 16]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
    [ID-IPDVB-ARCH] Montpetit, M.J., Fairhurst, G., Clausen, H.D.,
     Collini-Nocker, B., and H. Linder, "Architecture for IP transport
     over MPEG-2 Networks", Internet Draft, draft-ipdvb-arch-00.txt,
     February 2005, Work in Progress, IPDVB WG.
   
    [ID-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.
   
   
   
    9.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 June 2005                                          [page 17]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
   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
   
   
   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.
   
   
   
   
   
    Expires June 2005                                          [page 18]


   INTERNET DRAFT Address Resolution for IP datagrams over MPEG-2
   networks February 2005
   
   
   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 June 2005                                          [page 19]
   

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