draft-ietf-ipdvb-ule-ext-04.txt   draft-ietf-ipdvb-ule-ext-05.txt 
Internet Engineering Task Force Gorry Fairhurst Internet Engineering Task Force G. Fairhurst
Internet Draft University of Aberdeen Internet-Draft University of Aberdeen
Expires February 2008 B. Collini-Nocker Intended status: Proposed Standard B. Collini-Nocker
University of Salzburg Expires: April 2007 University of Salzburg
October 19, 2007
Category: WG Draft intended for PS August 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-04.txt draft-ietf-ipdvb-ule-ext-05.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 2, line 26 skipping to change at page 2, line 26
4. IANA Considerations 4. IANA Considerations
5. Acknowledgements 5. Acknowledgements
6. Security Considerations 6. Security Considerations
7. References 7. References
7.1 Normative References 7.1 Normative References
7.2 Informative References 7.2 Informative References
8. Authors' Addresses Authors' Addresses
9. IPR Notices
9.1 Intellectual Property Statement
9.2 Disclaimer of Validity
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 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].
skipping to change at page 8, line 5 skipping to change at page 8, line 5
= = = =
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Fragmented GSE SNDUs are protected by a CRC-32 carried in the final
fragment. After defragmentation, this CRC-32 is removed and the fragment. After reassembly, this CRC-32 is removed and the resulting
resulting SNDU carries a Total Length field. The fields labelled S SNDU carries a Total Length field. The fields labelled S and E are
and E are defined by [GSE] and contain control flags used by the GSE defined by [GSE] and contain control flags used by the GSE link
link layer. The Label Type field (LT) specifies the presence and layer. The Label Type field (LT) specifies the presence and format
format of the GSE label. The LT field is only specified for the of the GSE label. The LT field is only specified for the first
first fragment (or an unfragmented) GSE SNDU (i.e. when S=1). fragment (or a non-fragmented) GSE SNDU (i.e. when S=1).
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 9, line 13 skipping to change at page 9, line 13
operation may be simplified in GSE by ensuring that all SNDUs that operation may be simplified in GSE by ensuring that all SNDUs that
carry this Extension Header are placed before other data within the carry this Extension Header are placed before other data within the
BBFrame DataField [GSE]. BBFrame DataField [GSE].
This document does not specify how TS Packets are to be handled at This document does not specify how TS Packets are to be handled at
the Receiver, however it notes that a poorly configured Encapsulator the Receiver, however it notes that a poorly configured Encapsulator
could lead to a Multiplex carrying multiple (possibly conflicting) could lead to a Multiplex carrying multiple (possibly conflicting)
sets of TS Logical Channels and SI information encapsulated at sets of TS Logical Channels and SI information encapsulated at
different levels or with different NPA addresses. The need for different levels or with different NPA addresses. The need for
consistency in the use of PIDs and the related SI information is consistency in the use of PIDs and the related SI information is
described in [RFCxARx]. described in [RFC4947].
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,
skipping to change at page 12, line 51 skipping to change at page 12, line 51
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 Optional Extension Header timestamp Receivers MAY process the timestamp when the PDU encapsulation is
when the PDU is decapsulated. Receivers that do not implement, removed. Receivers that do not implement, or do not wish to process,
or do not wish to process, the Timestamp Extension MAY skip this the Timestamp Extension MAY skip this extension header. Receivers
extension header. Receivers MUST continue to process the remainder MUST continue to process the remainder of the SNDU, forwarding the
of the SNDU, forwarding the encapsulated PDU. encapsulated PDU.
4. IANA Considerations 4. IANA Considerations
This document requires IANA involvement for the assignment of three This document requires IANA involvement for the assignment of three
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 following assignments have been made in this document, and The following assignments have been made in this document, and
registered by IANA: registered by IANA:
skipping to change at page 14, line 36 skipping to change at page 14, line 36
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-
S2", Internet Draft <draft-cantillo-ipdvb-s2encaps-01.txt>, Work in S2", Internet-Draft <draft-cantillo-ipdvb-s2encaps-01.txt>, Work in
Progress. Progress.
[ID-Sec-Req] "Security requirements for the Unidirectional [ID-Sec-Req] "Security requirements for the Unidirectional
Lightweight Encapsulation (ULE) protocol", Internet Draft < draft- Lightweight Encapsulation (ULE) protocol", Internet-Draft < draft-
ietf-ipdvb-sec-req-03.txt>, Work in Progress. ietf-ipdvb-sec-req-04.txt>, Work in Progress.
[IEEE-802.3] "Local and metropolitan area networks - Specific [IEEE-802.3] "Local and metropolitan area networks - Specific
requirements Part 3: Carrier sense multiple access with collision requirements Part 3: Carrier sense multiple access with collision
detection (CSMA/CD) access method and physical layer detection (CSMA/CD) access method and physical layer
specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC
8802-3), 2002. 8802-3), 2002.
[ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology; [ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio Information Generic Coding of Moving Pictures and Associated Audio Information
Systems", International Standards Organisation (ISO). Systems", International Standards Organisation (ISO).
[RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini- [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-
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.
[RFCxARx] Montpetit, M.-J., Fairhurst, G., "Address Resolution [RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution
Mechanisms for IP Datagrams over MPEG-2 Networks", RFC Ed Queue, Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July
<draft-ietf-ipdvb-ar-xx.txt>, 2007. 2007.
8. Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
Department 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
Web: http://www.erg.abdn.ac.uk/users/Gorry 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
Web: http://www.cosy.sbg.ac.at/ URI: http://www.cosy.sbg.ac.at
9. IPR Notices Full Copyright Statement
9.1 Intellectual Property Statement 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.
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.
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
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
skipping to change at page 16, line 9 skipping to change at page 17, line 45
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.
9.2 Disclaimer of Validity Copyright Statement
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. 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
skipping to change at page 17, line 33 skipping to change at page 18, line 33
For example, the DVB-S2 [ETSI-S2] transmission link sequentially For example, the DVB-S2 [ETSI-S2] transmission link sequentially
multiplexes a series of baseband frames (BBFrames). Each BBFrame multiplexes a series of baseband frames (BBFrames). Each BBFrame
comprises a fixed-size 10B header and a payload. The payload carries comprises a fixed-size 10B header and a payload. The payload carries
a DataField and uses padding to fill any unused space. A stream a DataField and uses padding to fill any unused space. A stream
comprises a sequence of BBFrames associated with an Input Stream comprises a sequence of BBFrames associated with an Input Stream
Identifier (ISI) that is carried in the header of each BBFrame. The Identifier (ISI) that is carried in the header of each BBFrame. The
simplest scheme uses a single stream (with just one ISI value), but simplest scheme uses a single stream (with just one ISI value), but
multiple streams are permitted. The BBFrames forming a stream may be multiple streams are permitted. The BBFrames forming a stream may be
of variable size (selected from a set of allowed sizes), and must of variable size (selected from a set of allowed sizes), and must
use the same stream format (e.g. TS or GSE). Each stream represents use the same stream format (e.g. TS or GSE). Each stream represents
an independent link with independent address resolution [RFCxARx]. an independent link with independent address resolution [RFC4947].
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,
and support for Extension Headers. As in ULE, GSE permits multiple and support for Extension Headers. As in ULE, GSE permits multiple
address formats, indicated by the LT field (functionally equivalent address formats, indicated by the LT field (functionally equivalent
to the D field in ULE). The default addressing mode uses a 6-byte to the D field in ULE). The default addressing mode uses a 6-byte
NPA and a suppressed NPA address (functionally equivalent to D=1 in NPA and a suppressed NPA address (functionally equivalent to D=1 in
skipping to change at page 18, line 14 skipping to change at page 19, line 14
[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.
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
all concatenated PDUs MUST have the same Type. all concatenated PDUs MUST have the same Type.
Future versions of this draft may define additional Extension Future versions of this draft may define additional Extension
Headers, proposals and ideas are welcome via the IETF ipdvb mailing Headers, proposals and ideas are welcome via the IETF ipdvb mailing
skipping to change at page 18, line 43 skipping to change at page 19, line 43
Working Group Draft 01 Working Group Draft 01
Corrected contact info for Bernhard. Corrected contact info for Bernhard.
Added TimeStamp Options Added TimeStamp Options
Corrected NITS in draft Corrected NITS in draft
Working Group Draft 01 Working Group Draft 01
Amended diagrams and text to follow tentative IANA assignments for Amended diagrams and text to follow tentative IANA assignments for
the codepoints. the codepoints.
Working Group Draft 01 Working Group Draft 01
Ammended text to follow IANA assignments for the codepoints. Amended 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 appendix 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 Working Group Draft 02
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).
 End of changes. 22 change blocks. 
55 lines changed or deleted 52 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/