rfc2728.txt

<VC++网络游戏建摸与实现>源代码

   "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.