File: rfc2728.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1291 lines) | stat: -rw-r--r-- 49,099 bytes parent folder | download | duplicates (5)
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
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291






Network Working Group                                    R. Panabaker
Request for Comments: 2728                                  Microsoft
Category: Standards Track                                  S. Wegerif
                                               Philips Semiconductors
                                                           D. Zigmond
                                                       WebTV Networks
                                                        November 1999


    The Transmission of IP Over the Vertical Blanking Interval of a
                           Television Signal


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.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1. Abstract

   This document describes a method for broadcasting IP data in a
   unidirectional manner using the vertical blanking interval of
   television signals.  It includes a description for compressing IP
   headers on unidirectional networks, a framing protocol identical to
   SLIP, a forward error correction scheme, and the NABTS byte
   structures.

2. Introduction

   This RFC proposes several protocols to be used in the transmission of
   IP datagrams using the Vertical Blanking Interval (VBI) of a
   television signal.  The VBI is a non-viewable portion of the
   television signal that can be used to provide point-to-multipoint IP
   data services which will relieve congestion and traffic in the
   traditional Internet access networks.  Wherever possible these
   protocols make use of existing RFC standards and non-standards.

   Traditionally, point-to-point connections (TCP/IP) have been used
   even for the transmission of broadcast type data.  Distribution of
   the same content--news feeds, stock quotes, newsgroups, weather




Panabaker, et al.           Standards Track                     [Page 1]

RFC 2728                         IPVBI                     November 1999


   reports, and the like--are typically sent repeatedly to individual
   clients rather than being broadcast to the large number of users who
   want to receive such data.

   Today, IP is quickly becoming the preferred method of distributing
   one-to-many data on intranets and the Internet. The coming
   availability of low cost PC hardware for receiving television signals
   accompanied by broadcast data streams makes a defined standard for
   the transmission of data over traditional broadcast networks
   imperative.  A lack of standards in this area as well as the expense
   of hardware has prevented traditional broadcast networks from
   becoming effective deliverers of data to the home and office.

   This document describes the transmission of IP using the North
   American Basic Teletext Standard (NABTS), a recognized and industry-
   supported method of transporting data on the VBI.  NABTS is
   traditionally used on 525-line television systems such as NTSC.
   Another byte structure, WST, is traditionally used on 625-line
   systems such as PAL and SECAM.  These generalizations have
   exceptions, and countries should be treated on an individual basis.
   These existing television system standards will enable the television
   and Internet communities to provide inexpensive broadcast data
   services.  A set of existing protocols will be layered above the
   specific FEC for NABTS including a serial stream framing protocol
   similar to SLIP (RFC 1055 [Romkey 1988]) and a compression technique
   for unidirectional UDP/IP headers.

   The protocols described in this document are intended for the
   unidirectional delivery of IP datagrams using the VBI.  That is, no
   return channel is described, or for that matter possible, in the VBI.

   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.

3. Proposed protocol stack

   The following protocol stack demonstrates the layers used in the
   transmission of VBI data.  Each layer has no knowledge of the data it
   encapsulates, and is therefore abstracted from the other layers. At
   the link layer, the NABTS protocol defines the modulation scheme used
   to transport data on the VBI.  At the network layer, IP handles the
   movement of data to the appropriate clients.  In the transport layer,
   UDP determines the flow of data to the appropriate processes and
   applications.






Panabaker, et al.           Standards Track                     [Page 2]

RFC 2728                         IPVBI                     November 1999


              +-------------------+
              |                   |
              |    Application    |
              |                   |
              +-------------------+
              |                   |  )
              |        UDP        |   )
              |                   |   )
              +-------------------+   (-- IP
              |                   |   )
              |        IP         |   )
              |                   |  )
              +-------------------+
              |    SLIP-style     |
              |   encapsulation   |
              |                   |
              +-------------------+
              |        FEC        |
              |-------------------|
              |       NABTS       |
              |                   |
              +---------+---------+
              |                   |
              |     NTSC/other    |
              |                   |
              +-------------------+
                        |
                        |
                        |            cable, off-air, etc.
                        +--------<----<----<--------

   These protocols can be described in a bottom up component model using
   the example of NABTS carried over NTSC modulation as follows:

   Video signal --> NABTS --> FEC --> serial data stream --> Framing
   protocol --> compressed UDP/IP headers --> application data

   This diagram can be read as follows: television signals have NABTS
   packets, which contain a Forward Error Correction (FEC) protocol,
   modulated onto them.  The data contained in these sequential, ordered
   packets form a serial data stream on which a framing protocol
   indicates the location of IP packets, with compressed headers,
   containing application data.

   The structure of these components and protocols are described in
   following subsections.





Panabaker, et al.           Standards Track                     [Page 3]

RFC 2728                         IPVBI                     November 1999


