rfc1220.txt

RFC 的详细文档！


RFC 1220            Bridging Point-to-Point Protocol          April 1991


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.

   Configuration Option Types
        The Bridge Network Control Protocol has a separate set of
        Configuration Options.  These permit the negotiation of the
        following items:

             - MAC Types supported
             - Tinygram Compression support
             - LAN Identification support
             - Ring and Bridge Identification

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.



Point-to-Point Protocol Extensions Working Group               [Page 13]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


   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.

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




Point-to-Point Protocol Extensions Working Group               [Page 14]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


   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.

6.6.  MAC Type Support Selection

   The MAC Type Selection Option is provided to permit nodes to
   advertise what sort of traffic they are prepared to convey.  A device
   negotiating a 1600 octet MRU, for example, may not be willing to
   support 802.5 (although it might, with certain changes necessary in
   the RIFs it passes, and given that the hosts it supports implement
   the 802.5 Maximum Frame Size correctly), and is definitely not
   prepared to support 802.4 or FDDI.

   A system which does not announce the MAC Types that it supports may
   be assumed to support all MAC Types; it will discard those that it
   does not understand.  A system which chooses to announce MAC Types is
   advising its neighbor that all unspecified MAC Types will be
   discarded.  Announcement of multiple MAC Types is accomplished by
   placing multiple options in the Configure Request.

   The Rejection of a MAC Type Announcement (in a Configure-Reject) is
   essentially a statement that traffic appropriate to the MAC Type, if
   encountered, will be forwarded on the link even though the receiving
   system has indicated it will discard it.

   Figure 7: MAC Type Selection Option

    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=3    |length = 3     | MAC Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type 3 = MAC Type Selector

   Length
        3 Octets



Point-to-Point Protocol Extensions Working Group               [Page 15]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


   MAC Type Selector
        One of the values of the PDU's MAC Type Field that this system is
        prepared to receive and service.

6.7.  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 permits the system to negotiate compression.

   Consistent with the behavior of other compression options in the
   Internet Point-to-Point set of protocols, no negotiation implies no
   compression.  The systems need not agree on the setting of this
   parameter; one may be willing to decompress and the other not.  A
   system which does not negotiate, or negotiates this option to be
   disabled, should never receive a compressed packet, however.

   Figure 8: Tinygram Compression Option

    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=4    |length = 3     | Compression   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type 4 = Tinygram Compression Support Option

   Length
        3 Octets

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

6.8.  LAN Identification Support

   Not all systems are prepared to make use of the LAN Identification
   field.  This option enables the systems to negotiate its use.

   The parameter is advisory; if the value is "enabled", then there may
   exist labeled LANs beyond the system, and the system is prepared to
   service traffic to it.  if the value is "disabled", then there are no
   labeled LANs beyond the system, and all such traffic will by
   definition be dropped.  Therefore, a system which is advised that his
   peer does not service LAN Identifications need not forward such
   traffic on the link.



Point-to-Point Protocol Extensions Working Group               [Page 16]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


   The default value is that LAN Identification disabled.

   Figure 9: LAN Identification Option

    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=5    |length = 3     | Identification|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type 5 = LAN Identification Support Option

   Length
        3 Octets

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

7.  Acknowledgements

   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, and Rick Szmauz of Digital Equipment
   Corporation.

8.  Bibliography

   [1] Perkins, D., "The Point-to-Point Protocol for the Transmission of
       Multi-Protocol Datagrams Over Point-to-Point Links", RFC 1171,
       CMU, July 1990.

   [2] Hobby R., and D. Perkins, "The Point-to-Point Protocol (PPP)
       Initial Configuration Options", RFC 1172, CMU, UC Davis, July
       1990.

   [3] IEEE Draft Standard P802.1d/D9 MAC Bridges, Institute of
       Electrical and Electronic Engineers.  Also Published as ISO DIS
       10038, July 1989.

   [4] IEEE Draft Standard P802.5d/D13 Draft Addendum to ANSI/IEEE Std
       802.5-1988 Token Ring MAC and PHY Specification Enhancement for
       Multiple-Ring Networks, Institute of Electrical and Electronic
       Engineers, May 1989.






Point-to-Point Protocol Extensions Working Group               [Page 17]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


9.  Security Considerations

   Security issues are not discussed in this memo.

10.  Author's Address

   Fred Baker
   Advanced Computer Communications
   720 Santa Barbara Street
   Santa Barbara, CA 93101

   Phone: [phone]

   EMail: [e-mail]
   Or send comments to: [e-mail]




































Point-to-Point Protocol Extensions Working Group               [Page 18]