rfc2878.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                      M. Higashiyama
Request for Comments: 2878                                        Anritsu
Obsoletes: 1638                                                  F. Baker
Category: Standards Track                                           Cisco
                                                                July 2000


                  PPP Bridging Control Protocol (BCP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   The Point-to-Point Protocol (PPP) [6] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   defines an extensible Link Control Protocol, and proposes a family of
   Network Control Protocols for establishing and configuring different
   network-layer protocols.

   This document defines the Network Control Protocol for establishing
   and configuring Remote Bridging for PPP links.

   This document obsoletes RFC 1638, which was based on the IEEE
   802.1D-1993 MAC Bridge[3]. This document extends that specification
   by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q
   Virtual LAN (VLAN)[9] standards. This document also improves the
   protocol in order to support high-speed switched LANs.














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


Table of Contents

   1.     Historical Perspective ................................    3
      1.1       Requirements Keywords ...........................    3
   2.     Methods of Bridging ...................................    3
      2.1       Transparent Bridging ............................    3
      2.2       Remote Transparent Bridging .....................    4
      2.3       Source Routing ..................................    5
      2.4       Remote Source Route Bridging ....................    6
      2.5       SR-TB Translational Bridging ....................    7
   3.     Traffic Services ......................................    7
      3.1       LAN Frame Checksum Preservation .................    7
      3.2       Traffic having no LAN Frame Checksum ............    7
      3.3       Tinygram Compression ............................    8
      3.4       Virtual LANs ....................................    8
   4.     A PPP Network Control Protocol for Bridging ...........    9
      4.1       Sending Bridge Frames ...........................   10
         4.1.1  Maximum Receive Unit Considerations .............   11
         4.1.2  Loopback and Link Quality Monitoring ............   11
         4.1.3  Message Sequence ................................   11
         4.1.4  Separation of Spanning Tree Domains .............   12
      4.2       Bridged LAN Traffic in IEEE 802 Untagged Frame ..   12
      4.3       Bridged LAN Traffic in IEEE 802 Tagged Frame ....   16
      4.4       Bridge management protocol data unit ............   21
   5.     BCP Configuration Options .............................   21
      5.1       Bridge-Identification ...........................   22
      5.2       Line-Identification .............................   23
      5.3       MAC-Support .....................................   25
      5.4       Tinygram-Compression ............................   26
      5.5       MAC-Address .....................................   27
      5.6       Spanning Tree Protocol (old formatted) ..........   28
      5.7       IEEE-802-Tagged-Frame ...........................   30
      5.8       Management-Inline ...............................   30
   6.     Changes From RFC 1638 .................................   31
   7.     Security Considerations ...............................   32
   8.     Intellectual Property Notice ..........................   32
   9.     IANA Considerations ...................................   33
   10.    Acknowledgments .......................................   33
   APPENDICES ...................................................   34
      A.     Spanning Tree Bridge PDU (old formatted) ...........   34
      B.     Tinygram-Compression Pseudo-Code ...................   35
   References ...................................................   36
   Authors' Addresses ...........................................   37
   Full Copyright Statement......................................   38







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


1.  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.  The other is called "Source Route
   Bridging", and is prevalent on IEEE 802.5 Token Ring LANs.

   The IEEE has combined these two methods into a device called a Source
   Routing Transparent (SRT) bridge, which concurrently provides both
   Source Route and Transparent bridging.  Transparent and SRT bridges
   are specified in IEEE standard 802.1D-1998 [8].

   Although IEEE committee 802.1G is addressing remote bridging [2],
   neither standard directly defines the mechanisms for implementing
   remote bridging.  Technically, that would be beyond the IEEE 802
   committee's charter.  However, both 802.1D and 802.1G allow for it.
   The implementor may model the line either as a component within a
   single MAC Relay Entity, or as the LAN media between two remote
   bridges.

   The original IEEE 802.1D is augmented by IEEE 802.1Q [9] to provide
   support for Virtual LAN. Virtual LAN is an integral feature of
   switched LAN networks.

1.1 Requirements Keywords

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [12].

2.  Methods of Bridging

2.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}

                               or

                      {address, interface, VLAN ID}






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


   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.  Bridges which support Virtual LANs additionally
   keep the Virtual LAN ID in their forwarding database. It goes on to
   check whether the Destination Address is in the database, and if so,
   either discards the message when 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 behavior applies to Broadcast/Multicast frames
   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 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 Protocol Data Unit (BPDU), heard by all of
   its neighboring bridges.  Each of these modifies and passes the BPDU
   on to its neighbors, 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 (it is placed in a Hot Standby
   status, no traffic is emitted onto it except the BPDU, and all
   traffic received from it is discarded), until a topology change
   forces a recalculation of the network.

   To establish Virtual LANs in an environment of multiple bridges, GVRP
   (GARP VLAN Registration Protocol) is executed between bridges to
   exchange Virtual LAN information. GVRP provides a mechanism to
   dynamically establish and update their knowledge of the set of
   Virtual LANs that currently have active members.

   To reduce unnecessary multicast flooding in the network, bridges
   exchange group MAC addresses using the GARP Multicast Registration
   Protocol. GMRP provides a mechanism so that bridges can know which
   multicast frames should be forwarded on each port.