3.1. VBI

   The characteristics and definition of the VBI is dependent on the
   television system in use, be it NTSC, PAL, SECAM or some other.  For
   more information on Television standards worldwide, see ref [12].

3.1.1. 525 line systems

   A 525-line television frame is comprised of two fields of 262.5
   horizontal scan lines each.  The first 21 lines of each field are not
   part of the visible picture and are collectively called the Vertical
   Blanking Interval (VBI).

   Of these 21 lines, the first 9 are used while repositioning the
   cathode ray to the top of the screen, but the remaining lines are
   available for data transport.

   There are 12 possible VBI lines being broadcast 60 times a second
   (each field 30 times a second).  In some countries Line 21 is
   reserved for the transport of closed captioning data (Ref.[11]).  In
   that case, there are 11 possible VBI lines, some or all of which
   could be used for IP transport.  It should be noted that some of
   these lines are sometimes used for existing, proprietary, data and
   testing services. IP delivery therefore becomes one more data service
   using a subset or all of these lines.

3.1.2. 625 Line Systems

   A 625-line television frame is comprised of two fields of 312.5
   horizontal scan lines each.  The first few lines of each field are
   used while repositioning the cathode ray to the top of the screen.
   The lines available for data insertion are 6-22 in the first field
   and 319-335 in the second field.

   There are, therefore, 17 possible VBI lines being broadcast 50 times
   a second (each field 25 times a second), some or all of which could
   be used for IP transport.  It should be noted that some of these
   lines are sometimes used for existing, proprietary, data and testing
   services. IP, therefore, becomes one more data service using a subset
   or all of these lines.

3.2. NABTS

   The North American Basic Teletext Standard is defined in the
   Electronic Industry Association's EIA-516, Ref. [2], and ITU.R
   BT.653-2, system C, Ref. [13].  It provides an industry-accepted





Panabaker, et al.           Standards Track                     [Page 4]

RFC 2728                         IPVBI                     November 1999


   method of modulating data onto the VBI, usually of an NTSC signal.
   This section describes the NABTS packet format as it is used for the
   transport of IP.

   It should be noted that only a subset of the NABTS standard is used,
   as is common practice in NABTS implementations.  Further information
   concerning the NABTS standard and its implementation can be found in
   EIA-516.

   The NABTS packet is a 36-byte structure encoded onto one horizontal
   scan line of a television signal having the following structure:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            clock sync         |   byte sync   |  packet addr. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  packet address (cont.)       |  cont. index  |PcktStructFlags|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      user data (26 bytes)                     |
   :                                                               :
   :                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                               |              FEC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The two-byte Clock Synchronization and one-byte Byte Synchronization
   are located at the beginning of every scan line containing a NABTS
   packet and are used to synchronize the decoding sampling rate and
   byte timing.

   The three-byte Packet Address field is Hamming encoded (as specified
   in EIA-516), provides 4 data bits per byte, and thus provides 4096
   possible packet addresses.  These addresses are used to distinguish
   related services originating from the same source.  This is necessary
   for the receiver to determine which packets are related, and part of
   the same service.  NABTS packet addresses therefore distinguish
   different data services, possibly inserted at different points of the
   transmission system, and most likely totally unrelated.  Section 4 of
   this document discusses Packet Addresses in detail.

   The one-byte Continuity Index field is a Hamming encoded byte, which
   is incremented by one for each subsequent packet of a given Packet
   Address.  The value or number of the Continuity Index sequences from
   0 to 15. It increments by one each time a data packet is transmitted.
   This allows the decoder to determine if packets were lost during
   transmission.





Panabaker, et al.           Standards Track                     [Page 5]

RFC 2728                         IPVBI                     November 1999


   The Packet Structure field is also a Hamming encoded byte, which
   contains information about the structure of the remaining portions of
   the packet.  The least significant bit is always "0" in this
   implementation.  The second least significant bit specifies if the
   Data Block is full--"0" indicates the data block is full of useful
   data, and "1" indicates some or all of the data is filler data.  The
   two most significant bits are used to indicate the length of the
   suffix of the Data Block--in this implementation, either 2 or 28
   bytes (10 for 2-byte FEC suffix, 11 for 28-byte FEC suffix).  This
   suffix is used for the forward error correction described in the next
   section.  The following table shows the possible values of the Packet
   Structure field:

         Data Packet, no filler                     D0
         Data Packet, with filler                   8C
         FEC Packet                                 A1

   The Data Block field is 26 bytes, zero to 26 of which is useful data
   (part of a IP packet or SLIP frame), the remainder is filler data.
   Data is byte-ordered least significant bit first. Filler data is
   indicated by an Ox15 followed by as many OxEA as are needed to fill
   the Data Block field. Sequential data blocks minus the filler data
   form an asynchronous serial stream of data.

   These NABTS packets are modulated onto the television signal
   sequentially and on any combination of lines.

