1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Network Working Group G. Fairhurst
Request for Comments: 5163 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
April 2008
<span class="h1">Extension Formats for Unidirectional Lightweight Encapsulation (ULE)</span>
<span class="h1">and the Generic Stream Encapsulation (GSE)</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document describes a set of Extension Headers for the
Unidirectional Lightweight Encapsulation (ULE), <a href="./rfc4326">RFC 4326</a>.
The Extension Header formats specified in this document define
extensions appropriate to both ULE and the Generic Stream
Encapsulation (GSE) for the second-generation framing structure
defined by the Digital Video Broadcasting (DVB) family of
specifications.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Description of the Method .......................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. MPEG-2 TS-Concat Extension .................................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. PDU-Concat Extension .......................................<a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. TimeStamp Extension .......................................<a href="#page-12">12</a>
<a href="#section-4">4</a>. IANA Considerations ............................................<a href="#page-13">13</a>
<a href="#section-5">5</a>. Acknowledgments ................................................<a href="#page-13">13</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-14">14</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-14">14</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-14">14</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-14">14</a>
<a href="#appendix-A">Appendix A</a>. The Second-Generation DVB Transmission
Specifications .................................................<a href="#page-16">16</a>
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document describes three Extension Headers that may be used with
both the Unidirectional Lightweight Encapsulation (ULE) [<a href="./rfc4326" title=""Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)"">RFC4326</a>] and
the Generic Stream Encapsulation (GSE) [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>]. ULE is defined for
links that employ the MPEG-2 Transport Stream, and supports a wide
variety of physical-layer bearers [<a href="./rfc4259" title=""A Framework for Transmission of IP Datagrams over MPEG-2 Networks"">RFC4259</a>].
GSE has been designed for the Generic Mode (also known as the Generic
Stream (GS)), offered by second-generation DVB physical layers, and
in the first instance for DVB-S2 [<a href="#ref-ETSI-S2" title=""Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications"">ETSI-S2</a>]. The requirements for the
Generic Stream are described in [<a href="#ref-S2-REQ" title=""A Design Rationale for Providing IP Services over DVB-S2 Links"">S2-REQ</a>]. The important
characteristics of this encapsulation are described in the appendix
of this document. GSE maintains a design philosophy that presents a
network interface that is common to that presented by ULE and uses a
similar construction for SubNetwork Data Units (SNDUs).
The first Extension Header defines a method that allows one or more
TS Packets [<a href="#ref-ISO-MPEG2" title=""Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems"">ISO-MPEG2</a>] to be sent within a ULE SNDU. This method may
be used to provide control plane information including the
transmission of MPEG-2 Program Specific Information (PSI) for the
Multiplex. In GSE, there is no native support for Transport Stream
packets and this method is therefore suitable for providing an MPEG-2
control plane.
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
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 a receiver that is not configured to
receive the NPA address associated with an SNDU, allowing this
receiver to 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.
A third Extension Header provides an optional TimeStamp value for an
SNDU. Examples of the use of this TimeStamp option include
monitoring and benchmarking of ULE and GSE links. Receivers that do
not wish to decode (or do not support) the TimeStamp extension may
discard the extension and process the remaining PDU or Extension
Headers.
The appendix includes a summary of key design issues and
considerations relating to the GSE Specification defined by the DVB
Technical Module [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>].
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
b: bit. For example, one byte consists of 8b.
B: byte. Groups of bytes are represented in Internet byte order.
BBFrame payload: The data field part of a Baseband frame [<a href="#ref-ETSI-S2" title=""Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications"">ETSI-S2</a>]
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 Forward Error Correction (FEC) in use.
DVB: Digital Video Broadcasting. A framework and set of associated
standards published by the European Telecommunications Standards
Institute (ETSI) for the transmission of video, audio, and data.
E: A one-bit flag field defined in GSE [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>].
Encapsulator: A network device [<a href="./rfc4259" title=""A Framework for Transmission of IP Datagrams over MPEG-2 Networks"">RFC4259</a>] that receives PDUs and
formats these into Payload Units (known here as SNDUs) for output in
DVB-S or the Generic Mode of DVB-S2.
GS: Generic Stream. A stream of BBFrames identified by a common
Input Stream Identifier, and which does not use the MPEG-2 TS format
[<a href="#ref-ETSI-S2" title=""Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications"">ETSI-S2</a>]. It represents layer 2 of the ISO/OSI reference model.
GSE: Generic Stream Encapsulation [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>]. A method for encapsulating
PDUs to form a Generic Stream, which is sent using a sequence of
BBFrames. This encapsulation format shares the same extension format
and basic processing rules of ULE and uses a common IANA Registry.
LT: A two-bit flag field defined in GSE [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>].
MAC: Medium Access Control [<a href="#ref-IEEE-802.3" title=""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-802.3</a>]. A link-layer protocol
defined by the IEEE 802.3 standard.
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Organization for
Standardization (ISO/IEC 113818-1) [<a href="#ref-ISO-MPEG2" title=""Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems"">ISO-MPEG2</a>], and ITU-T (in H.220).
Next-Header: A Type value indicating an Extension Header [<a href="./rfc4326" title=""Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)"">RFC4326</a>].
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
NPA: Network Point of Attachment [<a href="./rfc4326" title=""Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)"">RFC4326</a>]. In this document, refers
to a destination address (resembling an IEEE MAC address) within the
DVB-S/S2 transmission network that is used to identify individual
Receivers or groups of Receivers.
PID: Packet Identifier [<a href="#ref-ISO-MPEG2" title=""Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems"">ISO-MPEG2</a>]. A 13-bit field carried in the
header of each TS Packet. This identifies the TS Logical Channel to
which a TS Packet belongs [<a href="#ref-ISO-MPEG2" title=""Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems"">ISO-MPEG2</a>]. The TS Packets that form 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
introduced to maintain a constant bit rate of a TS Multiplex. There
is no required relationship between the PID values used for TS
Logical Channels transmitted using different TS Multiplexes.
PDU: Protocol Data Unit [<a href="./rfc4259" title=""A Framework for Transmission of IP Datagrams over MPEG-2 Networks"">RFC4259</a>]. Examples of a PDU include
Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PSI: Program Specific Information [<a href="#ref-ISO-MPEG2" title=""Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems"">ISO-MPEG2</a>].
S: A one-bit flag field defined in [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>].
SI Table: Service Information Table [<a href="#ref-ISO-MPEG2" title=""Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems"">ISO-MPEG2</a>]. In this document,
this term describes a table that is been defined by another standards
body to convey information about the services carried on a DVB
Multiplex.
SNDU: SubNetwork Data Unit [<a href="./rfc4259" title=""A Framework for Transmission of IP Datagrams over MPEG-2 Networks"">RFC4259</a>]. In this document, this is an
encapsulated PDU sent using ULE or GSE.
Stream: A logical flow from an Encapsulator to a set of Receivers.
TS: Transport Stream [<a href="#ref-ISO-MPEG2" title=""Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems"">ISO-MPEG2</a>], 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) [<a href="./rfc4326" title=""Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)"">RFC4326</a>]. A
method that encapsulates PDUs into SNDUs that are sent in a series of
TS Packets using a single TS Logical Channel. The encapsulation
defines an extension format and an associated IANA Registry.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Description of the Method</span>
In ULE, a Type field value that is less than 1536 in decimal
indicates an Extension Header. This section describes a set of three
extension formats for the ULE encapsulation. [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>] uses a Type field
that adopts the same semantics as specified by <a href="./rfc4326">RFC 4326</a>. The
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
encapsulation format differs in that GSE does not include a Cyclic
Redundancy Check (CRC) for each SNDU, has different header flags, and
utilizes a different SNDU length calculation [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>].
There is a natural ordering of Extension Headers, which is determined
by the fields upon which the Extension Header operates. 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 optimization 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
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. MPEG-2 TS-Concat Extension</span>
The MPEG-2 TS-Concat Extension Header is specified by an IANA-
assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory
Extension Header.
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
SNDU is determined from the size of the remainder of the payload
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
is the number of bytes associated with Extension Headers that precede
the MPEG-2 TS-Concat Extension (zero if there are none) and D is the
value of the D-bit.
A Receiver MUST check the validity of the Length value prior to
processing the payload. A valid Length corresponds to an integral
number of TS Packets. An invalid Length (a remainder from the
division by 188) MUST result in the discard of all encapsulated TS
Packets and SHOULD be recorded as TS-Concat size mismatch error.
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0)
Figure 1 illustrates the format of this Extension Header for ULE with
a value D=0, which indicates the presence of an NPA address
[<a href="./rfc4326" title=""Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)"">RFC4326</a>]. In this case, the valid payload Length for a ULE SNDU
with no other extensions is (Length-10) / 188.
The method used to define the Length in GSE differs to that of ULE.
The equivalent case for GSE would result in a payload Length value of
(Length-6) / 188 (Figure 2).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|0 0| Length (12b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00)
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
Fragmented GSE SNDUs are protected by a CRC-32 carried in the final
fragment. After reassembly, this CRC-32 is removed and the resulting
SNDU carries a Total Length field. The fields labeled S and E are
defined by [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>] and contain control flags used by the GSE link
layer. The Label Type (LT) field specifies the presence and format
of the GSE label. The LT field is only specified for the first
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 of
an NPA address (Figure 3). A similar format is supported in GSE.
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 = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1)
The TS-Concat extension may be used to transport one or more MPEG-2
TS Packets of arbitrary content, interpreted according to [ISO-
MPEG2]. One expected use is for the transmission of MPEG-2 SI/PSI
signalling [<a href="./rfc4259" title=""A Framework for Transmission of IP Datagrams over MPEG-2 Networks"">RFC4259</a>].
NULL TS Packets [<a href="#ref-ISO-MPEG2" title=""Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems"">ISO-MPEG2</a>] SHOULD NOT be sent using this
encapsulation. To reduce transmission overhead and processing, an
Encapsulator SHOULD 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 value MUST be bounded and SHOULD be
configurable in the Encapsulator. A larger value can improve
efficiency, but incurs higher jitter and could increase the
probability of corruption. If additional TS Packets are NOT received
within the TS Packing Threshold, the Encapsulator MUST immediately
send any queued TS Packets.
The use of this format to transfer MPEG-2 clock references (e.g., a
Network Clock Reference, NCR) over ULE/GSE framing raises timing
considerations at the encapsulation gateway, including the need to
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
update/modify the timing information prior to transmission by the
physical layer. These issues are not considered here, but this
operation may be simplified in GSE by ensuring that all SNDUs that
carry this Extension Header are placed before other data within the
BBFrame DataField [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>].
This document does not specify how TS Packets are to be handled at
the Receiver. However, it notes:
* A Receiver needs to consistently associate all TS Packets in a
Stream with one TS Logical Channel (Stream). If an Encapsulator
transmits more than one Stream of TS Packets each encapsulated at a
different level or with a different NPA address, a Receiver needs
to ensure that each is independently demultiplexed as a separate
Stream (<a href="./rfc4259#section-3.2">Section 3.2 [RFC4259]</a>).
* If an Encapsulator transmits service information encapsulated at
different levels or with different NPA addresses, the Receivers
need to ensure each Stream is related to the corresponding SI table
information (if any). A RECOMMENDED way to reduce signaling
interactions is to ensure each PID value uniquely identifies a
Stream within a TS Multiplex carrying ULE and also any TS Packets
encapsulated by a ULE/GSE Stream.
The need for consistency in the use of PIDs and the related service
information is described in <a href="./rfc4947#section-4.2">section 4.2 of [RFC4947]</a>.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. PDU-Concat Extension</span>
The PDU-Concat Extension Header is specified by an IANA-assigned
H-Type value of 0x0003 in hexadecimal. 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 carries
the value of the combined length of all PDUs to be encapsulated,
including each set of encapsulation headers. The base header MAY be
followed by one or more additional Extension Headers that precede the
PDU-Concat Extension Header. These Extension Headers (e.g., a
TimeStamp Extension) apply to the composite concatenated PDU.
The Extension Header also contains a 16-bit ULE Type field describing
the encapsulated PDU, PDU-Concat-Type. Although any Type value
specified in the ULE Next-Header Registry (including Extension Header
Types) may be assigned to the encapsulated PDU (except the recursive
use of a PDU-Concat type), all concatenated PDUs MUST have a common
ULE Type (i.e., all concatenated PDUs passed by the network layer
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
must be associated with the same Type value). This simplifies the
receiver design, and reduces the transmission overhead for common use
cases.
Each PDU is prefixed by its length in bytes (shown in the following
diagrams as PDU-x-Length for the xth PDU). Encapsulated PDUs are of
arbitrary length (in bytes) and are not necessarily aligned to 16-bit
or 32-bit boundaries within the SNDU (as shown in the figures 4, 5,
and 6). The most significant bit of the first byte is reserved, R,
and this 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 than 32758 bytes, but will generally be much smaller.
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,
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0)
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|0 0| Length (12b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)
When the SNDU header indicates the absence of an SNDU Destination
Address field (i.e., D=1 in ULE), all encapsulated PDUs MUST be
processed as if they had been received without an NPA address.
The value of D in the ULE header indicates whether an NPA/MAC address
is in use [<a href="./rfc4326" title=""Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)"">RFC4326</a>]. A similar format is supported in GSE (using the
LT field).
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU-Concat-Type |R| PDU-1-Length (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1)
To reduce transmission overhead and processing, an Encapsulator
SHOULD specify a maximum period of time it will wait before sending a
Concatenated PDU. This is known as the PDU Packing Threshold. This
value MUST be bounded and SHOULD be configurable in the Encapsulator.
A larger value can improve efficiency, but incurs higher jitter and
could increase the probability of corruption. If additional PDUs are
NOT received within the PDU Packing Threshold, the Encapsulator MUST
immediately send all queued PDUs.
The Receiver processes this Extension Header by verifying that it
supports the specified PDU-Concat Type (unsupported Types MUST be
discarded, but the receiver SHOULD record a PDU-Type error
[<a href="./rfc4326" title=""Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)"">RFC4326</a>]). It then extracts each encapsulated PDU in turn. The
Receiver MUST verify the Length of each PDU. It MUST also ensure
that the sum of the Lengths of all processed PDUs equals the Length
specified in the SNDU base header. A Receiver SHOULD discard the
whole SNDU if the total and PDU sizes are not consistent and this
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
event SHOULD be recorded as a PDU-Concat size mismatch error. A
receiver MUST NOT forward a partial PDU with an indicated PDU-Length
greater than the number of unprocessed bytes remaining in the SNDU
payload field.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. TimeStamp Extension</span>
The TimeStamp Extension Header is an Optional Extension Header that
permits an Encapsulator to add a TimeStamp field to an SNDU. The
TimeStamp Extension Header is specified by the IANA-assigned H-Type
value of 257 decimal. This extension is an Optional Extension Header
(<a href="./rfc4326#section-5">[RFC4326], Section 5</a>).
This extension is designed to support monitoring and measurement of
the performance of a link to indicate the quality of an operational
ULE link. This may be useful for GSE links (e.g., where significant
complexity exists in the scheduling provided by the lower layers).
Possible uses of this extension include:
* Validation of in-sequence ordering per Logical Channel
* Measurement of one-way delay (when synchronized with the sender)
* Measurement of PDU Jitter introduced by the link
* Measurement of PDU loss (with additional information from sender)
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
implied byte-alignment).
0 7 15 23 31
+---------------+---------------+---------------+---------------+
| 0x03 | 0x01 | TimeStamp HI |
+---------------+---------------+---------------+---------------+
| TimeStamp LO | Type |
+---------------+---------------+---------------+---------------+
Figure 7: Format of the 32-bit TimeStamp Extension Header
The extension carries a 32-bit value (TimeStamp HI plus TimeStamp
LO). The specified resolution is 1 microsecond. The value therefore
indicates the number of 1-microsecond ticks past the hour in
Universal Time when the PDU was encapsulated. This value may be
earlier than the time of transmission, due for example to Packing,
queuing, and other Encapsulator processing. The value is right-
justified to the 32-bit field. Systems unable to insert TimeStamps
at the specified resolution MUST pad the unused least-significant
bits with a value of zero.
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
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-
Header (<a href="./rfc4326#section-4.4">[RFC4326], Section 4.4</a>).
Receivers MAY process the TimeStamp when the PDU encapsulation is
removed. Receivers that do not implement, or do not wish to process,
the TimeStamp Extension MAY skip this Extension Header. Receivers
MUST continue to process the remainder of the SNDU, forwarding the
encapsulated PDU.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
IANA has assigned three 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 following assignments have been made in this document and
registered by IANA:
Type Name Reference
2: TS-Concat <a href="#section-3.1">Section 3.1</a>
3: PDU-Concat <a href="#section-3.2">Section 3.2</a>
Type Name H-LEN Reference
257: TimeStamp 3 <a href="#section-3.3">Section 3.3</a>
The TS-Concat Extension is a Mandatory next-type Extension Header,
specified in <a href="#section-3.1">Section 3.1</a> of this document. The value of this next-
header is defined by an IANA assigned H-Type value of 0x0002.
The PDU-Concat Extension is a Mandatory next-type Extension Header
specified in <a href="#section-3.2">Section 3.2</a> of this document. The value of this next-
header is defined by an IANA assigned H-Type value of 0x0003.
The TimeStamp Extension is an Optional next-type Extension Header
specified in <a href="#section-3.3">Section 3.3</a> of this document. The value of this next-
header is defined by an IANA assigned H-Type value of 257 decimal.
This documents defines the format for an HLEN value of 0x3.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgments</span>
The authors gratefully acknowledge the inputs, comments, and
assistance offered by the members of the DVB-GBS ad hoc group on
DVB-S2 encapsulation, in particular contributions on DVB-S2
transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie.
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
Juan Cantillo provided a significant contribution to the informative
appendix. The authors thank Christian Praehauser for his insight and
contribution on Extension Header processing issues.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Security considerations for ULE are described in [<a href="./rfc4326" title=""Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)"">RFC4326</a>], and
further information on security aspects of using ULE are described in
the security considerations of [<a href="./rfc4259" title=""A Framework for Transmission of IP Datagrams over MPEG-2 Networks"">RFC4259</a>] and [<a href="#ref-Sec-Req" title=""Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol"">Sec-Req</a>].
An attacker that is able to inject arbitrary TS Packets in a ULE or
GSE Stream may modify layer 2 signalling information transmitted by
the MPEG-2 TS-Concat extension. Since this attack requires access to
the link and/or layer 2 equipment, such an attack could also directly
attack signalling information sent as native TS Packets (not
encapsulated by ULE/GSE). Security issues relating to the
transmission and interpretation of layer 2 signalling information
(including Address Resolution) within a TS Multiplex are described in
[<a href="./rfc4947" title=""Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks"">RFC4947</a>]. The use of security mechanisms to protect the MPEG-2
signalling information is discussed by [<a href="#ref-Sec-Req" title=""Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol"">Sec-Req</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC4326">RFC4326</a>] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Stream (TS)", <a href="./rfc4326">RFC</a>
<a href="./rfc4326">4326</a>, December 2005.
[<a id="ref-GSE">GSE</a>] TS 102 606 "Digital Video Broadcasting (DVB); Generic
Stream Encapsulation (GSE) Protocol, "European
Telecommunication Standards, Institute (ETSI), 2007.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-ETSI-S2">ETSI-S2</a>] 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).
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
[<a id="ref-S2-REQ">S2-REQ</a>] Cantillo, J. and J. Lacan, "A Design Rationale for
Providing IP Services over DVB-S2 Links", Work in
Progress, December 2006.
[<a id="ref-Sec-Req">Sec-Req</a>] Cruickshank, H., Iyengar, S., and P. Pillai, "Security
requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol", Work in Progress,
November 2007.
[<a id="ref-IEEE-802.3">IEEE-802.3</a>] "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 802.3, IEEE Computer
Society, (also ISO/IEC 8802-3), 2002.
[<a id="ref-ISO-MPEG2">ISO-MPEG2</a>] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio
Information Systems", International Organization for
Standardization (ISO), 2000.
[<a id="ref-RFC4259">RFC4259</a>] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-
Nocker, B., and H. Linder, "A Framework for Transmission
of IP Datagrams over MPEG-2 Networks", <a href="./rfc4259">RFC 4259</a>,
November 2005.
[<a id="ref-RFC4947">RFC4947</a>] Fairhurst, G. and M. Montpetit, "Address Resolution
Mechanisms for IP Datagrams over MPEG-2 Networks", <a href="./rfc4947">RFC</a>
<a href="./rfc4947">4947</a>, July 2007.
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. The Second-Generation DVB Transmission Specifications</span>
This section provides informative background to the network-layer
requirements of the second-generation DVB Transmission
Specifications. The second-generation waveforms specified by the
Digital Video Broadcasting project offer two main enhancements.
First, more efficient physical-layer methods that employ higher-order
modulation with stronger FEC and permit adaptive coding and
modulation response to changes in traffic and propagation conditions.
Second, at the link layer, they offer greater flexibility in framing.
Support is provided for a range of stream formats including the
classical Transport Stream (TS) [<a href="./rfc4259" title=""A Framework for Transmission of IP Datagrams over MPEG-2 Networks"">RFC4259</a>]. In addition, a new method
called Generic Stream (GS) (or the Generic Mode) is supported. A GS
can be packetized or continuous and is intended to provide native
transport of other network-layer services. One such method is that
provided by the Generic Stream Encapsulation (GSE) [<a href="#ref-GSE" title=""Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "">GSE</a>].
For example, the DVB-S2 [<a href="#ref-ETSI-S2" title=""Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications"">ETSI-S2</a>] transmission link sequentially
multiplexes a series of baseband frames (BBFrames). Each BBFrame
comprises a fixed-size 10B header and a payload. The payload carries
a DataField and uses padding to fill any unused space. A stream
comprises a sequence of BBFrames associated with an Input Stream
Identifier (ISI) that is carried in the header of each BBFrame. The
simplest scheme uses a single stream (with just one ISI value), but
multiple streams are permitted. The BBFrames forming a stream may be
of variable size (selected from a set of allowed sizes), and must use
the same stream format (i.e., TS or GSE). Each stream represents an
independent link with independent address resolution [<a href="./rfc4947" title=""Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks"">RFC4947</a>].
GSE provides functions that are equivalent to those of the
Unidirectional Lightweight Encapsulation (ULE) [<a href="./rfc4326" title=""Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)"">RFC4326</a>]. It
supports the transmission of IP packets and other network-layer
protocols. The network-layer interface resembles that of ULE, where
it adopts common mechanisms for a Length field, a 16-bit Type field,
and support for Extension Headers. As in ULE, GSE permits multiple
address formats, indicated by the LT field (functionally equivalent
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
ULE).
GSE also provides more flexible fragmentation at the interface to the
physical layer (using the S and E flags). This adapts the SNDUs to a
variable-sized link-layer frame, and reflects the more complex
requirements in terms of fragmentation and assembly that arise when
using point-to-multipoint adaptive physical layers. The integrity of
a reassembled SNDU is validated using a CRC-32 in the last fragment
for the corresponding PDU.
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
Authors' Addresses
Godred Fairhurst
School of Engineering,
University of Aberdeen,
Aberdeen, AB24 3UE
UK
EMail: gorry@erg.abdn.ac.uk
URI: <a href="http://www.erg.abdn.ac.uk/users/gorry">http://www.erg.abdn.ac.uk/users/gorry</a>
Bernhard Collini-Nocker
Department of Computer Sciences,
University of Salzburg,
Jakob Haringer Str. 2,
5020 Salzburg,
Austria
EMail: bnocker@cosy.sbg.ac.at
URI: <a href="http://www.cosy.sbg.ac.at">http://www.cosy.sbg.ac.at</a>
<span class="grey">Fairhurst & Collini-Nocker Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5163">RFC 5163</a> Extension Formats for the ULE Encapsulation April 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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
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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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.
Fairhurst & Collini-Nocker Standards Track [Page 18]
</pre>
|
