From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1763.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc1763.txt (limited to 'doc/rfc/rfc1763.txt') diff --git a/doc/rfc/rfc1763.txt b/doc/rfc/rfc1763.txt new file mode 100644 index 0000000..02434c2 --- /dev/null +++ b/doc/rfc/rfc1763.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group S. Senum +Request for Comments: 1763 DigiBoard +Category: Standards Track March 1995 + + + The PPP Banyan Vines Control Protocol (BVCP) + +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 + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + defines an extensible Link Control Protocol, and proposes a family of + Network Control Protocols for establishing and configuring different + network-layer protocols. + + This document defines the Network Control Protocol for establishing + and configuring the Banyan VINES protocol over PPP. + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1 Specification of Requirements ................... 2 + 1.2 Terminology ..................................... 3 + 2. A PPP Network Control Protocol for VINES .............. 3 + 2.1 Sending VINES Datagrams ......................... 4 + 2.2 General Considerations .......................... 4 + 3. BVCP Configuration Options ............................ 5 + 3.1 BV-NS-RTP-Link-Type ............................. 5 + 3.2 BV-FRP .......................................... 6 + 3.3 BV-RTP .......................................... 7 + 3.4 BV-Suppress-Broadcast ........................... 8 + SECURITY CONSIDERATIONS ...................................... 9 + REFERENCES ................................................... 9 + ACKNOWLEDGEMENTS .......................................... 9 + CHAIR'S ADDRESS .............................................. 10 + AUTHOR'S ADDRESS ............................................. 10 + + + + + + + +Senum [Page 1] + +RFC 1763 PPP BVCP March 1995 + + +1. Introduction + + PPP has three main components: + + 1. A method for encapsulating multi-protocol datagrams. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols for establishing and + configuring different network-layer protocols. + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure and test + the data link. After the link has been established and optional + facilities have been negotiated as needed by the LCP, PPP must send + BVCP packets to choose and configure the VINES network-layer + protocol. Once BVCP has reached the Opened state, VINES datagrams + can be sent over the link. + + The link will remain configured for communications until explicit LCP + or BVCP packets close the link down, or until some external event + occurs (an inactivity timer expires or network administrator + intervention). + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + + + + +Senum [Page 2] + +RFC 1763 PPP BVCP March 1995 + + +1.2. Terminology + + This document frequently uses the following terms: + + datagram The unit of transmission in the network layer (such as IP). + A datagram may be encapsulated in one or more packets + passed to the data link layer. + + frame The unit of transmission at the data link layer. A frame + may include a header and/or a trailer, along with some + number of units of data. + + packet The basic unit of encapsulation, which is passed across the + interface between the network layer and the data link + layer. A packet is usually mapped to a frame; the + exceptions are when data link layer fragmentation is being + performed, or when multiple packets are incorporated into a + single frame. + + peer The other end of the point-to-point link. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + +2. A PPP Network Control Protocol for VINES + + The Banyan VINES Control Protocol (BVCP) is responsible for + configuring, enabling, and disabling the VINES protocol modules on + both ends of the point-to-point link. BVCP uses the same packet + exchange mechanism as the Link Control Protocol. BVCP packets may + not be exchanged until PPP has reached the Network-Layer Protocol + phase. BVCP packets received before this phase is reached should be + silently discarded. + + The Baynan VINES Control Protocol is exactly the same as the Link + Control Protocol [1] with the following exceptions: + + Frame Modifications + + The packet may utilize any modifications to the basic frame format + which have been negotiated during the Link Establishment phase. + + + + + + +Senum [Page 3] + +RFC 1763 PPP BVCP March 1995 + + + Data Link Layer Protocol Field + + Exactly one BVCP packet is encapsulated in the Information field + of a PPP Data Link Layer frame where the Protocol field indicates + type hex 8035 (Banyan VINES Control Protocol). + + Code field + + Only Codes 1 through 7 (Configure-Request, Configure-Ack, + Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack + and Code-Reject) are used. Other Codes should be treated as + unrecognized and should result in Code-Rejects. + + Timeouts + + BVCP packets may not be exchanged until PPP has reached the + Network-Layer Protocol phase. An implementation should be + prepared to wait for Authentication and Link Quality Determination + to finish before timing out waiting for a Configure-Ack or other + response. It is suggested that an implementation give up only + after user intervention or a configurable amount of time. + + Configuration Option Types + + BVCP has a distinct set of Configuration Options. + +2.1. Sending VINES Datagrams + + Before any VINES datagrams may be communicated, PPP must reach the + Network-Layer Protocol phase, and the Banyan VINES Control Protocol + must reach the Opened state. + + Exactly one VINES packet is encapsulated in the Information field of + a PPP Data Link Layer frame where the Protocol field indicates type + hex 0035 (Banyan VINES datagram). The maximum length of a VINES + datagram transmitted over a PPP link is the same as the maximum + length of the Information field of a PPP data link layer frame. + + The format of the Information field itself is the same as that + defined in [2]. + +2.2. General Considerations + + VINES supports an Address Resolution Protocol, VINES ARP, primarily + used for address assignment. Since this protocol is part of VINES + IP, it is fully supported over BVCP. VINES also supports a data-link + Echo Protocol (VINES Echo), used to test connectivity to a VINES + Server in a LAN environment, which is not supported over BVCP. + + + +Senum [Page 4] + +RFC 1763 PPP BVCP March 1995 + + +3. BVCP Configuration Options + + BVCP Configuration Options allow modifications to the standard + characteristics of the network-layer protocol to be negotiated. If a + Configuration Option is not included in a Configure-Request packet, + the default value for that Configuration Option is assumed. + + BVCP uses the same Configuration Option format defined for LCP [1], + with a separate set of Options. + + Up-to-date values of the BVCP Option Type field are specified in the + most recent "Assigned Numbers" RFC [3]. Current values are assigned + as follows: + + Value Option + + 1 BV-NS-RTP-Link-Type + 2 BV-FRP + 3 BV-RTP + 4 BV-Suppress-Broadcast + + Note: A suggestion was made to combine the BV-NS-RTP-Link-Type option + and the BV-RTP option into a single option that could negotiate one + of four settings (S-RTP, NS-RTP-LAN, NS-RTP-WAN, NO-RTP). This + suggestion has been rejected because VINES must already deal with a + mix of S-RTP and NS-RTP, and that pushing this information down to + the PPP layer is not desirable. + +3.1. BV-NS-RTP-Link-Type + + Description + + This Configuration Option provides a way to negotiate the way the + Non-Sequenced Routing Update Protocol (NS-RTP) (pre-VINES 5.5, + i.e., 4.11 and 5.0) will run on the link. NS-RTP handles updates + differently depending on whether the interface is a LAN type or a + WAN type. For a LAN type, the full routing table is rebroadcast + every update interval (90 seconds). For a WAN type, the full + routing table is only transmitted for the first 3 update intervals + after the link comes up. After that only changes are transmitted + (for 5 update intervals). Note that this has no effect if + Sequenced RTP (VINES 5.5) is being used. 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 NS-RTP updates as if the link was a LAN + + + +Senum [Page 5] + +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: (805) 681-0115 + EMail: fred@cisco.com + +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: (612) 943-9020 + EMail: sjs@digibd.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Senum [Page 10] + -- cgit v1.2.3