3.3. FEC

   Due to the unidirectional nature of VBI data transport, Forward Error
   Correction (FEC) is needed to ensure the integrity of data at the
   receiver.  The type of FEC described here and in the appendix of this
   document for NABTS has been in use for a number of years, and has
   proven popular with the broadcast industry.  It is capable of
   correcting single-byte errors and single- and double-byte erasures in
   the data block and suffix of a NABTS packet.  In a system using
   NABTS, the FEC algorithm splits a serial stream of data into 364-byte
   "bundles".  The data is arranged as 14 packets of 26 bytes each.  A
   function is applied to the 26 bytes of each packet to determine the
   two suffix bytes, which (with the addition of a header) complete the
   NABTS packet (8+26+2).

   For every 14 packets in the bundle, two additional packets are
   appended which contain only FEC data, each of which contain 28 bytes
   of FEC data.  The first packet in the bundle has a Continuity Index
   value of 0, and the two FEC only packets at the end have Continuity
   Index values of 14 and 15 respectively.  This data is obtained by
   first writing the packets into a table of 16 rows and 28 columns.



Panabaker, et al.           Standards Track                     [Page 6]

RFC 2728                         IPVBI                     November 1999


   The same expression as above can be used on the columns of the table
   with the suffix now represented by the bytes at the base of the
   columns in rows 15 and 16.  With NABTS headers on each of these rows,
   we now have a bundle of 16 NABTS packets ready for sequential
   modulation onto lines of the television signal.

   At the receiver, these formulae can be used to verify the validity of
   the data with very high accuracy.  If single bit errors, double bit
   errors, single-byte errors or single- and double-byte erasures are
   found in any row or column (including an entire packet lost) they can
   be corrected using the algorithms found in the appendix. The success
   at correcting errors will depend on the particular implementation
   used on the receiver.

3.4. Framing

   A framing protocol identical to SLIP is proposed for encapsulating
   the packets described in the following section, thus abstracting this
   data from the lower protocol layers.  This protocol uses two special
   characters: END (0xc0) and ESC (0xdb).  To send a packet, the host
   will send the packet followed by the END character.  If a data byte
   in the packet is the same code as END character, a two-byte sequence
   of ESC (0xdb) and 0xdc is sent instead.  If a data byte is the same
   code as ESC character, a two-byte sequence of ESC (0xdb) and 0xdd is
   sent instead.  SLIP implementations are widely available; see RFC
   1055 [Romkey 1988] for more detail.

      +--------------+--+------------+--+--+---------+--+
      |   packet     |c0|    packet  |db|dd|         |c0|
      +--------------+--+------------+--+--+---------+--+
                      END              ESC            END

   The packet framed in this manner shall be formatted according to its
   schema type identified by the schema field, which shall start every
   packet:

      +-----------+---------------------------------------------+
      |  schema   |   packet (formatted according to schema)    |
      |  1 byte   |      ?? bytes (schema dependant length)     |
      +-----------+---------------------------------------------+











Panabaker, et al.           Standards Track                     [Page 7]

RFC 2728                         IPVBI                     November 1999


   In the case where the most significant bit in this field is set to
   "1", the length of the field extends to two bytes, allowing for 32768
   additional schemas:

      +-----------+---------------------------------------------+
      | extended  |   packet (formatted according to schema)    |
      |  schema   |       ?? bytes (schema dependant length)    |
      |   2 bytes |                                             |
      +-----------+---------------------------------------------+

   In the section 3.5, one such schema for sending IP is described.
   This is the only schema specified by this document. Additional
   schemas may be proposed for other packet types or other compression
   schemes as described in section 7.

3.4.1 Maximum Transmission Unit Size

   The maximum length of an uncompressed IP packet, or Maximum-
   Transmission Unit (MTU) size is 1500 octets.  Packets larger than
   1500 octets MUST be fragmented before transmission, and the client
   VBI interface MUST be able to receive full 1500 octet packet
   transmissions.

3.5. IP Header Compression Scheme

   The one-byte scheme defines the format for encoding the IP packet
   itself.  Due to the value of bandwidth, it may be desirable to
   introduce as much efficiency as possible in this encoding.  One such
   efficiency is the optional compression of the UDP/IP header using a
   method related to the TCP/IP header compression as described by Van
   Jacobson (RFC 1144).  UDP/IP header compression is not identical due
   to the limitation of unidirectional transmission.  One such scheme is
   proposed in this document for the compression of UDP/IP version 4.
   It is assigned a value of 0x00.  All future encapsulation schemes
   should use a unique value in this field.

   Only schema 0x00 is defined in this document; this schema must be
   supported by all receivers.  In schema 0x00, the format of the IP
   packet itself takes one of two forms.  Packets can be sent with full,
   uncompressed headers as follows:











