rfc1638.txt

中、英文RFC文档大全打包下载完全版 .

Baker & Bowen                                                   [Page 7]

RFC 1638                      PPP Bridging                     June 1994


   Each bridge port may be considered to have two additional variables
   associated with it: "domain" and "checkDomain".

   The variable "domain" (a 32-bit unsigned integer) is assigned a value
   that uniquely labels a set of bridge ports in an extended network,
   with a default value of 1, and the values of 0 and 0xffffffff being
   reserved.

   The variable "checkDomain" (a boolean) controls whether this value is
   used to filter output to a bridge port.  The variable "checkDomain"
   is generally set to the boolean value True for LAN bridge ports, and
   set to the boolean value False for WAN bridge ports.

   The action of the bridge is then as modified as expressed in the
   following C code fragments:

      On a packet being received from a bridge port:

      if (domainNotPresentWithPacket) {
          packetInformation.domain = portInformation[inputPort].domain;
      } else {
          packetInformation.domain = domainPresentWithPacket;
      }

      On a packet being transmitted from a bridge port:

      if (portInformation[outputPort].checkDomain &&
          portInformation[outputPort] != packetInformation.domain) {
          discardPacket();
          return;
      }

   For example, suppose you have the following configuration:

           E1     +--+            +--+     E3
      ------------|  |            |  |------------
                  |  |     W1     |  |
                  |B1|------------|B2|
           E2     |  |            |  |     E4
      ------------|  |            |  |------------
                  +--+            +--+

   E1, E2, E3, and E4 are Ethernet LANs (or Token Ring, FDDI, etc.).  W1
   is a WAN (PPP over T1).  B1 and B2 are MAC level bridges.

   You want End Stations on E1 and E3 to communicate, and you want End
   Stations on E2 and E4 to communicate, but you do not want End
   Stations on E1 and E3 to communicate with End Stations on E2 and E4.



Baker & Bowen                                                   [Page 8]

RFC 1638                      PPP Bridging                     June 1994


   This is true for Unicast, Multicast, and Broadcast traffic.  If a
   broadcast datagram originates on E1, you want it only to be
   propagated to E3, and not on E2 or E4.

   Another way of looking at it is that E1 and E3 form a Virtual LAN,
   and E2 and E4 form a Virtual LAN, as if the following configuration
   were actually being used:

           E1     +--+     W2     +--+     E3
      ------------|B3|------------|B4|------------
                  +--+            +--+

           E2     +--+     W3     +--+     E4
      ------------|B5|------------|B6|------------
                  +--+            +--+

   To accomplish this (using the LAN Identification option), B1 and B2
   negotiate this option on, and send datagrams with bit 6 set to 1,
   with the LAN ID field inserted in the frame.  Traffic on E1 and E3
   would be assigned LAN ID 1, and traffic on E2 and E4 would be
   assigned LAN ID 2.  Thus B1 and B2 can separate traffic going over
   W1.

   Note that execution of the spanning tree algorithm may result in the
   subdivision of a domain.  The administrator of LAN domains must
   ensure, through spanning tree configuration and topology design, that
   such subdivision does not occur.

4.  A PPP Network Control Protocol for Bridging

   The Bridging Control Protocol (BCP) is responsible for configuring,
   enabling and disabling the bridge protocol modules on both ends of
   the point-to-point link.  BCP uses the same packet exchange mechanism
   as the Link Control Protocol.  BCP packets may not be exchanged until
   PPP has reached the Network-Layer Protocol phase.  BCP packets
   received before this phase is reached SHOULD be silently discarded.

   The Bridging Control Protocol is exactly the same as the Link Control
   Protocol [6] with the following exceptions:

   Frame Modifications

      The packet may utilize any modifications to the basic frame format
      which have been negotiated during the Link Establishment phase.

      Implementations SHOULD NOT negotiate Address-and-Control-Field-
      Compression or Protocol-Field-Compression on other than low speed
      links.



Baker & Bowen                                                   [Page 9]

RFC 1638                      PPP Bridging                     June 1994


   Data Link Layer Protocol Field

      Exactly one BCP packet is encapsulated in the PPP Information
      field, where the PPP Protocol field indicates type hex 8031 (BCP).

   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

      BCP packets may not be exchanged until PPP has reached the
      Network-Layer Protocol phase.  An implementation SHOULD be
      prepared to wait for Authentication and Link Quality Determination
      to finish before timing out waiting for a Configure-Ack or other
      response.  It is suggested that an implementation give up only
      after user intervention or a configurable amount of time.

   Configuration Option Types

      BCP has a distinct set of Configuration Options, which are defined
      in this document.

4.1.  Sending Bridge Frames

   Before any Bridged LAN Traffic or BPDUs may be communicated, PPP MUST
   reach the Network-Layer Protocol phase, and the Bridging Control
   Protocol MUST reach the Opened state.

   Exactly one Bridged LAN Traffic or BPDU is encapsulated in the PPP
   Information field, where the PPP Protocol field indicates type hex
   0031 (Bridged PDU).

