doc: Add RFC documents

1 files changed, 2355 insertions, 0 deletions

diff --git a/doc/rfc/rfc4326.txt b/doc/rfc/rfc4326.txt
new file mode 100644
index 0000000..d9e01c3
--- /dev/null
+++ b/doc/rfc/rfc4326.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group                                       G. Fairhurst
+Request for Comments: 4326                        University of Aberdeen
+Category: Standards Track                              B. Collini-Nocker
+                                                  University of Salzburg
+                                                           December 2005
+
+
+           Unidirectional Lightweight Encapsulation (ULE) for
+   Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The MPEG-2 Transport Stream (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 a Unidirectional Lightweight Encapsulation
+   (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and
+   other network protocol packets directly over the ISO MPEG-2 Transport
+   Stream as TS Private Data.  ULE specifies a base encapsulation format
+   and supports an extension format that allows it to carry additional
+   header information to assist in network/Receiver processing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                     [Page 1]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Conventions Used in This Document ...............................4
+   3. Description of the Method .......................................8
+   4. SNDU Format .....................................................9
+      4.1. Destination Address Absent (D) Field ......................10
+      4.2. Length Field ..............................................10
+      4.3. End Indicator .............................................10
+      4.4. Type Field ................................................10
+           4.4.1. Type 1: Next-Header Type Fields ....................11
+           4.4.2. Type 2: EtherType Compatible Type Fields ...........11
+      4.5. SNDU Destination Address Field ............................12
+      4.6. SNDU Trailer CRC ..........................................12
+      4.7. Description of SNDU Formats ...............................13
+           4.7.1. End Indicator ......................................14
+           4.7.2. IPv4 SNDU Encapsulation ............................14
+           4.7.3. IPv6 SNDU Encapsulation ............................15
+   5. Extension Headers ..............................................16
+      5.1. Test SNDU .................................................18
+      5.2. Bridged Frame SNDU Encapsulation ..........................18
+      5.3. Extension-Padding Optional Extension Header ...............21
+   6. Processing at the Encapsulator .................................22
+      6.1. SNDU Encapsulation ........................................22
+      6.2. Procedure for Padding and Packing .........................24
+   7. Receiver Processing ............................................25
+      7.1. Idle State ................................................26
+           7.1.1. Idle State Payload Pointer Checking ................26
+      7.2. Processing of a Received SNDU .............................26
+           7.2.1. Reassembly Payload Pointer Checking ................28
+      7.3. Other Error Conditions ....................................28
+   8. Summary ........................................................29
+   9. Acknowledgements ...............................................29
+   10. Security Considerations .......................................29
+   11. IANA Considerations ...........................................30
+      11.1. IANA Guidelines ..........................................30
+   12. References ....................................................31
+      12.1. Normative References .....................................31
+      12.2. Informative References ...................................32
+   Appendix A. SNDU Packing Examples .................................35
+   Appendix B. SNDU Encapsulation ....................................40
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                     [Page 2]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+1.  Introduction
+
+   This document describes an encapsulation for the transport of IP
+   datagrams, or other network-layer packets, over ISO MPEG-2 Transport
+   Streams [ISO-MPEG2, RFC4259].  The encapsulation satisfies the
+   requirement for a lightweight encapsulation defined in section 4 of
+   [RFC4259].  The basic header provides the required set of protocol
+   fields.  Extension headers may also be defined.  This header
+   structure is significantly simpler to parse and process [SOOR05] than
+   current alternative methods (e.g., MPE [ETSI-DAT], which builds upon
+   the DSM-CC Table Section syntax [ISO-DSMCC]).
+
+   The encapsulation 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], and 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), such as Ethernet Frames, IP datagrams, or
+   other network-layer packets, used 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 one or more MPEG-2 Transport Stream (TS) Packets that are
+   sent over a single TS Logical Channel.
+
+   The MPEG-2 specification [ISO-MPEG2] requires that conformant TS
+   Multiplexes provide Program Specific Information (PSI) for each
+   stream in the TS Multiplex.  Other MPEG-2-based transmission
+   standards may also define Service Information (SI).
+
+   A format_identifier value has been registered for ULE [ULE1].  This
+   32 bit number has a hexadecimal value of 0x554C4531.  Transport
+   Streams that utilise the Programme Map Table (PMT) defined in ISO
+   13818-1 [ISO-MPEG2] and that use the ULE format defined in this
+   document, SHOULD insert a descriptor with this value in the PMT
+   ES_info descriptor loop.  ULE Streams may also be identified by the
+   stream_type value of 0x91 [ATSC-REG] in a SI/PSI Table [ISO_MPEG2].
+
+   This information may allow Receivers and Re-multiplexors [RFC4259] to
+   locate a specific ULE Stream (i.e., the PID value of the TS Logical
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                     [Page 3]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   Channel that carries a ULE Stream).  The conditions under which this
+   information is required and the format in which it is to be provided
+   are beyond the scope of this document.  Addressing and mapping issues
+   for ULE over MPEG-2 are also described in [IPDVB-AR].
+
+2.  Conventions Used in This Document
+
+   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   Other terms used in this document are defined below:
+
+   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-MPEG2].
+
+   AFC: Adaptation Field Control [ISO-MPEG2].  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.
+
+   b: bit.  For example, one byte consists of 8b.
+
+   B: Byte.  Groups of bytes are represented in Internet byte order.
+
+   DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC].  A
+   format for transmission of data and control information in an MPEG-2
+   Private Section, defined by the ISO MPEG-2 standard.
+
+   DVB: Digital Video Broadcast.  A framework and set of associated
+   standards published by the European Telecommunications Standards
+   Institute (ETSI) (e.g., [ETSI-DVBC, ETSI-DVBS, ETSI-DVBT]) for the
+   transmission of video, audio, and data using the ISO MPEG-2 Standard
+   [ISO-MPEG2].
+
+   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 value that indicates to the Receiver that there are
+   no further SNDUs present within the current TS Packet.
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                     [Page 4]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   LLC: Logical Link Control [ISO-8802-2, IEEE-802.2].  A link-layer
+   protocol defined by the IEEE 802 standard, which follows the Ethernet
+   MAC Header.
+
+   MAC: Medium Access Control [IEEE-802.3].  A link-layer protocol
+   defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).
+
+   MAC Header: The link-layer header of the IEEE 802.3 standard
+   [IEEE-802.3] or Ethernet v2 [DIX].  It consists of a 6B destination
+   address, 6B source address, and 2B Type field (see also NPA, LLC).
+
+   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/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222
+   [ITU-H222]).
+
+   Next-Header: A Type value indicating an Extension Header.
+
+   NPA: Network Point of Attachment.  In this document, refers to a
+   6-byte destination address (resembling an IEEE MAC address) within
+   the MPEG-2 transmission network that is used to identify individual
+   Receivers or groups of Receivers.
+
+   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.
+
+   Padding: A method that fills the remaining unused bytes in a TS
+   Packet payload using the specific pattern of 0xFF.
+
+   Payload Unit, PU.  A sequence of bytes sent using a TS.  Examples of
+   Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
+
+   PDU: Protocol Data Unit.  Examples of a PDU include Ethernet frames,
+   IPv4 or IPv6 datagrams, and other network packets.
+
+   PES: Packetized Elementary Steam [ISO-MPEG2].  A format of MPEG-2 TS
+   packet payload usually used for video or audio information.
+
+   PID: Packet Identifier  [ISO-MPEG2].  A 13-bit field carried in the
+   header of TS Packets.  This is used to identify the TS Logical
+   Channel to which a TS Packet belongs [ISO-MPEG2].  The TS Packets
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                     [Page 5]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   forming the parts of a Table Section, PES, or other Payload Unit must
+   all carry the same PID value.  The all-zeros PID 0x0000 as well as
+   other PID values are reserved for specific PSI/SI Tables [ISO-MPEG2].
+   The all-ones PID value 0x1FFF indicates a Null TS Packet introduced
+   to maintain a constant bit rate of a TS Multiplex.  There is no
+   required relationship between the PID values used for TS Logical
+   Channels transmitted using different TS Multiplexes.
+
+   PP: Payload Pointer [ISO-MPEG2].  An optional one-byte pointer that
+   directly follows the 4-byte TS Packet header.  It contains the number
+   of bytes that follow the Payload Pointer, up to the start of the
+   first Payload Unit (counted from the first byte of the TS Packet
+   payload field, and excluding the PP field itself).  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, Table
+   Sections, and ULE.  It is not present in TS Logical Channels that use
+   the PES-format.
+
+   Private Section: A syntactic structure constructed in accordance with
+   Table 2-30 of [ISO-MPEG2].  The structure may be used to identify
+   private information (i.e., not defined by [ISO-MPEG2]) relating to
+   one or more elementary streams, or a specific MPEG-2 program, or the
+   entire Transport Stream.  Other Standards bodies, e.g., ETSI, ATSC,
+   have defined sets of table structures using the private_section
+   structure.  A Private Section is transmitted as a sequence of TS
+   Packets using a TS Logical Channel.  A TS Logical Channel may carry
+   sections from more than one set of tables.
+
+   PSI: Program Specific Information [ISO-MPEG2].  Tables used to convey
+   information about the service carried in a TS Multiplex.  The
+   information is carried in one of four specifically identified Table
+   Sections defined by MPEG-2 [ISO-MPEG2].  See also SI Table.
+
+   PU: Payload Unit.
+
+   PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2].  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).
+
+   Receiver: Equipment that processes the signal from a TS Multiplex and
+   performs filtering and forwarding of encapsulated PDUs to the
+   network-layer service (or bridging module when operating at the link
+   layer).
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                     [Page 6]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   SI Table: Service Information Table [ISO-MPEG2].  In this document,
+   this term describes a table that is defined by another standards body
+   to convey information about the services carried in a TS Multiplex.
+   A Table may consist of one or more Table Sections; however, all
+   sections of a particular SI Table must be carried over a single TS
+   Logical Channel [ISO-MPEG2].
+
+   SNDU: SubNetwork Data Unit.  An encapsulated PDU sent as an MPEG-2
+   Payload Unit.
+
+   Table Section: A Payload Unit carrying all or part of an SI or PSI
+   Table [ISO-MPEG2].
+
+   TS: Transport Stream [ISO-MPEG2], a method of transmission at the
+   MPEG-2 level using TS Packets; it represents layer 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 [ISO-MPEG2].  Each 188B
+   TS Packet incorporates 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 to 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)
+
+   If the PUSI bit is set to a value of 1, there is one
+   additional field following the TS packet header:
+
+        *8b             Payload Pointer (PP)
+
+   TS Logical Channel: Transport Stream Logical Channel.  In this
+   document, this term identifies a channel at the MPEG-2 level
+   [ISO-MPEG2].  It exists at level 2 of the ISO/OSI reference model.
+   All packets sent over a TS Logical Channel carry the same PID value
+   (this value is unique within a specific TS Multiplex).  The term
+   "Stream" is defined in MPEG-2 [ISO-MPEG2] to describe the content
+   carried by a specific TS Logical Channel (see ULE Stream).  Some PID
+   values are reserved (by MPEG-2) for specific signalling.  Other
+   standards (e.g., ATSC, DVB) also reserve specific PID values.
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                     [Page 7]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   TS Multiplex: In this document, this term defines a set of MPEG-2 TS
+   Logical Channels sent over a single lower-layer connection.  This may
+   be a common physical link (i.e., a transmission at a specified symbol
+   rate, FEC setting, and transmission frequency) or an encapsulation
+   provided by another protocol layer (e.g., Ethernet, or RTP over IP).
+   The same TS Logical Channel may be repeated over more than one TS
+   Multiplex (possibly associated with a different PID value) [RFC4259];
+   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-MPEG2].  Each TS Packet carries a 4B header, plus optional
+   overhead including an Adaptation Field, encryption details, and time
+   stamp information to synchronise a set of related TS Logical
+   Channels.
+
+   ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE
+   encapsulated PDUs.  ULE Streams may be identified by definition of a
+   stream_type in SI/PSI [ISO-MPEG2].
+
+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 either by
+   being placed in the payload of a single TS Packet, or, if required,
+   by being 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 thereof), a practice sometimes known as
+   Packing.  All TS Packets comprising an 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.  A PUSI field with a value of 1 indicates the
+   start of at least one Payload Unit (SNDU) within the TS Packet
+   payload.  The semantics of the PUSI bit are defined for PES and PSI
+   packets [ISO-MPEG2]; for private data, its use is not defined in the
+   MPEG-2 Standard.  Although ULE uses 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 an SNDU, but
+        contains the continuation, or end, of an SNDU;
+
+        1: The TS Packet contains the start of an SNDU, and a one byte
+        Payload Pointer follows the last byte of the TS Packet header.
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                     [Page 8]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   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 (known as Padding) fills the remainder of the TS
+   Packet payload with bytes with a value 0xFF [ISO-MPEG2].
+
+   A Receiver processing MPEG-2 Table Sections that receives a value of
+   0xFF in the first byte of a Table Section (table_Id) interprets this
+   as Padding/Stuffing 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.  This adaptation field may extend the TS Packet Header
+   to carry timing and synchronisation information and may also be used
+   to include stuffing bytes before a TS Packet payload.  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'.  For TS Logical Channels supporting ULE, Receivers MUST discard
+   TS Packets that carry other AFC values.
+
+4.  SNDU Format
+
+   PDUs are encapsulated using ULE to form an SNDU.  (Each SNDU is an
+   MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs is
+   illustrated below:
+
+   < ----------------------------- SNDU ----------------------------- >
+   +-+-------------------------------------------------------+--------+
+   |D| Length | Type | Dest Address* |           PDU         | CRC-32 |
+   +-+-------------------------------------------------------+--------+
+
+       Figure 1: SNDU Encapsulation (* optional Destination Address)
+
+   All multi-byte values in ULE (including the Length/End Indicator
+   (4.2,4.3), Type (4.4), Destination Address (4.5), and Extension
+   Headers (5)) are transmitted in network byte order (most significant
+   byte first).  The most significant bit of each byte is placed in the
+   left-most position of the 8-bit field.  Appendix A provides
+   informative examples of usage.
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                     [Page 9]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+4.1.  Destination Address Absent (D) Field
+
+   The most significant bit of the Length field carries the value of the
+   Destination Address Absent 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.
+
+   An End Indicator (4.3) MUST be sent with a D-bit value of 1.  Other
+   SNDUs MAY be sent with a D-bit value of 0 or 1.  The default method
+   SHOULD use a D-bit value of 0 (see section 4.5).
+
+4.2.  Length Field
+
+   A 15-bit value that indicates the length, in bytes, of the SNDU
+   counted from the byte following the Type field of the SNDU base
+   header (figure 9) up to and including the CRC.  This Length includes
+   the size of any extension headers that may be present (section 5).
+   Note the special case described in section 4.3.
+
+4.3.  End Indicator
+
+   When the first two bytes following an SNDU have the value 0xFFFF,
+   this denotes an End Indicator (i.e., all ones length combined with a
+   D-bit value of 1).  This 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].
+
+4.4.  Type Field
+
+   The 16-bit Type field indicates the type of payload carried in an
+   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 Ethernet v2
+   Specification  [DIX].  After specification of IEEE 802.3 [IEEE-802.3,
+   ISO-8802-2], 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
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 10]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   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 5.2).
+
+   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
+   less than 1536 in decimal.  These Type field values are IANA assigned
+   (see section 4.4.1) and indicate the Next-Header.
+
+   The second set of ULE Type field values comprise the set of values
+   greater than or equal to 1536 in decimal.  In ULE, this 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-Header Type Fields
+
+   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 in this document:
+
+           0x0000: Test SNDU (see section 5.1)
+           0x0001: Bridged Frame (see section 5.2)
+           0x0100: Extension-Padding (see section 5.3)
+
+
+   The remaining values within the first part of the Type space are
+   reserved for Next-Header values allocated by the IANA.
+
+4.4.2.  Type 2: EtherType Compatible Type Fields
+
+   The second part of the Type space corresponds to the values between
+   0x600 (1536 decimal) and 0xFFFF.  This set of type assignments
+   follows DIX/IEEE assignments (but excludes use of this field as a
+   frame length indicator).  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 (see section 4.7.2)
+           0x86DD: IPv6 Payload (see section 4.7.3)
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 11]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+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, or a bridged MAC 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 an SNDU Destination
+   Address field (i.e., D=0), a Network Point of Attachment (NPA) field
+   directly follows the fourth byte of the SNDU header.  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 an 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 that this SNDU is to be delivered
+   to all Receivers.
+
+   IPv4 packets carrying an IPv4 subnetwork broadcast address need to be
+   delivered to all systems with the same network prefix.  When a SNDU
+   Destination Address is present (D=0), the value MUST be set to the
+   NPA link broadcast address (0xFF:FF:FF:FF:FF:FF).
+
+   When the PDU is an IP multicast packet and an SNDU Destination
+   Address is present (D=0), the IP group destination address of the
+   multicast packet MUST be mapped to the multicast SNDU Destination
+   Address (following the method used to generate a destination MAC
+   address in Ethernet).  The method for mapping IPv4 multicast
+   addresses is specified in [RFC1112].  The method for mapping IPv6
+   multicast addresses is specified in [RFC2464].
+
+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 [ITU-3563].  This is a 32-bit value calculated according to the
+   generator polynomial represented 0x104C11DB7 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.
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 12]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   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 from 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.  Appendix 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
+   Encapsulator 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).
+
+4.7.  Description of SNDU Formats
+
+   The format of an SNDU is determined by the combination of the
+   Destination Address Absent bit (D) and the SNDU Type field.  The
+   simplest encapsulation places a PDU directly into an SNDU payload.
+   Some Type 1 encapsulations may require additional header fields.
+   These are inserted in the SNDU following the NPA destination address
+   and directly preceding the PDU.
+
+   The following SNDU Formats are defined here:
+
+   End Indicator: The Receiver should enter the Idle State (4.7.1).
+   IPv4 SNDU: The payload is a complete IPv4 datagram (4.7.2).
+   IPv6 SNDU: The payload is a complete IPv6 datagram (4.7.3).
+   Test SNDU: The payload will be discarded by the Receiver (5.1).
+   Bridged SNDU: The payload carries a bridged MAC frame (5.2).
+
+   Other formats may be defined through relevant assignments in the IEEE
+   and IANA registries.
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 13]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+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           |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                                                               |
+      =   A sequence of zero or more bytes with a value 0xFF filling  =
+      |           the remainder of the TS Packet Payload              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 2: Format for a ULE End Indicator
+
+4.7.2.  IPv4 SNDU Encapsulation
+
+   IPv4 datagrams are directly 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 NPA Address  (6B)             |
+      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                                                               |
+      =                           IPv4 datagram                       =
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             (CRC-32)                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0)
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 14]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+       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)
+
+4.7.3.  IPv6 SNDU Encapsulation
+
+   IPv6 datagrams are directly 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 = 0x86DD         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            Receiver Destination NPA Address  (6B)             |
+      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                                                               |
+      =                           IPv6 datagram                       =
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             (CRC-32)                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 15]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+       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 = 0x86DD         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      =                           IPv6 datagram                       =
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             (CRC-32)                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1)
+
+5.  Extension Headers
+
+   This section describes an extension format for the ULE encapsulation.
+   In ULE, a Type field value less than 1536 decimal indicates an
+   Extension Header.  These values are assigned from a separate IANA
+   registry defined for ULE.
+
+   The use of a single Type/Next-Header field 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.
+
+   A ULE Extension Header is identified by a 16-bit value in the Type
+   field.  This field is organised as a 5-bit zero prefix, a 3-bit H-LEN
+   field, and an 8-bit H-Type field, as follows:
+
+           0                   1
+           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          |0 0 0 0 0|H-LEN|    H-Type     |
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 7: Structure of ULE Next-Header Field
+
+   The H-LEN Assignment is described below:
+
+   0    Indicates a Mandatory Extension Header
+   1    Indicates an Optional Extension Header of length 2B (Type only)
+   2    Indicates an Optional Extension Header of length 4B (Type + 2B)
+   3    Indicates an Optional Extension Header of length 6B (Type + 4B)
+   4    Indicates an Optional Extension Header of length 8B (Type + 6B)
+   5    Indicates an Optional Extension Header of length 10B (Type + 8B)
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 16]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   >=6  The combined H-LEN and H-TYPE values indicate the EtherType
+        of a PDU that directly follows this Type field.
+
+   The H-LEN value indicates the total number of bytes in an Optional
+   Extension Header (including the 2B Type field).
+
+   An H-LEN value of zero indicates a Mandatory Extension Header.  Each
+   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 a one-byte field that is either one of 256 Mandatory
+   Header Extensions or one of 256 Optional Header Extensions.  The set
+   of currently permitted values for both types of Extension Headers are
+   defined by an IANA Registry (section 15).  Registry values for
+   Optional Extensions are specified in the form H=1 (i.e., a decimal
+   number in the range 256-511), but may be used with an H-Length value
+   in the range 1-5 (see example in section 5.3).
+
+   Two examples of Extension Headers are the Test SNDU and the use of
+   Extension-Padding.  The Test SNDU Mandatory Extension Header results
+   in the entire PDU's being discarded.  The Extension-Padding Optional
+   Extension Header results in the following (if any) option header
+   being ignored (i.e., a total of H-LEN 16-bit words).
+
+   The general format for an SNDU with Extension Headers is:
+
+   < --------------------------   SNDU   ------------------------- >
+   +---+--------------------------------------------------+--------+
+   |D=0| Length | T1 | NPA Address | H1 | T2 |    PDU     | CRC-32 |
+   +---+--------------------------------------------------+--------+
+   < ULE base header >             <  ext 1  >
+
+   Figure 8: SNDU Encapsulation with one Extension Header (for D=0)
+
+   Where:
+   D  is the ULE D_bit (in this example D=0; however, NPA addresses may
+      also be omitted when using Extension Headers).
+   T1 is the base header Type field.  In this case, specifying a
+      Next-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, or an EtherType > 1535 B
+      indicating the type of the PDU being carried.
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 17]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   < --------------------------   SNDU   ------------------------- >
+   +---+---------------------------------------------------+--------+
+   |D=1| Length | T1 | H1 | T2 | H2 | T3 |       PDU       | CRC-32 |
+   +---+---------------------------------------------------+--------+
+   < ULE base header >< ext 1  >< ext 2  >
+
+   Figure 9: SNDU Encapsulation with two Extension Headers (D=1)
+
+   Using this method, several Extension Headers MAY be chained in
+   series.  Figure 12 shows an SNDU including two Extension Headers.  In
+   the example, the values of T1 and T2 are both less than 1536 decimal.
+   Each indicates the presence of an Extension 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 of extensions.
+
+5.1.  Test SNDU
+
+   A Test SNDU (Figure 10) is a Mandatory Extension Header of Type 1.
+   This header must be the final (or only) extension header specified in
+   the header chain of an SNDU.  The structure of the Data portion of
+   this SNDU is not defined by this document.  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 10: SNDU Format for a Test SNDU
+
+5.2.  Bridged Frame SNDU Encapsulation
+
+   A bridged SNDU is a Mandatory Extension Header of Type 1.  It MUST be
+   the final (or only) extension header specified in the header chain of
+   an SNDU.  The payload includes MAC address and EtherType [DIX] or LLC
+   Length [ISO-8802-2] fields together with the contents of a bridged
+   MAC frame.  The SNDU has the format shown in Figures 11 and 12.
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 18]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   When an NPA address is specified (D=0), Receivers MUST discard all
+   SNDUs that carry an NPA destination address that does NOT match their
+   own NPA address (or a broadcast/multicast 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.
+
+   An Encapsulator MAY also use this encapsulation format to directly
+   communicate network protocol packets that require the LLC
+   encapsulation [IEEE-802.2, ISO-8802-2].  To do this, it constructs an
+   SNDU with a Bridge Extension Header containing the intended
+   destination MAC address, the MAC source address of the Encapsulator,
+   and the LLC-Length.  The PDU comprises an LLC header followed by the
+   required payload.  The Encapsulator MAY choose to suppress the NPA
+   address (see 4.5).
+
+       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 NPA Address  (6B)             |
+      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                MAC Destination Address  (6B)                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    MAC Source Address  (6B)                   |
+      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |   EtherType/LLC-Length (2B)   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      =                 (Contents of bridged MAC frame)               =
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             (CRC-32)                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 11: SNDU Format for a Bridged Payload (D=0)
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 19]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+       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/LLC-Length (2B)   |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      |                                                               |
+      =                 (Contents of bridged MAC frame)               =
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             (CRC-32)                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure 12: SNDU Format for a Bridged Payload (D=1)
+
+   The EtherType/LLC-Length field of a frame is defined according to
+   IEEE 802.3 [IEEE-802.2] (see section 5).
+
+   In this special case, the Mandatory Extension Header format may be
+   interpreted as either an EtherType [DIX] or an LLC Length field,
+   specified by IEEE 802 [IEEE-802.3] rather than as a value assigned in
+   the ULE Next-Header Registry maintained by the IANA.
+
+   The MAC addresses in the frame being bridged SHOULD be assigned
+   according to the rules specified by the IEEE and 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 from the NPA addresses carried in
+   the SNDU header.
+
+   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 SHOULD be removed prior to forwarding.  This requires
+   the sender to be aware of such Ethernet padding (e.g., [DIX,
+   IEEE-802.3]).
+
+   Ethernet frames received at the Encapsulator for onward transmission
+   over ULE carry a Local Area Network Frame Check sequence (LAN FCS)
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 20]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   field (e.g., CRC-32 for Ethernet [DIX, IEEE-802.3]).  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.
+
+   This design is readily implemented using existing network interface
+   cards and does not introduce an efficiency cost by
+   calculating/verifying 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).
+
+5.3.  Extension-Padding Optional Extension Header
+
+   The Extension-Padding Optional Extension Header is specified by an
+   IANA-assigned H-Type value of 0x100.  As in other Optional
+   Extensions, the total length of the extension is indicated by the
+   H-LEN field (specified in 16-bit words).  The extension field is
+   formed of a group of one to five 16-bit fields.
+
+   For this specific option, only the last 16-bit word has an assigned
+   value; the sender SHOULD set the remaining values to 0x0000.  The
+   last 16-bit field forms the Next-Header Type field.  A Receiver MUST
+   interpret the Type field, but MUST ignore any other fields of this
+   Extension Header.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 21]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+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 13).
+   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
+   [RFC4259].
+
+                +------+--------------------------------+------+
+                | 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 an 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 an 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 that the SNDU starts immediately
+   after the Payload Pointer in 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-MPEG2].  This value MUST be incremented by one (modulo 16) for
+   each successive TS Packet containing a fragment/complete SNDU sent
+   using the same TS Logical Channel.
+
+   An Encapsulator MAY decide not to send another SNDU immediately, even
+   if space is available in a partially filled TS Packet.  This
+   procedure is known as Padding (Figure 14).  The End Indicator 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.
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 22]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+                 +-/------------+
+                 |  SubNetwork  |
+                 |     DU 1     |
+                 +-/------------+
+                        \        \
+                         \        \
+                          \        \
+                 +--------+--------+--------+----------+
+                 |MPEG-2TS| End of | 0xFFFF |  Unused  |
+                 | Header | SNDU 1 |        |  Bytes   |
+                 +--------+--------+--------+----------+
+                   PUSI=0            ULE
+                                     End
+                                     Indicator
+
+   Figure 14: A TS Packet carrying the end of SNDU 1, 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 2        |       |      DU 3        |
+              +-/----------------+       +----------------/-+
+                         \        \     /          /\
+                          \        \   /          /  \
+                           \        \ /          /    \. . .
+          +--------+--------+--------+----------+
+          |MPEG-2TS| Payload| end of | start of |
+          | Header | Pointer| SNDU 2 | SNDU 3   |
+          +--------+--------+--------+----------+
+            PUSI=1     |              ^
+                       |              |
+                       +--------------+
+
+   Figure 15: A TS Packet with the end of SNDU 2, followed by SNDU 3
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 23]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+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 [ISO-MPEG2] require that the
+   header of this new TS Packet carry a PUSI value of 1 followed by a
+   Payload Pointer value of 0x00.)
+
+   (ii) If the TS Packet carrying the final part of an 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 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 followed by a Payload
+   Pointer value of 0x00.)
+
+   (iii) If the TS Packet carrying the final part of an SNDU has exactly
+   two bytes of unused payload, and the PUSI was NOT already set, the
+   Encapsulator MUST place the value 0xFFFF in these 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 followed by 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
+   then start transmission of the next SNDU in a new TS Packet.  (The
+   standard rules [ISO-MPEG2] require that the header of this new TS
+   Packet carry a PUSI value of 1 and a Payload Pointer value of 0x00.)
+
+   (v) If at least two bytes are available for SNDU 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.  When the
+   Encapsulator packs further SNDUs into a TS Packet where the PUSI has
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 24]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   NOT already been set, the PUSI MUST be updated (set to 1), and an
+   8-bit Payload Pointer MUST be inserted in the first byte directly
+   following the TS Packet header.  (This reduces the size of the TS
+   Packet payload field that is available for data by one byte.)  The
+   value of the Payload Pointer 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 an 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 carrying a ULE Stream 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
+   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).
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 25]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+7.1.  Idle State
+
+   After initialisation or 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,
+   upon which it then enters the Reassembly State.  Figure 16 outlines
+   these state transitions:
+
+                                +-------+
+                                | 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 0 and 181 are permitted, in which case the Receiver MUST
+   discard the number of bytes indicated by the Payload Pointer (counted
+   from the first byte of the TS Packet payload field, and excluding the
+   PP field itself), 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.
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 26]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   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 (see also 7.2.1).  When the Current SNDU length
+   equals the value of the Length field, the Receiver MUST calculate and
+   verify the CRC value (see 4.6).  SNDUs that contain an invalid CRC
+   value MUST be discarded.  Mismatch of the CRC is an error event and
+   SHOULD be recorded as a CRC error.  The underlying physical-layer
+   processing (e.g., forward error correction coding) often results in
+   patterns of errors, rather than single bit errors, so the Receiver
+   needs to be robust to arbitrary patterns of corruption to the TS
+   Packet and payload, including potential corruption of the PUSI, PP,
+   and SNDU Length fields.  Therefore, a Receiver SHOULD discard the
+   remaining TS Packet payload (if any) following a CRC mismatch and
+   return to the Idle State.
+
+   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 Extension Headers).  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 an SNDU type error.
+
+   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 whether 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.  (This is provided that the TS Packet has a
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 27]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   PUSI value of 1, see 7.2.1; otherwise, the Receiver has detected a
+   delimiting error and MUST discard all remaining bytes in the TS
+   Packet payload and transitions to the Idle State.)
+
+7.2.1.  Reassembly Payload Pointer Checking
+
+   A Receiver that has partially received an 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.
+
+7.3.  Other Error Conditions
+
+   The Receiver SHOULD check the MPEG-2 Transport Error Indicator
+   carried in the TS Packet header [ISO-MPEG2].  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-MPEG2].  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-MPEG2], 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.
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 28]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+8.  Summary
+
+   This document defines a Unidirectional Lightweight Encapsulation
+   (ULE) that performs 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 compatibility
+   with existing implementations.  In particular, Optional Extension
+   Headers may safely be ignored by Receivers that do not implement
+   them, or choose not to process them.
+
+9.  Acknowledgements
+
+   This document is based on a previous document 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; in particular, the many comments received from Art
+   Allison, Carstsen Borman, 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 existing 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 direct encapsulation of
+   IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 29]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   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 an SNDU payload length error SHOULD be recorded.
+
+   In the future, a ULE Mandatory Extension Header may be used to define
+   a method to perform link encryption of the SNDU payload.  This is as
+   an additional security mechanism to IP-, transport-, or application-
+   layer security, not a replacement [RFC4259].  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.
+
+   Additional security control fields may be provided as part of this
+   link encryption 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 or
+   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 are the definition of the SA format and that of the related
+   encryption keys.
+
+11.  IANA Considerations
+
+   The IANA has created the ULE Next-Header Type field registry as
+   defined in this document.
+
+   ULE Next-Header registry
+
+      This registry allocates Next-Header values within the range 0-511
+      (decimal).  For each allocated value, it also specifies the set of
+      allowed H-LEN values (see section 5).  In combination, these
+      define a set of allowed values in the range 0-1535 for the first
+      part of the ULE Type space (see section 4.4.1).
+
+11.1.  IANA Guidelines
+
+   The following contains the IANA guidelines for management of the ULE
+   Next-Header registry.  This registry allocates values 0-511 decimal
+   (0x0000-0x01FF, hexadecimal).  It MUST NOT allocate values greater
+   than 0x01FF (decimal).
+
+   It subdivides the Next-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 expert review leading to prior issue of an IETF RFC.
+      This specification MUST define the value and the name associated
+      with the Extension Header, together with the procedure for
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 30]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+      processing the Extension Header.  It MUST also define the need for
+      the Mandatory Extension and the intended use.  The size of the
+      Extension Header MUST be specified.
+
+      Assignments have been made in this document, and registered by
+      IANA:
+
+      Type      Name                             Reference
+
+      0:       Test-SNDU                        Section 5.1
+      1:       Bridged-SNDU                     Section 5.2
+
+   2) 256-511 (decimal) IANA-assigned values, indicating Optional
+      Extension Headers for ULE, requiring expert review leading to
+      prior issue of an IETF RFC.  This specification MUST define the
+      value and the name associated with the Extension Header, together
+      with the procedure for processing the Extension Header.  The entry
+      MUST specify the range of allowable H-LEN values that are
+      permitted (in the range 1-5).  It MUST also define the need for
+      the Optional Extension and the intended use.
+
+      Assignments have been made in this document, and registered by
+      IANA:
+
+      Type      Name                    H-LEN   Reference
+
+      256:      Extension-Padding       1-5     Section 5.3
+
+12. References
+
+12.1.  Normative References
+
+   [ISO-MPEG2]    IS 13818-1, "Information technology -- Generic coding
+                  of moving pictures and associated audio information --
+                  Part 1: Systems", International Standards Organisation
+                  (ISO), 2000.
+
+   [RFC2119]      Bradner, S., "Key Words for Use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, 1997.
+
+   [RFC1112]      Deering, S., "Host extensions for IP multicasting",
+                  STD 5, RFC 1112, August 1989.
+
+   [RFC2464]      Crawford, M., "Transmission of IPv6 Packets over
+                  Ethernet Networks", RFC 2464, December 1998.
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 31]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   [ULE1]         Registration for format_identifier ULE1, SMPTE
+                  Registration Authority, LLC,
+                  http://www.smpte-ra.org/ule1.html.
+
+12.2.  Informative References
+
+   [IPDVB-AR]     Fairhurst, G. and M-J. Montpetit, "Address Resolution
+                  for IP datagrams over MPEG-2 Networks", Work in
+                  Progress, September 2005.
+
+   [ATSC]         A/53, "ATSC Digital Television Standard", Advanced
+                  Television Systems Committee (ATSC), Doc. A/53 Rev.C,
+                  2004
+
+   [ATSC-DAT]     A/90, "ATSC Data Broadcast Standard", Advanced
+                  Television Systems Committee (ATSC), Doc. A/090, 2000.
+
+   [ATSC-DATG]    A/91, "Recommended Practice: Implementation Guidelines
+                  for the ATSC Data Broadcast Standard", Advanced
+                  Television Systems Committee (ATSC), Doc. A/91, 2001.
+
+   [ATSC-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/65B, "Program and System Information Protocol for
+                  Terrestrial Broadcast and Cable", Advanced Television
+                  Systems Committee (ATSC), Doc. A/65B, 2003.
+
+   [ATSC-REG]     ATSC "Code Point Registry"
+                  www.atsc.org/standards/Code_Point_Registry.pdf.
+
+   [ATSC-S]       A/80, "Modulation and Coding Requirements for Digital
+                  TV (DTV) Applications over Satellite", Advanced
+                  Television Systems Committee (ATSC), Doc. A/80, 1999.
+
+   [DIX]          Digital Equipment Corp, Intel Corp, Xerox Corp,
+                  "Ethernet Local Area Network Specification" Version
+                  2.0, November 1982.
+
+   [ETSI-DAT]     EN 301 192, "Specifications for Data Broadcasting",
+                  European Telecommunications Standards Institute
+                  (ETSI), 2004.
+
+   [ETSI-DVBC]    EN 300 800, "Digital Video Broadcasting (DVB); DVB
+                  interaction channel for Cable TV distribution systems
+                  (CATV)", European Telecommunications Standards
+                  Institute (ETSI), 1998.
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 32]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   [ETSI-DVBS]    EN 300 421, "Digital Video Broadcasting (DVB);
+                  Modulation and Coding for DBS satellite systems at
+                  11/12 GHz", European Telecommunications Standards
+                  Institute (ETSI), 1997.
+
+   [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), 2004.
+
+   [ETSI-RCS]     ETSI 301 790, "Digital Video Broadcasting (DVB);
+                  Interaction Channel for Satellite Distribution
+                  Systems", European Telecommunications Standards
+                  Institute (ETSI), 2005.
+
+   [IEEE-802.2]   IEEE 802.2, "Local and metropolitan area networks-
+                  Specific requirements Part 2: Logical Link Control",
+                  IEEE Computer Society, (also ISO/IEC 8802-2), 1998.
+
+   [IEEE-802.3]   IEEE 802.3, "Local and metropolitan area networks-
+                  Specific requirements Part 3: Carrier sense multiple
+                  access with collision detection (CSMA/CD) access
+                  method and physical layer specifications", IEEE
+                  Computer Society, (also ISO/IEC 8802-3), 2002.
+
+   [ISO-DSMCC]    IS 13818-6, "Information technology -- Generic coding
+                  of moving pictures and associated audio information --
+                  Part 6: Extensions for DSM-CC", International
+                  Standards Organisation (ISO), 1998.
+
+   [ITU-H222]     H.222.0, "Information technology - Generic coding of
+                  moving pictures and associated audio information:
+                  Systems", International Telecommunication Union,
+                  (ITU-T), 1995.
+
+   [ITU-3563]     I.363.5, "B-ISDN ATM Adaptation Layer specification:
+                  Type 5 AAL", International Telecommunication Union,
+                  (ITU-T), 1996.
+
+   [ISO-8802-2]   ISO/IEC 8802.2, "Logical Link Control", International
+                  Standards Organisation (ISO), 1998.
+
+   [RFC3077]      Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
+                  Y. Zhang, "A Link-Layer Tunneling Mechanism for
+                  Unidirectional Links", RFC 3077, March 2001.
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 33]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   [RFC3309]      Stone, J., Stewart, R., and D. Otis, "Stream Control
+                  Transmission Protocol (SCTP) Checksum Change", RFC
+                  3309, September 2002.
+
+   [RFC4259]      Montpetit, M.-J., Fairhurst, G., Clausen, H.,
+                  Collini-Nocker, B., and H. Linder, "A Framework for
+                  Transmission of IP Datagrams over MPEG-2 Networks",
+                  RFC 4259, November 2005.
+
+   [SOOR05]       M. Sooriyabandara, G. Fairhurst, A. Ang, B. Collini-
+                  Nocker, H. Linder, W. Stering  "A Lightweight
+                  Encapsulation Protocol for IP over MPEG-2 Networks:
+                  Design, Implementation and Analysis", Computer
+                  Networks 48 p5-19, 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 34]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+Appendix A: SNDU Packing Examples
+
+   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-MPEG2].  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 the ULE destination NPA address)
+     SNDU B is 200 bytes (including the ULE destination NPA 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
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 35]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   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 | 0xB3 | ... | A182 |
+    +-----+----*-+-*----+------+-   -+------+
+    PUSI=1     *   *
+               *****
+                       SNDU                  Unused
+            PP=0      Length       CRC for B  byte
+    +-----+------+------+------+-   -+------+------+
+    | HDR | 0x00 | 0x00 | 0xB2 | ... | B181 | 0xFF |
+    +-----+---*--+-*----+------+-   -+------+------+
+    PUSI=1    *    *
+              ******
+                       SNDU                       SNDU
+            PP=0      Length      CRC for C      Length
+    +-----+------+------+------+-   -+------+------+------+
+    | HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |
+    +-----+---*--+-*----+------+-   -+------+------+------+
+    PUSI=1    *    *
+              ******           Unused
+                                byte
+    +-----+------+-   -+------+------+
+    | HDR | D002 | ... | D184 | 0xFF |
+    +-----+------+-   -+------+------+
+     PUSI=0
+
+   Example A.3: Large SNDUs
+
+   SNDU A is 732 bytes
+   SNDU B is 284 bytes
+
+   The sequence comprises 6 TS Packets:
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 36]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+                       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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 37]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   Example A.4: Illustration of SNDU Length field
+
+     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
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 38]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+   Example A.5: Three 44B PDUs.
+
+     SNDU A is 52 bytes (no ULE destination NPA address) SNDU B is 52
+     bytes (no ULE destination NPA address) SNDU C is 52 bytes (no ULE
+     destination NPA address)
+
+   The sequence comprises 1 TS Packet:
+
+                      SNDU
+           PP=0      Length
+   +-----+------+------+------+-   -+-----+------+------+-   -+-----+-
+   | HDR | 0x00 | 0x80 | 0x30 | ... | A51 | 0x80 | 0x30 | ... | B51 | ..
+   +-----+----*-+-*----+------+-   -+-----+------+------+-   -+-----+-
+   PUSI=1     *   *
+              *****
+
+                                           End        Stuffing
+                                         Indicator     bytes
+                -----+------+-   -+-----+---------+- -+------+
+            ... 0x80 | 0x30 | ... | C51 |0xFF|0xFF|   | 0xFF |
+                -----+------+-   -+-----+---------+- -+------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 39]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+Appendix B: SNDU Encapsulation
+
+   An example of ULE encapsulation carrying an ICMPv6 packet generated
+   by ping6.
+
+   ULE SNDU Length  :            63 decimal
+   D-bit value  :                0 (NPA destination address present)
+   ULE Protocol Type :           0x86dd (IPv6)
+   Destination ULE NPA Address : 00:01:02:03:04:05
+   ULE CRC32 :                   0x7c171763
+
+   Source IPv6 :                 2001:DB8:3008:1965::1
+   Destination IPv6 :            2001:DB8:2509:1962::2
+
+   SNDU contents (including CRC-32):
+
+   0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d
+   0016: 3a 40 20 01 0d b8 30 08 19 65 00 00 00 00 00 00
+   0032: 00 01 20 01 0d b8 25 09 19 62 00 00 00 00 00 00
+   0048: 00 02 80 00 9d 8c 06 38 00 04 00 00 00 00 00 7c
+   0064: 17 17 63
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 40]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+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.scicomp.sbg.ac.at/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 41]
+
+RFC 4326              ULE for IP over MPEG-2/DVB           December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Fairhurst & Collini-Nocker  Standards Track                    [Page 42]
+