📄 rfc2728.txt
字号:
"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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -