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

Versions: (draft-fair-ipdvb-ule) 00 01 02 03 04 05 06 RFC 4326

Internet Engineering Task Force                         Gorry Fairhurst
Internet Draft                             University of Aberdeen, U.K.
Document: draft-ietf-ipdvb-ule-02.txt           Bernhard Collini-Nocker
                                              University of Salzburg, A


ipdvb WG

Category: Draft, Intended Standards Track                  October 2004


        Ultra Lightweight Encapsulation (ULE) for transmission of
                IP datagrams over MPEG-2/DVB networks

Status of this Draft

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Abstract

   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. This document describes an Ultra Lightweight
   Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6
   Datagrams and other network protocol packets directly over ISO MPEG-
   2 Transport Streams (TS) as TS Private Data. ULE supports an
   extension format that allows it to carry both optional (with an
   explicit extension length) and mandatory (with an implicit extension
   length) header information to assist in network/Receiver processing
   of a SNDU.

















Expires April 2005                                            [page 1]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   [RFC EDITOR NOTE:
   This section must be deleted prior to publication]

   DOCUMENT HISTORY

   Draft 00
   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

   --------------------------------------------------------------------
   DRAFT 01 (Protocol update)

   * Padding sequence modified to 0xFFFF, this change aligns with other
   usage by MPEG-2 streams. Treatment remains the same as specified for
   ULE.

   * SDNU Format updated to include R-bit (reserved).

   * Procedure for TS Packet carrying the final part of a SNDU with
   either less than two bytes of unused payload updated.

   * A Receiver MUST silently discard the remainder of a TS Packet
   payload when two or less bytes remain unprocessed following the end
   of a SNDU, irrespective of the PUSI value in the received TS Packet.
   It MUST NOT record an error when the value of the remaining byte(s)
   is identical to 0xFF or 0xFFFF.  The Receiver MUST then wait for a
   TS Packet with a PUSI value set to 1.

   * Payload Pointer description updated.

   * CRC Calculation added.

   * Decapsulator processing revised.

   * Type field split into two.

   * References updated.

   * Security considerations added (first draft).

   * Appendix added with examples.

   --------------------------------------------------------------------
















Expires December 2004                                         [page 2]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   DRAFT - 02 (Improvement of clarity)

   * Corrected CRC-32 to follow standard practice in DSM-CC.

   * Removed LLC frame type, now redundant by Bridge-Type (==1)

   * Defined D-bit to use the reserved bit field (R ) - Gorry, Alain,
   Bernhard

   * Changes to description of minimum payload length. Gorry

   * MPEG-2 Error Indicator SHOULD be used.Hilmar & Gorry

   * MPEG-2 CC MAY be used (since CRC-32 is strong anyway). Hilmar &
   Gorry

   * Corrected CRC-32 to now follow standard practice in DSM-CC. Gorry,
   Hilmar, Alain.

   * Changed description of Encapsulator action for Packing. Gorry &
   Hilmar.

   * Changed description of Receiver to clarify packing. Gorry & Alain.

   * Stuff/Pad of unused bytes MUST be 0xFF, to align with MPEG.
   Hilmar/Bernhard.

   * Recommend removal of section on Flushing bit stream. Gorry

   * Updated SNDU figures to reflect D-bit and correct a mistake in the
   bridged type field. Alain

   * Reorganised section 5 to form sections 5 and 6, separating
   encapsulation and receiver processing. Gorry, Hilmar, Alain.

   * Added concept of Idle State and Reassembly State to the Receiver.
   Renumbered sections 5,6 and following.  Gorry.

   * Nits from Alain, Hilmar and Gorry.
   Moved security issue on the design of the protocol to appropriate
   sections, since this is not a concern for deployment: Length field
   usage and padding initialisation.

   * Changed wording: All multi-byte values in ULE (including Length,
   Type, and Destination fields) are transmitted in network byte order
   (most significant byte first). old NiT from Alain, now fixed.

   * Frame byte size in diagrams now updated to -standard- format, and
   D bit action corrected, as requested by Alain.












Expires December 2004                                         [page 3]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   * Frame format diagrams, redrawn to 32-bit format below:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   * Additional diagram requested by Alain for D=0 bridging (added, and
   subsequent figures renumbered).

   * Diagrams of encapsulation process, redrawn for clarity (no change
   to meaning). Gorry.

   * Reworded last para of CRC description.

   * Clarification to the statements in the CRC coverage - to make it
   clear that it is the entire SNDU (header AND payload) that is
   checksummed. (Fritsche@iabg.de, hlinder@cosy.sbg.ac.at).

   * References added for RCS (spotted by Alain) and AAL5 (provided by
   Anthony Ang).

   * Removed informative reference to MPEG part 1.Alain.
   Spelling correction -> Allain to Alain.

   * Added description of Receiver processing of the address
   field.Gorry

   * Added caution on LLC Length in bridged Packets thanks.
   Gorry/wolfgang

   * Removed Authors notes from text after their discussion on the list
   Gorry

   * Corrected text to now say maximum value of PP = 182 in ULE. Gorry

   * Tidied diagrams at end (again) - Gorry,

Revision with following changes:

  * Re issue as working group draft (filename change)
  * Refinement of the text on CRC generation to be unambiguous.
  * Revised CC processing at Encapsulator (B C-N/GF/A.Allison)
  * Revised CC processing at Receiver (from List: A.Allison; et al )
  * Corrections to length/PP field in Examples (M Sooriyabandara,
  Alain)
  * Corrections to pointer in Example 3 SNDU C (M Jose-Montpetit)
  * Section 4.5 only SHARED routed links require D=0
  * Packing Threshold defined
  * Next-Layer-Header defined
  * Addition of Appendix B (to aide verification of SNDFU format)







   Working Group ID rev 01

   Issues addressed:
   * Typographical


Expires December 2004                                         [page 4]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   * Types > 1500 should be passed to the next higher protocol (Hilmar)
   * The second part of the Type space corresponds to the values 1500
   COMMENT: ~Range should be 1536 Decimal Decimal to 0xFFFF.
   * IANA has already defined IP and IPv6 types - corrected text!
   Added more security considerations (-01d).
   * Should we allow an Adaptation Field within ULE (request for DVB-
   RCS compatibility)? Requirement to be clarified! Implementation
   impact to be evaluated!
   Current Recommendation: The current spec does not preclude use of
   AF, it simply says that this is not the standard for ULE.  The use
   case and requirement for this mode are not currently clear, based on
   this there is no current intention to add this to ULE - text for
   requirements would be welcome.
   * Verify the minimum value allocated to DIX Ethernet Header Types.
   Draft updated to align with IEEE Registry assignments.

   --------------------------------------------------------------------

   Working Group ID rev 02

   Revised IPR disclosure
   Revised copyright notice

  Section 5 added to ULE to define optional extension headers (see
  xule)

  Correction of figure numbering.
  Correction to capitalisation in Transport Stream definition of fields
  Inserted space character after 1536 in line 2 of 4.4.2
  Replaced } with ] after ISO_DSMCC
  Replace reference to section 6.3 with section 7.3 at end of section
  4.6.
  Reference in 4.7.4 was changed to refer to figure 7 (not 6).
  Note added after figure 9.

  7.2 Changed, New text: <<SNDUs that contain an invalid CRC value MUST
  be discarded, causing the Receiver to processes the next in-sequence
  SNDU (if any).>> The rationale is that the this a SNDU-integrity
  check - rather than a framing issue. The mantra of being liberal in
  what is accepted suggests we discard, but not that we also discard
  succeeding SNDUs.



  Known issues with this revision of the document:

  (i)    The worked hexadecimal example in the annexe needs to be
          reworked.
  (ii)   The IANA procedures need to be checked with IANA.
  (iii)  Format page breaks in next rev!


   [END of RFC EDITOR NOTE]








Expires December 2004                                         [page 5]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