4.1.1.  Maximum Receive Unit Considerations

   The maximum length of a Bridged datagram transmitted over a PPP link
   is the same as the maximum length of the Information field of a PPP
   encapsulated packet.  Since there is no standard method for
   fragmenting and reassembling Bridged PDUs, PPP links supporting
   Bridging MUST negotiate an MRU large enough to support the MAC Types
   that are later negotiated for Bridging support.  Because they include
   the MAC headers, even bridged Ethernet frames are larger than the
   default PPP MRU of 1500 octets.





Baker & Bowen                                                  [Page 10]

RFC 1638                      PPP Bridging                     June 1994


4.1.2.  Loopback and Link Quality Monitoring

   It is strongly recommended that PPP Bridge Protocol implementations
   utilize Magic Number Loopback Detection and Link-Quality-Monitoring.
   The 802.1 Spanning Tree protocol, which is integral to both
   Transparent Bridging and Source Routing (as standardized), is
   unidirectional during normal operation.  Configuration BPDUs emanate
   from the Root system in the general direction of the leaves, without
   any reverse traffic except in response to network events.

4.1.3.  Message Sequence

   The multiple link case requires consideration of message
   sequentiality.  The transmitting system may 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 several links, enqueuing traffic to
   multiple links to minimize delay.

   In the absence of such a determination, the transmitting system MUST
   act as though all protocols require order preservation.  Many
   protocols designed primarily for use on a single LAN require order
   preservation.

   Work is currently in progress on a protocol to allow use of multiple
   PPP links [7].  If approved, this protocol will allow use of multiple
   links while maintaining message sequentiality for Bridged LAN Traffic
   and BPDU frames.

4.1.4.  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 should configure both ends to not exchange BPDUs on a
   link.  An implementation that does not support any spanning tree
   protocol MUST silently discard any received IEEE 802.1D BPDU packets,
   and MUST either silently discard or respond to other received BPDU
   packets with an LCP Protocol-Reject packet.








Baker & Bowen                                                  [Page 11]

RFC 1638                      PPP Bridging                     June 1994


4.2.  Bridged LAN Traffic

   For Bridging LAN traffic, the format of the frame on the line is
   shown below.  The fields are transmitted from left to right.

   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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Address and Control      |      0x00     |      0x31     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|I|Z|0| Pads  |    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                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Frame FCS            |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



















Baker & Bowen                                                  [Page 12]

RFC 1638                      PPP Bridging                     June 1994


   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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Address and Control      |      0x00     |      0x31     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|I|Z|0| Pads  |    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       ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   LAN FCS (optional)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              optional Data Link Layer padding                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Frame FCS            |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Address and Control

      As defined by the framing in use.

   PPP Protocol

      0x0031 for PPP Bridging

   Flags

      bit F:  Set if the LAN FCS Field is present
      bit I:  Set if the LAN ID Field is present
      bit Z:  Set if IEEE 802.3 Pad must be zero filled to minimum size
      bit 0:  reserved, must be zero

   Pads

      Any PPP frame may have padding inserted in the "Optional Data Link
      Layer Padding" field.  This number tells the receiving system how
      many pad octets to strip off.



Baker & Bowen                                                  [Page 13]

RFC 1638                      PPP Bridging                     June 1994


   MAC Type

      Up-to-date values of the MAC Type field are specified in the most
      recent "Assigned Numbers" RFC [4].  Current values are assigned as
      follows:

          0: reserved
          1: IEEE 802.3/Ethernet  with canonical addresses
          2: IEEE 802.4           with canonical addresses
          3: IEEE 802.5           with non-canonical addresses
          4: FDDI                 with non-canonical addresses
       5-10: reserved
         11: IEEE 802.5           with canonical addresses
         12: FDDI                 with canonical addresses

      "Canonical" is the address format defined as standard address
      representation by the IEEE.  In this format, the bit within each
      byte that is to be transmitted first on a LAN is represented as
      the least significant bit.  In contrast, in non-canonical form,
      the bit within each byte that is to be transmitted first is
      represented as the most-significant bit.  Many LAN interface
      implementations use non-canonical form.  In both formats, bytes
      are represented in the order of transmission.

      If an implementation supports a MAC Type that is the higher-
      numbered format of that MAC Type, then it MUST also support the
      lower-numbered format of that MAC Type.  For example, if an
      implementation supports FDDI with canonical address format, then
      it MUST also support FDDI with non-canonical address format.  The
      purpose of this requirement is to provide backward compatibility
      with earlier versions of this specification.

      A system MUST NOT transmit a MAC Type numbered higher than 4
      unless it has received from its peer a MAC-Support Configuration
      Option indicating that the peer is willing to receive frames of
      that MAC Type.

   LAN ID

      This optional 32-bit field identifies the Community of LANs which
      may be interested to receive this frame.  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.



Baker & Bowen                                                  [Page 14]