One document matched: draft-fairhurst-ipdvb-ule-ext-00.txt
Internet Engineering Task Force Gorry Fairhurst
Internet Draft University of Aberdeen
Document: draft-fairhurst-ipdvb-ule-ext-00.txt
Category: Draft June 2006
Extension Formats for the ULE Encapsulation
to support the Generic Stream Encapsulation (GSE)
Status of this Draft
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a set of Extension Headers. For the
Unidirectional Lightweight Encapsulation (ULE).
The Extension Header formats defined in this document provide new
extensions that are common extensions to both ULE and the Generic
Stream Encapsulation (GSE) defined by the second generation framing
structure DVB-S2 standard (Channel coding and modulation systems for
Broadcasting, Interactive Services, News Gathering and other
broadband satellite applications).
Expires December 2006 [page 1]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
Expires June 2006 [page 2]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
Table of Contents
1. Introduction
2. Conventions used in this document
3. Description of method
4. Summary
5. IANA Considerations
6. Acknowledgments
7. Security Considerations
8. References
8.1 Normative References
8.2 Informative References
9. Authors' Addresses
10. IPR Notices
10.1 Intellectual Property Statement
10.2 Disclaimer of Validity
11. Copyright Statement
11.1 Intellectual Property Statement
11.2 Disclaimer of Validity
Appendix A:
Expires June 2006 [page 3]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
1. Introduction
This document describes a set of Header Extensions for ULE [RFC4236]
over the MPEG-2 Transport-Stream. The methods are also applicable to
a link that uses the physical layer specified by DVB-S2 [ETSI-S2] in
the Generic Mode (also known as the Generic Stream (GS)). The
Generic Stream Encapsulation (GSE) [GSE] is currently a work item of
the DVB-TM. The requirements for the Generic Stream are defined in
[S2-REQ], [S2-REQ-RCS], and [ID-S2-REQ]. GSE maintains a design
philosophy that presents a similar network interface to that of ULE
and uses a similar construction for SNDUs. The important
characteristics of this encapsulation are described in an Appendix
to this document.
The approaches seek to define well-founded methods that may be used
with both ULE and GSE. This will present the same network layer
interface over both physical layers.
One method allows one or more TS-Packets [ISO-MPEG] to be sent
within a ULE SNDU. In GSE this method may be used to provide then
control plane information including the transmission of MPEG-2
Program Specific Information (PSI) for the Multiplex.
A second method allows one or more PDUs to be sent within 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 Attachment
(NPA) address. The method may improve transmission efficiency (by
removing duplicated MAC layer overhead). It can also reduce
processing overhead for receivers that are not addressed by the NPA,
since these receivers may then skip several PDUs in one operation.
The method is defined as a generic extension header and 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 in
combination with this method.
Future versions of this document are expected to provide
recommendations on the interface between the Generic Stream
Encapsulation (GSE) and the Internet Protocol Stack.
The appendix is also expected to be enhanced to include a summary of
key design issues and considerations based on the GSE Specification
defined by the DVB-TM (e.g. [ID-S2-REQ]).
Expires June 2006 [page 4]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC2119].
b: bit. For example, one byte consists of 8b.
B: Byte. Groups of bytes are represented in Internet byte order.
BBFrame payload [ETSI-S2]: The data field part of a Baseband frame
that may be used for the communication of data. Typical BBFrames
range in size from 3072 to 58192 bits according to the choice of
modulation format and FEC in use.
DVB: Digital Video Broadcast. A framework and set of
associated standards published by the European Telecommunications
Standards Institute (ETSI) for the transmission of video, audio, and
data.
Encapsulator: A network device that receives PDUs and formats these
into Payload Units (known here as SNDUs) for output in the Generic
Mode of DVB-S2.
GS: Generic Stream.
GSE: Generic Stream Encapsulation.
MAC: Medium Access Control [IEEE-802.3]. A link layer protocol
defined by the IEEE 802.3 standard (or by Ethernet v2).
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards
Organisation (ISO/IEC 113818-1) [ISO-MPEG], and ITU-T (in H.220).
Next-Header: A Type value indicating an Extension Header [RFC4236].
NPA: Network Point of Attachment [RFC4236]. In this document, refers
to a destination address (resembling an IEEE MAC address) within the
DVB-S2 transmission network that is used to identify individual
Receivers or groups of Receivers.
PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include
Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PSI: Programme Specific Information [ISO-MPEG].
SI Table: Service Information Table [ISO-MPEG]. In this document,
this term describes a table that is been defined by another
standards body to convey information about the services carried in a
Expires June 2006 [page 5]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
SNDU: Subnetwork Data Unit [RFC4259]. In this document this is an
encapsulated PDU sent using GSE.
Stream: A logical flow from an Encapsulator to a set of Receivers.
The addresses at the MAC/NPA level and IP level need to be unique
within a specific stream (i.e. denoted by a common S.2 ISI value).
TS: Transport Stream [ISO-MPEG], a method of transmission at the
MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI
reference model.
ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4236]. A
scheme that encapsulates PDUs, into SNDUs that are sent in a series
of TS Packets using a single TS Logical Channel. The encapsulation
format defined by this document shares the same extension format,
and basic processing rules and uses a common IANA Registry.
Expires June 2006 [page 6]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
3. Description of the Method
In ULE, a Type field value less than 1536 Decimal indicates an
Extension Header. This section describes a set of two extension
formats for the ULE encapsulation.
3.1 MPEG-2 TS-Concat Extension
The MPEG-2 TS-Concat Extension Header is specified by an IANA
assigned H-Type value of <tbd>. This is a Mandatory Next-Header
Extension.
The extension is used to communicate 1 or more MPEG-2 TS Packets
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
Payload following the MPEG-2 TS Extension. A Receiver MUST silently
discard any data, if present, between the last complete encapsulated
MPEG-2 TS Packet and the size denoted in the Length field of the
SNDU fragment base header.
A value of D=1 indicates there is no NPA/MAC address in use. A value
D=0 is also permitted, as defined in ULE.
The extension may be used to communicate one or more MPEG-2 TS
Packets of arbitrary content, interpreted according to [ISO-MPEG].
One expected use is for the transmission of MPEG-2 SI/PSI signalling
and clock references over the ULE framing.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0xtbd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SNDU Format for a TS-Packet Payload (D=1)
Expires June 2006 [page 7]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0xtbd-concat |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SNDU Format for a TS-Packet Payload (D=0)
3.2 PDU-Concat Extension
The PDU-Concat Extension is specified by an IANA assigned H-Type
value of <tbd>. This is a Mandatory Next-Header Extension. It
enables a sequence of (usually short) PDUs to be sent within a
single SNDU payload.
The base header contains the Length of the entire SNDU. This is set
to the combined length of all PDUs to be encapsulated, including
each set of encapsulation headers.
Each PDU is prefixed by its length in bytes (shown as PDU-Length in
the following diagrams) and a 16-bit ULE Type field. The most
significant bit of the first byte MUST must be set to zero. The
length of each PDU MUST be less than 32 768 bytes. The Type field
(shown as PDU-Type in the following figures) may be any ULE-
specified Type.
The Receiver processes this Extension Header by extracting each PDU
in turn. The Receiver first verifies the Length of each PDU, and
ensures the sum of the Lengths of all processed PDUs is less than
the Length specified in the SNDU base header. A Receiver MUST
silently discard any data, if present, after the last complete
encapsulated PDU.
Expires June 2006 [page 8]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0xtbd-concat |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PDU-Length (15b) | PDU-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| PDU-Length (15b) | PDU-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SNDU Format for a PDU-Concat Payload (D=1)
A value of D=1 indicates there is no NPA/MAC address in use.
This field MUST be carried (i.e. D=0) for IP unicast packets
destined to routers that are sent using shared links (i.e., where
the same link connects multiple Receivers). A sender MAY omit this
field (D=1) for 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 destination address, or a bridged MAC destination
address), which in combination with the PID value, could be
interpreted as a Link-Level address.
When the SNDU header indicates the presence of an SNDU Destination
Address field (i.e. D=0), a Network Point of Attachment, NPA, field
directly follows the fourth byte of the SNDU header. NPA destination
addresses are 6 Byte numbers, normally expressed in hexadecimal,
used to identify the Receiver(s) in a transmission network that
should process a received SNDU. When present the Receiver MUST
associate the same specified MAC/NPA address with all PDUs within
the SNDU Payload. This MAC/NPA address MUST also be forwarded with
each PDU, if required by the forwarding interface.
Expires June 2006 [page 9]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0xtbd-concat |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ||0| Length (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frag-Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Frag-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SNDU Format for a PDU-Concat Payload (D=1)
4. Summary
This document defines a set of Next_Header options for the
Unidirectional Lightweight Encapsulation (ULE).
5. IANA Considerations
This document will require IANA involvement for the assignment of
two new Next-Header Type values from the IANA ULE Next-Header
Registry. These options are defined for specific use cases envisaged
by GSE, but are compatible with ULE.
The TS-Concat Extension is a Mandatory next-type extension header,
specified in section 3.1 of this document. The value of this next-
header is defined by an IANA assigned H-Type value of <tbd>.
The PDU-Concat Extension is a Mandatory next-type extension header
specified in section 3.2 of this document. The value of this next-
header is defined by an IANA assigned H-Type value of <tbd>.
6. Acknowledgments
The author gratefully acknowledges the inputs, comments and
assistance offered by the members of the DVB-GBS ad hoc group on S2
Expires June 2006 [page 10]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
encapsulation, in particular contributions on networking aspects
from Axel Jahn, Ulrik De Bie, and Bernhard Collini-Nocker..
7. Security Considerations
No specific security issues are raised within this document.
Additional security control fields may be provided as a part of a
link encryption Extension Header, e.g. to associate a PFU with one
of a set of Security Association (SA) parameters. As a part of the
encryption process, it may also be desirable to authenticate
some/all of the headers. The method of encryption and the way in
which keys are exchanged is beyond the scope of this specification,
as also are the definition of the SA format and that of the related
encryption keys.
8. References
8.1 Normative References
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC4236] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP datagrams
over an MPEG-2 Transport Stream", RFC 4236, December 2006.
8.2 Informative References
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting",
European Telecommunications Standards Institute (ETSI).
[ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second
generation framing structure, channel coding and modulation systems
for Broadcasting, Interactive Services, News Gathering and other
broadband satellite applications", European Telecommunication
Standards Institute (ETSI).
[GSE] "Generic Stream Encapsulation", Work in Progress, DVB
Technical Module (GBS Group), 2006.
[ID-S2-REQ] "Requirements for transmission of IP datagrams over DVB-
S2", Internet Draft <draft-cantillo-ipdvb-s2encaps-01.rxr>, Work in
Progress.
[ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio Information
Systems", International Standards Organisation (ISO).
Expires June 2006 [page 11]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
[RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-
Nocker, B., and H. Linder, "A Framework for Transmission of IP
Datagrams over MPEG-2 Networks", RFC 4259, November 2006.
[S2-Eval] "Procedure for Comparative Evaluation of IP/DVB-S2
Encapsulation Protocol over Generic Streams", Technical Note, Work
in Progress, DVB TM-GBS.
[S2-REQ] GBS0339, "Functional and performance requirements for
IP/S2", DVB-TM GBS WG.
[S2-REQ-RCS] "Requirements for S2", Document 529r1, DVB Technical
Module (RCS WG).
9. Authors' Addresses
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/Gorry
10. IPR Notices
10.1 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Expires June 2006 [page 12]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
10.2 Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Copyright Statement
Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
[RFC EDITOR NOTE:
This section must be deleted prior to publication]
DOCUMENT HISTORY
Draft 00
This draft complements a study item in the DVB-GBS in this area to
define a Generic Stream Encapsulation (GSE). Comments relating to
this document will be gratefully received by the author(s) and may
also be sent to ip-dvb mailing list at: ip-dvb@erg.abdn.ac.uk
[END of RFC EDITOR NOTE]
Expires June 2006 [page 13]
INTERNET DRAFT Extension Formats for the ULE Encapsulation Jun 2006
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.
Expires June 2006 [page 14] | PAFTECH AB 2003-2026 | 2026-04-23 11:02:17 |