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

Versions: 00 01 02

     Internet Engineering Task Force                         Gorry Fairhurst
     Internet Draft                             University of Aberdeen, U.K.
     Document: draft-fair-ipdvb-ule-00.txt           Bernhard Collini-Nocker
                                                  University of Salzburg, A
     
     
     
     
     Category: Draft                                                May 2003
     
     
             Ultra Lightweight Encapsulation (ULE) for transmission of
                     IP datagrams over MPEG-2/DVB networks
     
     Status of this Draft
     
        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.
     
     
        Document history
     
        This draft is intended as a study item for proposed future work by
        the IETF in this area.  Comments relating to this document will be
        gratefully received by the author(s) and the ip-dvb mailing list at:
        ip-dvb@erg.abdn.ac.uk
     
        Abstract
     
     This document contains an alternative Ultra Lightweight Encapsulation
     (ULE) mechanism for the transport of IP Datagrams directly over ISO
     MPEG-2 Transport Streams (TS) as TS private data. 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.
     
     
     
     
     
     
     
     Expires December 2003                                         [page 1]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
        Table of Contents
     
        1. Introduction
        2. Conventions used in this document
        3. Description of method
        4. SNDU Format
        4.1 Bridged Payload
        4.2 IPv4 Encapsulation
        4.3 Ipv6
        5. Processing at the Encapsulator and Receiver
        5.1 Encapsulator processing
        5.2 Flushing the bitstream
        5.3 Receiver Processing
        6. Summary
        7. Acknowledgments
        8. Security Considerations
        9. References
        10. Authors' Addresses
        11. IANA Considerations
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Expires December 2003                                         [page 2]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
     1. Introduction
     
        This document describes an encapsulation for transport of IP
        datagrams or other network layer packets over ISO MPEG-2 Transport
        Streams [ISO-MPEG].  This is suited to 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],Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]).   Bi-
        directional (duplex) links may also be established using these
        standards (e.g., DVB defines a range of return channel technologies,
        including the use of two-way satellite links [ETSI-RCS] and dial-up
        modem links [RFC3077]).
     
        Data for transmission over the MPEG-2 transport multiplex is passed
        to an encapsulator that typically receives PDUs (Ethernet
        Frames, IP datagrams or other network layer packets). It formats
        each PDU into a series of TS Packets (usually after adding an
        encapsulation header), which is sent over a TS logical channel.
     
        The draft describes a mechanism aimed at a subset of the services
        supported by [draft-unisal-ipdvb-enc-01.txt].  The format of this
        document resembles this for ease of comparison and much of the
        background text is common, although the encapsulation protocol is
        different and more lightweight.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Expires December 2003                                         [page 3]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
     2. Conventions used in this document
     
        ADAPTATION FIELD: An optional variable-length extension field of the
        fixed-length TS Packet header, intended to convey clock references
        and timing and synchronization information as well as stuffing over
        an MPEG-2 multiplex [ISO-MPEG].
     
        AFC: Adaptation Field Control.
     
        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 which receives PDUs (Ethernet frames
        or IP datagrams) and formats these for output as a transport stream
        of TS Packets.
        MAC: Medium Access and Control of the Ethernet IEEE 802 standard of
        protocols.
     
        MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that
        encapsulates Ethernet frames or IP Datagrams, 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].
     
        PES: Programme Elementary Scheme of MPEG-2 [ISO-MPEG].
     
        PID: Packet Identifier. A field carried in the header of all MPEG-2
        Transport Stream packets. This is used to identify the TS logical
        channel to which it belongs [ISO-MPEG].
     
        PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A PUSI
        value of zero indicates that the TS Packet does not carry the start
        of a new payload. In this document, a PUSI value of one indicates
        that the TS Packet does carry the start of a new payload. When the
        PUSI bit is set to 1, in ULE this also indicates the presence of a
        one byte pointer directly following the TS packet header.
        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.
     
     Expires December 2003                                         [page 4]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
     
        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.
     
        SNDU: Subnetwork Data Unit, an IPv4 or IPv6 datagram (or other
        subnetwork packet, e.g., an arp message or bridged Ethernet frame).
     
        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 transport stream channels sent over a
        single common physical link (i.e. a transmission 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 an
        adaptation field, encryption details and time stamp information to
        synchronise a set of Transport Streams.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Expires December 2003                                         [page 5]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
     3. Description of method
     
        Routed IP packets and bridged Ethernet frames shall be encapsulated
        to form a Subnetwork Data Unit (SNDU). The method encapsulates IP
        packets, Ethernet frames or packets from other network protocols
        within a SNDU. The SNDU transmitted over an MPEG-2 transmission
        system, by placing it in the payload of a single TS Packet, or, if
        required, the SNDU may be fragmented into a series of TS Packets.
        Where there is sufficient space, the method allows a single TS
        Packet to carry more than one SNDU (or part there of).
     
        All packets from a SNDU shall be assigned the same PID, and shall
        therefore form a part of the same logical TS channel.
     
        The ULE encapsulation is limited to TS private streams only. In TS
        private streams, one may define the use of PUSI, AFC, and adaptation
        field as appropriate [ISO-MPEG].. The method relies upon use of the
        Payload Unit Start Indicator (PUSI) carried in the 4 byte header of
        each TS Packet.
     
        The header of each TS Packet carries a one bit Payload Unit Start
        Indicator (PUSI) field whose semantics is defined for PES and PSI
        packets; for private data its use is not defined in the MPEG-2
        standard. IN ULE, this bit is used by the encapsulation to identify
        the start of a payload unit within the MPEG-2 TS Packet Payload.
        Hence, when used with this encapsulation, the following PUSI values
        are defined:
     
             0 - the TS Packet does not contain the start of a SNDU but the
             continuation or end of a SNDU;
     
             1 € the TS Packet contains the start of a SNDU, and a one byte
             pointer follows the last byte of the 4 byte TS Packet Header.
     
        The TS Packet Header also carries a two bit Adaptation Field Control
        (AFC) value.  This value is not used in this encapsulation method,
        and TS packets from a ULE encapsulator will normally be sent with an
        AFC value of '01'. Standard decoders shall discard TS Packets with
        the adaptation_field_control field set to a value of '00'; in the
        case of a null packet the value of the adaptation_field_control
        shall be set to '01'. The purpose of the adaptation field is
        primarily to carry timing and synchronisation information and
        occasionally to include stuffing bytes.
     
     
     
     
     
     
     
     
     
     
     Expires December 2003                                         [page 6]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
     4. SNDU Format
     
        The encapsulation format to be used for IP packets and bridged
        Ethernet frames is shown below:
     
        +---------------------------------------------------+--------+
        | length | type |        SNDU field                | CRC-32 |
        +---------------------------------------------------+--------+
     
        Figure 1: SNDU Encapsulation
     
     
        Note that the SNDU field might include a Òlabel‚ or some other form
        of discriminator field, which in combination with the PID value,
        could be interpreted as a ÒLink-Level address‚.
     
        Length Field
        A 16-bit value indicates the length in bytes of the SNDU
        (encapsulated Ethernet frame, IP datagram or other packet) counted
        from the byte following the type field up to and including the CRC.
        The special value 0x0000 indicates that there are no further SNDUs
        within the current TS packet (see section 5.1). The maximum value is
        65531 bytes.
     
     
        Type Field
        The 16-bit type field indicates the type of payload being sent.
        Three types are suggested in this document. These are:
     
        0x0800 : IPv4 Payload (according to IANA EtherTypes)
        0x86DD : IPv6 Payload (according to IANA EtherTypes)
        0x8847 : MPLS frame (according to IANA EtherTypes)
        0x????: ROHC Compressed IPv4 Packet
        0x????: ROHC Compressed IPv6 Packet
        0x6558: Bridged Ethernet Frame (i.e. MAC header follows)
     
        All other assignments should be coordinated with the values defined
        for IANA EtherTypes encapsulations.
     
        [AuthorÌs note: An assignment of one/two bits of the type field to
        indicate the presence of a MAC header following the SNDU type field
        may simplify receiving processing.  This may necessitate the use of
        alternate type codes to those described above. This is an area of
        future study, to be confirmed in the next revision of this draft.]
     
        [AuthorsÌ note: suitable values for bridged Ethernet Frames to be
        determined; suitable values for ROHC types to be determined]
     
     
        IPv4 SNDU
        The payload shall be a complete IPv4 datagram.
     
     
     Expires December 2003                                         [page 7]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
        IPv6 SNDU
        The payload shall be a complete IPv6 datagram.
     
        Bridged SNDU
        The payload shall be a bridged MAC frame (see section 4.1).
     
        CRC
        Each SNDU MUST have a CRC field carries a CRC value calculated by
        the encapsulator and checked by the receiver this protects the
        entire SNDU. A CRC-32 is recommended for SNDUs up to 12 KB in size.
        The primary purpose of this CRC is to protect an IP payload from
        undetected resassembly errors and errors introduced by unexpected
        software / hardware operation at the IP encapsulation gateway and/or
        the receiver. It may also be used to detect the presence of
        uncorrected errors from the physical link (these however may, in
        some case, also be detected by other means).
     
     
        4.1 Bridged Payload
     
        The Bridged Payload shall carry an SNDU field with the following
        format shown in figure 2.
     
             +-------------------------------+
             |  Length and Type  fields (4B) |
             +-------------------------------+
             |  MAC destination address (6B) |
             +-------------------------------+
             |  MAC source address      (6B) |
             +-------------------------------+
             |  Ethernet (DIX) Type     (2B) |
             +-------------------------------+
             |                               |
             |   (remainder of MAC frame)    |
             |                               |
             +-------------------------------+
             | CRC_32                   (4B) |
             +-------------------------------+
     
        Figure 2: SNDU Format for a Bridged Payload
     
        The MAC addresses shall be assigned according to the rules specified
        by the IEEE and may denote unknown, unicast, broadcast, and
        multicast link addresses. The type of frame shall be defined
        according to Ethernet [DIX]. Note that Òarp messages‚ relate to the
        binding of MAC addresses to IP addresses are carried in this format
        and are identified by the appropriate DIX Ethernet frame type.
     
     In normal operation, it is expected that any padding appended to the
     Ethernet frame will be removed prior to forwarding. This requires the
     sender to be aware of such padding.
     
     
     Expires December 2003                                         [page 8]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
        32-bit CRC
        The LAN FCS field, is in this case not forwarded by the
        encapsulation, and is replaced by a CRC-32 calculated by the IP
        encapsulator.  Note: It is assumed the LAN FCS is checked prior to
        removal.
     
     
        4.2 IPv4 Encapsulation
     
        IPv4 datagrams will be transported over the MPEG-2 Transport Stream
        using the SNDU structure shown in figure 3.
     
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |   Length  (2B)        |     Type = 0x0800     |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                                               |
          |                IPv4 datagram                  |
          |                                               |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                   (CRC_32)                    |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     
        Figure 3: SNDU Format for an IPv4 Datagram
     
     
        4.3 IPv6 Encapsulation
     
        IPv6 datagrams will be transported over the MPEG-2 Transport Stream
        using the SNDU structure shown in figure 4.
     
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |   Length  (2B)        |     Type = 0x86DD     |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                                               |
          |                IPv6 datagram                  |
          |                                               |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                   (CRC_32)                    |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     
        Figure 4: SNDU Format for an IPv6 Datagram
     
     
     
     
     
     
     
     
     
     
     
     
     Expires December 2003                                         [page 9]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
     5. Processing at the Encapsulator and Receiver
     
        5.1 Encapsulator processing
     
        The encapsulator shall fragment the SNDU into a series of MPEG-2 TS
        Packets belonging to the same logical TS channel (figure 5).
     
                    +-----------------------------------------+
                    |Encap Header|       Subnetwork PU        |
                    +-----------------------------------------+
                   /         /                          \      \
                  /         /                            \      \
                 /         /                              \      \
         +------*----------*  +------*----------*   +------*----------+
         |MPEG-2| MPEG-2   |..|MPEG-2| MPEG-2   |...|MPEG-2| MPEG-2   |
         |Header| Payload  |  |Header| Payload  |   |Header| Payload  |
         +------+----------+  +------+----------+   +------+----------+
     
        Figure 5: Encapsulation of a subnetwork Payload_Unit (SNDU) e.g. an
        IP datagram into a series of TS Packets (each TS Packet carries a
        header with a common Packet ID, PID, value).
     
        The encapsulation layer will first wrap each payload unit (IP
        datagram or Ethernet frame) to form a SNDU. (This is similar to an
        AAL5 encapsulation in ATM networks). This SNDU will then be
        segmented into payload units of TS Packets; the resulting set of TS
        Packets will all use the same PID value and successive values for
        the continuation counter. This set will then be sent as a sequence
        over a TS multiplex or possibly as one burst over a satellite link.
     
        Measurements of IP traffic have shown that the overwhelming majority
        of the datagrams have lengths of 1500 or 576 bytes for data and 40
        or 48 bytes for control traffic; for example, these values represent
        almost 96% of the typical world-wide-web traffic.
     
        The most frequent situations for the encapsulator are:
             -  a short control packet using only a fraction of the
                TS payload of 184 bytes;
             -  a long data packet using a number of TS Packets with
                the last one containing only a remainder.
                Both of the most frequent values (576 and 1500) lead
                to a fairly high overhead in the last TS Packet.
     
        Since radio/satellite bandwidth is an expensive resource, as opposed
        to bandwidth in LANs, it is necessary to look for improvements. One
        possibility is header compression but this is outside the scope of
        this proposal. Another one is to pack SNDUs densely into TS Packets,
        i.e. whenever the encapsulator has more than one SNDU available it
        fills the TS Packets completely by appending the data of the
        following SNDU directly to the preceding one before segmentation.
     
     
     
     Expires December 2003                                        [page 10]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
        When the encapsulator has not previously sent a TS Packet for the
        specified logical TS channel, or after an idle period, it will start
        sending the SNDU in the first available TS Packet.  This first TS
        Packet MUST carry a value of one in the payload_unit_start_indicator
        (PUSI) to indicate it contains the start of a SNDU. It will also
        carry a Payload Pointer value of one to indicate that the SNDU
        starts in the first available byte of the TS Packet payload.
     
        The encapsulator will continue to fill subsequent TS Packets, until
        the end of the SNDU.
     
        If the TS Packet carrying the final part of a SNDU has either zero
        or one byte of unused payload, the encapsulator will start
        transmission of the next SNDU in a new TS Packet. For the case of
        one remaining byte this MAY be assigned the value of 0x00, but this
        value MUST NOT be required at the receiver.
     
           +------------------+       +------------------+
           |   Subnetwork     |       |   Subnetwork     |
           |      DU 1        |       |      DU 2        |
           +------------------+       +------------------+
                      \        \     /          /
                       \        \   /          /
                        \        \ /          /
         +------+--------+--------+----------+
         |MPEG-2| Payload| end of | start of |
         |Header| Pointer| SNDU 1 | SNDU 2   |
         +------+--------+--------+----------+
                    |              ^
         PUSI=1     |              |
                    +--------------+
     
        Figure 6 A TS Packet carrying the end of SNDU 1, followed by SNDU 2
     
        If more packets are waiting at the encapsulator, and a TS Packet has
        more than two bytes of unused payload, it MAY start the next SNDU in
        the next available byte of the TS Packet payload. The PUSI MUST be
        set, if not already set. If the PUSI is set by this operation, the
        payload pointer MUST be assigned to the position of the byte
        following the end of the first SNDU in the TS Packet payload.
     
     
     
     
     
     
     
     
     
     
     
     
     
     Expires December 2003                                        [page 11]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
     
        +-------------+
        | Subnetwork  |
        |      DU 3   |
        +-------------+
              \        \
               \        \
                \        \
         +------+--------+--------+----------+
         |MPEG-2| end of | 0x0000 |  Unused  |
         |Header| SNDU 3 |        |          |
         +------+--------+--------+----------+
     
         PUSI=0            End
                           Indicator
     
        Figure 7 A TS Packet carrying the end of SNDU 3, followed by idle
     
     
        If the TS Packet carrying the final part of a SNDU has two or more
        bytes of unused payload, and an encapsulator does not start a new
        SNDU to use this unused payload, it MUST directly follow the final
        byte of the last SNDU with the value 0x00 00.  This value
        corresponds to a SNDU payload length of zero, and is an End
        Indicator, informing the receiver that there are no more SNDUs in
        this TS Packet payload.
     
        When a SNDU is less than the size of a TS Packet payload, a TS
        Packet may be formed which carries a PUSI value of one and also an
        End Indicator.
     
     
        5.2 Flushing the bitstream
     
        MPEG-2 multiplexers do not usually flush their buffers, but store TS
        Packets until the buffer fills, assuming that the data comes in a
        more or less continuous stream. In the case of data traffic, this
        assumption no longer holds, leading to the problem that the last IP
        datagram will be only partly transmitted unless a special Òpush‚
        packet is appended. This introduces additional overhead and is not
        an appealing solution.
     
        A further SNDU within the same TS Packet is only started if it is
        already available in the encapsulatorÌs buffer at the time the
        previous one is encapsulated. The encapsulator does not wait for
        another SNDU to fill a TS Packet, because this would introduce
        additional latency.
     
     
     
     
     
     
     Expires December 2003                                        [page 12]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
        5.3 Receiver Processing
     
        Receipt of a TS Packet with a non-zero PUSI value indicates that the
        TS Packet contains the start of a new SNDU.  It also indicates the
        presence of the Payload Pointer. The Payload Pointer value indicates
        that there are payload ((Payload Pointer) €1) bytes of the SNDU
        currently being reassembled at the start of the TS Packet payload. A
        Payload Pointer value equal to 0 or greater than 183 is illegal in
        ULE, and the SNDU reassembly MUST be aborted. This event may
        generate an error message.
     
        A receiver reassembles SNDUs from the TS Packets received from a
        logical TS channel. To perform this reassembly, the receiver may use
        a buffer to hold the partially assembled SNDU, referred to here as
        the Current SNDU buffer. Other implementations may choose to use
        other data structures, but must provide equivalent operations.
     
        Initialisation
     
        After initialisation or an idle period, the receiver discards the
        contents of the Current SNDU buffer and waits for the start of the
        next SNDU by waiting for a TS Packet with a PUSI value of 1.  All
        other TS Packets are discarded in this mode.
     
        A PUSI value of 1, indicates the presence of a Payload Pointer. For
        the first TS Packet received, the Payload Pointer will also normally
        have a value of 1.  Following a loss of synchronisation, values
        between 2 and 183 are permitted, in which case the receiver MUST
        discard ((Payload Pointer) €1) bytes, before starting reassembly of
        the next SNDU.
     
        Processing of received SNDUs
     
        The receiver reads the SNDU Length field from the current SNDU. If
        this Length is less than or equal to 3, the receiver discards the
        Current SNDU and the remaining TS Packet payload and returns to a
        search for the next TS Packet with a PUSI value of 1.
     
        If the Length of the Current SNDU is greater than 4, it then accepts
        bytes from the TS Packet payload to the Current SNDU buffer until
        either Length bytes in total are received, or the end of the TS
        Packet is reached. When Length bytes are received, the receiver MUST
        calculate and verify the CRC value. SNDUs that contain an invalid
        CRC value MUST be discarded. After receiving a valid SNDU, the
        receiver MUST check the Type Field. The SNDU payload is then passed
        to the next protocol layer specified. An SNDU with an unknown Type
        value MUST be discarded.
     
        The receiver then starts reassembly of the next SNDU. This may
        directly follow the previously reassembled SNDU within the TS Packet
        Payload.
     
     
     Expires December 2003                                        [page 13]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
     
        If there is either 0 or 1 byte of payload data remaining in the TS
        Packet after completion of the Current SNDU, the receiver MUST
        discard this remaining TS payload, and wait for the next TS Packet
        with the PUSI value set to 1.
     
        If there more than one byte of payload data remains in the TS Packet
        after completion of the Current SNDU, the receiver MUST accept the
        next bytes as the start of the next SNDU (or an End Indicator), and
        continue processing the next SNDU.
     
        Payload Pointer Checking
     
        A receiver that has partially received a SNDU (in the Current SNDU
        buffer) MUST also check the Payload Pointer, of any received packets
        with a PUSI value of 1.  A Payload Pointer value of 1 indicates that
        the receiver MUST discard any previously unreassembled SNDU, and
        start processing the new SNDU that directly follows the Payload
        Pointer.
     
        A Payload Pointer value greater than 1, indicates the receiver MUST
        complete processing of the current SNDU, if there are ((Payload
        Pointer)-1) bytes remaining to complete the ANDU. If the receiver
        has not completed the current SNDU, and the Length Field indicates
        that it is awaiting a greater number of bytes than the ((Payload
        Pointer) €1), then the receiver has detected a delimiting error and
        the partially received SNDU MUST be discarded. The receiver MUST
        also discard ((Payload Pointer) €1) bytes prior to the first SNDU in
        the TS Packet, where it shall restart reassembly.
     
        Other Error Condistions
     
        The receiver SHOULD also check the MPEG-2 Continuity Counter carried
        in the TS Packet Header.  This counter should increment by one for
        each TS Packet received on a logical TS channel. If the value is not
        incremented by one in successive packets (modulo 16), any partially
        received SNDU MUST be discarded. The receiver then waits for the
        next TS Packet with a PUSI value of 1.
     
        The receiver SHOULD also check the MPEG-2 Transport Error indicator
        carried in the TS Packet Header.  This flag indicates a transmission
        error for the logical TS channel. If the flag is set to a one, any
        partially received SNDU MUST be discarded. The receiver then waits
        for the next TS Packet with a PUSI value of 1.
     
     
     
     
     
     
     
     
     
     Expires December 2003                                        [page 14]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
     6. Summary
     
        This document defines a Ultra Lightweight Encapsulation (ULE) to
        perform efficient and flexible support for IPv4 and IPv6 network
        services over networks built upon the MPEG-2 Transport Stream (TS).
     
     7. Acknowledgments
     
        This draft is based on a previous draft authored by: Horst D.
        Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry
        Fairhurst. The authors wish to thank the members of the ip-dvb
        mailing list for the input provided. In particular, the many
        comments received from Patrick Cipiere.
     
     8. Security Considerations
     
        Security issues are not addressed in this document.
     
     9. 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, 26 July 00
     
        [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
        for the ATSC Data Broadcast Standard", Advanced Television Systems
        Committee (ATSC),Doc. A/91. 10 June 2001
     
        [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television
        Standard", Advanced Television Systems Committee (ATSC), Doc. A/54,
        4 Oct 95
     
        [ATSC-PSIP-TC] A/65A, "Program and System Information Protocol for
        Terrestrial Broadcast and Cable", Advanced Television Systems
        Committee (ATSC), Doc. A/65A, 23 Dec 1997, Rev. A € 31 May 2000
     
        [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV
        (DTV) Applications  over Satellite", Advanced Television Systems
        Committee (ATSC), Doc. A/80, 17 July 99
     
        [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 December 2003                                        [page 15]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
        [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).
     
        [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).
     
        [LLC] IEEE Logical Link Control (ANSI/IEEE Std 802.2/ ISO 8802.2),
        1985
     
        [RFC3077] E. Duros, W. Dabbous, H. Izumiyama, Y. Zhang, "A Link
        Layer Tunneling Mechanism for Unidirectional Links", RFC3077.
     
        [RFC3095] C. Bormann, et al, "RObust Header Compression (ROHC):
        Framework and four profiles: RTP, UDP ESP and uncompressed",
        RFC3095.
     
        [SI-DAT] SI-DAT group, "Second Draft DVB Specification for Data
        Broadcasting", Geneva, 15 Jan. 1997
     
     
     10.Authors' Addresses
     
        Godred Fairhurst
        Department of Engineering
        University of Aberdeen
        Aberdeen, AB24 3UE
        UK
        Email: gorry@erg.abdn.ac.uk
        Web: http://www.erg.abdn.ac.uk/users/gorry
     
        Bernhard Collini-Nocker
        Institute of Computer Sciences
     
     Expires December 2003                                        [page 16]


     INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB        May 2003
     
     
        University of Salzburg
        Jakob Haringer Str. 2
        5020 Salzburg
        Austria
        Email: [bnocker]@cosy.sbg.ac.at
        Web: http://www.cosy.sbg.ac.at/cs/
     
     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.
     
     
     11. IANA Considerations
     
     
        This document will require IANA involvement.
     
        The payload type field defined in this document must be aligned with
        an existing IANA registry or the following values need to be
        assigned by the IANA:
     
             Payload Type Field
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Expires December 2003                                        [page 17]
     

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