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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
ポイントツーポイントプロトコル（PPP）[6]のポイントツーポイントリンク上でマルチプロトコルデータグラムを輸送するための標準的な方法を提供します。 PPPは、拡張可能なリンク制御プロトコルを定義し、異なるネットワーク層プロトコルを確立し、設定するためのネットワーク制御プロトコルのファミリーを提案しています。
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.
このドキュメントは、PPPリンク用のリモートブリッジングを確立し、構成するためにNetwork Controlプロトコルを定義します。
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.
この文書では、IEEE 802.1D-1993 MACブリッジに基づいていたRFC 1638、廃止[3]。このドキュメントでは、IEEE 802.1D-1998 MACブリッジ[8]とIEEE 802.1Q仮想LAN（VLAN）[9]の基準を含むことにより、その仕様を拡張します。また、このドキュメントでは、高速切り替えLANをサポートするために、プロトコルを改善します。
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
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.
二つの基本的なアルゴリズムは、ローカルエリアネットワークのブリッジングのために、業界内の雰囲気です。より一般的なアルゴリズムは、「トランスペアレントブリッジング」と呼ばれ、IEEE 802.1で拡張LAN構成のための標準化されています。他には、「ソースルートブリッジング」と呼ばれ、IEEE 802.5トークンリングLAN上の流行です。
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].
IEEEは、同時に送信元経路とトランスペアレントブリッジングの両方を提供するソースルーティング透明（SRT）ブリッジと呼ばれる装置にこれらの2つの方法を組み合わせています。透明でSRTブリッジは、IEEE標準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.
IEEE委員会802.1Gはブリッジリモートアドレス指定されているが[2]、いずれも標準直接リモートブリッジングを実現するためのメカニズムを定義します。技術的には、それはIEEE 802委員会の憲章を超えるだろう。ただし、802.1Dと802.1Gの両方がそれを可能にします。実装は、単一のMAC中継エンティティ内成分として、または2つのリモートブリッジ間のLAN媒体のいずれかの行をモデル化することができます。
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.
オリジナルのIEEE 802.1Dは、仮想LANのサポートを提供するために、IEEE 802.1Q [9]によって拡張されます。仮想LANは、スイッチドLANネットワークの不可欠な機能です。
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].
彼らは、この文書に表示される[12]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
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}
{アドレス、インタフェース、VLAN ID}
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.
レコードを、それが受信されたインターフェイスのインターフェイス識別子と共に、受信した各LANの伝送の送信元アドレスを保存することもできます。仮想LANをサポート橋は、さらに自分のフォワーディングデータベースに仮想LAN IDを保持します。これは、宛先アドレスがデータベースにあるかどうかを確認するに進み、そうであれば、いずれかの宛先とソースを同じインタフェースに配置されているメッセージを破棄し、または指示インタフェースにメッセージを転送します。宛先アドレスがテーブル内に見つからない、それが受信された以外のすべてのインターフェイスに転送されるメッセージ。この動作は、マルチキャストが同様にフレーム/ブロードキャストに適用されます。
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.
1つのシステムが定期的にその隣接ブリッジのすべてで聞いたブリッジプロトコルデータユニット（BPDU）と呼ばれるメッセージを、放出する「ルート」として選出されます。これらの修飾のそれぞれと、ネットワーク内のリーフのLANセグメントに到着するまで、その隣接上にBPDUを通過する（それはさらに隣人に沿ってそれを通過しないように有し、ダイ場合）、またはメッセージを有するブリッジによって停止されるまで「ルート」よりも優れてパス。トポロジ変更が強制されるまで、この後者の場合には、BPDUが受信されたインターフェイスは、（トラフィックがBPDUを除き、それに照射されていない、ホットスタンバイ状態に置かれ、そしてすべてのトラフィックは、それが破棄されるから受信）は無視されネットワークの再計算。
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.
複数のブリッジの環境で仮想LANを構築するには、GVRP（GARP VLAN登録プロトコル）は、仮想LAN情報を交換するために、ブリッジ間で実行されます。 GVRPは、動的に確立し、現在アクティブなメンバーを持っている仮想LANのセットの知識を更新するためのメカニズムを提供します。
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.
ネットワーク内の不要なマルチキャストフラッディングを減らすために、GARPマルチキャスト登録プロトコルを使用して交換基MACアドレスがブリッジします。ブリッジは、各ポートに転送されるべきマルチキャストどのフレーム知ることができるようにGMRP機構を提供します。
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.
直接それらの相互接続のLAN、ローカルブリッジ、及び、リモートブリッジと呼ばれる専用線などの中間媒体を介して、それらの相互接続のLANと呼ばれる - ブリッジの二つの基本的な種類が存在します。 PPPは、リモートブリッジを接続するために使用することができます。
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.
IEEE 802.1GリモートMACブリッジング委員会は、リモート回線を介して相互に接続された2つ以上のリモートブリッジのセットがリモートブリッジグループと呼ばれているリモート・ブリッジのモデルを提案しました。グループ内では、リモート・ブリッジクラスタは動的にお互いの間でフレームを渡すことができるブリッジのセットとしてスパニングツリーを実行することにより形成されています。
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.
このモデルは、リモート回線LANの基本的な性質に授けるが、仮想LANセグメントへのラインの1対1のマッピングを必要としません。ラインリモートブリッジBとCとの間に存在する場合、例えば、3つの相互接続されたリモートブリッジ、A、B及びCのモデルは、しかし、BとCの間のAとBと他の間で仮想LANセグメントのものであってもよいですフレームは、実際に限り、それはA.を通過したこと外観があったとして、CにBから直接送ることができます
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.
IEEE 802.1Gは、このように限り、モデルが維持されているように、このような経路最適化と負荷分散などの機能の実装の自由度の多大することができます。
For simplicity, we discuss Remote Bridging in this document in terms of two Remote Bridges connected by a single line.
簡単にするために、我々は、単一のラインで接続された2つのリモートブリッジの点では、この文書に記載されているリモートブリッジングを議論します。
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.
IEEE 802.1D委員会は、その使用を可能にする任意のMACタイプのためにソースルーティングを標準化しています。現在、ソースルーティングをサポートするMACタイプは、FDDIおよびIEEE 802.5トークンリングです。
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].
IEEE規格は、SRTブリッジの構成要素として、ソースルーティングを定義します。しかし、多くの橋だけではソースルーティングを実行することが可能である実装されています。これらは、最も一般的にどちらかのIBMトークンリングネットワークアーキテクチャリファレンスに従って実装されている[1]または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.
ソースルーティングアプローチにおいて、発信システムは、メッセージが従うべき経路を指示する責任を有します。メッセージがルーティング情報フィールド（RIF）と呼ばれる可変長MACヘッダ拡張を含むことによって、ローカルセグメントの外向けられている場合には、これを行います。 RIFは、ゼロまたはそれ以上のセグメントとブリッジ識別子に続くフラグとパラメータの1つの16ビットワードから成ります。途中各ブリッジは、それがメッセージとどのようにそれを転送する方法を受け入れるべきかどうか、このソースルートリストから決定されます。
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
宛先への経路を発見するために、元のシステムは、探索フレームを送信します。全ルートエクスプローラ（ARE）フレームは、宛先へのすべての可能な経路をたどります。スパニングツリー
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.
エクスプローラ（STE）フレームは、スパニングツリーアルゴリズムはフォワーディング状態にしたブリッジポートによって定義されただけのパスをたどります。ポートの状態は、AREまたは具体的にルートフレームには適用されません。宛先システムは、具体的には、ルーティングフレームとAREフレームの各コピーにされ、フレームとSTEフレームに応答します。いずれの場合においても、発信局は、それが将来の具体的ルーティングフレームに使用する経路を選択し、そこから複数の応答を受信することができます。
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.
ソースルーティングのためのアルゴリズムは、そのセグメントとブリッジ識別子によって任意インターフェイスを識別することができるように、ブリッジを必要とします。パケットがRIF存在を有する受信された場合、RIFのbooleanはセグメントとブリッジ識別子が「前方」または「逆」の意味で検査されるべきかどうかを決定するために検査されます。その検索では、ブリッジは、パケットが受信されたインターフェイスのセグメントとブリッジ識別子を探し、それを次のセグメントとブリッジ識別子で識別されたセグメントに向けてパケットを転送します。
GVRP and GMRP are available and effective on Source Routing networks.
GVRPおよびGMRPは、ソースルーティングネットワーク上で利用できると効果的です。
There is no Remote Source Route Bridge proposal in IEEE 802.1 at this time, although many vendors ship remote Source Routing Bridges.
多くのベンダーは、リモートソースルーティングブリッジを出荷するが、この時点でのIEEE 802.1にはリモートソースルートブリッジの提案は、ありません。
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.
我々のいずれか、又は二橋（独立したブリッジモデル）との間のLANセグメントとして「スプリット」ブリッジ（スプリットブリッジモデル）の二つの部分の間に存在する接続としてラインをモデル化を可能にします。後者の場合、ラインはLANセグメント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.
デフォルトでは、PPPソースルートブリッジは、独立したブリッジモデルを使用します。この要件は、オプションのネゴシエーションの不存在下での相互運用性を確保します。スプリット・ブリッジモデルを使用するためには、システムが正常にブリッジ識別情報の構成オプションを交渉しなければなりません。
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.
noオプションのネゴシエーションが独立したブリッジモデルを使用するようにシステムに必要とされていないが、このモデルを使用するシステムは、ライン識別情報の構成オプションを交渉することを強くお勧めします。そうすることでラインに割り当てられたLANのセグメントIDの正しい設定を確認します。
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 know whether the transmitting system had updated the RIF, it would have to scan the RIF and decide whether to update it. The choice of the transmitting system for the role of updating the RIF allows the system receiving the frame from the PPP link to forward the frame without processing the RIF.
2つのPPPシステムが分割ブリッジモデルを使用する場合、PPPリンクに探索フレームを送信するシステムは、2つのシステムの代わりにRIFを更新する必要があります。この制約の目的は、相互運用性を確保し、ブリッジングアルゴリズムの単純さを維持することです。受信システムは、送信システムがRIFを更新していたかどうかわからなかった場合、それはRIFをスキャンし、それを更新するかどうかを決定しなければなりません。 RIFを更新する役割のための送信システムの選択は、PPPのリンクからフレームを受信し、システムがRIFを処理せずにフレームを転送することができます。
Given that source routing is configured on a line or set of lines, the specifics of the link state with respect to STE frames are defined by the Spanning Tree Protocol in use. Choice of the split-bridge or independent-bridge model does not affect spanning tree operation. In both cases, the spanning tree protocol is executed on the two systems independently.
ソースルーティングがライン上で設定またはラインで設定されていることを考えると、STEフレームに対するリンク状態の詳細は、使用中のスパニングツリープロトコルによって定義されます。スプリット・ブリッジまたは独立したブリッジモデルの選択は、ツリーの動作をまたがる影響はありません。両方の場合において、スパニングツリープロトコルは、独立して二つのシステム上で実行されます。
IEEE 802 is not currently addressing bridges that translate between Transparent Bridging and Source Routing. For the purposes of this standard, such a device is either a Transparent or a Source Routing bridge, and will act on the line in one of these two ways, just as it does on the LAN.
IEEE 802は、現在、トランスペアレントブリッジングとソースルーティングの間の変換ブリッジに対処されていません。この規格の目的のために、そのようなデバイスは、透明またはソースルーティングブリッジのいずれかであり、それはLAN上と同じように、これら2つの方法のいずれかで行に作用します。
Several services are provided for the benefit of different system types and user configurations. These include LAN Frame Checksum Preservation, LAN Frame Checksum Generation, Tinygram Compression, and the identification of closed sets of LANs.
いくつかのサービスは、異なるシステム・タイプとユーザー設定の利益のために提供されています。これらは、LANフレームチェックサム保存、LANフレームチェックサム生成、Tinygram圧縮、およびLANの閉集合の識別が含まれます。
IEEE 802.1 stipulates that the Extended LAN must enjoy the same probability of undetected error that an individual LAN enjoys. Although there has been considerable debate concerning the algorithm, no other algorithm has been proposed than having the LAN Frame Checksum received by the ultimate receiver be the same value calculated by the original transmitter. Achieving this requires, of course, that the line protocols preserve the LAN Frame Checksum from end to end. The protocol is optimized towards this approach.
IEEE 802.1は、拡張LANが個々のLANを楽しんで見逃し誤り同じ確率を享受しなければならないと規定しています。アルゴリズムに関してかなりの議論があったが、他のアルゴリズムは、最終的な受信機によって受信されたLANフレームチェックサムが元の送信機によって算出同じ値を有するより提案されていません。これを達成するには、ラインプロトコルが端から端までLANフレームのチェックサムを維持することを、もちろん、必要とされます。プロトコルは、このアプローチに向けて最適化されています。
The fact that the protocol is optimized towards LAN Frame Checksum preservation raises twin questions: "What is the approach to be used by systems which, for whatever reason, cannot easily support Frame Checksum preservation?" and "What is the approach to be used when the system originates a message, which therefore has no Frame Checksum precalculated?".
プロトコルはLANフレームチェックサムの保全に向けて最適化されているという事実は、双子の問題を提起：「どんな理由であれ、簡単にフレームチェックサムの保存をサポートすることができない、システムが使用するアプローチは何ですか？」そして「システムがそれゆえ何フレームチェックサムが事前計算されていないメッセージを、発信するときに使用するアプローチは何ですか？」。
Surely, one approach would be to require stations to calculate the Frame Checksum in software if hardware support were unavailable; this would meet with profound dismay, and would raise serious questions of interpretation in a Bridge/Router.
確かに、1つのアプローチは、ソフトウェア、ハードウェアのサポートが利用できなかった場合には、フレームのチェックサムを計算するためにステーションを必要とするだろう。これは、深い失望と会うだろう、とブリッジ/ルータの解釈の重大な問題を提起するだろう。
However, stations which implement LAN Frame Checksum preservation must already solve this problem, as they do originate traffic. Therefore, the solution adopted is that messages which have no Frame Checksum are tagged and carried across the line.
彼らはトラフィックを発信そうであるようにしかし、LANフレームのチェックサムの保存を実装するステーションはすでに、この問題を解決しなければなりません。したがって、採用されたソリューションには、フレームチェックサムを持っていないメッセージがタグ付けされた、ラインを横切って運ばれることです。
When a system which does not implement LAN Frame Checksum preservation receives a frame having an embedded FCS, it converts it for its own use by removing the trailing four octets. When any system forwards a frame which contains no embedded FCS to a LAN, it forwards it in a way which causes the FCS to be calculated.
LANフレームチェックサム保存を実装していないシステムが埋め込まFCSを有するフレームを受信すると、末尾の4つのオクテットを除去することによって、自身の使用のためにそれを変換します。任意のシステムがLANにない埋め込みFCSを含まないフレームを転送する場合には、FCSが計算させる方法でそれを転送します。
An issue in remote Ethernet bridging is that the protocols that are most attractive to bridge are prone to problems on low speed (64 KBPS and below) lines. This can be partially alleviated by observing that the vendors defining these protocols often fill the PDU with octets of ZERO. Thus, an Ethernet or IEEE 802.3 PDU received from a line that is (1) smaller than the minimum PDU size, and (2) has a LAN Frame Checksum present, must be padded by inserting zeroes between the last four octets and the rest of the PDU before transmitting it on a LAN. These protocols are frequently used for interactive sessions, and therefore are frequently this small.
リモートイーサネットブリッジングでの問題は、ブリッジに最も魅力的なプロトコルは、（64 KBPS以下）のライン低速で問題になりやすいということです。これは、部分的にこれらのプロトコルを定義するベンダーは、多くの場合、ZEROのオクテットでPDUを埋めることを観察することによって軽減することができます。このように、イーサネット（登録商標）またはIEEE 802.3 PDUが最小PDUサイズより（1）小さく、（2）LANフレームチェックサムの存在を有し、最後の4つのオクテットの残りの部分との間にゼロを挿入することによってパディングされなければならないラインから受信LAN上でそれを送信する前にPDU。これらのプロトコルは、頻繁に対話型セッションのために使用され、そのため頻繁にこの小さなされています。
To prevent ambiguity, PDUs requiring padding are explicitly tagged. Compression is at the option of the transmitting station, and is probably performed only on low speed lines, perhaps under configuration control.
あいまいさを防ぐために、パディングが必要なPDUは明示的にタグ付けされています。圧縮は、送信局の選択であり、おそらく、おそらく構成制御の下で、唯一の低速回線上で行われます。
The pseudo-code in Appendix B describes the algorithms.
付録Bで擬似コードは、アルゴリズムを記述する。
IEEE 802.1Q defines Virtual LANs and their exchangeable VLAN Tagged frame format. Virtual LANs allow user multiple community groups to co-exist within one bridge. A bridging community is identified by its VLAN ID. If a system that supports Virtual LANs receives a frame from the LAN, that frame will be only emitted onto a LAN which belongs to the same community. In order to handle multiple communities on a single line, IEEE 802.1Q defines a VLAN Tagged Frame.
IEEE 802.1Qは、仮想LANとその交換可能なVLANタグ付きフレームのフォーマットを定義します。仮想LANは、ユーザの複数のコミュニティグループは1つのブリッジ内に共存することができます。ブリッジのコミュニティは、そのVLAN IDで識別されます。仮想LANをサポートするシステムがLANからフレームを受信した場合、そのフレームは、同じコミュニティに属しているLAN上に照射されます。単一の行に複数のコミュニティを処理するためには、IEEE 802.1QはVLANタグ付きフレームを定義します。
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.
E1、E2、E3、およびE4は、イーサネットLAN（またはトークンリング、FDDIなど）です。 W1は、WAN（T1上PPP）です。 B1とB2は、MACレベルのブリッジです。
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.
あなたは、E1およびE3のエンドステーションが通信したい、とあなたはE2とE4上のエンドステーションが通信したいが、あなたは、E1とE3のエンドステーションは、E2とE4にエンドステーションと通信する必要はありません。
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.
これは、ユニキャスト、マルチキャスト、およびブロードキャストトラフィックについても同様です。ブロードキャストデータグラムがE1に発信した場合、あなたはそれが唯一のE3にはなく、E2または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およびE3は、仮想LANを形成し、以下の構成が実際に使用されていたかのようにE2とE4は、仮想LANを形成することです。
E1 +--+ W2 +--+ E3
------------|B3|------------|B4|------------
+--+ +--+
E2 +--+ W3 +--+ E4
------------|B5|------------|B6|------------
+--+ +--+
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.
ブリッジ制御プロトコル（BCP）は、ポイントツーポイントリンクの両端のブリッジ・プロトコル・モジュールを構成する有効化および無効化の原因です。 BCPは、リンク制御プロトコルと同じパケット交換メカニズムを使用しています。 PPPはネットワーク層プロトコルフェーズに達するまで、BCPパケットが交換されない場合があります。静かに捨てられるべきである。この段階に到達する前に、BCPパケットを受信しました。
The Bridging Control Protocol is exactly the same as the Link Control Protocol [6] with the following exceptions:
ブリッジング制御プロトコルは、以下の例外を除き、リンク制御プロトコル[6]とまったく同じです。
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.
実装は、低速リンク以外に住所・アンド・コントロール・フィールド圧縮またはプロトコルフィールド圧縮を交渉すべきではありません。
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).
正確に一つのBCPパケットは、PPPプロトコルフィールドがタイプヘクス8031を示すPPP情報フィールド、（BCP）にカプセル化されます。
Code field
Codeフィールド
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.
唯一のコード1〜7（設定要求、設定肯定応答、通信設定否定応答、構成拒否、終了要求、終了-ACKおよびコード拒否）が使用されます。他のコードは認識されていないとして扱われるべきとコード・リジェクツを生じるはずです。
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.
PPPはネットワーク層プロトコルフェーズに達するまで、BCPパケットが交換されない場合があります。実装は、通信設定肯定応答または他の応答を待ってタイムアウトする前に終了する認証とリンク品質の決意を待つように準備する必要があります。実装がユーザ介入や時間の設定可能な量の後にあきらめることが示唆されます。
Configuration Option Types
設定オプションの種類
BCP has a distinct set of Configuration Options, which are defined in this document.
BCPは、この文書で定義されている設定オプションの明確なセットを持っています。
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.
任意のブリッジLANトラフィックまたはBPDUが伝達することができる前に、PPPはネットワーク層プロトコルフェーズに達しなければならない、とブリッジング制御プロトコルはOpened状態に達しなければなりません。
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).
正確に一つのブリッジLANトラフィックまたはBPDUは、PPPプロトコルフィールドがタイプヘクス0031（ブリッジPDU）を示すPPP情報フィールド内にカプセル化されています。
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.
PPPリンクを介して送信された架橋データグラムの最大長は、PPPカプセル化されたパケットの情報フィールドの最大長さと同じです。断片化およびブリッジPDUを再構築するための標準的な方法がないため、ブリッジングをサポートするPPPリンクは、後のサポートを埋めるために交渉されているMACタイプをサポートするのに十分な大きMRUを交渉しなければなりません。彼らはMACヘッダを含んでいるので、さえブリッジイーサネットフレームは1500オクテットのデフォルトPPP MRUよりも大きくなっています。
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.
PPPブリッジプロトコルの実装は、マジックナンバーループバック検出およびリンク品質監視を利用することを強くお勧めします。トランスペアレントブリッジングと（標準化されたような）ソースルーティングの両方に不可欠である802.1スパニングツリープロトコルは、通常動作時に一方向性です。コンフィギュレーションBPDUには、ネットワークイベントに応答した以外の任意の逆方向トラフィックなしで、葉の一般的な方向でのルートシステムから発せられます。
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.
このような決定の非存在下において、送信システムは、すべてのプロトコルが順番保存を必要とするかのように行動しなければなりません。主に単一LAN上で使用するために設計された多くのプロトコルは、順序保存を必要とします。
PPP Multilink [7] and its multi-class extension [11] may be used to allow the use of multiple PPP links between a pair of systems without loss of message sequentiality. It treats the group of links as a single link with speed equal to the sum of the speeds of the links in the group.
PPPマルチリンクは、[7]とそのマルチクラス拡張[11]メッセージの連続性を損なうことなくシステムの対の間の複数のPPPリンクの使用を可能にするために使用されてもよいです。これは、グループ内のリンクの速度の和に等しい速度で単一のリンクとしてリンクのグループを処理します。
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.
ネットワーク管理者は論理的に異なる根（及び潜在的に異なるスパニングツリーの実装またはアルゴリズム）を有する別のスパニングツリーに2つの領域を分割するためにリンク上のBPDUの交換を阻害することを望むかもしれないと考えられます。そのために、彼は、リンク上でBPDUを交換しないように両端を設定する必要があります。すべてのスパニングツリープロトコルをサポートしていない実装は静かに任意の受信IEEE 802.1D BPDUパケットを捨てなければなりません。
If a bridge is connected to an old BCP bridge [10], the other bridge cannot operate according to this specification. Options are therefore to decide that:
ブリッジが古いBCPブリッジ[10]に接続されている場合、他のブリッジは、この仕様に応じて動作することができません。オプションはそれを決定するため、以下のとおりです。
(a) If the bridge wants to terminate the connection, it sends a Terminate-Request and terminate the connection. (b) If the bridge wants to run the connection but not receive old BPDUs, its only option is to run without spanning tree on the link at all, which is dangerous. It should Configure-Reject the option and advise the network administration that it has done so. (c) If the bridge chooses to be entirely backward compatible, it sends Configure-Ack and operates in the manner described in Appendix A.
ブリッジは接続を終了したい場合は（A）、それが終了要求を送信し、接続を終了します。ブリッジ接続を実行しますが、古いBPDUを受信しないようにしたい場合（b）は、その唯一のオプションは危険です全くリンク、でスパニングツリーをせずに実行することです。これは、オプションを拒否し、設定し、それはそうしたネットワーク管理を助言すべきです。ブリッジが完全に後方互換性があるように選択した場合（C）は、設定肯定応答を送信し、付録Aに記載のように動作します
In the event that both the new Management-Inline Option and the Spanning-Tree-Protocol-Configuration Option are configure-rejected, indicating that the peer implements no spanning tree protocol at all and doesn't understand the options, it is an incomplete implementation. For safety reasons the system should cease attempting to configure bridging, and log the fact. If the peer was configure-rejecting the options in order to disable spanning tree entirely, it understood the option but could not within its configuration comply. It should have sent the Spanning-Tree-Protocol-Configuration Option with the value NULL.
新しい管理-inlineオプションとスパニングツリープロトコル設定オプションの両方を設定し、拒否された場合には、ピアは全くスパニングツリープロトコルを実装していないとオプションを理解していないことを示し、それは不完全な実装であります。安全上の理由から、システムは、ブリッジングを設定しようと停止し、実際にログインする必要があります。ピアが完全にスパニングツリーをディセーブルにするために構成-拒否するオプションをした場合は、オプションを理解しますが、その設定内準拠していませんでした。これは、NULL値を持つスパニングツリープロトコル設定オプションを送っているはずです。
Implementations SHOULD implement a backward compatibility mode.
実装は、下位互換性モードを実装する必要があります。
For Bridging LAN traffic, the format of the frame on the line is shown below. This format is used if the traffic does not include VLAN ID and priority.
ブリッジLANトラフィックの場合、ライン上のフレームのフォーマットを以下に示します。トラフィックは、VLAN IDと優先順位が含まれていない場合は、このフォーマットが使用されています。
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
+-+-+-+-+-+-+-+-+
| HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address and Control | 0x00 | 0x31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|0|Z|0| Pads | MAC Type | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|Z|0| Pads | MAC Type | 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
PPPプロトコル
0x0031 for PPP Bridging
PPPブリッジングのための0x0031
Flags
国旗
bit F: Set if the LAN FCS Field is present bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum size bit 0: reserved, must be zero
ビットF：LAN FCSフィールドが存在ビットZである場合に設定：IEEE 802.3パッドがゼロに満たさなければならない場合に設定された最小サイズビット0：予約され、ゼロでなければなりません
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.
任意のPPPフレームは、「オプションのデータリンク層のパディング」フィールドに挿入されたパディングを有することができます。この数は、多くのパッドオクテットが剥ぎ取るためにどのように受信システムに指示します。
MAC Type
MACタイプ
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:
MAC Typeフィールドの値は、最新の「Assigned Numbers」に指定されている最新のRFC [4]。次のように現在の値が割り当てられています。
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
0：非標準アドレス5~10とFDDI：非標準アドレス4とIEEE 802.5：正規アドレス3とIEEE 802.4：カノニカルアドレス2とIEEE 802.3 /イーサネット：1予約カノニカルアドレス12とIEEE 802.5：11：予約正規のアドレスを持つFDDI
"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.
「標準的な」とは、IEEEによって標準アドレスの表現として定義されたアドレス形式です。この形式では、LAN上で最初に送信される各バイト内のビットは、最下位ビットとして表されます。対照的に、非標準形式で、最初に送信される各バイト内のビットは最上位ビットとして表されます。多くのLANインタフェースの実装が非標準形式を使用します。両方の形式で、バイトは伝送のために表されています。
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.
実装はそのMACタイプの高い番号のフォーマットであるMACタイプをサポートしている場合、それはまた、MACタイプの低い番号の形式をサポートしなければなりません。例えば、実装は正規のアドレス形式でFDDIをサポートしている場合、それはまた、非正規のアドレス形式でFDDIをサポートしなければなりません。この要件の目的は、本明細書の以前のバージョンと下位互換性を提供することです。
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.
システムは、ピアMAC-サポート設定オプションから受信していない限り、MACタイプは、ピアがそのMACタイプのフレームを受信する意思があることを示す4よりも高い番号が付け送信してはいけません。
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.
802.4、802.5、およびFDDI LAN上、FCSによって保護されてその一つの宛先MACアドレスを、前のいくつかのオクテットがあります。
The MAC Type of the frame determines the contents of the Frame Control field. A pad octet is present to provide 32-bit packet alignment.
フレームのMACタイプは、フレーム制御フィールドの内容を決定します。パッドオクテットは、32ビットのパケットの配置を提供することです。
Destination MAC Address
宛先MACアドレス
As defined by the IEEE. The MAC Type field defines the bit ordering.
IEEEによって定義されているように。 MAC Typeフィールドには、ビット順序を定義します。
Source MAC Address
送信元MACアドレス
As defined by the IEEE. The MAC Type field defines the bit ordering.
IEEEによって定義されているように。 MAC Typeフィールドには、ビット順序を定義します。
LLC data
LLCデータ
This is the remainder of the MAC frame which is (or would be were it present) protected by the LAN FCS.
これはLAN FCSによって保護されている（またはそれが存在していたであろう）は、MACフレームの残りの部分です。
For example, the 802.5 Access Control field, and Status Trailer are not meaningful to transmit to another ring, and are omitted.
例えば、802.5アクセス制御フィールド、およびステータストレーラーは、別の環に送信する意味のものではなく、省略されています。
LAN FCS
LAN FCS
If present, this is the LAN FCS which was calculated by (or which appears to have been calculated by) the originating station. If the LAN FCS flag is not set, then this field is not present, and the PDU is four octets shorter.
存在する場合、これは発信局をすることにより算出した（またはで計算されているように見える）LAN FCSです。 LAN FCSフラグが設定されていない場合、このフィールドは存在せず、PDUは4つのオクテット短いです。
Optional Data Link Layer Padding
オプションのデータリンク層のパディング
Any PPP frame may have padding inserted between the Information field and the Frame FCS. The Pads field contains the length of this padding, which may not exceed 15 octets.
任意のPPPフレームは情報フィールドとフレームのFCSの間に挿入パディングを有することができます。パッドフィールドは、15個のオクテットを超えないようにして、このパディングの長さを含みます。
The PPP LCP Extensions [5] specify a self-describing pad. Implementations are encouraged to set the Pads field to zero, and use the self-describing pad instead.
PPP LCP拡張[5]自己記述パッドを指定します。実装はゼロにパッドフィールドを設定し、その代わりに、自己記述パッドを使用することが奨励されます。
Frame FCS
FCSフレーム
Mentioned primarily for clarity. The FCS used on the PPP link is separate from and unrelated to the LAN FCS.
明確にするため、主に言及しました。 PPPリンク上で使用されるFCSは別にしてLAN FCSとは無関係です。
To connect two or more Virtual LAN segments, the frame MUST include its VLAN ID and priority. An IEEE 802 Tagged Frame may be used if the IEEE-802-Tagged-Frame Option is accepted by the peer. The format of the frame on the line is shown below.
二つ以上の仮想LANセグメントを接続するために、フレームは、VLAN IDと優先順位を含まなければなりません。 IEEE-802タグ付きフレームオプションがピアによって受け入れられた場合、IEEE 802タグ付きフレームを使用することができます。ライン上のフレームのフォーマットを以下に示します。
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
+-+-+-+-+-+-+-+-+
| HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address and Control | 0x00 | 0x31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|0|Z|0| Pads | MAC Type | Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address | 0x81 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pri |C| VLAN ID | Length/Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAN FCS (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| potential line protocol pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0|Z|0| Pads | MAC Type | Pad Byte | Frame Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP-encoded TPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP-encoded TPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Pri |C| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
PPPプロトコル
0x0031 for PPP Bridging
PPPブリッジングのための0x0031
Flags
国旗
bit F: Set if the LAN FCS Field is present bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum size bit 0: reserved, must be zero
ビットF：LAN FCSフィールドが存在ビットZである場合に設定：IEEE 802.3パッドがゼロに満たさなければならない場合に設定された最小サイズビット0：予約され、ゼロでなければなりません
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.
任意のPPPフレームは、「オプションのデータリンク層のパディング」フィールドに挿入されたパディングを有することができます。この数は、多くのパッドオクテットが剥ぎ取るためにどのように受信システムに指示します。
MAC Type
MACタイプ
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:
MAC Typeフィールドの値は、最新の「Assigned Numbers」に指定されている最新のRFC [4]。次のように現在の値が割り当てられています。
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
0：非標準アドレス5~10とFDDI：非標準アドレス4とIEEE 802.5：正規アドレス3とIEEE 802.4：カノニカルアドレス2とIEEE 802.3 /イーサネット：1予約カノニカルアドレス12とIEEE 802.5：11：予約正規のアドレスを持つFDDI
"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.
「標準的な」とは、IEEEによって標準アドレスの表現として定義されたアドレス形式です。この形式では、LAN上で最初に送信される各バイト内のビットは、最下位ビットとして表されます。対照的に、非標準形式で、最初に送信される各バイト内のビットは最上位ビットとして表されます。多くのLANインタフェースの実装が非標準形式を使用します。両方の形式で、バイトは伝送のために表されています。
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.
実装はそのMACタイプの高い番号のフォーマットであるMACタイプをサポートしている場合、それはまた、MACタイプの低い番号の形式をサポートしなければなりません。例えば、実装は正規のアドレス形式でFDDIをサポートしている場合、それはまた、非正規のアドレス形式でFDDIをサポートしなければなりません。この要件の目的は、本明細書の以前のバージョンと下位互換性を提供することです。
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.
システムは、ピアMAC-サポート設定オプションから受信していない限り、MACタイプは、ピアがそのMACタイプのフレームを受信する意思があることを示す4よりも高い番号が付け送信してはいけません。
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.
802.4、802.5、およびFDDI LAN上、FCSによって保護されてその一つの宛先MACアドレスを、前のいくつかのオクテットがあります。
The MAC Type of the frame determines the contents of the Frame Control field. A pad octet is present to provide 32-bit packet alignment.
フレームのMACタイプは、フレーム制御フィールドの内容を決定します。パッドオクテットは、32ビットのパケットの配置を提供することです。
Destination MAC Address
宛先MACアドレス
As defined by the IEEE. The MAC Type field defines the bit ordering.
IEEEによって定義されているように。 MAC Typeフィールドには、ビット順序を定義します。
Source MAC Address
送信元MACアドレス
As defined by the IEEE. The MAC Type field defines the bit ordering.
IEEEによって定義されているように。 MAC Typeフィールドには、ビット順序を定義します。
Pri 3 bit priority value as defined by IEEE 802.1D.
IEEE 802.1Dによって定義されるようなPRI 3ビットの優先度値。
C Canonical flag as defined by IEEE 802.1Q. It must be set if RIF data is present in the LLC data.
IEEE 802.1Qによって定義されるようなC正規フラグ。 RIFデータがLLCデータに存在している場合は設定する必要があります。
VLAN ID 12 bit VLAN identifier number as defined by IEEE 802.1Q.
IEEE 802.1Qによって定義されるVLAN ID 12ビットVLAN識別番号。
LLC data
LLCデータ
This is the remainder of the MAC frame which is (or would be were it present) protected by the LAN FCS.
これはLAN FCSによって保護されている（またはそれが存在していたであろう）は、MACフレームの残りの部分です。
For example, the 802.5 Access Control field, and Status Trailer are not meaningful to transmit to another ring, and are omitted.
例えば、802.5アクセス制御フィールド、およびステータストレーラーは、別の環に送信する意味のものではなく、省略されています。
LAN FCS
LAN FCS
If present, this is the LAN FCS which was calculated by (or which appears to have been calculated by) the originating station. If the LAN FCS flag is not set, then this field is not present, and the PDU is four octets shorter.
存在する場合、これは発信局をすることにより算出した（またはで計算されているように見える）LAN FCSです。 LAN FCSフラグが設定されていない場合、このフィールドは存在せず、PDUは4つのオクテット短いです。
Optional Data Link Layer Padding
オプションのデータリンク層のパディング
Any PPP frame may have padding inserted between the Information field and the Frame FCS. The Pads field contains the length of this padding, which may not exceed 15 octets.
任意のPPPフレームは情報フィールドとフレームのFCSの間に挿入パディングを有することができます。パッドフィールドは、15個のオクテットを超えないようにして、このパディングの長さを含みます。
The PPP LCP Extensions [5] specify a self-describing pad. Implementations are encouraged to set the Pads field to zero, and use the self-describing pad instead.
PPP LCP拡張[5]自己記述パッドを指定します。実装はゼロにパッドフィールドを設定し、その代わりに、自己記述パッドを使用することが奨励されます。
Frame FCS
FCSフレーム
Mentioned primarily for clarity. The FCS used on the PPP link is separate from and unrelated to the LAN FCS.
明確にするため、主に言及しました。 PPPリンク上で使用されるFCSは別にしてLAN FCSとは無関係です。
To avoid network loops and improve redundancy, Bridges exchange a Spanning Tree Protocol data unit known as BPDU. Bridges also exchange a Generic Attributes Registration Protocol data unit to carry the GARP VLAN Registration Protocol (GVRP) data and GARP Multicast Registration Protocol (GMRP). GVRP allow the Bridges to create VLAN groups dynamically. GMRP allows bridges to filter Multicast data if the receiver is absent from the network. These Bridge protocols include Spanning Tree Protocol and GARP protocols data units are carried with a special destination address assigned by the IEEE.
ネットワークループを回避し、冗長性を向上させるために、ブリッジがBPDUとして知られているスパニングツリープロトコルデータユニットを交換します。ブリッジはまた、GARP VLAN登録プロトコル（GVRP）データおよびGARPマルチキャスト登録プロトコル（GMRP）を運ぶために一般属性登録プロトコルデータユニットを交換します。 GVRP橋が動的VLANグループを作成することができます。 GMRPは、受信機がネットワークに存在しない場合、ブリッジは、マルチキャストデータをフィルタリングすることを可能にします。これらのブリッジプロトコルは、スパニングツリープロトコルが含まれており、GARPプロトコルデータユニットは、IEEEによって割り当てられた特別な宛先アドレスで運ばれます。
These bridge protocols data units and GARP protocol data units must be carried in the frame format shown in section 4.2 or 4.3. The Bridge that receives these data units identifies these protocols based on the destination address in the frame format, just like the operation of receiving frames from a LAN segment.
これらのブリッジプロトコルデータユニットとGARPプロトコルデータユニットは、セクション4.2または4.3に示すフレームフォーマットで実施しなければなりません。これらのデータユニットを受信するブリッジは、単にLANセグメントからのフレームを受信する動作と同様、フレームフォーマットの宛先アドレスに基づいて、これらのプロトコルを識別する。
Bridge protocols and GARP protocols data units MUST be recognized by checking the destination addresses, which are assigned by IEEE.
ブリッジプロトコルとGARPプロトコルデータユニットは、IEEEによって割り当てられた宛先アドレスをチェックすることによって認識されなければなりません。
01-80-c2-00-00-00 Bridge Group Address (used by STP) 01-80-c2-00-00-01 IEEE Std. 802.3x Full Duplex PAUSE operation 01-80-c2-00-00-10 Bridge Management Group Address 01-80-c2-00-00-20 GARP Multicast Registration Protocol (GMRP) 01-80-c2-00-00-21 GARP VLAN Registration Protocol (GVRP)
（STPによって使用される）01-80-C2-00-00-00ブリッジグループアドレス01-80-c2-00-00-01 IEEE STD。 802.3xの全二重PAUSE操作01-80-c2-00-00-10ブリッジ・マネジメント・グループアドレス01-80-c2-00-00-20 GARPマルチキャスト登録プロトコル（GMRP）01-80-c2-00-00-21 GARP VLAN登録プロトコル（GVRP）
But there is one exception to this rule: if the bridge is connected to an old BCP bridge [10] and can support backward compatibility, it MUST send the BPDU in the old format described in Appendix A.
しかし、この規則の唯一の例外があります：ブリッジが古いBCPブリッジ[10]に接続されていると、それは付録Aに記載の古い形式でBPDUを送信しなければならないの下位互換性をサポートできる場合
BCP Configuration Options allow modifications to the standard characteristics of the network-layer protocol to be negotiated. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed.
BCP設定オプションは、ネットワーク層プロトコルの標準特性への変更が交渉されることを可能にします。設定オプションが設定要求パケットに含まれていない場合は、その設定オプションのデフォルト値が仮定されます。
BCP uses the same Configuration Option format defined for LCP [6], with a separate set of Options.
BCPは、オプションの別個のセットと、LCP [6]のために定義された同一の構成オプションのフォーマットを使用します。
Up-to-date values of the BCP Option Type field are specified in the most recent "Assigned Numbers" RFC [4]. Current values are assigned as follows:
BCPオプションタイプフィールドの値は、最新の「Assigned Numbers」に指定されている最新のRFC [4]。次のように現在の値が割り当てられています。
1 Bridge-Identification
2 Line-Identification
3 MAC-Support
4 Tinygram-Compression
5 LAN-Identification (obsoleted)
6 MAC-Address
7 Spanning-Tree-Protocol (old formatted)
8 IEEE 802 Tagged Frame
9 Management Inline
Description
説明
The Bridge-Identification Configuration Option is designed for use when the line is an interface between half bridges connecting virtual or physical LAN segments. Since these remote bridges are modeled as a single bridge with a strange internal interface, each remote bridge needs to know the LAN segment and bridge numbers of the adjacent remote bridge. This option MUST NOT be included in the same Configure-Request as the Line-Identification option.
線が仮想または物理LANセグメントを接続するハーフブリッジとの間のインタフェースであるときブリッジ識別設定オプションを使用するように設計されます。これらのリモートブリッジが奇妙内部インターフェースを備えた単一のブリッジとしてモデル化されているので、各リモート・ブリッジは、隣接するリモートブリッジのLANセグメントおよびブリッジ番号を知る必要があります。このオプションはライン識別オプションと同じ設定要求に含まれてはいけません。
The Source Routing Route Descriptor and its use are specified by the IEEE 802.1D Appendix on Source Routing. It identifies the segment to which the interface is attached by its configured segment number, and itself by bridge number on the segment.
ソースルーティングルート記述子とその使用は、ソースルーティング上のIEEE 802.1D付録で指定されています。これは、セグメント上のブリッジ番号によってそれ自身をインターフェイスは、その構成されたセグメント番号によって取り付けられたセグメントを識別し、。
The two half bridges MUST agree on the bridge number. If a bridge number is not agreed upon, the Bridging Control Protocol MUST NOT enter the Opened state.
2つのハーフブリッジは、ブリッジ番号に同意しなければなりません。ブリッジ番号が合意されていない場合は、ブリッジング制御プロトコルはOpened状態に入ってはいけません。
Since mismatched bridge numbers are indicative of a configuration error, a correct configuration requires that either the bridge declare the misconfiguration or choose one of the options. To allow two systems to proceed to the Opened state despite a mismatch, a system MAY change its bridge number to the higher of the two numbers. A higher-numbered system MUST NOT change its bridge number to a lower number. It should, however, inform the network administration of the misconfiguration in any case.
不一致のブリッジ番号が設定エラーを示しているので、正しい構成は、ブリッジのどちらかが設定ミスを宣言するかのいずれかのオプションを選択する必要があります。 2つのシステムが不一致にもかかわらず、オープン状態に進行させるために、システムは、2つの数の上位にそのブリッジ番号を変更することがあります。高い番号のシステムは低い数字にそのブリッジ番号を変更しないでください。それは、しかし、どのような場合には設定ミスのネットワーク管理を通知する必要があります。
By default, a system that does not negotiate this option is assumed to be configured not to use the model of the two systems as two halves of a single source-route bridge. It is instead assumed to be configured to use the model of the two systems as two independent bridges.
デフォルトでは、このオプションをネゴシエートしないシステムは、単一のソースルートブリッジの両半分ように、2つのシステムのモデルを使用しないように構成されているものとします。その代わりに二つの独立したブリッジとして2つの系統のモデルを使用するように構成されているものとします。
Example
例
If System A announces LAN Segment AAA, Bridge #1, and System B announces LAN Segment BBB, Bridge #1, then the resulting Source Routing configuration (read in the appropriate direction) is then AAA,1,BBB.
システムAが発表場合LANセグメントAAA、ブリッジ＃1、及びシステムBは、LANセグメントBBB、ブリッジ＃1を発表し、次いで得られたソースルーティング構成は、（適切な方向に読み取る）をAAA、1、BBBです。
A summary of the Bridge-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
タイプ
1
１
Length
長さ
4
４
LAN Segment Number
LANのセグメント番号
A 12-bit number identifying the LAN segment, as defined in the IEEE 802.1D Source Routing Specification.
IEEE 802.1Dソースルーティング仕様で定義されているLANセグメントを識別する12ビット数。
Bridge Number
ブリッジ番号
A 4-bit number identifying the bridge on the LAN segment, as defined in the IEEE 802.1D Source Routing Specification.
IEEE 802.1Dソースルーティング仕様で定義され、LANセグメント上のブリッジを識別する4ビットの数。
Description
説明
The Line-Identification Configuration Option is designed for use when the line is assigned a LAN segment number as though it were a two system LAN segment in accordance with the Source Routing algorithm.
それはソースルーティングアルゴリズムに従って、2つのシステムのLANセグメントであるかのようにラインをLANセグメント番号が割り当てられているときに、ライン識別設定オプションを使用するように設計されます。
The Source Routing Route Descriptor and its use are specified by the IEEE 802.1D Appendix on Source Routing. It identifies the segment to which the interface is attached by its configured segment number, and itself by bridge number on the segment.
ソースルーティングルート記述子とその使用は、ソースルーティング上のIEEE 802.1D付録で指定されています。これは、セグメント上のブリッジ番号によってそれ自身をインターフェイスは、その構成されたセグメント番号によって取り付けられたセグメントを識別し、。
The two bridges MUST agree on the LAN segment number. If a LAN segment number is not agreed upon, the Bridging Control Protocol MUST NOT enter the Opened state.
2つのブリッジは、LANセグメント番号に同意しなければなりません。 LANセグメント番号が合意されていない場合は、ブリッジング制御プロトコルはOpened状態に入ってはいけません。
Since mismatched LAN segment numbers are indicative of a configuration error, a correct configuration requires that either the bridge declare the misconfiguration or choose one of the options. To allow two systems to proceed to the Opened state despite a mismatch, a system MAY change its LAN segment number to the higher of the two numbers. A higher-numbered system MUST NOT change its LAN segment number to a lower number. It should, however, inform the network administration of the misconfiguration in any case.
不一致のLANセグメント番号が設定エラーを示しているので、正しい構成は、ブリッジのどちらかが設定ミスを宣言するかのいずれかのオプションを選択する必要があります。 2つのシステムが不一致にもかかわらず、オープン状態に進行させるために、システムは、2つの数の上位にそのLANセグメント番号を変更することがあります。より高い番号のシステムは、より低い数へのLANセグメント番号を変更しないでください。それは、しかし、どのような場合には設定ミスのネットワーク管理を通知する必要があります。
By default, a system that does not negotiate this option is assumed to have its LAN segment number correctly configured by the user.
デフォルトでは、このオプションを交渉していないシステムは、そのLANセグメント番号が正しく利用者によって構成されているものとします。
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
LANのセグメント番号
A 12-bit number identifying the LAN segment, as defined in the IEEE 802.1D Source Routing Specification.
IEEE 802.1Dソースルーティング仕様で定義されているLANセグメントを識別する12ビット数。
Bridge Number
ブリッジ番号
A 4-bit number identifying the bridge on the LAN segment, as defined in the IEEE 802.1D Source Routing Specification.
IEEE 802.1Dソースルーティング仕様で定義され、LANセグメント上のブリッジを識別する4ビットの数。
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.
MAC-サポート設定のオプションは、それらが受信する用意があるトラフィックの種類を示すための実装を可能にするために提供されます。このオプションの交渉を強くお勧めします。
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.
実装はそれがサポートするMACタイプを発表していない場合、デフォルトでは、すべてのMACタイプは、与えられた他の設定パラメータを輸送されることが可能であるピアによって送信されます。受信機は、それがサポートしていないものをMACタイプを破棄します。
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.
1600オクテットMRUをサポートするデバイスは、1600オクテットよりも大きいた各支持フレームを802.5、802.4またはFDDIをサポートすることをいとわないかもしれません。
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.
それがサポートするMACタイプを発表することで、実装は、すべての未指定のMACタイプは破棄され、そのピアをアドバイスしています。ピアは、サポートされていないMACタイプを送信しないことにより、帯域幅の使用量を減らすことができます。
Announcement of support for multiple MAC Types is accomplished by placing multiple options in the Configure-Request.
複数のMACタイプのサポートの発表は、設定要求で複数のオプションを配置することによって達成されます。
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.
MAC-サポートオプションフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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
３
Length
長さ
3
３
MAC Type
MACタイプ
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.
このシステムは受信してサービスする用意があることをPDU MACタイプフィールドの値のいずれか（以前に「ブリッジLANトラフィック」に記載）。
Description
説明
This Configuration Option permits the implementation to indicate support for Tinygram compression.
この設定オプションは、Tinygram圧縮のためのサポートを示すために、実装を可能にします。
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.
Tinygram圧縮オプションフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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
３
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.
値が1の場合、Tinygram圧縮が有効になっています。値が2である場合、Tinygram-圧縮は無効になり、何の減圧は発生しません。
The implementations need not agree on the setting of this parameter. One may be willing to decompress and the other not.
実装は、このパラメータの設定に同意する必要はありません。一つは、解凍して喜んで、その他ではないかもしれません。
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.
MACアドレス設定オプションは、そのMACアドレスをアナウンスまたは1つが割り当てられているために、実装を可能にします。 MACアドレスは、マルチキャストビットは、アドレスの最初のオクテットの最下位ビットであるということであるIEEE 802.1標準形式で表されています。
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.
システムは、そのMACアドレスをアナウンスしたい場合は、指定されたMACアドレスを持つオプションを送信します。設定要求内の非ゼロのMACアドレスを指定する場合、設定否定応答でこのオプションのいずれかの含めることは無視しなければなりません。
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.
実装は、割り当てられたMACアドレスを持っているしたい場合は、それは00-00-00-00-00-00のMACアドレスとオプションを送信します。アドレス割り当てのためのメカニズムを持っていないシステムでは、オプションを設定して拒否されます。
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.
通信設定否定応答は、有効なIEEE 802.1形式の物理アドレスを指定する必要があります。マルチキャストビットはゼロでなければなりません。強くローカルに割り当てられたアドレスを示し、「局所的に割り当てられたアドレス」ビット（最初のオクテットの第二の最下位ビット）が設定されていることが（必須ではないが）が推奨されます。
A summary of the MAC-Address Option format is shown below. The fields are transmitted from left to right.
MACアドレスオプションフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6
６
Length
長さ
8
８
MAC Byte
MACバイト
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.
802.1標準的な順序でMACアドレスの6つのオクテット。明確にするために、ローカルの割り当て（L）及びマルチキャスト（M）ビットの位置は、図に示されています。
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.
スパニングツリー・プロトコル設定は、BCPの古い実装[10]との互換性を保つために橋を可能にします。この設定オプションは、しかし、IEEEは現在、ブリッジが使用できるように期待し、多くのプロトコルを実装するためのブリッジを可能に管理・インライン・オプションと互換性がありません。
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.
ピアは、拒否設定送信することによって、管理、インライン構成オプションを拒否した場合、それは、必要に応じて交渉を終了することが付録Aにシステムを記載し、またはそのように交渉するために提供されている[10]の実装でなければなりません。
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.
両方のブリッジがスパニングツリープロトコルをサポートしている場合この場合は、それらがサポートするプロトコルに同意しなければなりません。付録Aに記載さ古いBPDUは、セクション4.2または4.3に示すようなフォーマットではなく、使用しなければなりません。 2は2つのスパニングツリープロトコルの低い番号、同意できない場合には使用すべきです。競合を解決するには、より低い番号のプロトコルを使用してシステムを使用するために、独自のプロトコルを示唆し、オプションを否定応答に設定する必要があります。スパニングツリープロトコルが合意されていない場合は、一つのシステムは任意のスパニングツリープロトコルをサポートしていない場合を除き、ブリッジング制御プロトコルはOpened状態に入ってはいけません。
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.
ほとんどのシステムは、単一のスパニングツリープロトコルに参加します。システムに複数のスパニングツリープロトコルに同時に参加することを希望する場合は、単一のスパニングツリー・プロトコル設定オプションに適切なプロトコルタイプのすべてを含んでいてもよいです。プロトコルタイプは、数値昇順で指定する必要があります。交渉中の比較のために、プロトコル番号は、単一の番号であることを考えなければなりません。システムAは、プロトコルが含まれている場合、例えば、01と03とシステムBは、プロトコル03、システムBは、NAKを設定し、0103以来03のプロトコルタイプが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.
デフォルトでは、実装は、IEEE 802.1Dスパニングツリーをサポートしたり、まったくスパニングツリープロトコルをサポートしていない必要があります。静かいずれかを捨てなければなりません任意のスパニングツリープロトコルをサポートしていない実装では、IEEE 802.1D BPDUパケットを受信し、いずれかを静かに捨てるか、この場合には、パケットをプロトコルが拒否LCPと他の受信BPDUパケットに反応しなければなりません。
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.
積極的にサポートされる各プロトコルの2つのオクテットプラス1つの追加オクテット。ほとんどのシステムは唯一の3の長さで、その結果、単一スパニングツリープロトコルをサポートします。
Protocol n
プロトコルの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:
各プロトコルフィールドは1つのオクテットであり、所望のスパニングツリープロトコルを示しています。スパニングツリー・プロトコルフィールドの最新の値は最新の「番号割り当て」RFC [4]でPPP DLL番号として指定されています。次のように現在の値が割り当てられています。
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
0ヌル（非スパニングツリープロトコルがサポートされていない）1 IEEE 802.1Dスパニングツリー2 IEEE 802.1G拡張スパニングツリープロトコル3 IBMソースルートスパニングツリープロトコル12月4日LANbridge 100スパニングツリープロトコル
Description
説明
This configuration option permits the implementation to indicate support for IEEE 802 Tagged Frame. Negotiation of this option is strongly recommended.
この設定オプションは、IEEE 802タグ付きフレームのサポートを示すために、実装を可能にします。このオプションの交渉を強くお勧めします。
A device supporting IEEE 802 Tagged Frame must be willing to support IEEE 802 Tagged Frame shown in section 4.3.
IEEE 802タグ付きフレームをサポートしているデバイスは、セクション4.3に示されているIEEE 802タグ付きフレームをサポートして喜んでなければなりません。
By default, IEEE 802 Tagged Frame is not supported. A system which does not negotiate, or negotiates this option to be disabled, should never receive a IEEE 802 Tagged Frame.
デフォルトでは、IEEE 802タグ付きフレームがサポートされていません。交渉、または無効にするには、このオプションを交渉する、IEEE 802タグ付きフレームを受信することはありませんしませんシステム。
A summary of the IEEE 802 Tagged Frame Option format is shown below. The fields are transmitted from left to right.
IEEE 802タグ付きフレームオプションフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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
タイプ
8
８
Length
長さ
3
３
Enable/Disable
有効化/無効化
If the value is 1, IEEE-802-Tagged-Frame is enabled. If the value is 2, IEEE-802-Tagged-Frame is disabled, and MUST not send any IEEE-802-Tagged-Frame packet.
値が1の場合、IEEE-802-タグ付きフレームが有効になっています。値が2である場合には、IEEE-802-タグ付きフレームは無効になり、任意のIEEE-802-タグ付きフレームのパケットを送信してはなりません。
Description
説明
The Management-Inline Configuration Option indicates that the system is willing to receive any IEEE-defined inter-bridge protocols, such as bridge protocol data units and GARP protocol data units, in the frame format shown in section 4.2 or 4.3.
管理インライン構成オプションは、システムがセクション4.2または4.3に示すフレームフォーマットでは、このようなブリッジプロトコルデータユニットとGARPプロトコルデータユニットとして、任意のIEEE定義のブリッジ間のプロトコルを受信する意思があることを示しています。
Old BCP [10] implementations will use the negotiation procedure described in section 5.6. Implementations of this procedure will use this option to indicate compliance with the new BCP and may optionally negotiate the section 5.6 procedure, either on the same configure-request or in response to a configure-reject, as well. It is recommended that the configure-request only show this option when it is relevant, and that it reply with the Spanning-Tree-Protocol (old formatted) option if a configure-reject is received, as in the normal case one can expect it to be the quickest negotiation.
古いBCP [10]の実装はセクション5.6で説明したネゴシエーション手順を使用します。この手順の実装は、新しいBCPの準拠を示すために、このオプションを使用し、必要に応じて同一の設定要求に又は同様に、リジェクト設定に応答してのいずれかで、セクション5.6の手順を交渉することができます。関連しているとき、設定要求のみ、このオプションを示すこと、および-は拒否configureが受信された場合、それは1がそれを期待することができ、通常の場合のように、スパニングツリープロトコル（旧書式付き）オプションを使用して返信することをお勧めします最速交渉するように。
If a system receives a configure-request offering both alternatives, it should accept this procedure and reject the Spanning-Tree-Protocol (old format) option.
システムは両方の選択肢を提供する設定要求を受信した場合、この手順を受け入れて、スパニングツリープロトコル（旧形式）オプションを拒否すべきです。
One can expect old BCP [10] implementations to not understand the option and issue a configure-reject.
一つは、古いBCP [10]の実装はオプションを理解し、configureはリジェクト発行しないことを期待することができます。
By default, Management-Inline is not allowed. A system which does not negotiate, or negotiates this option to be disabled, should never receive a Bridge Protocol data unit or GARP protocol data unit inline.
デフォルトでは、管理-インラインが許可されていません。交渉、または無効にするには、このオプションを交渉しないシステムでは、ブリッジプロトコルデータユニットまたはGARPプロトコルデータユニットをインラインで受け取ることはありません。
A summary of the Management-Inline Option format is shown below. The fields are transmitted from left to right.
管理-inlineオプションフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
9
９
Length
長さ
2
２
This section enumerates changes made to old BCP [10] to produce this document.
このセクションでは、この文書を生成するために古いBCP [10]に加えられた変更を列挙します。
(1) Remove all LAN Identification descriptions and replace with IEEE 802.1Q VLAN descriptions.
（1）すべてのLAN識別記述を削除し、IEEE 802.1Q VLANの説明と交換してください。
(2) Remove LAN Identification field from frame format and I flags from flag field. (3) Merge the Spanning Tree BPDU frame format with Bridged traffic.
（2）フラグフィールドのフラグをフレームフォーマットからLAN識別フィールドを削除し、I。 （3）ブリッジトラフィックでスパニングツリーBPDUフレームフォーマットをマージします。
This network control protocol compares the configurations of two devices and seeks to negotiate an acceptable subset of their intersection, to enable correct interoperation even in the presence of minor configuration or implementation differences. In the event that a major misconfiguration is detected, the negotiation will not complete successfully, resulting in the link coming down or not coming up. It is possible that if a bridged link comes up with a rogue peer, network information may be learned from forwarded multicast traffic, or denial of service attacks may be created by closing loops that should be detected and isolated or by offering rogue load.
このネットワーク制御プロトコルは、2つのデバイスの構成を比較してもマイナーな構成や実装の違いの存在下で正しい相互運用を可能にするために、それらの交差点の許容されるサブセットをネゴシエートしようとするものです。主要な設定ミスが検出された場合、交渉は下って来るか来ていないリンクで、その結果、正常に完了しません。ブリッジリンクが不正なピアで起動した場合、ネットワーク情報が検出され、孤立しなければならないのループを閉じることにより、または不正な負荷を提供することにより、転送されたマルチキャストトラフィックから学ぶことができる、またはサービス拒否攻撃が作成される可能性があります。
Such attacks are not isolated to this NCP; any PPP NCP is subject to attack when connecting to a foreign or compromised device. However, no situations arise which are not common to all NCPs; any NCP that comes up with a rogue peer is subject to snooping and other attacks. Therefore, it is recommended that links on which this may happen should be configured to use PPP authentication during the LCP start-up phase.
このような攻撃は、このNCPに絶縁されていません。任意PPP NCPは、外来または損なわデバイスに接続するときに攻撃の対象です。しかし、状況は、すべてのNCPに共通されていない発生しません。不正なピアを思い付くすべてのNCPはスヌーピングやその他の攻撃の対象となります。そのため、起こる可能性がある上のリンクがLCP起動フェーズ中にPPP認証を使用するように設定することをお勧めします。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat."
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、あるいは本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。」
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
This document proposes a total of two new BCP option numbers to be maintained by the IANA. These options (described in Section 5.1 and 5.2) are IEEE-802-Tagged-Frame and Management-Inline. The IANA has assigned the values 8 and 9 respectively for these option numbers.
この文書では、2つの新しいBCPオプション数の合計は、IANAによって維持されることを提案しています。 （セクション5.1と5.2で説明した）これらのオプションは、IEEE-802-タグ付きフレームと管理・インラインです。 IANAは、これらのオプション番号にそれぞれ値8と9が割り当てられています。
This document is a product of the Point-to-Point Protocol Extensions Working Group.
この文書では、ポイントツーポイントプロトコルの拡張作業部会の製品です。
This document is based on the PPP Bridging Control Protocol, RFC 1638 [10], edited by Rich Bowen of IBM and produced by the Point-to-Point Protocol Extensions Working Group. It extends that document by providing support for Virtual LANs as outlined in [9].
このドキュメントは、PPPブリッジング制御プロトコルに基づいており、RFC 1638 [10]、IBMのリッチボーエンによって編集され、ポイントツーポイントプロトコルの拡張ワーキンググループによって作成。これは、[9]に概説されているよう仮想LANのサポートを提供することによって、そのドキュメントを拡張します。
A. Spanning Tree Bridge PDU (old format)
A.スパニングツリーブリッジPDU（旧形式）
By default, Spanning Tree BPDUs MUST be encoded with a MAC or 802.2 LLC header as described in section 4.2 or 4.3 of this document. However, should the remote entity Configure-Reject the Management-Inline option, thereby indicating that it is a purely RFC 1638 compliant device, the local entity may subsequently encode BPDUs as described in section 4.3 of RFC 1638 provided that use of a suitable non-NULL STP protocol across the link is successfully negotiated using the (old) Spanning-Tree-Protocol option.
セクション4.2、またはこの文書の4.3に記載されているように、デフォルトでは、スパニングツリーBPDUがMACまたは802.2 LLCヘッダで符号化されなければなりません。しかし、リモートエンティティは、それによってそれが純粋にRFC 1638に準拠機器であることを示す、管理インラインオプションを設定し、拒否すべきである適切な非の使用を提供RFC 1638のセクション4.3で説明したように、ローカルエンティティは、その後BPDUをコードすることができますリンクを介してNULL STPプロトコルが成功した（旧）スパニングツリー・プロトコルのオプションを使用して交渉しています。
This is the Spanning Tree BPDU used in RFC 1638, without any MAC or 802.2 LLC header (these being functionally equivalent to the Address, Control, and PPP Protocol Fields). The LAN Pad and Frame Checksum fields are likewise superfluous and absent.
これは、スパニングツリーBPDUは、（これらのアドレス、制御、およびPPPプロトコルフィールドと機能的に等価である）任意のMACまたは802.2 LLCヘッダなしで、RFC 1638で使用されています。 LANパッドとフレームのチェックサムフィールドは、同様に、余分と存在しません。
The Address and Control Fields are subject to LCP Address-and-Control-Field-Compression negotiation.
アドレスと制御フィールドは、LCP住所・アンド・コントロール・フィールド圧縮交渉の対象となります。
A PPP system which is configured to participate in a particular spanning tree protocol and receives a BPDU of a different spanning tree protocol SHOULD reject it with the LCP Protocol-Reject. A system which is configured not to participate in any spanning tree protocol MUST silently discard all BPDUs.
異なるスパニングツリープロトコルのBPDUを特定のスパニングツリープロトコルに参加するように構成され、受信されたPPPシステムは、プロトコルが拒否LCPでそれを拒否すべきです。任意のスパニングツリープロトコルに参加しないように構成されているシステムは静かにすべてのBPDUを捨てなければなりません。
Spanning Tree Bridge PDU
スパニングツリーブリッジPDU
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 | Spanning Tree Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPDU data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame FCS | HDLC FLAG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address and Control
住所と制御
As defined by the framing in use.
使用中のフレーミングによって定義されているように。
Spanning Tree Protocol
スパニングツリープロトコル
Up-to-date values of the Spanning-Tree-Protocol field are specified in the most recent "Assigned Numbers" RFC [4]. Current values are assigned as follows:
スパニングツリー・プロトコルフィールドの値は、最新の「Assigned Numbers」に指定されている最新のRFC [4]。次のように現在の値が割り当てられています。
Value (in hex) Protocol
（16進数）の値プロトコル
0201 IEEE 802.1 (either 802.1D or 802.1G) 0203 IBM Source Route Bridge 0205 DEC LANbridge 100
0201 IEEE 802.1（802.1Dまたは802.1Gのいずれか）0203 IBMソースルートブリッジ0205 DEC LANbridge 100
The two versions of the IEEE 802.1 spanning tree protocol frames can be distinguished by fields within the BPDU data.
IEEE 802.1スパニングツリープロトコルのフレームの2つのバージョンは、BPDUデータ内のフィールドによって区別することができます。
BPDU data
BPDU日
As defined by the specified Spanning Tree Protocol.
指定されたスパニングツリープロトコルによって定義されているように。
B. Tinygram-Compression Pseudo-Code
B. Tinygram圧縮擬似コード
PPP Transmitter:
PPPトランスミッター：
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:
PPP受信機：
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 */
}
}
References
リファレンス
[1] IBM, "Token-Ring Network Architecture Reference", 3rd edition, September 1989.
[1] IBM、「トークンリングネットワークアーキテクチャリファレンス」、第3版、1989年9月。
[2] IEEE 802.1, "Draft Standard 802.1G: Remote MAC Bridging", P802.1G/D7, December 30, 1992.
[2] IEEE 802.1、 "ドラフト標準802.1G：リモートMACブリッジング"、P802.1G / D7、1992年12月30日。
[3] IEEE 802.1D-1993, "Media Access Control (MAC) Bridges", ISO/IEC 15802-3:1993 ANSI/IEEE Std 802.1D, 1993 edition., July 1993.
[3] IEEE 802.1D-1993、 "メディアアクセス制御（MAC）ブリッジ"、ISO / IEC 15802-3：1993 ANSI / IEEE規格802.1D、1993年版、1993年7月。
[4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[4]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月を見る：http://www.iana.org/numbers.html
[5] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.
[5]シンプソン、W.、 "PPP LCP拡張機能"、RFC 1570、1994年1月。
[6] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[6]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月を。
[7] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[7] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.およびT. Coradetti、 "PPPマルチリンクプロトコル（MP）"、RFC 1990、1996年8月。
[8] IEEE 802.1D-1998, "Information technology - Telecommunications and Information exchange between systems - Local and metropolitan area networks - Common Specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998.
[8] IEEE 802.1D-1998、「情報技術を - 電気通信とシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - 第3部：メディアアクセス制御（MAC）はブリッジ：リビジョンは、これはISO / IECの改訂版であります10038：1993、802.1j-1992と802.6k-1992はP802.11c、P802.1pとP802.12eが組み込まれて「。 ISO / IEC 15802-3：1998。
[9] IEEE 802.1Q, ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998.
[9] IEEE 802.1Q、ANSI / IEEE規格802.1Q、 "ローカルおよびメトロポリタンエリアネットワークのIEEE標準：仮想ブリッジローカルエリアネットワーク"、1998。
[10] Baker, F. and R. Bowen, "PPP Bridging Control Protocol (BCP)", RFC 1638, June 1994.
[10]ベーカー、F. R.及びボーエン、 "PPPブリッジ制御プロトコル（BCP）"、RFC 1638、1994年6月。
[11] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[11]ボルマン、C.、RFC 2686 "マルチリンクPPPへのマルチクラス拡張"、1999年9月。
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[12]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Questions about this memo can also be directed to:
このメモに関する質問も対象とすることができます。
Mitsuru Higashiyama Anritsu Corporation 1800 Onna, Atsugi-shi, Kanagawa-prf., 243-8555 Japan
みつる ひがしやま あんりつ こｒぽらちおん １８００ おんあ、 あつぎーし、 かながわーｐｒｆ。、 ２４３ー８５５５ じゃぱん
Phone: +81 (46) 296-6625 EMail: Mitsuru.Higashiyama@yy.anritsu.co.jp
電話：+81（46）296-6625 Eメール：Mitsuru.Higashiyama@yy.anritsu.co.jp
Fred Baker 519 Lado Drive Santa Barbara, California 93111
フレッド・ベイカー519ラドドライブサンタバーバラ、カリフォルニア州93111
EMail: fred.baker@cisco.com
メールアドレス：fred.baker@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。