7.3. Other Error Conditions
The Receiver SHOULD check the MPEG-2 Transport Error Indicator
carried in the TS Packet header [ISO-MPEG2]. This flag indicates a
transmission error for a TS Logical Channel. If the flag is set to a
value of one, a transmission error event SHOULD be recorded. Any
partially received SNDU MUST be discarded. The Receiver then enters
the Idle State.
The Receiver MUST check the MPEG-2 Continuity Counter carried in the
TS Packet header [ISO-MPEG2]. If two (or more) successive TS Packets
within the same TS Logical Channel carry the same Continuity Counter
value, the duplicate TS Packets MUST be silently discarded. If the
received value is NOT identical to that in the previous TS Packet,
and it does NOT increment by one for successive TS Packets (modulo
16), the Receiver has detected a continuity error. Any partially
received SNDU MUST be discarded. A continuity counter error event
SHOULD be recorded. The Receiver then enters the Idle State.
Note that an MPEG2-2 Transmission network is permitted to carry
duplicate TS Packets [ISO-MPEG2], which are normally detected by the
MPEG-2 Continuity Counter. A Receiver that does not perform the
above Continuity Counter check would accept duplicate copies of TS
Packets to the reassembly procedure. In most cases, the SNDU CRC-32
integrity check will result in discard of these SNDUs, leading to
unexpected PDU loss; however, in some cases, duplicate PDUs (fitting
into one TS Packet) could pass undetected to the next layer protocol.
8. Summary
This document defines a Unidirectional Lightweight Encapsulation
(ULE) that performs efficient and flexible support for IPv4 and IPv6
network services over networks built upon the MPEG-2 Transport Stream
(TS). The encapsulation is also suited to transport of other
protocol packets and bridged Ethernet frames.
ULE also provides an Extension Header format and defines an
associated IANA registry for efficient and flexible support of both
mandatory and optional SNDU headers. This allows for future
extension of the protocol, while providing backwards compatibility
with existing implementations. In particular, Optional Extension
Headers may safely be ignored by Receivers that do not implement
them, or choose not to process them.
9. Acknowledgements
This document is based on a previous document authored by: Horst D.
Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry Fairhurst.
The authors wish to thank the members of the ip-dvb mailing list for
their input; in particular, the many comments received from Art
Allison, Carstsen Borman, Patrick Cipiere, Wolgang Fritsche, Hilmar
Linder, Alain Ritoux, and William Stanislaus. Alain also provided
the original examples of usage.
10. Security Considerations
The security considerations for ULE resemble those that arise when
the existing Multi-Protocol Encapsulation (MPE) is used. ULE does
not add specific new threats that will impact the security of the
general Internet.
There is a known security issue with un-initialised stuffing bytes.
In ULE, these bytes are set to 0xFF (normal practice in MPEG-2).
There are known integrity issues with the removal of the LAN FCS in a
bridged networking environment. The removal for bridged frames
exposes the traffic to potentially undetected corruption while being
processed by the Encapsulator and/or Receiver.
There is a potential security issue when a Receiver receives a PDU
with two Length fields: The Receiver would need to validate the
actual length and the Length field and ensure that inconsistent
values are not propagated by the network. In direct encapsulation of
IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length
Field. However, this issue still arises in bridged LLC frames, and
frames with a LLC Length greater than the SNDU payload size MUST be
discarded, and an SNDU payload length error SHOULD be recorded.
In the future, a ULE Mandatory Extension Header may be used to define
a method to perform link encryption of the SNDU payload. This is as
an additional security mechanism to IP-, transport-, or application-
layer security, not a replacement [RFC4259]. The approach is generic
and decouples the encapsulation from future security extensions. The
operation provides functions that resemble those currently used with
the MPE encapsulation.
Additional security control fields may be provided as part of this
link encryption Extension Header, e.g., to associate an SNDU 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 or
all of the SNDU headers. The method of encryption and the way in
which keys are exchanged is beyond the scope of this specification,
as are the definition of the SA format and that of the related
encryption keys.
11. IANA Considerations
The IANA has created the ULE Next-Header Type field registry as
defined in this document.
ULE Next-Header registry
This registry allocates Next-Header values within the range 0-511
(decimal). For each allocated value, it also specifies the set of
allowed H-LEN values (see section 5). In combination, these
define a set of allowed values in the range 0-1535 for the first
part of the ULE Type space (see section 4.4.1).
11.1. IANA Guidelines
The following contains the IANA guidelines for management of the ULE
Next-Header registry. This registry allocates values 0-511 decimal
(0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater
than 0x01FF (decimal).
It subdivides the Next-Header registry in the following way:
1) 0-255 (decimal) IANA-assigned values, indicating Mandatory
Extension Headers (or link-dependent Type fields) for ULE,
requiring expert review leading to prior issue of an IETF RFC.
This specification MUST define the value and the name associated
with the Extension Header, together with the procedure for
processing the Extension Header. It MUST also define the need for
the Mandatory Extension and the intended use. The size of the
Extension Header MUST be specified.
Assignments have been made in this document, and registered by
IANA:
Type Name Reference
0: Test-SNDU Section 5.1
1: Bridged-SNDU Section 5.2
2) 256-511 (decimal) IANA-assigned values, indicating Optional
Extension Headers for ULE, requiring expert review leading to
prior issue of an IETF RFC. This specification MUST define the
value and the name associated with the Extension Header, together
with the procedure for processing the Extension Header. The entry
MUST specify the range of allowable H-LEN values that are
permitted (in the range 1-5). It MUST also define the need for
the Optional Extension and the intended use.
Assignments have been made in this document, and registered by
IANA:
Type Name H-LEN Reference
256: Extension-Padding 1-5 Section 5.3
12. References
12.1. Normative References
[ISO-MPEG2] IS 13818-1, "Information technology -- Generic coding
of moving pictures and associated audio information --
Part 1: Systems", International Standards Organisation
(ISO), 2000.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[ULE1] Registration for format_identifier ULE1, SMPTE
Registration Authority, LLC,
http://www.smpte-ra.org/ule1.html.
12.2. Informative References
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution
for IP datagrams over MPEG-2 Networks", Work in
Progress, September 2005.
[ATSC] A/53, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53 Rev.C,
2004
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/91, 2001.
[ATSC-G] A/54, "Guide to the use of the ATSC Digital Television
Standard", Advanced Television Systems Committee
(ATSC), Doc. A/54, 1995.
[ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television
Systems Committee (ATSC), Doc. A/65B, 2003.
[ATSC-REG] ATSC "Code Point Registry"
www.atsc.org/standards/Code_Point_Registry.pdf.
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital
TV (DTV) Applications over Satellite", Advanced
Television Systems Committee (ATSC), Doc. A/80, 1999.
[DIX] Digital Equipment Corp, Intel Corp, Xerox Corp,
"Ethernet Local Area Network Specification" Version
2.0, November 1982.
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting",
European Telecommunications Standards Institute
(ETSI), 2004.
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems
(CATV)", European Telecommunications Standards
Institute (ETSI), 1998.
[ETSI-DVBS] EN 300 421, "Digital Video Broadcasting (DVB);
Modulation and Coding for DBS satellite systems at
11/12 GHz", European Telecommunications Standards
Institute (ETSI), 1997.
[ETSI-DVBT] EN 300 744, "Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital
terrestrial television (DVB-T)", European
Telecommunications Standards Institute (ETSI), 2004.
[ETSI-RCS] ETSI 301 790, "Digital Video Broadcasting (DVB);
Interaction Channel for Satellite Distribution
Systems", European Telecommunications Standards
Institute (ETSI), 2005.
[IEEE-802.2] IEEE 802.2, "Local and metropolitan area networks-
Specific requirements Part 2: Logical Link Control",
IEEE Computer Society, (also ISO/IEC 8802-2), 1998.
[IEEE-802.3] IEEE 802.3, "Local and metropolitan area networks-
Specific requirements Part 3: Carrier sense multiple
access with collision detection (CSMA/CD) access
method and physical layer specifications", IEEE
Computer Society, (also ISO/IEC 8802-3), 2002.
[ISO-DSMCC] IS 13818-6, "Information technology -- Generic coding
of moving pictures and associated audio information --
Part 6: Extensions for DSM-CC", International
Standards Organisation (ISO), 1998.
[ITU-H222] H.222.0, "Information technology - Generic coding of
moving pictures and associated audio information:
Systems", International Telecommunication Union,
(ITU-T), 1995.
[ITU-3563] I.363.5, "B-ISDN ATM Adaptation Layer specification:
Type 5 AAL", International Telecommunication Union,
(ITU-T), 1996.
[ISO-8802-2] ISO/IEC 8802.2, "Logical Link Control", International
Standards Organisation (ISO), 1998.
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
Y. Zhang, "A Link-Layer Tunneling Mechanism for
Unidirectional Links", RFC 3077, March 2001.
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC
3309, September 2002.
[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 2005.
[SOOR05] M. Sooriyabandara, G. Fairhurst, A. Ang, B. Collini-
Nocker, H. Linder, W. Stering "A Lightweight
Encapsulation Protocol for IP over MPEG-2 Networks:
Design, Implementation and Analysis", Computer
Networks 48 p5-19, 2005.
Appendix A: SNDU Packing Examples
This appendix provides some examples of use. The appendix is
informative. It does not provide a description of the protocol. The
examples provide the complete TS Packet sequence for some sample
encapsulated IP packets.
The specification of the TS Packet header operation and field values
is provided in [ISO-MPEG2]. The specification of ULE is provided in
the body of this document.
The key below is provided for the following examples.
HDR 4B TS Packet Header
PUSI Payload Unit Start Indicator
PP Payload Pointer
*** TS Packet Payload Pointer (PP)
Example A.1: Two 186B PDUs.
SNDU A is 200 bytes (including the ULE destination NPA address)
SNDU B is 200 bytes (including the ULE destination NPA address)
The sequence comprises 3 TS Packets:
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * *
*****
SNDU
PP=17 CRC for A Length
+-----+------+------+- -+--- --+------+------+- -+------+
| HDR | 0x11 | A183 | ... | A199 | 0x00 | 0xC4 | ... | B165 |
+-----+----*-+------+- -+------+-*----+------+- -+------+
PUSI=1 * *
*************************
End Stuffing
CRC for A Indicator Bytes
+-----+------+- -+------+----+----+- -+----+
| HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF|
+-----+------+- -+------+----+----+- -+----+
PUSI=0
Example A.2: Usage of last byte in a TS-Packet
SNDU A is 183 bytes
SNDU B is 182 bytes
SNDU C is 181 bytes
SNDU D is 185 bytes
The sequence comprises 4 TS Packets:
SNDU
PP=0 Length CRC for A
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xB3 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * *
*****
SNDU Unused
PP=0 Length CRC for B byte
+-----+------+------+------+- -+------+------+
| HDR | 0x00 | 0x00 | 0xB2 | ... | B181 | 0xFF |
+-----+---*--+-*----+------+- -+------+------+
PUSI=1 * *
******
SNDU SNDU
PP=0 Length CRC for C Length
+-----+------+------+------+- -+------+------+------+
| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |
+-----+---*--+-*----+------+- -+------+------+------+
PUSI=1 * *
****** Unused
byte
+-----+------+- -+------+------+
| HDR | D002 | ... | D184 | 0xFF |
+-----+------+- -+------+------+
PUSI=0
Example A.3: Large SNDUs
SNDU A is 732 bytes
SNDU B is 284 bytes
The sequence comprises 6 TS Packets:
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x02 | 0xD8 | ... | A182 |
+-----+---*--+-*----+------+- -+------+
PUSI=1 * *
******
+-----+------+- -+------+
| HDR | A183 | ... | A366 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+
| HDR | A367 | ... | A550 |
+-----+------+- -+------+
PUSI=0
SNDU
PP=181 CRC for A Length
+-----+------+------+- -+------+------+------+
| HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 |
+-----+---*--+------+- -+------+*-----+------+
PUSI=1 * *
*************************
+-----+------+- -+------+
| HDR | B002 | ... | B185 |
+-----+------+- -+------+
PUSI=0
End Stuffing
Indicator Bytes
+-----+------+- -+------+------+------+- -+------+
| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
+-----+------+- -+------+------+------+- -+------+
PUSI=0
Example A.4: Illustration of SNDU Length field
SNDU A is 200 bytes
SNDU B is 60 bytes
SNDU C is 60 bytes
The sequence comprises two TS Packets:
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * * + +
***** ++++++++
+
+++++++++++++++++
+ SNDU
PP=17 CRC for A + Length
+-----+------+------+- -+------+-+----+------+-
| HDR | 0x11 | A183 | ... | A199 | 0x00 | 0x38 | ...
+-----+----*-+------+- -+------+*-----+------+-
PUSI=1 * * + +
************************ +++++++++
+
+++++++++++++++++++++++++++++++++++++++
+
+ SNDU End Stuffing
+ Length Indicator bytes
+ -+------+------+------+ -+------+------+------+- -+------+
+ ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF |
+ -+------+-+----+------+ -+------+-+----+------+- -+------+
+ + + + +
+ + ++++++++ +
+ + + +
++++++++++++++++ ++++++++++++++++++++++
*** TS Packet Payload Pointer (PP)
+++ ULE Length Indicator
Example A.5: Three 44B PDUs.
SNDU A is 52 bytes (no ULE destination NPA address) SNDU B is 52
bytes (no ULE destination NPA address) SNDU C is 52 bytes (no ULE
destination NPA address)
The sequence comprises 1 TS Packet:
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+------+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 | 0x80 | 0x30 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+------+------+- -+-----+-
PUSI=1 * *
*****
End Stuffing
Indicator bytes
-----+------+- -+-----+---------+- -+------+
... 0x80 | 0x30 | ... | C51 |0xFF|0xFF| | 0xFF |