[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 4259

    Internet Engineering Task Force       Marie J. Montpetit ed.
    Internet Draft                                     MJMontpetit.com, USA
    Document: draft-ietf-ipdvb-arch-00.txt                  Gorry Fairhurst
                                                University of Aberdeen, U.K.
                                                           Horst D. Clausen
                                                     Bernhard Collini-Nocker
                                                               Hilmar Linder
                                             University of Salzburg, Austria




    Category: Informational                                        July 2004


    A Framework for transmission of 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


    Abstract

       This document describes a new architecture for the transport of IP
       Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has
       been widely accepted not only for providing digital TV services, but
       also as a subnetwork technology for building IP networks. Examples
       of systems using MPEG-2 include the Digital Video Broadcast (DVB)
       and Advanced Television Systems Committee (ATSC) Standards for
       Digital Television.

       The document identifies the need for a set of Internet standards
       defining the interface between the MPEG-2 Transport Stream and an IP
       subnetwork. It suggests a new encapsulation method for IP datagrams,
       and proposes protocols to perform IPv6/IPv4 address resolution, to
       associate IP packets with the properties of the Logical Channels
       provided by an MPEG-2 TS.

    Expires November 2004                                         [page 1]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004



       Table of Contents

       1. Introduction
       2. Conventions Used in this Document
       3. Architecture
       4. Encapsulation Protocol
       5. Address Resolution Functions
       6. Multicast Support
       7. Summary
       8. Security Considerations
       9. Acknowledgments
       10. References
       11. Author's Addresses
       12. IANA Considerations
       Appendices





    Expires November 2004                                         [page 2]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       Document History

       -00 Current version



    Expires November 2004                                         [page 3]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       1. Introduction

       This document identifies requirements and an architecture for
transport
       of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2]. The prime
       focus is the efficient and flexible delivery of IP services over
       those subnetworks that use the MPEG-2 transport stream.

       Hence, the architecture is designed to be compatible with services
       based on MPEG-2, for example the Digital Video Broadcast (DVB)
       architecture, the Advanced Television Systems Committee (ATSC)
       system [ATSC; ATSC-G], and other similar MPEG-2 based transmission
       systems. Such systems typically provide unidirectional (simplex)
       physical and link layer standards, and have been defined for a wide
       range of physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-
       TC], Satellite TV [ETSI-DVBS; ATSC-S] and Cable Transmission [ETSI-
       DVBC; ATSC-PSIP-TC]).

             +---------+-+-+-+-+------+--------+---+--+--+
             |         |T|V|A|O|  O   |        | O |S |O |
             |         |e|i|u|t|  t   |        | t |I |t |
             |         |l|d|d|h|  h   |   IP   | h |  |h |
             |Protocols|e|e|i|e|  e   |        | e |T |e |
             |native   |t|o|o|r|  r   |        | r |a |r |
             |over     |e| | | |      |        |   |b |  |
             |MPEG-2 TS|x| | | |      |   +----+-+ |l |  |
             |         |t| | | |      |   | MPE  | |e |  |
             |         | | | | |   +--+---+------+ |  |  |
             |         | | | | |   | AAL5 |Priv. | |  |  |
             |         +-+-+-+-+---+------+      +-+--+--+
             |         | PES   |  ATM     |Sect. |Section|
             +---------+-------+----------+------+-------+
             |               MPEG-2 TS                   |
             +---------+-------+-------+-----------------+
             |Satellite| Cable | D-TV  |    Other PHY    |
             +---------+-------+-------+-----------------+

       Figure 1: Overview of the MPEG-2 protocol stack

       Although many MPEG-2 systems carry a mixture data types, MPEG-2
       components may, and are, also used to build IP-only networks.
       Often, those networks do not implement all parts of a DVB / ATSC
       system, and may for instance support minimal, or no, signalling of
       Service Information (SI) tables. Standard system components offer
       advantages of improved interoperability and larger deployment.

    1.1 Salient features of the Architecture

       The architecture proposed in this document describes a set of
protocols
       to support transmission of IP packets over the MPEG-2 TS. Key
       characteristics of these networks are that they may provide link-
       level broadcast capability, and that many supported applications
       require access to a very large number of subnetwork nodes.  Some or

    Expires November 2004                                         [page 4]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       all of these protocols may also be applicable to other subnetworks,
       e.g., other MPEG-2 transmission networks, regenerative satellite
       links [ETSI-BSM], and some types of broadcast wireless links. The
       key goals of the architecture are to reduce complexity when using the
       system, while improving performance, increasing flexibility for IP
       services, and providing opportunities for better integration with IP
       services.

       Since a majority of MPEG-2 transmission networks are bandwidth-
       limited, encapsulation protocols must therefore add minimal overhead
       to ensure good link efficiency while providing adequate network
       services. They also needs to be simple to minimize processing,
       robust to errors and security threats, and extensible to a wide
       range of services.

       In MPEG-2 systems, logical channels provide multiplexing,
       addressing, and error reporting. The logical channel may also be
       used to provide Quality of Service (QoS). Mapping functions are
       required to relate Logical Channels to IP addresses, to map Logical
       Channels to IP-level QoS, and to associate IP flows with specific
       subnetwork capabilities.  An important feature of the proposed
       architecture will be to provide these functions in a dynamic way,
       allowing transparent integration with other IP-layer protocols.
       Collectively, these will form a MPEG-2 TS address resolution
       protocol suite.




    Expires November 2004                                         [page 5]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    2. Conventions Used In This Document

       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.

       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 Media 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.

       ENCAPSULATOR: A network device that receives Ethernet frames or IP
       packets, and formats these for output as a transport stream of TS
       Packets.

       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.

       MAC: Medium Access and Control of the Ethernet IEEE 802 standard of
       protocols (see also NPA).

       MPE: Multiprotocol Encapsulation [ETSI-DAT]. 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 6]

    INTERNET DRAFT  Architecture for IP transport over DVB        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. A PID of 8191 (decimal)
       indicates a null packet that must be discarded by a Receiver.


       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.

       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.

       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 November 2004                                         [page 7]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    3. Architecture

       The following sections introduce the components of the MPEG-2
       Transmission network and relate these to a networking framework.

    3.1 MPEG-2 Transmission Networks

       There are many possible topologies for the MPEG-2 Transmission
       Networks. A number of example scenarios are briefly described below,
       and the following text relates specific functions to this set of
       scenarios.

       A) Broadcast TV and Radio Delivery
       The principal service in the Broadcast TV and Radio Delivery
       scenario is Digital TV and/or Radio and their associated data [ID-
       MMUSIC-IMG]. Such networks typically contain two components: the
       contribution feed and the broadcast part.  Contribution feeds
       provide communication from a typically small number of individual
       sites (usually at high quality) to the Hub of a broadcast network.
       The traffic carried on contribution feeds is typically encrypted,
       and is usually processed prior to being resent on the Broadcast part
       of the network. The Broadcast part uses a star topology centred on
       the Hub to reach a typically large numbers of down-stream Receivers.
       Although such networks may provide IP transmission, they do not
       necessarily provide access to the public Internet.

       B) Broadcast Networks used as an ISP
       Another scenario resembles that above, but includes the provision of
       IP-services providing access to the public Internet. The IP traffic
in
       this scenario is typically not related to the digital TV/Radio
content,
       and the service may be operated by an independent operator such as
uni-
       directional File Delivery or bi-directional ISP access. The IP
service
       must adhere to the full system specification used for the broadcast
       transmission, including allocation of PIDs, and generation of
       appropriate MPEG-2 control information (e.g. DVB and ATSC SI tables).

       C) Uni-directional Star IP Scenario
       The Uni-directional Star IP Scenario utilises a Hub station to
       provide a data network delivering a common bit stream to medium-
       sized groups of Receivers. MPEG-2 transmission technology provides
       the forward physical and link layers for this transmission, the
       return link (if required) is provided by other means. IP services
       typically form the main proportion of the transmission traffic. Such
       networks may not necessarily implement the MPEG-2 control plane.

       D) Data-cast overlay
       The Data-cast overlay scenario employs MPEG-2 physical and link
       layers to provide additional connectivity such as uni-directional
       multicast to supplement an existing IP-based Internet service.
       Examples of such a network includes IP Datacast to mobile wireless
       receivers [ID-MMUSIC-IMG].


    Expires November 2004                                         [page 8]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       E) Point-to-point links
       Point-to-point connectivity may be provided using a pair of transmit
       and receive interfaces supporting the MPEG-2 physical and link
       layers.  Typically the transmission from a sender is received by
       only one or a small number of Receive terminals. Examples include
       the use of transmit/receive DVB-S terminals to provide satellite
       links between ISPs utilising BGP routing.

       F) Two-Way IP Networks
       Two-Way IP networks are typically satellite-based and star-based
       utilising a Hub station to deliver a common bit stream to medium-
       sized groups of receivers. A bi-directional service is provided over
       a common air-interface. The transmission technology in the forward
       physical and link layers for this transmission is MPEG-2, which may
       also be used in the return direction. Such systems also usually
       include a control plane element to manage the (shared) return link
       capacity. A concrete example is the DVB-RCS system. IP services
       typically form the main proportion of the transmission traffic.

       Scenarios A-D employ uni-directional MPEG-2 Transmission networks.
       For satellite-based networks, these typically have a star topology,
       with a central Hub providing service to large numbers of down-stream
       Receivers. Terrestrial networks may employ several transmission Hubs
       each serving a particular coverage cell with a community of
       Receivers.

       From an IP viewpoint, the service is typically either uni-
       directional multicast, or a bi-directional service in which some
       complementary link technology (e.g. Modem, LMDS, GPRS, ...) is used
       to provide the return path from Receivers to the Internet.  Routing


       in this case could be provided using Uni-Directional Link Routing
       (UDLR) [RFC3077].

       Note that only Scenarios A-B actually carry MPEG-2 video and audio
       intended for reception by digital Set Top Boxes (STBs) as the
       primary traffic. The other scenarios are IP-based data networks and
       need not necessarily implement the MPEG-2 control plane.

       Scenarios E-F provide two-way connectivity using MPEG-2
       transmission.  Such networks provide direct support for bi-
       directional protocols above and below the IP layer.

       The complete MPEG-2 transmission network may be managed by a
       transmission service operator. In such cases, the assignment of
       addresses and TS Logical Channels at Receivers are usually under the
       control of the service operator.  Examples include a TV operator
       (Scenario A), or an ISP (Scenarios B-F).  MPEG-2 transmission
       networks are also used for private networks. These typically involve
       a smaller number of Receivers and do not require the same level of
       centralised control. Examples include companies wishing to connect
       DVB-capable routers to form links within the Internet (Scenario B).

    Expires November 2004                                         [page 9]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    3.2 TS Logical Channels

       An MPEG-2 transport multiplex offers a number of parallel channels,
       which are known here as TS Logical Channels.  Each MPEG-2 TS Logical
       Channel is uniquely identified by the Packet ID, PID, value carried
       in the header of each MPEG-2 TS Packet. The PID value is a 13 bit
       field and, thus, the number of available channels is limited to 8192
       (decimal), some of which are reserved for transmission of SI tables.
       Non-reserved TS Logical Channels may be use to carry audio [ISO-AUD],
       video [ISO-VID], IP packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT],
       or other data [ISO-DSMCC; ETSI-DAT; ATSC-DAT]. The value 8191
       (decimal) indicates a null packet, used to maintain the physical
       bearer bit rate when there are no other MPEG-2 TS Packets to be
       sent.

              TS-LC-A-1         /---\--------------------/---\
                      \        /     \                  /     \
                       \      |       |                |       |
           TS-LC-A-2    -----------   |                | -------------
               --------------------   |                | -------------
                              |       |                |       |
                         /--------   /                 | -------------
                        /      \----/-------------------\----/
              TS-LC-A-3/               MPEG-2 TS MUX A
                      /
        TS-LC        /
        ------------X
                     \ TS-LC-B-3 /---\------------------------/---\
                      \         /     \                      /     \
                       \       |       |                    |       |
           TS-LC-B-2    \-----------   |                    | ---------
                --------------------   |                    | ---------
                               |       |                    |       |
                          /--------   /                     | ---------
                         /      \----/-----------------------\----/
                        /                 MPEG-2 TS MUX B
             TS-LC-B-1

         Figure 2: Example showing MPEG-2 TS Logical Channels carried over
                               2 MPEG-2 TS Multiplexes.

       TS Logical Channels are independently numbered on each MPEG-2 TS
       Multiplex (MUX).  In most cases the data sent over the TS Logical
       Channels will differ for different multiplexes. The above figure
       shows a set of TS Logical Channels sent using two MPEG-2 TS
       Multiplexes (A and B).

       There are cases where the same data may be distributed over two or
       more multiplexes (e.g., some SI tables; multicast content which
       needs to be received by Receivers tuned to either MPEG-2 TS; unicast
       data were the Receiver may be in either/both two potentially
       overlapping MPEG-2 transmission cells). In figure 2, each multiplex

    Expires November 2004                                        [page 10]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       carries 3 MPEG-2 TS Logical Channels. These Logical Channels may
       differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be
       common to both MPEG-2 TS Multiplexes (i.e. TS-LC-A-3 and TS-LC-B-3
       carry identical content).

       As can been seen above, there are similarities between the way PIDs
       are used and the operation of virtual channels in ATM. However,
       unlike ATM, a PID defines a unidirectional broadcast channel and not
       a point-to-point link. Contrary to ATM, there is, as yet, no
       specified standard interface for MPEG-2 connection setup, or for
       signalling mappings of IP flows to PIDs, or to set the Quality of
       Service, QoS, assigned to an TS Logical Channel.

    3.3  Multiplexing and Re-Multiplexing

       In a simple example, one or more TS are processed by a MPEG-2
       multiplexor resulting in a TS Multiplex. The TS Multiplex is
       forwarded over a physical bearer towards one or more Receivers
       (figure 3).

          +------------+                                  +------------+
          |  IP        |                                  |  IP        |
          |  End Host  |                                  |  End Host  |
          +-----+------+                                  +------------+
                |                                                ^
                +------------>+---------------+                  |
                              +  IP           |                  |
                +-------------+  Encapsulator |                  |
        SI-Data |             +------+--------+                  |
        +-------+-------+            |MPEG-2 TS Logical Channel  |
        |  MPEG-2       |            |                           |
        |  SI Tables    |            |                           |
        +-------+-------+   ->+------+--------+                  |
                |          -->|  MPEG-2       |                . . .
                +------------>+  Multiplexor  |                  |
        MPEG-2 TS             +------*--------+                  |
        Logical Channel              |MPEG-2 TS Mux              |
                                     |                           |
                   Other    ->+------+--------+                  |
                   MPEG-2  -->+  MPEG-2       |                  |
                   TS     --->+  Multiplexor  |                  |
                         ---->+------+--------+                  |
                                     |MPEG-2 TS Mux              |
                                     |                           |
                              +------+--------+           +------+-----+
                              |Physical Layer |           |  MPEG-2    |
                              |Modulator      +---------->+  Receiver  |
                              +---------------+  MPEG-2   +------------+
                                                 TS Mux

        Figure 3: An example configuration for a uni-directional service
                  for IP transport over MPEG-2

    Expires November 2004                                        [page 11]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       In a more complex example, the same TS may be fed to multiple MPEG-2
       multiplexors and these may, in turn, feed other MPEG-2 multiplexors
       (remultiplexing). Remultiplexing may occur in several places (and is
       common in Scenario A of section 3.1). One example is a satellite
       that provides on-board processing of the TS packets, multiplexing
       the TS Logical Channels received from one or more up-link physical
       bearers (TS Multiplex) to one (or more in the case of
       broadcast/multicast) down-link physical bearer (TS Multiplex). As
       part of the remultiplexing process, a remultiplexor may renumber the
       PID values associated with one or more TS Logical Channels to
       prevent clashes between input TS Logical Channels with the same PID
       carried on different input multiplexes. It may also modify and/or
       insert new SI data into the control plane to reflect the content
       output using TS Multiplex.

       In all cases, the final result is a "TS Multiplex" which is
       transmitted over the physical bearer towards the Receiver.

    3.4  IP Datagram Transmission

       Packet data for transmission over the MPEG-2 transport multiplex is
       passed to an Encapsulator, sometimes known as a Gateway.  This
       receives Protocol Data Units, PDUs, such as Ethernet frames or IP
       packets, and formats each into a Sub-Network Data Unit, SNDU, by
       adding an encapsulation header and trailer (see section 5). The
       SNDUs are subsequently fragmented into a series of TS Packets.

       To receive IP packets over a MPEG-2 transport multiplex, a Receiver
       needs to identify the specific TS Multiplex (physical link) and also
       the TS Logical Channel (the PID value of a logical link). It is
       common for a number of MPEG-2 TS Logical Channels to carry SNDUs,
       and a Receiver must therefore filter (accept) IP packets sent with a
       number of PID values, and must independently reassemble each SNDU.

       A Receiver that simultaneously receives from several TS Logical
       Channels, must filter other unwanted TS Logical Channels by
       employing for example specific hardware support. Packets for one IP
       flow (i.e. a specific combination of IP source and destination
       addresses) must be sent using the same PID. It should not be assumed
       that all IP packets are carried on a single PID, as in some cable
       modem implementations, and multiple PIDs must be allowed in the
       architecture. Many current hardware filters limit the maximum number
