rfc2878.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,640 行 · 第 1/5 页

      By default, a system that does not negotiate this option is
      assumed to have its LAN segment number correctly configured by the
      user.

   A summary of the Line-Identification 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     | LAN Segment Number    |Bridge#|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      2

   Length

      4

   LAN Segment Number

      A 12-bit number identifying the LAN segment, as defined in the
      IEEE 802.1D Source Routing Specification.







Higashiyama & Baker         Standards Track                    [Page 24]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


   Bridge Number

      A 4-bit number identifying the bridge on the LAN segment, as
      defined in the IEEE 802.1D Source Routing Specification.

5.3.  MAC-Support

   Description

      The MAC-Support Configuration Option is provided to permit
      implementations to indicate the sort of traffic they are prepared
      to receive.  Negotiation of this option is strongly recommended.

      By default, when an implementation does not announce the MAC Types
      that it supports, all MAC Types are sent by the peer which are
      capable of being transported given other configuration parameters.
      The receiver will discard those MAC Types that it does not
      support.

      A device supporting a 1600 octet MRU might not be willing to
      support 802.5, 802.4 or FDDI, which each support frames larger
      than 1600 octets.

      By announcing the MAC Types it will support, an implementation is
      advising its peer that all unspecified MAC Types will be
      discarded.  The peer MAY then reduce bandwidth usage by not
      sending the unsupported MAC Types.

      Announcement of support for multiple MAC Types is accomplished by
      placing multiple options in the Configure-Request.

      The nature of this option is advisory only.  This option MUST NOT
      be included in a Configure-Nak.

   A summary of the MAC-Support 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     |    MAC Type   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      3





Higashiyama & Baker         Standards Track                    [Page 25]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


   Length

      3

   MAC Type

      One of the values of the PDU MAC Type field (previously described
      in the "Bridged LAN Traffic" section) that this system is prepared
      to receive and service.

5.4.  Tinygram-Compression

   Description

      This Configuration Option permits the implementation to indicate
      support for Tinygram compression.

      Not all systems are prepared to make modifications to messages in
      transit.  On high speed lines, it is probably not worth the
      effort.

      This option MUST NOT be included in a Configure-Nak if it has been
      received in a Configure-Request.  This option MAY be included in a
      Configure-Nak in order to prompt the peer to send the option in
      its next Configure-Request.

      By default, no compression is allowed.  A system which does not
      negotiate, or negotiates this option to be disabled, should never
      receive a compressed packet.

   A summary of the Tinygram-Compression 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

      4

   Length

      3





Higashiyama & Baker         Standards Track                    [Page 26]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


   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.  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   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Higashiyama & Baker         Standards Track                    [Page 27]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


   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.6.  Spanning-Tree-Protocol (old format)

   Description

      The Spanning-Tree-Protocol Configuration enables a Bridge to
      remain compatible with older implementations of BCP [10]. This
      configuration option is, however, incompatible with the
      Management-Inline option, which enables a bridge to implement the
      many protocols that IEEE now expects a bridge to be able to use.

      If the peer rejects the Management-Inline configuration option, by
      sending configure-reject, it must be an implementation of [10],
      which is described in Appendix A. The system may optionally
      terminate the negotiation or offer to negotiate in that manner.

      In this case, if both bridges support a spanning tree protocol,
      they MUST agree on the protocol to be supported. The old BPDU
      described in Appendix A MUST be used rather than the format shown
      in section 4.2 or 4.3. 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



Higashiyama & Baker         Standards Track                    [Page 28]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


      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
      MUST either silently discard or respond to other received BPDU
      packets with an LCP Protocol-Reject packet in this case.

   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    |     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 Spanning-Tree-Protocol
      field are specified as PPP DLL numbers 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






Higashiyama & Baker         Standards Track                    [Page 29]

RFC 2878          PPP Bridging Control Protocol (BCP)          July 2000


5.7.  IEEE-802-Tagged-Frame

   Description

      This configuration option permits the implementation to indicate
      support for IEEE 802 Tagged Frame. Negotiation of this option is
      strongly recommended.

      A device supporting IEEE 802 Tagged Frame must be willing to
      support IEEE 802 Tagged Frame shown in section 4