Panabaker, et al.           Standards Track                     [Page 8]

RFC 2728                         IPVBI                     November 1999


     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|    group    |         uncompressed IP header (20 bytes)     |
    +-+-+-+-+-+-+-+-+                                               +
    |                                                               |
    :                             ....                              :
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               |        uncompressed UDP header (8 bytes)      |
    +-+-+-+-+-+-+-+-+                                               +
    |                                                               |
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               |              payload  (<1472 bytes)           |
    +-+-+-+-+-+-+-+-+                                               +
    |                                                               |
    :                              ....                             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              CRC                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first byte in the 0x00 scheme is the Compression Key.  It is a
   one-byte value: the first bit indicates if the header has been
   compressed, and the remaining seven bits indicate the compression
   group to which it belongs.

   If the high bit of the Compression Key is set to zero, no compression
   is performed and the full header is sent, as shown above. The client
   VBI interface should store the most recent uncompressed header for a
   given group value for future potential use in rebuilding subsequent
   compressed headers.  Packets with identical group bits are assumed to
   have identical UDP/IP headers for all UDP and IP fields, with the
   exception of the "IP identification" and "UDP checksum" fields.

   Group values may be recycled following 60 seconds of nonuse by the
   preceding UDP/IP session (no uncompressed packets sent), or by
   sending packets with uncompressed headers for the 60-second duration
   following the last packet in the preceding UDP/IP session.
   Furthermore, the first packet sent following 60 seconds of nonuse, or
   compressed header packets only use, must use an uncompressed header.
   Client VBI interfaces should disregard compressed packets received 60
   or more seconds after the last uncompressed packet using a given
   group address.  This avoids any incorrectly decompressed packets due
   to group number reuse, and limits the outage due to a lost
   uncompressed packet to 60 seconds.

   If the high bit of the Compression Key is set to one, a compressed
   version of the UDP/IP header is sent.  The client VBI interface must
   then combine the compressed header with the stored uncompressed



Panabaker, et al.           Standards Track                     [Page 9]

RFC 2728                         IPVBI                     November 1999


   header of the same group and recreate a full packet.  For compressed
   packets, the only portions of the UDP/IP header sent are the "IP
   identification" and "UDP checksum" fields:

     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|    group    |        IP identification        | UDP checksum|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |UDP cksm (cont)|           payload  (<1472 bytes)              |
    +-+-+-+-+-+-+-+-+                                               +
    :                              ....                             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              CRC                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   All datagrams belonging to a multi fragment IP packet shall be sent
   with full headers, in the uncompressed header format.  Therefore,
   only packets that have not been fragmented can be sent with the most
   significant bit of the compression key set to "1".

   A 32-bit CRC has also been added to the end of every packet in this
   scheme to ensure data integrity.  It is performed over the entire
   packet including schema byte, compression key, and either compressed
   or uncompressed headers.  It uses the same algorithm as the MPEG-2
   transport stream (ISO/IEC 13818-1).  The generator polynomial is:

   1 + D + D2 + D4 + D5 + D7 + D8 + D10 + D11 + D12 + D16 + D22 + D23 +
   D26 + D32

   As in the ISO/IEC 13818-1 specification, the initial state of the sum
   is 0xFFFFFFFF.  This is not the same algorithm used by Ethernet. This
   CRC provides a final check for damaged datagrams that span FEC
   bundles or were not properly corrected by FEC.

4. Addressing Considerations

   The addressing of IP packets should adhere to existing standards in
   this area.  The inclusion of an appropriate source address is needed
   to ensure the receiving client can distinguish between sources and
   thus services if multiple hosts are sharing an insertion point and
   NABTS packet address.

   NABTS packet addressing is not regulated or standardized and requires
   care to ensure that unrelated services on the same channel are not
   broadcasting with the same packet address.  This could occur due to
   multiple possible NABTS insertion sites, including show production,
   network redistribution, regional operator, and local operator.



Panabaker, et al.           Standards Track                    [Page 10]

RFC 2728                         IPVBI                     November 1999


   Traditionally, the marketplace has recognized this concern and made
   amicable arrangements for the distribution of these addresses for
   each channel.

5. IANA Considerations

   IANA will register new schemas on a "First Come First Served" basis
   [RFC 2434].  Anyone can register a scheme, so long as they provide a
   point of contact and a brief description. The scheme number will be
   assigned by IANA.  Registrants are encouraged to publish complete
   specifications for new schemas (preferably as standards-track RFCs),
   but this is not required.

6. Security Considerations

   As with any broadcast network, there are security issues due to the
   accessibility of data.  It is assumed that the responsibility for
   securing data lies in other protocol layers, including the IP
   Security (IPSEC) protocol suite, Transport Layer Security (TLS)
   protocols, as well as application layer protocols appropriate for a
   broadcast-only network.

