draft-ietf-ipdvb-ule-ext-00.txt   draft-ietf-ipdvb-ule-ext-01.txt 
Internet Engineering Task Force Gorry Fairhurst Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen Internet Draft University of Aberdeen
Document: draft-ietf-ipdvb-ule-ext-00.txt B. Collini-Nocker Expires July 2007 B. Collini-Nocker
University of Salzburg University of Salzburg
Extension Formats for Unidirectional Link Encapsulation (ULE)
Category: WG Draft intended for PS January 2006 and the Generic Stream Encapsulation (GSE)
draft-ietf-ipdvb-ule-ext-01.txt
Extension Formats for Unidirectional Link Encapsulation (ULE) and
the Generic Stream Encapsulation (GSE)
Status of this Draft Status of this Draft
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress". reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (c) The IETF Trust (2007).
Abstract Abstract
This document describes a set of Extension Headers for the This document describes a set of Extension Headers for the
Unidirectional Link Encapsulation (ULE) [RFC4236]. Unidirectional Link Encapsulation (ULE) [RFC4236].
The Extension Header formats defined in this document define new The Extension Header formats defined in this document define new
extensions that are common extensions to both ULE and the Generic extensions that are common extensions to both ULE and the Generic
Stream Encapsulation (GSE) [GSE] defined by the second generation Stream Encapsulation (GSE) [GSE] defined by the second generation
framing structure DVB-S2 standard [S2]. framing structure DVB-S2 standard [S2].
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Conventions used in this document 2. Conventions used in this document
3. Description of method 3. Description of method
3.1 MPEG-2 TS-Concat Extension 3.1 MPEG-2 TS-Concat Extension
3.2 PDU-Concat Extension 3.2 PDU-Concat Extension
3.3 TimeStamp Extension
4. Summary 4. Summary
5. IANA Considerations 5. IANA Considerations
6. Acknowledgments 6. Acknowledgments
7. Security Considerations 7. Security Considerations
8. References 8. References
skipping to change at page 3, line 11 skipping to change at page 3, line 11
11.2 Disclaimer of Validity 11.2 Disclaimer of Validity
Appendix A: Appendix A:
1. Introduction 1. Introduction
This document describes two new Header Extensions that may be used This document describes two new Header Extensions that may be used
with both Unidirectional Link Encapsulation, ULE, [RFC4236] and the with both Unidirectional Link Encapsulation, ULE, [RFC4236] and the
Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for links Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for links
that employ the MPEG-2 Transport Stream, and supports a wide variety that employ the MPEG-2 Transport Stream, and supports a wide variety
of physical-layer bearers [RFC4259]. GSE has been designed for the of physical-layer bearers [RFC4259].
Generic Mode (also known as the Generic Stream (GS)), offered by
second-generation DVB physical layers, and specifically for DVB-S2 GSE has been designed for the Generic Mode (also known as the
[ETSI-S2]. The requirements for the Generic Stream are defined in Generic Stream (GS)), offered by second-generation DVB physical
[S2-REQ], [S2-REQ-RCS], and [ID-S2-REQ]. The important layers, and specifically for DVB-S2 [ETSI-S2]. The requirements for
characteristics of this encapsulation are described in an Appendix the Generic Stream are defined in [S2-REQ], [S2-REQ-RCS], and [ID-
to this document. GSE maintains a design philosophy that presents a S2-REQ]. The important characteristics of this encapsulation are
common network interface to that of ULE and uses a similar described in an Appendix to this document. GSE maintains a design
construction for Subnetwork Data Unit (SNDUs). philosophy that presents a common network interface to that of ULE
and uses a similar construction for Subnetwork Data Unit (SNDUs).
One extension header defines a method that allows one or more TS- One extension header defines a method that allows one or more TS-
Packets [ISO-MPEG] to be sent within a ULE SNDU. This method may be Packets [ISO-MPEG] to be sent within a ULE SNDU. This method may be
used to provide control plane information including the transmission used to provide control plane information including the transmission
of MPEG-2 Program Specific Information (PSI) for the Multiplex. In of MPEG-2 Program Specific Information (PSI) for the Multiplex. In
GSE, there is no native support for transport stream packets and GSE, there is no native support for transport stream packets and
this method is therefore suitable for providing an MPEG-2 control this method is therefore suitable for providing an MPEG-2 control
plane. plane.
A second extension header allows one or more PDUs to be sent within A second extension header allows one or more PDUs to be sent within
skipping to change at page 3, line 41 skipping to change at page 3, line 42
number of small PDUs are directed to the same Network Point of number of small PDUs are directed to the same Network Point of
Attachment (NPA) address. The method may improve transmission Attachment (NPA) address. The method may improve transmission
efficiency (by removing duplicated MAC layer overhead). It can also efficiency (by removing duplicated MAC layer overhead). It can also
reduce processing overhead for receivers that are not addressed by reduce processing overhead for receivers that are not addressed by
the NPA, since these receivers may then skip several PDUs in one the NPA, since these receivers may then skip several PDUs in one
operation. The method is defined as a generic extension header and operation. The method is defined as a generic extension header and
may be used for IPv4 or IPv6 packets. If and when a compression may be used for IPv4 or IPv6 packets. If and when a compression
format is defined for ULE or Ethernet, the method may also be used format is defined for ULE or Ethernet, the method may also be used
in combination with this method. in combination with this method.
Future versions of this document are expected to provide A third extension header provides an optional timestamp value for an
recommendations on the interface between the Generic Stream SNDU. Examples of the use of this timestamp option include
Encapsulation (GSE) and the Internet Protocol Stack. monitoring and benchmarking of ULE and GSE links. Receivers that do
not wish to decode (or do not support) the timestamp extension may
discard the extension and process the remaining PDU or extension
headers.
The appendix includes a summary of key design issues and The appendix includes a summary of key design issues and
considerations based on the GSE Specification defined by the DVB considerations based on the GSE Specification defined by the DVB
Technical Module[GSE]. Technical Module[GSE].
2. Conventions used in this document 2. Conventions used in this document
This document uses the conventions defined in [RFC2119]. The key The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "OPTIONAL" in this document are to be interpreted as described in
document are to be interpreted as described in RFC 2119. This RFC 2119 [RFC2119].
indicates the requirement levels for compliant implementations.
b: bit. For example, one byte consists of 8b. b: bit. For example, one byte consists of 8b.
B: Byte. Groups of bytes are represented in Internet byte order. B: Byte. Groups of bytes are represented in Internet byte order.
BBFrame payload [ETSI-S2]: The data field part of a Baseband frame BBFrame payload [ETSI-S2]: The data field part of a Baseband frame
that may be used for the communication of data. Typical BBFrames that may be used for the communication of data. Typical BBFrames
range in size from 3072 to 58192 bits according to the choice of range in size from 3072 to 58192 bits according to the choice of
modulation format and method of Forward Error Correction in use. modulation format and FEC in use.
DVB: Digital Video Broadcast. A framework and set of DVB: Digital Video Broadcast. A framework and set of
associated standards published by the European Telecommunications associated standards published by the European Telecommunications
Standards Institute (ETSI) for the transmission of video, audio, and Standards Institute (ETSI) for the transmission of video, audio, and
data. data.
Encapsulator: A network device that receives PDUs and formats these Encapsulator: A network device that receives PDUs and formats these
into Payload Units (known here as SNDUs) for output in DVB-S or the into Payload Units (known here as SNDUs) for output in DVB-S or the
Generic Mode of DVB-S2. Generic Mode of DVB-S2.
skipping to change at page 6, line 26 skipping to change at page 6, line 26
>>> IANA Action required, please replace < #NH-TS-CAT> with assigned >>> IANA Action required, please replace < #NH-TS-CAT> with assigned
value from the Next-Header Registry>>> value from the Next-Header Registry>>>
The MPEG-2 TS-Concat Extension Header is specified by an IANA The MPEG-2 TS-Concat Extension Header is specified by an IANA
assigned H-Type value of <#NH-TS-CAT>. This is a Mandatory Next- assigned H-Type value of <#NH-TS-CAT>. This is a Mandatory Next-
Header Extension. Header Extension.
The extension is used to transport 1 or more MPEG-2 TS Packets The extension is used to transport 1 or more MPEG-2 TS Packets
within a ULE SNDU. The number of TS Packets carried in a specific within a ULE SNDU. The number of TS Packets carried in a specific
SNDU is determined from the size specified by the remainder of the SNDU is determined from the size specified by the remainder of the
Payload following the MPEG-2 TS Extension. A Receiver MUST verify Payload following the MPEG-2 TS Extension. The number of TS packets
that payload length is correct prior to processing it, and SHOULD be contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N
recorded as TS-concat size mismatch error. is the number of bytes associated with Extension Headers that
precede the MPEG-2 TS-Concat Extension (zero if there are none). A
Receiver MUST check that the payload length is correct prior to
processing it. Any mismatch (remainder from the division) MUST
result in discard of all encapsulated PDUs and SHOULD be recorded as
TS-concat size mismatch error.
Consider the example shown in the figure below. The value D=0 A value D=0 indicates the presence of a NPA address. In that case
indicates the presence of a NPA address. In this example, there are the correct payload length for ULE is (Length-10) / 188, whereas in
no additional extension headers between the ULE base header and the case of GSE the correct payload length is (Length-6) / 188.
TS-Concast extension, therefore the payload length value using ULE
is (Length - 10) / 188, whereas the value for payload length using
GSE is (Length - 6) / 188.
>>> IANA Action required, please replace < #NH-TS-CAT> with assigned
value from the Next-Header Registry>>>
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 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 = 0x #NH-TS-CAT | |0| Length (15b) | Type = 0x <#NH-TS-CAT> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 | | TS-Packet 1 |
= = = =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) | | TS-Packet 2 (if Length > 2*188) |
skipping to change at page 7, line 4 skipping to change at page 7, line 24
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) | | TS-Packet 2 (if Length > 2*188) |
= = = =
| etc. | | etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0) Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0)
>>> IANA Action required, please replace < #NH-TS-CAT> with assigned >>> IANA Action required, please replace < #NH-TS-CAT> with assigned
value from the Next-Header Registry in Figures 1 and 2>>> value from the Next-Header Registry>>>
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 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 =0x #NH-TS-CAT | |0| Length (15b) | Type =0x <#NH-TS-CAT> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 | | TS-Packet 1 |
= = = =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) | | TS-Packet 2 (if Length > 2*188) |
skipping to change at page 9, line 11 skipping to change at page 9, line 11
is noted that the operation may be simplified by ensuring that all is noted that the operation may be simplified by ensuring that all
SNDUs that carry this Extension Header are placed before other data SNDUs that carry this Extension Header are placed before other data
within the GSE DataField [GSE]. within the GSE DataField [GSE].
3.2 PDU-Concat Extension 3.2 PDU-Concat Extension
>>> IANA Action required, please replace <#NH-PDU-CAT> with assigned >>> IANA Action required, please replace <#NH-PDU-CAT> with assigned
value from the Next-Header Registry>>> value from the Next-Header Registry>>>
The PDU-Concat Extension is specified by an IANA assigned H-Type The PDU-Concat Extension is specified by an IANA assigned H-Type
value of #NH-PDU-CAT This is a Mandatory Next-Header Extension. It value of <#NH-PDU-CAT> This is a Mandatory Next-Header Extension.
enables a sequence of (usually short) PDUs to be sent within a It enables a sequence of (usually short) PDUs to be sent within a
single SNDU payload. single SNDU payload.
The base header contains the Length of the entire SNDU. This carries The base header contains the Length of the entire SNDU. This carries
the value of the combined length of all PDUs to be encapsulated, the value of the combined length of all PDUs to be encapsulated,
including each set of encapsulation headers. The base header also including each set of encapsulation headers. The base header also
caries a 16-bit ULE Type field. Although any Type value specified in caries a 16-bit ULE Type field. Although any Type value specified in
the ULE Next-Header Registry may be assigned to the encapsulated the ULE Next-Header Registry may be assigned to the encapsulated
PDU, all PDUs included in the SNDU payload MUST have a common ULE PDU, all PDUs included in the SNDU payload MUST have a common ULE
Type (i.e. all concatenated PDUs passed by the network layer must be Type (i.e. all concatenated PDUs passed by the network layer must be
associated with the same Type value). This simplifies the receiver associated with the same Type value). This simplifies the receiver
skipping to change at page 11, line 14 skipping to change at page 11, line 18
routers that are sent using shared links (i.e., where the same link 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 connects multiple Receivers). A sender MAY omit this field (D=1) for
a set of packets delivered to a Receiver or group of receivers that a set of packets delivered to a Receiver or group of receivers that
are able to utilise a discriminator field (e.g. the IPv4/IPv6 are able to utilise a discriminator field (e.g. the IPv4/IPv6
destination address, or a bridged MAC destination address), which in destination address, or a bridged MAC destination address), which in
combination with the PID value, could be interpreted as a Link-Level combination with the PID value, could be interpreted as a Link-Level
address. A similar format is supported in GSE. address. A similar format is supported in GSE.
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 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 = 0x<#NH-PDU-CAT | |1| Length (15b) | Type = 0x<#NH-PDU-CAT> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONCAT-PDU-Type |0| PDU-Length-1 (15b) | | CONCAT-PDU-Type |0| PDU-Length-1 (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 = = PDU-1 =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PDU-Length-2 (15b) | | |0| PDU-Length-2 (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 = = PDU-2 =
| | | |
skipping to change at page 12, line 5 skipping to change at page 12, line 5
The Receiver processes this Extension Header by verifying that it The Receiver processes this Extension Header by verifying that it
supports the specified CONCAT-PDU Type (unsupported Types MUST be supports the specified CONCAT-PDU Type (unsupported Types MUST be
discarded but the receiver SHOULD record a PDU-Type error). It then discarded but the receiver SHOULD record a PDU-Type error). It then
extracts each encapsulated PDU in turn. The Receiver MUST verify the extracts each encapsulated PDU in turn. The Receiver MUST verify the
Length of each PDU. It MUST also ensure the sum of the Lengths of Length of each PDU. It MUST also ensure the sum of the Lengths of
all processed PDUs is less than the Length specified in the SNDU all processed PDUs is less than the Length specified in the SNDU
base header. A Receiver MUST discard the whole SNDU if the sizes do base header. A Receiver MUST discard the whole SNDU if the sizes do
not match and this event SHOULD be recorded as a PDU-concat size not match and this event SHOULD be recorded as a PDU-concat size
mismatch error. mismatch error.
3.3 Timestamp Extension
The timestamp extension header permits an Encapsulator to add a
timestamp field to an SNDU. This is designed to support monitoring
and measurement of ULE performance over a link to indicate the
quality of an operational ULE link. This may be useful for GSE links
(where significant complexity exists in the scheduling provided by
the lower layers). This extension may be (optionally) checked at the
Receiver.
Possible uses of this extension include:
* Validation of in-sequence ordering per Logical Channel,
* Measurement of one-way delay (when synchronised with the sender)
* Measurement of PDU Jitter introduced by the link,
* PDU loss (with additional information from the sender).
>>> IANA please insert a value for the H-Type from the Optional part
of the Next-Header Registry, and replace <NH-TStamp> in the sentence
below, and the figure following <<<
The Timestamp Extension Header is specified by the IANA-assigned H-
Type of <NH-TStamp>. This extension is an Optional Extension Header
([RFC4326], Section 5).
0 7 15 23 31
+---------------+---------------+---------------+---------------+
| 0x03 | <NH-TStamp> | time stamp HI |
+---------------+---------------+---------------+---------------+
| time stamp LO | Type |
+---------------+---------------+---------------+---------------+
Figure 7 The format of the 32-bit Timestamp Extension Header
Figure 7 shows the format of this extension with a HLEN value of 3
indicating a timestamp of length 4B with a Type field (there is no
implied byte-alignment).
The extension carries a 32-bit value (time stamp HI plus time stamp
LO). The specified resolution is 1 microsecond. The value therefore
indicates the number of 1 microsecond ticks past the hour in
Universal Time when the timestamp option was inserted, right-
justified to the 32-bit field. Systems unable to insert timestamps
at the specified resolution may use an arbitrary (and varying) value
to pad the unused least-significant bits.
The last two bytes carry a 16-bit Type field that indicates the type
of payload carried in the SNDU, or the presence of a further Next-
Header ([RFC4326], Section 4.4).
This is an Optional Extension Header. Receivers that do not
implement, or do not wish to process, the Timestamp Extension MAY
skip this extension and continue to process the remainder of the
SNDU, forwarding the encapsulated PDU.
4. Summary 4. Summary
This document defines a set of Next_Header Extensions for the This document defines a set of Next_Header Extensions for the
Unidirectional Link Encapsulation (ULE). Unidirectional Link Encapsulation (ULE).
5. IANA Considerations 5. IANA Considerations
This document requires IANA involvement for the assignment of two This document requires IANA involvement for the assignment of two
new Next-Header Type values from the IANA ULE Next-Header Registry. new Next-Header Type values from the IANA ULE Next-Header Registry.
These options are defined for specific use cases envisaged by GSE, These options are defined for specific use cases envisaged by GSE,
but are compatible with ULE. but are compatible with ULE.
The TS-Concat Extension is a Mandatory next-type extension header, The TS-Concat Extension is a Mandatory next-type extension header,
specified in section 3.1 of this document. The value of this next- specified in section 3.1 of this document. The value of this next-
header is defined by an IANA assigned H-Type value of #NH-TS-CAT. header is defined by an IANA assigned H-Type value of <#NH-TS-CAT>.
The PDU-Concat Extension is a Mandatory next-type extension header The PDU-Concat Extension is a Mandatory next-type extension header
specified in section 3.2 of this document. The value of this next- specified in section 3.2 of this document. The value of this next-
header is defined by an IANA assigned H-Type value of #NH-PDU-CAT. header is defined by an IANA assigned H-Type value of <#NH-PDU-CAT>.
The Timestamp Extension is an Optional next-type extension header
specified in section 3.3 of this document. The value of this next-
header is defined by an IANA assigned H-Type value of <#NH-TStamp>.
This documents defines format for a HLEN value of 0x3.
6. Acknowledgments 6. Acknowledgments
The author gratefully acknowledges the inputs, comments and The author gratefully acknowledges the inputs, comments and
assistance offered by the members of the DVB-GBS ad hoc group on S2 assistance offered by the members of the DVB-GBS ad hoc group on S2
encapsulation, in particular contributions on transmission aspects encapsulation, in particular contributions on transmission aspects
from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. from Rita Rinaldo, Axel Jahn, and Ulrik De Bie.
7. Security Considerations 7. Security Considerations
skipping to change at page 13, line 49 skipping to change at page 14, line 49
Nocker, B., and H. Linder, "A Framework for Transmission of IP Nocker, B., and H. Linder, "A Framework for Transmission of IP
Datagrams over MPEG-2 Networks", RFC 4259, November 2006. Datagrams over MPEG-2 Networks", RFC 4259, November 2006.
[S2] EN 302 307, "Digital Video Broadcasting (DVB); Second [S2] EN 302 307, "Digital Video Broadcasting (DVB); Second
generation framing structure, channel coding and modulation systems generation framing structure, channel coding and modulation systems
for Broadcasting, Interactive Services, News Gathering and other for Broadcasting, Interactive Services, News Gathering and other
broadband satellite applications", European Telecommunication broadband satellite applications", European Telecommunication
Standards Institute (ETSI). Standards Institute (ETSI).
[S2-REQ] GBS0339, "Functional and performance requirements for [S2-REQ] GBS0339, "Functional and performance requirements for
IP/S2", DVB-TM GBS WG. IP/S2", DVB-TM (GBS WG).
[S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB Technical [S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB Technical
Module (RCS WG). Module (RCS WG).
9. Authors' Addresses 9. Authors' Addresses
Godred Fairhurst Godred Fairhurst
Department of Engineering Department of Engineering
University of Aberdeen University of Aberdeen
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/Gorry Web: http://www.erg.abdn.ac.uk/users/Gorry
Bernhard Collini-Nocker Bernhard Collini-Nocker
Department of Scientific Computing Department of Computer Sciences
University of Salzburg University of Salzburg
Jakob Haringer Str. 2 Jakob Haringer Str. 2
5020 Salzburg 5020 Salzburg
Austria Austria
EMail: bnocker@cosy.sbg.ac.at EMail: bnocker@cosy.sbg.ac.at
Web: http://www.scicomp.sbg.ac.at/ Web: http://www.cosy.sbg.ac.at/
10. IPR Notices 10. IPR Notices
Copyright (c) The IETF Trust (2007).
10.1 Intellectual Property Statement 10.1 Intellectual Property Statement
Full Copyright Statement
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, THE
IETF TRUST 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.
10.2 Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
skipping to change at page 15, line 18 skipping to change at page 16, line 5
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgment 10.2 Disclaimer of Validity
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
The IETF invites any interested party to bring to its attention any This document and the information contained herein are provided on
copyrights, patents or patent applications, or other proprietary an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
rights that may cover technology that may be required to implement REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
this standard. Please address the information to the IETF at ietf- IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
ipr@ietf.org. 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.
11. Copyright Statement 11. Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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.
APPENDIX: DVB-S.2
PDUs, (Ethernet Frames, IP datagrams or other network layer packets)
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 [ID-S2-REQ]. A mode also permits an SNDU to be fragmented
with the remaining fragments sent in a later BBFrame(s), 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 are
assigned to the same Stream.
In ULE and MPE [ETSI-DAT], each SNDU carries a 32-bit CRC field in
the last four bytes of the SNDU. 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. This also serves to verify the delineation (framing) of
PDUs and may detect the presence of uncorrected errors from the
physical link
When an SNDU is sent over a DVB-S2 subnetwork using GSE, the
Integrity protection is provided by a CRC at the baseband frame
level, using a CRC in the final bytes of the DataField.
[RFC EDITOR NOTE: [RFC EDITOR NOTE:
This section must be deleted prior to publication] This section must be deleted prior to publication]
DOCUMENT HISTORY DOCUMENT HISTORY
Individual Draft 00 Individual Draft 00
This draft complements a study item in the DVB-GBS in this area to This draft complements a study item in the DVB-GBS in this area to
define a Generic Stream Encapsulation (GSE). Comments relating to define a Generic Stream Encapsulation (GSE). Comments relating to
this document will be gratefully received by the author(s) and may 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 also be sent to ip-dvb mailing list at: ip-dvb@erg.abdn.ac.uk
Individual Draft 01 Individual Draft 01
Co-Author Added. Co-Author Added.
This draft updates the language and format. This draft updates the language and format.
This draft fixes problems with the concatenation mode, and defines a This draft fixes problems with the concatenation mode, and defines a
new header format that restricts the use of the Type field so that new header format that restricts the use of the Type field so that
skipping to change at page 16, line 32 skipping to change at page 17, line 34
Headers, proposals and ideas are welcome via the IETF ipdvb mailing Headers, proposals and ideas are welcome via the IETF ipdvb mailing
list. Possible extensions include those for encapsulation FEC, Link list. Possible extensions include those for encapsulation FEC, Link
parameter negotiation (e.g. for header compression), and support for parameter negotiation (e.g. for header compression), and support for
ATM/ULE. ATM/ULE.
Working Group Draft 00 Working Group Draft 00
Fixed editorial mistakes from Christian Praehauser and ID style for Fixed editorial mistakes from Christian Praehauser and ID style for
WG adoption. WG adoption.
[END of RFC EDITOR NOTE] Working Group Draft 01
APPENDIX: DVB-S.2
PDUs, (Ethernet Frames, IP datagrams or other network layer packets)
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 [ID-S2-REQ]. A mode also permits an SNDU to be fragmented
with the remaining fragments sent in a later BBFrame(s), 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 are
assigned to the same Stream.
In ULE and MPE [ETSI-DAT], each SNDU carries a 32-bit CRC field in Corrected contact info for Bernhard.
the last four bytes of the SNDU. The purpose of this CRC is to Added TimeStamp Options
protect the SNDU (header, and payload) from undetected reassembly Corrected NITS in draft
errors and errors introduced by unexpected software / hardware
operation. This also serves to verify the delineation (framing) of
PDUs and may detect the presence of uncorrected errors from the
physical link
When an SNDU is sent over a DVB-S2 subnetwork using GSE, the [END of RFC EDITOR NOTE]
Integrity protection is provided by a CRC at the baseband frame
level, using a CRC in the final bytes of the DataField.
 End of changes. 33 change blocks. 
101 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/