Table of Contents


   1. Introduction
   2. Conventions used in this document
   3. Description of method
   4. SNDU Format
     4.1 Destination Address Present Field
     4.2 Length Field
     4.3 End Indicator
     4.4 Type Field
       4.4.1 Type 1: IANA Assigned Type Fields
       4.4.2 Type 2: Ethertype Compatible Type Fields
     4.5 SNDU Destination Address Field
     4.6 SNDU Trailer CRC
     4.7 Description of SNDU Formats
       4.7.1 End Indicator
       4.7.2 IPv4 SNDU Encapsulation
       4.7.3 IPv6 SNDU Encapsulation
       4.7.4 Test SNDU
   5. Extension Headers
        5.1 Mandatory Extension Header
        5.2 Optional Extension Header
   6.Processing at the Encapsulator
     6.1 SNDU Encapsulation
     6.2 Procedure for Padding and Packing
   7. Receiver Processing
     7.1 Idle State
       7.1.1 Reassembly Payload Pointer Checking
     7.2 Processing of a Received SNDU
       7.2.1 Reassembly Payload Pointer Checking
     7.3 Other Error Conditions
   8. Summary
   9. Acknowledgments
   10. Security Considerations
   11. References
     11.1 Normative References
     11.2 Informative References
   12. Authors' Addresses
   13. IPR Notices
   14. Copyright Statement
        14.1     Intellectual Property Statement
        14.2 Disclaimer of Validity
   15. IANA Considerations

   ANNEXE A: Informative Appendix - SNDU Packing Examples
   ANNEXE B: Informative Appendix - SNDU Encapsulation














Expires December 2004                                         [page 6]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


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; ID-ipdvb-arch].  It 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 provide unidirectional (simplex) physical and
   link layer standards.  Support has 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]).

   Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other
   network layer packets) for transmission over an MPEG-2 Transport
   Multiplex are passed to an Encapsulator. This formats each PDU into
   a Subnetwork Data Unit (SNDU) by adding an encapsulation header and
   an integrity check trailer. The SNDU is fragmented into a series of
   TS Packets) that are sent over a single TS Logical Channel.






































Expires December 2004                                         [page 7]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


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, a pair of bits carried in the TS
   Packet header that signal the presence of the Adaptation Field
   and/or TS Packet payload.

   ATSC: Advanced Television Systems Committee [ATSC]. A framework and
   a set of 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 format for transmission of data and control information defined by
   the ISO MPEG-2 standard that is carried in an MPEG-2 Private
   Section.

   DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of
   associated standards published by the European Telecommunications
   Standards Institute (ETSI) for the transmission of video, audio, and
   data, using the ISO MPEG-2 Standard.

   ENCAPSULATOR: A network device that receives PDUs and formats these
   into Payload Units (known here as SNDUs) for output as a stream of
   TS Packets.

   END INDICATOR: A Type value that indicates to the Receiver that
   there are no further SNDUs present within the current TS Packet.

   MAC: Medium Access and Control. The link layer header of the
   Ethernet IEEE 802 standard of protocols, consisting of a 6B
   destination address, 6B source address, and 2B type field.

   MPE: Multiprotocol Encapsulation [ETSI-DAT; ATSC-DAT ; ATSC-DATG]. A
   scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each
   Section is sent in a series of TS Packets using a single 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].

   NEXT-HEADER: A Type value indicating an extension header.

   NPA: Network Point of Attachment. In this document, refers to a 6 B
   destination address (similar to an Ethernet MAC address) within the
   MPEG-2 transmission network used to identify individual Receivers or
   groups of Receivers.

   PACKING THRESHOLD: A period of time an Encapsulator is willing to
   defer transmission of a partially filled TS-Packet to accumulate
   more SNDUs, rather than use Padding. After the Packet Threshold
   period, the Encapsulator uses Padding to send the partially filled
   TS-Packet.

   PDU: Protocol Data Unit. Examples of PDU include Ethernet frames,
   IPv4 or IPv6 datagrams, and other network packets

Expires December 2004                                         [page 8]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004



   PES: Packetized Elementary Stream of MPEG-2 [ISO-MPEG].

   PID: Packet Identifier. A 13 bit field carried in the header of TS
   Packets. This is used to identify the TS Logical Channel to which a
   TS Packet belongs [ISO-MPEG]. The TS Packets forming the parts of a
   Table Section, PES, or other payload unit must all carry the same
   PID value.  The all 1s PID value indicates a Null TS Packet
   introduced to maintain a constant bit rate of a TS Multiplex.

   PP: Payload Pointer. An optional one byte pointer that directly
   follows the TS Packet header. It contains the number of bytes
   between the end of the TS Packet header and the start of a Payload
   Unit. The presence of the Payload Pointer is indicated by the value
   of the PUSI bit in the TS Packet header. The Payload Pointer is
   present in DSM-CC, and Table Sections, it is not present in TS
   Logical Channels that use the PES-format.

   PU: Payload Unit. A sequence of bytes sent using a TS. Examples of
   Payload Units include: an MPEG-2 Table Section or a ULE SNDU.

   PUSI: Payload_Unit_Start_Indicator of MPEG-2 [ISO-MPEG]. A single
   bit flag carried in the TS Packet header. A PUSI value of zero
   indicates that the TS Packet does not carry the start of a new
   Payload Unit. A PUSI value of one indicates that the TS Packet does
   carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1
   also indicates the presence of a one byte Payload Pointer (PP).

   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 Table Sections, however all Table Sections
   must be carried over a single TS Logical Channel.

   PSI: Program Specific Information. Tables used to convey information
   about the service carried in a TS Multiplex. The set of PSI tables
   is defined by [ISO-MPEG], see also SI Table.

   SI TABLE: Service Information Table. In this document, this term
   describes any table used to convey information about the service
   carried in a TS Multiplex. SI tables are carried in MPEG-2 private
   sections.

   SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2
   Payload Unit.

   TABLE SECTION: A Payload Unit carrying a part of a MPEG-2 SI Table.

   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 HEADER: The 4 byte header of a TS Packet as illustrated in the
   introduction.

   TS LOGICAL CHANNEL: Transport Stream Logical Channel, a channel
   identified at the MPEG-2 level [ISO-MPEG]. It exists at level 2 of
   the ISO/OSI reference model. All packets sent over a TS Logical
   Channel carry the same PID value. According to MPEG-2, some TS
   Logical Channels are reserved for specific signalling purposes.


Expires December 2004                                         [page 9]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   Other standards (e.g., ATSC, DVB) also reserve specific TS Logical
   Channels.

   TS MULTIPLEX: A set of MPEG-2 TS Logical Channels sent over a single
   common physical link (i.e. a transmission at a specified symbol
   rate, FEC setting, and transmission frequency). The same TS Logical
   Channel may be repeated over more than one TS Multiplex, for example
   to redistribute the same multicast content to two terrestrial TV
   transmission cells.

   TS PACKET: A fixed-length 188B unit of data sent over a TS Multiplex
   [ISO-MPEG]. Each TS Packet carries a 4B header, plus optional
   overhead including an Adaptation Field, encryption details and time
   stamp information to synchronise a set of related Transport Streams.
   The 188B TS Packets incorporate a 4B header with the following
   fields (those referenced within this document are marked with *):

        Field Length            Name/Purpose
         (in bits)

         8b             Synchronisation pattern equal 0x47
        *1b             Transport Error Indicator
        *1b             Payload Unit Start Indicator (PUSI)
         1b             Transport Priority
        *13b            Packet IDentifier (PID)
         2b             Transport scrambling control
        *2b             Adaptation Field Control (AFC)
        *4b             Continuity Counter (CC)

































Expires December 2004                                        [page 10]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


