From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 7 12:49:52 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02910; Fri, 7 Sep 90 12:30:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from decpa.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02815; Fri, 7 Sep 90 12:23:51 -0700 Received: by decpa.pa.dec.com; id AA21506; Fri, 7 Sep 90 12:22:50 -0700 Message-Id: <9009071922.AA21506@decpa.pa.dec.com> Received: from gah.enet; by decwrl.enet; Fri, 7 Sep 90 12:23:00 PDT Date: Fri, 7 Sep 90 12:23:00 PDT From: "Arthur Harvey, 226-7647, LKG1-2/A19" To: ietf-ppp@ucdavis.edu Subject: Proposal for 802.2 LLC over PPP Status: O The Point-to-Point Protocol: LLC over PPP DRAFT PROPOSAL Abstract The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: 1. A method for encapsulating datagrams over serial links. 2. An extensible Link Control Protocol (LCP). 3. A family of Network Control Protocols (NCP) for establishing and configuring different network layer protocols. The IEEE 802.2 Logical Link Control (LLC) protocol provides additional services beyond those available directly from the various IEEE 802 Medium Access Control (MAC) data link protocols. This document defines the operation of the LLC protocol over PPP. Status of this memo This draft document is for review by the PPP Working Group of the IETF. Distribution of this memo is unlimited. Please send comments to the author. DRAFT PROPOSAL LLC over PPP Page 2 Introduction 7 September 1990 1 Introduction 1.1 Overview Of PPP PPP is a point-to-point serial data link protocol providing a multiplexing, datagram delivery service. It has three main components: 1. A method for encapsulating datagrams of multiple data link users over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point-to-point links. 2. An extensible Link Control Protocol (LCP) to establish, configure, and test the data link connection. 3. A family of Network Control Protocols (NCP) for establishing and configuring different network layer protocols. PPP is designed to allow the simultaneous use of multiple network layer protocols. To establish communications over a point-to-point link, the originating PPP sends 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, the originating PPP may send NCP packets to choose and configure one or more network layer protocols. Once each of the chosen network layer protocols has been configured, datagrams from each network layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (e.g. inactivity timer expires or user intervention). The encapsulation method, the LCP, and an NCP for the DoD IP protocol are all defined in [1]. Configuration Options for PPP are defined in [2]. 1.2 Overview Of LLC The IEEE 802.2 LLC protocol provides a set of services which are common across all the 802 data links [3]. Some of the services provided are: the multiplexing of data link users over a single MAC; a connectionless Protocol Data Unit (PDU) delivery service providing no error recovery; a reliable PDU delivery service; information exchange and test functions. The PPP protocol type used by LLC is . The availability of uniform services and PDU formats for all data links should simplify implementation of Network Layer protocols. Operating LLC over PPP extends the set of data link protocols capable of providing this uniformity. DRAFT PROPOSAL LLC over PPP Page 3 A PPP NCP For LLC 7 September 1990 2 A PPP NCP For LLC The LLC Network Control Protocol is responsible for configuring, enabling, and disabling the LLC modules on both ends of the point-to-- point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. These NCP packets may not be exchanged until LCP has reached the network layer Protocol Configuration Negotiation phase. NCP packets received before this phase is reached should be silently discarded. Likewise, LLC PDUs may not be exchanged until the NCP has first opened the connection (reached the Open state). The LLC Network Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one LLC NCP packet is encapsulated in the Information field of PPP data link layer frames where the Protocol field indicates type hex (LLC Network 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 LLC NCP packets may not be exchanged until the Link Control Protocol has reached the Network Layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing 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 Currently, the LLC NCP has no Configuration Options defined. 2.1 Sending LLC PDUs Before any LLC PDUs may be communicated, both the Link Control Protocol and the LLC Network Control Protocol must reach the Open state. DRAFT PROPOSAL LLC over PPP Page 4 A PPP NCP For LLC 7 September 1990 Exactly one LLC PDU is encapsulated in the Information field of PPP data link layer frames where the Protocol field indicates type hex (LLC). The maximum length of a LLC PDU transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. 2.1.1 Format - The format of a PPP frame containing an LLC PDU is +----------+---------+---------+----------+--------+--------+--- | Flag | Address | Control | Protocol | DSAP | SSAP | | 01111110 | 1111111 | 0000011 | 16 bits | 8 bits | 8 bits | +----------+---------+---------+----------+--------+--------+--- -------------------+---------------+---------+----------+ LLC Control | LLC user data | FCS | Flag | 8 bits or 16 bits | N*8 bits | 16 bits | 01111110 | -------------------+---------------+---------+----------+ The fields Flag, Address, Control, Protocol, and FCS are the same as described in the PPP specification. DSAP LLC Destination Service Access Point address. This identifies the LLC user for which the LLC user data field is intended. SSAP LLC Source Service Access Point address. This identifies the LLC user from which the LLC user data field was initiated. LLC Control This indicates the LLC PDU type and function LLC user data This is the data passed to the LLC entity by a user of the LLC. DRAFT PROPOSAL LLC over PPP Page 5 A PPP NCP For LLC 7 September 1990 References [1] Perkins, D., "The Point-to-Point Protocol: A Proposed Standard for the Transmission of Multi-Protocol Datagrams Over Point-to-- Point Links", Internet Draft, IETF, April 1990. [2] Perkins, D., "The Point-to-Point Protocol (PPP) Initial Configuration Options", Internet Draft, IETF, April 1990. [3] IEEE, "IEEE 802.2: Logical Link Control", IEEE Std. 802.2-1985 (ISO 8802/2). Chairman's Address This proposal is within the purview of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair: Stev Knowles FTP Software 26 Princess Street Wakefield, MA 01880-3004 Phone: (617) 246-0900 x270 EMail: Stev@FTP.com Author's Address Questions about this memo can also be directed to the author: Arthur Harvey Digital Equipment Corporation 550 King Street, LKG1-2/A19 Littleton, MA 01460-1289 Phone: (508) 486-7647 EMail: Harvey@gah.enet.dec.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 7 13:13:40 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02986; Fri, 7 Sep 90 12:32:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from decpa.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02856; Fri, 7 Sep 90 12:28:11 -0700 Received: by decpa.pa.dec.com; id AA21899; Fri, 7 Sep 90 12:27:05 -0700 Message-Id: <9009071927.AA21899@decpa.pa.dec.com> Received: from gah.enet; by decwrl.enet; Fri, 7 Sep 90 12:27:15 PDT Date: Fri, 7 Sep 90 12:27:15 PDT From: "Arthur Harvey, 226-7647, LKG1-2/A19" To: ietf-ppp@ucdavis.edu Subject: Updated draft of Configuration Option negotiation for 32-bit FCS Status: O The Point-to-Point Protocol Configuration Options: Negotiation of 32-bit FCS DRAFT PROPOSAL Abstract The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: 1. A method for encapsulating datagrams over serial links. 2. An extensible Link Control Protocol (LCP). 3. A family of Network Control Protocols (NCP) for establishing and configuring different network layer protocols. The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called the IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol (PPP) [1]. This document defines a method to negotiate a 32-bit FCS Configuration Option for PPP. Status of this memo This draft document is for review by the PPP Working Group of the IETF. Distribution of this memo is unlimited. Please send comments to the author. 1 Introduction As described in [1], Link Control Protocol (LCP) Configuration Options allow modifications to the standard characteristics of a point-to-- point link to be negotiated. Reference [2] describes the initial DRAFT PROPOSAL 32-bit FCS Option for PPP Page 2 Introduction 23 August 1990 configuration options for PPP. This document describes a method for negotiating a 32-bit FCS Configuration Option to improve the error detection guarantees provided by PPP. 2 Description The default frame check for PPP is defined to be a 16-bit FCS. The use of a 32-bit FCS will improve the error detection guarantees provided by PPP, but, both PPP entities must agree on the FCS size. Frames transmitted under one FCS type will result in an FCS failure if received under the other FCS. In principle, the LCP can be used to negotiate the FCS size. The LCP frames, however, carry an FCS and cannot be received unless the frames pass the frame check at the receiver. Normally, this requires that the receiving station is operating the same FCS as the transmitter. Fortunately, it is possible to generate a frame which will pass the frame check for both the 16-bit FCS and the 32-bit FCS. 2.1 Generating and Checking the FCS This section describes the generation and checking of an "n"-bit FCS. A sequence of bits is described in terms of a polynomial where the coefficient of "x^i" indicates the value of bit "i". Thus, the bit pattern 101001 is represented by the polynomial x^5 + x^3 + 1 The notation "x^n ...1" represents the polynomial for which all coefficients from "x^n" down to "x^0" are 1. This corresponds to a bit pattern of "n+1" consecutive one bits. The following polynomials are defined for an "n"-bit FCS. 1. The initializing polynomial, In. 2. The generating polynomial, Gn. 3. The complementing polynomial, Cn. 4. The result polynomial, Rn. This has the value (Cn * x^n) mod Gn. The "n"-bit FCS, Fn, for the message portion of a frame (represented by the polynomial Mk of length "k" bits) is the sum (modulo 2) of DRAFT PROPOSAL 32-bit FCS Option for PPP Page 3 Description 23 August 1990 1. the remainder of x^k * In divided (modulo 2) by Gn, 2. the remainder of x^n * Mk divided (modulo 2) by Gn, 3. and Cn. The frame transmitted, Tj (where j=k+n), is then represented as follows Tj = Mk * x^n + Fn The received frame, Tj, is checked to detect transmission errors by forming the sum (modulo 2) of 1. the remainder of x^j * In divided (modulo 2) by Gn, 2. the remainder of x^n * Tj divided (modulo 2) by Gn. The frame is valid if the above sum is equal to Rn. 2.2 The 16-bit FCS polynomials I16 = x^15 ...1 G16 = x^15 + x^12 + x^5 + 1 C16 = x^15 ...1 R16 = x^12 + x^11 + x^10 + x^8 + x^3 + x^2 + x + 1 2.3 The 32-bit FCS polynomials I32 = x^31 ...1 G32 = x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1 C32 = x^31 ...1 R32 = x^31 + x^30 + x^26 + x^25 + x^24 + x^18 + x^15 + x^14 + x^12 + x^11 + x^10 + x^8 + x^6 + x^5 + x^4 + x^3 + x^2 + x + 1 DRAFT PROPOSAL 32-bit FCS Option for PPP Page 4 Description 23 August 1990 2.4 The 48-bit FCS polynomials To generate a frame with a 48-bit FCS which is valid when checked using either 16-bit or 32-bit polynomials, the operations described previously for generating an "n"-bit FCS are performed using the following polynomials. I48 = x^47 + x^46 + x^43 + x^42 + x^39 + x^37 + x^34 + x^32 + x^31 + x^30 + x^29 + x^27 + x^25 + x^23 + x^22 + x^21 + x^20 + x^19 + x^17 + x^16 + x^15 + x^11 + x^10 + x^9 + x^8 + x^5 + x^4 + x^2 + x + 1 G48 = x^48 + x^44 + x^42 + x^39 + x^37 + x^35 + x^34 + x^31 + x^28 + x^23 + x^19 + x^18 + x^17 + x^15 + x^14 + x^12 + x^11 + x^9 + x^8 + x^6 + x^4 + x^2 + x + 1 C48 = x^45 + x^44 + x^41 + x^40 + x^38 + x^36 + x^35 + x^33 + x^31 + x^30 + x^29 + x^27 + x^25 + x^23 + x^22 + x^21 + x^20 + x^19 + x^17 + x^16 + x^14 + x^13 + x^12 + x^7 + x^6 + x^3 2.5 Derivation of the 48-bit polynomials The generator polynomial G48 is the product (modulo 2) of the 16-bit and 32-bit generator polynomials. G48 = G16 * G32 The initializing and complementing polynomials are chosen so that they solve the following equations. C48 mod G16 = C16 C48 mod G32 = C32 I48 mod G16 = I16 * x^32 I48 mod G32 = I32 * x^16 2.6 Implementation and Operation The 48-bit FCS can be computed in exactly the same way as the 16-bit and 32-bit FCSs using suitable hardware or software. The polynomials I48, G48 and C48 are used, and the generated 48-bit FCS may be appended to the message for transmission. However, most hardware is designed to operate with only a 16-bit or 32-bit register and will not be capable of performing the 48-bit operations. In this case, it is necessary to perform the FCS computation by software. Fortunately, it is not necessary to bypass the hardware FCS generation and transmit the 48-bit FCS frame directly. If the transmission hardware is DRAFT PROPOSAL 32-bit FCS Option for PPP Page 5 Description 23 August 1990 operating in 16-bit FCS generation mode, then the leading 32 bits of the 48-bit FCS can be appended to the original message of length "k" and the new message of length (k + 32) passed through the 16-bit FCS generation hardware. The resultant (k + 48)-bit message will be the same as that produced by appending the 48-bit FCS to the original message. Similarly, if the transmission hardware is operating in 32-bit FCS generation mode, then the leading 16 bits of the 48-bit FCS can be appended to the original message of length "k" and the new message of length (k + 16) passed through the 32-bit FCS generation hardware. The resultant (k + 48)-bit message will again be the same as that produced by appending the 48-bit FCS to the original message. A PPP station attempting to negotiate the 32-bit FCS must append the 48-bit FCS to all frames until the LCP handshake completes and the link enters the Open state. Frames sent when the link is in the Open state may contain either the negotiated FCS or the 48-bit FCS. Note that the receiver must treat as padding the part of the 48-bit FCS that precedes the expected 16-bit or 32-bit FCS field. Thus, a receiver operating the 16-bit FCS will handle the initial 32 bits of the 48-bit FCS as padding. Similarly, a receiver operating the 32-bit FCS will handle the initial 16 bits of the 48-bit FCS as padding. 3 Format A summary of the 32-bit FCS 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 Length 2 Default 16-bit FCS. DRAFT PROPOSAL 32-bit FCS Option for PPP Page 6 Format 23 August 1990 References [1] Perkins, D., "The Point-to-Point Protocol: A Proposed Standard for the Transmission of Multi-Protocol Datagrams Over Point-to-- Point Links", Internet Draft, IETF, April 1990. [2] Perkins, D., "The Point-to-Point Protocol (PPP) Initial Configuration Options", Internet Draft, IETF, April 1990. Chairman's Address This proposal is within the purview of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair: Stev Knowles FTP Software 26 Princess Street Wakefield, MA 01880-3004 Phone: (617) 246-0900 x290 EMail: Stev@FTP.com Author's Address Questions about this memo can also be directed to the author: Arthur Harvey Digital Equipment Corporation 550 King Street, LKG1-2/A19 Littleton, MA 01460-1289 Phone: (508) 486-7647 EMail: Harvey@gah.enet.dec.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 12 11:19:23 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01839; Wed, 12 Sep 90 11:04:05 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01699; Wed, 12 Sep 90 10:54:34 -0700 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA27694; Wed, 12 Sep 90 13:54:01 -0500 Date: Wed, 12 Sep 90 13:54:01 -0500 Message-Id: <9009121854.AA27694@ftp.com> To: ietf-ppp@ucdavis.edu Subject: Re: at too long last... From: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com Status: O i realize this is late. sorry . . . . . Minutes of the Internet Point to Point Working Group UBC IETF Point to Point MIB: Discussion ensued on statistics per protocol per interface. Is there duplication of objects, or a breakage of precedent? The general feeling was that there is need for counts by protocol, precendent or not, and that only some protocols are duplicated elsewhere. Therefore the MIB should contain counts by protocol. AppleTalk: Frank Slaughter and Steve Senum have differing approaches to Appletalk. Frank's includes a reduced verhead routing information transfer protocol. They are to coalesce their documents and put them up to the list. DECNET IV: At first blush, it would appear that Art Harvey and Steve Senum have dueling documents; however, this appears to be related to several miscommunications. Art, given certain modifications, is willing to see Steve's document as the standard. There are a number of problems with the use of timers in the protocol, resulting primarily from Digital's assumption that a reliable protocol such as LAPB is in use on the line. This will cause problems on unreliable links. A General Note: Large interest is reported for Point-to-Point Host to Router implementations over a dial interface. This, according ot Vicki Ralls, is most of the interest cisco has seen in the protocol. Art Harvey's proposal for SNAP over Point-to-Point The general feeling is that there is no overriding reason to stop the document, so we should let it become a standard for generalized use of the link. Bridge Protocol Fred Baker submitted an alternative approach to bridge use of the link. This was generally considered superior to the approach requested by the Pittsburg IETF attendees. A document will be published. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 14 19:00:41 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12982; Fri, 14 Sep 90 18:45:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12864; Fri, 14 Sep 90 18:33:58 -0700 Received: from VitaM6.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA08316; Fri, 14 Sep 90 21:33:32 -0400 Message-Id: <9009150133.AA08316@uunet.uu.net> Date: Fri, 14 Sep 90 18:25:56 PDT From: VitaM6!baker@uunet.UU.NET (Fred Baker) To: uunet!"ietf-ppp@ucdavis.edu"@uunet.UU.NET Subject: Bridging PPP Protocol Redux Status: O Would yo mind looking this over and commenting on it? It is what we discussed in the UBC IETF with mods as discussed. Fred Baker baker@vitalink.com ---------------------snip--snip--snip--snip--------------------- Internet Draft Bridging Point to Point Protocol September 1990 Point to Point Protocol Extensions for Bridging Fri Sep 14 17:42:31 PDT 1990 Point to Point Working Group F. Baker Vitalink Communications Corporation 6607 Kaiser Drive Fremont California 94555 baker@vitalink.com 1. Status of this Memo This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the author. It is an extension of the Internet Point-to-Point Protocol described in RFC 1171, targeting the use of Point-to-Point lines for Remote Bridging. 2. Historical Perspective Two basic algorithms are ambient in the industry for Bridging of Local Area Networks. The more common algorithm is called "Transparent Bridging", and has been standardized for Extended LAN configurations by IEEE 802.1. IEEE 802.5 has proposed an alternative approach, called "Source Routing", and is in the process of standardizing that approach for IEEE 802.5 extended networks. Although there is a subcommittee of IEEE 802.1 addressing remote bridging, neither standard directly defines Remote Bridging per se, as that would technically be beyond the IEEE 802 committee's charter. Both allow for it, however, modeling the line as an unspecified interface between half-bridges. This document assumes that the devices at either end of a serial link - have agreed to utilize the RFC 1171 line discipline in some form - may have agreed, by some other means, to exchange other protocols on the line interspersed with each other and with any bridged PDUs, F Baker [Page 1] Internet Draft Bridging Point to Point Protocol September 1990 - may be willing to use the link as a vehicle for Remote Bridging. - may have multiple point-to-point links that are configured in parallel to simulate a single line of higher speed or reliability, but message sequence issues are solved by the transmitting end. 3. General Considerations 3.1. Link Quality Monitoring It is strongly recommended that Point-to-Point Bridge Protocol implementations utilize Magic Number Loopback Detection and Link-Quality-Monitoring. This is because the 802.1 Spanning Tree protocol, which is integral to both Transparent Bridging and Source Routing (as standardized), is unidirectional during normal operation, with HELLO PDUs emanating from the Root System in the general direction of the leaves, without any reverse traffic except in response to network events. 3.2. Message Sequence The multiple link case requires consideration of message sequentiality. The transmitting station must determine either that the protocol being bridged requires transmissions to arrive in the order of their original transmission, and enqueue all transmissions on a given conversation onto the same link to force order preservation, or that the protocol does NOT require transmissions to arrive in the order of their original transmission, and use that knowledge to optimize the utilization of the several links, enqueuing traffic to links to minimize delay. In the absence of such a determination, the transmitting station must act as though all protocols require order preservation; many protocols designed primarily for use on a single LAN in fact do. A protocol could be described to maintain message sequentiality across multiple links, either by sequence numbering or by fragmentation and re-assembly, but this is neither elegant nor absolutely necessary. 3.3. Separation of Spanning Tree Domains It is conceivable that a network manager might wish to inhibit the exchange of BPDUs on a link in order to logically divide two regions into separate Spanning Trees with different Roots (and potentially different Spanning Tree implementations or algorithms). In order to do that, he must configure both ends to not exchange BPDUs on a link. For the sake of robustness, a bridge which is so configured must silently discard the BPDU of its neighbor, should it receive one. F Baker [Page 2] Internet Draft Bridging Point to Point Protocol September 1990 4. IEEE 802.1 Transparent Bridging 4.1. Overview of IEEE 802.1 Transparent Bridging As a favor to the uninitiated, let us first describe Transparent Bridging. Essentially, the bridges in a network operate as isolated entities, largely unaware of each others' presence. A Transparent Bridge maintains a Forwarding Database consisting of {address, interface} records by saving the Source Address of each LAN transmission that it receives along with the interface identifier for the interface it was received on. It goes on to check whether the Destination Address is in the database, and if so, either discards the message (if the destination and source are located at the same interface) or forwards the message to the indicated interface. A message whose Destination Address is not found in the table is forwarded to all interfaces except the one it was received on; this describes Broadcast/Multicast behavior as well. The obvious fly in the ointment is that redundant paths in the network cause indeterminate (nay, all too determinate) forwarding behavior to occur. To prevent this, a protocol called the IEEE 802.1(d) Spanning Tree Protocol is executed between the bridges to detect and logically remove redundant paths from the network. One system is elected as the "Root", which periodically emits a message called a Bridge Hello Protocol Data Unit, or BPDU, heard by all of its neighboring bridges. Each of these modifies and passes the BPDU on to its neighbors, and they to theirs, until it arrives at the leaf LAN segments in the network (where it dies, having no further neighbors to pass it along) or until the message is stopped by a bridge which has a superior path to the "Root". In this latter case, the interface the BPDU was received on is ignored (ie, it is placed in a Hot Standby status, no traffic emitted onto it except the BPDU, and all traffic received from it is discarded) until a topology change forces a recalculation of the network. 4.2. IEEE 802.1 Remote Bridging Activity There exist two basic sorts of bridges - ones that interconnect LANs directly, called Local Bridges, and ones that interconnect LANs via an intermediate medium such as a leased line, called Remote Bridges. The Point-to-Point Protocol might be used by a Remote Bridge. There is more than one proposal within the IEEE 802.1 Interworking Committee for modeling the Remote Bridge. In one F Baker [Page 3] Internet Draft Bridging Point to Point Protocol September 1990 model, the interconnecting serial link(s) are treated in the same way that a LAN is, having a standard IEEE 802.1 Link State; in another, the serial links operate in a mode quite different from the LANs that they interconnect. For the sake of simplicity of specification, the first model is adopted, although some of the good ideas from proponents of the second model are included or allowed for. Therefore, given that transparent bridging is configured on a line or set of lines, the specifics of the link state with respect to the bridge is defined by IEEE 802.1(d). The Bridge Protocol Data Unit, or BPDU, is defined there, as well as the algorithms for its use. It is assumed that, if a Point-to-Point Link neighbor receives IEEE 802.1 BPDUs without rejecting them with the RFC 1171 Protocol-Reject LCP PDU, Transparent Bridging is permitted on the link. 4.3. IEEE 802.5 Source Routing The IEEE 802.5 Committee has defined a different approach to bridging for use on the Token Ring, called Source Routing. In this approach, the originating system has the responsibility of indicating what path that the message should follow. It does this, if the message is directed off the local ring, by including a variable length MAC header extension called the Routing Information Field, or RIF. The RIF consists of one 16 bit word of flags and parameters followed by zero or more ring-and-bridge identifiers. Each bridge en route determines from this 'source route list' whether it should receive the message and how to forward it on. The algorithm for Source Routing requires the bridge to be able to identify any interface by its ring-and-bridge identifier, and to be able to identify any of its OTHER interfaces likewise. When a packet is received which has the Routing Information Field (RIF) present, a boolean in the RIF is inspected to determine whether the ring-and-bridge identifiers are to be inspected in "forward" or "reverse" sense. In a "forward" search, the bridge looks for the ring- and-bridge identifier of the interface the packet was received on, and forwards the packet toward the ring identified in the ring-and-bridge identifier that follows it. In a "reverse" search, the bridge looks for the ring-and-bridge identifier of the OTHER INTERFACE, and delivers the packet to the indicated interface if such is found. The algorithms for handling multicasts ("Functional Addresses" and "Group Addresses") have been the subject of much discussion in 802.5, and are likely to be the most troublesome for bridge implementations. Fortunately, they are beyond the scope of this document. F Baker [Page 4] Internet Draft Bridging Point to Point Protocol September 1990 4.4. IEEE 802.5 Remote Bridging Activity There is no Remote Bridge proposal in IEEE 802.5 at this time, although IBM ships a remote Source Routing Bridge. Simplicity would dictate that we choose the same model for IEEE 802.5 Source Routing that was selected for IEEE 802.1, but necessity requires a ring number for the line in some cases. We allow for both models. Given that source routing is configured on a line or set of lines, the specifics of the link state with respect to the bridge is defined by the IEEE 802.5 Addendum on Source Routing. The requisite PDUs for calculating the spanning tree (used for assuring that each ring will receive at most one copy of a multicast) are defined there, as well as the algorithms for their use. MAC PDUs (Beacon, Ring Management, etc) are specific to the MAU technology and are not exchanged on the line. 4.5. Source Routing to Transparent Bridge Translation IEEE 802 also has a subcommittee looking at the interoperation of Transparent Bridging and Source Routing. For the purposes of this standard, such a device is both a transparent and a source routing bridge, and will act on the line in both ways, just as it does on the LAN. F Baker [Page 5] Internet Draft Bridging Point to Point Protocol September 1990 5. Traffic Services Several services are provided for the benefit of different system types and user configurations. These include LAN Frame Checksum Preservation, LAN Frame Checksum Generation, Tinygram Compression, and the identification of closed sets of LANs. 5.1. LAN Frame Checksum Preservation IEEE 802.1 stipulates that the Extended LAN must enjoy the same probability of undetected error that an individual LAN enjoys. Although there has been considerable debate concerning the algorithm, no other algorithm has been proposed than having the LAN Frame Checksum received by the ultimate receiver be the same value calculated by the original transmitter. Achieving this requires, of course, that the line protocols preserve the LAN Frame Checksum from end to end. The protocol is optimized towards this approach. 5.2. Traffic having no LAN Frame Checksum The fact that the protocol is optimized towards LAN Frame Checksum preservation raises twin questions: "What is the approach to be used by systems which, for whatever reason, cannot easily support Frame Checksum preservation?" and "What is the approach to be used when the system originates a message, which therefore has no Frame Checksum precalculated?". Surely, one approach would be to require stations to calculate the Frame Checksum in software if hardware support were unavailable; this would meet with profound dismay, and would raise serious questions of interpretation in a Bridge/Router. However, stations which implement LAN Frame Checksum preservation must already solve this problem, as they do originate traffic. Therefore, the solution adopted is that messages which have no Frame Checksum are tagged and carried across the line. When a system which does not implement LAN Frame Checksum preservation receives a frame having an embedded FCS, it converts it for its own use by removing the trailing four octets. When any system forwards a frame which contains no embedded FCS to a LAN, it forwards it in a way which causes the FCS to be calculated. 5.3. Tinygram Compression An issue in remote Ethernet bridging is that the protocols that are most attractive to bridge are prone to problems on low speed (64 KBPS and below) lines. This can be partially alleviated by observing that the vendors defining these F Baker [Page 6] Internet Draft Bridging Point to Point Protocol September 1990 protocols often fill the PDU pad with octets of ZERO. Thus, an Ethernet or IEEE 802.3 PDU received from a line that is (1) smaller than the minimum PDU size, and (2) has a LAN Frame Checksum present, must be padded by inserting zeroes between the last four octets and the rest of the PDU before transmitting it on a LAN. These protocols are frequently used for interactive sessions, and therefore are frequently this small. To prevent ambiguity, PDUs requiring padding are explicitly tagged, and all bridges are required to implement the decompression algorithm. Compression is at the option of the transmitting station, and is probably performed only on low speed lines, perhaps under configuration control. 5.4. LAN Identification In some applications, it is useful to tag traffic by the user community it is a part of, and guarantee that it will be only emitted onto a LAN which is of the same community. The user community is defined by a LAN ID. Systems which choose to not implement this feature must assume that any frame received having a LAN ID is from a different community than theirs, and discard it. F Baker [Page 7] Internet Draft Bridging Point to Point Protocol September 1990 6. Protocol Data Unit Formats 6.1. Common LAN Traffic Figure 1: 802.3 Frame format 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x31 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | MAC type | LAN ID high word (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN ID low word (optional) | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address | Length/Type + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | potential pad octets + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For Bridging LAN traffic, the format of the frame on the line is as shown in figure 1 or figure 2. This is conformant to RFC 1171 section 3.1 "Frame Format". It also allows for RFC 1172 negotiation of Protocol Field Compression and Address and Control Field Compression. It is recommended that devices which use controllers that require even memory addresses negotiate to NOT USE Protocol Field Compression on other than low speed links. F Baker [Page 8] Internet Draft Bridging Point to Point Protocol September 1990 Figure 2: 802.4/802.5/FDDI Frame format 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x31 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | flags | MAC type | LAN ID high word (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN ID low word (optional) | Pad Byte | Frame Control + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | potential pad octets + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of this message are as follows: Address Field and Control Field: As defined by RFC 1171 Protocol Field: 0x0031 Services: bit 0: Set if IEEE 802.3 Pad must be zero filled bit 1: Set if the LAN ID Field is present bit 2: Set if the LAN FCS Field is present bits 7-5: Number of trailing "pad" octets others: Reserved The "number of trailing "pad" octets is a deference to the fact that any point to point frame may have padding at the end. This number tells the receiving system how many octets to strip off the end. F Baker [Page 9] Internet Draft Bridging Point to Point Protocol September 1990 Bridged Protocol Header Format: 0: Reserved 1: IEEE 802.3/Ethernet 2: IEEE 802.4 3: IEEE 802.5 4: FDDI other: Assigned by the Internet Assigned Numbers Authority This optional 32 bit field identifies the Community of LANs which may be interested to receive this frame, as described in section 5.4. MAC Frame: It is considered good form to include a MAC frame. This is that portion of the frame which is (or would be were it present) protected by the LAN FCS; for example, the 802.5 Access Control field, and Status Trailer are not meaningful to transmit to another ring, and are omitted. In the illustrations, the MAC frame has details of the MAC header and data layout present. The reader will understand. LAN Frame Checksum: If present, this is the LAN FCS which was calculated by (or which appears to have been calculated by) the originating station. CRC-CCITT Mentioned primarily for clarity. The CRC used on the PPP link is separate from and unrelated to the LAN FCS. F Baker [Page 10] Internet Draft Bridging Point to Point Protocol September 1990 6.2. IEEE 802.1 Bridge This is the BPDU as defined by IEEE 802.1(d), without any MAC or 802.2 LLC header (these being functionally equivalent to the Address, Control, and Protocol Fields). The LAN Pad and Frame Checksum fields are likewise superfluous and absent. The Address and Control Fields are optional, subject to the Address and Control Field Compression negotiation. Figure 3: Bridge "Hello" PDU 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x02 | 0x01 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPDU data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of this message are as follows: Address Field and Control Field: As defined by RFC 1171 Protocol Field: 0x0201 MAC Frame: 802.1(d) BPDU F Baker [Page 11] Internet Draft Bridging Point to Point Protocol September 1990 6.3. IEEE 802 Network Control Protocol The Bridge Network Control Protocol is responsible for configuring, enabling, and disabling the bridges on both ends of the point-to-point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. BNCP packets may not be exchanged until LCP has reached the network-layer Protocol Configuration Negotiation phase. Likewise, LAN traffic may not be exchanged until BNCP has first opened the connection. The Bridge Network Control Protocol is exactly the same as the Point-to-Point Link Control Protocol with the following exceptions: Data Link Layer Protocol Field Exactly one Bridge Network Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8031 (BNCP). 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 BNCP packets may not be exchanged until the Link Control Protocol has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing to finish before timing out waiting for 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 The Bridge Network Control Protocol has a separate set of Configuration Options. F Baker [Page 12] Internet Draft Bridging Point to Point Protocol September 1990 6.4. IEEE 802.5 Remote Ring Identification Option Since the Remote Bridges are modeled as normal Bridges with a strange internal interface, each bridge needs to know the ring/bridge numbers of the bridges it is adjacent to. This is the subject of a Link Negotiation. The exchange of ring-and- bridge identifiers is done using this option on the Network Control Protocol. The Token Ring Ring-and-Bridge Identifier, and its use, is specified by the IEEE 802.5 Addendum on Source Routing. It identifies the ring that the interface is attached to by its configured ring number, and itself by bridge number on the ring. Figure 4: Remote Ring Identification Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=1 |length = 4 | ring number |bridge#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 = IEEE 802.5 Source Routing Ring/Bridge Identifier Length 4 Octets Ring Number A 12 bit number identifying the token ring, as defined in the IEEE 802.5 Source Routing Specification. Bridge Number A 4 bit number identifying the bridge on the token ring, as defined in the IEEE 802.5 Source Routing Specification. F Baker [Page 13] Internet Draft Bridging Point to Point Protocol September 1990 6.5. IEEE 802.5 Line Identification Option This option permits the systems to treat the line as a visible "Token Ring", in accordance with the Source Routing algorithm. The bridges exchange ring-and-bridge identifiers using this option on the Network Control Protocol. The configured ring numbers must be identical in normal operation. The Token Ring Ring-and-Bridge Identifier, and its use, is specified by the IEEE 802.5 Addendum on Source Routing. It identifies the ring that the interface is attached to by its configured ring number, and itself by bridge number on the ring. Figure 5: Line Identification Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=2 |length = 4 | ring number |bridge#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 = IEEE 802.5 Line "Ring/Bridge" Identifier Length 4 Octets Ring Number A 12 bit number identifying the line, as defined in the IEEE 802.5 Source Routing Specification. Bridge Number A 4 bit number identifying the bridge on the token ring, as defined in the IEEE 802.5 Source Routing Specification. F Baker [Page 14] From ietf-ppp-request@ucdavis.ucdavis.edu Mon Sep 17 22:46:43 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13847; Mon, 17 Sep 90 22:32:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from PO2.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13691; Mon, 17 Sep 90 22:24:52 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Tue, 18 Sep 90 01:24:21 EDT Received: via switchmail; Tue, 18 Sep 90 01:24:17 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 18 Sep 90 01:23:12 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 18 Sep 90 01:23:07 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Tue, 18 Sep 90 01:23:05 -0400 (EDT) Message-Id: Date: Tue, 18 Sep 90 01:23:05 -0400 (EDT) From: Drew Daniel Perkins To: ietf-ppp@ucdavis.edu Subject: Re: Bridging PPP Proposal Redux In-Reply-To: <9007262115.AA26586@uunet.uu.net> References: <9007262115.AA26586@uunet.uu.net> Status: O I have a few comments on the new proposal. Overall, it looks like a lot of good improvements were made. 5.3 Tinygram Compression: This only directly describes what the receiver does for decompression. It does not directly describe how a transmitter decides to compress. At first it seems that the transmitter would just go backwards from the end of the packet and count zero bytes until it found a non-zero byte. This absolutely assumes that implementations will actually bother to zero the pad octets, which I strongly doubt. I think there may be other, possibly less kosher, uses for compression. What if you have a real 802.3 packet with a length field indicating a short packet? Can I compress these even if I have non-zero octets? Also, what if the bridge has a small amount of protocol-specific knowledge, enough for example to know how much of an ARP packet is padding? Can I pad these anyway? 5.4 LAN Identification I think this assumes, without stating it, that each box MUST have a LAN ID configured. 6.1 Common LAN Traffic The "potential pad octets" field in the pictures were very confusing to me. It took me a while to figure out that you meant the optional standard PPP framing pad octets vs. special ones for bridging. This should be made more clear. Also, you use the field "flags" in the picture, but "Services" in the text. Some of the other fields are inconsistent between the figures and the text. Each of the fields should be described in text to eliminate confusion. Finally, the bits 7-5 in the Services field indicate the number of trailing pad octets. This seems to me to be a gross violation of layering. Unfortunately, the only suggestion I have is to add an explicit length field to the packet. Drew From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 18 10:46:26 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22245; Tue, 18 Sep 90 10:30:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21977; Tue, 18 Sep 90 10:16:39 -0700 Received: from VitaM6.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA07454; Tue, 18 Sep 90 13:16:15 -0400 Message-Id: <9009181716.AA07454@uunet.uu.net> Date: Tue, 18 Sep 90 10:13:12 PDT From: VitaM6!baker@uunet.UU.NET (Fred Baker) To: uunet!"ietf-ppp@ucdavis.edu"@uunet.UU.NET Subject: PPP Bridging Status: O Drew: Thanks for your comments/questions In 5.3, I am describing what Vitalink does, called "LAT Compression". It has proven to be a very useful service; Scott Bradner recently inquired about it, because we were the "only people who seem to be able to make LAT work over low speed lines". Unfortunately, cutting back to the 802.3 length doesn't work unless the LAN FCS is discounted; one must be able re-create the data that was compressed out in order for the LAN FCS to be valid end to end. Realizing that end to end FCS is not a viable question in a routing world, it is something that is addressed by other means - eg, the TCP and UDP checksums, etc. In a bridge world, end to end FCS sells systems, because architects (especially at Digital) and customers seem to really like the idea of nearly certifiable correctness. In point of fact, we know of several vendors that DO zero their buffers (folks who like to make it easy to sell into the security world, especially), and I can assure you that LAT is generally zero filled. Section 5.4 was requested by Steve Senum at Network Systems, and addresses a particular requirement that some of their customers are asking for. Yes, if the LAN ID option is going to be useful, and LAN ID must be configured. However, it is quite possible that systems having LAN IDs configured and systems without might share a backbone, with traffic between systems of the latter type connected by systems of the former. 6.1: Steve Senum and I go back and forth on this one. The issue, of course, is that the PPP spec rather broadly assumed that every protocol it carried had a way to determine the length of its PDUs, which is somewhat presumptive. I would, however, be curious to understand this "layer violation". It seems to me that, if PPP is considered a black box, and a packet of length is stuffed into it on one side, a packet of the same length should blump out on the other. If the protocol driver adds some number of octets (let's say in order to DES encode it, or to make it work nicely with 16 bit wide data link controllers), it is not a layer violation for it to tag the message with the number of added octets for the purpose of effecting correct delivery... Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 18 12:45:35 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24216; Tue, 18 Sep 90 12:34:35 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23919; Tue, 18 Sep 90 12:17:59 -0700 Received: from VitaM6.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA16749; Tue, 18 Sep 90 15:17:28 -0400 Message-Id: <9009181917.AA16749@uunet.uu.net> Date: Tue, 18 Sep 90 12:10:34 PDT From: VitaM6!baker@uunet.UU.NET (Fred Baker) To: uunet!"ietf-ppp@ucdavis.edu"@uunet.UU.NET Subject: PPP Bridging Status: O This addresses Steve and Drew's comments, I think: -----------------snip--snip--hack--tear------------------------------- Internet Draft Bridging Point to Point Protocol September 1990 Point to Point Protocol Extensions for Bridging Tue Sep 18 12:08:53 PDT 1990 Point to Point Working Group F. Baker Vitalink Communications Corporation 6607 Kaiser Drive Fremont California 94555 baker@vitalink.com 1. Status of this Memo This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the author. It is an extension of the Internet Point-to-Point Protocol described in RFC 1171, targeting the use of Point-to-Point lines for Remote Bridging. 2. Historical Perspective Two basic algorithms are ambient in the industry for Bridging of Local Area Networks. The more common algorithm is called "Transparent Bridging", and has been standardized for Extended LAN configurations by IEEE 802.1. IEEE 802.5 has proposed an alternative approach, called "Source Routing", and is in the process of standardizing that approach for IEEE 802.5 extended networks. Although there is a subcommittee of IEEE 802.1 addressing remote bridging, neither standard directly defines Remote Bridging per se, as that would technically be beyond the IEEE 802 committee's charter. Both allow for it, however, modeling the line as an unspecified interface between half-bridges. This document assumes that the devices at either end of a serial link - have agreed to utilize the RFC 1171 line discipline in some form - may have agreed, by some other means, to exchange other protocols on the line interspersed with each other and with any bridged PDUs, F Baker [Page 1] Internet Draft Bridging Point to Point Protocol September 1990 - may be willing to use the link as a vehicle for Remote Bridging. - may have multiple point-to-point links that are configured in parallel to simulate a single line of higher speed or reliability, but message sequence issues are solved by the transmitting end. 3. General Considerations 3.1. Link Quality Monitoring It is strongly recommended that Point-to-Point Bridge Protocol implementations utilize Magic Number Loopback Detection and Link-Quality-Monitoring. This is because the 802.1 Spanning Tree protocol, which is integral to both Transparent Bridging and Source Routing (as standardized), is unidirectional during normal operation, with HELLO PDUs emanating from the Root System in the general direction of the leaves, without any reverse traffic except in response to network events. 3.2. Message Sequence The multiple link case requires consideration of message sequentiality. The transmitting station must determine either that the protocol being bridged requires transmissions to arrive in the order of their original transmission, and enqueue all transmissions on a given conversation onto the same link to force order preservation, or that the protocol does NOT require transmissions to arrive in the order of their original transmission, and use that knowledge to optimize the utilization of the several links, enqueuing traffic to links to minimize delay. In the absence of such a determination, the transmitting station must act as though all protocols require order preservation; many protocols designed primarily for use on a single LAN in fact do. A protocol could be described to maintain message sequentiality across multiple links, either by sequence numbering or by fragmentation and re-assembly, but this is neither elegant nor absolutely necessary. 3.3. Separation of Spanning Tree Domains It is conceivable that a network manager might wish to inhibit the exchange of BPDUs on a link in order to logically divide two regions into separate Spanning Trees with different Roots (and potentially different Spanning Tree implementations or algorithms). In order to do that, he must configure both ends to not exchange BPDUs on a link. For the sake of robustness, a bridge which is so configured must silently discard the BPDU of its neighbor, should it receive one. F Baker [Page 2] Internet Draft Bridging Point to Point Protocol September 1990 4. IEEE 802.1 Transparent Bridging 4.1. Overview of IEEE 802.1 Transparent Bridging As a favor to the uninitiated, let us first describe Transparent Bridging. Essentially, the bridges in a network operate as isolated entities, largely unaware of each others' presence. A Transparent Bridge maintains a Forwarding Database consisting of {address, interface} records by saving the Source Address of each LAN transmission that it receives along with the interface identifier for the interface it was received on. It goes on to check whether the Destination Address is in the database, and if so, either discards the message (if the destination and source are located at the same interface) or forwards the message to the indicated interface. A message whose Destination Address is not found in the table is forwarded to all interfaces except the one it was received on; this describes Broadcast/Multicast behavior as well. The obvious fly in the ointment is that redundant paths in the network cause indeterminate (nay, all too determinate) forwarding behavior to occur. To prevent this, a protocol called the IEEE 802.1(d) Spanning Tree Protocol is executed between the bridges to detect and logically remove redundant paths from the network. One system is elected as the "Root", which periodically emits a message called a Bridge Hello Protocol Data Unit, or BPDU, heard by all of its neighboring bridges. Each of these modifies and passes the BPDU on to its neighbors, and they to theirs, until it arrives at the leaf LAN segments in the network (where it dies, having no further neighbors to pass it along) or until the message is stopped by a bridge which has a superior path to the "Root". In this latter case, the interface the BPDU was received on is ignored (ie, it is placed in a Hot Standby status, no traffic emitted onto it except the BPDU, and all traffic received from it is discarded) until a topology change forces a recalculation of the network. 4.2. IEEE 802.1 Remote Bridging Activity There exist two basic sorts of bridges - ones that interconnect LANs directly, called Local Bridges, and ones that interconnect LANs via an intermediate medium such as a leased line, called Remote Bridges. The Point-to-Point Protocol might be used by a Remote Bridge. There is more than one proposal within the IEEE 802.1 Interworking Committee for modeling the Remote Bridge. In one F Baker [Page 3] Internet Draft Bridging Point to Point Protocol September 1990 model, the interconnecting serial link(s) are treated in the same way that a LAN is, having a standard IEEE 802.1 Link State; in another, the serial links operate in a mode quite different from the LANs that they interconnect. For the sake of simplicity of specification, the first model is adopted, although some of the good ideas from proponents of the second model are included or allowed for. Therefore, given that transparent bridging is configured on a line or set of lines, the specifics of the link state with respect to the bridge is defined by IEEE 802.1(d). The Bridge Protocol Data Unit, or BPDU, is defined there, as well as the algorithms for its use. It is assumed that, if a Point-to-Point Link neighbor receives IEEE 802.1 BPDUs without rejecting them with the RFC 1171 Protocol-Reject LCP PDU, Transparent Bridging is permitted on the link. 4.3. IEEE 802.5 Source Routing The IEEE 802.5 Committee has defined a different approach to bridging for use on the Token Ring, called Source Routing. In this approach, the originating system has the responsibility of indicating what path that the message should follow. It does this, if the message is directed off the local ring, by including a variable length MAC header extension called the Routing Information Field, or RIF. The RIF consists of one 16 bit word of flags and parameters followed by zero or more ring-and-bridge identifiers. Each bridge en route determines from this 'source route list' whether it should receive the message and how to forward it on. The algorithm for Source Routing requires the bridge to be able to identify any interface by its ring-and-bridge identifier, and to be able to identify any of its OTHER interfaces likewise. When a packet is received which has the Routing Information Field (RIF) present, a boolean in the RIF is inspected to determine whether the ring-and-bridge identifiers are to be inspected in "forward" or "reverse" sense. In a "forward" search, the bridge looks for the ring- and-bridge identifier of the interface the packet was received on, and forwards the packet toward the ring identified in the ring-and-bridge identifier that follows it. In a "reverse" search, the bridge looks for the ring-and-bridge identifier of the OTHER INTERFACE, and delivers the packet to the indicated interface if such is found. The algorithms for handling multicasts ("Functional Addresses" and "Group Addresses") have been the subject of much discussion in 802.5, and are likely to be the most troublesome for bridge implementations. Fortunately, they are beyond the scope of this document. F Baker [Page 4] Internet Draft Bridging Point to Point Protocol September 1990 4.4. IEEE 802.5 Remote Bridging Activity There is no Remote Bridge proposal in IEEE 802.5 at this time, although IBM ships a remote Source Routing Bridge. Simplicity would dictate that we choose the same model for IEEE 802.5 Source Routing that was selected for IEEE 802.1, but necessity requires a ring number for the line in some cases. We allow for both models. Given that source routing is configured on a line or set of lines, the specifics of the link state with respect to the bridge is defined by the IEEE 802.5 Addendum on Source Routing. The requisite PDUs for calculating the spanning tree (used for assuring that each ring will receive at most one copy of a multicast) are defined there, as well as the algorithms for their use. MAC PDUs (Beacon, Ring Management, etc) are specific to the MAU technology and are not exchanged on the line. 4.5. Source Routing to Transparent Bridge Translation IEEE 802 also has a subcommittee looking at the interoperation of Transparent Bridging and Source Routing. For the purposes of this standard, such a device is both a transparent and a source routing bridge, and will act on the line in both ways, just as it does on the LAN. F Baker [Page 5] Internet Draft Bridging Point to Point Protocol September 1990 5. Traffic Services Several services are provided for the benefit of different system types and user configurations. These include LAN Frame Checksum Preservation, LAN Frame Checksum Generation, Tinygram Compression, and the identification of closed sets of LANs. 5.1. LAN Frame Checksum Preservation IEEE 802.1 stipulates that the Extended LAN must enjoy the same probability of undetected error that an individual LAN enjoys. Although there has been considerable debate concerning the algorithm, no other algorithm has been proposed than having the LAN Frame Checksum received by the ultimate receiver be the same value calculated by the original transmitter. Achieving this requires, of course, that the line protocols preserve the LAN Frame Checksum from end to end. The protocol is optimized towards this approach. 5.2. Traffic having no LAN Frame Checksum The fact that the protocol is optimized towards LAN Frame Checksum preservation raises twin questions: "What is the approach to be used by systems which, for whatever reason, cannot easily support Frame Checksum preservation?" and "What is the approach to be used when the system originates a message, which therefore has no Frame Checksum precalculated?". Surely, one approach would be to require stations to calculate the Frame Checksum in software if hardware support were unavailable; this would meet with profound dismay, and would raise serious questions of interpretation in a Bridge/Router. However, stations which implement LAN Frame Checksum preservation must already solve this problem, as they do originate traffic. Therefore, the solution adopted is that messages which have no Frame Checksum are tagged and carried across the line. When a system which does not implement LAN Frame Checksum preservation receives a frame having an embedded FCS, it converts it for its own use by removing the trailing four octets. When any system forwards a frame which contains no embedded FCS to a LAN, it forwards it in a way which causes the FCS to be calculated. 5.3. Tinygram Compression An issue in remote Ethernet bridging is that the protocols that are most attractive to bridge are prone to problems on low speed (64 KBPS and below) lines. This can be partially alleviated by observing that the vendors defining these F Baker [Page 6] Internet Draft Bridging Point to Point Protocol September 1990 protocols often fill the PDU pad with octets of ZERO. Thus, an Ethernet or IEEE 802.3 PDU received from a line that is (1) smaller than the minimum PDU size, and (2) has a LAN Frame Checksum present, must be padded by inserting zeroes between the last four octets and the rest of the PDU before transmitting it on a LAN. These protocols are frequently used for interactive sessions, and therefore are frequently this small. To prevent ambiguity, PDUs requiring padding are explicitly tagged, and all bridges are required to implement the decompression algorithm. Compression is at the option of the transmitting station, and is probably performed only on low speed lines, perhaps under configuration control. The psuedo-code in Figure 1 describes the algorithms. 5.4. LAN Identification In some applications, it is useful to tag traffic by the user community it is a part of, and guarantee that it will be only emitted onto a LAN which is of the same community. The user community is defined by a LAN ID. Systems which choose to not implement this feature must assume that any frame received having a LAN ID is from a different community than theirs, and discard it. F Baker [Page 7] Internet Draft Bridging Point to Point Protocol September 1990 Figure 1: Tinygram Compression Psuedo-Code PPP Transmitter: if (ZeroPadCompressionEnabled && BridgedProtocolHeaderFormat == IEEE8023 && PacketLength == Minimum8023PacketLength) { /* * Remove octets of zero between, but not including, * the MAC header, and the LAN FCS. */ Set (ZeroCompressionFlag); if (LAN_FCS_Present) { FCS = TrailingOctets (PDU, 4); UnAppendbuf (4); while (PacketLength > 14 && TrailingOctets (PDU, 1) == 0) UnAppendbuf (1); Appendbuf (4, FCS); } else { while (PacketLength > 14 && TrailingOctets (PDU, 1) == 0) UnAppendbuf (1); } } PPP Receiver: if (ZeroCompressionFlag) { /* Restoring packet to minimum 802.3 length */ Clear (ZeroCompressionFlag); if (LAN_FCS_Present) { FCS = TrailingOctets (PDU, 4); UnAppendbuf (4); Appendbuf (60 - PacketLength, zeroes); Appendbuf (4, FCS); } else { Appendbuf (60 - PacketLength, zeroes); } } F Baker [Page 8] Internet Draft Bridging Point to Point Protocol September 1990 6. Protocol Data Unit Formats 6.1. Common LAN Traffic Figure 2: 802.3 Frame format 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x31 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Count|0|0|F|I|Z| MAC type | LAN ID high word (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN ID low word (optional) | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address | Length/Type + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN FCS (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | potential line protocol pad + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For Bridging LAN traffic, the format of the frame on the line is as shown in Figures 2 or 3. This is conformant to RFC 1171 section 3.1 "Frame Format". It also allows for RFC 1172 negotiation of Protocol Field Compression and Address and Control Field Compression. It is recommended that devices which use controllers that require even memory addresses negotiate to NOT USE Protocol Field Compression on other than low speed links. F Baker [Page 9] Internet Draft Bridging Point to Point Protocol September 1990 Figure 3: 802.4/802.5/FDDI Frame format 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x31 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Count|0|0|F|I|Z| MAC type | LAN ID high word (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN ID low word (optional) | Pad Byte | Frame Control + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | potential line protocol pad + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of this message are as follows: Address Field and Control Field: As defined by RFC 1171 Protocol Field: 0x0031 Flags: bit 0: Set if IEEE 802.3 Pad must be zero filled to minimum size bit 1: Set if the LAN ID Field is present bit 2: Set if the LAN FCS Field is present bits 7-5: length of the line protocol pad field. others: Reserved, The "number of trailing "pad" octets is a deference to the fact that any point to point frame may have padding at the end. This number tells the receiving system how many octets to strip off the end. F Baker [Page 10] Internet Draft Bridging Point to Point Protocol September 1990 MAC type: 0: Reserved 1: IEEE 802.3/Ethernet 2: IEEE 802.4 3: IEEE 802.5 4: FDDI other: Assigned by the Internet Assigned Numbers Authority LAN ID: This optional 32 bit field identifies the Community of LANs which may be interested to receive this frame, as described in section 5.4. If the LAN ID flag is not set, then this field is not present, and the PDU is four octets shorter. Frame Control: On 802.4, 802.5, and FDDI LANs, there are a few octets preceding the Destination MAC Address, one of which is protected by the FCS. A pad octet is present to avoid odd machine address boundary problems. Destination MAC Address: As defined by the IEEE. Since the MAC type field defines the bit ordering, this is sent in MAC order. Source MAC Address: As defined by the IEEE. Since the MAC type field defines the bit ordering, this is sent in MAC order. LLC data: This is the remainder of the MAC frame. This is that portion of the frame which is (or would be were it present) protected by the LAN FCS; for example, the 802.5 Access Control field, and Status Trailer are not meaningful to transmit to another ring, and are omitted. LAN Frame Checksum: If present, this is the LAN FCS which was calculated by (or which appears to have been calculated by) the originating station. If the FCS Present flag is not set, then this field is not present, and the PDU is four octets shorter. Potential Line Pad RFC 1171 specifies that an arbitrary pad can be added after the actual length. The "Count" portion of the flag field contains the length of this pad, and may not exceed 7 octets. CRC-CCITT Mentioned primarily for clarity. The CRC used on the PPP link is separate from and unrelated to the LAN FCS. F Baker [Page 11] Internet Draft Bridging Point to Point Protocol September 1990 6.2. IEEE 802.1 Bridge This is the BPDU as defined by IEEE 802.1(d), without any MAC or 802.2 LLC header (these being functionally equivalent to the Address, Control, and Protocol Fields). The LAN Pad and Frame Checksum fields are likewise superfluous and absent. The Address and Control Fields are optional, subject to the Address and Control Field Compression negotiation. Figure 4: Bridge "Hello" PDU 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x02 | 0x01 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPDU data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of this message are as follows: Address Field and Control Field: As defined by RFC 1171 Protocol Field: 0x0201 MAC Frame: 802.1(d) BPDU F Baker [Page 12] Internet Draft Bridging Point to Point Protocol September 1990 6.3. IEEE 802 Network Control Protocol The Bridge Network Control Protocol is responsible for configuring, enabling, and disabling the bridges on both ends of the point-to-point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. BNCP packets may not be exchanged until LCP has reached the network-layer Protocol Configuration Negotiation phase. Likewise, LAN traffic may not be exchanged until BNCP has first opened the connection. The Bridge Network Control Protocol is exactly the same as the Point-to-Point Link Control Protocol with the following exceptions: Data Link Layer Protocol Field Exactly one Bridge Network Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8031 (BNCP). 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 BNCP packets may not be exchanged until the Link Control Protocol has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing to finish before timing out waiting for 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 The Bridge Network Control Protocol has a separate set of Configuration Options. F Baker [Page 13] Internet Draft Bridging Point to Point Protocol September 1990 6.4. IEEE 802.5 Remote Ring Identification Option Since the Remote Bridges are modeled as normal Bridges with a strange internal interface, each bridge needs to know the ring/bridge numbers of the bridges it is adjacent to. This is the subject of a Link Negotiation. The exchange of ring-and- bridge identifiers is done using this option on the Network Control Protocol. The Token Ring Ring-and-Bridge Identifier, and its use, is specified by the IEEE 802.5 Addendum on Source Routing. It identifies the ring that the interface is attached to by its configured ring number, and itself by bridge number on the ring. Figure 5: Remote Ring Identification Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=1 |length = 4 | ring number |bridge#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 = IEEE 802.5 Source Routing Ring/Bridge Identifier Length 4 Octets Ring Number A 12 bit number identifying the token ring, as defined in the IEEE 802.5 Source Routing Specification. Bridge Number A 4 bit number identifying the bridge on the token ring, as defined in the IEEE 802.5 Source Routing Specification. F Baker [Page 14] Internet Draft Bridging Point to Point Protocol September 1990 6.5. IEEE 802.5 Line Identification Option This option permits the systems to treat the line as a visible "Token Ring", in accordance with the Source Routing algorithm. The bridges exchange ring-and-bridge identifiers using this option on the Network Control Protocol. The configured ring numbers must be identical in normal operation. The Token Ring Ring-and-Bridge Identifier, and its use, is specified by the IEEE 802.5 Addendum on Source Routing. It identifies the ring that the interface is attached to by its configured ring number, and itself by bridge number on the ring. Figure 6: Line Identification Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=2 |length = 4 | ring number |bridge#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 = IEEE 802.5 Line "Ring/Bridge" Identifier Length 4 Octets Ring Number A 12 bit number identifying the line, as defined in the IEEE 802.5 Source Routing Specification. Bridge Number A 4 bit number identifying the bridge on the token ring, as defined in the IEEE 802.5 Source Routing Specification. F Baker [Page 15] From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 18 13:39:42 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24842; Tue, 18 Sep 90 13:20:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from PO9.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24716; Tue, 18 Sep 90 13:13:10 -0700 Received: by po9.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Tue, 18 Sep 90 16:12:18 EDT Received: via switchmail; Tue, 18 Sep 90 16:12:09 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 18 Sep 90 16:10:46 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 18 Sep 90 16:10:42 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Tue, 18 Sep 90 16:10:39 -0400 (EDT) Message-Id: <8axbwzW00iU4Q14tp0@andrew.cmu.edu> Date: Tue, 18 Sep 90 16:10:39 -0400 (EDT) From: Drew Daniel Perkins To: ietf-ppp@ucdavis.edu Subject: Re: PPP Bridging In-Reply-To: <9009181716.AA07454@uunet.uu.net> References: <9009181716.AA07454@uunet.uu.net> Status: O > Excerpts from mail: 18-Sep-90 PPP Bridging Fred Baker@uunet.UU.NET (2236) > Unfortunately, cutting back to the 802.3 length > doesn't work unless the LAN FCS is discounted; Oops, forgot about this unfortunate detail. > Excerpts from mail: 18-Sep-90 PPP Bridging Fred Baker@uunet.UU.NET (2236) > However, it is quite possible that systems having LAN IDs configured and > systems without might share a backbone, with traffic between systems of the > latter type connected by systems of the former. Shouldn't there be a default "unconfigured" LAN ID (like zero)? > Excerpts from mail: 18-Sep-90 PPP Bridging Fred Baker@uunet.UU.NET (2236) I would, however, be curious to understand this "layer violation". I think it is a layering violation because I consider PPP as having two sublayers. I view the Data Link Layer as the entity which provides framing, and I consider adding padding as being a low level framing task. In contrast, I view Bridging along with IP/OSI/Appletalk/etc. as being a separate higher sublayer. Another point is that you are allowed to have more than 7 octets of padding, which breaks your scheme. Drew From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 18 15:01:05 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26223; Tue, 18 Sep 90 14:45:35 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26109; Tue, 18 Sep 90 14:35:43 -0700 Received: from VitaM6.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA08447; Tue, 18 Sep 90 17:35:04 -0400 Message-Id: <9009182135.AA08447@uunet.uu.net> Date: Tue, 18 Sep 90 14:29:56 PDT From: VitaM6!baker@uunet.UU.NET (Fred Baker) To: uunet!"ietf-ppp@ucdavis.edu"@uunet.UU.NET Subject: PPP Bridging Status: O Drew: LAN ID: I guess we could make a LAN ID of zero be "any LAN", equivalent to not having one present at all. Would that accomplish what you are requesting? Layer Violation: Point of Order! Point of Order! If the length of the data in the PDU is the subject of what you are calling the data link layer, it should be solved in the data link layer. I would understand this as being the (Broadcast, UI, Protocol Type) header - you should add a length field to it. Since this is not present, it must be solved by what you are choosing to call the higher layer. If that layer solves it, where is the layer violation? Re: 0..7 octets of trailer. I really don't want to get into another two octets of header for the length field, although I guess I will if I absolutely must. Can you name an implementation that would actually be broken? Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 18 15:46:41 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26922; Tue, 18 Sep 90 15:31:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26777; Tue, 18 Sep 90 15:26:29 -0700 Received: from whizzer.wpd.sgi.com by SGI.COM via SMTP (5.64-bind 1.5+ida/900410.SGI) for ietf-ppp@ucdavis.edu id AA03868; Tue, 18 Sep 90 15:26:05 -0700 Received: from rigden.wpd.sgi.com by whizzer.wpd.sgi.com via SMTP (5.64-bind 1.5+ida/900721.SGI) for sgi.sgi.com!ucdavis.edu!ietf-ppp id AA27642; Tue, 18 Sep 90 15:25:36 -0700 Received: by rigden.wpd.sgi.com (5.52/900721.SGI) for @whizzer.wpd.sgi.com:ietf-ppp@ucdavis.edu id AA28969; Tue, 18 Sep 90 22:25:34 GMT Date: Tue, 18 Sep 90 22:25:34 GMT From: rpw3%rigden.wpd.sgi.com@SGI.COM (Rob Warnock) Message-Id: <9009182225.AA28969@rigden.wpd.sgi.com> To: ietf-ppp@ucdavis.edu Subject: Re: PPP Bridging Status: O +--------------- | Re: 0..7 octets of trailer. I really don't want to get into another two | octets of header for the length field, although I guess I will if I absolutely | must. Can you name an implementation that would actually be broken? | Fred +--------------- Implementations of XTP would probably break. XTP depends on the data link layer providing a reliable length indication. The XTP header itself contains no length field, allowing XTP packets to be generated "on-the-fly" from real-time data... -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 18 17:02:25 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27991; Tue, 18 Sep 90 16:46:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from PO9.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27832; Tue, 18 Sep 90 16:32:27 -0700 Received: by po9.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Tue, 18 Sep 90 19:31:31 EDT Received: via switchmail; Tue, 18 Sep 90 19:31:24 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 18 Sep 90 19:29:39 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 18 Sep 90 19:29:34 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Tue, 18 Sep 90 19:29:27 -0400 (EDT) Message-Id: Date: Tue, 18 Sep 90 19:29:27 -0400 (EDT) From: Drew Daniel Perkins To: ietf-ppp@ucdavis.edu Subject: Re: PPP Bridging In-Reply-To: <9009182135.AA08447@uunet.uu.net> References: <9009182135.AA08447@uunet.uu.net> Status: O > Excerpts from mail: 18-Sep-90 PPP Bridging Fred Baker@uunet.UU.NET (848) > LAN ID: I guess we could make a LAN ID of zero be "any LAN", equivalent to > not having one present at all. Would that accomplish what you are requesting? Yes. > Excerpts from mail: 18-Sep-90 PPP Bridging Fred Baker@uunet.UU.NET (848) > Layer Violation: Point of Order! Point of Order! > If the length of the data in the PDU is the subject of what you are calling > the data link layer, it should be solved in the data link layer. I would > understand this as being the (Broadcast, UI, Protocol Type) header - you > should add a length field to it. Since this is not present, it must be > solved by what you are choosing to call the higher layer. If that layer > solves it, where is the layer violation? You are possibly correct, and this is probably the same argument used by the 802.3 people. However, we went with the Ethernet model instead, and it is too late to change. The violation as I see it is that on transmission your upper bridging layer needs to know what the lower data link layer is going to do, before it does it. With the intended model, the upper bridging level knows on reception what the lower data link layers did because it is the last to be passed the packet. > Excerpts from mail: 18-Sep-90 PPP Bridging Fred Baker@uunet.UU.NET (848) > Re: 0..7 octets of trailer. I really don't want to get into another two > octets of header for the length field, although I guess I will if I absolutely > must. Can you name an implementation that would actually be broken? I can't name an existing implementation that would break, but I really do think you should bite the bullet and put in the other two octets. I admit that I may be standing on religious ground. Drew From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 18 20:15:36 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00377; Tue, 18 Sep 90 19:46:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from PO2.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00327; Tue, 18 Sep 90 19:42:29 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Tue, 18 Sep 90 22:41:58 EDT Received: via switchmail; Tue, 18 Sep 90 22:41:55 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 18 Sep 90 22:40:24 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Tue, 18 Sep 90 22:40:20 -0400 (EDT) Received: from Messages.7.8.N.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.3 via MS.5.6.valkyries.andrew.cmu.edu.pmax_3; Tue, 18 Sep 90 22:40:14 -0400 (EDT) Message-Id: Date: Tue, 18 Sep 90 22:40:14 -0400 (EDT) From: Drew Daniel Perkins To: ietf-ppp@ucdavis.edu Subject: Re: PPP Bridging In-Reply-To: <9009181917.AA16749@uunet.uu.net> References: <9009181917.AA16749@uunet.uu.net> Status: O > Excerpts from mail: 18-Sep-90 PPP Bridging Fred Baker@uunet.UU.NET (29109) > 5.3. Tinygram Compression > Thus, > an Ethernet or IEEE 802.3 PDU received from a line that is (1) > smaller than the minimum PDU size, and (2) has a LAN Frame > Checksum present, must be padded by inserting zeroes between > the last four octets and the rest of the PDU before > transmitting it on a LAN. > To prevent ambiguity, PDUs requiring padding are explicitly > tagged, and all bridges are required to implement the > decompression algorithm. It seems that you may have introduced a bit of ambiguity. What if you receive a packet where (1) and (2) are true but there is no explicit tag? The liberal reception principle would seem to indicate that you decompress anyway and perhaps increment a soft error counter. Whatever the intended action is, it should be explicitly stated. > 5.4. LAN Identification > In some applications, it is useful to tag traffic by the user > community it is a part of, and guarantee that it will be only > emitted onto a LAN which is of the same community. The user > community is defined by a LAN ID. Systems which choose to not > implement this feature must assume that any frame received > having a LAN ID is from a different community than theirs, and > discard it. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Count|0|0|F|I|Z| MAC type | LAN ID high word (optional) + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LAN ID low word (optional) | Destination MAC Address + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It cleared up some of my confusion when I noticed that there was an explicit flag bit for the LAN ID. To keep others from being confused, I think this should be mentioned in the introductory text. This confusion led to my comments on the default LAN ID, which I now retract. If you have an explicit bit then you don't need a default. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | potential line protocol pad + > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ How about "optional Data Link Layer padding". > Figure 1: Tinygram Compression Psuedo-Code > How about: PPP Transmitter: if (ZeroPadCompressionEnabled && BridgedProtocolHeaderFormat == IEEE8023 && PacketLength == Minimum8023PacketLength) { /* * Remove any continuous run of zero octets preceding, * but not including, the LAN FCS, but not extending * into the MAC header. */ Set (ZeroCompressionFlag); /* Signal receiver */ if (LAN_FCS_Present) { FCS = TrailingOctets (PDU, 4); /* Store FCS */ RemoveTrailingOctets (PDU, 4); /* Remove FCS */ while (PacketLength > 14 && /* Stop at MAC header */ TrailingOctet (PDU) == 0) /* or last zero octet */ RemoveTrailingOctets (PDU, 1);/* Remove zero octet */ Appendbuf (PDU, 4, FCS); /* Restore FCS */ } else { while (PacketLength > 14 && /* Stop at MAC header */ TrailingOctet (PDU) == 0) /* or last zero octet */ RemoveTrailingOctets (PDU, 1);/* Remove zero octet */ } } PPP Receiver: if (ZeroCompressionFlag) { /* Flag set in header? */ /* Restoring packet to minimum 802.3 length */ Clear (ZeroCompressionFlag); if (LAN_FCS_Present) { FCS = TrailingOctets (PDU, 4); /* Store FCS */ RemoveTrailingOctets (PDU, 4); /* Remove FCS */ Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */ Appendbuf (PDU, 4, FCS); /* Restore FCS */ } else { Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */ } } Last comment: the draft needs a reference section. Drew From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 21 15:35:54 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23397; Fri, 21 Sep 90 15:17:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23259; Fri, 21 Sep 90 15:09:12 -0700 Received: from VitaM6.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA18427; Fri, 21 Sep 90 18:08:34 -0400 Message-Id: <9009212208.AA18427@uunet.uu.net> Date: Fri, 21 Sep 90 14:46:01 PDT From: VitaM6!baker@uunet.UU.NET (Fred Baker) To: uunet!"ietf-ppp@ucdavis.edu"@uunet.UU.NET Subject: PPP redux redux redux Status: O I have attended to Steve and Drew's comments, and had an extended conversation re: requireements with Silicon Graphics about the ramifications of the protocol. I think this addresses all of the issues, finessing one. I would be curious to hear commentary from the readership on this: 1171 technically allows a data link implementation to add an arbitrary number of octets on the end of a message and not say boo about it. Drew is concerned that a protocol implementation that must predict the behavior of the hardware it uses in this respect contains a layer violation, which took me some time to understand his point and I state it for the benefit of those equally dense. It seems to me that any real world driver for a device not only knows good and well what its hardware will do, but is generally designed around the hardware and often winds up fixing a lot of the bugs with software work-arounds. Therefore, although an absolute purist would grant the point, I'm not convinced that it makes real world sense. The other side of the concern is the use of PPP at reasonably high speed, like T-2 and T-3 - the kind of stuff people are all interested in bridging these days. Chips like the 80960 or the 29000 really like things to be aligned on 32 bit boundaries, and either trap or behave less efficiently when they are not. Steve Senum spent a fair amount of time looking at the headers trying to optimize the things to support high speed networking. Inserting a two byte length field rather blows that whole exercise to smithereens. I would really like to avoid putting the data on the other 16 bit boundary. Hence, I assume that the hardware will do something predictable on transmission and store the length of the data received when it does so, and a four bit 'pad length' field is adequate to describe the difference between the length presented for transmission and the length actually transmitted. Please comment on that issue, and any others that come to mind. Fred baker -----------------------shred-scrape-hack------------------------- Internet Draft Bridging Point to Point Protocol September 1990 Point to Point Protocol Extensions for Bridging Fri Sep 21 14:23:17 PDT 1990 Point to Point Working Group F. Baker Vitalink Communications Corporation 6607 Kaiser Drive Fremont California 94555 baker@vitalink.com _1. _S_t_a_t_u_s _o_f _t_h_i_s _M_e_m_o This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the author. It is an extension of the Internet Point-to-Point Protocol described in RFC 1171 [1], targeting the use of Point-to-Point lines for Remote Bridging. _2. _H_i_s_t_o_r_i_c_a_l _P_e_r_s_p_e_c_t_i_v_e Two basic algorithms are ambient in the industry for Bridging of Local Area Networks. The more common algorithm is called "Transparent Bridging", and has been standardized for Extended LAN configurations by IEEE 802.1. IEEE 802.5 has proposed an alternative approach, called "Source Routing", and is in the process of standardizing that approach for IEEE 802.5 extended networks. Although there is a subcommittee of IEEE 802.1 addressing remote bridging, neither standard directly defines Remote Bridging per se, as that would technically be beyond the IEEE 802 committee's charter. Both allow for it, however, modeling the line as an unspecified interface between half-bridges. This document assumes that the devices at either end of a serial link - have agreed to utilize the RFC 1171 line discipline in some form - may have agreed, by some other means, to exchange other protocols on the line interspersed with each other and with any bridged PDUs, F Baker [Page 1] Internet Draft Bridging Point to Point Protocol September 1990 - may be willing to use the link as a vehicle for Remote Bridging. - may have multiple point-to-point links that are configured in parallel to simulate a single line of higher speed or reliability, but message sequence issues are solved by the transmitting end. _3. _G_e_n_e_r_a_l _C_o_n_s_i_d_e_r_a_t_i_o_n_s _3._1. _L_i_n_k _Q_u_a_l_i_t_y _M_o_n_i_t_o_r_i_n_g It is strongly recommended that Point-to-Point Bridge Protocol implementations utilize Magic Number Loopback Detection and Link-Quality-Monitoring. This is because the 802.1 Spanning Tree protocol, which is integral to both Transparent Bridging and Source Routing (as standardized), is unidirectional during normal operation, with HELLO PDUs emanating from the Root System in the general direction of the leaves, without any reverse traffic except in response to network events. _3._2. _M_e_s_s_a_g_e _S_e_q_u_e_n_c_e The multiple link case requires consideration of message sequentiality. The transmitting station must determine either that the protocol being bridged requires transmissions to arrive in the order of their original transmission, and enqueue all transmissions on a given conversation onto the same link to force order preservation, or that the protocol does NOT require transmissions to arrive in the order of their original transmission, and use that knowledge to optimize the utilization of the several links, enqueuing traffic to links to minimize delay. In the absence of such a determination, the transmitting station must act as though all protocols require order preservation; many protocols designed primarily for use on a single LAN in fact do. A protocol could be described to maintain message sequentiality across multiple links, either by sequence numbering or by fragmentation and re-assembly, but this is neither elegant nor absolutely necessary. _3._3. _S_e_p_a_r_a_t_i_o_n _o_f _S_p_a_n_n_i_n_g _T_r_e_e _D_o_m_a_i_n_s It is conceivable that a network manager might wish to inhibit the exchange of BPDUs on a link in order to logically divide two regions into separate Spanning Trees with different Roots (and potentially different Spanning Tree implementations or algorithms). In order to do that, he must configure both ends to not exchange BPDUs on a link. For the sake of robustness, a bridge which is so configured must silently discard the BPDU of its neighbor, should it receive one. F Baker [Page 2] Internet Draft Bridging Point to Point Protocol September 1990 _4. _I_E_E_E _8_0_2._1 _T_r_a_n_s_p_a_r_e_n_t _B_r_i_d_g_i_n_g _4._1. _O_v_e_r_v_i_e_w _o_f _I_E_E_E _8_0_2._1 _T_r_a_n_s_p_a_r_e_n_t _B_r_i_d_g_i_n_g As a favor to the uninitiated, let us first describe Transparent Bridging. Essentially, the bridges in a network operate as isolated entities, largely unaware of each others' presence. A Transparent Bridge maintains a Forwarding Database consisting of {address, interface} records by saving the Source Address of each LAN transmission that it receives along with the interface identifier for the interface it was received on. It goes on to check whether the Destination Address is in the database, and if so, either discards the message (if the destination and source are located at the same interface) or forwards the message to the indicated interface. A message whose Destination Address is not found in the table is forwarded to all interfaces except the one it was received on; this describes Broadcast/Multicast behavior as well. The obvious fly in the ointment is that redundant paths in the network cause indeterminate (nay, all too determinate) forwarding behavior to occur. To prevent this, a protocol called the IEEE 802.1(d) Spanning Tree Protocol is executed between the bridges to detect and logically remove redundant paths from the network. One system is elected as the "Root", which periodically emits a message called a Bridge Hello Protocol Data Unit, or BPDU, heard by all of its neighboring bridges. Each of these modifies and passes the BPDU on to its neighbors, and they to theirs, until it arrives at the leaf LAN segments in the network (where it dies, having no further neighbors to pass it along) or until the message is stopped by a bridge which has a superior path to the "Root". In this latter case, the interface the BPDU was received on is ignored (ie, it is placed in a Hot Standby status, no traffic emitted onto it except the BPDU, and all traffic received from it is discarded) until a topology change forces a recalculation of the network. _4._2. _I_E_E_E _8_0_2._1 _R_e_m_o_t_e _B_r_i_d_g_i_n_g _A_c_t_i_v_i_t_y There exist two basic sorts of bridges - ones that interconnect LANs directly, called Local Bridges, and ones that interconnect LANs via an intermediate medium such as a leased line, called Remote Bridges. The Point-to-Point Protocol might be used by a Remote Bridge. F Baker [Page 3] Internet Draft Bridging Point to Point Protocol September 1990 There is more than one proposal within the IEEE 802.1 Interworking Committee for modeling the Remote Bridge. In one model, the interconnecting serial link(s) are treated in the same way that a LAN is, having a standard IEEE 802.1 Link State; in another, the serial links operate in a mode quite different from the LANs that they interconnect. For the sake of simplicity of specification, the first model is adopted, although some of the good ideas from proponents of the second model are included or allowed for. Therefore, given that transparent bridging is configured on a line or set of lines, the specifics of the link state with respect to the bridge is defined by IEEE 802.1(d). The Bridge Protocol Data Unit, or BPDU, is defined there, as well as the algorithms for its use. It is assumed that, if a Point-to-Point Link neighbor receives IEEE 802.1 BPDUs without rejecting them with the RFC 1171 Protocol-Reject LCP PDU, Transparent Bridging is permitted on the link. _4._3. _I_E_E_E _8_0_2._5 _S_o_u_r_c_e _R_o_u_t_i_n_g The IEEE 802.5 Committee has defined a different approach to bridging for use on the Token Ring, called Source Routing. In this approach, the originating system has the responsibility of indicating what path that the message should follow. It does this, if the message is directed off the local ring, by including a variable length MAC header extension called the Routing Information Field, or RIF. The RIF consists of one 16 bit word of flags and parameters followed by zero or more ring-and-bridge identifiers. Each bridge en route determines from this 'source route list' whether it should receive the message and how to forward it on. The algorithm for Source Routing requires the bridge to be able to identify any interface by its ring-and-bridge identifier, and to be able to identify any of its OTHER interfaces likewise. When a packet is received which has the Routing Information Field (RIF) present, a boolean in the RIF is inspected to determine whether the ring-and-bridge identifiers are to be inspected in "forward" or "reverse" sense. In a "forward" search, the bridge looks for the ring- and-bridge identifier of the interface the packet was received on, and forwards the packet toward the ring identified in the ring-and-bridge identifier that follows it. In a "reverse" search, the bridge looks for the ring-and-bridge identifier of the OTHER INTERFACE, and delivers the packet to the indicated interface if such is found. The algorithms for handling multicasts ("Functional Addresses" and "Group Addresses") have been the subject of much discussion in 802.5, and are likely to be the most troublesome F Baker [Page 4] Internet Draft Bridging Point to Point Protocol September 1990 for bridge implementations. Fortunately, they are beyond the scope of this document. _4._4. _I_E_E_E _8_0_2._5 _R_e_m_o_t_e _B_r_i_d_g_i_n_g _A_c_t_i_v_i_t_y There is no Remote Bridge proposal in IEEE 802.5 at this time, although IBM ships a remote Source Routing Bridge. Simplicity would dictate that we choose the same model for IEEE 802.5 Source Routing that was selected for IEEE 802.1, but necessity requires a ring number for the line in some cases. We allow for both models. Given that source routing is configured on a line or set of lines, the specifics of the link state with respect to the bridge is defined by the IEEE 802.5 Addendum on Source Routing. The requisite PDUs for calculating the spanning tree (used for assuring that each ring will receive at most one copy of a multicast) are defined there, as well as the algorithms for their use. MAC PDUs (Beacon, Ring Management, etc) are specific to the MAU technology and are not exchanged on the line. _4._5. _S_o_u_r_c_e _R_o_u_t_i_n_g _t_o _T_r_a_n_s_p_a_r_e_n_t _B_r_i_d_g_e _T_r_a_n_s_l_a_t_i_o_n IEEE 802 also has a subcommittee looking at the interoperation of Transparent Bridging and Source Routing. For the purposes of this standard, such a device is both a transparent and a source routing bridge, and will act on the line in both ways, just as it does on the LAN. F Baker [Page 5] Internet Draft Bridging Point to Point Protocol September 1990 _5. _T_r_a_f_f_i_c _S_e_r_v_i_c_e_s Several services are provided for the benefit of different system types and user configurations. These include LAN Frame Checksum Preservation, LAN Frame Checksum Generation, Tinygram Compression, and the identification of closed sets of LANs. _5._1. _L_A_N _F_r_a_m_e _C_h_e_c_k_s_u_m _P_r_e_s_e_r_v_a_t_i_o_n IEEE 802.1 stipulates that the Extended LAN must enjoy the same probability of undetected error that an individual LAN enjoys. Although there has been considerable debate concerning the algorithm, no other algorithm has been proposed than having the LAN Frame Checksum received by the ultimate receiver be the same value calculated by the original transmitter. Achieving this requires, of course, that the line protocols preserve the LAN Frame Checksum from end to end. The protocol is optimized towards this approach. _5._2. _T_r_a_f_f_i_c _h_a_v_i_n_g _n_o _L_A_N _F_r_a_m_e _C_h_e_c_k_s_u_m The fact that the protocol is optimized towards LAN Frame Checksum preservation raises twin questions: "What is the approach to be used by systems which, for whatever reason, cannot easily support Frame Checksum preservation?" and "What is the approach to be used when the system originates a message, which therefore has no Frame Checksum precalculated?". Surely, one approach would be to require stations to calculate the Frame Checksum in software if hardware support were unavailable; this would meet with profound dismay, and would raise serious questions of interpretation in a Bridge/Router. However, stations which implement LAN Frame Checksum preservation must already solve this problem, as they do originate traffic. Therefore, the solution adopted is that messages which have no Frame Checksum are tagged and carried across the line. When a system which does not implement LAN Frame Checksum preservation receives a frame having an embedded FCS, it converts it for its own use by removing the trailing four octets. When any system forwards a frame which contains no embedded FCS to a LAN, it forwards it in a way which causes the FCS to be calculated. _5._3. _T_i_n_y_g_r_a_m _C_o_m_p_r_e_s_s_i_o_n An issue in remote Ethernet bridging is that the protocols that are most attractive to bridge are prone to problems on low speed (64 KBPS and below) lines. This can be partially alleviated by observing that the vendors defining these F Baker [Page 6] Internet Draft Bridging Point to Point Protocol September 1990 protocols often fill the PDU pad with octets of ZERO. Thus, an Ethernet or IEEE 802.3 PDU received from a line that is (1) smaller than the minimum PDU size, and (2) has a LAN Frame Checksum present, must be padded by inserting zeroes between the last four octets and the rest of the PDU before transmitting it on a LAN. These protocols are frequently used for interactive sessions, and therefore are frequently this small. To prevent ambiguity, PDUs requiring padding are explicitly tagged, and all bridges are required to implement the decompression algorithm. Compression is at the option of the transmitting station, and is probably performed only on low speed lines, perhaps under configuration control. The psuedo-code in Figure 1 describes the algorithms. _5._4. _L_A_N _I_d_e_n_t_i_f_i_c_a_t_i_o_n In some applications, it is useful to tag traffic by the user community it is a part of, and guarantee that it will be only emitted onto a LAN which is of the same community. The user community is defined by a LAN ID. Systems which choose to not implement this feature must assume that any frame received having a LAN ID is from a different community than theirs, and discard it. F Baker [Page 7] Internet Draft Bridging Point to Point Protocol September 1990 Figure 1: Tinygram Compression Psuedo-Code PPP Transmitter: if (ZeroPadCompressionEnabled && BridgedProtocolHeaderFormat == IEEE8023 && PacketLength == Minimum8023PacketLength) { /* * Remove any continuous run of zero octets preceding, * but not including, the LAN FCS, but not extending * into the MAC header. */ Set (ZeroCompressionFlag); /* Signal receiver */ if (is_Set (LAN_FCS_Present)) { FCS = TrailingOctets (PDU, 4); /* Store FCS */ RemoveTrailingOctets (PDU, 4); /* Remove FCS */ while (PacketLength > 14 && /* Stop at MAC header */ TrailingOctet (PDU) == 0) /* or last non-zero octet */ RemoveTrailingOctets (PDU, 1);/* Remove zero octet */ Appendbuf (PDU, 4, FCS); /* Restore FCS */ } else { while (PacketLength > 14 && /* Stop at MAC header */ TrailingOctet (PDU) == 0) /* or last zero octet */ RemoveTrailingOctets (PDU, 1);/* Remove zero octet */ } } PPP Receiver: if (ZeroCompressionFlag) { /* Flag set in header? */ /* Restoring packet to minimum 802.3 length */ Clear (ZeroCompressionFlag); if (is_Set (LAN_FCS_Present)) { FCS = TrailingOctets (PDU, 4); /* Store FCS */ RemoveTrailingOctets (PDU, 4); /* Remove FCS */ Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */ Appendbuf (PDU, 4, FCS); /* Restore FCS */ } else { Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */ } } F Baker [Page 8] Internet Draft Bridging Point to Point Protocol September 1990 _6. _P_r_o_t_o_c_o_l _D_a_t_a _U_n_i_t _F_o_r_m_a_t_s _6._1. _C_o_m_m_o_n _L_A_N _T_r_a_f_f_i_c Figure 2: 802.3 Frame format 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x31 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|I|Z|0| Count | MAC type | LAN ID high word (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN ID low word (optional) | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address | Length/Type + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN FCS (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | potential line protocol pad + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For Bridging LAN traffic, the format of the frame on the line is as shown in Figures 2 or 3. This is conformant to RFC 1171 section 3.1 "Frame Format". It also allows for RFC 1172 [2] negotiation of Protocol Field Compression and Address and Control Field Compression. It is recommended that devices which use controllers that require even memory addresses negotiate to NOT USE Protocol Field Compression on other than low speed links. F Baker [Page 9] Internet Draft Bridging Point to Point Protocol September 1990 Figure 3: 802.4/802.5/FDDI Frame format 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x31 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|I|Z|0| Count | MAC type | LAN ID high word (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN ID low word (optional) | Pad Byte | Frame Control + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional Data Link Layer padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of this message are as follows: Address Field and Control Field: As defined by RFC 1171 Protocol Field: 0x0031 Flags: bits 0-3: length of the line protocol pad field. bit 4: Reserved, Set to Zero bit 5: Set if IEEE 802.3 Pad must be zero filled to minimum size bit 6: Set if the LAN ID Field is present bit 7: Set if the LAN FCS Field is present The "number of trailing "pad" octets is a deference to the fact that any point to point frame may have padding at the end. This number tells the receiving system how many octets to strip off the end. F Baker [Page 10] Internet Draft Bridging Point to Point Protocol September 1990 MAC type: 0: Reserved 1: IEEE 802.3/Ethernet 2: IEEE 802.4 3: IEEE 802.5 4: FDDI other: Assigned by the Internet Assigned Numbers Authority LAN ID: This optional 32 bit field identifies the Community of LANs which may be interested to receive this frame, as described in section 5.4. If the LAN ID flag is not set, then this field is not present, and the PDU is four octets shorter. Frame Control: On 802.4, 802.5, and FDDI LANs, there are a few octets preceding the Destination MAC Address, one of which is protected by the FCS. A pad octet is present to avoid odd machine address boundary problems. Destination MAC Address: As defined by the IEEE. Since the MAC type field defines the bit ordering, this is sent in MAC order. Source MAC Address: As defined by the IEEE. Since the MAC type field defines the bit ordering, this is sent in MAC order. LLC data: This is the remainder of the MAC frame. This is that portion of the frame which is (or would be were it present) protected by the LAN FCS; for example, the 802.5 Access Control field, and Status Trailer are not meaningful to transmit to another ring, and are omitted. LAN Frame Checksum: If present, this is the LAN FCS which was calculated by (or which appears to have been calculated by) the originating station. If the FCS Present flag is not set, then this field is not present, and the PDU is four octets shorter. Optional Data Link Layer Padding RFC 1171 specifies that an arbitrary pad can be added after the data intended for transmission. The "Count" portion of the flag field contains the length of this pad, which may not exceed 15 octets. CRC-CCITT Mentioned primarily for clarity. The CRC used on the PPP link is separate from and unrelated to the LAN FCS. F Baker [Page 11] Internet Draft Bridging Point to Point Protocol September 1990 _6._2. _I_E_E_E _8_0_2._1 _B_r_i_d_g_e This is the BPDU as defined by IEEE 802.1(d), without any MAC or 802.2 LLC header (these being functionally equivalent to the Address, Control, and Protocol Fields). The LAN Pad and Frame Checksum fields are likewise superfluous and absent. The Address and Control Fields are optional, subject to the Address and Control Field Compression negotiation. Figure 4: Bridge "Hello" PDU 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 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x02 | 0x01 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPDU data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of this message are as follows: Address Field and Control Field: As defined by RFC 1171 Protocol Field: 0x0201 MAC Frame: 802.1(d) BPDU F Baker [Page 12] Internet Draft Bridging Point to Point Protocol September 1990 _6._3. _I_E_E_E _8_0_2 _N_e_t_w_o_r_k _C_o_n_t_r_o_l _P_r_o_t_o_c_o_l The Bridge Network Control Protocol is responsible for configuring, enabling, and disabling the bridges on both ends of the point-to-point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. BNCP packets may not be exchanged until LCP has reached the network-layer Protocol Configuration Negotiation phase. Likewise, LAN traffic may not be exchanged until BNCP has first opened the connection. The Bridge Network Control Protocol is exactly the same as the Point-to-Point Link Control Protocol with the following exceptions: Data Link Layer Protocol Field Exactly one Bridge Network Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8031 (BNCP). 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 BNCP packets may not be exchanged until the Link Control Protocol has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing to finish before timing out waiting for 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 The Bridge Network Control Protocol has a separate set of Configuration Options. F Baker [Page 13] Internet Draft Bridging Point to Point Protocol September 1990 _6._4. _I_E_E_E _8_0_2._5 _R_e_m_o_t_e _R_i_n_g _I_d_e_n_t_i_f_i_c_a_t_i_o_n _O_p_t_i_o_n Since the Remote Bridges are modeled as normal Bridges with a strange internal interface, each bridge needs to know the ring/bridge numbers of the bridges it is adjacent to. This is the subject of a Link Negotiation. The exchange of ring-and- bridge identifiers is done using this option on the Network Control Protocol. The Token Ring Ring-and-Bridge Identifier, and its use, is specified by the IEEE 802.5 Addendum on Source Routing. It identifies the ring that the interface is attached to by its configured ring number, and itself by bridge number on the ring. Figure 5: Remote Ring Identification Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=1 |length = 4 | ring number |bridge#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 = IEEE 802.5 Source Routing Ring/Bridge Identifier Length 4 Octets Ring Number A 12 bit number identifying the token ring, as defined in the IEEE 802.5 Source Routing Specification. Bridge Number A 4 bit number identifying the bridge on the token ring, as defined in the IEEE 802.5 Source Routing Specification. F Baker [Page 14] Internet Draft Bridging Point to Point Protocol September 1990 _6._5. _I_E_E_E _8_0_2._5 _L_i_n_e _I_d_e_n_t_i_f_i_c_a_t_i_o_n _O_p_t_i_o_n This option permits the systems to treat the line as a visible "Token Ring", in accordance with the Source Routing algorithm. The bridges exchange ring-and-bridge identifiers using this option on the Network Control Protocol. The configured ring numbers must be identical in normal operation. The Token Ring Ring-and-Bridge Identifier, and its use, is specified by the IEEE 802.5 Addendum on Source Routing. It identifies the ring that the interface is attached to by its configured ring number, and itself by bridge number on the ring. Figure 6: Line Identification Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=2 |length = 4 | ring number |bridge#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 = IEEE 802.5 Line "Ring/Bridge" Identifier Length 4 Octets Ring Number A 12 bit number identifying the line, as defined in the IEEE 802.5 Source Routing Specification. Bridge Number A 4 bit number identifying the bridge on the token ring, as defined in the IEEE 802.5 Source Routing Specification. F Baker [Page 15] Internet Draft Bridging Point to Point Protocol September 1990 _7. _B_i_b_l_i_o_g_r_a_p_h_y [1] D. Perkins, he Point-to-Point Protocol for the Transmission of Multi-Protocol Datagrams Over Point-to- Point Links, Point-to-Point Working Group Request for Comments 1171. Network Information Center, SRI International, Menlo Park, California, (July 1990). [2] R. Hobby and D. Perkins, he Point-to-Point Protocol (PPP) Initial Configuration Options, Point-to-Point Working Group Request for Comments 1172. Network Information Center, SRI International, Menlo Park, California, (July 1990). [3] _I_E_E_E _D_r_a_f_t _S_t_a_n_d_a_r_d _P_8_0_2._1_d/_D_9 _M_A_C _B_r_i_d_g_e_s, Institute of Electrical and Electronic Engineers. Also Published as ISO DIS 10038 (July 1989). [4] _I_E_E_E _D_r_a_f_t _S_t_a_n_d_a_r_d _P_8_0_2._5_d/_D_1_3 _D_r_a_f_t _A_d_d_e_n_d_u_m _t_o _A_N_S_I/_I_E_E_E _S_t_d _8_0_2._5-_1_9_8_8 _T_o_k_e_n _R_i_n_g _M_A_C _a_n_d _P_H_Y _S_p_e_c_i_f_i_c_a_t_i_o_n _E_n_h_a_n_c_e_m_e_n_t _f_o_r _M_u_l_t_i_p_l_e-_R_i_n_g _N_e_t_w_o_r_k_s, Institute of Electrical and Electronic Engineers. (May 1989). F Baker [Page 16] From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 25 10:30:59 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18919; Tue, 25 Sep 90 10:16:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Mail.Think.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18868; Tue, 25 Sep 90 10:12:40 -0700 Return-Path: Received: from Gateway.Think.COM by mail.think.com; Tue, 25 Sep 90 13:12:01 -0400 Received: from News.Think.COM by gateway.think.com (5.61/Think-1.0C) id AA20801; Tue, 25 Sep 90 13:11:57 -0400 Received: from signet.UUCP by Early-Bird.Think.COM; Tue, 25 Sep 90 13:11:41 EDT Received: from leigh.signet.UUCP (sigma10) by signet.UUCP (4.0/SMI-4.0) id AA00749; Tue, 25 Sep 90 12:30:12 EDT Date: Tue, 25 Sep 90 12:30:12 EDT From: ken%signet.uucp@Think.COM (Kenneth Virgile) Message-Id: <9009251630.AA00749@signet.UUCP> To: ietf-ppp@ucdavis.edu Subject: Mailing list Status: O Please add "think!signet!ppp-interest" to the PPP mailing list. Thanks, Ken (617) 942-0200 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 28 19:15:08 1990 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01667; Fri, 28 Sep 90 19:01:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01601; Fri, 28 Sep 90 18:51:48 -0700 Received: from telebit.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA14350; Fri, 28 Sep 90 21:51:14 -0400 Received: from robin.telebit.COM by telebit.TELEBIT.COM (4.0/TELEBITGENERIC.3) id AA00635 to ietf-ppp@ucdavis.edu; Fri, 28 Sep 90 17:58:08 PDT From: Brian Lloyd X-Mailer: SCO System V Mail (version 3.2) To: ietf-ppp@ucdavis.edu Subject: Successful PPP interoperability testing Date: Fri, 28 Sep 90 17:56:28 PDT Message-Id: <9009290056.aa05838@robin.telebit.COM> Status: O We are doing pre-Interop PPP interoperability testing and thought that you might like to know that Cisco, 3-Com, and Telebit products have all mutually routed packets on 56Kbps synchronous links using PPP. Brian Lloyd, WB6RQN Telebit Corporation brian@telebit.com (408) 745-3103