7. Conclusions

   This document provides a method for broadcasting Internet data over a
   television signal for reception by client devices.  With an
   appropriate broadcast content model, this will become an attractive
   method of providing data services to end users.  By using existing
   standards and a layered protocol approach, this document has also
   provided a model for data transmission on unidirectional and
   broadcast networks.

8. Acknowledgements

   The description of the FEC in Appendix A is taken from a document
   prepared by Trevor Dee of Norpak Corporation. Dean Blackketter of
   WebTV Networks, Inc., edited the final draft of this document.

9. References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
        1112, August 1989.






Panabaker, et al.           Standards Track                    [Page 11]

RFC 2728                         IPVBI                     November 1999


   [3]  EIA-516, "Joint EIA/CVCC Recommended Practice for Teletext:
        North American Basic Teletext Specification (NABTS)" Washington:
        Electronic Industries Association, c1988

   [4]  International Telecommunications Union Recommendation. ITU-R
        BT.470-5 (02/98) "Conventional TV Systems"

   [5]  International Telecommunications Union Recommendation. ITU.R
        BT.653-2, system C

   [6]  Jack, Keith. "Video Demystified: A Handbook for the Digital
        Engineer, Second Edition," San Diego: HighText Pub.  c1996.

   [7]  Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
        Links", RFC 1144, February 1990.

   [8]  Mortimer, Brian.  "An Error-correction system for the Teletext
        Transmission in the Case of Transparent Data" c1989 Department
        of Mathematics and Statistics, Carleton University, Ottawa
        Canada

   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [10] Norpak Corporation "TTX71x Programming Reference Manual", c1996,
        Kanata, Ontario, Canada

   [11] Norpak Corporation, "TES3 EIA-516 NABTS Data Broadcast Encoder
        Software User's Manual." c1996, Kanata, Ontario, Canada

   [12] Norpak Corporation, "TES3/GES3 Hardware Manual" c1996, Kanata,
        Ontario, Canada

   [13] Pretzel, Oliver. "Correcting Codes and Finite Fields: Student
        Edition" OUP, c1996

   [14] Rorabaugh, C. Britton.  "Error Coding Cookbook" McGraw Hill,
        c1996

   [15] Romkey, J., "A Nonstandard for Transmission of IP Datagrams Over
        Serial Lines: SLIP", STD 47, RFC 1055, June 1988.

   [16] Recommended Practice for Line 21 Data Service (ANSI/EIA-608-94)
        (Sept., 1994)

   [17] Stevens, W. Richard.  "TCP/IP Illustrated, Volume 1,: The
        Protocols"  Reading: Addison-Wesley Publishing Company, c1994.




Panabaker, et al.           Standards Track                    [Page 12]

RFC 2728                         IPVBI                     November 1999


10. Acronyms

   FEC            - Forward Error Correction
   IP             - Internet Protocol
   NABTS          - North American Basic Teletext Standard
   NTSC           - National Television Standards Committee
   NTSC-J         - NTSC-Japanese
   PAL            - Phase Alternation Line
   RFC            - Request for Comments
   SECAM          - Sequentiel Couleur Avec Memoire
                    (sequential color with memory)
   SLIP           - Serial Line Internet Protocol
   TCP            - Transmission Control Protocol
   UDP            - User Datagram Protocol
   VBI            - Vertical Blanking Interval
   WST            - World System Teletext

11. Editors' Addresses and Contacts

   Ruston Panabaker, co-editor
   Microsoft
   One Microsoft Way Redmond, WA 98052

   EMail: rustonp@microsoft.com


   Simon Wegerif, co-editor
   Philips Semiconductors
   811 E. Arques Avenue
   M/S 52, P.O. Box 3409 Sunnyvale, CA 94088-3409

   EMail: Simon.Wegerif@sv.sc.philips.com


   Dan Zigmond, WG Chair
   WebTV Networks
   One Microsoft Way Redmond, WA 98052

   EMail: djz@corp.webtv.net












Panabaker, et al.           Standards Track                    [Page 13]

RFC 2728                         IPVBI                     November 1999


12. Appendix A: Forward Error Correction Specification

   This FEC is optimized for data carried in the VBI of a television
   signal.  Teletext has been in use for many years and data
   transmission errors have been categorized into three main types: 1)
   Randomly distributed single bit errors 2) Loss of lines of NABTS data
   3) Burst Errors

   The quantity and distribution of these errors is highly variable and
   dependent on many factors.  The FEC is designed to fix all these
   types of errors.