2.2.  Remote Transparent Bridging

   There exist two basic sorts of bridges -- those that interconnect
   LANs directly, called Local Bridges, and those that interconnect LANs
   via an intermediate medium such as a leased line, called Remote
   Bridges.  PPP may be used to connect Remote Bridges.




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


   The IEEE 802.1G Remote MAC Bridging committee has proposed a model of
   a Remote Bridge in which a set of two or more Remote Bridges that are
   interconnected via remote lines are termed a Remote Bridge Group.
   Within a Group, a Remote Bridge Cluster is dynamically formed through
   execution of the spanning tree as the set of bridges that may pass
   frames among each other.

   This model bestows on the remote lines the basic properties of a LAN,
   but does not require a one-to-one mapping of lines to virtual LAN
   segments.  For instance, the model of three interconnected Remote
   Bridges, A, B and C, may be that of a virtual LAN segment between A
   and B and another between B and C.  However, if a line exists between
   Remote Bridges B and C, a frame could actually be sent directly from
   B to C, as long as there was the external appearance that it had
   travelled through A.

   IEEE 802.1G thus allows for a great deal of implementation freedom
   for features such as route optimization and load balancing, as long
   as the model is maintained.

   For simplicity, we discuss Remote Bridging in this document in terms
   of two Remote Bridges connected by a single line.

2.3.  Source Routing

   The IEEE 802.1D Committee has standardized Source Routing for any MAC
   Type that allows its use.  Currently, MAC Types that support Source
   Routing are FDDI and IEEE 802.5 Token Ring.

   The IEEE standard defines Source Routing only as a component of an
   SRT bridge.  However, many bridges have been implemented which are
   capable of performing Source Routing alone.  These are most commonly
   implemented in accordance either with the IBM Token-Ring Network
   Architecture Reference [1] or with the Source Routing Appendix of
   IEEE 802.1D-1998 [8].

   In the Source Routing approach, the originating system has the
   responsibility of indicating the path that the message should follow.
   It does this, if the message is directed off of the local segment, by
   including a variable length MAC header extension called the Routing
   Information Field (RIF).  The RIF consists of one 16-bit word of
   flags and parameters, followed by zero or more segment-and-bridge
   identifiers.  Each bridge en route determines from this source route
   list whether it should accept the message and how to forward it.

   In order to discover the path to a destination, the originating
   system transmits an Explorer frame.  An All-Routes Explorer (ARE)
   frame follows all possible paths to a destination.  A Spanning Tree



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


   Explorer (STE) frame follows only those paths defined by Bridge ports
   that the Spanning Tree Algorithm has put in Forwarding state.  Port
   states do not apply to ARE or Specifically-Routed Frames.  The
   destination system replies to each copy of an ARE frame with a
   Specifically-Routed Frame, and to an STE frame with an ARE frame.  In
   either case, the originating station may receive multiple replies,
   from which it chooses the route it will use for future Specifically-
   Routed Frames.

   The algorithm for Source Routing requires the bridge to be able to
   identify any interface by its segment-and-bridge identifier.  When a
   packet is received that has the RIF present, a boolean in the RIF is
   inspected to determine whether the segment-and-bridge identifiers are
   to be inspected in "forward" or "reverse" sense.  In its search, the
   bridge looks for the segment-and-bridge identifier of the interface
   the packet was received on, and forwards the packet toward the
   segment identified in the segment-and-bridge identifier that follows
   it.

   GVRP and GMRP are available and effective on Source Routing networks.

2.4.  Remote Source Route Bridging

   There is no Remote Source Route Bridge proposal in IEEE 802.1 at this
   time, although many vendors ship remote Source Routing Bridges.

   We allow for modelling the line either as a connection residing
   between two halves of a "split" Bridge (the split-bridge model), or
   as a LAN segment between two Bridges (the independent-bridge model).
   In the latter case, the line requires a LAN Segment ID.

   By default, PPP Source Route Bridges use the independent-bridge
   model.  This requirement ensures interoperability in the absence of
   option negotiation.  In order to use the split-bridge model, a system
   MUST successfully negotiate the Bridge-Identification Configuration
   Option.

   Although no option negotiation is required for a system to use the
   independent-bridge model, it is strongly recommended that systems
   using this model negotiate the Line-Identification Configuration
   Option.  Doing so will verify correct configuration of the LAN
   Segment Id assigned to the line.

   When two PPP systems use the split-bridge model, the system that
   transmits an Explorer frame onto the PPP link MUST update the RIF on
   behalf of the two systems.  The purpose of this constraint is to
   ensure interoperability and to preserve the simplicity of the
   bridging algorithm.  For example, if the receiving system did not



Higashiyama & Baker         Standards Track                     [Page 6]