3. Description of the Method

   PDUs (IP packets, Ethernet frames or packets from other network
   protocols) are encapsulated to form a Subnetwork Data Unit (SNDU).
   The SNDU is transmitted over an MPEG-2 transmission network by
   placing it either in the payload of a single TS Packet, or if
   required, an SNDU may be fragmented into a series of TS Packets.
   Where there is sufficient space, the method permits a single TS
   Packet to carry more than one SNDU (or part there of), sometimes
   known as Packing. All TS Packets comprising a SNDU MUST be assigned
   the same PID, and therefore form a part of the same TS Logical
   Channel.

   The ULE encapsulation is limited to TS private streams only. The
   header of each TS Packet carries a one bit Payload Unit Start
   Indicator (PUSI) field. The PUSI identifies the start of a payload
   unit (SNDU) within the MPEG-2 TS Packet payload. The semantics of
   the PUSI bit are defined for PES and PSI packets [ISO-MPEG]; for
   private data, its use is not defined in the MPEG-2 Standard. In ULE,
   although being private data, the operation follows that of PSI
   packets. Hence, the following PUSI values are defined:

        0: The TS Packet does NOT contain the start of a SNDU, but
        contains the continuation, or end of a SNDU;

        1: The TS Packet contains the start of a SNDU, and a one byte
        Payload Pointer follows the last byte of the TS Packet header.

   If a Payload Unit (SNDU) finishes before the end of a TS Packet
   payload, but it is not intended to start another Payload Unit, a
   stuffing procedure fills the remainder of the TS Packet payload with
   bytes with a value 0xFF [ISO-MPEG2], known as Padding.

   A Receiver processing MPEG-2 Table Sections is aware that when it
   receives a table_id value of 0xFF, this indicates Padding/Stuffing
   occurred and silently discards the remainder of the TS Packet
   payload. The payload of the next TS Packet for the same TS Logical
   Channel will begin with a Payload Pointer of value 0x00, indicating
   that the next Payload Unit immediately follows the TS Packet header.
   The ULE protocol resembles this, but differs in the exact procedure
   (see the following sections).

   The TS Packet Header also carries a two bit Adaptation Field Control
   (AFC) value. The purpose of the adaptation field is primarily to
   extend the TS header for timing and synchronisation information and
   may be used to also include stuffing bytes before a TS Packet
   payload. Standard Receivers discard TS Packets with an
   adaptation_field_control field value of '00'. Adaptation Field
   stuffing is NOT used in this encapsulation method, and TS Packets
   from a ULE Encapsulator MUST be sent with an AFC value of '01'.
   Receivers MUST discard TS Packets that carry other AFC values.










Expires December 2004                                        [page 11]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


4. SNDU Format

   PDUs (IP packets and bridged Ethernet frames) are encapsulated using
   ULE to form a SNDU. Each SNDU is sent as an MPEG-2 Payload Unit. The
   encapsulation format to be used for PDUs is illustrated below:

   < ----------------------------- SNDU ----------------------------- >
   +-+-------------------------------------------------------+--------+
   |D| Length | Type |                 PDU                   | CRC-32 |
   +-+-------------------------------------------------------+--------+

   Figure 1: SNDU Encapsulation

   All multi-byte values in ULE (including Length, Type, and
   Destination fields) are transmitted in network byte order (most
   significant byte first). Appendix A provides informative examples of
   usage.


   4.1 The Destination Address Present Field

   The most significant bit of the Length Field carries the value of
   the Destination Address Present Field, the D-bit. A value of 0
   indicates the presence of the Destination Address Field (see section
   4.5). A value of 1 indicates that a Destination Address Field is not
   present (i.e. it is omitted).

   By default, the D-bit value MUST be set to a value of 0, except for
   the transmission of an End Indicator (see 4.3), in which this bit
   MUST be set to the value of 1.


   4.2 Length Field

   A 15-bit value that 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.
   Note the special case described in 4.3.


   4.3 End Indicator

   When the first two bytes of a SNDU have the value 0xFFFF, this
   denotes an End Indicator (i.e., all 1s length combined with a D-bit
   value of 1). It indicates to the Receiver that there are no further
   SNDUs present within the current TS Packet (see section 6), and that
   no Destination Address Field is present. The value 0xFF has specific
   semantics in MPEG-2 framing, where it is used to indicate the
   presence of Padding. This use resembles [ISO-DSMCC].












Expires December 2004                                        [page 12]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   4.4 Type Field

   The 16-bit Type field indicates the type of payload carried in a
   SNDU, or the presence of a Next-Header. The set of values that may
   be assigned to this field is divided into two parts, similar to the
   allocations for Ethernet.

   Ethertypes were originally specified by Xerox under the DIX
   framework for Ethernet. After specification of IEEE 802.3 [LLC], the
   set of Ethertypes less than 1536 (0x0600), assumed the role of a
   length indicator. Ethernet receivers use this feature to
   discriminate LLC format frames. Hence any IEEE Ethertype < 1536
   indicates an LLC frame, and the actual value indicates the length of
   the LLC frame.

   There is a potential ambiguous case when a Receiver receives a PDU
   with two length fields:  The Receiver would need to validate the
   actual length and the Length field and ensure that inconsistent
   values are not propagated by the network. Specification of two
   independent length fields is therefore undesirable.  In the ULE
   header, this is avoided in the SNDU header by including only one
   length value, but bridging of LLC frames re-introduces this
   consideration (section 4.7.5).

   The Ethernet LLC mode of identification is not required in ULE,
   since the SNDU format always carries an explicit Length Field, and
   therefore the procedure in ULE is modified, as below:

   The first set of ULE Type Field values comprise the set of values <
   1536.  These Type Field values are IANA assigned (see 4.4.1), and
   indicate the Next-Header.

   The second set of ULE Type Field values comprise the set of values
   >= 1536. In ULE, this indicates that the value is identical to the
   corresponding type codes specified by the IEEE/DIX type assignments
   for Ethernet and recorded in the IANA EtherType registry.


   4.4.1 Type 1: Next-Layer-Header

   The first part of the Type space corresponds to the values  0 to
   1535 Decimal. These values may be used to identify link-specific
   protocols and/or to indicate the presence of extension headers that
   carry additional optional protocol fields (e.g. a bridging
   encapsulation). Use of these values is co-ordinated by an IANA
   registry.

   The following types are defined:

   [XXX IANA ACTION REQUIRED XXX]

   0x0000: Test SNDU, discarded by the Receiver.
   0x0001: Bridged Ethernet Frame (i.e. MAC source address follows)
   0x0100: Padding, ignored by the Receiver.

   [XXX END OF IANA ACTION REQUIRED XXX]

   The remaining values within the first part of the Type space are
   reserved for allocation by the IANA.


Expires December 2004                                        [page 13]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   4.4.2 Type 2: Ethertype compatible Type Fields

   The second part of the Type space corresponds to the values 1536
   Decimal (0x600) and 0xFFFF.  This set of type assignments follow
   DIX/IEEE assignments (but exclude use of this field as a frame
   length indicator) [LLC].  All assignments in this space MUST use the
   values defined for IANA EtherType, the following two Type values are
   used as examples (taken from the IANA Ethertypes registry):

   0x0800 : IPv4 Payload
   0x86DD : IPv6 Payload


   4.5 SNDU Destination Address Field

   The SNDU Destination Address Field is optional (see section 4.1).
   This field MUST be carried (i.e. D=0) for IP unicast packets
   destined to routers that are sent using shared links (i.e., where
   the same link connects multiple Receivers). A sender MAY omit this
   field (D=1) for an IP unicast packet and/or multicast packets
   delivered to Receivers that are able to utilise a discriminator
   field (e.g. the IPv4/IPv6 destination address), which in combination
   with the PID value, could be interpreted as a Link-Level address.

   When the SNDU header indicates the presence of a SNDU Destination
   Address field (i.e. D=0), a Network Point of Attachment, NPA, field
   directly follows the SNDU Type Field.  NPA destination addresses are
   6 Byte numbers, normally expressed in hexadecimal, used to identify
   the Receiver(s) in a MPEG-2 transmission network that should process
   a received SNDU. The value 0x00:00:00:00:00:00, MUST NOT be used as
   a destination address in a SNDU. The least significant bit of the
   first byte of the address is set to 1 for multicast frames, and the
   remaining bytes specify the link layer multicast address. The
   specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address,
   indicating this SNDU is to be delivered to all Receivers.


























