rfc1763.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1763                        PPP BVCP                      March 1995


      type.  The rejection (or absence) of this option indicates that
      the peer will send NS-RTP updates as if the link was a WAN type.

      By default, NS-RTP updates are sent as if the link was a WAN type.

   A summary of the BV-NS-RTP-Link-Type Configuration Option format is
   shown below.  The fields are transmitted from left to right.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type

         1

      Length

         2

3.2.  BV-FRP

   Description

      This Configuration Option provides a way to negotiate the use of
      VINES Fragmentation Protocol (FRP).  This protocol is used to
      allow fragmentation and reassembly of a VINES packet over the
      link.  FRP prepends a two octet field to every packet going over
      the link that contains a begin and end fragment information and a
      sequence number.  With PPP's default MRU of 1500, FRP is not
      normally needed, and no FRP header would be sent with the VINES
      packet.  If a MRU of less than 1484 is negotiated, FRP will be
      needed to send a full size VINES packet over the link.  More
      information on this can be found in [2].

      This option negotiates what an implementation is willing to
      receive, and is negotiated separately per side of the PPP
      connection.  The acceptance of this option (by the peer) indicates
      that the peer will send VINES packets with a FRP header.  The
      rejection (or absence) of this option indicates that the peer will
      send VINES packets without a FRP header.

      By default, VINES packets are sent without a FRP header.





Senum                                                           [Page 6]

RFC 1763                        PPP BVCP                      March 1995


   A summary of the BV-FRP Configuration Option format is shown below.
   The fields are transmitted from left to right.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type

         2

      Length

         2

3.3.  BV-RTP

   Description

      This Configuration Option provides a way to negotiate whether RTP
      is used over the link.  If dial-up lines with static routes are
      being used, the use of RTP may be totally suppressed to conserve
      bandwidth on the link.

      This option negotiates what an implementation is willing to
      receive, and is negotiated separately per side of the PPP
      connection.  The acceptance of this option (by the peer) indicates
      that the peer will not send RTP packets.  The rejection (or
      absence) of this option indicates that the peer will send any RTP
      packets.

      By default, RTP packets are sent over the link.
















Senum                                                           [Page 7]

RFC 1763                        PPP BVCP                      March 1995


   A summary of the BV-RTP Configuration Option format is shown below.
   The fields are transmitted from left to right.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type

         3

      Length

         2

3.4.  BV-Suppress-Broadcast

   Description

      This Configuration Option provides a way to negotiate the sending
      of VINES broadcast packets, i.e., packets with a destination VINES
      network address of all ones.  This option only affects VINES
      packets that are not of type VINES ARP or VINES RTP.  This option
      can be used by a VINES Client to request that most of the
      broadcast packets that would normally be sent to it by a VINES
      Server be discarded, in order to conserve link bandwidth.  Most of
      the broadcast packets sent by a VINES Server are not useful to a
      VINES Client.

      This option negotiates what an implementation is willing to
      receive, and is negotiated separately per side of the PPP
      connection.  The acceptance of this option (by the peer) indicates
      that the peer MUST NOT send any VINES broadcast packets, other
      than packets of type VINES ARP or VINES RTP.  The rejection (or
      absence) of this option indicates that the peer will send all
      VINES broadcast packets.

      By default, all VINES broadcast packets are sent.










Senum                                                           [Page 8]

RFC 1763                        PPP BVCP                      March 1995


   A summary of the BV-Suppress-Broadcast Configuration Option format is
   shown below.  The fields are transmitted from left to right.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type

         4

      Length

         2

Security Considerations

   Security issues are not discussed in this memo.

References

   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
       1661, Daydreamer, July 1994.

   [2] Banyan, "VINES Protocol Definition", June 1993, Order No.
       003673.

   [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
       USC/Information Sciences Institute, October 1994.

Acknowledgements

   Some of the text in this document is taken from previous documents
   produced by the Point-to-Point Protocol Working Group of the Internet
   Engineering Task Force (IETF).

   In particular, Bill Simpson provided the boiler-plate used to create
   this document.










Senum                                                           [Page 9]

RFC 1763                        PPP BVCP                      March 1995


Chair's Address

   The working group can be contacted via the current chair:

   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, California 93111

   Phone: [phone]
   EMail: [e-mail]

Author's Address

   Questions about this memo can also be directed to:

   Steven J. Senum
   DigiBoard
   6400 Flying Cloud Drive
   Eden Prairie, Minnesota 55344

   Phone: [phone]
   EMail: [e-mail]




























Senum                                                          [Page 10]