12.1. Mathematics used in the FEC

   Galois fields form the basis for the FEC algorithm presented here.
   Rather then explain these fields in general, a specific explanation
   is given of the Galois field used in the FEC algorithm.

   The Galois field used is GF(2^8) with a primitive element alpha of
   00011101.  This is a set of 256 elements, along with the operations
   of "addition", "subtraction", "division", and "multiplication" on
   these elements.  An 8-bit binary number represents each element.

   The operations of "addition" and "subtraction" are the same for this
   Galois field.  Both operations are the XOR of two elements.  Thus,
   the "sum" of 00011011 and 00000111 is 00011100.

   Division of two elements is done using long division with subtraction
   operations replaced by XOR.  For multiplication, standard long
   multiplication is used but with the final addition stage replaced
   with XOR.

   All arithmetic in the following FEC is done modulo 100011101; for
   instance, after you multiply two numbers, you replace the result with
   its remainder when divided by 100011101.  There are 256 values in
   this field (256 possible remainders), the 8-bit numbers.  It is very
   important to remember that when we write A*B = C, we more accurately
   imply modulo(A*B) = C.

   It is obvious from the above description that multiplication and
   division is time consuming to perform.  Elements of the Galois Field
   share two important properties with real numbers.

   A*B = POWERalpha(LOGalpha(A) + LOGalpha(B))
   A/B = POWERalpha(LOGalpha(A) - LOGalpha(B))






Panabaker, et al.           Standards Track                    [Page 14]

RFC 2728                         IPVBI                     November 1999


   The Galois Field is limited to 256 entries so the power and log
   tables are limited to 256 entries.  The addition and subtraction
   shown is standard so the result must be modulo alpha.  Written as a
   "C" expression:

   A*B = apower[alog[A] + alog[B]]
   A/B = apower[255 + alog[A] - alog[B]]

   You may note that alog[A] + alog[B] can be greater than 255 and
   therefore a modulo operation should be performed.  This is not
   necessary if the power table is extended to 512 entries by repeating
   the table.  The same logic is true for division as shown.  The power
   and log tables are calculated once using the long multiplication
   shown above.

12.2. Calculating FEC bytes

   The FEC algorithm splits a serial stream of data into "bundles".
   These are arranged as 16 packets of 28 bytes when the correction
   bytes are included.  The bundle therefore has 16 horizontal codewords
   interleaved with 28 vertical codewords.  Two sums are calculated for
   a codeword, S0 and S1.  S0 is the sum of all bytes of the codeword
   each multiplied by alpha to the power of its index in the codeword.
   S1 is the sum of all bytes of the codeword each multiplied by alpha
   to the power of three times its index in the codeword.  In "C" the
   sum calculations would look like:

   Sum0 = 0;
      Sum1 = 0;
      For (i = 0;i < m;i++)
      {
         if (codeword[i] != 0)
         {
            Sum0 = sum0 ^ power[i + alog[codeword[i]]];
            Sum1 = sum1 ^ power[3*i + alog[codeword[i]]];
            }
         }


   Note that the codeword order is different from the packet order.
   Codeword positions 0 and 1 are the suffix bytes at the end of a
   packet horizontally or at the end of a column vertically.

   When calculating the two FEC bytes, the summation above must produce
   two sums of zero.  All codewords except 0 and 1 are know so the sums
   for the known codewords can be calculated.  Let's call these values
   tot0 and tot1.




Panabaker, et al.           Standards Track                    [Page 15]

RFC 2728                         IPVBI                     November 1999


   Sum0 = tot0^power[0+alog[codeword[0]]]^power[1+alog[codeword[1]]]
   Sum1 = tot1^power[0+alog[codeword[0]]]^power[3+alog[codeword[1]]]

   This gives us two equations with the two unknowns that we can solve:

   codeword[1] = power[255+alog[tot0^tot1]-alog[power[1]^power[3]]]
   codeword[0] = tot0^power[alog[codeword[1]]+alog[power[1]]]

12.3. Correcting Errors

   This section describes the procedure for detecting and correcting
   errors using the FEC data calculated above.  Upon reception, we begin
   by rebuilding the bundle.  This is perhaps the most important part of
   the procedure because if the bundle is not built correctly it cannot
   possibly correct any errors.  The continuity index is used to
   determine the order of the packets and if any packets are missing
   (not captured by the hardware).  The recommendation, when building
   the bundle, is to convert the bundle from packet order to codeword
   order.  This conversion will simplify the codeword calculations. This
   is done by taking the last byte of a packet and making it the second
   byte of the codeword and taking the second last byte of a packet and
   making it the first byte of a codeword.  Also the packet with
   continuity index 15 becomes codeword position one and the packet with
   continuity index 14 becomes codeword position zero.  The same FEC is
   used regardless of the number of bytes in the codeword.  So let's
   think of the codewords as an array codeword[vert][hor] where vert is
   16 packets and hor is 28.  Each byte in the array is protected by
   both a horizontal and a vertical codeword.  For each of the
   codewords, the sums must be calculated. If both the sums for a
   codeword are zero then no errors have been detected for that
   codeword.  Otherwise, an error has been detected and further steps
   need to be taken to see if the error can be corrected.  In "C" the
   horizontal summation would look like:


