Expires December 2004                                        [page 14]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   4.6 SNDU Trailer CRC

   Each SNDU MUST carry a 32-bit CRC field in the last four bytes of
   the SNDU. This position eases CRC computation by hardware.  The CRC-
   32 polynomial is to be used. Examples where this polynomial is also
   employed include Ethernet, DSM-CC section syntax [ISO-DSMCC] and
   AAL5 [ITU3563]. This is a 32 bit value calculated according to the
   generator polynomial represented 0x04C11DB7 in hexadecimal:

   x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0.

   The Encapsulator initialises the CRC-32 accumulator register to the
   value 0xFFFF FFFF.  It then accumulates a transmit value for the
   CRC32 that includes all bytes from the start of the SNDU header to
   the end of the SNDU (excluding the 32-bit trailer holding the CRC-
   32), and places this in the CRC Field. In ULE, the bytes are
   processed in order of increasing position within the SNDU, the order
   of processing bits is NOT reversed.  This use resembles, but is
   different to that in SCTP [RFC3309].

   The Receiver performs an integrity check by independently
   calculating the same CRC value and comparing this with the
   transmitted value in the SNDU trailer. SNDUs that do not have a
   valid CRC, are discarded, causing the Receiver to enter the Idle
   State.

   This description may be suited for hardware implementation, but this
   document does not imply any specific implementation.  Software-based
   table-lookup or hardware-assisted software-based implementations are
   also possible. Annexe B provides an example of an Encapsulated PDU
   that includes the computed CRC-32 value.

   The primary purpose of this CRC is to protect the SNDU (header, and
   payload) from undetected reassembly errors and errors introduced by
   unexpected software / hardware operation while the SNDU is in
   transit across the MPEG-2 subnetwork and during processing at the
   encapsulation gateway and/or the Receiver. It may also detect the
   presence of uncorrected errors from the physical link (however,
   these may also be detected by other means, e.g. section 7.3).






















Expires December 2004                                        [page 15]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   4.7 Description of SNDU Formats

   The format of a SNDU is determined by the combination of the
   Destination Address Present bit (D) and the SNDU Type Field.  The
   simplest encapsulation places a PDU directly into a SNDU payload.
   Some Type 1 encapsulations may require additional header fields.
   These are inserted in the SNDU directly preceding the PDU.

   The following SNDU Formats are defined here:

   End Indicator: The Receiver should enter the Idle State.
   IPv4 SNDU: The payload is a complete IPv4 datagram
   IPv6 SNDU: The payload is a complete IPv6 datagram.
   Test SNDU: The payload will be discarded by the Receiver.
   Bridged SNDU: The payload carries a bridged MAC or LLC frame.

   All other formats are currently reserved.


   4.7.1 End Indicator

   The format of the End Indicator is shown in figure 2. This format
   MUST carry a D-bit value of 1.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|                            0x7FFF                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      =        Arbitrary number (>= 0) bytes with value 0xFF          =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 2: SNDU Format for an End Indicator.



























Expires December 2004                                        [page 16]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   4.7.2 IPv4 SNDU

   IPv4 datagrams are transported using one of the two standard SNDU
   structures, in which the PDU is placed directly in the SNDU payload.
   The two encapsulations are shown in figures 3 and 4. (Note that in
   this, and the following figures, the IP datagram payload is of
   variable size, and is directly followed by the CRC-32).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|        Length  (15b)        |         Type = 0x0800         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Receiver Destination Address  (6B)              |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      =                           IPv4 datagram                       =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|        Length  (15b)        |         Type = 0x0800         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      =                           IPv4 datagram                       =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1).






















Expires December 2004                                        [page 17]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   4.7.3 IPv6 SNDU Encapsulation

   IPv6 datagrams are transported using one of the two standard SNDU
   structures, in which the PDU is placed directly in the SNDU payload.
   The two encapsulations are shown in figures 5 and 6.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|        Length  (15b)        |         Type = 0x086DD        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Receiver Destination Address  (6B)              |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      =                           IPv6 datagram                       =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|        Length  (15b)        |         Type = 0x086DD        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      =                           IPv6 datagram                       =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1).
























Expires December 2004                                        [page 18]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   4.7.4 Test SNDU

   A Test SNDU is of Type 1 (figure 7). The structure of the Data
   portion of this SNDU is not defined by this document. All Receivers
   MAY record reception in a log file, but MUST then discard any Test
   SNDUs. The D-bit MAY be set in a TEST SNDU.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D|        Length  (15b)        |         Type = 0x0000         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      =               Data (not forwarded by a Receiver)              =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 7: SNDU Format for a Test SNDU


   4.7.5 Bridge Frame SNDU Encapsulation

   A bridged SNDU is of Type 1.  The payload includes a MAC source and
   Ether-Type field together with the contents of a bridged MAC frame.
   The SNDU has the format shown in figures 8 and 9.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|        Length  (15b)        |         Type = 0x0001         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Receiver Destination Address  (6B)               |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                MAC Destination Address  (6B)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    MAC Source Address  (6B)                   |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |          EtherType (2B)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      =                 (Contents of bridged MAC frame)               =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 8: SNDU Format for a Bridged Payload (D=0)










Expires December 2004                                        [page 19]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


           0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|        Length  (15b)        |         Type = 0x0001         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   MAC Destination Address  (6B)               |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                     MAC Source Address  (6B)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          EtherType (2B)       |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      =                 (Contents of bridged MAC frame)               =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 9: SNDU Format for a Bridged Payload (D=1)

   Note: The final two bytes of the bridging header also carry a Type
   field (see section 5). In this special case, the extension mandatory
   header format permits this to carry a LLC Length field, specified by
   IEEE 802 [LLC] rather than an IANA assigned value.

   When an NPA address is specified (D=0), Receivers MUST discard all
   SNDUs that carry an NPA address that does NOT match their own NPA
   address (or a broadcast/mcast address), the payload of the remaining
   SNDUs are processed by the bridging rules that follow. An SNDU
   without an NPA address (D=1) results in a Receiver performing
   bridging processing on the payload of all received SNDUs.

   The MAC addresses in the frame being bridged SHOULD be assigned
   according to the rules specified by the IEEE and may denote unknown,
   unicast, broadcast, and multicast link addresses. These MAC
   addresses denote the intended recipient in the destination LAN, and
   therefore have a different function to the NPA addresses carried in
   the SNDU header. The EtherType field of a frame is defined according
   to Ethernet/LLC [LLC].

   A frame type < 1536 for a bridged frame, introduces a LLC Length
   Field. The Receiver MUST check this length and discard any frame
   with a length greater than permitted by the SNDU payload size.

   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 Ethernet padding.

   Ethernet frames received at the Encapsulator for onward transmission
   over ULE carry a Local Area Network Frame Check sequence, LAN FCS,
   field (e.g. CRC-32 for Ethernet). The Encapsulator MUST check the
   LAN-FCS value of all frames received, prior to further processing.
   Frames received with an invalid LAN FCS MUST be discarded. After
   checking, the LAN FCS is then removed (i.e., it is NOT forwarded in
   the bridged SNDU).  As in other ULE frames, the Encapsulator appends
   a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate
   LAN-FCS field will be appended to the bridged frame prior to onward
   transmission on the Ethernet interface.

Expires December 2004                                        [page 20]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   This design is readily implemented using existing network interface
   cards, and does not introduce an efficiency cost by transmitting two
   integrity check fields for bridged frames. However, it also
   introduces the possibility that a frame corrupted within the
   processing performed at an Encapsulator and/or Receiver may not be
   detected by the final recipient(s) (i.e. such corruption would not
   normally result in an invalid LAN FCS).





















































