draft-ietf-ipdvb-ule-ext-05.txt   draft-ietf-ipdvb-ule-ext-06.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Proposed Standard B. Collini-Nocker Intended status: Proposed Standard B. Collini-Nocker
Expires: April 2007 University of Salzburg Expires: April 2007 University of Salzburg
October 19, 2007 November 05, 2007
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-05.txt draft-ietf-ipdvb-ule-ext-06.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 38 skipping to change at page 3, line 38
2 control plane. 2 control 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
the same ULE SNDU. This method is designed for cases where a large the same ULE SNDU. This method is designed for cases where a large
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.
A third Extension Header provides an optional timestamp value for an A third Extension Header provides an optional timestamp value for an
SNDU. Examples of the use of this timestamp option include SNDU. Examples of the use of this timestamp option include
monitoring and benchmarking of ULE and GSE links. Receivers that do monitoring and benchmarking of ULE and GSE links. Receivers that do
not wish to decode (or do not support) the timestamp extension may not wish to decode (or do not support) the timestamp extension may
discard the extension and process the remaining PDU or Extension discard the extension and process the remaining PDU or Extension
Headers. Headers.
An appendix includes a summary of key design issues and An appendix includes a summary of key design issues and
considerations based on the GSE Specification defined by the DVB considerations relating to 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC2119]. RFC 2119 [RFC2119].
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: The data field part of a Baseband frame [ETSI-S2]
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 FEC in use. modulation format and FEC in use.
DVB: Digital Video Broadcasting. A framework and set of associated DVB: Digital Video Broadcasting. A framework and set of associated
standards published by the European Telecommunications Standards standards published by the European Telecommunications Standards
Institute (ETSI) for the transmission of video, audio, and data. Institute (ETSI) for the transmission of video, audio, and data.
E: A one-bit flag field defined in [GSE]. E: A one-bit flag field defined in GSE [GSE].
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 [RFC4259].
GS: Generic Stream [ETSI-S2]. A stream of BBFrames identified by a GS: Generic Stream. A stream of BBFrames identified by a common
common Input Stream Identifier, and which does not use the MPEG-2 TS Input Stream Identifier, and which does not use the MPEG-2 TS
format. It represents layer 2 of the ISO/OSI reference model. format [ETSI-S2]. It represents layer 2 of the ISO/OSI reference
model.
GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating
PDUs to form a Generic Stream, which is sent using a sequence of PDUs to form a Generic Stream, which is sent using a sequence of
BBFrames. This encapsulation format shares the same extension BBFrames. This encapsulation format shares the same extension
format, and basic processing rules of ULE and uses a common IANA format, and basic processing rules of ULE and uses a common IANA
Registry. Registry.
LT: A two-bit flag field defined in [GSE]. LT: A two-bit flag field defined in GSE [GSE].
MAC: Medium Access Control [IEEE-802.3]. A link layer protocol MAC: Medium Access Control [IEEE-802.3]. A link layer protocol
defined by the IEEE 802.3 standard (or by Ethernet v2). defined by the IEEE 802.3 standard (or by Ethernet v2).
MPEG-2: A set of standards specified by the Motion Picture Experts MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards Group (MPEG), and standardized by the International Standards
Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220). Organisation (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
Next-Header: A Type value indicating an Extension Header [RFC4326]. Next-Header: A Type value indicating an Extension Header [RFC4326].
NPA: Network Point of Attachment [RFC4326]. In this document, refers NPA: Network Point of Attachment [RFC4326]. In this document, refers
to a destination address (resembling an IEEE MAC address) within the to a destination address (resembling an IEEE MAC address) within the
DVB-S/S2 transmission network that is used to identify individual DVB-S/S2 transmission network that is used to identify individual
Receivers or groups of Receivers. Receivers or groups of Receivers.
PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the
header of each TS Packet. This identifies the TS Logical Channel to header of each TS Packet. This identifies the TS Logical Channel to
which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the
parts of a Table Section, or other Payload Unit must all carry the parts of a Table Section, or other Payload Unit must all carry the
same PID value. The all ones PID value indicates a Null TS Packet same PID value. The all ones PID value indicates a Null TS Packet
introduced to maintain a constant bit rate of a TS Multiplex. There introduced to maintain a constant bit rate of a TS Multiplex. There
is no required relationship between the PID values used for TS is no required relationship between the PID values used for TS
Logical Channels transmitted using different TS Multiplexes. Logical Channels transmitted using different TS Multiplexes.
PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include
Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PSI: Program Specific Information [ISO-MPEG2]. PSI: Program Specific Information [ISO-MPEG2].
S: A one-bit flag field defined in [GSE]. S: A one-bit flag field defined in [GSE].
SI Table: Service Information Table [ISO-MPEG2]. In this document, SI Table: Service Information Table [ISO-MPEG2]. In this document,
this term describes a table that is been defined by another this term describes a table that is been defined by another
standards body to convey information about the services carried on a standards body to convey information about the services carried on a
DVB Multiplex. DVB Multiplex.
SNDU: SubNetwork Data Unit [RFC4259]. In this document this is an SNDU: SubNetwork Data Unit [RFC4259]. In this document, this is an
encapsulated PDU sent using ULE or GSE. encapsulated PDU sent using ULE or GSE.
Stream: A logical flow from an Encapsulator to a set of Receivers. Stream: A logical flow from an Encapsulator to a set of Receivers.
TS: Transport Stream [ISO-MPEG2], a method of transmission at the TS: Transport Stream [ISO-MPEG2], a method of transmission at the
MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI
reference model. reference model.
ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A
method that encapsulates PDUs, into SNDUs that are sent in a series method that encapsulates PDUs, into SNDUs that are sent in a series
of TS Packets using a single TS Logical Channel. The encapsulation of TS Packets using a single TS Logical Channel. The encapsulation
defines an extension format and an associated IANA Registry. defines an extension format and an associated IANA Registry.
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 three an Extension Header. This section describes a set of three
extension formats for the ULE encapsulation. [GSE] uses a Type field extension formats for the ULE encapsulation. [GSE] uses a Type field
that adopts the same semantics as specified by RFC 4326. The that adopts the same semantics as specified by RFC 4326. The
encapsulation format differs in that GSE does not include a per-SNDU encapsulation format differs in that GSE does not include a CRC for
CRC, has different header flags, and utilises a different SNDU each SNDU, has different header flags, and utilises a different SNDU
length calculation [GSE]. length calculation [GSE].
There is a natural ordering of extension headers, which is There is a natural ordering of extension headers, which is
determined by the fields upon which the extension header operates. A determined by the fields upon which the extension header operates. A
suitable ordering for many applications is presented in the list suitable ordering for many applications is presented in the list
below (from first to last header within an SNDU). This does not below (from first to last header within an SNDU). This does not
imply that all types of Extensions should be present in a single imply that all types of Extensions should be present in a single
SNDU. The presented ordering may serve as a guideline for SNDU. The presented ordering may serve as a guideline for
optimisation of Receiver processing. optimisation of Receiver processing.
+----------------------------------+-------------------------------+ +----------------------------------+-------------------------------+
|Fields related to Extension Header| Example Extension Headers | |Fields related to Extension Header| Example Extension Headers |
skipping to change at page 6, line 52 skipping to change at page 6, line 53
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
contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N
is the number of bytes associated with Extension Headers that is the number of bytes associated with Extension Headers that
precede the MPEG-2 TS-Concat Extension (zero if there are none). precede the MPEG-2 TS-Concat Extension (zero if there are none).
A Receiver MUST check the validity of the Length value prior to A Receiver MUST check the validity of the Length value prior to
processing the payload. A valid Length contains an integral number processing the payload. A valid Length corresponds to an integral
of TS Packets. An invalid Length (a remainder from the division by number of TS Packets. An invalid Length (a remainder from the
188) MUST result in the discard of all encapsulated TS Packets and division by 188) MUST result in the discard of all encapsulated
SHOULD be recorded as TS-Concat size mismatch error. TS Packets and SHOULD be recorded as TS-Concat size mismatch error.
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 = 0x0002 | |0| Length (15b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 | | TS-Packet 1 |
skipping to change at page 8, line 36 skipping to change at page 8, line 36
| etc. | | etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (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. signaling [RFC4259].
NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this
encapsulation. To reduce transmission overhead and processing, an encapsulation. To reduce transmission overhead and processing, an
Encapsulator SHOULD specify a maximum period of time that it can Encapsulator SHOULD specify a maximum period of time that it can
wait before sending all queued TS Packets. This is known as the TS wait before sending all queued TS Packets. This is known as the TS
Packing Threshold. This value MUST be bounded and SHOULD be Packing Threshold. This value MUST be bounded and SHOULD be
configurable in the Encapsulator. A larger value can improve configurable in the Encapsulator. A larger value can improve
efficiency, but incurs higher jitter and could increase the efficiency, but incurs higher jitter and could increase the
probability of corruption. If additional TS Packets are NOT received probability of corruption. If additional TS Packets are NOT received
within the TS Packing Threshold, the Encapsulator MUST immediately within the TS Packing Threshold, the Encapsulator MUST immediately
skipping to change at page 9, line 53 skipping to change at page 9, line 53
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. Receivers MUST specification requires that this MUST be set to zero. Receivers MUST
ignore the value of the R bit. The length of each PDU MUST be less ignore the value of the R bit. The length of each PDU MUST be less
than 32758 bytes, but will generally be much smaller. than 32758 bytes, but will generally be much smaller.
When the SNDU header indicates the presence of an SNDU Destination When the SNDU header indicates the presence of an SNDU Destination
Address field (i.e. D=0 in ULE), a Network Point of Attachment, NPA, Address field (i.e. D=0 in ULE), a Network Point of Attachment, NPA,
field directly follows the fourth byte of the SNDU header. NPA field directly follows the fourth byte of the SNDU header. NPA
destination addresses are 6 Byte numbers, normally expressed in destination addresses are 6 Byte numbers, normally expressed in
hexadecimal, used to identify the Receiver(s) in a transmission hexadecimal, used to identify the Receiver(s) in a transmission
network that should process a received SNDU. When present the network that should process a received SNDU. When present, the
Receiver MUST associate the same specified MAC/NPA address with all Receiver MUST associate the same specified MAC/NPA address with all
PDUs within the SNDU Payload. This MAC/NPA address MUST also be PDUs within the SNDU Payload. This MAC/NPA address MUST also be
forwarded with each PDU, if required by the forwarding interface. forwarded with each PDU, if required by the forwarding interface.
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 = 0x0003 | |0| Length (15b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) | | Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 41 skipping to change at page 12, line 41
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| 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,
queuing 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).
Receivers MAY process the timestamp when the PDU encapsulation is Receivers MAY process the timestamp when the PDU encapsulation is
skipping to change at page 14, line 24 skipping to change at page 14, line 24
7.1 Normative References 7.1 Normative References
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997. Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP datagrams Lightweight Encapsulation (ULE) for transmission of IP datagrams
over an MPEG-2 Transport Stream", RFC 4326, December 2005. over an MPEG-2 Transport Stream", RFC 4326, December 2005.
[GSE] "Generic Stream Encapsulation", DVB Document A116, DVB [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream
Technical Module (GBS Group), May 2007. Encapsulation (GSE) Protocol, "European Telecommunication Standards
Institute (ETSI).
7.2 Informative References 7.2 Informative References
[ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second [ETSI-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).
[ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB- [ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB-
skipping to change at page 16, line 8 skipping to change at page 16, line 8
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.
[RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution [RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution
Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July
2007. 2007.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
School of Engineering School 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
URI: http://www.erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk
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
URI: http://www.cosy.sbg.ac.at URI: http://www.cosy.sbg.ac.at
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
skipping to change at page 18, line 7 skipping to change at page 18, line 7
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
APPENDIX: The Second Generation DVB Transmission Specifications APPENDIX: The Second Generation DVB Transmission Specifications
This section provides informative background to the network layer This section provides informative background to the network-layer
requirements of the second generation DVB Transmission requirements of the second generation DVB Transmission
Specifications. The second generation waveforms specified by the Specifications. The second generation waveforms specified by the
Digital Video Broadcasting project offer two main enhancements. Digital Video Broadcasting project offer two main enhancements.
First, more efficient physical layer methods that employ higher First, more efficient physical layer methods that employ higher
order modulation with stronger FEC and permit adaptive coding and order modulation with stronger FEC and permit adaptive coding and
modulation response to changes in traffic and propagation modulation response to changes in traffic and propagation
conditions. Second, at the link layer, they offer greater conditions. Second, at the link layer, they offer greater
flexibility in framing. Support is provided for a range of stream flexibility in framing. Support is provided for a range of stream
formats including the classical Transport Stream (TS) [RFC4259]. In formats including the classical Transport Stream (TS) [RFC4259]. In
addition, a new method called Generic Streams (GS) (or the Generic addition, a new method called Generic Streams (GS) (or the Generic
skipping to change at page 20, line 10 skipping to change at page 20, line 10
Added rules for Types of PDUs in PDU-Concat. Added rules for Types of PDUs in PDU-Concat.
Added appendix on DVB 2 nd generation. Added appendix on DVB 2 nd generation.
Added new text on timers to control concat (from list). Added new text on timers to control concat (from list).
Working Group Draft 03 Working Group Draft 03
Added a table to the start of the method defining recommended. Added a table to the start of the method defining recommended.
Fixed NiTs. Fixed NiTs.
Working Group Draft 04 Draft Working Group Draft 04
Editorial changes to prepare the document for WGLC. Editorial changes to prepare the document for WGLC.
Updated IANA section to comply with RFC4326 IANA Guidelines. Updated IANA section to comply with RFC4326 IANA Guidelines.
Reduced Security considerations section by reference to other Reduced Security considerations section by reference to other
documents that give a fuller discussion. documents that give a fuller discussion.
There were no intentional changes to the protocol specification. There were no intentional changes to the protocol specification.
Working Group Draft 06
Addressed review comments.
Working Group Draft 06
Updated reference to GSE (now an ETSI Spec) - This spec has a
normative reference to the current document.
Minor editorial corrections to English
[END of RFC EDITOR NOTE] [END of RFC EDITOR NOTE]
 End of changes. 25 change blocks. 
35 lines changed or deleted 47 lines changed or added

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