draft-ietf-ipdvb-ule-ext-02.txt   draft-ietf-ipdvb-ule-ext-03.txt 
Internet Engineering Task Force Gorry Fairhurst Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen Internet Draft University of Aberdeen
Expires November 2007 B. Collini-Nocker Expires November 2007 B. Collini-Nocker
University of Salzburg University of Salzburg
Extension Formats for Unidirectional Lightweight Encapsulation (ULE) Extension Formats for Unidirectional Lightweight Encapsulation (ULE)
and the Generic Stream Encapsulation (GSE) and the Generic Stream Encapsulation (GSE)
draft-ietf-ipdvb-ule-ext-02.txt draft-ietf-ipdvb-ule-ext-03.txt
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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
9. IPR Notices 9. IPR Notices
9.1 Intellectual Property Statement 9.1 Intellectual Property Statement
9.2 Disclaimer of Validity 9.2 Disclaimer of Validity
10. Copyright Statement 10. Copyright Statement
Appendix: The Second Generation DVB Transmission Specifications Appendix: The Second Generation DVB Transmission Specifications
1. Introduction 1. Introduction
This document describes three new Header Extensions that may be used This document describes three Header Extensions that may be used
with both Unidirectional Lightweight Encapsulation, ULE, [RFC4326] with both Unidirectional Lightweight Encapsulation, ULE, [RFC4326]
and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for
links that employ the MPEG-2 Transport Stream, and supports a wide links that employ the MPEG-2 Transport Stream, and supports a wide
variety of physical-layer bearers [RFC4259]. variety of physical-layer bearers [RFC4259].
GSE has been designed for the Generic Mode (also known as the GSE has been designed for the Generic Mode (also known as the
Generic Stream (GS)), offered by second-generation DVB physical Generic Stream (GS)), offered by second-generation DVB physical
layers, and in the first instance for DVB-S2 [ETSI-S2]. The layers, and in the first instance for DVB-S2 [ETSI-S2]. The
requirements for the Generic Stream are described in [ID-S2-REQ]. requirements for the Generic Stream are described in [ID-S2-REQ].
The important characteristics of this encapsulation are described in The important characteristics of this encapsulation are described in
skipping to change at page 6, line 15 skipping to change at page 6, line 15
3. Description of the Method 3. Description of the Method
In ULE, a Type field value that is less than 1536 Decimal indicates In ULE, a Type field value that is less than 1536 Decimal indicates
an Extension Header. This section describes a set of two extension an Extension Header. This section describes a set of two extension
formats for the ULE encapsulation. The GSE [GSE] follows the same formats for the ULE encapsulation. The GSE [GSE] follows the same
format as used in the ULE Type field. The encapsulation format format as used in the ULE Type field. The encapsulation format
differs in that GSE does not include a per-SNDU CRC, has different differs in that GSE does not include a per-SNDU CRC, has different
header flags, and utilises a different SNDU length calculation header flags, and utilises a different SNDU length calculation
[GSE]. [GSE].
There is a natural ordering of Extension Headers, which is
determined by the fields that they are associated with. A suitable
ordering for many applications is presented in the list below (from
first to last header within an SNDU). This does not imply that all
types of Extensions should be present in a single SNDU. The
presented ordering may serve as a guideline for optimisation of
Receiver processing.
+----------------------------------+-------------------------------+
|Fields related to Extension Header| Example Extension Headers |
+----------------------------------+-------------------------------+
| Link framing and transmission | Timestamp Extension |
+----------------------------------+-------------------------------+
| Entire remaining SNDU Payload | Encryption Extension |
+----------------------------------+-------------------------------+
| Group of encapsulated PDUs | PDU-Concat or TS-Concat |
+-----------------------------------+------------------------------+
| Specific encapsulated PDU | IEEE-defined type |
| | Test or MAC bridging Extension|
+-----------------------------------+------------------------------+
Table 1: Recommended ordering of Extension Headers
3.1 MPEG-2 TS-Concat Extension 3.1 MPEG-2 TS-Concat Extension
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 0x0002 in hexadecimal. This is a Mandatory assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory
Next-Header Extension. Next-Header Extension.
The extension is used to transport one or more MPEG-2 TS Packets The extension is used to transport one 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 of the remainder of the payload SNDU is determined from the size of the remainder of the payload
following the MPEG-2 TS Extension Header. The number of TS Packets following the MPEG-2 TS Extension Header. The number of TS Packets
skipping to change at page 7, line 31 skipping to change at page 8, line 4
| TS-Packet 1 | | TS-Packet 1 |
= = = =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) | | TS-Packet 2 (if Length > 2*188) |
= = = =
| etc. | | etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00) Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00)
Fragmented GSE SNDUs are protected by a CRC-32 carried in the final
Note that fragmented GSE SNDUs are protected by a CRC-32 carried in fragment. The fields labelled S and E are defined by [GSE} and
the final fragment. The fields labelled S and E are defined by [GSE} contains control flags used by the GSE link layer. The Label Type
and contains control flags used by the GSE link layer. The Label field (LT) specifies the presence and format of the GSE label.
Type field (LT) specifies the presence and format of the GSE label.
In ULE, a value of D=1, is also permitted and indicates the absence In ULE, a value of D=1, is also permitted and indicates the absence
of a NPA address (Figure 3). A similar format is supported in GSE. of a NPA address (Figure 3). A similar format is supported in GSE.
0 1 2 3 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 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 = 0x0002 | |1| Length (15b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 | | TS-Packet 1 |
skipping to change at page 8, line 28 skipping to change at page 8, line 35
| (CRC-32) | | (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1) Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1)
This extension may be used to transport one or more MPEG-2 TS This extension may be used to transport one or more MPEG-2 TS
Packets of arbitrary content, interpreted according to [ISO-MPEG2]. Packets of arbitrary content, interpreted according to [ISO-MPEG2].
One expected use is for the transmission of MPEG-2 SI/PSI One expected use is for the transmission of MPEG-2 SI/PSI
signalling. signalling.
NULL TS Packets are not normally sent using this encapsulation. To Null TS Packets are not normally sent using this encapsulation. To
reduce transmission overhead and processing, an Encapsulator SHOULD reduce transmission overhead and processing, an Encapsulator SHOULD
specify a maximum period of time that it can wait before sending all specify a maximum period of time that it can wait before sending all
queued TS Packets. This is known as the TS Packing Threshold. This queued TS Packets. This is known as the TS Packing Threshold. This
value MUST be bounded and SHOULD be configurable in the value MUST be bounded and SHOULD be configurable in the
Encapsulator. A larger value can improve efficiency, but incurs Encapsulator. A larger value can improve efficiency, but incurs
higher jitter and could increase the probability of corruption. If higher jitter and could increase the probability of corruption. If
additional TS Packets are NOT received within the TS Packing additional TS Packets are NOT received within the TS Packing
Threshold, the Encapsulator MUST immediately send any queued TS Threshold, the Encapsulator MUST immediately send any queued TS
Packets. Packets.
skipping to change at page 9, line 15 skipping to change at page 9, line 23
3.2 PDU-Concat Extension 3.2 PDU-Concat Extension
The PDU-Concat Extension Header is specified by an IANA assigned H- The PDU-Concat Extension Header is specified by an IANA assigned H-
Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header
Extension. It enables a sequence of (usually short) PDUs to be sent Extension. It enables a sequence of (usually short) PDUs to be sent
within a single SNDU payload. within a 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 MAY be including each set of encapsulation headers. The base header MAY be
followed by one or more additional Extension Headers preceding the followed by one or more additional Extension Headers that precede
PDU-Concat Extension Header. These Extension Headers (e.g. a the PDU-Concat Extension Header. These Extension Headers (e.g. a
TimeStamp Extension) apply to the composite concatenated PDU. TimeStamp Extension) apply to the composite concatenated PDU.
The Extension Header also conatains a 16-bit ULE Type field The Extension Header also contains a 16-bit ULE Type field
describing the encapsulated PDU, CONCAT-PDU-Type. Although any Type describing the encapsulated PDU, CONCAT-PDU-Type. Although any Type
value specified in the ULE Next-Header Registry (including Extension value specified in the ULE Next-Header Registry (including Extension
Header Types) may be assigned to the encapsulated PDU, all Header Types) may be assigned to the encapsulated PDU (except the
concatenated PDUs MUST have a common ULE Type (i.e. all concatenated recursive use of a PDU-Concat type), all concatenated PDUs MUST have
PDUs passed by the network layer must be associated with the same a common ULE Type (i.e. all concatenated PDUs passed by the network
Type value). This simplifies the receiver design, and reduces the layer must be associated with the same Type value). This simplifies
transmission overhead for common use cases. the receiver design, and reduces the transmission overhead for
common use cases.
Each PDU is prefixed by its length in bytes (shown as PDU-Length in Each PDU is prefixed by its length in bytes (shown as PDU-Length in
the following diagrams). Encapsulated PDUs are of arbitrary length the following diagrams). Encapsulated PDUs are of arbitrary length
(in bytes) and are not necessarily aligned to 16-bit or 32-bit (in bytes) and are not necessarily aligned to 16-bit or 32-bit
boundaries within the SNDU (as shown in the figure). The most boundaries within the SNDU (as shown in the figure). The most
significant bit of the first byte is reserved, R, and this significant bit of the first byte is reserved, R, and this
specification requires that this MUST be set to zero. The length of specification requires that this MUST be set to zero. The length of
each PDU MUST be less than 32758 bytes, but will generally be much each PDU MUST be less than 32758 bytes, but will generally be much
smaller. smaller.
skipping to change at page 10, line 52 skipping to change at page 11, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-Length-2 (15b) | | |R| PDU-Length-2 (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 = = PDU-2 =
| | | |
More PDUs as required More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)_ Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)_
The value of D in the ULE header indicates whether a NPA/MAC address
The value of D in the ULE header idicates whether a NPA/MAC address
is in use [RFC4326]. A similar format is supported in GSE. is in use [RFC4326]. 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 = 0x0003 | |1| Length (15b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CONCAT-PDU-Type |R| PDU-Length-1 (15b) | | CONCAT-PDU-Type |R| PDU-Length-1 (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 = = PDU-1 =
| | | |
skipping to change at page 12, line 8 skipping to change at page 12, line 10
timestamp field to an SNDU. This is designed to support monitoring timestamp field to an SNDU. This is designed to support monitoring
and measurement of ULE performance over a link to indicate the and measurement of ULE performance over a link to indicate the
quality of an operational ULE link. This may be useful for GSE links quality of an operational ULE link. This may be useful for GSE links
(where significant complexity exists in the scheduling provided by (where significant complexity exists in the scheduling provided by
the lower layers). This extension may be (optionally) checked at the the lower layers). This extension may be (optionally) checked at the
Receiver. Receiver.
Possible uses of this extension include: Possible uses of this extension include:
* Validation of in-sequence ordering per Logical Channel, * Validation of in-sequence ordering per Logical Channel,
* Measurement of one-way delay (when synchronised with the sender) * Measurement of one-way delay (when synchronised with the sender),
* Measurement of PDU Jitter introduced by the link, * Measurement of PDU Jitter introduced by the link,
* PDU loss (with additional information from the sender). * PDU loss (with additional information from the sender).
The Timestamp Extension Header is specified by the IANA-assigned H- The Timestamp Extension Header is specified by the IANA-assigned H-
Type value of 257 decimal. This extension is an Optional Extension Type value of 257 decimal. This extension is an Optional Extension
Header ([RFC4326], Section 5). Header ([RFC4326], Section 5).
Figure 7 shows the format of this extension with a HLEN value of 3 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 indicating a timestamp of length 4B with a Type field (there is no
implied byte-alignment). implied byte-alignment).
skipping to change at page 12, line 34 skipping to change at page 12, line 36
| time stamp LO | Type | | time stamp LO | Type |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 7 The format of the 32-bit Timestamp Extension Header Figure 7 The format of the 32-bit Timestamp Extension Header
The extension carries a 32-bit value (time stamp HI plus time stamp The extension carries a 32-bit value (time stamp HI plus time stamp
LO). The specified resolution is 1 microsecond. The value therefore LO). The specified resolution is 1 microsecond. The value therefore
indicates the number of 1 microsecond ticks past the hour in indicates the number of 1 microsecond ticks past the hour in
Universal Time when the PDU was encapsulated. This value may be Universal Time when the PDU was encapsulated. This value may be
earlier than the time of transmission due for example to Packing, earlier than the time of transmission due for example to Packing,
queueing and other Encapsulator processing. The value is right- queuing and other Encapsulator processing. The value is right-
justified to the 32-bit field. Systems unable to insert timestamps justified to the 32-bit field. Systems unable to insert timestamps
at the specified resolution may use an arbitrary (and varying) value at the specified resolution may use an arbitrary (and varying) value
to pad the unused least-significant bits. to pad the unused least-significant bits.
The last two bytes carry a 16-bit Type field that indicates the type 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- of payload carried in the SNDU, or the presence of a further Next-
Header ([RFC4326], Section 4.4). Header ([RFC4326], Section 4.4).
This is an Optional Extension Header. Receivers SHOULD process the This is an Optional Extension Header. Receivers SHOULD process the
timestamp when the PDU is decapsulated. Receivers that do not timestamp when the PDU is decapsulated. Receivers that do not
implement, or do not wish to process, the Timestamp Extension MAY implement, or do not wish to process, the Timestamp Extension MAY
skip this extension and continue to process the remainder of the skip this extension and continue to process the remainder of the
SNDU, forwarding the encapsulated PDU. SNDU, forwarding the encapsulated PDU.
4.. IANA Considerations 4. 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 0x0002. header is defined by an IANA assigned H-Type value of 0x0002.
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 0x0003. header is defined by an IANA assigned H-Type value of 0x0003.
skipping to change at page 13, line 18 skipping to change at page 13, line 21
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 0x0003. header is defined by an IANA assigned H-Type value of 0x0003.
The Timestamp Extension is an Optional next-type Extension Header The Timestamp Extension is an Optional next-type Extension Header
specified in section 3.3 of this document. The value of this next- specified in section 3.3 of this document. The value of this next-
header is defined by an IANA assigned H-Type value of 257 decimal. header is defined by an IANA assigned H-Type value of 257 decimal.
This documents defines format for a HLEN value of 0x3. This documents defines format for a HLEN value of 0x3.
5. Acknowledgments 5. Acknowledgements
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 assistance offered by the members of the DVB-GBS ad hoc group on
DVB-S2 encapsulation, in particular contributions on DVB-S2 DVB-S2 encapsulation, in particular contributions on DVB-S2
transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie. transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie.
Juan Cantillo provided a significant contribution to the informative Juan Cantillo provided a significant contribution to the informative
annexe. The authors thank Christian Praehauser for his insight and annexe. The authors thank Christian Praehauser for his insight and
contribution on header extension processing issues. contribution on header extension processing issues.
6. Security Considerations 6. Security Considerations
skipping to change at page 14, line 51 skipping to change at page 15, line 4
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 Computer Sciences 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.cosy.sbg.ac.at/ Web: http://www.cosy.sbg.ac.at/
10. IPR Notices 9. IPR Notices
9.1 Intellectual Property Statement 9.1 Intellectual Property Statement
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
skipping to change at page 16, line 45 skipping to change at page 16, line 45
GSE provides functions that are equivalent to those of the GSE provides functions that are equivalent to those of the
Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It
supports the transmission of IP packets and other network-layer supports the transmission of IP packets and other network-layer
protocols. The network-layer interface resembles that of ULE, where protocols. The network-layer interface resembles that of ULE, where
it adopts common mechanisms for a Length field, a 16-bit Type field, it adopts common mechanisms for a Length field, a 16-bit Type field,
support for Extension Headers, and addressing using a 6-byte NPA and support for Extension Headers, and addressing using a 6-byte NPA and
a suppressed NPA address (functionally equivalent to D=1 in ULE). In a suppressed NPA address (functionally equivalent to D=1 in ULE). In
addition GSE also supports other addressing modes. It employs a CRC addition GSE also supports other addressing modes. It employs a CRC
method in which a CRC is placed at the end of a BBFrame, covering method in which a CRC is placed at the end of a BBFrame, covering
multiples SNDUs. This is a result of more advanced physical layer multiples SNDUs. This is a result of more advanced physical layer
coding and a larger link frame size differ than used by the MPEG-2 coding and a larger link frame size that differs to than used by the
TS. In some systems the CRC may be suppressed and replaced by cross- MPEG-2 TS. In some systems the CRC may be suppressed and replaced by
layer signalling from the physical layer. cross-layer signalling from the physical layer.
GSE also provides more flexible fragmentation at the interface to GSE also provides more flexible fragmentation at the interface to
the physical layer. This adapts the SNDUs to a variable-sized link- the physical layer. This adapts the SNDUs to a variable-sized link-
layer frame, and reflects the more complex requirements in terms of layer frame, and reflects the more complex requirements in terms of
fragmentation and assembly that arise when using point-to-multipoint fragmentation and assembly that arise when using point-to-multipoint
adaptive physical layers. adaptive physical layers.
[RFC EDITOR NOTE: [RFC EDITOR NOTE:
This section must be deleted prior to publication] This section must be deleted prior to publication]
skipping to change at page 17, line 51 skipping to change at page 17, line 51
Working Group Draft 01 Working Group Draft 01
Ammended text to follow IANA assignments for the codepoints. Ammended text to follow IANA assignments for the codepoints.
Added issues raised at ipdvb meeting by C Praehauser. Added issues raised at ipdvb meeting by C Praehauser.
Revised annexe with text from GSE Spec, J Cantillo, et al. Revised annexe with text from GSE Spec, J Cantillo, et al.
Revised wording to clarify corner cases. Revised wording to clarify corner cases.
Removed references to documents not in public domain. Removed references to documents not in public domain.
Updated conventions and abbreviations for consistency. Updated conventions and abbreviations for consistency.
Updated text referencing ULE. Updated text referencing ULE.
Working Group Draft 02
Added rules for Types of PDUs in PDU-Concat
Added appendix on DVB 2 nd generation
Added new text on timers to control concat (from list)
Working Group Draft 03
Added a table to the start of the method defining recommended
ordering
Fixed NiTs
[END of RFC EDITOR NOTE] [END of RFC EDITOR NOTE]
 End of changes. 18 change blocks. 
27 lines changed or deleted 59 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/