Expires December 2004                                        [page 21]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


5. Extension Headers

   This section describes an extension format for the ULE
   encapsulation. In ULE, a Type field value less than 1536 Decimal
   indicates a next-layer-header and is assigned from a separate IANA
   registry defined for ULE.

   The use of a single Type/next-layer-header registry simplifies
   processing and eliminates the need to maintain multiple IANA
   registries. The cost is that each extension header requires at least
   2 bytes. This is justified, on the basis of simplified processing
   and maintaining a simple lightweight header for the common case when
   no extensions are present.

   The 16-bit ULE next-layer-header field is used in place of the Type
   value. It is organised as a 5-bit zero prefix, a 3-bit H-LEN field
   and an 8-bit H-Type field, as follows:

   +----+-----+--------+
   |0000|H-LEN| H-TYPE |
   +----+-----+--------+

   Figure 10: Structure of ULE Next-Layer-Header Extension Type.

   The H-LEN Assignment

   0    Indicates a Mandatory Extension Header
   1    Indicates an Optional Extension Header of length 2B
   2    Indicates an Optional Extension Header of length 4B
   3    Indicates an Optional Extension Header of length 6B
   4    Indicates an Optional Extension Header of length 8B
   5    Indicates an Optional Extension Header of length 10BX
   >=6  the combined H-LEN and H-TYPE values indicate the Ethertype
        of a PDU that directly follows this Type field.

   A H-LEN of zero indicates a Mandatory Extension Header. Each
   specific Mandatory Extension header has a pre-defined length, that
   is not communicated in the H-LEN field. No additional limit is
   placed on the maximum length of a Mandatory Extension Header. A
   Mandatory Extension header MAY modify the format or encoding of the
   enclosed PDU (e.g. to perform encryption and/or compression).

   The H-Type is sent in a one byte field which may be either be
   one of 256 Mandatory Header Extensions or one of 256 Optional
   Header Extensions. The set of currently permitted H-Type values
   for both types of header extension are defined by an IANA Registry.

   The simplest examples of Extension Headers are Test and Padding.
   The Test Mandatory Extension Header results in the entire PDU
   being discarded. The Padding Optional Extension Header results
   in the following (if any) option header being ignored.










Expires December 2004                                        [page 22]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   The general format for an SNDU with extension headers is:

   <--------------------------   SNDU   --------------------------->
   +---+--------------------------------------------------+--------+
   |D=1| Length | T1 | H1 | T2 |           PDU            | CRC-32 |
   +---+--------------------------------------------------+--------+
   <-ULE base header->< ext 1 >

   Figure 11: SNDU Encapsulation with one Extension Header


   Where:
   D is the ULE D_bit (in this example D=1, however NPA addresses may
     also be used in combination with extension headers).
   T1 is the base header Type field. In this case, specifying a
      next-layer-header value.
   H1 is a set of fields defined for header type T1.  There may be 0
      or more bytes of information for a specific ULE extension header.
   T2 is the Type field of the next header, i.e. a value > 1535 B
      indicating the Ethertype of the PDU being carried.


   <--------------------------   SNDU   --------------------------->
   +---+---------------------------------------------------+--------+
   |D=1| Length | T1 | H1 | T2 | H2 | T3 |      PDU        | CRC-32 |
   +---+---------------------------------------------------+--------+
   <ULE base header-> < ext 1 > < ext 2 >

   Figure 12: SNDU Encapsulation with two Extension Headers

   Using this method several extension headers may be chained in
   series. Figure 12 shows an SNDU including two extension headers.
   The values of T1 and T2 are both less than 1536 Decimal, each
   indicating the presence of a next-layer-header rather than a
   directly following PDU. T3 has a value > 1535 indicating the
   Ethertype of the PDU being carried. Although an SNDU may contain
   an arbitrary number of consecutive extension headers, it is not
   expected that SNDUs will generally carry a large number.























Expires December 2004                                        [page 23]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004



6. Processing at the Encapsulator

   The Encapsulator forms the PDUs queued for transmission into SNDUs
   by adding a header and trailer to each PDU (section 4). It then
   segments the SNDU into a series of TS Packet payloads (figure 9).
   These are transmitted using a single TS Logical Channel over a TS
   Multiplex. The TS Multiplex may be processed by a number of MPEG-2
   (re)multiplexors before it is finally delivered to a Receiver.

                +------+--------------------------------+------+
                | ULE  |        Protocol Data Unit      | ULE  |
                |Header|                                |CRC-32|
                +------+--------------------------------+------+
               /         /                              \       \
              /         /                                \       \
             /         /                                  \       \
   +--------+---------+   +--------+---------+   +--------+---------+
   |MPEG-2TS| MPEG-2  |...|MPEG-2TS| MPEG-2  |...|MPEG-2TS| MPEG-2  |
   | Header | Payload |   | Header | Payload |   | Header | Payload |
   +--------+---------+   +--------+---------+   +--------+---------+

   Figure 13: Encapsulation of a SNDU into a series of TS Packets


   6.1 SNDU Encapsulation

   When an Encapsulator has not previously sent a TS Packet for a
   specific TS Logical Channel, or after an idle period, it starts to
   send a SNDU in the first available TS Packet.  This first TS Packet
   generated MUST carry a PUSI value of 1. It MUST also carry a Payload
   Pointer value of zero indicating the SNDU starts in the first
   available byte of the TS Packet payload.

   The Encapsulation MUST ensure that all TS Packets set the MPEG-2
   Continuity Counter carried in the TS Packet header, according to
   [ISO-MPEG].  This value MUST be incremented by one (modulo 16) for
   each successive fragment/complete SNDU sent using a TS Logical
   Channel.

   An Encapsulator MAY decide not to immediately send another SNDU,
   even if space is available in a partially filled TS Packet. This
   procedure is known as Padding (figure 11). It informs the Receiver
   that there are no more SNDUs in this TS Packet payload. The End
   Indicator is followed by zero or more unused bytes until the end of
   the TS Packet payload. All unused bytes MUST be set to the value of
   0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The padding
   procedure trades decreased efficiency against improved latency.













Expires December 2004                                        [page 24]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004



                 +-/------------+
                 |  SubNetwork  |
                 |     DU 3     |
                 +-/------------+
                        \        \
                         \        \
                          \        \
                 +--------+--------+--------+----------+
                 |MPEG-2TS| End of | 0xFFFF |  Unused  |
                 | Header | SNDU 3 |        |  Bytes   |
                 +--------+--------+--------+----------+
                   PUSI=0            ULE
                                     End
                                     Indicator

   Figure 14: A TS Packet carrying the end of SNDU 3, followed by an
   End Indicator.

   Alternatively, when more packets are waiting at an Encapsulator, and
   a TS Packet has sufficient space remaining in the payload, the
   Encapsulator can follow a previously encapsulated SNDU with another
   SNDU using the next available byte of the TS Packet payload (see
   6.2). This is called Packing (figure 15).

              +-/----------------+       +----------------/-+
              |   Subnetwork     |       |   Subnetwork     |
              |      DU 1        |       |      DU 2        |
              +-/----------------+       +----------------/-+
                         \        \     /          /\
                          \        \   /          /  \
                           \        \ /          /    \. . .
          +--------+--------+--------+----------+
          |MPEG-2TS| Payload| end of | start of |
          | Header | Pointer| SNDU 1 | SNDU 2   |
          +--------+--------+--------+----------+
            PUSI=1     |              ^
                       |              |
                       +--------------+

   Figure 15: A TS Packet with the end of SNDU 1, followed by SNDU 2.


   6.2 Procedure for Padding and Packing

   Five possible actions may occur when an Encapsulator has completed
   encapsulation of an SNDU:

   (i) If the TS Packet has no remaining space, the Encapsulator
   transmits this TS Packet. It starts transmission of the next SNDU in
   a new TS Packet. (The standard rules require the header of this new
   TS Packet to carry a PUSI value of 1, and a Payload Pointer value of
   0x00.)

   (ii) If the TS Packet carrying the final part of a SNDU has one byte
   of unused payload, the Encapsulator MUST place the value 0xFF in
   this final byte, and transmit the TS Packet. This rule provides a
   simple mechanism to resolve the complex behaviour that may arise
   when the TS Packet has no PUSI set. To send another SNDU in the
   current TS Packet, would otherwise require the addition of a Payload