Panabaker, et al.           Standards Track                    [Page 16]

RFC 2728                         IPVBI                     November 1999


   for (i = 0; i < 16; i++)
   {
      sum0 = 0;
      sum1 = 0;
      for (j = 0;j < hor;j++)
      {
         if (codeword[i][j] != 0)
         {
            sum0 = sum0 ^ power[j + alog[codeword[i][j]];
            sum1 = sum1 ^ power[3*j + alog[codeword[i][j]];
         }
      }
      if ((sum0 != 0) || (sum1 != 0))
      {
         Try Correcting Packet
      }
   }

   Similarly, vertical looks like:

   for (j = 0;i < hor;i++)
   {
      sum0 = 0;
      sum1 = 0;
      for (i = 0;i < 16;i++)
      {
         if (codeword[i][j] != 0)
         {
            sum0 = sum0 ^ power[i + alog[codeword[i][j]];
            sum1 = sum1 ^ power[3*i + alog[codeword[i][j]];
         }
      }
      if ((sum0 != 0) || (sum1 != 0))
      {
         Try Correcting Column
      }
   }

12.4. Correction Schemes

   This FEC provides four possible corrections:
   1)    Single bit correction in codeword.  All single bit errors.
   2)    Double bit correction in a codeword.  Most two-bit errors.
   3)    Single byte correction in a codeword.  All single-byte errors.
   4)    Packet replacement.  One or two missing packets from a bundle.






Panabaker, et al.           Standards Track                    [Page 17]

RFC 2728                         IPVBI                     November 1999


12.4.1. Single Bit Correction

   When correcting a single-bit in a codeword, the byte and bit position
   must be calculated.  The equations are:

   Byte = 1/2LOGalpha(S1/S0)
   Bit  = 8LOGalpha(S0/POWERalpha(Byte))

   In "C" this is written:

   Byte = alog[power[255 + alog[sum1] - alog[sum0]]];
   if (Byte & 1)
      Byte = Byte + 255;
   Byte = Byte >> 1;
   Bit = alog[power[255 + alog[sum0] - Byte]] << 3;
   while (Bit > 255)
      Bit = Bit - 255;

   The error is correctable if Byte is less than the number of bytes in
   the codeword and Bit is less than eight.  For this math to be valid
   both sum0 and sum1 must be non-zero.  The codeword is corrected by:

   codeword[Byte] = codeword[Byte] ^ (1 << Bit);


12.4.2. Double Bit Correction

   Double bit correction is much more complex than single bit correction
   for two reasons.  First, not all double bit errors are deterministic.
   That is two different bit patterns can generate the same sums.
   Second, the solution is iterative.  To find two bit errors you assume
   one bit in error and then solve for the second error as a single bit
   error.

   The procedure is to iteratively move through the bits of the codeword
   changing each bit's state.  The new sums are calculated for the
   modified codeword. Then the single bit calculation above determines
   if this is the correct solution.  If not, the bit is restored and the
   next bit is tried.

   For a long codeword, this can involve many calculations.  However,
   tricks can speed the process.  For example, the vertical sums give a
   strong indication of which bytes are in error horizontally.  Bits in
   other bytes need not be tried.







Panabaker, et al.           Standards Track                    [Page 18]

RFC 2728                         IPVBI                     November 1999


12.4.3. Single Byte Correction

   For single byte correction, the byte position and bits to correct
   must be calculated.  The equations are:

   Byte = 1/2*LOGalpha(S1/S0)
   Mask = S0/POWERalpha[Byte]

   Notice that the byte position is the same calculation as for single
   bit correction.  The mask will allow more than one bit in the byte to
   be corrected.  In "C" the mask calculation looks like:

   Mask = power[255 + alog[sum0] - Byte]

   Both sum0 and sum1 must be non-zero for the calculations to be valid.
   The Byte value must be less than the codeword length but Mask can be
   any value.  This corrects the byte in the codeword by:

   Codeword[Byte] = Codeword[Byte] ^ Mask

12.4.4. Packet Replacement

   If a packet is missing, as determined by the continuity index, then
   its byte position is known and does not need to be calculated.  The
   formula for single packet replacement is therefore the same as for
   the Mask calculation of single byte correction.  Instead of XORing an
   existing byte with the Mask, the Mask replaces the missing codeword
   position:

   Codeword[Byte] = Mask

   When two packets are missing, both the codeword positions are known
   by the continuity index.  This again gives two equations with two
   unknowns, which is solved to give the following equations.  Mask2 =
   POWERalpha(2*Byte1)*S0+S1

   POWERalpha(2*Byte1+Byte2) +POWERalpha(3*BYTE2)
   Mask1 = S0 + Mask2*POWERalpha(Byte2)/POWERalpha(BYTE1)













