Internet DRAFT - draft-fair-ipdvb-req

draft-fair-ipdvb-req





    Internet Engineering Task Force                         Gorry Fairhurst
    Internet Draft                             University of Aberdeen, U.K.
    Document: draft-fair-ipdvb-req-05.txt                  Horst D. Clausen
                                                     Bernhard Collini-Nocker
                                                               Hilmar Linder
                                                  University of Salzburg, A
                                                                           
                                                                           
                                                                           
                                                                           
    Category: Informational                                        May 2004
    
    
    A Framework for transmission of IP datagrams over MPEG-2 networks
    
    Status of this Memo
    
       This document is an Internet-Draft and is in full conformance with
          all provisions of Section 10 of RFC2026. 
       
       Internet-Drafts are working documents of the Internet Engineering
       Task Force (IETF), its areas, and its working groups. Note that
       other groups may also distribute working documents as Internet-
       Drafts. Internet-Drafts are draft documents valid for a maximum of
       six months and may be updated, replaced, or obsoleted by other
       documents at any time. It is inappropriate to use Internet- Drafts
       as reference material or to cite them other than as "work in
       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.
       
       
    Abstract
       
       This document describes a new framework 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  Requirements for IP transport over DVB        May 2004
    
    
       
       Table of Contents
       
       1. Introduction
       2. Conventions used in this document
       3. Motivation
       4. Encapsulation Protocol 
       5. Address Resolution Functions
       6. Multicast Support
       7. Summary
       8. Security Considerations
       9. Acknowledgments
       10. References
       
       
       
        
                    
    Expires November 2004                                         [page 2] 
    INTERNET DRAFT  Requirements for IP transport over DVB        May 2004
    
    
       Document History
       
       -00 This draft is intended as a study item for proposed future work
       by the IETF in this area. 
       
       -01 This draft has been expanded with additional rationale for the
       simple encapsulation described in [ID-IPDVB-Enc].
       
       -02a Comments received from Isabel Amonou, May 2002. Corrections to
       spelling. Addition of section filter. Addition of first draft of
       text on čaddressed area¸ in arp.
       
       -02b GF Added some long-awaited figures
       
       -02c GF Added text on section processing in MPE
    
       -03a GF Updated text June 2003, comments from Bernhard C-N. 
            Abstract shortened
            Description generalised to all MPEG-2 TS networks;-)
            Improved discussion of PES / PUSI
            Subtle title change 
       
       -03b GF updated to reflect ULE [ID-IPDVB-ULE].
            IPv6 terminology improved.
       
       -03c GF formatting for ID.
       
       -04a NiTs following IETF-57 BOF
       
       -04b Updated section on encapsulation.
            New section numbering
            New summary section
       -04d Aligned with charter and reduced discussion on MPE/ULE/etc
       -04e Rewritten conclusion.
       -04e Feedback from various people on DVB address resolution process-
                       04f New address resolution section.
       
       -05a Edits to prepare for proposal for an ipdvb work item.
       
       -05b Revised security & ULE motivation
       
       -05c,d Revised security text
       
       - 05e, 05f, 5g, 5h Final edits to WG approval as an ipdvb work item.
                             
    Expires November 2004                                         [page 3] 
    INTERNET DRAFT  Requirements for IP transport over DVB        May 2004
    
    
       1. Introduction
       
       This document identifies requirements for a framework 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 framework 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 Framework
       
       The framework 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  Requirements for IP transport over DVB        May 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 framework 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
       framework 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  Requirements for IP transport over DVB        May 2004
    
    
       2. Conventions used in this document
       
       ACK: A cumulative TCP acknowledgment. In this document, this term
       refers to a TCP segment (packet) that carries a cumulative
       acknowledgement (ACK), but no data.
       
       Adaptation Field: Option control overhead or padding associated with
       an MPEG-2 TS Packet. Examples of overhead are: TS Logical Channel
       encryption details and clock (PCR) information to synchronise a set
       of TS Logical Channels.
       
       ATSC: Advanced Television Systems Committee [ATSC]. A set of
       framework and associated standards for the transmission of video,
       audio, and data, using the ISO MPEG-2 standard.
       
       DSM-CC: Digital Storage Management Command and Control [ISO-DSMCC].
       A formatting defined by the ISO MPEG-2 standard, which is carried in
       an MPEG-2 private section.
       
       DVB: Digital Video Broadcast [ETSI-DVB]. A set of framework and
       associated standards for the transmission of video, audio, and data,
       using the ISO MPEG-2 standard.
       
       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: Programme 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  Requirements for IP transport over DVB        May 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. 
       
       REVERSE DIRECTION: The direction in which feedback control messages
       generally flow (e.g. acknowledgments of a forward TCP transfer
       flow). Data transfer could also happen in this direction (and it is
       termed "reverse transfer").
       
       PRIVATE SECTION: A syntactic structure used for mapping all service
       information (e.g. an SI table) into TS Packets.  A table may be
       divided into a number of sections.  All sections of a table must be
       carried over a single TS Logical Channel.
       
       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  Requirements for IP transport over DVB        May 2004
    
    
    3. The Framework
       
       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 MPEG2 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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
     
    Expires November 2004                                        [page 11] 
    INTERNET DRAFT  Requirements for IP transport over DVB        May 2004
    
    
                    for IP transport over MPEG-2
       
       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
       framework. 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  Requirements for IP transport over DVB        May 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 framework
       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  Requirements for IP transport over DVB        May 2004
    
    
    
       The framework 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 framework 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  Requirements for IP transport over DVB        May 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 3: 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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 cased 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 framework, 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  Requirements for IP transport over DVB        May 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, and there may
       therefore be a good case for allowing the use of a reduced (smaller
       than an IEEE MAC address) NPA. 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) [LINK-ID]. 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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       /-----\
                            /       /       \
                                   | Terminal|
                        /----------+    A    |
                       /            \       /
           /-----\    /              \-----/
          /       \  /
         |   Hub   |/
         |         +\                /-----\
          \       /  \              /       \
           \-----/    \            | Terminal|
                       \-----------+    B    |
                                    \       /
                                     \-----/
       
       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  Requirements for IP transport over DVB        May 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. 
       6.2 The AR Process
    
       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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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 similarities here with SEND [REF-to-
       SEND-WG]. 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 2004
    
    
           \
            |
        +---+----+   +--------+
        |  Tuner |---+TS Tabl | . . . .
        +---+----+   +--------+       .
            |                         .
        +--------+   +--------+       .
        | deMux  |---+PID Tabl|........
        +---+----+   +--------+       :
            |                         :
        +--------+   +--------+   +--------+
        |MPE/ULE |---+AR Cache|---+  MFIB  |
        +---+----+   +--------+   +--------+
            |            |            |
        +---+----+   +---+----+   +---+----+
        |  IP    |   |  AR    |   |IGMP/MLD|
        +---+----+   +---+----+   +---+----+
            |            |            |
            *------------+------------+
       
       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.
       
    
    9. Summary
       
       This document describes the framework 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 framework 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 in the framework will support IP packet transmission using
     
    Expires November 2004                                        [page 27] 
    INTERNET DRAFT  Requirements for IP transport over DVB        May 2004
    
    
       both the Multiprotocol Encapsulation (MPE), which is currently
       widely deployed, and also any new optimised encapsulation.
       
       
    
    10. 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  Requirements for IP transport over DVB        May 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. 
    
     10.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.
    
       
    11. Acknowledgments
       
       The authors wish to thank Isabel Amonou , Torsten Jaekel, Pierre
       Loyer,  Marie-Jose Montpetit, Luoma Juha-Pekkaand , and Rod Walsh,
       for their detailed inputs. We also wish to acknowledge the input
       provided by the members of the ip-dvb (ip-dvb@erg.abdn.ac.uk)
       mailing list.
        
                       
    Expires November 2004                                        [page 29] 
    INTERNET DRAFT  Requirements for IP transport over DVB        May 2004
    
    
    12. References
    
    12.1 Normative References
       
       [ISO-MPEG] ISO/IEC DIS 13818-1 "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.
       
    12.2 Informative References
       
       [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television
       Systems Committee (ATSC), Doc. A/53, 1995.
       
       [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television
       Systems Committee (ATSC), Doc. A/090, 200
       
       [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/54, "Guide to the use of the ATSC Digital Television
       Standard", Advanced Television Systems Committee (ATSC), Doc. A/54,
       1995.
       
       [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for
       Terrestrial Broadcast and Cable", Advanced Television Systems
       Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A , 2000.
    
       [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  Requirements for IP transport over DVB        May 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-xx.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-MPEG] ISO/IEC DIS 13818-1 "Information technology -- Generic
       coding  of  moving  pictures  and  associated  audio  information:
       Systems", International Standards Organisation (ISO).
       
       [ISO-VID] ISO/IEC DIS 13818-2 "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  Requirements for IP transport over DVB        May 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
       
    13.Authors' Addresses
       
       Godred Fairhurst
       Department of Engineering
       University of Aberdeen
       Aberdeen, AB24 3UE
       UK
       Email: gorry@erg.abdn.ac.uk
       Web: http://www.erg.abdn.ac.uk/users/gorry
       
       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  Requirements for IP transport over DVB        May 2004
    
    
    Full Copyright Statement
    
       "Copyright (C) The Internet Society (date). All Rights Reserved.
       This document and translations of it may be copied and furnished to
       others, and derivative works that comment on or otherwise explain it
       or assist in its implementation may be prepared, copied, published
       and distributed, in whole or in part, without restriction of any
       kind, provided that the above copyright notice and this paragraph
       are included on all such copies and derivative works. However, this
       document itself may not be modified in any way, such as by removing
       the copyright notice or references to the Internet Society or other
       Internet organizations, except as needed for the purpose of
       developing Internet standards in which case the procedures for
       copyrights defined in the Internet Standards process must be
       followed, or as required to translate it into languages other than
       English.
       
       The limited permissions granted above are perpetual and will not be
       revoked by the Internet Society or its successors or assigns.
       
    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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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  Requirements for IP transport over DVB        May 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]