Expires December 2004                                        [page 25]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   Pointer that would consume the last remaining byte of TS Packet
   payload.  The behaviour follows similar practice for other MPEG-2
   payload types [ISO-DSMCC]. The Encapsulator MUST start transmission
   of the next SNDU in a new TS Packet. (The standard rules require the
   header of this new TS Packet to carry a PUSI value of 1 and a
   Payload Pointer value of 0x00.)

   (iii) If the TS Packet carrying the final part of a SNDU has exactly
   two bytes of unused payload, and the PUSI was NOT already set, the
   Encapsulator MUST place the value 0xFFFF in this final two bytes,
   providing an End Indicator (section 4.3), and transmit the TS
   Packet. This rule prevents fragmentation of the SNDU Length Field
   over two TS Packets. The Encapsulator MUST start transmission of the
   next SNDU in a new TS Packet. (The standard rules require the header
   of this new TS Packet to carry a PUSI value of 1 and a Payload
   Pointer value of 0x00.)

   (iv) If the TS Packet has more than two bytes of unused payload, the
   Encapsulator MAY transmit this partially full TS Packet but MUST
   first place the value 0xFF in all remaining unused bytes (i.e.
   setting an End Indicator followed by Padding). The Encapsulator MUST
   start transmission of the next SNDU in a new TS Packet. (The
   standard rules require the header of this new TS Packet to carry a
   PUSI value of 1 and a Payload Pointer value of 0x00.)

   (v) If at least two bytes are available for payload data in the TS
   Packet payload (i.e. three bytes if the PUSI was NOT previously set,
   and two bytes if it was previously set), the Encapsulator MAY
   encapsulate further queued PDUs, by starting the next SNDU in the
   next available byte of the current TS Packet payload. The PUSI MUST
   be set.  When the Encapsulator packs further SNDUs into a TS Packet
   where the PUSI has NOT already been set, this requires the PUSI to
   be updated (set to 1) and an 8-bit Payload Pointer MUST be inserted
   in the first byte directly following the TS Packet header. The value
   MUST be set to the position of the byte following the end of the
   first SNDU in the TS Packet payload. If no further PDUs are
   available, an Encapsulator MAY wait for additional PDUs to fill the
   incomplete TS Packet. The maximum period of time an Encapsulator can
   wait, known as the Packing Threshold, MUST be bounded and SHOULD be
   configurable in the Encapsulator. If sufficient additional PDUs are
   NOT received to complete the TS Packet within the Packing Threshold,
   the Encapsulator MUST insert an End Indicator (using rule iv).

   Use of the Packing method (v) by an Encapsulator is optional, and
   may be determined on a per-session, per-packet, or per-SNDU basis.

   When a SNDU is less than the size of a TS Packet payload, a TS
   Packet may be formed that carries a PUSI value of one and also an
   End Indicator (using rule iv).


7. Receiver Processing

   A Receiver tunes to a specific TS Multiplex and sets a receive
   filter to accept all TS Packets with a specific PID.  These TS
   Packets are associated with a specific TS Logical Channel and are
   reassembled to form a stream of SNDUs.  A single Receiver may be
   able to receive multiple TS Logical Channels, possibly using a range
   of TS Multiplexes.  In each case, reassembly MUST be performed
   independently for each TS Logical Channel. To perform this

Expires December 2004                                        [page 26]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   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.

   Receipt of a TS Packet with a PUSI value of 1 indicates that the TS
   Packet contains the start of a new SNDU.  It also indicates the
   presence of the Payload Pointer (indicating the number of bytes to
   the start of the first SNDU in the TS-Packet currently being
   reassembled). It is illegal to receive a Payload Pointer value
   greater than 181, and this MUST cause the SNDU reassembly to be
   aborted and the Receiver to enter the Idle State. This event SHOULD
   be recorded as a payload pointer error.

   A Receiver MUST support the use of both the Packing and Padding
   method for any received SNDU, and MUST support reception of SNDUs
   with or without a Destination Address Field (i.e. D=0 and D=1).


   7.1 Idle State

   After initialisation, errors, or on receipt of an End Indicator, the
   Receiver enters the Idle State. In this state, the Receiver discards
   all TS Packets until it discovers the start of a new SNDU, when it
   then enters the Reassembly State. Figure 16 outlines these state
   transitions:



































Expires December 2004                                        [page 27]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


                                +-------+
                                | START |
                                +---+---+
                                    |
                                   \/
                               +----------+
                              \|   Idle   |/
                      +-------/|   State  |\-------+
         Insufficient |        +----+-----+        |
         unused space |             | PUSI set     | MPEG-2 TS Error
         or           |            \/              | or
         End Indicator|        +----------+        | SNDU Error
                      |        |Reassembly|        |
                      +--------|  State   |--------+
                               +----------+

   Figure 16: Receiver state transitions


   7.1.1 Idle State Payload Pointer Checking

   A Receiver in the Idle State MUST check the PUSI value in the header
   of all received TS Packets. A PUSI value of 1 indicates the presence
   of a Payload Pointer. Following a loss of synchronisation, values
   between 1 and 182 are permitted, in which case the Receiver MUST
   discard the number of bytes indicated by the Payload Pointer from
   the start of the TS Packet payload, before leaving the Idle State.
   It then enters the Reassembly State, and starts reassembly of a new
   SNDU at this point.


   7.2 Processing of a Received SNDU

   When in the Reassembly State, the Receiver reads a 2 byte SNDU
   Length Field from the TS Packet payload. If the value is less than
   or equal to 4, or equal to 0xFFFF, the Receiver discards the Current
   SNDU and the remaining TS Packet payload and returns to the Idle
   State. Receipt of an invalid Length Field is an error event and
   SHOULD be recorded as an SNDU length error.

   If the Length of the Current SNDU is greater than 4, the Receiver
   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 Current SNDU length equals the value of
   the Length Field, the Receiver MUST calculate and verify the CRC
   value (section 4.6). SNDUs that contain an invalid CRC value MUST be
   discarded, causing the Receiver to processes the next in-sequence
   SNDU (if any).

   When the Destination Address is present (D=0), the Receiver accepts
   SNDUs that match one of a set of addresses specified by the Receiver
   (this includes the NPA address of the Receiver, the NPA broadcast
   address and any required multicast NPA addresses). The Receiver MUST
   silently discard an SNDU with an unmatched address.

   After receiving a valid SNDU, the Receiver MUST check the Type Field
   (and process any Type 1 extensions specified). The SNDU payload is
   then passed to the next protocol layer specified. An SNDU with an
   unknown Type value < 1536 MUST be discarded. This error event SHOULD
   be recorded as a SNDU type error.