Panabaker, et al.           Standards Track                    [Page 19]

RFC 2728                         IPVBI                     November 1999


In "C" these equations are written:

if (sum0 == 0)
{
   if (sum1 == 0)
      mask2 = 0;
   else
      mask2=power[255+alog[sum1]-alog[power[byte2+2*byte1]
                  ^power[3*Byte2]]];
}
else
{
   if ((a=sum1^power[alog[sum0]+2*byte1]) == 0)
      mask2 = 0;
   else
      mask2 =
power[255+alog[a]-alog[power[byte2+2*byte1]^power[3*byte2]]];
}

if (mask2 = 0)
{
   if (sum0 == 0)
      mask1 = 0;
   else
      mask1 = power[255+alog[sum0]-byte1];
}
else
{
   if ((a=sum0^power[alog[mask2] + byte2]) == 0)
      mask1 = 0;
   else
      mask1 = power[255+alog[a]-byte1];
}

   Notice that, in the code above, care is taken to check for zero
   values.  The missing codeword position can be fixed by:

         codeword[byte1] = mask1;
         codeword[byte2] = mask2;

12.5. FEC Performance Considerations

   The section above shows how to correct the different types of errors.
   It does not suggest how these corrections may be used in an algorithm
   to correct a bundle.  There are many possible algorithms and the one
   chosen depends on many variables.  These include:





Panabaker, et al.           Standards Track                    [Page 20]

RFC 2728                         IPVBI                     November 1999


      . The amount of processing power available
      . The number of packets per VBI to process
      . The type of hardware capturing the data
      . The delivery path of the VBI
      . How the code is implemented

   As a minimum, it is recommended that the algorithm use single bit or
   single byte correction for one pass in each direction followed by
   packet replacement if appropriate.  It is possible to do more than
   one pass of error correction in each direction.  The theory is that
   errors not corrected in the first pass may be corrected in the second
   pass because error correction in the other direction has removed some
   errors.

   In making choices, it is important to remember that the code has
   several possible states:

   1)    Shows codeword as correct and it is.

   2)    Shows codeword as correct and it is not (detection failure).

   3)    Shows codeword as incorrect but cannot correct (detection).

   4)    Shows codeword as incorrect and corrects it correctly
         (correction).

   5)    Shows codeword as incorrect but corrects wrong bits (false
         correction).

   There is actually overlap among the different types of errors.  For
   example, a pair of sums may indicate both a double bit error and a
   byte error.  It is not possible to know at the code level which is
   correct and which is a false correction.  In fact, neither might be
   correct if both are false corrections.

   If you know something about the types of errors in the delivery
   channel, you can greatly improve efficiency.  If you know that errors
   are randomly distributed (as in a weak terrestrial broadcast) then
   single and double bit correction are more powerful than single byte.












Panabaker, et al.           Standards Track                    [Page 21]

RFC 2728                         IPVBI                     November 1999


13. Appendix B: Architecture

   The architecture that this document is addressing can be broken down
   into three areas: insertion, distribution network, and receiving
   client.

   The insertion of IP data onto the television signal can occur at any
   part of the delivery system.  A VBI encoder typically accepts a video
   signal and an asynchronous serial stream of bytes forming framed IP
   packets as inputs and subsequently packetizes the data onto a
   selected set of lines using NABTS and an FEC.  This composite signal
   is then modulated with other channels before being broadcast onto the
   distribution network. Operators further down the distribution chain
   could then add their own data, to other unused lines, as well.  The
   distribution networks include coax plant, off-air, and analog
   satellite systems and are primarily unidirectional broadcast
   networks.  They must provide a signal to noise ratio, which is
   sufficient for FEC to recover any lost data for the broadcast of data
   to be effective.

   The receiving client must be capable of tuning, NABTS waveform
   sampling as appropriate, filtering on NABTS addresses as appropriate,
   forward error correction, unframing, verification of the CRC and
   decompressing the UDP/IP header if they are compressed. All of the
   above functions can be carried out in PC software and inexpensive
   off-the-shelf hardware.

14. Appendix C: Scope of proposed protocols

   The protocols described in this document are for transmitting IP
   packets.  However, their scope may be extensible to other
   applications outside this area.  Many of the protocols in this
   document could be implemented on any unidirectional network.

   The unidirectional framing protocol provides encapsulation of IP
   datagrams on the serial stream, and the compression of the UDP/IP
   headers reduces the overhead on transmission, thus conserving
   bandwidth.  These two protocols could be widely used on different
   unidirectional broadcast networks or modulation schemes to
   efficiently transport any type of packet data.  In particular, new
   versions of Internet protocols can be supported to provide a
   standardized method of data transport.









Panabaker, et al.           Standards Track                    [Page 22]

RFC 2728                         IPVBI                     November 1999


15.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Panabaker, et al.           Standards Track                    [Page 23]