of
       active PIDs (e.g. 32), although if needed, future systems may
       reasonably be expected to support more.

       In some cases, Receivers may need to select TS Logical Channels from
       a number of simultaneously active TS Multiplexes. To do this, they
       need multiple physical receive interfaces (e.g., RF front-ends and
       demodulators). Some applications also envisage the concurrent

    Expires November 2004                                        [page 12]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       reception of IP Packets over other media that may not necessarily
       use MPEG-2 transmission.

       Bi-directional (duplex) transmission can be provided using a MPEG-2
       transmission network by using one of a number of alternate return
       channel schemes [DVB-RC]. Duplex IP paths may also be supported
       using non-MPEG-2 return links (e.g. in Scenarios B-D of section
       3.1). One example of such an application is that of Uni-Directional
       Link Routing, UDLR [RFC3077].

       The DVB family of standards currently defines a mechanism for
       transporting an IP packet, or Ethernet frame using the Multi-
       Protocol Encapsulation (MPE) [ETSI-DAT]. This scheme is also
       supported in ATSC [ATSC-DAT; ATSC-DATG]. It allows transmission of
       IP packets or Ethernet style frames in the control plane associated
       with audio/video transport. Data is formatted as if it were a Table
       Section. The MPE specification includes a set of optional header
       components and requires decoding of the control headers.  This
       processing is suboptimal for Internet traffic, since it incurs
       significant receiver processing overhead and some extra link
       overhead [CLC99].

                   +-----------------------------------------+
                   |Encap Header|       Subnetwork DU        |
                   +-----------------------------------------+
                  /         /                          \      \
                 /         /                            \      \
                /         /                              \      \
        +------+----------+  +------+----------+   +------+----------+
        |MPEG-2| MPEG-2   |..|MPEG-2| MPEG-2   |...|MPEG-2| MPEG-2   |
        |Header| Payload  |  |Header| Payload  |   |Header| Payload  |
        +------+----------+  +------+----------+   +------+----------+

         Figure 4: Encapsulation of an SNDU (e.g., IP packet) into a series
        of MPEG-2 TS Packets (each TS Packet carries a header with a common
           Packet ID, PID, value denoting the MPEG-2 TS Logical Channel).

    3.5 Motivation

       The network layer protocols to be supported by this architecture
       include:
       (i) IPv4 Unicast packets, destined for a single end host
       (ii) IPv4 Broadcast packets, sent to all end systems in an IP
       network
       (iii) IPv4 Multicast packets
       (iv) IPv6 Unicast packets, destined for a single end host
       (v) IPv6 Multicast packets
       (vi) Packets with compressed IPv4 / IPv6 packet headers (e.g.
       [RFC1114; RFC2507; RFC3095])
       (vii) Bridged Ethernet frames
       (viii) Other (MPLS, IPv6 anycast, potential new protocols__

    Expires November 2004                                        [page 13]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       The architecture will provide:

       (i)  Guidance on which MPEG-2 features are pre-requisites for the IP
            service, and identification of any optional fields that impact
            performance/correct operation.

       (ii) Standards to provide an efficient and flexible encapsulation
            scheme that may be easily implemented in an Encapsulator or
            Receiver. The payload encapsulation requires a type field for
            the SNDU to indicate the type of packet and a mechanism to
            signal which encapsulation is used on a certain PID.

       (iii) Standards to associate a particular IP address with a Network
            Point of Attachment (NPA) that could or could not be a MAC
            Address. This process resembles the IPv4 Address Resolution
            Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR-
            DRAFT]. In addition, the standard will be compatible with IPv6
            autoconfiguration.

       (iv) Standards to associate a MPEG-2 TS interface with one or more
            specific TS Logical Channels (PID, TS Multiplex). Bindings are
            required for both unicast transmission, and multicast reception.
            In the case of IPv4 this must also support network broadcast. To
            make the schemes robust to loss and state changes within the
            MPEG-2 transmission network, a soft-state approach may prove
            desirable.

       (v)  Standards to associate the capabilities of a MPEG-2 TS Logical
            Channel with IP flows. This includes mapping of QoS functions,
            such as IP QoS/DSCP and RSVP, to underlying MPEG-2 TS QoS,
            multi-homing and mobility. This capability could be associated
            by the AR standard proposed above.

       (vi) Guidance on Security for IP transmission over MPEG-2. The
            framework must permit use of IPSEC and clearly identify any
            security issues concerning the specified protocols. The security
            issues need to consider two cases: unidirectional transfer (in
            which communication is only from the sending IP end host to the
            receiving IP end host) and bi-directional transfer.
            Consideration should also be given to security of the TS
            Multiplex: the need for closed user groups and the use of MPEG-2
            TS encryption.

       (vii) Management of the IP transmission, including standardised SNMP
            MIBs and error reporting procedures. The need for and scope of
            this is to be determined.

       The specified architecture and techniques should be suited to a range
       of systems employing the MPEG-2 TS, and may also suit other (sub)
       networks offering similar transfer capabilities.

    Expires November 2004                                        [page 14]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       The following sections 4 and 5 describe encapsulation issues.
       Sections 6 and 7 describe address resolution issues for unicast and
       multicast. The appendix provides some use cases.

    4. Encapsulation Protocol Requirements

       This section identifies requirements and provides examples of
       mechanisms that may be used to perform the encapsulation of IPv4 and
       IPv6 multicast and unicast packets over MPEG-2 transmission
       networks.

       The encapsulation protocol transports a SNDU over the MPEG-2 TS
       service and provides the appropriate mechanisms to deliver this to
       the Receiver IP interface. A convergence protocol typically adds
       header fields before a SNDU that carry protocol control information
       such as length of SNDU, Receiver address, multiplexing information,
       payload type, sequence numbers etc.  The SNDU payload is typically
       followed by a trailer, which carries an Integrity Check (e.g.,
       Cyclic Redundancy Check, CRC). Some protocols also add additional
       control information and/or padding to or after the trailer.

               +--------+-------------------------+-----------------+
               | Header |            SNDU         | Integrity Check |
               +--------+-------------------------+-----------------+

           Figure 5: Encapsulation of a subnetwork PDU (e.g. IPv4 or IPv6
                     packet) to form an MPEG-2 Payload Unit.

       Examples of existing convergence protocols include ATM AAL5 [ITU-
       AAL5], and MPEG-2 MPE [ETSI-DAT].

       The existing proposals and standards for use with MPEG-2 carry
       heritage from legacy implementations that reflect the limitations of
       technology at their deployment.  For example a majority are more
       dominated by audio/video considerations than IP requirements. This
       justifies the development of a new encapsulation that will be truly
       IP-centric. Carrying IP packets over a TS Logical Channel involves
       several convergence protocol functions. This section briefly
       describes these functions and highlights the requirements for a new
       encapsulation.

       4.1 Payload_Unit Delimitation

       MPEG-2 indicates the start of a Payload Unit in a new TS Packet with
       a "start_of_payload_unit_indicator" (PUSI) [ISO-MPEG] carried in the
       4B TS Packet header. The PUSI is a 1 bit flag that has normative
       meaning [ISO_MPEG] for TS Packets that carry PES Packets or PSI
       data.

       When the payload of a TS Packet contains PES data, a PUSI value of
       '1' indicates the TS Packet payload starts with the first byte of a

    Expires November 2004                                        [page 15]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       PES Packet. A value of '0' indicates that no PES Packet starts in
       this TS Packet. If the PUSI is set to '1', then one, and only one,
       PES Packet starts in the TS Packet.

       When the payload of the TS Packet contains PSI data, a PUSI value of
       '1' indicates the first byte of the TS Packet payload carries a
       payload pointer that indicates the position of the first byte of the
       Payload Unit (Section) being carried; if the TS Packet does not
       carry the first byte of a Section, the PUSI is set to '0',
       indicating that there is no payload pointer.

       Using this PUSI bit, the start of the first Payload Unit in a TS
       Packet is exactly known by the Receiver, unless that TS Packet has
       been corrupted or lost in the transmission. In which case, the
       payload is discarded until the next TS Packet is received with a
       PUSI value of '1'.

       The encapsulation should allow packing of more than one SNDU into
       the same TS Packet and should not limit the number of SNDUs that can
       be sent in a TS Packet.  In addition, it should allow an IP
       Encapsulator to insert padding when there is an incomplete TS Packet
       payload. A mechanism needs to be identified to differentiate this
       padding from the case where another encapsulated SNDU follows.

       A combination of the PUSI and a Length Indicator (see below) allows
       an efficient MPEG-2 convergence protocol to receive accurate
       delineation of packed SNDUs.  The MPEG-2 standard [ISO_MPEG] however
       does not specify how private data should use the PUSI bit.

       4.2 Length Indicator

       Most services using MPEG-2 include a length field in the payload
       header to allow the Receiver to identify the end of a payload unit
       (e.g. PES Packet, Section, or an SNDU).

       When parts of more than two Payload Units are carried in the same TS
       Packet, only the start of the first is indicated by the Payload
       Pointer. Placement of a Length Indicator in the encapsulation header
       allows a Receiver to determine the number of bytes until the start
       of the next encapsulated SNDU. This placement also provides the
       opportunity for the Receiver to pre-allocate an appropriate-sized
       memory buffer to receive the reassembled SNDU.

       A Length Indicator is required, and should be carried in the
       encapsulation header.  This should support SNDUs of at least the MTU
       size offered by Ethernet (1500 bytes). Although the IPv4 and IPv6
       packet format permits an IP packet of size up to 64 KB, such packets
       are seldom seen on the current Internet. Since high speed links are
       often limited by the packet forwarding rate of routers, there has
       been a tendency for Internet core routers to support MTU values
       larger than 1500 bytes. A value of 16 KB is not uncommon in the core

    Expires November 2004                                        [page 16]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       of the current Internet.  This would seem a suitable maximum size
       for an MPEG-2 transmission network.

       4.3 Next Level Protocol Type

       A key feature of the new encapsulation is to identify the type of
       payload being transported (e.g., to differentiate IPv4, IPv6 etc.).
       Most protocols use a type field to identify a specific process at
       the next higher layer that is the originator or the recipient of the
       payload (SNDU). This method is used by IPv4, IPv6, and also by the
       original Ethernet protocol (DIX). OSI uses the concept of a
       'Selector' for this, (e.g. in the IEEE 802/ISO 8802 standards for
       CSMA/CD [LLC], although in this case a SNAP (subnetwork access
       protocol) header is also required for IP packets.

       A Next Level Protocol Type field is also required if compression
       (e.g. Robust Header Compression, ROHC) is supported. No compression
       method has currently been defined that is directly applicable to
       this architecture, however the ROHC framework defines a number of
       header compression techniques that may yield considerable
       improvement in throughput on links which have a limited capacity.
       Since many MPEG-2 transmission networks are wireless the ROHC
       framework will be directly applicable for many applications. Use of
       ROHC implies the need to transfer smaller SNDUs and the need for
       additional processing at the Receiver to expand the received
       compressed packets. The selected type field should contain
       sufficient code points to support this technique.

       It is thus a requirement to include a Next Level Protocol Type field
       in the encapsulation header.  Such a field should specify values for
       at least IPv4, IPv6, and must allow for other values (e.g., MAC-
       level bridging).

       4.4 L2 Subnet Addressing

       In MPEG-2, the PID carried in the TS Packet header is used to
       identify individual services with the help of SI tables. This was
       primarily intended as a unidirectional (simplex) broadcast system. A
       TS Packet stream carries either tables or one PES Packet stream
       (i.e., compressed video or audio). Individual Receivers are not
       addressable at this level.

       IPv4 and IPv6 allocate addresses to end hosts and intermediate
       systems (routers). Each system (or interface) is identified by a
       globally assigned address.  ISO uses the concept of a hierarchically
       structured Network Service Access Point (NSAP) address to identify
       an end user process in an Internet environment.

       Within a local network a completely different set of addresses for
       the Network Point of Attachment (NPA) is used; frequently these NPA
       addresses are referred to as Medium Access Control, MAC-level
       addresses. In the Internet they are also called hardware addresses.

    Expires November 2004                                        [page 17]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       Whereas network layer addresses are used for routing, NPA addresses
       are primarily used for Receiver identification.

       Receivers may use the NPA of a received SNDU to reject unwanted
       unicast packets within the (software) interface driver at the
       Receiver, but must also perform forwarding checks based on the IP
       address. IP multicast and broadcast may also filter based using the
       NPA, but Receivers must also filter unwanted packets at the network
       layer based on source and destination IP addresses.  This does not
       imply that each IP address must map to a unique NPA (more than one
       IP address may map to the same NPA). If a separate NPA address is
       not required, the IP address is sufficient for both functions.

       If it is required to address an individual Receiver in an MPEG-2
       transport system, this can be achieved either at the network level
       (IP address) or via a hardware-level NPA address (MAC-address).  If
       both addresses used, they must be mapped either in a static or a
       dynamic way (e.g., by an address resolution process). A similar
       requirement may also exist to identify the PID and TS multiplex on
       which services are carried.

       Using an NPA address in a MPEG-2 transport system may enhance
       security, in that a particular payload may be targeted for a
       particular Receiver by specifying the Receiver NPA address. This is
       however only a weak form of security, since the NPA filtering is
       often reconfigurable (frequently performed in software), and may be
       modified by a user to allow reception of specified (or all) packets,
       similar to promiscuous mode operation in Ethernet. If security is
       required, it should be applied at another place (e.g. link
       encryption, authentication of address resolution, IPSEC, transport
       level security and/or application level security).

       There are also cases where the use of a NPA is required (e.g. where
       a system operates as a router) and if present this should be carried
       in encapsulation header where it may be used by Receivers as a pre-
       filter to discard unwanted SNDUs. The addresses allocated do not
       need to conform to the IEEE MAC address format. There are many cases
       where a NPA is not required, and network layer filtering may be used.
       A new encapsulation protocol should therefore support an optional
NPA.

       4.5 Integrity Check

       For the IP service, the probability of undetected packet error
       should be small (or negligible) [ID-PILC-LINK]. There is therefore a
need
       for a CRC to verify correctness of a received IP packet. Such checks
       should be sufficient to detect incorrect operation of the
       encapsulator and Receiver (including reassembly errors following
       loss/corruption of TS Packets), in addition to protecting from loss
       and/or corruption by the transmission network (e.g., multiplexors
       and links).

    Expires November 2004                                        [page 18]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004



       Mechanisms exist in MPEG-2 transmission networks that may assist in
       detecting loss (e.g. the 4-bit continuity counter included as
       standard in the MPEG-2 TS Packet header).

       A convergence protocol should use an encapsulation that provides a
       strong integrity check. For ease of hardware implementation, this
       check should be carried in a trailer following the SNDU. A CRC-32 is
       sufficient for operation with up to a 12 KB payload, and may still
       provide adequate protection for larger payloads.

       4.6 Identification of Scope.

       The MPE section header contains information that may be used by the
       Receiver to identify the scope of the (MAC) address carried as a
       NPA, and prevent TS Packets intended for one scope to be received by
       another. Similar functionality may be achieved by ensuring that only
       IP packets that do not have overlapping scope are sent on the same
       TS Logical Channel. In some cases, this may imply the use of
       multiple TS Logical Channels.

       4.7 Extension Headers

       The evolution of the Internet service may in future require
       additional functions. A flexible protocol should therefore provide a
       way to introduce new features when required, without having to
       provide additional out-of-band configuration.

       IPv6 introduced the concept of extension headers that carry extra
       information necessary/desirable for certain subnetworks. The DOCSIS
       cable specification also allows a MAC header to carry extension
       headers to build operator-specific services. It is thus a
       requirement for the new encapsulation to allow extension headers.

       4.8 Summary of Requirements for Encapsulation

       The main requirements for an IP-centric encapsulation include:
          - support of IPv4 and IPv6 packets
          - support for Ethernet encapsulated packets
          - flexibility to support other IP formats and protocols (e.g.
            ROHC, MPLS)
          - easy processing by hardware devices
          - low overhead/managed overhead
          - a fully specified algorithm that allows a sender to pack
            multiple packets per SNDU and to easily locate packet fragments
          - extensibility
          - compatibility with legacy deployments
          - ability to allow link encryption, when required
          - capability to support a full network architecture including
            data, control and management planes


     Expires November 2004                                        [page 19]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    5. Address Resolution Functions

       Address Resolution (AR) provides a mechanism that associates L2
       information with the IP address of a system. Many L2 technologies
       employ unicast AR at the sender: an IP system wishing to send an IP
       packet encapsulates it and places it into a L2 frame.  It then
       identifies the appropriate L3 adjacency (e.g. next hop router, end-
       host) and determines the appropriate L2 adjacency (e.g. MAC address
       in Ethernet) to which the frame should be sent so that the packet
       gets across the L2 link.

       The L2 addresses discovered using AR are normally recorded in a data
       structure known as the arp/neighbor cache. The results of previous
       AR requests are usually cached. Further AR protocol exchanges may be
       required as communication proceeds to update or re-initialise the
       client cache state contents (i.e. purge/refresh the contents [ND]).
       For stability, and to allow network topology changes and client
       faults, the cache contents are normally "soft state", that is, they
       are aged with respect to time and old entries removed.

       In some cases (e.g. ATM, FR, X.25, MPEG-2 and many more), AR
       involves finding other information than the MAC address. This
       includes identifying other parameters required for L2 transmission,
       such as channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2
       TS).

       Address resolution has different purposes for unicast and multicast.
       Multicast address resolution is not required for many L2 networks,
       but is required for many MPEG-2 transmission networks.

       5.1 Address Resolution for MPEG-2

       There are three elements to the L2 information required to perform
       AR for a MPEG-2 TS. These are:

       (i)  A Receiver ID (e.g. a 6B MAC/NPA address).
       (ii) A PID or index to find a PID.
       (iii) Tuner information (e.g. a Transport Stream ID) that maps to a
       set of physical layer parameters.

       Elements (ii) and (iii) need to be de-referenced via indexes to the
       PMT when remultiplexors are used that may renumber the PID values,
       (i.e. PIDs are not intended to be end-to-end identifiers). However,
       although such use is common in broadcast TV networks, many private
       networks do not need to employ multiplexors that renumber PIDs (see
       section 3.2).

       The third element (iii) allows an AR client to resolve to a
       different MPEG TS Multiplex. This is used when there are several
       channels that may be used for communication (i.e. multiple
       outbound/inbound links). In a mesh system, this could be used to
       determine connectivity.

    Expires November 2004                                        [page 20]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       This AR information is used in two ways at a Receiver:

       (i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG
       TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set
       L2 filters to let traffic pass to the IP layer. This is used for
       unicast, and IPv4 subnet broadcast. Usually this is configured with
       the equivalent of an "ifconfig" on the interface.

       (ii) AR resolves an IP multicast address to the (MPEG TS Multiplex,
       PID, MAC/NPA address), and allows the Receiver to set L2 filters
       enabling traffic pass to the IP layer. This operation may need to be
       performed many times based on IGMP, MLD, and Multicast Routing
       protocol operation. A Receiver in a MPEG-2 TS network needs to
       resolve the PID value and tuning parameters associated with a TS
       Logical Channel and (at least for unicast) the destination Receiver
       NPA address.

       A star topology MPEG-2 TS transmission network is illustrated below,
       with two terminals receiving a forward broadcast channel sent by a
       Hub.  (A mesh system has some additional cases.) The forward
       broadcast channel consists of a "TS Multiplex" (a single physical
       bearer) allowing communication with the terminals. These communicate
       using a set of return channels.

          Forward broadcast
          MPEG-2TS          \
             ----------------X       /-----\
                            /       /       \
                                   | Receiver|
                        /----------+    A    |
                       /            \       /
           /-----\    /              \-----/
          /       \  /
         |   Hub   |/
         |         +\                /-----\
          \       /  \              /       \
           \-----/    \            | Receiver|
                       \-----------+    B    |
                                    \       /
                                     \-----/
       Figure 6: MPEG-2 Transmission Network with 2 Receivers

       There are three possibilities for unicast AR:
       (1) A system at a terminal, A, needs to resolve an address of a
       system that is at the hub;
        (2) A system at a terminal, A, needs to resolve an address that is
       at another terminal, B;
        (3) A host at the hub needs to resolve an address that is at a
       terminal. The sender (encapsulation gateway), uses AR to provide the
       (MPEG TS Multiplex, PID, MAC/NPA address) to be used to send
       unicast, IPv4 subnet broadcast and multicast packets.


    Expires November 2004                                        [page 21]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       If the Hub is as an IP router, then case (1) and (2) are the same:
       the host at the Receiver doesn't know the difference.  In these
       cases, the address to be determined is the L2 address of the device
       at the hub to which the IP packet should be forwarded, and which
       then relays the IP packet back to the forward (broadcast) MPEG-2
       channel after AR (case 3).

       If the hub is a L2 bridge, then case 2 still has to relay the IP
       packet back to the outbound MPEG-2 channel. The AR protocol needs to
       resolve the specific Receiver L2 MAC address of B, but needs to send
       this on a L2 channel to the Hub.  This requires terminals to be
       informed of the L2 address of other terminals.

       An end host connected to the hub needs to use the AR protocol to
       resolve the Receiver terminal MAC/NPA address. This requires the AR
       server at the Hub to be informed of the L2 addresses of other
       terminals.

       5.2 Scenarios for MPEG AR

       An AR protocol may transmit AR information in three distinct ways:

       (i) An MPEG-2 signalling table transmitted at the MPEG-2 level
       (ii) An MPEG-2 signalling table transmitted at the IP level (tbd, no
       implementations of this are known)
       (iii) An address resolution protocol transported over IP (as in ND)

       There are three distinct cases in which AR may be used:

       A. Multiple TS-Mux and the use of re-multiplexors; e.g. Digital
       Terrestrial, Satellite TV broadcast multiplexes. Many such systems
       employ remultiplexors that modify the PID values associated with TS
       Logical Channels as they pass through the MPEG-2 transmission
       network (see Scenario A of Section 3.1).

       B. Tuner configuration(s) that are fixed or controlled by some other
       process. In these systems, the PID value associated with a TS
       Logical Channel may be known by the Sender.

       C. A service run over one TS Mux (i.e., uses only one PID, for
       example DOCSIS and some current DVB-RCS multicast systems). In these
       systems, the PID value of a TS Logical Channel may be known by the
       Sender.

       5.2.1 Table-based AR over MPEG-2

       In current deployments of MPEG-2 networks, 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 was originally
       designed for audio/video distribution to set-top-boxes. The design

    Expires November 2004                                        [page 22]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       requires access to and processing of the SI table information (which
       is carried in MPEG-2 section format [ISO_DSMCC]). This scheme
       reflects the complexity of delivering and co-ordinating the various
       TS Logical Channels associated with a multimedia TV programme.

       One possible requirement to provide TS multiplex and PID information
       for IP services is to integrate additional information into the
       existing MPEG-2 tables, or to define additional tables specific to
       the IP service. The DVB INT and the A/92 Specification from ATSC
       [ATSC-A92] are examples of the realization of such a requirement.

       5.2.2 Table-based AR over IP

       AR information could be carried over a TS data channel, (e.g. using
       an IP protocol similar to the Service Announcement Protocol, SAP).
       Implementing this independently of the SI tables, would ease
       implementation, by allowing it to operate on systems where IP
       processing is performed in a software driver. It may also allow the
       technique to be more easily adapted to other similar delivery
       networks. It also is advantageous for networks which use the MPEG-2
       TS but links, but do not necessarily support audio/video services
       and therefore do not need to provide interoperability with TV
       equipment (e.g. links used solely for connecting IP (sub)networks).

       5.2.3. Query/Response AR over IP

       A query/response protocol may be used at the IP level (similar to,
       or based on IPv6 Neighbor Advertisements of the ND protocol). The AR
       protocol may operate over an MPEG-2 TS Logical Channel using a
       previously agreed PID (e.g. configured, or communicated using a SI
       table). In this case, the AR could be performed by the target system
       itself (as in arp and nd). This has good soft-state properties, and
       is very tolerant to failures. To find an address, a system sends a
       "query" to the network, and the "target" replies.

       5.3 Scoping

       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;

    Expires November 2004                                        [page 23]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


               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 using level 2 NPA addresses:

       (i)    The NPA address must be unique within the TS Logical Channel.
               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 1s 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
       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 an IP
       packet may lead to unexpected protocol behaviour. This also provides
       a security vulnerability since arbitrary packets may be passed to
       the IP layer.

       5.5 AR Authentication

       In many AR designs authentication has been overlooked, because of
       the wired nature of most existing IP networks, which makes it easy
       to control hosts physically connected. With wireless connections,
       this is changing: unauthorised hosts actually can claim L2
       resources. The address resolution client (i.e. Receiver) may also
       need to verify the integrity and authenticity of the AR information
       that it receives. There are trust relationships both ways: clients
       need to know they have a valid server and that the resolution is
       valid.Servers have a basic authorisation issue before they allow a L2
       address to be used.


    Expires November 2004                                        [page 24]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       The MPEG-2 transmission system may also require access control to
       prevent unauthorised use of the satellite bearer, however, this is
       an orthogonal issue to address resolution.

       5.6 Requirements for Unicast AR over MPEG-2

       The requirement for AR over MPEG-2 networks include:

       (i)    Use of a table based approach to promote AR scaling.  This
               requires definition of the frequency of update and volume of
               AR traffic generated.
       (ii)   Mechanisms to install AR information at the server
               (unsolicited registration).
       (iii)  Mechanisms to verify AR information held at the server
               (solicited responses). Appropriate timer values need to be
               defined.
       (iv)   An ability to purge client AR information (after IP network
               renumbering, etc.).
       (v)    Support of IP subnetwork scoping.
       (vi)   Appropriate security associations to authenticate the sender.


    6. Multicast Support

       This section addresses specific issues concerning IPv4 and IPv6
       multicast over MPEG-2 Transmission Networks. 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 drivers and operating systems from discarding unwanted
       multicast traffic.

       Multicast mechanisms are used at more than one protocol level. The
       upstream MPEG-2 router may forward multicast traffic on the MPEG-2
       TS link using a static or dynamic set of groups. When static
       forwarding is used, the set of groups may also be configured or set
       using SNMP, Telnet, etc. A Receiver normally uses either IGMP/MLD or
       multicast routing to establish membership tables that it uses to
       dynamically set local forwarding of received groups.  In a dynamic
       case, this group membership information is fed-back to the Sender to
       enable it to start sending new groups and (if required) to update
       the tables that it produces for multicast AR.

       Appropriate procedures need to identify the correct action when the
       same multicast group is available on more than one TS Logical
       Channel.  This could arise when different end hosts act as senders
       to contribute IP packets with the same IP group destination address.

    Expires November 2004                                        [page 25]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       It may also arise when a sender duplicates the same IP group over
       several TS Logical Channels (or even different TS Multiplexes), and
       in this case a Receiver may potentially receive more than one copy
       of the same packet. At the IP level, the host/router may be unaware
       of this duplication.

       6.1 Multicast AR Functions

       The functions required for multicast AR may be summarised as:
       (i) The Sender needs to know L2 mapping of multicast group.
       (ii) The Receiver needs to know L2 mapping of multicast group.

       In the Internet, multicast AR is normally a mapping function rather
       than a one-to-one association using a protocol. In Ethernet, the
       sender maps an IP address to a L2 MAC address, and the Receiver uses
       the same mapping to determine the L2 address to set a L2
       hardware/software filter entry.

       A typical sequence of actions for the dynamic case is:
       L3) Populate the IP L3 membership tables at the Receiver.
       L3) Receivers send/forward IP L3 membership tables to the Hub
       L3) Dynamic/static forwarding at hub/upstream router of IP L3 groups
       L2) Populate the IP AR tables at the encapsulator gateway
           (i.e. Map IP L3 mcast groups to L2 (PIDs))
       L2) Distribute the AR information to Receivers
       L2) Set Receiver L2 multicast filters for IP groups in the
           membership table.

       Multicast also introduces the concept of scoped addresses, requiring
       appropriate scoping to be followed. To be flexible AR must associate
       a Logical Channel (PID) not only with a group, possibly a QoS class,
       and other appropriate MPEG-2 TS attributes. Performing multicast AR
       at the IP level can enable providers wishing to provide
       independently scoped addresses would need to use multiple Multicast
       AR servers, one per multicast domain.  Explicit per group AR to
       individual L2 addresses is to be avoided.

    Expires November 2004                                        [page 26]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


           \
            |
        +---+----+   +--------+
        |  Tuner |---+TS Tabl | . . . .
        +---+----+   +--------+       .
            |                         .
        +--------+   +--------+       .
        | deMux  |---+PID Tabl|........
        +---+----+   +--------+       :
            |                         :
        +--------+   +--------+   +--------+
        |MPE/ULE |---+AR Cache|---+  MFIB  |
        +---+----+   +--------+   +--------+
            |            |            |
        +---+----+   +---+----+   +---+----+
        |  IP    |   |  AR    |   |IGMP/MLD|
        +---+----+   +---+----+   +---+----+
            |            |            |
            *------------+------------+
       Figure 7: Receiver Processing Architecture

       6.2 Requirements for Multicast over MPEG-2

       The requirements for supporting multicast include, but are not
       restricted to:

       (i)    Encapsulating multicast packets for transmission using a
               MPEG-2 TS.
       (ii)   Mapping IP multicast groups to the underlying MPEG-2 TS
               Logical Channel (PID) and the MPEG-2 TS Multiplex.
       (iii)  Provide AR information to allow a Receiver to locate an IP
               multicast flow within an MPEG-2 TS Multiplex.
        (v)   Error Reporting.

    7. Summary

       This document describes the architecture for a set of protocols to
       perform efficient and flexible support for IP network services over
       networks built upon the MPEG-2 Transport Stream (TS). It also
       describes existing approaches. It focuses on IP networking, the
       mechanisms that are used and their applicability to supporting IP
       unicast and multicast services.

       The requirements for a new encapsulation of IPv4 and IPv6 packets is
       described, outlining the limitations of current methods and the need
       for a streamlined IP-centric approach.

       The architecture also describes MPEG-2 Address Resolution (AR)
       procedures to allow dynamic configuration of the sender and Receiver
       using an MPEG-2 transmission link/network.  These support IPv4 and
       IPv6 services in both the unicast and multicast modes. Resolution
       protocols will support IP packet transmission using both the

     Expires November 2004                                        [page 27]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       Multiprotocol Encapsulation (MPE), which is currently
       widely deployed, and also any new optimised encapsulation.


    8. Security Considerations

       When the MPEG-2 network is not using a wireline network, the normal
       security issues relating to the use of wireless links for transport
       Internet traffic should be considered [ID-PILC-LINK].

       End-to-end security (including confidentiality, authentication,
       integrity and access control) is closely associated with the end-
       user assets that are protected. This close association cannot be
       ensured when providing security mechanisms only within a subnetwork
       (e.g. an MPEG-2 transmission network).  Several security mechanisms
       that can be used end-to-end have already been deployed in the
       general Internet and are enjoying increasing use. Important examples
       include:

       * The Secure Sockets Layer (SSL) and Transport Layer Security, TLS,
       which is primarily used to protect web commerce;
       * Pretty Good Privacy (PGP) and S/MIME, primarily used to protect
       and authenticate email and software distributions;
       * The Secure Shell (SSH), used to secure remote access and file
       transfer;
       * IPsec, a general purpose encryption and authentication mechanism
       above IP that can be used by any IP application.

       However, subnetwork security is also important [ID-PILC-LINK] and
       should be encouraged, on the principle that it is better than the
       default situation, which all too often is no security at all.  Users
       of especially vulnerable subnets (such as radio/broadcast networks
       and /or shared media Internet access) often have control over at
       most one endpoint - usually a client and therefore cannot enforce
       the use of end-to-end mechanisms.

       A related role for subnetwork security is to protect users against
       traffic analysis, i.e., identifying the communicating parties (by IP
       or MAC address) and determining their communication patterns, even
       when their actual contents are protected by strong end-to-end
       security mechanisms (this is important for networks such as
       broadcast/radio, where eaves-dropping is easy).

       Where it is possible for an attacker to inject traffic into the
       subnetwork control plane, subnetwork security can additionally
       protect the subnetwork assets.  This threat must specifically be
       considered for the protocols used for subnetwork control functions
       (e.g. address resolution, management, configuration). Possible
       threats include theft of service and denial of service; shared media
       subnets tend to be especially vulnerable to such attacks [ID-PILC-
       LINK]. Appropriate security functions must therefore be provided for

     Expires November 2004                                        [page 28]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       ipdvb control protocols [ID-PILC-LINK], particularly when the
       control functions are provided above the IP-layer using IP-based
       protocols. Internet level security mechanisms (e.g. IPSEC) can
       mitigate such threats.

       In general, End-to-End security is recommended for users of any
       communication path, especially when it includes a
       wireless/radio/broadcast link, where a range of security techniques
       already exist. Specification of security mechanisms at the
       application layer, or within the MPEG-2 transmission network are the
       concerns of organisations beyond the IETF. The complexity of any such
       security mechanisms should be considered carefully so that it will
       not unduly impact the IP operation.

     8.1 Link Encryption

       Link level encryption of IP traffic is commonly used in
       broadcast/radio links to supplement End-to-End security (e.g.
       provided by SSL, SSH, PGP, IPSec).  The encryption and key exchange
       methods vary significantly, depending on the intended application.
       For example, DVB-S/DVB-RCS operated by Access Network Operators
       (ANO) may wish to provide their customers (Internet Service
       Providers, ISP) with security services. Common targeted security
       services are: terminal authentication and data confidentiality (for
       unicast and multicast) between a gateway and Receivers. A common
       objective is to provide the same level of privacy as terrestrial
       links. An ISP may also wish to provide end-to-end security services
       to the end-users (based on the well known mechanisms such as IPSec).
       Therefore it is important to understand that both security solutions
       (ANO-to-ISP and ISP-to-end users) may co-exist.

       MPE supports optional link encryption using a pair of bits within
       the MPE protocol header to indicate the use of encryption.  To
       support optional link level encryption, it is recommended that a new
       encapsulation also supports optional encryption of the SNDU payload.
       Furthermore, it may be desirable to encrypt/authenticate some/all of
       the SNDU headers.  The method of encryption and the way in which
       keys are exchanged is beyond the scope of the ULE Specification.
       However, the specification must provide appropriate code points to
       allow such encryption to be implemented at the link layer.


    9. Acknowledgments

       The authors wish to thank Isabel Amonou , Torsten Jaekel, Pierre
       Loyer, Luoma Juha-Pekkaand and Rod Walsh for their detailed inputs.
       We also wish to acknowledge the input provided by the members of the
       IETF ipdvb WG.


    Expires November 2004                                        [page 29]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


    10. References

    10.1 Normative References

       [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).

       [RFC1122] B. Braden, ed., "Requirements for Internet Hosts  -
       Communication Layers", RFC 1122.

    10.2 Informative References

       [ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television
       Systems Committee (ATSC), Doc. A/53C, 2004.

       [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
       Systems Committee (ATSC), Doc. A/090, 2000.

       [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
       for the ATSC Data Broadcast Standard", Advanced Television Systems
       Committee (ATSC),Doc. A/91, 2001.

       [ATSC-A92] A/92  "Delivery of IP Multicast Sessions over ATSC Data
       Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92,
       2002.

       [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television
       Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A,
       2003.

       [ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
       Terrestrial Broadcast and Cable", Advanced Television Systems
       Committee (ATSC), Doc. A/65B, 2003.

       [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
       (DTV) Applications  over Satellite", Advanced Television Systems
       Committee (ATSC), Doc. A/80, 1999.

       [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet
       over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.

       [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).

     Expires November 2004                                        [page 30]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       [ETSI-DVBS] EN 301 421 Digital Video Broadcasting (DVB); Modulation
       and  Coding  for  DBS  satellite  systems  at  11/12  GHz,  European
       Telecommunications Standards Institute (ETSI).

       [ETSI-DVBT] EN 300 744 Digital Video Broadcasting (DVB); Framing
       structure, channel coding and modulation for digital terrestrial
       television (DVB-T), European Telecommunications Standards Institute
       (ETSI).

       [ID-IPDVB-ULE] Fairhurst, G., B. Collini-Nocker, "Simple Ultra
       Lightweight Encapsulation for transmission of IP datagrams over
       MPEG-2/DVB networks", Internet Draft, draft-ipdvb-ule-xx.txt, Work
       in Progress, IP-DVB WG.

       [ID-PILC-LINK] P. Karn  (ed) Advice for Internet Subnetwork
       Designers, Internet Draft draft-ietf-pilc-link-design-00.txt , Work
       in Progress, IETF PILC WG, BCP (with RFC-Ed).

       [ID-IPDVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for
       IP datagrams over MPEG-2 networks", Internet Draft, draft-fair-
       ipdvb-ar-00.txt, Work in Progress, IP-DVB WG.

       [ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.
       Schulzrinne, "Protocol Requirements for Internet Media Guides",
       Internet Draft, draft-ietf-mmusic-img-req-XX.txt, 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).

       [ISO-VID] ISO/IEC DIS 13818-2:1998 "Information technology -- Generic
       coding of moving pictures and associated audio information: Video",
       International Standards Organisation (ISO).

       [ISO-AUD] ISO/IEC 13818-3:1995 "Information technology -- Generic
       coding of moving pictures and associated audio information -- Part
       3: Audio", International Standards Organisation (ISO).

       [Ken87] Kent C.A., and J. C. Mogul, ?Fragmentation Considered
       Harmful", Proc. ACM SIGCOMM, USA, CCR Vol.17, No.5, 1988, pp.390-
       401.

       [RFC793] Postel, J., "Transmission Control Protocol", RFC791.

       [RFC1122] B. Braden, ed., "Requirements for Internet Hosts  -
       Communication Layers", RFC 1122.

    Expires November 2004                                        [page 31]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004



       [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
       Serial Links", RFC1144.

       [RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191.

       [RFC2507] Degermark, M., Nordgren, B., and Pink, S., "IP Header
       Compression", RFC2507.

       [RFC3077] Duros, E., W. Dabbous, H. Izumiyama, Y. Zhang, "A Link
       Layer Tunneling Mechanism for Unidirectional Links", RFC3077.

       [RFC3095] Bormann, C., et al, "RObust Header Compression (ROHC):
       Framework and four profiles: RTP, UDP ESP and uncompressed",
       RFC3095.

       http://www.atsc.org/standards/Code_Point_Registry.pdf

    11. Authors' Addresses

       Marie J. Montpetit
       MJMontpetit.com
       Email: marie@mjmontpetit.com

       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

       Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder
       Debartment of Scientific Computing
       University of Salzburg
       Jakob Haringer Str. 2
       5020 Salzburg
       Austria
       Email: [clausen|bnocker|hlinder]@cosy.sbg.ac.at
       Web: http://www.network-research.org







    Expires November 2004                                        [page 32]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    12. 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.

    13. 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.

    14. IANA Considerations

    A set of protocols which meet these requirements, will require the IANA
    to assign various numbers.  This document by itself, however, does not
    require any IANA involvement.

    Expires November 2004                                        [page 33]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    Appendix A: MPEG-2 Encapsulation Mechanisms

       To transmit packet data over an MPEG-2 transmission network requires
       that individual SNDUs (e.g. IPv4, IPv6 packets, or bridged Ethernet
       Frames) are encapsulated using a convergence protocol. The following
       encapsulations are currently standardised for MPEG-2 transmission
       networks:

       (i)     Multi-Protocol Encapsulation (MPE).
               The Multi-Protocol Encapsulation, MPE, specification of DVB
               [ETSI-DAT] uses private Sections for the transport of IP
               packets and uses encapsulation that is similar to the IEEE
               LAN/MAN standards [LLC]. Data packets are encapsulated in
               datagram sections that are compliant with the DSMCC section
               format for private data. Some Receivers may exploit section-
               processing hardware to perform a first-level filter of the
               packets that arrive at the Receiver.

               The section header also includes fields, which may be used by
               a Receiver to filter datagrams assigned to the same TS
               Logical Channel.  This feature allows several logical
               networks to be established without assigning PID values to
               each of the services. Section filtering is especially well
               suited for TV broadcast environments where remultiplexing
               comes into play.

               This encapsulation makes use of a MAC-level network point of
               attachment address. The address format conforms to the
               ISO/IEEE standards for LAN/MAN LLC]. The 48-bit MAC address
               field contains the MAC address of the destination; it is
               distributed over six 8-bit fields, labeled MAC_address_1 to
               MAC_address_6. The MAC_address_1 field contains the most
               significant byte of the MAC address, while MAC_address_6
               contains the least significant byte.  How many of these bytes
               are significant is optional and defined by the value of the
               broadcast descriptor table [SI-DAT] sent separately over
               another MPEG-2 TS within the TS multiplex.

               MPE is currently a widely deployed scheme. Due to investments
               in existing systems, usage is likely to continue in current
               and future networks.

       (ii)   Data Piping.
               The Data Piping profile [ETSI-DAT] is a minimum overhead,
               simple and flexible profile that makes no assumptions
               concerning the format of the data being sent. In this
               profile, the Receiver is intended to provide PID filtering,
               packet reassembly according to [DVB-SIDAT-368], error
               detection and optional Conditional Access (link encryption).

               The specification allows the user data stream to be
               unstructured or organized into packets. The specific

    Expires November 2004                                        [page 34]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


               structure is transparent to the Receiver. It may conform to
               any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc.

        (iii)  Data Streaming.
               The data broadcast specification profile [ETSI-DAT] for PES
               tunnels (Data Streaming) supports unicast and multicast data
               services that require a stream-oriented delivery of data
               packets. This encapsulation maps an IP packet into a single
               PES Packet payload.

               Two different types of PES headers can are selected via the
               stream_id values [ISO-MPEG]. The private_stream_2 value
               permits the use of the short PES header with limited
               overhead, while the private_stream_1 value makes available
               the scrambling control and the timing and clock reference
               features of the PES layer.



    Expires November 2004                                        [page 35]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    Appendix B: Address Resolution Use Cases

       Consider the case where a hub server collects a table of AR
       information. The collected AR information then needs to be
       redistributed to clients using the forward multicast link. The
       number of Receivers may range from 1 to many thousands.

       (i)  Example 1 Example protocol stack for Sender Side (2 interface)

       Consider a router with two logical interface (A,B) each to an IP
       network which could use either private or global IP addresses.  If
       AR is performed independently for each interface, the L2 addresses
       used by subnetworks A,B may also overlap or be globally unique. A
       separate association protocol could provide MPEG-2 other L2
       information (MPEG-2 TS Logical Channels / PID mappings, etc) to the
       IP systems in each of the connected IP networks. Both AR for L2
       addresses and for association with TS logical channel attributes may
       be performed by IP-level protocols using link-local IP multicast. A
       good solution may also permit multiple servers. A simple association
       protocol may only support networks that do not perform remux
       renumbering of PIDs. When this needs to be supported, a L2 table
       method may be used.

                              |
                     +--------+--------+
                     |      Port C     |
       +-------------+--------+--------+-------------+
       |                    Router                   |
       +-----------------+---------+-----------------+
       |      Port A     |         |      Port B     |
       +--------+--------+         +--------+--------+
       |  IP Interface 1 |         |  IP Interface 2 |
       |    (subnet)     |         |    (subnet)     |
       +------+----------+         +------+----------+
       | AR   |   +-------+        | AR   |   +-------+
       |Server|.. |   AR  +--+     |Server|.. |   AR  +--+
       +------+   | Cache |  |     +------+   | Cache |  |
                |  +-+-----+  |             |  +-+-----+  |
                |    | Assoc  |             |    | Assoc  |
                |    +--------+             |    +--------+
       +-------( )--------------+----------( )-----------+
       |     Encapsulator X     |    Encapsulator Y      |
       +---------+--------------+-----------+------------+
                 |                          |
                 +----->------+   +----<----+
                              |   |
                     +-------( )-( )--( )-----+
                     |       PID PID  PID     |
                     |        TS-Mux          |
                     +---------+--------------+
                               | Forward Link
                               | (Feed)

    Expires November 2004                                        [page 36]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       (ii) Example 2

       Suppose we have system B and a system A. The L2 address B is (Y:q)
       (i.e. Combination of MAC address, PID, TS) and the corresponding one
       for A is (X:p).

                               |  Forward   |
         +-------+  +-------+  |   Link     |  +-------+  +-------+
       --+AR     +--+Encaps +--------->--------+ A     +--+AR     +-
         |server |  |       |  |            |  |       |  |Client |
         +-------+  +-------+  |            |  +-------+  +-------+
                     +------+  |            |   +------+
                     |A:X:p |  |            |   |p:X:A |
                     +------+  |            |   +------+
                               |            |
         +-------+  +-------+  |            |  +-------+  +-------+
        -+AR     +--+ B     +---------<--------+Encaps +--+AR     +-
         |Client |  | Decaps|  |            |  |       |  |server |
         +-------+  +-------+  |   Return   |  +-------+  +-------+
                     +------+  |    Link    |   +------+
                     |q:Y:B |  |            |   |B:Y:q |
                     +------+  |            |   +------+
               IP addr B                         IP addr A

       For B to send to A, the encapsulation gateway at B needs to resolve
       the IP address of A to the l2 address of X and identify that this
       must be carried over (PID,TS) of p.

       A already knows its L2 address is X, this doesn't need to be
       communicated. It also knows or can determine it's layer 3 IP
       address. It can not determine the  (pid,TS-ID) to use, so it must be
       told p. Once it knows p it can tune and set the MPEG-2 demux filter.
       The corresponding addresses for B are Y and q.

       How do A and B find out X and Y?

       1) X can be preassigned to A (e.g. A L2 address assigned by a
       Receiver manufacturer), in which case, A has to tell the AR server
       at B informing it that it will be using X (register). The AR server
       at B could then inform other devices by sending an AR table that
       includes an entry that says A uses X (mesh). The encapsulator needs
       this information, and also other clients that need to send to A.

       2) B can assign X to A. B informs A that it is using X. B could then
       inform others by sending an AR table that includes an entry saying A
       uses X (mesh) or that B uses Y as a proxy (star).

       3) It is also possible that B does not know that A is using X. To
       find this out, it may query the network/a third party AR server (Y)
       looking for address A. A can then respond giving its resolved
       address (X), which B then uses. The way in which Y is found is to be
       determined (e.g. configured, or determined by a protocol mechanism).

    Expires November 2004                                        [page 37]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       (iii)        Example 3

       Assume a unicast (e.g. TCP) stream originates at a host, S, and is
       intended for an end host, R.
       The path between S and R includes an MPEG-2 link, with an
       encapsulator B and a Receiver A. The Receiver, A, acts as a router.

       The Encapsulator receives the IP packets from S and encapsulate them
       with an SNDU destination address field of X, this is performed by
       determining that A is not local to the subnetwork, but reached via
       router with the IP Address A corresponding to the L2 value of X. The
       packet is fragmented into TS-Packets and a PID assigned.

               +-------+ +------+
        +->----|AR     | |A:X   |
        |   +--+Server | +------+
        |   |  +-------+                 +---->  |
        |   |              |             |       |
        |   |              | Forward     +---->  |
        |   |   +-------+  |             |       |    +-------+
        |   +->-+Encaps +------------>---+---->-------+Decaps +----+->--
        |   >---+       |  | Data                |    |       |    |
        |  IP   +-------+  | A sent over X       |    +-------+   ++------+
        |  data  +------+  |                     |     +------+   |AR     |
        |        |A:X   |  | & AR Adverts (mcast)|     |X:A   | <-+Client |
        |        +------+  | A uses X            |     +------+   ++------+
        |                  | B uses Y            |                 |
        |  Encaps receives |                     | Cached values   |
        |  AR Tables       |                     | used for rx     |
        |                  |                     | AR of packets   |
        |  Cached values   |                     | own unicast addr|
        |  used for tx     |                     | & mcast addrs   |
        |                  |                     |                 |
        |                  |                     |                 |
        |                  | Reverse             |                 |
        |       +-------+  |                     |    +-------+    |
       -+--<----+Decaps +------------<----------------+Encaps +-<--+--<
         Decaps |       |  |                     |    |       |
                +-------+  | AR requests         |    +-------+
                           |  who-is-C?          |
                           |                     |
                           | & AR registration   |     IP addr A
                           |  I-am A I-use X     |

       For A to forward packets to B, the encapsulation gateway at A.
       For A to forward packets to B, the encapsulation gateway at A needs
       to resolve the IP address.of B to the L2 address X. A should already
       be listening on the L2 address X, because it is either the media-
       resolved of its A's IP address. (For multicast, this could be L2
       multicast IP address for a multicast group for which it has enabled
       a filter).

    Expires November 2004                                        [page 38]

    Internet Engineering Task Force                  Marie J. Montpetit ed.
    Internet Draft                                     MJMontpetit.com, USA
    Document: draft-ipdvb-arch-00.txt                       Gorry Fairhurst
                                                University of Aberdeen, U.K.
                                                           Horst D. Clausen
                                                     Bernhard Collini-Nocker
                                                               Hilmar Linder
                                             University of Salzburg, Austria




    Category: Informational                                        July 2004


    A Framework for transmission of 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


    Abstract

       This document describes a new architecture for the transport of IP
       Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has
       been widely accepted not only for providing digital TV services, but
       also as a subnetwork technology for building IP networks. Examples
       of systems using MPEG-2 include the Digital Video Broadcast (DVB)
       and Advanced Television Systems Committee (ATSC) Standards for
       Digital Television.

       The document identifies the need for a set of Internet standards
       defining the interface between the MPEG-2 Transport Stream and an IP
       subnetwork. It suggests a new encapsulation method for IP datagrams,
       and proposes protocols to perform IPv6/IPv4 address resolution, to
       associate IP packets with the properties of the Logical Channels
       provided by an MPEG-2 TS.

    Expires November 2004                                         [page 1]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004



       Table of Contents

       1. Introduction
       2. Conventions Used in this Document
       3. Architecture
       4. Encapsulation Protocol
       5. Address Resolution Functions
       6. Multicast Support
       7. Summary
       8. Security Considerations
       9. Acknowledgments
       10. References
       11. Author's Addresses
       12. IANA Considerations
       Appendices





    Expires November 2004                                         [page 2]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       Document History

       -00 Current version



    Expires November 2004                                         [page 3]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       1. Introduction

       This document identifies requirements and an architecture for transport
       of IP Datagrams over ISO MPEG-2 Transport Streams [MPEG2]. The prime
       focus is the efficient and flexible delivery of IP services over
       those subnetworks that use the MPEG-2 transport stream.

       Hence, the architecture is designed to be compatible with services
       based on MPEG-2, for example the Digital Video Broadcast (DVB)
       architecture, the Advanced Television Systems Committee (ATSC)
       system [ATSC; ATSC-G], and other similar MPEG-2 based transmission
       systems. Such systems typically provide unidirectional (simplex)
       physical and link layer standards, and have been defined for a wide
       range of physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-
       TC], Satellite TV [ETSI-DVBS; ATSC-S] and Cable Transmission [ETSI-
       DVBC; ATSC-PSIP-TC]).

             +---------+-+-+-+-+------+--------+---+--+--+
             |         |T|V|A|O|  O   |        | O |S |O |
             |         |e|i|u|t|  t   |        | t |I |t |
             |         |l|d|d|h|  h   |   IP   | h |  |h |
             |Protocols|e|e|i|e|  e   |        | e |T |e |
             |native   |t|o|o|r|  r   |        | r |a |r |
             |over     |e| | | |      |        |   |b |  |
             |MPEG-2 TS|x| | | |      |   +----+-+ |l |  |
             |         |t| | | |      |   | MPE  | |e |  |
             |         | | | | |   +--+---+------+ |  |  |
             |         | | | | |   | AAL5 |Priv. | |  |  |
             |         +-+-+-+-+---+------+      +-+--+--+
             |         | PES   |  ATM     |Sect. |Section|
             +---------+-------+----------+------+-------+
             |               MPEG-2 TS                   |
             +---------+-------+-------+-----------------+
             |Satellite| Cable | D-TV  |    Other PHY    |
             +---------+-------+-------+-----------------+

       Figure 1: Overview of the MPEG-2 protocol stack

       Although many MPEG-2 systems carry a mixture data types, MPEG-2
       components may, and are, also used to build IP-only networks.
       Often, those networks do not implement all parts of a DVB / ATSC
       system, and may for instance support minimal, or no, signalling of
       Service Information (SI) tables. Standard system components offer
       advantages of improved interoperability and larger deployment.

    1.1 Salient features of the Architecture

       The architecture proposed in this document describes a set of protocols
       to support transmission of IP packets over the MPEG-2 TS. Key
       characteristics of these networks are that they may provide link-
       level broadcast capability, and that many supported applications
       require access to a very large number of subnetwork nodes.  Some or

    Expires November 2004                                         [page 4]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       all of these protocols may also be applicable to other subnetworks,
       e.g., other MPEG-2 transmission networks, regenerative satellite
       links [ETSI-BSM], and some types of broadcast wireless links. The
       key goals of the architecture are to reduce complexity when using the
       system, while improving performance, increasing flexibility for IP
       services, and providing opportunities for better integration with IP
       services.

       Since a majority of MPEG-2 transmission networks are bandwidth-
       limited, encapsulation protocols must therefore add minimal overhead
       to ensure good link efficiency while providing adequate network
       services. They also needs to be simple to minimize processing,
       robust to errors and security threats, and extensible to a wide
       range of services.

       In MPEG-2 systems, logical channels provide multiplexing,
       addressing, and error reporting. The logical channel may also be
       used to provide Quality of Service (QoS). Mapping functions are
       required to relate Logical Channels to IP addresses, to map Logical
       Channels to IP-level QoS, and to associate IP flows with specific
       subnetwork capabilities.  An important feature of the proposed
       architecture will be to provide these functions in a dynamic way,
       allowing transparent integration with other IP-layer protocols.
       Collectively, these will form a MPEG-2 TS address resolution
       protocol suite.




    Expires November 2004                                         [page 5]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    2. Conventions Used In This Document

       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.

       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 Media 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.

       ENCAPSULATOR: A network device that receives Ethernet frames or IP
       packets, and formats these for output as a transport stream of TS
       Packets.

       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.

       MAC: Medium Access and Control of the Ethernet IEEE 802 standard of
       protocols (see also NPA).

       MPE: Multiprotocol Encapsulation [ETSI-DAT]. 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 6]

    INTERNET DRAFT  Architecture for IP transport over DVB        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. A PID of 8191 (decimal)
       indicates a null packet that must be discarded by a Receiver.


       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.

       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.

       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 November 2004                                         [page 7]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    3. Architecture

       The following sections introduce the components of the MPEG-2
       Transmission network and relate these to a networking framework.

    3.1 MPEG-2 Transmission Networks

       There are many possible topologies for the MPEG-2 Transmission
       Networks. A number of example scenarios are briefly described below,
       and the following text relates specific functions to this set of
       scenarios.

       A) Broadcast TV and Radio Delivery
       The principal service in the Broadcast TV and Radio Delivery
       scenario is Digital TV and/or Radio and their associated data [ID-
       MMUSIC-IMG]. Such networks typically contain two components: the
       contribution feed and the broadcast part.  Contribution feeds
       provide communication from a typically small number of individual
       sites (usually at high quality) to the Hub of a broadcast network.
       The traffic carried on contribution feeds is typically encrypted,
       and is usually processed prior to being resent on the Broadcast part
       of the network. The Broadcast part uses a star topology centred on
       the Hub to reach a typically large numbers of down-stream Receivers.
       Although such networks may provide IP transmission, they do not
       necessarily provide access to the public Internet.

       B) Broadcast Networks used as an ISP
       Another scenario resembles that above, but includes the provision of
       IP-services providing access to the public Internet. The IP traffic in
       this scenario is typically not related to the digital TV/Radio content,
       and the service may be operated by an independent operator such as uni-
       directional File Delivery or bi-directional ISP access. The IP service
       must adhere to the full system specification used for the broadcast
       transmission, including allocation of PIDs, and generation of
       appropriate MPEG-2 control information (e.g. DVB and ATSC SI tables).

       C) Uni-directional Star IP Scenario
       The Uni-directional Star IP Scenario utilises a Hub station to
       provide a data network delivering a common bit stream to medium-
       sized groups of Receivers. MPEG-2 transmission technology provides
       the forward physical and link layers for this transmission, the
       return link (if required) is provided by other means. IP services
       typically form the main proportion of the transmission traffic. Such
       networks may not necessarily implement the MPEG-2 control plane.

       D) Data-cast overlay
       The Data-cast overlay scenario employs MPEG-2 physical and link
       layers to provide additional connectivity such as uni-directional
       multicast to supplement an existing IP-based Internet service.
       Examples of such a network includes IP Datacast to mobile wireless
       receivers [ID-MMUSIC-IMG].


    Expires November 2004                                         [page 8]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       E) Point-to-point links
       Point-to-point connectivity may be provided using a pair of transmit
       and receive interfaces supporting the MPEG-2 physical and link
       layers.  Typically the transmission from a sender is received by
       only one or a small number of Receive terminals. Examples include
       the use of transmit/receive DVB-S terminals to provide satellite
       links between ISPs utilising BGP routing.

       F) Two-Way IP Networks
       Two-Way IP networks are typically satellite-based and star-based
       utilising a Hub station to deliver a common bit stream to medium-
       sized groups of receivers. A bi-directional service is provided over
       a common air-interface. The transmission technology in the forward
       physical and link layers for this transmission is MPEG-2, which may
       also be used in the return direction. Such systems also usually
       include a control plane element to manage the (shared) return link
       capacity. A concrete example is the DVB-RCS system. IP services
       typically form the main proportion of the transmission traffic.

       Scenarios A-D employ uni-directional MPEG-2 Transmission networks.
       For satellite-based networks, these typically have a star topology,
       with a central Hub providing service to large numbers of down-stream
       Receivers. Terrestrial networks may employ several transmission Hubs
       each serving a particular coverage cell with a community of
       Receivers.

       From an IP viewpoint, the service is typically either uni-
       directional multicast, or a bi-directional service in which some
       complementary link technology (e.g. Modem, LMDS, GPRS, ...) is used
       to provide the return path from Receivers to the Internet.  Routing


       in this case could be provided using Uni-Directional Link Routing
       (UDLR) [RFC3077].

       Note that only Scenarios A-B actually carry MPEG-2 video and audio
       intended for reception by digital Set Top Boxes (STBs) as the
       primary traffic. The other scenarios are IP-based data networks and
       need not necessarily implement the MPEG-2 control plane.

       Scenarios E-F provide two-way connectivity using MPEG-2
       transmission.  Such networks provide direct support for bi-
       directional protocols above and below the IP layer.

       The complete MPEG-2 transmission network may be managed by a
       transmission service operator. In such cases, the assignment of
       addresses and TS Logical Channels at Receivers are usually under the
       control of the service operator.  Examples include a TV operator
       (Scenario A), or an ISP (Scenarios B-F).  MPEG-2 transmission
       networks are also used for private networks. These typically involve
       a smaller number of Receivers and do not require the same level of
       centralised control. Examples include companies wishing to connect
       DVB-capable routers to form links within the Internet (Scenario B).

    Expires November 2004                                         [page 9]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    3.2 TS Logical Channels

       An MPEG-2 transport multiplex offers a number of parallel channels,
       which are known here as TS Logical Channels.  Each MPEG-2 TS Logical
       Channel is uniquely identified by the Packet ID, PID, value carried
       in the header of each MPEG-2 TS Packet. The PID value is a 13 bit
       field and, thus, the number of available channels is limited to 8192
       (decimal), some of which are reserved for transmission of SI tables.
       Non-reserved TS Logical Channels may be use to carry audio [ISO-AUD],
       video [ISO-VID], IP packets [ISO-DSMCC; ETSI-DAT; ATSC-DAT],
       or other data [ISO-DSMCC; ETSI-DAT; ATSC-DAT]. The value 8191
       (decimal) indicates a null packet, used to maintain the physical
       bearer bit rate when there are no other MPEG-2 TS Packets to be
       sent.

              TS-LC-A-1         /---\--------------------/---\
                      \        /     \                  /     \
                       \      |       |                |       |
           TS-LC-A-2    -----------   |                | -------------
               --------------------   |                | -------------
                              |       |                |       |
                         /--------   /                 | -------------
                        /      \----/-------------------\----/
              TS-LC-A-3/               MPEG-2 TS MUX A
                      /
        TS-LC        /
        ------------X
                     \ TS-LC-B-3 /---\------------------------/---\
                      \         /     \                      /     \
                       \       |       |                    |       |
           TS-LC-B-2    \-----------   |                    | ---------
                --------------------   |                    | ---------
                               |       |                    |       |
                          /--------   /                     | ---------
                         /      \----/-----------------------\----/
                        /                 MPEG-2 TS MUX B
             TS-LC-B-1

         Figure 2: Example showing MPEG-2 TS Logical Channels carried over
                               2 MPEG-2 TS Multiplexes.

       TS Logical Channels are independently numbered on each MPEG-2 TS
       Multiplex (MUX).  In most cases the data sent over the TS Logical
       Channels will differ for different multiplexes. The above figure
       shows a set of TS Logical Channels sent using two MPEG-2 TS
       Multiplexes (A and B).

       There are cases where the same data may be distributed over two or
       more multiplexes (e.g., some SI tables; multicast content which
       needs to be received by Receivers tuned to either MPEG-2 TS; unicast
       data were the Receiver may be in either/both two potentially
       overlapping MPEG-2 transmission cells). In figure 2, each multiplex

    Expires November 2004                                        [page 10]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       carries 3 MPEG-2 TS Logical Channels. These Logical Channels may
       differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be
       common to both MPEG-2 TS Multiplexes (i.e. TS-LC-A-3 and TS-LC-B-3
       carry identical content).

       As can been seen above, there are similarities between the way PIDs
       are used and the operation of virtual channels in ATM. However,
       unlike ATM, a PID defines a unidirectional broadcast channel and not
       a point-to-point link. Contrary to ATM, there is, as yet, no
       specified standard interface for MPEG-2 connection setup, or for
       signalling mappings of IP flows to PIDs, or to set the Quality of
       Service, QoS, assigned to an TS Logical Channel.

    3.3  Multiplexing and Re-Multiplexing

       In a simple example, one or more TS are processed by a MPEG-2
       multiplexor resulting in a TS Multiplex. The TS Multiplex is
       forwarded over a physical bearer towards one or more Receivers
       (figure 3).

          +------------+                                  +------------+
          |  IP        |                                  |  IP        |
          |  End Host  |                                  |  End Host  |
          +-----+------+                                  +------------+
                |                                                ^
                +------------>+---------------+                  |
                              +  IP           |                  |
                +-------------+  Encapsulator |                  |
        SI-Data |             +------+--------+                  |
        +-------+-------+            |MPEG-2 TS Logical Channel  |
        |  MPEG-2       |            |                           |
        |  SI Tables    |            |                           |
        +-------+-------+   ->+------+--------+                  |
                |          -->|  MPEG-2       |                . . .
                +------------>+  Multiplexor  |                  |
        MPEG-2 TS             +------*--------+                  |
        Logical Channel              |MPEG-2 TS Mux              |
                                     |                           |
                   Other    ->+------+--------+                  |
                   MPEG-2  -->+  MPEG-2       |                  |
                   TS     --->+  Multiplexor  |                  |
                         ---->+------+--------+                  |
                                     |MPEG-2 TS Mux              |
                                     |                           |
                              +------+--------+           +------+-----+
                              |Physical Layer |           |  MPEG-2    |
                              |Modulator      +---------->+  Receiver  |
                              +---------------+  MPEG-2   +------------+
                                                 TS Mux

        Figure 3: An example configuration for a uni-directional service
                  for IP transport over MPEG-2

    Expires November 2004                                        [page 11]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       In a more complex example, the same TS may be fed to multiple MPEG-2
       multiplexors and these may, in turn, feed other MPEG-2 multiplexors
       (remultiplexing). Remultiplexing may occur in several places (and is
       common in Scenario A of section 3.1). One example is a satellite
       that provides on-board processing of the TS packets, multiplexing
       the TS Logical Channels received from one or more up-link physical
       bearers (TS Multiplex) to one (or more in the case of
       broadcast/multicast) down-link physical bearer (TS Multiplex). As
       part of the remultiplexing process, a remultiplexor may renumber the
       PID values associated with one or more TS Logical Channels to
       prevent clashes between input TS Logical Channels with the same PID
       carried on different input multiplexes. It may also modify and/or
       insert new SI data into the control plane to reflect the content
       output using TS Multiplex.

       In all cases, the final result is a "TS Multiplex" which is
       transmitted over the physical bearer towards the Receiver.

    3.4  IP Datagram Transmission

       Packet data for transmission over the MPEG-2 transport multiplex is
       passed to an Encapsulator, sometimes known as a Gateway.  This
       receives Protocol Data Units, PDUs, such as Ethernet frames or IP
       packets, and formats each into a Sub-Network Data Unit, SNDU, by
       adding an encapsulation header and trailer (see section 5). The
       SNDUs are subsequently fragmented into a series of TS Packets.

       To receive IP packets over a MPEG-2 transport multiplex, a Receiver
       needs to identify the specific TS Multiplex (physical link) and also
       the TS Logical Channel (the PID value of a logical link). It is
       common for a number of MPEG-2 TS Logical Channels to carry SNDUs,
       and a Receiver must therefore filter (accept) IP packets sent with a
       number of PID values, and must independently reassemble each SNDU.

       A Receiver that simultaneously receives from several TS Logical
       Channels, must filter other unwanted TS Logical Channels by
       employing for example specific hardware support. Packets for one IP
       flow (i.e. a specific combination of IP source and destination
       addresses) must be sent using the same PID. It should not be assumed
       that all IP packets are carried on a single PID, as in some cable
       modem implementations, and multiple PIDs must be allowed in the
       architecture. Many current hardware filters limit the maximum number of
       active PIDs (e.g. 32), although if needed, future systems may
       reasonably be expected to support more.

       In some cases, Receivers may need to select TS Logical Channels from
       a number of simultaneously active TS Multiplexes. To do this, they
       need multiple physical receive interfaces (e.g., RF front-ends and
       demodulators). Some applications also envisage the concurrent

    Expires November 2004                                        [page 12]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       reception of IP Packets over other media that may not necessarily
       use MPEG-2 transmission.

       Bi-directional (duplex) transmission can be provided using a MPEG-2
       transmission network by using one of a number of alternate return
       channel schemes [DVB-RC]. Duplex IP paths may also be supported
       using non-MPEG-2 return links (e.g. in Scenarios B-D of section
       3.1). One example of such an application is that of Uni-Directional
       Link Routing, UDLR [RFC3077].

       The DVB family of standards currently defines a mechanism for
       transporting an IP packet, or Ethernet frame using the Multi-
       Protocol Encapsulation (MPE) [ETSI-DAT]. This scheme is also
       supported in ATSC [ATSC-DAT; ATSC-DATG]. It allows transmission of
       IP packets or Ethernet style frames in the control plane associated
       with audio/video transport. Data is formatted as if it were a Table
       Section. The MPE specification includes a set of optional header
       components and requires decoding of the control headers.  This
       processing is suboptimal for Internet traffic, since it incurs
       significant receiver processing overhead and some extra link
       overhead [CLC99].

                   +-----------------------------------------+
                   |Encap Header|       Subnetwork DU        |
                   +-----------------------------------------+
                  /         /                          \      \
                 /         /                            \      \
                /         /                              \      \
        +------+----------+  +------+----------+   +------+----------+
        |MPEG-2| MPEG-2   |..|MPEG-2| MPEG-2   |...|MPEG-2| MPEG-2   |
        |Header| Payload  |  |Header| Payload  |   |Header| Payload  |
        +------+----------+  +------+----------+   +------+----------+

         Figure 4: Encapsulation of an SNDU (e.g., IP packet) into a series
        of MPEG-2 TS Packets (each TS Packet carries a header with a common
           Packet ID, PID, value denoting the MPEG-2 TS Logical Channel).

    3.5 Motivation

       The network layer protocols to be supported by this architecture
       include:
       (i) IPv4 Unicast packets, destined for a single end host
       (ii) IPv4 Broadcast packets, sent to all end systems in an IP
       network
       (iii) IPv4 Multicast packets
       (iv) IPv6 Unicast packets, destined for a single end host
       (v) IPv6 Multicast packets
       (vi) Packets with compressed IPv4 / IPv6 packet headers (e.g.
       [RFC1114; RFC2507; RFC3095])
       (vii) Bridged Ethernet frames
       (viii) Other (MPLS, IPv6 anycast, potential new protocols__

    Expires November 2004                                        [page 13]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       The architecture will provide:

       (i)  Guidance on which MPEG-2 features are pre-requisites for the IP
            service, and identification of any optional fields that impact
            performance/correct operation.

       (ii) Standards to provide an efficient and flexible encapsulation
            scheme that may be easily implemented in an Encapsulator or
            Receiver. The payload encapsulation requires a type field for
            the SNDU to indicate the type of packet and a mechanism to
            signal which encapsulation is used on a certain PID.

       (iii) Standards to associate a particular IP address with a Network
            Point of Attachment (NPA) that could or could not be a MAC
            Address. This process resembles the IPv4 Address Resolution
            Protocol, ARP, or IPv6 Neighbour Discovery, ND, protocol [AR-
            DRAFT]. In addition, the standard will be compatible with IPv6
            autoconfiguration.

       (iv) Standards to associate a MPEG-2 TS interface with one or more
            specific TS Logical Channels (PID, TS Multiplex). Bindings are
            required for both unicast transmission, and multicast reception.
            In the case of IPv4 this must also support network broadcast. To
            make the schemes robust to loss and state changes within the
            MPEG-2 transmission network, a soft-state approach may prove
            desirable.

       (v)  Standards to associate the capabilities of a MPEG-2 TS Logical
            Channel with IP flows. This includes mapping of QoS functions,
            such as IP QoS/DSCP and RSVP, to underlying MPEG-2 TS QoS,
            multi-homing and mobility. This capability could be associated
            by the AR standard proposed above.

       (vi) Guidance on Security for IP transmission over MPEG-2. The
            framework must permit use of IPSEC and clearly identify any
            security issues concerning the specified protocols. The security
            issues need to consider two cases: unidirectional transfer (in
            which communication is only from the sending IP end host to the
            receiving IP end host) and bi-directional transfer.
            Consideration should also be given to security of the TS
            Multiplex: the need for closed user groups and the use of MPEG-2
            TS encryption.

       (vii) Management of the IP transmission, including standardised SNMP
            MIBs and error reporting procedures. The need for and scope of
            this is to be determined.

       The specified architecture and techniques should be suited to a range
       of systems employing the MPEG-2 TS, and may also suit other (sub)
       networks offering similar transfer capabilities.

    Expires November 2004                                        [page 14]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       The following sections 4 and 5 describe encapsulation issues.
       Sections 6 and 7 describe address resolution issues for unicast and
       multicast. The appendix provides some use cases.

    4. Encapsulation Protocol Requirements

       This section identifies requirements and provides examples of
       mechanisms that may be used to perform the encapsulation of IPv4 and
       IPv6 multicast and unicast packets over MPEG-2 transmission
       networks.

       The encapsulation protocol transports a SNDU over the MPEG-2 TS
       service and provides the appropriate mechanisms to deliver this to
       the Receiver IP interface. A convergence protocol typically adds
       header fields before a SNDU that carry protocol control information
       such as length of SNDU, Receiver address, multiplexing information,
       payload type, sequence numbers etc.  The SNDU payload is typically
       followed by a trailer, which carries an Integrity Check (e.g.,
       Cyclic Redundancy Check, CRC). Some protocols also add additional
       control information and/or padding to or after the trailer.

               +--------+-------------------------+-----------------+
               | Header |            SNDU         | Integrity Check |
               +--------+-------------------------+-----------------+

           Figure 5: Encapsulation of a subnetwork PDU (e.g. IPv4 or IPv6
                     packet) to form an MPEG-2 Payload Unit.

       Examples of existing convergence protocols include ATM AAL5 [ITU-
       AAL5], and MPEG-2 MPE [ETSI-DAT].

       The existing proposals and standards for use with MPEG-2 carry
       heritage from legacy implementations that reflect the limitations of
       technology at their deployment.  For example a majority are more
       dominated by audio/video considerations than IP requirements. This
       justifies the development of a new encapsulation that will be truly
       IP-centric. Carrying IP packets over a TS Logical Channel involves
       several convergence protocol functions. This section briefly
       describes these functions and highlights the requirements for a new
       encapsulation.

       4.1 Payload_Unit Delimitation

       MPEG-2 indicates the start of a Payload Unit in a new TS Packet with
       a "start_of_payload_unit_indicator" (PUSI) [ISO-MPEG] carried in the
       4B TS Packet header. The PUSI is a 1 bit flag that has normative
       meaning [ISO_MPEG] for TS Packets that carry PES Packets or PSI
       data.

       When the payload of a TS Packet contains PES data, a PUSI value of
       '1' indicates the TS Packet payload starts with the first byte of a

    Expires November 2004                                        [page 15]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       PES Packet. A value of '0' indicates that no PES Packet starts in
       this TS Packet. If the PUSI is set to '1', then one, and only one,
       PES Packet starts in the TS Packet.

       When the payload of the TS Packet contains PSI data, a PUSI value of
       '1' indicates the first byte of the TS Packet payload carries a
       payload pointer that indicates the position of the first byte of the
       Payload Unit (Section) being carried; if the TS Packet does not
       carry the first byte of a Section, the PUSI is set to '0',
       indicating that there is no payload pointer.

       Using this PUSI bit, the start of the first Payload Unit in a TS
       Packet is exactly known by the Receiver, unless that TS Packet has
       been corrupted or lost in the transmission. In which case, the
       payload is discarded until the next TS Packet is received with a
       PUSI value of '1'.

       The encapsulation should allow packing of more than one SNDU into
       the same TS Packet and should not limit the number of SNDUs that can
       be sent in a TS Packet.  In addition, it should allow an IP
       Encapsulator to insert padding when there is an incomplete TS Packet
       payload. A mechanism needs to be identified to differentiate this
       padding from the case where another encapsulated SNDU follows.

       A combination of the PUSI and a Length Indicator (see below) allows
       an efficient MPEG-2 convergence protocol to receive accurate
       delineation of packed SNDUs.  The MPEG-2 standard [ISO_MPEG] however
       does not specify how private data should use the PUSI bit.

       4.2 Length Indicator

       Most services using MPEG-2 include a length field in the payload
       header to allow the Receiver to identify the end of a payload unit
       (e.g. PES Packet, Section, or an SNDU).

       When parts of more than two Payload Units are carried in the same TS
       Packet, only the start of the first is indicated by the Payload
       Pointer. Placement of a Length Indicator in the encapsulation header
       allows a Receiver to determine the number of bytes until the start
       of the next encapsulated SNDU. This placement also provides the
       opportunity for the Receiver to pre-allocate an appropriate-sized
       memory buffer to receive the reassembled SNDU.

       A Length Indicator is required, and should be carried in the
       encapsulation header.  This should support SNDUs of at least the MTU
       size offered by Ethernet (1500 bytes). Although the IPv4 and IPv6
       packet format permits an IP packet of size up to 64 KB, such packets
       are seldom seen on the current Internet. Since high speed links are
       often limited by the packet forwarding rate of routers, there has
       been a tendency for Internet core routers to support MTU values
       larger than 1500 bytes. A value of 16 KB is not uncommon in the core

    Expires November 2004                                        [page 16]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       of the current Internet.  This would seem a suitable maximum size
       for an MPEG-2 transmission network.

       4.3 Next Level Protocol Type

       A key feature of the new encapsulation is to identify the type of
       payload being transported (e.g., to differentiate IPv4, IPv6 etc.).
       Most protocols use a type field to identify a specific process at
       the next higher layer that is the originator or the recipient of the
       payload (SNDU). This method is used by IPv4, IPv6, and also by the
       original Ethernet protocol (DIX). OSI uses the concept of a
       'Selector' for this, (e.g. in the IEEE 802/ISO 8802 standards for
       CSMA/CD [LLC], although in this case a SNAP (subnetwork access
       protocol) header is also required for IP packets.

       A Next Level Protocol Type field is also required if compression
       (e.g. Robust Header Compression, ROHC) is supported. No compression
       method has currently been defined that is directly applicable to
       this architecture, however the ROHC framework defines a number of
       header compression techniques that may yield considerable
       improvement in throughput on links which have a limited capacity.
       Since many MPEG-2 transmission networks are wireless the ROHC
       framework will be directly applicable for many applications. Use of
       ROHC implies the need to transfer smaller SNDUs and the need for
       additional processing at the Receiver to expand the received
       compressed packets. The selected type field should contain
       sufficient code points to support this technique.

       It is thus a requirement to include a Next Level Protocol Type field
       in the encapsulation header.  Such a field should specify values for
       at least IPv4, IPv6, and must allow for other values (e.g., MAC-
       level bridging).

       4.4 L2 Subnet Addressing

       In MPEG-2, the PID carried in the TS Packet header is used to
       identify individual services with the help of SI tables. This was
       primarily intended as a unidirectional (simplex) broadcast system. A
       TS Packet stream carries either tables or one PES Packet stream
       (i.e., compressed video or audio). Individual Receivers are not
       addressable at this level.

       IPv4 and IPv6 allocate addresses to end hosts and intermediate
       systems (routers). Each system (or interface) is identified by a
       globally assigned address.  ISO uses the concept of a hierarchically
       structured Network Service Access Point (NSAP) address to identify
       an end user process in an Internet environment.

       Within a local network a completely different set of addresses for
       the Network Point of Attachment (NPA) is used; frequently these NPA
       addresses are referred to as Medium Access Control, MAC-level
       addresses. In the Internet they are also called hardware addresses.

    Expires November 2004                                        [page 17]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       Whereas network layer addresses are used for routing, NPA addresses
       are primarily used for Receiver identification.

       Receivers may use the NPA of a received SNDU to reject unwanted
       unicast packets within the (software) interface driver at the
       Receiver, but must also perform forwarding checks based on the IP
       address. IP multicast and broadcast may also filter based using the
       NPA, but Receivers must also filter unwanted packets at the network
       layer based on source and destination IP addresses.  This does not
       imply that each IP address must map to a unique NPA (more than one
       IP address may map to the same NPA). If a separate NPA address is
       not required, the IP address is sufficient for both functions.

       If it is required to address an individual Receiver in an MPEG-2
       transport system, this can be achieved either at the network level
       (IP address) or via a hardware-level NPA address (MAC-address).  If
       both addresses used, they must be mapped either in a static or a
       dynamic way (e.g., by an address resolution process). A similar
       requirement may also exist to identify the PID and TS multiplex on
       which services are carried.

       Using an NPA address in a MPEG-2 transport system may enhance
       security, in that a particular payload may be targeted for a
       particular Receiver by specifying the Receiver NPA address. This is
       however only a weak form of security, since the NPA filtering is
       often reconfigurable (frequently performed in software), and may be
       modified by a user to allow reception of specified (or all) packets,
       similar to promiscuous mode operation in Ethernet. If security is
       required, it should be applied at another place (e.g. link
       encryption, authentication of address resolution, IPSEC, transport
       level security and/or application level security).

       There are also cases where the use of a NPA is required (e.g. where
       a system operates as a router) and if present this should be carried
       in encapsulation header where it may be used by Receivers as a pre-
       filter to discard unwanted SNDUs. The addresses allocated do not
       need to conform to the IEEE MAC address format. There are many cases
       where a NPA is not required, and network layer filtering may be used.
       A new encapsulation protocol should therefore support an optional NPA.

       4.5 Integrity Check

       For the IP service, the probability of undetected packet error
       should be small (or negligible) [ID-PILC-LINK]. There is therefore a need
       for a CRC to verify correctness of a received IP packet. Such checks
       should be sufficient to detect incorrect operation of the
       encapsulator and Receiver (including reassembly errors following
       loss/corruption of TS Packets), in addition to protecting from loss
       and/or corruption by the transmission network (e.g., multiplexors
       and links).

    Expires November 2004                                        [page 18]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004



       Mechanisms exist in MPEG-2 transmission networks that may assist in
       detecting loss (e.g. the 4-bit continuity counter included as
       standard in the MPEG-2 TS Packet header).

       A convergence protocol should use an encapsulation that provides a
       strong integrity check. For ease of hardware implementation, this
       check should be carried in a trailer following the SNDU. A CRC-32 is
       sufficient for operation with up to a 12 KB payload, and may still
       provide adequate protection for larger payloads.

       4.6 Identification of Scope.

       The MPE section header contains information that may be used by the
       Receiver to identify the scope of the (MAC) address carried as a
       NPA, and prevent TS Packets intended for one scope to be received by
       another. Similar functionality may be achieved by ensuring that only
       IP packets that do not have overlapping scope are sent on the same
       TS Logical Channel. In some cases, this may imply the use of
       multiple TS Logical Channels.

       4.7 Extension Headers

       The evolution of the Internet service may in future require
       additional functions. A flexible protocol should therefore provide a
       way to introduce new features when required, without having to
       provide additional out-of-band configuration.

       IPv6 introduced the concept of extension headers that carry extra
       information necessary/desirable for certain subnetworks. The DOCSIS
       cable specification also allows a MAC header to carry extension
       headers to build operator-specific services. It is thus a
       requirement for the new encapsulation to allow extension headers.

       4.8 Summary of Requirements for Encapsulation

       The main requirements for an IP-centric encapsulation include:
          - support of IPv4 and IPv6 packets
          - support for Ethernet encapsulated packets
          - flexibility to support other IP formats and protocols (e.g.
            ROHC, MPLS)
          - easy processing by hardware devices
          - low overhead/managed overhead
          - a fully specified algorithm that allows a sender to pack
            multiple packets per SNDU and to easily locate packet fragments
          - extensibility
          - compatibility with legacy deployments
          - ability to allow link encryption, when required
          - capability to support a full network architecture including
            data, control and management planes


     Expires November 2004                                        [page 19]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    5. Address Resolution Functions

       Address Resolution (AR) provides a mechanism that associates L2
       information with the IP address of a system. Many L2 technologies
       employ unicast AR at the sender: an IP system wishing to send an IP
       packet encapsulates it and places it into a L2 frame.  It then
       identifies the appropriate L3 adjacency (e.g. next hop router, end-
       host) and determines the appropriate L2 adjacency (e.g. MAC address
       in Ethernet) to which the frame should be sent so that the packet
       gets across the L2 link.

       The L2 addresses discovered using AR are normally recorded in a data
       structure known as the arp/neighbor cache. The results of previous
       AR requests are usually cached. Further AR protocol exchanges may be
       required as communication proceeds to update or re-initialise the
       client cache state contents (i.e. purge/refresh the contents [ND]).
       For stability, and to allow network topology changes and client
       faults, the cache contents are normally "soft state", that is, they
       are aged with respect to time and old entries removed.

       In some cases (e.g. ATM, FR, X.25, MPEG-2 and many more), AR
       involves finding other information than the MAC address. This
       includes identifying other parameters required for L2 transmission,
       such as channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2
       TS).

       Address resolution has different purposes for unicast and multicast.
       Multicast address resolution is not required for many L2 networks,
       but is required for many MPEG-2 transmission networks.

       5.1 Address Resolution for MPEG-2

       There are three elements to the L2 information required to perform
       AR for a MPEG-2 TS. These are:

       (i)  A Receiver ID (e.g. a 6B MAC/NPA address).
       (ii) A PID or index to find a PID.
       (iii) Tuner information (e.g. a Transport Stream ID) that maps to a
       set of physical layer parameters.

       Elements (ii) and (iii) need to be de-referenced via indexes to the
       PMT when remultiplexors are used that may renumber the PID values,
       (i.e. PIDs are not intended to be end-to-end identifiers). However,
       although such use is common in broadcast TV networks, many private
       networks do not need to employ multiplexors that renumber PIDs (see
       section 3.2).

       The third element (iii) allows an AR client to resolve to a
       different MPEG TS Multiplex. This is used when there are several
       channels that may be used for communication (i.e. multiple
       outbound/inbound links). In a mesh system, this could be used to
       determine connectivity.

    Expires November 2004                                        [page 20]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       This AR information is used in two ways at a Receiver:

       (i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG
       TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set
       L2 filters to let traffic pass to the IP layer. This is used for
       unicast, and IPv4 subnet broadcast. Usually this is configured with
       the equivalent of an "ifconfig" on the interface.

       (ii) AR resolves an IP multicast address to the (MPEG TS Multiplex,
       PID, MAC/NPA address), and allows the Receiver to set L2 filters
       enabling traffic pass to the IP layer. This operation may need to be
       performed many times based on IGMP, MLD, and Multicast Routing
       protocol operation. A Receiver in a MPEG-2 TS network needs to
       resolve the PID value and tuning parameters associated with a TS
       Logical Channel and (at least for unicast) the destination Receiver
       NPA address.

       A star topology MPEG-2 TS transmission network is illustrated below,
       with two terminals receiving a forward broadcast channel sent by a
       Hub.  (A mesh system has some additional cases.) The forward
       broadcast channel consists of a "TS Multiplex" (a single physical
       bearer) allowing communication with the terminals. These communicate
       using a set of return channels.

          Forward broadcast
          MPEG-2TS          \
             ----------------X       /-----\
                            /       /       \
                                   | Receiver|
                        /----------+    A    |
                       /            \       /
           /-----\    /              \-----/
          /       \  /
         |   Hub   |/
         |         +\                /-----\
          \       /  \              /       \
           \-----/    \            | Receiver|
                       \-----------+    B    |
                                    \       /
                                     \-----/
       Figure 6: MPEG-2 Transmission Network with 2 Receivers

       There are three possibilities for unicast AR:
       (1) A system at a terminal, A, needs to resolve an address of a
       system that is at the hub;
        (2) A system at a terminal, A, needs to resolve an address that is
       at another terminal, B;
        (3) A host at the hub needs to resolve an address that is at a
       terminal. The sender (encapsulation gateway), uses AR to provide the
       (MPEG TS Multiplex, PID, MAC/NPA address) to be used to send
       unicast, IPv4 subnet broadcast and multicast packets.


    Expires November 2004                                        [page 21]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       If the Hub is as an IP router, then case (1) and (2) are the same:
       the host at the Receiver doesn't know the difference.  In these
       cases, the address to be determined is the L2 address of the device
       at the hub to which the IP packet should be forwarded, and which
       then relays the IP packet back to the forward (broadcast) MPEG-2
       channel after AR (case 3).

       If the hub is a L2 bridge, then case 2 still has to relay the IP
       packet back to the outbound MPEG-2 channel. The AR protocol needs to
       resolve the specific Receiver L2 MAC address of B, but needs to send
       this on a L2 channel to the Hub.  This requires terminals to be
       informed of the L2 address of other terminals.

       An end host connected to the hub needs to use the AR protocol to
       resolve the Receiver terminal MAC/NPA address. This requires the AR
       server at the Hub to be informed of the L2 addresses of other
       terminals.

       5.2 Scenarios for MPEG AR

       An AR protocol may transmit AR information in three distinct ways:

       (i) An MPEG-2 signalling table transmitted at the MPEG-2 level
       (ii) An MPEG-2 signalling table transmitted at the IP level (tbd, no
       implementations of this are known)
       (iii) An address resolution protocol transported over IP (as in ND)

       There are three distinct cases in which AR may be used:

       A. Multiple TS-Mux and the use of re-multiplexors; e.g. Digital
       Terrestrial, Satellite TV broadcast multiplexes. Many such systems
       employ remultiplexors that modify the PID values associated with TS
       Logical Channels as they pass through the MPEG-2 transmission
       network (see Scenario A of Section 3.1).

       B. Tuner configuration(s) that are fixed or controlled by some other
       process. In these systems, the PID value associated with a TS
       Logical Channel may be known by the Sender.

       C. A service run over one TS Mux (i.e., uses only one PID, for
       example DOCSIS and some current DVB-RCS multicast systems). In these
       systems, the PID value of a TS Logical Channel may be known by the
       Sender.

       5.2.1 Table-based AR over MPEG-2

       In current deployments of MPEG-2 networks, 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 was originally
       designed for audio/video distribution to set-top-boxes. The design

    Expires November 2004                                        [page 22]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       requires access to and processing of the SI table information (which
       is carried in MPEG-2 section format [ISO_DSMCC]). This scheme
       reflects the complexity of delivering and co-ordinating the various
       TS Logical Channels associated with a multimedia TV programme.

       One possible requirement to provide TS multiplex and PID information
       for IP services is to integrate additional information into the
       existing MPEG-2 tables, or to define additional tables specific to
       the IP service. The DVB INT and the A/92 Specification from ATSC
       [ATSC-A92] are examples of the realization of such a requirement.

       5.2.2 Table-based AR over IP

       AR information could be carried over a TS data channel, (e.g. using
       an IP protocol similar to the Service Announcement Protocol, SAP).
       Implementing this independently of the SI tables, would ease
       implementation, by allowing it to operate on systems where IP
       processing is performed in a software driver. It may also allow the
       technique to be more easily adapted to other similar delivery
       networks. It also is advantageous for networks which use the MPEG-2
       TS but links, but do not necessarily support audio/video services
       and therefore do not need to provide interoperability with TV
       equipment (e.g. links used solely for connecting IP (sub)networks).

       5.2.3. Query/Response AR over IP

       A query/response protocol may be used at the IP level (similar to,
       or based on IPv6 Neighbor Advertisements of the ND protocol). The AR
       protocol may operate over an MPEG-2 TS Logical Channel using a
       previously agreed PID (e.g. configured, or communicated using a SI
       table). In this case, the AR could be performed by the target system
       itself (as in arp and nd). This has good soft-state properties, and
       is very tolerant to failures. To find an address, a system sends a
       "query" to the network, and the "target" replies.

       5.3 Scoping

       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;

    Expires November 2004                                        [page 23]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


               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 using level 2 NPA addresses:

       (i)    The NPA address must be unique within the TS Logical Channel.
               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 1s 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
       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 an IP
       packet may lead to unexpected protocol behaviour. This also provides
       a security vulnerability since arbitrary packets may be passed to
       the IP layer.

       5.5 AR Authentication

       In many AR designs authentication has been overlooked, because of
       the wired nature of most existing IP networks, which makes it easy
       to control hosts physically connected. With wireless connections,
       this is changing: unauthorised hosts actually can claim L2
       resources. The address resolution client (i.e. Receiver) may also
       need to verify the integrity and authenticity of the AR information
       that it receives. There are trust relationships both ways: clients
       need to know they have a valid server and that the resolution is
       valid.Servers have a basic authorisation issue before they allow a L2
       address to be used.


    Expires November 2004                                        [page 24]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       The MPEG-2 transmission system may also require access control to
       prevent unauthorised use of the satellite bearer, however, this is
       an orthogonal issue to address resolution.

       5.6 Requirements for Unicast AR over MPEG-2

       The requirement for AR over MPEG-2 networks include:

       (i)    Use of a table based approach to promote AR scaling.  This
               requires definition of the frequency of update and volume of
               AR traffic generated.
       (ii)   Mechanisms to install AR information at the server
               (unsolicited registration).
       (iii)  Mechanisms to verify AR information held at the server
               (solicited responses). Appropriate timer values need to be
               defined.
       (iv)   An ability to purge client AR information (after IP network
               renumbering, etc.).
       (v)    Support of IP subnetwork scoping.
       (vi)   Appropriate security associations to authenticate the sender.


    6. Multicast Support

       This section addresses specific issues concerning IPv4 and IPv6
       multicast over MPEG-2 Transmission Networks. 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 drivers and operating systems from discarding unwanted
       multicast traffic.

       Multicast mechanisms are used at more than one protocol level. The
       upstream MPEG-2 router may forward multicast traffic on the MPEG-2
       TS link using a static or dynamic set of groups. When static
       forwarding is used, the set of groups may also be configured or set
       using SNMP, Telnet, etc. A Receiver normally uses either IGMP/MLD or
       multicast routing to establish membership tables that it uses to
       dynamically set local forwarding of received groups.  In a dynamic
       case, this group membership information is fed-back to the Sender to
       enable it to start sending new groups and (if required) to update
       the tables that it produces for multicast AR.

       Appropriate procedures need to identify the correct action when the
       same multicast group is available on more than one TS Logical
       Channel.  This could arise when different end hosts act as senders
       to contribute IP packets with the same IP group destination address.

    Expires November 2004                                        [page 25]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       It may also arise when a sender duplicates the same IP group over
       several TS Logical Channels (or even different TS Multiplexes), and
       in this case a Receiver may potentially receive more than one copy
       of the same packet. At the IP level, the host/router may be unaware
       of this duplication.

       6.1 Multicast AR Functions

       The functions required for multicast AR may be summarised as:
       (i) The Sender needs to know L2 mapping of multicast group.
       (ii) The Receiver needs to know L2 mapping of multicast group.

       In the Internet, multicast AR is normally a mapping function rather
       than a one-to-one association using a protocol. In Ethernet, the
       sender maps an IP address to a L2 MAC address, and the Receiver uses
       the same mapping to determine the L2 address to set a L2
       hardware/software filter entry.

       A typical sequence of actions for the dynamic case is:
       L3) Populate the IP L3 membership tables at the Receiver.
       L3) Receivers send/forward IP L3 membership tables to the Hub
       L3) Dynamic/static forwarding at hub/upstream router of IP L3 groups
       L2) Populate the IP AR tables at the encapsulator gateway
           (i.e. Map IP L3 mcast groups to L2 (PIDs))
       L2) Distribute the AR information to Receivers
       L2) Set Receiver L2 multicast filters for IP groups in the
           membership table.

       Multicast also introduces the concept of scoped addresses, requiring
       appropriate scoping to be followed. To be flexible AR must associate
       a Logical Channel (PID) not only with a group, possibly a QoS class,
       and other appropriate MPEG-2 TS attributes. Performing multicast AR
       at the IP level can enable providers wishing to provide
       independently scoped addresses would need to use multiple Multicast
       AR servers, one per multicast domain.  Explicit per group AR to
       individual L2 addresses is to be avoided.

    Expires November 2004                                        [page 26]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


           \
            |
        +---+----+   +--------+
        |  Tuner |---+TS Tabl | . . . .
        +---+----+   +--------+       .
            |                         .
        +--------+   +--------+       .
        | deMux  |---+PID Tabl|........
        +---+----+   +--------+       :
            |                         :
        +--------+   +--------+   +--------+
        |MPE/ULE |---+AR Cache|---+  MFIB  |
        +---+----+   +--------+   +--------+
            |            |            |
        +---+----+   +---+----+   +---+----+
        |  IP    |   |  AR    |   |IGMP/MLD|
        +---+----+   +---+----+   +---+----+
            |            |            |
            *------------+------------+
       Figure 7: Receiver Processing Architecture

       6.2 Requirements for Multicast over MPEG-2

       The requirements for supporting multicast include, but are not
       restricted to:

       (i)    Encapsulating multicast packets for transmission using a
               MPEG-2 TS.
       (ii)   Mapping IP multicast groups to the underlying MPEG-2 TS
               Logical Channel (PID) and the MPEG-2 TS Multiplex.
       (iii)  Provide AR information to allow a Receiver to locate an IP
               multicast flow within an MPEG-2 TS Multiplex.
        (v)   Error Reporting.

    7. Summary

       This document describes the architecture for a set of protocols to
       perform efficient and flexible support for IP network services over
       networks built upon the MPEG-2 Transport Stream (TS). It also
       describes existing approaches. It focuses on IP networking, the
       mechanisms that are used and their applicability to supporting IP
       unicast and multicast services.

       The requirements for a new encapsulation of IPv4 and IPv6 packets is
       described, outlining the limitations of current methods and the need
       for a streamlined IP-centric approach.

       The architecture also describes MPEG-2 Address Resolution (AR)
       procedures to allow dynamic configuration of the sender and Receiver
       using an MPEG-2 transmission link/network.  These support IPv4 and
       IPv6 services in both the unicast and multicast modes. Resolution
       protocols will support IP packet transmission using both the

     Expires November 2004                                        [page 27]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       Multiprotocol Encapsulation (MPE), which is currently
       widely deployed, and also any new optimised encapsulation.


    8. Security Considerations

       When the MPEG-2 network is not using a wireline network, the normal
       security issues relating to the use of wireless links for transport
       Internet traffic should be considered [ID-PILC-LINK].

       End-to-end security (including confidentiality, authentication,
       integrity and access control) is closely associated with the end-
       user assets that are protected. This close association cannot be
       ensured when providing security mechanisms only within a subnetwork
       (e.g. an MPEG-2 transmission network).  Several security mechanisms
       that can be used end-to-end have already been deployed in the
       general Internet and are enjoying increasing use. Important examples
       include:

       * The Secure Sockets Layer (SSL) and Transport Layer Security, TLS,
       which is primarily used to protect web commerce;
       * Pretty Good Privacy (PGP) and S/MIME, primarily used to protect
       and authenticate email and software distributions;
       * The Secure Shell (SSH), used to secure remote access and file
       transfer;
       * IPsec, a general purpose encryption and authentication mechanism
       above IP that can be used by any IP application.

       However, subnetwork security is also important [ID-PILC-LINK] and
       should be encouraged, on the principle that it is better than the
       default situation, which all too often is no security at all.  Users
       of especially vulnerable subnets (such as radio/broadcast networks
       and /or shared media Internet access) often have control over at
       most one endpoint - usually a client and therefore cannot enforce
       the use of end-to-end mechanisms.

       A related role for subnetwork security is to protect users against
       traffic analysis, i.e., identifying the communicating parties (by IP
       or MAC address) and determining their communication patterns, even
       when their actual contents are protected by strong end-to-end
       security mechanisms (this is important for networks such as
       broadcast/radio, where eaves-dropping is easy).

       Where it is possible for an attacker to inject traffic into the
       subnetwork control plane, subnetwork security can additionally
       protect the subnetwork assets.  This threat must specifically be
       considered for the protocols used for subnetwork control functions
       (e.g. address resolution, management, configuration). Possible
       threats include theft of service and denial of service; shared media
       subnets tend to be especially vulnerable to such attacks [ID-PILC-
       LINK]. Appropriate security functions must therefore be provided for

     Expires November 2004                                        [page 28]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       ipdvb control protocols [ID-PILC-LINK], particularly when the
       control functions are provided above the IP-layer using IP-based
       protocols. Internet level security mechanisms (e.g. IPSEC) can
       mitigate such threats.

       In general, End-to-End security is recommended for users of any
       communication path, especially when it includes a
       wireless/radio/broadcast link, where a range of security techniques
       already exist. Specification of security mechanisms at the
       application layer, or within the MPEG-2 transmission network are the
       concerns of organisations beyond the IETF. The complexity of any such
       security mechanisms should be considered carefully so that it will
       not unduly impact the IP operation.

     8.1 Link Encryption

       Link level encryption of IP traffic is commonly used in
       broadcast/radio links to supplement End-to-End security (e.g.
       provided by SSL, SSH, PGP, IPSec).  The encryption and key exchange
       methods vary significantly, depending on the intended application.
       For example, DVB-S/DVB-RCS operated by Access Network Operators
       (ANO) may wish to provide their customers (Internet Service
       Providers, ISP) with security services. Common targeted security
       services are: terminal authentication and data confidentiality (for
       unicast and multicast) between a gateway and Receivers. A common
       objective is to provide the same level of privacy as terrestrial
       links. An ISP may also wish to provide end-to-end security services
       to the end-users (based on the well known mechanisms such as IPSec).
       Therefore it is important to understand that both security solutions
       (ANO-to-ISP and ISP-to-end users) may co-exist.

       MPE supports optional link encryption using a pair of bits within
       the MPE protocol header to indicate the use of encryption.  To
       support optional link level encryption, it is recommended that a new
       encapsulation also supports optional encryption of the SNDU payload.
       Furthermore, it may be desirable to encrypt/authenticate some/all of
       the SNDU headers.  The method of encryption and the way in which
       keys are exchanged is beyond the scope of the ULE Specification.
       However, the specification must provide appropriate code points to
       allow such encryption to be implemented at the link layer.


    9. Acknowledgments

       The authors wish to thank Isabel Amonou , Torsten Jaekel, Pierre
       Loyer, Luoma Juha-Pekkaand and Rod Walsh for their detailed inputs.
       We also wish to acknowledge the input provided by the members of the
       IETF ipdvb WG.


    Expires November 2004                                        [page 29]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


    10. References

    10.1 Normative References

       [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).

       [RFC1122] B. Braden, ed., "Requirements for Internet Hosts  -
       Communication Layers", RFC 1122.

    10.2 Informative References

       [ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television
       Systems Committee (ATSC), Doc. A/53C, 2004.

       [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
       Systems Committee (ATSC), Doc. A/090, 2000.

       [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
       for the ATSC Data Broadcast Standard", Advanced Television Systems
       Committee (ATSC),Doc. A/91, 2001.

       [ATSC-A92] A/92  "Delivery of IP Multicast Sessions over ATSC Data
       Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92,
       2002.

       [ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television
       Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A,
       2003.

       [ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
       Terrestrial Broadcast and Cable", Advanced Television Systems
       Committee (ATSC), Doc. A/65B, 2003.

       [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
       (DTV) Applications  over Satellite", Advanced Television Systems
       Committee (ATSC), Doc. A/80, 1999.

       [CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet
       over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.

       [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).

     Expires November 2004                                        [page 30]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       [ETSI-DVBS] EN 301 421 Digital Video Broadcasting (DVB); Modulation
       and  Coding  for  DBS  satellite  systems  at  11/12  GHz,  European
       Telecommunications Standards Institute (ETSI).

       [ETSI-DVBT] EN 300 744 Digital Video Broadcasting (DVB); Framing
       structure, channel coding and modulation for digital terrestrial
       television (DVB-T), European Telecommunications Standards Institute
       (ETSI).

       [ID-IPDVB-ULE] Fairhurst, G., B. Collini-Nocker, "Simple Ultra
       Lightweight Encapsulation for transmission of IP datagrams over
       MPEG-2/DVB networks", Internet Draft, draft-ipdvb-ule-xx.txt, Work
       in Progress, IP-DVB WG.

       [ID-PILC-LINK] P. Karn  (ed) Advice for Internet Subnetwork
       Designers, Internet Draft draft-ietf-pilc-link-design-00.txt , Work
       in Progress, IETF PILC WG, BCP (with RFC-Ed).

       [ID-IPDVB-AR] Fairhurst, G., M-J. Montpetit, "Address Resolution for
       IP datagrams over MPEG-2 networks", Internet Draft, draft-fair-
       ipdvb-ar-00.txt, Work in Progress, IP-DVB WG.

       [ID-MMUSIC-IMG] Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H.
       Schulzrinne, "Protocol Requirements for Internet Media Guides",
       Internet Draft, draft-ietf-mmusic-img-req-XX.txt, 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).

       [ISO-VID] ISO/IEC DIS 13818-2:1998 "Information technology -- Generic
       coding of moving pictures and associated audio information: Video",
       International Standards Organisation (ISO).

       [ISO-AUD] ISO/IEC 13818-3:1995 "Information technology -- Generic
       coding of moving pictures and associated audio information -- Part
       3: Audio", International Standards Organisation (ISO).

       [Ken87] Kent C.A., and J. C. Mogul, ?Fragmentation Considered
       Harmful", Proc. ACM SIGCOMM, USA, CCR Vol.17, No.5, 1988, pp.390-
       401.

       [RFC793] Postel, J., "Transmission Control Protocol", RFC791.

       [RFC1122] B. Braden, ed., "Requirements for Internet Hosts  -
       Communication Layers", RFC 1122.

    Expires November 2004                                        [page 31]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004



       [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
       Serial Links", RFC1144.

       [RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", RFC 1191.

       [RFC2507] Degermark, M., Nordgren, B., and Pink, S., "IP Header
       Compression", RFC2507.

       [RFC3077] Duros, E., W. Dabbous, H. Izumiyama, Y. Zhang, "A Link
       Layer Tunneling Mechanism for Unidirectional Links", RFC3077.

       [RFC3095] Bormann, C., et al, "RObust Header Compression (ROHC):
       Framework and four profiles: RTP, UDP ESP and uncompressed",
       RFC3095.

       http://www.atsc.org/standards/Code_Point_Registry.pdf

    11. AuthorsÆ Addresses

       Marie J. Montpetit
       MJMontpetit.com
       Email: marie@mjmontpetit.com

       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

       Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder
       Debartment of Scientific Computing
       University of Salzburg
       Jakob Haringer Str. 2
       5020 Salzburg
       Austria
       Email: [clausen|bnocker|hlinder]@cosy.sbg.ac.at
       Web: http://www.network-research.org







    Expires November 2004                                        [page 32]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    12. 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.

    13. 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.

    14. IANA Considerations

    A set of protocols which meet these requirements, will require the IANA
    to assign various numbers.  This document by itself, however, does not
    require any IANA involvement.

    Expires November 2004                                        [page 33]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    Appendix A: MPEG-2 Encapsulation Mechanisms

       To transmit packet data over an MPEG-2 transmission network requires
       that individual SNDUs (e.g. IPv4, IPv6 packets, or bridged Ethernet
       Frames) are encapsulated using a convergence protocol. The following
       encapsulations are currently standardised for MPEG-2 transmission
       networks:

       (i)     Multi-Protocol Encapsulation (MPE).
               The Multi-Protocol Encapsulation, MPE, specification of DVB
               [ETSI-DAT] uses private Sections for the transport of IP
               packets and uses encapsulation that is similar to the IEEE
               LAN/MAN standards [LLC]. Data packets are encapsulated in
               datagram sections that are compliant with the DSMCC section
               format for private data. Some Receivers may exploit section-
               processing hardware to perform a first-level filter of the
               packets that arrive at the Receiver.

               The section header also includes fields, which may be used by
               a Receiver to filter datagrams assigned to the same TS
               Logical Channel.  This feature allows several logical
               networks to be established without assigning PID values to
               each of the services. Section filtering is especially well
               suited for TV broadcast environments where remultiplexing
               comes into play.

               This encapsulation makes use of a MAC-level network point of
               attachment address. The address format conforms to the
               ISO/IEEE standards for LAN/MAN LLC]. The 48-bit MAC address
               field contains the MAC address of the destination; it is
               distributed over six 8-bit fields, labeled MAC_address_1 to
               MAC_address_6. The MAC_address_1 field contains the most
               significant byte of the MAC address, while MAC_address_6
               contains the least significant byte.  How many of these bytes
               are significant is optional and defined by the value of the
               broadcast descriptor table [SI-DAT] sent separately over
               another MPEG-2 TS within the TS multiplex.

               MPE is currently a widely deployed scheme. Due to investments
               in existing systems, usage is likely to continue in current
               and future networks.

       (ii)   Data Piping.
               The Data Piping profile [ETSI-DAT] is a minimum overhead,
               simple and flexible profile that makes no assumptions
               concerning the format of the data being sent. In this
               profile, the Receiver is intended to provide PID filtering,
               packet reassembly according to [DVB-SIDAT-368], error
               detection and optional Conditional Access (link encryption).

               The specification allows the user data stream to be
               unstructured or organized into packets. The specific

    Expires November 2004                                        [page 34]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


               structure is transparent to the Receiver. It may conform to
               any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc.

        (iii)  Data Streaming.
               The data broadcast specification profile [ETSI-DAT] for PES
               tunnels (Data Streaming) supports unicast and multicast data
               services that require a stream-oriented delivery of data
               packets. This encapsulation maps an IP packet into a single
               PES Packet payload.

               Two different types of PES headers can are selected via the
               stream_id values [ISO-MPEG]. The private_stream_2 value
               permits the use of the short PES header with limited
               overhead, while the private_stream_1 value makes available
               the scrambling control and the timing and clock reference
               features of the PES layer.



    Expires November 2004                                        [page 35]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

    Appendix B: Address Resolution Use Cases

       Consider the case where a hub server collects a table of AR
       information. The collected AR information then needs to be
       redistributed to clients using the forward multicast link. The
       number of Receivers may range from 1 to many thousands.

       (i)  Example 1 Example protocol stack for Sender Side (2 interface)

       Consider a router with two logical interface (A,B) each to an IP
       network which could use either private or global IP addresses.  If
       AR is performed independently for each interface, the L2 addresses
       used by subnetworks A,B may also overlap or be globally unique. A
       separate association protocol could provide MPEG-2 other L2
       information (MPEG-2 TS Logical Channels / PID mappings, etc) to the
       IP systems in each of the connected IP networks. Both AR for L2
       addresses and for association with TS logical channel attributes may
       be performed by IP-level protocols using link-local IP multicast. A
       good solution may also permit multiple servers. A simple association
       protocol may only support networks that do not perform remux
       renumbering of PIDs. When this needs to be supported, a L2 table
       method may be used.

                              |
                     +--------+--------+
                     |      Port C     |
       +-------------+--------+--------+-------------+
       |                    Router                   |
       +-----------------+---------+-----------------+
       |      Port A     |         |      Port B     |
       +--------+--------+         +--------+--------+
       |  IP Interface 1 |         |  IP Interface 2 |
       |    (subnet)     |         |    (subnet)     |
       +------+----------+         +------+----------+
       | AR   |   +-------+        | AR   |   +-------+
       |Server|.. |   AR  +--+     |Server|.. |   AR  +--+
       +------+   | Cache |  |     +------+   | Cache |  |
                |  +-+-----+  |             |  +-+-----+  |
                |    | Assoc  |             |    | Assoc  |
                |    +--------+             |    +--------+
       +-------( )--------------+----------( )-----------+
       |     Encapsulator X     |    Encapsulator Y      |
       +---------+--------------+-----------+------------+
                 |                          |
                 +----->------+   +----<----+
                              |   |
                     +-------( )-( )--( )-----+
                     |       PID PID  PID     |
                     |        TS-Mux          |
                     +---------+--------------+
                               | Forward Link
                               | (Feed)

    Expires November 2004                                        [page 36]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004

       (ii) Example 2

       Suppose we have system B and a system A. The L2 address B is (Y:q)
       (i.e. Combination of MAC address, PID, TS) and the corresponding one
       for A is (X:p).

                               |  Forward   |
         +-------+  +-------+  |   Link     |  +-------+  +-------+
       --+AR     +--+Encaps +--------->--------+ A     +--+AR     +-
         |server |  |       |  |            |  |       |  |Client |
         +-------+  +-------+  |            |  +-------+  +-------+
                     +------+  |            |   +------+
                     |A:X:p |  |            |   |p:X:A |
                     +------+  |            |   +------+
                               |            |
         +-------+  +-------+  |            |  +-------+  +-------+
        -+AR     +--+ B     +---------<--------+Encaps +--+AR     +-
         |Client |  | Decaps|  |            |  |       |  |server |
         +-------+  +-------+  |   Return   |  +-------+  +-------+
                     +------+  |    Link    |   +------+
                     |q:Y:B |  |            |   |B:Y:q |
                     +------+  |            |   +------+
               IP addr B                         IP addr A

       For B to send to A, the encapsulation gateway at B needs to resolve
       the IP address of A to the l2 address of X and identify that this
       must be carried over (PID,TS) of p.

       A already knows its L2 address is X, this doesn't need to be
       communicated. It also knows or can determine it's layer 3 IP
       address. It can not determine the  (pid,TS-ID) to use, so it must be
       told p. Once it knows p it can tune and set the MPEG-2 demux filter.
       The corresponding addresses for B are Y and q.

       How do A and B find out X and Y?

       1) X can be preassigned to A (e.g. A L2 address assigned by a
       Receiver manufacturer), in which case, A has to tell the AR server
       at B informing it that it will be using X (register). The AR server
       at B could then inform other devices by sending an AR table that
       includes an entry that says A uses X (mesh). The encapsulator needs
       this information, and also other clients that need to send to A.

       2) B can assign X to A. B informs A that it is using X. B could then
       inform others by sending an AR table that includes an entry saying A
       uses X (mesh) or that B uses Y as a proxy (star).

       3) It is also possible that B does not know that A is using X. To
       find this out, it may query the network/a third party AR server (Y)
       looking for address A. A can then respond giving its resolved
       address (X), which B then uses. The way in which Y is found is to be
       determined (e.g. configured, or determined by a protocol mechanism).

    Expires November 2004                                        [page 37]

    INTERNET DRAFT  Architecture for IP transport over DVB        July 2004


       (iii)        Example 3

       Assume a unicast (e.g. TCP) stream originates at a host, S, and is
       intended for an end host, R.
       The path between S and R includes an MPEG-2 link, with an
       encapsulator B and a Receiver A. The Receiver, A, acts as a router.

       The Encapsulator receives the IP packets from S and encapsulate them
       with an SNDU destination address field of X, this is performed by
       determining that A is not local to the subnetwork, but reached via
       router with the IP Address A corresponding to the L2 value of X. The
       packet is fragmented into TS-Packets and a PID assigned.

               +-------+ +------+
        +->----|AR     | |A:X   |
        |   +--+Server | +------+
        |   |  +-------+                 +---->  |
        |   |              |             |       |
        |   |              | Forward     +---->  |
        |   |   +-------+  |             |       |    +-------+
        |   +->-+Encaps +------------>---+---->-------+Decaps +----+->--
        |   >---+       |  | Data                |    |       |    |
        |  IP   +-------+  | A sent over X       |    +-------+   ++------+
        |  data  +------+  |                     |     +------+   |AR     |
        |        |A:X   |  | & AR Adverts (mcast)|     |X:A   | <-+Client |
        |        +------+  | A uses X            |     +------+   ++------+
        |                  | B uses Y            |                 |
        |  Encaps receives |                     | Cached values   |
        |  AR Tables       |                     | used for rx     |
        |                  |                     | AR of packets   |
        |  Cached values   |                     | own unicast addr|
        |  used for tx     |                     | & mcast addrs   |
        |                  |                     |                 |
        |                  |                     |                 |
        |                  | Reverse             |                 |
        |       +-------+  |                     |    +-------+    |
       -+--<----+Decaps +------------<----------------+Encaps +-<--+--<
         Decaps |       |  |                     |    |       |
                +-------+  | AR requests         |    +-------+
                           |  who-is-C?          |
                           |                     |
                           | & AR registration   |     IP addr A
                           |  I-am A I-use X     |

       For A to forward packets to B, the encapsulation gateway at A.
       For A to forward packets to B, the encapsulation gateway at A needs
       to resolve the IP address.of B to the L2 address X. A should already
       be listening on the L2 address X, because it is either the media-
       resolved of its A's IP address. (For multicast, this could be L2
       multicast IP address for a multicast group for which it has enabled
       a filter).

    Expires November 2004                                        [page 38]


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