Expires December 2004                                        [page 28]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004



   The Receiver then starts reassembly of the next SNDU. This MAY
   directly follow the previously reassembled SNDU within the TS Packet
   payload.

   (i) If the Current SNDU finishes at the end of a TS Packet payload,
   the Receiver MUST enter the Idle State.

   (ii) If only one byte remains unprocessed in the TS Packet payload
   after completion of the Current SNDU, the Receiver MUST discard this
   final byte of TS Packet payload. It then enters the Idle State. It
   MUST NOT record an error when the value of the remaining byte is
   identical to 0xFF.

   (iii) If two or more bytes of TS Packet payload data remain after
   completion of the Current SNDU, the Receiver accepts the next 2
   bytes and examines if this is an End Indicator. When an End
   Indicator is received, a Receiver MUST silently discard the
   remainder of the TS Packet payload and transition to the Idle State.
   Otherwise this is the start of the next Packed SNDU, and the
   Receiver continues by processing this SNDU.


   7.2.1 Reassembly Payload Pointer Checking

   A Receiver that has partially received a SNDU (in the Current SNDU
   buffer) MUST check the PUSI value in the header of all subsequent TS
   Packets with the same PID (i.e. same TS Logical Channel). If it
   receives a TS Packet with a PUSI value of 1, it MUST then verify the
   Payload Pointer. If the Payload Pointer does NOT equal the number of
   bytes remaining to complete the Current SNDU, i.e., the difference
   between the SNDU Length field and the number of reassembled bytes,
   the Receiver has detected a delimiting error.

   Following a delimiting error, the Receiver MUST discard the
   partially assembled SNDU (in the Current SNDU buffer), and SHOULD
   record a reassembly error. It MUST then re-enter the Idle State.
























Expires December 2004                                        [page 29]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   7.3 Other Error Conditions

   The Receiver SHOULD check the MPEG-2 Transport Error Indicator
   carried in the TS Packet header.  This flag indicates a transmission
   error for a TS Logical Channel. If the flag is set to a value of
   one, a transmission error event SHOULD be recorded. Any partially
   received SNDU MUST be discarded. The Receiver then enters the Idle
   State.

   The Receiver MUST check the MPEG-2 Continuity Counter carried in the
   TS Packet header [ISO-MPEG]. If two (or more) successive TS Packets
   within the same TS Logical Channel carry the same Continuity Counter
   value, the duplicate TS Packets MUST be silently discarded. If the
   received value is NOT identical to that in the previous TS Packet,
   and it does NOT increment by one for successive TS Packets (modulo
   16), the Receiver has detected a continuity error. Any partially
   received SNDU MUST be discarded. A continuity counter error event
   SHOULD be recorded. The Receiver then enters the Idle State.

   Note that an MPEG2-2 Transmission network is permitted to carry
   duplicate TS Packets [ISO-MPEG], which are normally detected by the
   MPEG-2 Continuity Counter.  A Receiver that does not perform the
   above Continuity Counter check, would accept duplicate copies of TS
   Packets to the reassembly procedure. In most cases, the SNDU CRC-32
   integrity check will result in discard of these SNDUs, leading to
   unexpected PDU loss, however in some cases, duplicate PDUs (fitting
   into one TS Packet) could pass undetected to the next layer
   protocol.


8. Summary

   This document defines an 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).
   The encapsulation is also suited to transport of other protocol
   packets and bridged Ethernet frames.

   ULE also provides an extension header format and defines an
   associated IANA registry for efficient and flexible support of both
   mandatory and optional SNDU headers. This allows for future
   extension of the protocol, while providing backwards capability with
   existing implementations. In particular, Optional Extension Headers
   may safely be ignored by drivers that do not implement them, or
   choose not to process them.
















Expires December 2004                                        [page 30]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   9. 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 their input provided. In particular, the many
   comments received from Patrick Cipiere, Wolgang Fritsche, Hilmar
   Linder, Alain Ritoux, and William Stanislaus. Alain also provided
   the original examples of usage.


10. Security Considerations

   The security considerations for ULE resemble those that arise when
   the exiting Multi-Protocol Encapsulation (MPE) is used.  ULE does
   not add specific new threats that will impact the security of the
   general Internet.

   There is a known security issue with un-initialised stuffing bytes.
   In ULE, these bytes are set to 0xFF (normal practice in MPEG-2).

   There are known integrity issues with the removal of the LAN FCS in
   a bridged networking environment. The removal for bridged frames
   exposes the traffic to potentially undetected corruption while being
   processed by the Encapsulator and/or Receiver.

   There is a potential security issue when a Receiver receives a PDU
   with two length fields:  The Receiver would need to validate the
   actual length and the Length Field and ensure that inconsistent
   values are not propagated by the network. In ULE, this is avoided by
   including only one SNDU Length Field.  However, this issue still
   arises in bridged LLC frames, and frames with a LLC Length greater
   than the SNDU payload size MUST be discarded, and a SNDU payload
   length error SHOULD be recorded.

   ULE supports optional link level encryption of the SNDU payload.
   This is as an additional security mechanism to IP, transport or
   application layer security - not a replacement [ID-ipdvb-arch]. The
   approach is generic and decouples the encapsulation from future
   security extensions. The operation provides functions that resemble
   those currently used with the MPE encapsulation.

   A ULE Mandatory Extension Header may in future be used to define a
   mechanism to perform link encryption . Additional security control
   fields may be provided as a part of the extension header, e.g. to
   associate an SNDU with one of a set of Security Association (SA)
   parameters. As a part of the encryption process, it may also be
   desirable to authenticate some/all of the SNDU headers. The method
   of encryption and the way in which keys are exchanged is beyond the
   scope of this specification, as also are the definition of the SA
   format and that of the related encryption keys.










Expires December 2004                                        [page 31]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


