Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen
Document: draft-fairhurst-ipdvb-s2-gule-04.txt
Category: Draft January 2006
An Encapsulation for Transmission of
IP Datagrams over a DVB-S2 Generic Stream (GULE)
Status of this Draft
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a Generic stream Unidirectional Lightweight
Encapsulation (GULE) mechanism for the transport of IPv4 and IPv6
Datagrams and other network protocol packets directly over the DVB
S2 Generic Stream. This specifies a base encapsulation format and
supports an extension format that allows it to carry additional
header information to assist in network/Receiver processing.
Internet-Drafts can be and are used to describe technical issues and
protocols that are of interest to the Internet community but that
are not finally standardised within the IETF. This is such a
document. It is intended for open discussion, but there is no
current plan to publish this as an Internet RFC.
Expires June 2006 [page 1]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
Table of Contents
1. Introduction
1.1 SNDU and PDU Processing
1.2 Fragmentation Considerations
2. Conventions used in this document
3. Description of method
3.1 GULE Encapsulation Overhead
3.2 Placement of the Encapsulation Header within the BBHeader
3.3 BB Encapsulation Header within the BBFrame Payload
4. SNDU Format
4.1 Destination Address Absent (D) Field
4.2 Length Field
4.3 End Indicator
4.4 Type Field
4.4.1 Type 1: Next-Header Type Fields
4.4.2 Type 2: EtherType Compatible Type Fields
4.5 SNDU Destination Address Field
4.6 SNDU Trailer CRC
4.7 Description of SNDU Formats
4.7.1 End Indicator
4.7.2 IPv4 SNDU Encapsulation
4.7.3 IPv6 SNDU Encapsulation
5. Extension Headers
5.1 Test SNDU
5.2 Bridged Frame SNDU Encapsulation
5.3 Extension-Padding Optional Extension Header
5.4 MPEG-2 TS Extension
5.5 SNDU-Resume Extension
5.5.1 SNDU-Resume Extension fragment processing
5.5.2 SNDU-Resume Extension reassembly
5.6 SNDU-Suspend.
5.7 SNDU-Concat Extension
6.Processing at the Encapsulator
6.1 SNDU Encapsulation
6.2 Procedure for Padding and Packing
7. Receiver Processing
7.1 Idle State
7.1.1 Idle State Payload Pointer Checking
7.2 Processing of a Received SNDU
7.2.1 Reassembly Payload Pointer Checking
7.3 Other Error Conditions
8. Summary
9. IANA Considerations
Expires June 2006 [page 2]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
10. Acknowledgments
11. Security Considerations
12. References
12.1 Normative References
12.2 Informative References
13. Authors' Addresses
14. IPR Notices
14.1 Intellectual Property Statement
14.2 Disclaimer of Validity
15. Copyright Statement
15.1 Intellectual Property Statement
15.2 Disclaimer of Validity
Appendix A: Scenarios for Fragmentation
Appendix B
Expires June 2006 [page 3]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
1. Introduction
This document describes an encapsulation for transport of IP
datagrams, or other network layer packets, over a link using the
physical layer specified by DVB-S2 [ETSI-S2] in the Generic Mode
(also known as the Generic Stream (GS)). Protocol requirements are
defined in [S2-REQ], [S2-REQ-RCS], and [ID-S2-REQ]. Some recommended
evaluation criteria are defined in [S2-REQ] and [S2-EVAL].
The method also allows TS-Packets [ISO-MPEG] to be sent within GULE
SNDUs. This may be used to provide control information and/or
Program Specific Information (PSI) for a Multiplex.
Note: Internet-Drafts can be and are used to describe technical
issues and protocols that are of interest to the Internet community
but that are not finally standardised within the IETF. This is such
a document and is intended for open discussion.
1.1 SNDU and PDU Processing
Protocol Data Units, PDUs, (Ethernet Frames, IP datagrams or other
network layer packets) for transmission 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 [RFC4259]. The SNDU may be fragmented into a series of
fragments sent in one or more BaseBand (BB) frames that are sent
over the DVB S2 link.
Although this document defines a different framing method to ULE
[RFC4236], it maintains the same design philosophy as ULE for
construction of the SNDUs. The important characteristics of this
encapsulation are described in this subsection. This will allow
subsequent additions to ULE to also be supported within GULE. The
key features are that each SNDU has:
(i) D-bit
This permits both addressed and unaddressed SNDUs. The D=1 mode may
be used as an enhancement to link efficiency (e.g. where IP-based
address filtering is in use).
(ii) SNDU Length
This may be utilised in the SNDU framing, to skip unwanted SNDUs and
to validate wanted SNDUs.
(iii) SNDU Type/Extension field
The Type field uses an extension processing in place of flag-parsing
for options, providing a method for efficient option support. This
field also permits the use of any IEEE format frame, including those
that control L2 infrastructure (QoS, VLAN, Network Management, ST,
etc), bridging, and IETF-defined methods such as IPv4, IPv6, MPLS,
arp, etc. The final use of this field is as a discriminator for
IETF-defined encapsulation extensions. Currently envisaged
Expires June 2006 [page 4]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
extensions are (a) Security extensions providing functions such as:
encryption, identity hiding, and authentication methods; (b) Header
compression methods for various formats of payloads.
An important consideration is that the Length and Type fields
replicate information that may also be extracted from the network-
layer protocol information. There are various reasons for this
design:
(i) It is envisaged that SNDU parsing could be implemented in
hardware/firmware or could use specialised logic to assist in
parsing the SNDUs. In this case, access to the information may
be required at a low-level to assure rapid filtering or
unwanted packets and correct queuing of wanted packets.
Omitting the information requires additional processing for all
PDUs, irrespective of whether specific PDUs are forwarded to
the specific Receiver, incurring significant additional
computational cost.
(ii) Not all network-layer PDUs contain Type/Length information
(e.g. DIX-format packets). When present, the fields are located
at an offset from the start of each PDU (e.g. IPv4/IPv6). In
some cases, this also requires computation (e.g. header
skipping in IEEE/LLC).
(ii) Omitting the Type and Length field places a reliance of
the SNDU framing on the PDU formats that are supported. This
dependency will hinder evolution of the encapsulation for new
applications.
If transmission efficiency is an important consideration, the
duplicate protocol fields should be compressed at the PDU-level not
the SNDU-level. This approach ensures protocol-independent framing
of SNDUs; enable protocol-dependent compression (allowing the
context of a particular protocol associations to provide
sophisticated compression where needed); requires decompression only
of those PDUs to be forwarded; and finally allows the decompression
function to be off-loaded from the SNDU framing function (e.g. a
design that does this as part of the Internet driver interface,
rather than the device driver). The recommended approach is
therefore to define well-founded and robust methods that may be used
with both ULE and GULE.
1.2 Fragmentation Considerations
Three forms of fragmentation are provided in this encapsulation
method:
(i) The simplest (default) provides efficient fragmentation and
reassembly for consecutive fragmentation (adjacent BBFrames)
[S2-REQ]. This follows a procedure that resembles that used by
ULE [RFC4236], and common to other MPEG-2 TS formats [ISO-
Expires June 2006 [page 5]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
MPEG]. This mode requires each Receiver to maintain one buffer
for reassembly of the Current SNDU [ULE-RFC]. A constraint is
that a BBFrame may contain only the fragment of a single new
SNDU, which must be aligned to the end of the BBFrame.
(ii) The SNDU-Resume Extension Header defined in this document
provides a method for non-consecutive fragmentation with
multiplexing [S2-REQ] (i.e. where intervening BBFrames may be
sent using an arbitrary ModCod value). When used in the latter
way, an arbitrary large number of fragments may be resumed in
the same BBFrame (i.e. multiple fragment support [S2-REQ]). A
constraint is that a BBFrame may contain only the fragment of a
single new SNDU, which must be aligned to the end of the
BBFrame.
This method requires an additional protocol overhead within
each resumed fragment. To utilise this method, Receivers need
to maintain several buffers, up to one buffer for each MAC/NPA
address that they expect to receive, plus one for the case of
no specified MAC/NPA address (D=1). Receivers that allocate
fewer buffers, may not be able to buffer all fragmented SNDUs,
potentially resulting in some packet loss (depending on the
fragmentation policy of the Gateway). This document defines a
method to recover buffers that are occupied by incomplete
fragments after a specified interval.
(iii) The SNDU-Suspend Extension Header defined in this
document provides a method for non-consecutive fragmentation
with multiplexing [S2-REQ] that also supports an arbitrary
fragmentation of the first fragment of a new SNDU. This method
must be used in combination with the SNDU-Resume method and has
the same buffer management requirements as for the SNDU-Resume
method. Using this method, a BBFrame may contain any number of
fragments that start a new SNDU. New fragmented SNDUs do not
need to be aligned to the end of the BBFrame.
To utilise this method, a Receiver needs to be able to accept
an arbitrary large number of new fragmented new SNDUs within a
BBFrame. This may add complexity to the Receiver design, but
permits more flexibility in fragmentation by the Gateway.
These methods provide backwards compatibility: All Receivers MUST
implement method (i). If a Receiver does not also implement methods
(ii) and (iii), this Receiver will silently discard all PDUs sent
using the SNDU-Resume or SNDU-Suspend method. A Receiver that
implements the SNDU-Resume method may use method (i) and/or (ii),
but will silently discard all PDUs sent using the SNDU-Suspend
method (iii). A Receiver that implements the SNDU-Resume or SNDU-
Suspend method is able to receive and forward PDU encapsulated using
any/all of the three methods.
Expires June 2006 [page 6]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
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].
ACM: Adaptive Coding and Modulation (see ModCod).
b: bit. For example, one byte consists of 8b.
B: Byte. Groups of bytes are represented in Internet byte order.
BB: Baseband.
BBFrame payload [ETSI-S2]: The data field part of a Baseband frame
that may be used for the communication of data. Typical BBFrames
range in size from 3072 to 58192 bits according to the choice of
modulation format and FEC in use.
BBH, Baseband Header [ETSI-S2]: A fixed format 10 byte header that
starts each BBFrame.
Counter: An encapsulation protocol field located at a fixed position
in all BBFrames utilising the GULE encapsulation. The value is
incremented modulo 255 in each BBFrame sent with a specific ISI. It
is used to monitor in-sequence reception of BBFrames within a
Stream, and may be utilised for monitoring functions as a part of
link-layer Operations and Management (OAM). In addition, the value
is used to verify that BBFrames are consecutive within a Stream when
the PP value is used to reassemble frames.
DF: Data Field [ETSI-S2]. The BBFrame payload. Note this
abbreviation is also used for a different function at the IP layer.
DFL: Data Field Length [ETSI-S2]. The size of the BBFrame payload
measured in bits. A set of DFL values have been specified by S.2,
corresponding to the set of specified ModCod formats.
DVB: Digital Video Broadcast [ETSI-DVB]. A framework and set of
associated standards published by the European Telecommunications
Standards Institute (ETSI) for the transmission of video, audio, and
data.
Encapsulator: A network device that receives PDUs and formats these
into Payload Units (known here as SNDUs) for output in the Generic
Mode of DVB-S2.
End Indicator [RFC4236]: A value that indicates to the Receiver that
there are no further SNDUs present within the current BBFrame.
Encapsulation Header: The logical group of fields that carry the
protocol control information for the encapsulation protocol.
Expires June 2006 [page 7]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
GULE: Generic Stream ULE. The protocol defined in this document.
GS: Generic Stream.
ISI: Input Stream Identifier, the second byte of the header of a
BBFrame. This value uniquely identifies a specific logical channel
within a DVB-S2 multiplex.
MAC: Medium Access Control [IEEE-802.3]. A link layer protocol
defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).
ModCod: Modulation/Coding. A combination of Modulation and FEC
Coding that together determine the size of a BBFrame.
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards
Organisation (ISO/IEC 113818-1) [ISO-MPEG], and ITU-T (in H.220).
Next-Header: A Type value indicating an Extension Header [RFC4236].
NPA: Network Point of Attachment [RFC4236]. In this document, refers
to a destination address (resembling an IEEE MAC address) within the
DVB-S2 transmission network that is used to identify individual
Receivers or groups of Receivers.
OAM: Operations and Management.
Packing Threshold: In GULE, this is a period of time an Encapsulator
is willing to defer transmission of a partially filled BBFrame to
accumulate more SNDUs, rather than use Padding. After the Packet
Threshold period, the Encapsulator uses Padding to send the
partially filled BBFrame.
Padding: A sequence of bytes with the value 0xFF that are used after
an End Indicator to occupy the unused portion of a BBFrame payload.
The DFL field may also be used in place of Padding.
PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include
Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PP, Payload Pointer: In GULE, the PP is a 13-bit pointer located at
a fixed position in the encapsulation header of all BBFrames
utilising the GULE encapsulation. If the BBFrame contains the start
of a GULE SNDU, the PP value SHALL be set to the position of the
first byte of the first SNDU within the BBFrame. If the BBFrame
contains neither the start of a SNDU (or an End Indicator), the
value SHALL be assigned 0xFFFF.
PSI: Programme Specific Information [ISO-MPEG].
SI Table: Service Information Table [ISO-MPEG]. In this document,
this term describes a table that is been defined by another
Expires June 2006 [page 8]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
standards body to convey information about the services carried in a
SNDU: Subnetwork Data Unit [RFC4259]. In this document this is an
encapsulated PDU sent using GULE.
Stream: A logical flow from an Encapsulator to a set of Receivers.
The addresses at the MAC/NPA level and IP level need to be unique
within a specific stream (i.e. denoted by a common S.2 ISI value).
SYNCD: Synchronisation Distance [ETSI-S2]. This is specified for a
DVB-S2 packetized stream, where the distance in bits from the start
of the DataField to the first start of packet contained in this
DataField. This use resembles the MPEG-2 Payload Pointer, as
defined in ULE. The use of SYNCD is not specified for continuous
Generic Streams.
TS: Transport Stream [ISO-MPEG], a method of transmission at the
MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI
reference model.
ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4236]. A
scheme that encapsulates PDUs, into SNDUs that are sent in a series
of TS Packets using a single TS Logical Channel. The encapsulation
format defined by this document shares the same extension format,
and basic processing rules and uses a common IANA Registry.
Expires June 2006 [page 9]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
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)
[RFC4236] associated with a specific Stream at the link layer. The
SNDU is transmitted over an DVB-S2 link by placing it either in a
single BBFrame, or if required, an SNDU may be fragmented into a
series of BBFrames. A mode also permits an SNDU to be suspended and
resumed in a later BBFrame, while preserving the original order of
each SNDU sent to a specific MAC/NPA address over a Stream. Where
there is sufficient space, the method permits a BBFrame to carry
more than one SNDU (or part there of), sometimes known as Packing.
All parts comprising an SNDU MUST be assigned to the same Stream.
If a SNDU finishes before the end of a BBFrame, but it is not
intended to start another SNDU, a stuffing procedure fills the
remainder of the BBFrame payload with bytes with a value 0xFF, known
as Padding.
A Receiver that receives a value of 0xFF in place of the start of a
SNDU, interprets this as Padding/Stuffing and silently discards the
remainder of the BBFrame payload. The payload of the next BBFrame
for the same stream will begin with a Payload Pointer of value
0x0000, indicating that the next SNDU immediately follows the
encapsulation header. The ULE protocol [RFC4236] resembles this, but
differs in the procedure that binds it to the MPEG-2 TS physical
layer.
3.1 GULE Encapsulation Overhead
Each BBFrame includes a logical encapsulation header. This overhead
comprises a set of fixed format fields defined by GULE, shown in the
figure below.
< ------------------- BBFrame ------------------------------- >
+---------------------------- ----+---------------------------+
|Ver| Resv | Counter | Resv | PP | CRC-8 | BBFrame payload |
+---------------------------------+---------------------------+
< ----Encapsulation Overhead---- >
Figure 1: BBFrame Logical Encapsulation Overhead
The BBFrame encapsulation is identified by the 4-bit version field.
There are also a BBFrame counter (size to be determined), a 13-bit
Payload Pointer (aligned to an 8 byte boundary) and an 8-bit CRC-8.
All unused fields are reserved for future use. The BBFrame payload
is also known as the User Payload [ETSI-S2].
A CRC-8 provides an integrity check for the encapsulation overhead.
It also guards against framing misalignment that may otherwise
result following corruption of the PP value. The polynomial for
computation of the CRC-8 will be defined in this document.
Expires June 2006 [page 10]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
Field Size of Field Notes
----- ----------------------------- -----
- - Identifies the GULE format.
ver (4 bits + 4 reserved bits) *1
Counter(8 bits) For use in OAM *2
PP (13 bits) Measured in bytes.
(3 bits) Reserved for future use.
CRC CRC-8 Overhead integrity check.
Notes:
*1 Usage to be confirmed.
*2 Also used to verify that BBFrames are consecutive within a Stream
when the PP value is used to reassemble SNDUs.
Table 1: Encapsulation Overhead Protocol Fields
The specification described by this document does not define a
transmission format for the logical encapsulation header. The
approach recommended in this document is to include this
encapsulation overhead within the BBFrame Header itself (Section
3.2). An alternative is to prefix as a fixed-sized protocol header
within the BBFrame payload, placed following the BBFrame header
defined by DVB-S2 (Section 3.3).
3.2 Placement of the Encapsulation Header within the BBHeader
This section describes the physical placement of the extension
overhead fields within the header of a BBFrame [ID-S2-REQ], known as
the BaseBand Header (BBH) [ETSI-S2]. These fields are placed into
positions that are currently unused within the DVB S.2 BBH when
sending in the Generic Mode. This placement eliminates the need for
a separate Encapsulation header.
Field Corresponding BB Header Field Notes
----- ----------------------------- -----
MATYPE (2B) Identifies the GULE format.
ISI (1B subfield) Identifies the stream.
0000 User Payload Length, UPL (2B)*1 Identifies the GULE format.
Data Field Length, DFL (2B)*2 As used in S.2 TS.
ver Sync Pattern SYNCD (1B)*1
Counter For use in OAM.
PP Sync Distance SYNCD (2B)*1 Equivalent function.
CRC CRC-8 *2 Function already provided.
Notes:
*1 The usage of this BBH field is not specified in the DVB-S2
Specification for the Generic Mode [ID-S2-REQ].
*2 This BBH field is specified in the S.2 Specification and use in
the Generic Mode [ID-S2-REQ] is identical to use for Transport
Streams [ISO-MPEG].
Table 2: BBFrame Header Structure
Expires June 2006 [page 11]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
Usage of these fields (as in Table 2) within the BB header is
subject to clarification of acceptable usage for the Generic Mode
within the DVB-S2 Standard [ETSI-S2].
3.3 BB Encapsulation Header within the BBFrame Payload
This section describes an alternative method for communicating the
encapsulation protocol overhead, in the case where the fields in the
BBFrame header are not accessible to the GULE Gateway/Receiver.
The payload of each BBFrame starts with an encapsulation header
defined by GULE. The GULE encapsulation header is sent as the first
bytes of every BBFrame transmitetd by an encapsulation Gateway.
The BBFrame encapsulation header is of a fixed format. This
comprises an 8-bit BBFrame counter, a 16-bit Payload Pointer field
and an 8-bit CRC-8.
XXX Future revisions of this document may define additional fields
within this header to accelerate processing of the GULE Receiver.
XXX
The CRC-8 provides an integrity check for the entire GULE
encapsulation header, and guards against framing mis-alignment that
may otherwise result following corruption of the PP value. The
polynomial for computation of the CRC-8 is identical to that
specified for the BBHeader in [DVB-S2].
Expires June 2006 [page 12]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
4. SNDU Format
This section is Informative, the formats described in this section
are defined by ULE [RFC4236].
PDUs are encapsulated using ULE to form an SNDU. The encapsulation
format to be used for PDUs is illustrated below:
< ----------------------------- SNDU ----------------------------- >
+-+-----------------------------------------------------+----------+
|D| Length | Type | Dest Address* | PDU | CRC-32** |
+-+-----------------------------------------------------+----------+
Figure 2: SNDU Encapsulation (* optional Destination Address)
(** CRC-32 is optional for some formats of SNDU)
This format is identical that defined for ULE [RFC4236]. All multi-
byte values (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.
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 SHOULD be sent with a D-bit value of 0 (see 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, up to and including
the CRC (when present). Note the special case described in 4.3.
4.3 End Indicator
When the first two bytes of 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 BBFrame (see section 6),
and that no Destination Address Field is present.
Expires June 2006 [page 13]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
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.
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 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. The format is defined by
ULE and the ULE registry maintained 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
follow DIX/IEEE assignments (but exclude 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 4.7.2)
0x86DD: IPv6 Payload (see 4.7.3)
4.5 SNDU Destination Address Field
The SNDU Destination Address Field is optional (see 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.
Expires June 2006 [page 14]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
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 DVB-S2 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 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
A SNDU may 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.
The Encapsulator initialises the CRC-32 accumulator register to the
value 0xFFFF FFFF. It then accumulates a transmit value for the
CRC32 that includes all bytes from the start of the SNDU header to
the end of the SNDU (excluding the 32-bit trailer holding the CRC-
32), and places this in the CRC Field. In ULE, the bytes are
processed in order of increasing position within the SNDU, the order
of processing bits is NOT reversed. This use resembles, but is
different to that in SCTP [RFC3309].
When present, 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.
Expires June 2006 [page 15]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
This description may be suited for hardware implementation, but this
document does not imply any specific implementation. Software-based
table-lookup or hardware-assisted software-based implementations are
also possible. Annexe B provides an example of an Encapsulated PDU
that includes the computed CRC-32 value.
The 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 DVB-S2 subnetwork and during processing at the
encapsulation gateway and/or the Receiver. It serves to verify the
delineation (framing) of PDUs and 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). When a MAC?NPA
address is present, it binds the SNDU to the specified address.
The presence of a CRC field is determined by the format of the SNDU
(specified in the Type field of the Header). Formats by default
SHOULD include a CRC, exceptions include amn End Indicator, the
SNDU-Suspend and SNDU-Resume fragments.
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/MAC destination
address and directly preceding the PDU.
Formats may be defined through relevant assignments in the IEEE and
IANA registries.
4.7.1 End Indicator
The format of the End Indicator is defined by ULE [ULERFC]. It 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 BB frame payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format for a ULE End Indicator.
Expires June 2006 [page 16]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
4.7.2 IPv4 SNDU
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 formats are defined by ULE [ULERFC]. The two
encapsulations are shown in figures 4 and 5. (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 4: SNDU Format for an IPv4 Datagram using L2 filtering (D=0).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: 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, as defined by ULE [ULERFC]. The two encapsulations
are shown in figures 6 and 7.
Expires June 2006 [page 17]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
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 6: SNDU Format for an IPv6 Datagram using L2 filtering (D=0).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SNDU Format for an IPv6 Datagram using L3 filtering (D=1)
Expires June 2006 [page 18]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
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 [ELE-RFC].
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 8: Structure of ULE Next-Header Field [RFC4236].
The H-LEN value indicates the total number of bytes in an Optional
Extension Header (including the 2B Type field) [RFC4236].
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. This is
defined by ULE [RFC4236].
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 9: 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
Expires June 2006 [page 19]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
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.
< -------------------------- 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 [RFC4236]. 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 is a Mandatory Extension Header of Type 1, specified by
ULE [RFC4236].
5.2 Bridge Frame SNDU Encapsulation
A bridged SNDU is a Mandatory Extension Header of Type 1 specified
by ULE [RFC4236].
5.3 Extension-Padding Optional Extension Header
The Extension-Padding Optional Extension Header is s specified by
ULE [RFC4236].
Expires June 2006 [page 20]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
5.4 MPEG-2 TS Extension
The MPEG-2 TS Extension Header is specified by an IANA assigned H-
Type value of <tbd>. This is a Mandatory Extension. The extension
is used to communicate 1 or more MPEG-2 TS Packets over the DVB-S2
link when utilising the Generic Mode. The number of TS Packets
carried in a specific SNDU is determined from the size specified by
the remainder of the Payload following the MPEG-2 TS Extension. A
Receiver MUST silently discard any data, if present, between the
last complete encapsulated MPEG-2 TS Packet and the size denoted in
the Length field of the SNDU fragment base header.
A value of D=1 indicates there is no NPA/MAC address in use. A value
D=0 is also permitted, as defined in ULE.
The extension may be used to communicate one or more MPEG-2 TS
Packets of arbitrary content, interpreted according to [ISO-MPEG].
One expected use is for the transmission of MPEG-2 SI/PSI signalling
and clock references.
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 = 0xtbd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SNDU Format for a TS-Packet Payload (D=1)
5.5 SNDU-Resume Extension
The SNDU-Resume Extension is specified by an IANA assigned H-Type
value of <tbd>. This is a Mandatory Extension. The extension is
used to send the remainder of a suspended SNDU. It MAY be used at
any time by Gateway which has already sent the first part of a SNDU.
The payload of an SNDU-Resume Extension contains a Fragment of a
SNDU payload. The final fragment includes the SNDU CRC value
calculated over the entire (reassembled) SNDU. This CRC is used to
verify the integrity and reassembly of the complete PDU. It also
binds this to the MAC address for the case D=0.
Expires June 2006 [page 21]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
The Length field in an SNDU-Resume Extension fragment specifies the
size of the SNDU-Resume payload.
A Receiver that receives an SNDU-Resume fragment that it will not
process/forward MUST silently discard all bytes from the fragment,
it MUST NOT check the CRC value of the fragment, and proceeds with
processing of the next in-sequence SNDU.
An SNDU that carries an SNDU-Resume Extension fragment that contains
the final Fragment of a suspended SNDU carries the 4 byte CRC of the
complete SNDU (that would have been sent at the end of the of the
original SNDU, had the SNDU not been suspended). This CRC is follows
the SNDU payload and is included in the calculated Length of the
SNDU that carries this final Fragment (figure 11).
It is allowed to have a SNDU-Resume fragment with a Length less than
the total remaining bytes (see Appendix for an example), however
these fragments do NOT contain a CRC field.
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 = 0xtbd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Continuation of a previous SNDU Payload =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC of Complete reassembled SNDU * |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* If the SNDU-Resume fragment contains the final byte of a SNDU, the
CRC-32 of the original SNDU (prior to fragmentation) is appended to
the SNDU-Resume fragment to form the CRC field (and included in the
Length calculation). This is not the CRC of the fragment, but in
this case the CRC of the complete reassembled SNDU. If further SNDU-
Resume fragments would be required to complete the SNDU, the CRC
field is omitted.
Figure 11: SNDU Format for a SNDU-Resume Payload (D=1).
If the number of bytes to be sent in an SNDU-Resume Extension
fragment exceeds the unfilled space in the BBFrame payload, then the
Encapsulator SHOULD by default continue transmission in the next
BBFrame for the same stream. However, it MAY instead choose (e.g.
utilising a local policy with ACM coding to optimise overall
efficiency) to suspend the partially sent frame.
Expires June 2006 [page 22]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
5.5.1 SNDU-Resume Extension fragment processing
A receiver may receive a BBFrame containing zero or more SNDUs that
carry the SNDU-Resume Extension.
The Receiver SHOULD provisionally accept all SNDUs with a Length
that is greater than the number of bytes remaining in the BBFrame,
these are called Fragments. A Receiver MAY silently discard such
SNDUs to recover the space in previously allocated reassembly
buffers, or to limit processing, e.g. if it believes it is under a
DoS attack, the resources consumed exceed some threshold, or other
information indicates the frame has been corrupted by physical layer
errors. A receiver MUST also configure a Fragment-timeout. Fragments
that have been buffered for more than this predetermined period MUST
be discarded (this procedure MUST be invoked when an encapsulation
Gateway is restarted, and MAY be invoked via the control interface).
To reassemble the Fragments of a fragmented SNDU, a Receiver should
buffer up to one full-sized SNDU for each NPA/MAC filter for which
it expects to receive SNDUs. Reassembly is performed independently
for each Stream that the Receiver is configured to receive. A
Receiver may be configured to receive an arbitrary large number of
multicast NPA/MAC addresses over a single Stream. This is in
contrast to normal reassembly, where a Receiver needs to buffer at
most one SNDU per Stream.
The Receiver detects the presence of a Fragment, when the SNDU
Length is greater than the number of bytes remaining in a BBFrame,
and the next BBFrame for the same Stream had a PP value of zero.
The processing of fragments uses the following rules:
1) Under-sized SNDU
The Receiver receives a subsequent SNDU-Resume Extension
fragment with the same NPA/MAC address of a fragment that is
pending reassembly for the Stream, and which contains less than
the expected number of bytes required to complete the SNDU
payload (SNDU Length of original base header). The Fragments
SHOULD be added to the set of Fragments to be later
reassembled.
2) Correct-sized SNDU
The Receiver receives a subsequent SNDU-Resume Extension
fragment with a NPA/MAC address that matches a Fragment pending
reassembly for the Stream, and which contains the expected
number of bytes required to complete the SNDU payload. The
Fragments are then reassembled and the CRC-32 is validated. An
invalid CRC-32 MUST result in SNDU discard. The Receiver
continues processing the next SNDU in the BBFrame.
3) Over-Sized SNDU
The Receiver receives a subsequent SNDU-Resume Extension
Fragment that matches the NPA/MAC address of a Fragment pending
Expires June 2006 [page 23]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
reassembly for the Stream, and which contains more than the
expected number of bytes required to complete the SNDU payload.
This is a framing error. All Fragments for this combination of
Stream and NPA/MAC address MUST be discarded. The Receiver
continues processing the next SNDU in the BBFrame.
4) Unexpected Fragment
The Receiver receives a SNDU that is an SNDU-Resume Extension
Fragment, but for which it has no Fragments pending reassembly
with the same NPA/MAC address for the Stream. This is not a
framing error. All Fragments for this combination of Stream and
NPA/MAC address MUST be discarded and the Receiver will
continue processing of the next received SNDU.
5) Unexpected SNDU
The Receiver receives a SNDU that is not an SNDU-Resume
Extension fragment, but has the same NPA/MAC address of a
Fragment that is pending reassembly for the Stream. This is a
framing error. All Fragments for this combination of Stream and
NPA/MAC address MUST be discarded. The Receiver then continues
processing the next received SNDU.
6) Invalid Length
The Receiver receives a SNDU with an invalid Length of a
Fragment. The SNDU MUST be discarded, and the Receiver enters
the Idle state (see section 7).
7) Time-out
Within the period specified by the specified Fragment-timeout
(see section 7), the Receiver does not receive an SNDU with a
subsequent SNDU-Resume Extension for a NPA/MAC address for
which it has Fragments outstanding. This is a framing error.
All Fragments for this combination of Stream and NPA/MAC
address MUST be discarded. The Receiver continues processing
the next received SNDU.
8) Abort
The Receiver decides by other means that it will abort the
reassembly processing. This is a not framing error. All
Fragments for this combination of Stream and NPA/MAC address
will be discarded. The Receiver continues processing the next
received SNDU.
Expires June 2006 [page 24]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
5.5.1 SNDU-Resume Extension reassembly
No specific algorithm for reassembly processing is mandated in this
specification. Implementers may choose to reassemble SNDU Fragments
as they are received, or only when all fragments are received.
When a Receiver has accumulated a set of Fragments with the Length
specified in the SNDU in the base header of the first suspended
Fragment, it must validate the reassembly. The total accumulated
size of all SNDU fragments (including the SNDU CRC in the final
fragment) MUST exactly match this Length. SNDUs with an inconsistent
length MUST be discarded (a framing error may be recorded).
The Receiver MUST verify the SNDU CRC value carried in the final 4
bytes of the final fragment of a SNDU that it has reassembled. This
value is used to verify the integrity of the reassembled SNDU.
A Receiver MUST ignore the SNDU CRC value of an SNDU-Resume fragment
that is incomplete or has not been reassembled.
A successfully reassembled SNDU payload is processed according to
the Type field specified in the base header of the first suspended
Fragment (i.e. the start of the SNDU).
5.6 SNDU-Suspend Extension
The normal (continuous) method of transmission of a SNDU requires
that a SNDU can only be fragmented if it is positioned at the end of
a BBFrame. The sender can therefore only start one fragmented SNDU
in each BBFrame, while this bounds processing costs per BBFrame, it
can impose scheduler limitations.
Use of the method described in this section allows more scheduler
flexibility. A Gateway using this method MUST use the SNDU-Resume
method to transmit the remainder of the SNDU payload.
The SNDU-Suspend Extension is specified by an IANA assigned H-Type
value of <tbd>. This is a Mandatory Extension. It enables a sender
to start a SNDU at an arbitrary position within a BBFrame, and to
then suspend processing to allow the SNDU to be completed in a
subsequent BBFrame (or aborted). It MAY be used at any time by
Gateway that wishes to start a new SNDU.
The extension header specifies the number of bytes sent in the
current fragment (always less than the SNDU Length). The normal use
of this extension is to allow a Gateway to start more than one
different fragmented SNDU in the same BBFrame, in this case the
Suspended-Length will be less than the number of bytes remaining
within a BBFrame.
A value of D=1 indicates there is no NPA/MAC address in use. A value
D=0 is also permitted, as defined in ULE, and in this case a MAC/NPA
address is attached to the SNDU base header.
Expires June 2006 [page 25]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
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 = 0xtbd-Suspend |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Suspended-Length (15b) | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Start of a PDU =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SNDU Format for a SNDU-Suspend Payload (D=1)
5.7 SNDU-Concat Extension
The SNDU-Concat Extension is specified by an IANA assigned H-Type
value of <tbd>. This is a Mandatory Extension. It enables a
sequence of (usually short) PDUs to be sent within a single SNDU
payload. Each PDU is prefixed by its length in bytes. The Receiver
processes this type of SNDU by extracting each SNDU in turn. The
Receiver first verifies the Length and CRC of the SNDU. A Receiver
MUST silently discard any data, if present, after the last complete
encapsulated PDU.
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 = 0xtbd-concat |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EtherType |0| Length (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
= PDU-2 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: SNDU Format for a SNDU-Concat Payload (D=1)
A value of D=1 indicates there is no NPA/MAC address in use. A value
D=0 is also permitted, as defined in ULE, and in this case a MAC/NPA
address is attached to the SNDU base header. When D=1, the Receiver
MUST associate the specified MAC/NPA address with all PDUs within
Expires June 2006 [page 26]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
the SNDU Payload. This MAC/NPA address MUST also be forwarded with
each PDU, if required by the forwarding interface.
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 BBFrame payloads (figure 9).
These are transmitted using a single DVB-S2 Logical Channel (denoted
by a specific ISI). Each BBFrame carries a Counter value, that is
incremented modulo 255 after transmission of the BBFrame.
+------+------------------------------+------+
|ULE | Protocol Data Unit |ULE |
|Header| |CRC-32|
+------+------------------------------+------+
/ /\ \
/ / \ \
/ / \ \
+-------+-----------------------+ +-------+-------------------+
|Encaps | | |Encaps | |
|Header | | |Header | |
+-------+-----------------------+ +-------+-------------------+
Figure 14: Encapsulation of an SNDU into a series of BBFrames
6.1 SNDU Encapsulation
When an Encapsulator has not previously sent a SNDU for a specific
Stream, or after an Idle period, it starts to send an SNDU in the
first available BBFrame. This BBFrame MUST carry a Payload Pointer
value of zero indicating the SNDU starts in the first available byte
of the BBFrame payload.
The Encapsulation MUST ensure that all BBFrames incremented by one
(e.g. modulo 256 for an 8-bit value) the Counter carried in the
Encapsulation header.
An Encapsulator MAY decide not to immediately send another SNDU,
even if space is available in a partially filled BBFrame payload.
This procedure is known as Padding (figure 11). The End Indicator
informs the Receiver that there are no more SNDUs in this BBFrame
payload. The End Indicator is followed by zero or more unused bytes
until the end of the BBFrame payload. All unused bytes MUST be set
to the value of 0xFF. The Padding procedure trades decreased
efficiency against improved latency.
Expires June 2006 [page 27]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
+-/------------+
| SubNetwork |
| DU 3 |
+-/------------+
\ \
\ \
\ \
+--------+--------+--------+----------+
| Encaps | End of | 0xFFFF | Unused |
| Header | SNDU 3 | | Bytes |
+--------+--------+--------+----------+
ULE
End
Indicator
Figure 15: A BBFrame carrying the end of SNDU 3, followed by an End
Indicator.
Alternatively, when more packets are waiting at an Encapsulator, and
the BBFrame 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 BBFrame payload (see 6.2).
This is called Packing (figure 16).
+-/----------------+ +----------------/-+
| Subnetwork | | Subnetwork |
| DU 1 | | DU 2 |
+-/----------------+ +----------------/-+
\ \ / /\
\ \ / / \
\ \ / / \. . .
+--------+--------+--------+----------+
| Encaps | Payload| end of | start of |
| Header | Pointer| SNDU 1 | SNDU 2 |
+--------+--------+--------+----------+
| ^
| |
+--------------+
Figure 16: A BBFrame with the end of SNDU 1, followed by SNDU 2.
6.2 Procedure for Padding and Packing
Use of the Packing method by an Encapsulator is optional, and may be
determined on a per-session, per-packet, or per-SNDU basis.
6.3 Suspend/Resume processing
An encapsulation gateway MAY also decide to suspend a SNDU at the
end of BBFrame. In this case, it may continue transmission by
Expires June 2006 [page 28]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
sending SNDUs to other MAC addresses within the same Stream. It
MUST however preserve FIFO delivery of packets with the same MAC
address by either sending a subsequent SNDU-Resume fragment (see
section 5) or by aborting the suspended SNDU (by starting a new SNDU
with the same MAC address).
Expires June 2006 [page 29]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
7. Receiver Processing
A Receiver tunes to a specific S2 Multiplex and sets a receive
filter to accept all Packets from a specific Stream. A single
Receiver may be able to receive multiple Streams. In each case,
reassembly MUST be performed independently for each Stream. To
perform reassembly, the Receiver may use a buffer to hold the
partially assembled SNDUs (when the SNDU-Resume extension is used,
the buffers are managed separately for each active MAC/NPA address).
The buffer is 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 BBFrame with a PP value not equal to 0xFFFF indicates
that the BBFrame contains the start of a new SNDU. The value of the
Payload Pointer indicates the number of bytes to the start of the
first SNDU in the BBFrame. It is illegal to receive a Payload
Pointer value greater than the size of the BBFrame payload, 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).
In GULE, the buffers that hold partially reassembled PDUs destined
for each NPA/MAC address MAY be released at any time, and SHOULD be
released after holding a buffer pending completion for a maximum of
256 BBFrames (with the same ISI). A simple way to implement this, is
to mark each partially reassembled frame with the BBFrame Counter
value of the BBFrame in which the SNDU started, and to abort (i.e.
discard the memory buffer) when the BBFrame Counter of a later
BBFrame increments to the stored value. This mechanism imposes a
maximum fragment lifetime within the DVB-S.2 link, ensuring that
badly formed fragments are purged from the Receiver. The value 255
was chosen as a balance between memory usage, and the need for
flexible fragmentation of
large PDUs.
7.1 Idle State
After initialisation, errors, or on receipt of an End Indicator, the
Receiver enters the Idle State. In this state, the Receiver discards
all BBFrames until it discovers the start of a new SNDU (using the
PP value), when it then enters the Reassembly State.
The Idle State does NOT normally result in the discard of any
buffered SNDU Fragments. The space in buffers occupied by Fragments
that are no longer required is recovered by other means (section 7).
Figure 17 outlines these state transitions:
Expires June 2006 [page 30]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
+-------+
| START |
+---+---+
|
\/
+----------+
\| Idle |/
+-------/| State |\-------+
Insufficient | +----+-----+ |
unused space | | PP valid | Physical Error
or | \/ | or
End Indicator| +----------+ | SNDU Error
| |Reassembly| |
+--------| State |--------+
+----------+
Figure 17: Receiver state transitions
7.1.1 Idle State Payload Pointer Checking
A Receiver in the Idle State MUST check the PP value in the BBFrame
header of all received BBFrames. Following a loss of
synchronisation, the Receiver MUST discard the number of bytes
indicated by the Payload Pointer (counted from the first byte of the
BBFrame payload field), 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 BBFrame payload. If the value is less than or
equal to 4, or equal to 0xFFFF, the Receiver discards the Current
SNDU and the remaining SNDU payload (and any Fragments pending
reassembly, see section 5) and returns to the Idle State. Receipt of
an invalid Length Field is an error event and SHOULD be recorded as
an SNDU length error.
If the Length of the Current SNDU is greater than 4, the Receiver
accepts bytes from the BBFrame payload to the Current SNDU buffer
until either Length bytes in total are received, or the end of the
BBFrame payload is reached (see also 7.2.1). When 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.
Expires June 2006 [page 31]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
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 BBFrame
payload.
(i) If the Current SNDU finishes at the end of a BBFrame, the
Receiver MUST enter the Idle State.
(ii) If only one byte remains unprocessed in the BBFrame
payload after completion of the Current SNDU, the Receiver MUST
discard this final byte of BBFrame 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 BBFrame payload data remain after
completion of the Current SNDU, the Receiver accepts the next 2
bytes and examines if this is an End Indicator. When an End
Indicator is received, a Receiver MUST silently discard the
remainder of the BBFrame 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 (provided that
the BBFrame has a PP value of less than 0xFFFF, see 7.2.1,
otherwise the Receiver has detected a delimiting error and MUST
discard all remaining bytes in the BBFrame 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 PP value in the header of the next
consecutive BBFrames for the same Stream (consecutive frames are
identified by verifying the Counter value associated with the
BBFrame). 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, or the
Counter value is not one larger, modulo 255, than in the previous
BBFrame for the same Stream) the Receiver has detected a delimiting
error, or a suspended frame. The receiver follows the procedure
described in section 5.
Expires June 2006 [page 32]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
7.3 Other Error Conditions
The Receiver MUST check the BBFrame header and physical layer for
information that indicates a BBFrame has been corrupted. If
detected, a transmission error event SHOULD be recorded, and the
entire BBFrame MUST be discarded.
The Receiver MUST check the BBFrame Counter of the Encapsulation. If
the received value does NOT increment by one for successive BBFrames
within a stream (modulo 255), the Receiver has detected a continuity
error. A BBFrame counter error event SHOULD be recorded. A loss of
continuity implies a Receiver has missed one or more SNDUs (e.g.
because they was sent using a ModCod that the Receiver was unable to
decode). The missed SNDUs do not necessarily have a NPA/MAC that the
Receiver will forward. The Receiver MUST enter the Idle State, and
use the PP value in the new BBFrame to recover framing alignment.
In Generic Mode, continuity errors may occur because an
Encapsulation Gateway uses a ModCod [ETSI-S2, S2-REQ] that does not
provide sufficient protection for the receive conditions experienced
by a Receiver or a ModCod that is not implemented by a specific the
Receiver.
Expires June 2006 [page 33]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
8. Summary
This document defines an Generic Unidirectional Lightweight
Encapsulation (GULE) to perform efficient and flexible support for
IPv4 and IPv6 network services over networks built upon the DVB S2
physical layer specification operating in the Generic Mode. The
encapsulation is also suited to transport of other protocol packets
and bridged Ethernet frames.
GULE utilises Extension Header format defined by the Uni-directional
Lihtweight Encapsulation (ULE) defined by RFC4236 and shares the
associated IANA registry for support of both mandatory and optional
SNDU headers.
9. IANA Considerations
This document will require IANA involvement for the assignment of
two new ULE option headers. These options are defined for specific
use cases envisaged by GULE, but are compatible with ULE.
10. Acknowledgments
This draft is based on the ULE protocol specification developed by
the IETF ipdvb WG. The author gratefully acknowledges the inputs,
comments and assistance offered by the members of the DVB-GBS ad hoc
group on S2 encapsulation, and the inputs provided by the DVB-RCS WG
in identifying appropriate protocol requirements. The author also
wishes to thank Bernhard Collini-Nocker for his constructive email
and to others who have patiently tried to explain DVB-S2. The author
particularly wishes to thank Juan Cantillo & Jerome Lacan for their
constant attention to detail and their contributions to the
definition of the requirements for this protocol spec. The Suspend
and Concat modes, and various other improvements followed
discussions with Rita Ronaldo and Ulrik de Be.
11. Security Considerations
The security considerations for GULE resemble those of ULE, and
security mechanisms developed as ULE extensions are expected to be
appropriate also to the use of GULE.
Expires June 2006 [page 34]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
12. References
12.1 Normative References
[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.
[RFC4236] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP
datagrams over an MPEG-2 Transport Stream", Formerly <draft-ipdvb-
arch-xx.txt, RFC 4236, December 2006.
[ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second
generation framing structure, channel coding and modulation systems
for Broadcasting, Interactive Services, News Gathering and other
broadband satellite applications", European Telecommunication
Standards Institute (ETSI).
12.2 Informative References
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting",
European Telecommunications Standards Institute (ETSI).
[ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB-
S2", Internet Draft <draft-cantillo-ipdvb-s2encaps-01.rxr>, Work in
Progress.
[ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio Information
Systems", International Standards Organisation (ISO).
[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 2006.
[S2-Eval] "Procedure for Comparative Evaluation of IP/DVB-S2
Encapsulation Protocol over Generic Streams", Technical Note, Work
in Progress, DVB TM-GBS.
[S2-REQ] GBS0339, "Functional and performance requirements for
IP/S2", DVB-TM GBS WG.
[S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB TM RCS WG.
Expires June 2006 [page 35]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
13. Authors' Addresses
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/Gorry
14. IPR Notices
14.1 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
14.2 Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
15. Copyright Statement
Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Expires June 2006 [page 36]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
Appendix A: Scenarios for Fragmentation
This appendix provides a set of informative examples of the usage of
this encapsulation.
A.1 CONSECUTIVE Fragmentation
This is the normal mode for fragmentation, where there is no
additional header overhead resulting from SNDU fragmentation. SNDU
fragments sent to the same NPA/MAC address follow in the next
consecutive BBFrame sent to the same stream. These may be
interleaved with other BBFrames associated with different streams.
In the following figure, there are no additional overhead bytes
consumed by Fragmentation of F2.
+--------------+ +-------------+
| F1 | F2a | | F2b |F3 |
|* c|* | | c|* c|
+--------------+ +-------------+
BBFrame 1 2
PP F2a F3
* = SNDU base header
c = SNDU payload CRC-32
Figure A.1.1 Fragments will follow in the next consecutive BBFrame
In the figure below, a large SNDU is fragmented across 3 consecutive
frames, each sent using the same stream.
+--------------+ +-------------+ +--------------+
| F1 | F2a | | F2b | | F2c | F3 |
|* c|* | | | | c|* c|
+--------------+ +-------------+ +--------------+
BBFrame 1 2 3
PP F2a 0xFFFF F3
* = SNDU base header
c = SNDU payload CRC-32
Figure A.1.2 Figure A.1.2 Fragments will follow in the next
consecutive BBFrame
There is no additional overhead bytes consumed by Fragmentation of
F2 in the case of fragmentation across an arbitrary number of
BBFrames.
Expires June 2006 [page 37]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
A.2 GAP Fragmentation
In the case of a "gap" fragmentation, the Encapsulation sends a
BBFrame after starting a fragment, that is not completed in the next
adjacent BBFrame. Instead, one or more BBFrames are sent which are
not directed at the same intended recipient (i.e. NPA/MAC address).
It may be, for instance be that the Receiver can not decode the
ModCod used for these intervening frames. In the figures in this
section, it is assumed that all the BBFrames are directed to the
same common stream.
In this encapsulation, this requires a fragment header in the
resumed segment (F2b shown in the figure below).
+--------------+ +-------------+ +--------------+
| F1 | F2a | |XXXXXXXXXXXXX| | F2b | |
|* c|* | | | |+ c| |
+--------------+ +-------------+ +--------------+
* = SNDU base header
+ = SNDU-Resume Fragment
c = SNDU payload CRC-32
Figure A.2.1 BBFrames are not consecutive in the SNDU flow.
The additional overhead resulting from the fragmentation of F2 = 1
base header+CRC in F2b.
+--------------+ +-------------+ +-------------+ +--------------+
| F1 | F2a | |XXXXXXXXXXXX | | F2b | | F2c | |
|* c|* | | | | |+ | | c| |
+--------------+ +-------------+ +-------------+ +--------------+
* = SNDU base header
+ = SNDU-Resume Fragment
c = SNDU payload CRC-32
Figure A.2.2 BBFrames are not consecutive in the SNDU flow.
The additional overhead resulting from the fragmentation of the SNDU
into three BBFrames is the same as that for the frame depicted in
Figure A.2.2. Since the fragment F2c is consecutive with that of
F2c (i.e. it is the next in-sequence BBFrame that was sent with the
same stream identifier), there is no additional fragmentation
header.
In some cases the Encapsulation Gateway may choose a transmission
ordering that eliminates the need for a gap transmission (in this
case, scheduling the 2nd burst in figure A.2.2 before the start of
the first). Where this is possible, it eliminates the need for the
additional overhead associated with suspending and resuming a SNDU.
Expires June 2006 [page 38]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
It is also permitted to suspend and later resume a SNDU on more than
one occasion, should the Encapsulation Gateway wish to send a frame
using space available in several BBFrames.
+--------------+ +--------------+ +--------------+
| F1 | F2a | |F3 | F2b | | F4 | F2c |
|* c|* | |* c|+ | |* c|+ c|
+--------------+ +--------------+ +--------------+
* = SNDU base header
+ = SNDU-Resume Fragment
c = SNDU payload CRC-32
Figure A.2.3 BBFrames that send F2 utilising the remaining space in
3 BBFrames.
In the above example, SNDUs F3 and F4 carry a unicast address that
is not the same as that used for F2. In this encapsulation, this
requires two fragment headers (and CRCs) in each of the resumed
segments (F2b,F2c shown in the figure below). The extra flexibility
may be justified, for example, in cases where the three BBFrames are
sent using ModCod values that provide higher protection than
required for transmission of F2, but where there is no higher
priority traffic pending transmission in these frames. In this case,
there will be a higher physical-layer cost, and the additional
overhead only adds to this transmission cost.
A.3 Abort Fragmentation
These examples show the cases where the encapsulation process is
terminated, resulting in discard of the partially received fragment.
All the examples refer to a sequence of BBFrames associated with the
same stream.
+--------------+ +-------------+
| F1 | F2a | | F3 |
|* c|* | |* c|
+--------------+ +-------------+
BBFrame 1 2
PP F2a 0 (First byte of F3)
* = SNDU base header
+ = SNDU-Resume Fragment
c = SNDU payload CRC-32
Figure A.3.1 Aborted Frame by start of a new complete SNDU (F3) to
same NPA/MAC address
In the above example, F2a is a partially complete fragment, followed
by a BBFrame that contains the start of a different SNDU that is has
Expires June 2006 [page 39]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
the same Receiver NPA/MAC address. Receipt of the SNDU F3 results in
F2a being aborted.
+--------------+ +-------------+ +--------------+
| F1 | F2a | |XXXXXXXXXXXX | | F3 | F4 |
|* c|* | | | | |* c|* c|
+--------------+ +-------------+ +--------------+
Figure A.3.2 Aborted Frame by start of a new complete fragment to
same MAC address
In the above example, F2a is a partially complete fragment, followed
by a BBFrame that is not decoded by the Receiver and F3 is a
complete SNDU sent to a different Receiver NPA/MAC address. F4 is
sent to the same MAC address as F2a, and results in F2a being
aborted.
A.4 Informative examples of usage of SNDU-Resume
These examples illustrate use of the SNDU-Resume extension. All the
examples refer to a sequence of BBFrames associated with the same
Stream.
In the following example, SNDU 2 is fragmented into three parts
(F2a,F2b,F2c). The first part of the SNDU, F2a contains the SNDU
base header, followed by a sequence of bytes until the end of the
1st BBFrame. Fragment F2b follows in a later BBFrame as a SNDU-
Resume fragment F2b, allowing transmission of F3 also within the
second BBFrame. The final part of the SNDU is also sent in an SNDU-
Resume fragment, F2c.
+--------------+ +--------------+ +--------------+
| F1 | F2a | |F2b | F3 | | F4 | F2c |
|* c|* | |+ d|* c| |* c|+ c|
+--------------+ +--------------+ +--------------+
BBFrame 1 2 3
PP 0 0 0
* = SNDU base header
+ = SNDU-Resume header
c = CRC-32 used to validate integrity of SNDU.
d = CRC-32 used only to validate framing.
Figure A.4.1 Example use of SNDU-Resume
In the example above, a decision was made by the Gateway to send
fragment F2c as a SNDU-Resume fragment. If the Fragment F2b had been
sent at the end of the second BBFrame, the Length field of the SNDU-
Resume fragment could have been set to the total number of remaining
bytes, allowing F2c to be sent as a continuation fragment,
eliminating the need for a SNDU-header for
Expires June 2006 [page 40]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
F2c (and hence improving efficiency).
+--------------+ +--------------+ +--------------+
| F1 | F2a | |F3 | F2b | | F2c | F4 |
|* c|* | |* c|+ | | c|* c|
+--------------+ +--------------+ +--------------+
BBFrame 1 2 3
PP 0 0 (1st byte of F4)
* = SNDU base header
+ = SNDU-Resume header
c = CRC-32 used to validate integrity of SNDU.
Figure A.4.2 Example use of SNDU-Resume (optimised placement)
Expires June 2006 [page 41]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
Appendix B: Alternative design options.
This section identifies a set of issued that will require further
consideration.
B.1 Expanded D-Field
00 No MAC
01 Mac 3B * **
10 Mac 6B
11 Currently Unused
* Note: Subject to a satisfactory use-case being defined.
** Note: The short-form NPA/MAC address may also be represented in
long-form by prefixing this with a well-known/reserved IEEE OUI
field. The mapping of multicast IP addresses to the short-form OUI
is to be specified. This mode is also outlined in [S2-REQ].
B.2 Reduction of CRC Field
The size of the CRC field may be reduced in future revisions of this
document, subject to alternative methods being found that provide
equivalent protection. A CRC-16 could be used in combination with
appropriate and reliable feedback from the BBFrame processing layer.
A method could be defined that does not employ a CRC for complete
(unfragmented) SNDUs.
Selection of the appropriate method requires inputs from experts
with knowledge of the DVB-S.2 channel.
B.3 Encapsulation Header Field
Two methods of adding encapsulation overhead are defined. Selection
of the appropriate method requires inputs from experts with
knowledge of the DVB-S.2 BBHeader format.
Expires June 2006 [page 42]
INTERNET DRAFT Encapsulation for IP over DVB-S2/GS Jan 2006
[RFC EDITOR NOTE:
This section must be deleted prior to publication]
DOCUMENT HISTORY
Draft 00
This draft is intended as a study item for proposed future work by
the DVB-GBS in this area. Comments relating to this document will
be gratefully received by the author(s) and may also be sent to ip-
dvb mailing list at: ip-dvb@erg.abdn.ac.uk
Draft 01
This draft was updated to include recommended placement of the
encapsulation overhead within the BBFrame header, improved
readability, correction of the counter field use (this does not
trigger realignment, and is only for OAM), improved fragmentation
text.
Draft 02
The author wishes to acknowdledge the detailed review by Juan
Cantillo & Jerome Lacan, and their comments and contributions. Many
references to MPEG-2 TS were corrected, and other minor mistakes
were also corrected.
Draft 03
This draft was updated following discussion at the DVB S.2 GS Study
Group.
The additions include:
SNDU-Resume - addition of payload format and informative examples
SNDU-Suspend - new extension
SNDU-Concat - new extension
The Idle state does not result in discard of the Currenmt SNDU (as
in GULE).
Section 1 now includes implementation notes/constraints.
It also includes a number of editorial corrections.
Draft 04
This rev of the Spec does not use the CRC for validating frame
alignment (i.e.delineating SNDU boundaries), and also therefore the
SNDU Suspend option has no CRC-32. The SNDU-Resume option only
carries a CRC when this is the final fragment of a SNDU. This
modification came from comments from Axel J. and Rita R.
Text was also updated on the Counter to clarify use in combination
with the PP value (U.de.B).
--------------------------------------------------------------------
[END of RFC EDITOR NOTE]
Expires June 2006 [page 43]