rfc1638.txt

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

RFC 1638                      PPP Bridging                     June 1994


   Length

      3

   Enable/Disable

      If the value is 1, Tinygram-Compression is enabled.  If the value
      is 2, Tinygram-Compression is disabled, and no decompression will
      occur.

      The implementations need not agree on the setting of this
      parameter.  One may be willing to decompress and the other not.


5.5.  LAN-Identification

   Description

      This Configuration Option permits the implementation to indicate
      support for the LAN Identification field, and that the system is
      prepared to service traffic to any labeled LANs beyond the system.

      A Configure-NAK MUST NOT be sent in response to a Configure-
      Request that includes this option.

      By default, LAN-Identification is disabled.  All Bridge LAN
      Traffic and BPDUs that contain the LAN ID field will be discarded.
      The peer may then reduce bandwidth usage by not sending the
      unsupported traffic.

   A summary of the LAN-Identification Option format is shown below.
   The fields are transmitted from left to right.

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


   Type

      5

   Length

      3




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


   Enable/Disable

      If the value is 1, LAN Identification is enabled.  If the value is
      2, LAN Identification is disabled.

      The implementations need not agree on the setting of this
      parameter.  One may be willing to accept LAN Identification and
      the other not.

5.6.  MAC-Address

   Description

      The MAC-Address Configuration Option enables the implementation to
      announce its MAC address or have one assigned.  The MAC address is
      represented in IEEE 802.1 Canonical format, which is to say that
      the multicast bit is the least significant bit of the first octet
      of the address.

      If the system wishes to announce its MAC address, it sends the
      option with its MAC address specified.  When specifying a non-zero
      MAC address in a Configure-Request, any inclusion of this option
      in a Configure-Nak MUST be ignored.

      If the implementation wishes to have a MAC address assigned, it
      sends the option with a MAC address of 00-00-00-00-00-00.  Systems
      that have no mechanism for address assignment will Configure-
      Reject the option.

      A Configure-Nak MUST specify a valid IEEE 802.1 format physical
      address; the multicast bit MUST be zero.  It is strongly
      recommended (although not mandatory) that the "locally assigned
      address" bit (the second least significant bit in the first octet)
      be set, indicating a locally assigned address.

   A summary of the MAC-Address Option format is shown below.  The
   fields are transmitted from left to right.

    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      |    Length     |MAC byte 1 |L|M|  MAC byte 2   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MAC byte 3   |  MAC byte 4   |  MAC byte 5   |  MAC byte 6   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






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


   Type

      6

   Length

      8

   MAC Byte

      Six octets of MAC address in 802.1 Canonical order.  For clarity,
      the position of the Local Assignment (L) and Multicast (M) bits
      are shown in the diagram.

5.7.  Spanning-Tree-Protocol

   Description

      The Spanning-Tree-Protocol Configuration Option enables the
      Bridges to negotiate the version of the spanning tree protocol in
      which they will participate.

      If both bridges support a spanning tree protocol, they MUST agree
      on the protocol to be supported.  When the two disagree, the
      lower-numbered of the two spanning tree protocols should be used.
      To resolve the conflict, the system with the lower-numbered
      protocol SHOULD Configure-Nak the option, suggesting its own
      protocol for use.  If a spanning tree protocol is not agreed upon,
      except for the case in which one system does not support any
      spanning tree protocol, the Bridging Control Protocol MUST NOT
      enter the Opened state.

      Most systems will only participate in a single spanning tree
      protocol.  If a system wishes to participate simultaneously in
      more than one spanning tree protocol, it MAY include all of the
      appropriate protocol types in a single Spanning-Tree-Protocol
      Configuration Option.  The protocol types MUST be specified in
      increasing numerical order.  For the purpose of comparison during
      negotiation, the protocol numbers MUST be considered to be a
      single number.  For instance, if System A includes protocols 01
      and 03 and System B indicates protocol 03, System B should
      Configure-Nak and indicate a protocol type of 03 since 0103 is
      greater than 03.

      By default, an implementation MUST either support the IEEE 802.1D
      spanning tree or support no spanning tree protocol.  An
      implementation that does not support any spanning tree protocol
      MUST silently discard any received IEEE 802.1D BPDU packets, and



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


      MUST either silently discard or respond to other received BPDU
      packets with an LCP Protocol-Reject packet.

   A summary of the Spanning-Tree-Protocol Option format is shown below.
   The fields are transmitted from left to right.

    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 2 3 4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Protocol 1   |  Protocol 2   | ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      7

   Length

      2 octets plus 1 additional octet for each protocol that will be
      actively supported.  Most systems will only support a single
      spanning tree protocol, resulting in a length of 3.

   Protocol n

      Each Protocol field is one octet and indicates a desired spanning
      tree protocol.  Up-to-date values of the Protocol field are
      specified in the most recent "Assigned Numbers" RFC [4].  Current
      values are assigned as follows:


           Value     Protocol

             0       Null (no Spanning Tree protocol supported)
             1       IEEE 802.1D spanning tree
             2       IEEE 802.1G extended spanning tree protocol
             3       IBM Source Route Spanning tree protocol
             4       DEC LANbridge 100 Spanning tree protocol













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


A.  Tinygram-Compression Pseudo-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 or */
                   TrailingOctet (PDU) == 0)  /*  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 */
        }
    }








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


Security Considerations

   Security issues are not discussed in this memo.

References

   [1] IBM, "Token-Ring Network Architecture Reference", 3rd edition,
       September 1989.

   [2] IEEE 802.1, "Draft Standard 802.1G: Remote MAC Bridging",
       P802.1G/D7, December 30, 1992.

   [3] IEEE 802.1, "Media Access Control (MAC) Bridges", ISO/IEC 15802-
       3:1993 ANSI/IEEE Std 802.1D, 1993 edition., July 1993.

   [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

   [5] Simpson, W., "PPP LCP Extensions", RFC 1570, Daydreamer, January
       1994.

   [6] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1548,
       Daydreamer, December 1993.

   [7] Sklower, K., "A Multilink Protocol for Synchronizing the
       Transmission of Multi-protocol Datagrams", Work in Progress,
       August 1993.
























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


Acknowledgments

   This document is a product of the Point-to-Point Protocol Extensions
   Working Group.

   Special thanks go to Steve Senum of Network Systems, Dino Farinacci
   of 3COM, Rick Szmauz of Digital Equipment Corporation, and Andrew
   Fuqua of IBM.

Chair's Address

   The working group can be contacted via the current chair:

   Fred Baker
   Advanced Computer Communications
   315 Bollay Drive
   Santa Barbara, California  93117

   EMail: [e-mail]

Author's Address

   Questions about this memo can also be directed to:

   Rich Bowen
   International Business Machines Corporation
   P. O. Box 12195
   Research Triangle Park, NC  27709

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




















Baker & Bowen                                                  [Page 28]