11. References


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

   [RFC2026] Bradner, S., "The Internet Standards Process - Revision
   3", BCP 9, RFC 2026, BCP 9, 1996.

   [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, 1997.


   11.2 Informative References

   [ID-ipdvb-arch] "Requirements for transmission of IP datagrams over
   MPEG-2 networks", Internet Draft, Work in Progress.

   [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, 2000.

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

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

   [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


Expires December 2004                                        [page 32]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   television (DVB-T)", European Telecommunications Standards Institute
   (ETSI).

   [ETSI-RCS] ETSI 301 791 "Digital Video Broadcasting (DVB);
   Interaction Channel for Satellite Distribution Systems", 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).

   [ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification
   Type AAL5, International Standards Organisation (ISO), 1996.

   [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,
   Proposed Standard, 2001.

   [RFC3309] Stone, J., R. Stewart, D. Otis. "Stream Control
   Transmission Protocol (SCTP) Checksum Change". RFC3095, Proposed
   Standard, 2001.


12. 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
   Department of Scientific Computing
   University of Salzburg
   Jakob Haringer Str. 2
   5020 Salzburg
   Austria
   Email: [bnocker]@cosy.sbg.ac.at
   Web: http://www.cosy.sbg.ac.at/sc/
















Expires December 2004                                        [page 33]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   13. IPR Notices

   13.1 Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

   13.2 Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


   14. Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is
   subject to the rights, licenses and restrictions contained in
   BCP 78, and except as set forth therein, the authors retain all
   their rights.


















Expires December 2004                                        [page 34]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004




15. IANA Considerations

   This document will require IANA involvement.

   The ULE type field defined in this document requires a registry. The
   payload type field defined in this document requires creation of a
   new IANA registry:

   ULE Next-Protocol-Header registry

   This registry allocates values 0-512 (decimal).


   15.1 IANA Guidelines

   The following contains the IANA guidelines for management of the ULE
   Next-Protocol-Header registry. This registry allocates values
   decimal 0-512 (0x0000-0x01FF, hexadecimal). It MUST NOT allocate
   values greater than 0x01FF (decimal).

   It subdivides the Next-Layer-Header registry in the following way:

   1) 0-255 (decimal) IANA assigned values indicating Mandatory
     Extension Headers (or link-dependent type fields) for ULE,
     requiring prior issue of an IETF RFC.

     Assignments made in this document:

       0: Test-SNDU
       1: Bridged-SNDU

   2) 256-511 (decimal) IANA assigned values indicating Optional
     Extension Headers for ULE, requiring prior issue of an IETF RFC.

    Assignments made in this document:

      256: Padding





















Expires December 2004                                        [page 35]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   ANNEXE A: Informative Appendix

   This appendix provides some examples of use. The appendix is
   informative. It does not provide a description of the protocol.  The
   examples provide the complete TS Packet sequence for some sample
   encapsulated IP packets.

   The specification of the TS Packet header operation and field values
   is provided in [ISO-MPEG].  The specification of ULE is provided in
   the body of this document.

   The key below is provided for the following examples.

   HDR    4B TS Packet Header
   PUSI   Payload Unit Start Indicator
   PP     Payload Pointer
   ***    TS Packet Payload Pointer (PP)


   Example A.1: Two 186B PDUs.

     SNDU A is 200 bytes (including destination MAC address)
     SNDU B is 200 bytes (including destination MAC address)

   The sequence comprises 3 TS Packets:

                      SNDU
           PP=0      Length
   +-----+------+------+------+-   -+------+
   | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
   +-----+----*-+-*----+------+-   -+------+
   PUSI=1     *   *
              *****
                                          SNDU
           PP=17           CRC for A     Length
   +-----+------+------+-   -+--- --+------+------+-   -+------+
   | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0xC4 | ... | B165 |
   +-----+----*-+------+-   -+------+-*----+------+-   -+------+
   PUSI=1     *                       *
              *************************

                                 End     Stuffing
                    CRC for A Indicator   Bytes
   +-----+------+-   -+------+----+----+-   -+----+
   | HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF|
   +-----+------+-   -+------+----+----+-   -+----+
   PUSI=0














Expires December 2004                                        [page 36]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   Example A.2: Usage of last byte in a TS-Packet

     SNDU A is 183 bytes
     SNDU B is 182 bytes
     SNDU C is 181 bytes
     SNDU D is 185 bytes

   The sequence comprises 4 TS Packets:

                       SNDU
            PP=0      Length     CRC for A
    +-----+------+------+------+-   -+------+
    | HDR | 0x00 | 0x00 | 0x63 | ... | A182 |
    +-----+----*-+-*----+------+-   -+------+
    PUSI=1     *   *
               *****
                       SNDU                  Unused
            PP=0      Length       CRC for B  byte
    +-----+------+------+------+-   -+------+------+
    | HDR | 0x00 | 0x00 | 0x62 | ... | B181 | 0xFF |
    +-----+---*--+-*----+------+-   -+------+------+
    PUSI=1    *    *
              ******
                       SNDU                       SNDU
            PP=0      Length      CRC for C      Length
    +-----+------+------+------+-   -+------+------+------+
    | HDR | 0x00 | 0x00 | 0x61 | ... | C180 | 0x00 | 0x65 |
    +-----+---*--+-*----+------+-   -+------+------+------+
    PUSI=1    *    *
              ******           Unused
                                byte
    +-----+------+-   -+------+------+
    | HDR | D002 | ... | D184 | 0xFF |
    +-----+------+-   -+------+------+
     PUSI=0


























Expires December 2004                                        [page 37]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   Example A.3: Large SNDUs

   SNDU A is 732 bytes
   SNDU B is 284 bytes

   The sequence comprises 6 TS Packets:

                       SNDU
            PP=0      Length
    +-----+------+------+------+-   -+------+
    | HDR | 0x00 | 0x02 | 0xD8 | ... | A182 |
    +-----+---*--+-*----+------+-   -+------+
    PUSI=1    *    *
              ******

    +-----+------+-   -+------+
    | HDR | A183 | ... | A366 |
    +-----+------+-   -+------+
    PUSI=0


    +-----+------+-   -+------+
    | HDR | A367 | ... | A550 |
    +-----+------+-   -+------+
    PUSI=0

                                           SNDU
            PP=181         CRC for A      Length
    +-----+------+------+-   -+------+------+------+
    | HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 |
    +-----+---*--+------+-   -+------+*-----+------+
    PUSI=1    *                       *
              *************************

    +-----+------+-   -+------+
    | HDR | B002 | ... | B185 |
    +-----+------+-   -+------+
    PUSI=0

                                    End          Stuffing
                                 Indicator        Bytes
    +-----+------+-   -+------+------+------+-   -+------+
    | HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
    +-----+------+-   -+------+------+------+-   -+------+
    PUSI=0
















Expires December 2004                                        [page 38]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   Example A.4: Packing of SNDUs

     SNDU A is 200 bytes
     SNDU B is 60 bytes
     SNDU C is 60 bytes

   The sequence comprises two TS Packets:

                       SNDU
            PP=0      Length
    +-----+------+------+------+-   -+------+
    | HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
    +-----+----*-+-*----+------+-   -+------+
    PUSI=1     *   *  +      +
               *****  ++++++++
                       +
                       +++++++++++++++++
                                       +   SNDU
            PP=17           CRC for A  +  Length
    +-----+------+------+-   -+------+-+----+------+-
    | HDR | 0x11 | A183 | ... | A199 | 0x00 | 0x38 | ...
    +-----+----*-+------+-   -+------+*-----+------+-
    PUSI=1     *                      *  +       +
               ************************  +++++++++
                                          +
    +++++++++++++++++++++++++++++++++++++++
    +
    +                  SNDU                       End      Stuffing
    +                 Length                   Indicator     bytes
    +    -+------+------+------+  -+------+------+------+- -+------+
    + ... | B59  | 0x00 | 0x38 |...| C59  | 0xFF | 0xFF |...| 0xFF |
    +    -+------+-+----+------+  -+------+-+----+------+- -+------+
    +              +  +      +              +
    +              +  ++++++++              +
    +              +   +                    +
    ++++++++++++++++   ++++++++++++++++++++++

   *** TS Packet Payload Pointer (PP)
   +++ ULE Length Indicator






















Expires December 2004                                        [page 39]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   Example A.5: Three 44B PDUs.

     SNDU A is 52 bytes (no destination MAC address)
     SNDU B is 52 bytes (no destination MAC address)
     SNDU C is 52 bytes (no destination MAC address)

   The sequence comprises 1 TS Packet:

                      SNDU
           PP=0      Length
   +-----+------+------+------+-   -+-----+------+-----+-   -+-----+-
   | HDR | 0x00 | 0x80 | 0x34 | ... | A51 |0x80 | 0x34 | ... | B51 | ..
   +-----+----*-+-*----+------+-   -+-----+-*----+-----+-   -+-----+-
   PUSI=1     *   *
              *****


                                           End        Stuffing
                                         Indicator     bytes
                -----+------+-   -+-----+---------+- -+------+
            ... 0x80 | 0x34 | ... | C51 |0xFF|0xFF|   | 0xFF |
                -*---+------+-   -+-----+---------+- -+------+







































Expires December 2004                                        [page 40]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004


   ANNEXE B: Informative Appendix - SNDU Encapsulation

   An example of ULE encapsulation carrying an ICMPv6 packet generated
   by ping6.

   ULE SNDU Length  :            63 decimal
   D-bit value  :                0 (NPA Present)
   ULE Protocol Type :           0x86dd (IPv6)
   Destination ULE NPA Address:  01:02:03:04:05:06
   ULE CRC32 :                   0x784679a5

   Source IPv6:                  2001:660:3008:1789::5
   Destination IPv6:             2001:660:3008:1789::6

   SNDU contents (including CRC-32):

   0000:  00 3f 86 dd 01 02 03 04 05 06 60 00 00 00 00 0d
   0010:  3a 40 20 01 06 60 30 08 17 89 00 00 00 00 00 00
   0020:  00 05 20 01 06 60 30 08 17 89 00 00 00 00 00 00
   0030:  00 06 80 00 9d 8c 06 38 00 04 00 00 00 00 00 78
   0040:  46 79 a5


   >>>> Author Note : This packet is not a valid IPv6 packet since it
   has a unicast L3 IP address and a multicast L2 MAC address. A new
   packet decode is required. <<<



































Expires December 2004                                        [page 41]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     October 2004































































Expires December 2004                                        [page 42]


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