RFC1220 日本語訳
1220 Point-to-Point Protocol extensions for bridging. F. Baker. April 1 1991. (Format: TXT=38165 bytes) (Obsoleted by RFC1638) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group F. Baker, Editor Request for Comments: 1220 ACC April 1991
ワーキンググループのF.ベイカー、コメントを求めるエディタ要求をネットワークでつないでください: 1220 ACC1991年4月
Point-to-Point Protocol Extensions for Bridging
橋を架ける二地点間プロトコル拡大
1. Status of this Memo
1. このMemoの状態
This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. It is a product of the Point-to- Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF).
このドキュメントはインターネットPointからポイントへのRFC1171で説明されたプロトコル(PPP)の拡大を定義します、Pointからポイントへの線のRemote Bridgingの使用を狙って。 それはPointからポイントへのプロトコルExtensionsインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
2. Historical Perspective
2. 歴史観
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. IEEE 802.5 has proposed an alternative approach, called "Source Routing", and is in the process of standardizing that approach for IEEE 802.5 extended networks.
ローカル・エリア・ネットワークのBridgingにおいて、2つの基本的なアルゴリズムが産業で周囲です。 より一般的なアルゴリズムは、「透明な橋を架けること」と呼ばれて、Extended LAN構成のためにIEEE802.1によって標準化されました。 IEEE802.5は「ソースルート設定」と呼ばれる代替的アプローチを提案しました、そして、標準化の途中にIEEEのためのそのアプローチは802.5の拡大ネットワークですか?
Although there is a subcommittee of IEEE 802.1 addressing remote bridging, neither standard directly defines Remote Bridging per se, as that would technically be beyond the IEEE 802 committee's charter. Both allow for it, however, modeling the line as an unspecified interface between half-bridges.
リモート橋を架けることを記述するIEEE802.1の小委員会がありますが、どちらの規格も直接そういうものとしてRemote Bridgingを定義しません、それが802委員会のものがチャーターするIEEEを超えて技術的にいるだろうというとき。 しかしながら、両方が、半分橋の間の不特定のインタフェースとして線をモデル化しながら、それを考慮します。
This document assumes that the devices at either end of a serial link
このドキュメントは、シリーズのどちらかの終わりの装置がリンクされると仮定します。
- have agreed to utilize the RFC 1171 line discipline in some form.
- 何らかのフォームでRFC1171線規律を利用するのに同意しました。
- may have agreed, by some other means, to exchange other protocols on the line interspersed with each other and with any bridged PDUs.
- 互いとどんな橋を架けられたPDUsと共にも点在した線と他のプロトコルを交換するのにある他の手段で同意したかもしれません。
- may be willing to use the link as a vehicle for Remote Bridging.
- Remote Bridgingに乗り物としてリンクを使用することを望むかもしれません。
- may have multiple point-to-point links that are configured in parallel to simulate a single line of higher speed or
- またはより高い速度の単線をシミュレートするために平行で構成される複数のポイントツーポイント接続を持っているかもしれない。
Point-to-Point Protocol Extensions Working Group [Page 1] RFC 1220 Bridging Point-to-Point Protocol April 1991
プロトコル1991年4月にポイントツーポイントに橋を架ける二地点間プロトコル拡大作業部会[1ページ]RFC1220
reliability, but message sequence issues are solved by the transmitting end.
信頼性、しかし、メッセージ系列問題は送信側までに解決されています。
3. General Considerations
3. 一般問題
3.1. Link Quality Monitoring
3.1. 上質のモニターをリンクしてください。
It is strongly recommended that Point-to-Point Bridge Protocol implementations utilize Magic Number Loopback Detection and Link- Quality-Monitoring. This is because the 802.1 Spanning Tree protocol, which is integral to both Transparent Bridging and Source Routing (as standardized), is unidirectional during normal operation, with HELLO PDUs emanating from the Root System in the general direction of the leaves, without any reverse traffic except in response to network events.
PointからポイントへのBridgeプロトコル実現がマジックNumber Loopback DetectionとLink品質モニターを利用することが強く勧められます。 これは通常の操作の間、802.1Spanning Treeプロトコル(Transparent BridgingとSourceルート設定の両方(標準化されるように)に不可欠である)が単方向であるからです、HELLO PDUsがRoot Systemから葉の一般的な方向に発していて、ネットワークイベント以外の少しも逆の交通なしで。
3.2. Message Sequence
3.2. メッセージ系列
The multiple link case requires consideration of message sequentiality. The transmitting station must 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 the several links, enqueuing traffic to links to minimize delay.
複数のリンクケースがメッセージsequentialityの考慮を必要とします。 送信所は、プロトコルが橋を架けられるプロトコルが彼らのオリジナルのトランスミッションの注文に到達して、オーダー保存を強制するために与えられた会話のすべてのトランスミッションを同じリンクに待ち行列に入れるためにトランスミッションを必要とするか、彼らのオリジナルのトランスミッションの注文に到達するようにトランスミッションを必要として、または数個のリンクの利用を最適化するのにその知識を使用しないことを決定しなければなりません、遅れを最小にするためにリンクに交通を待ち行列に入れて。
In the absence of such a determination, the transmitting station must act as though all protocols require order preservation; many protocols designed primarily for use on a single LAN in fact do. A protocol could be described to maintain message sequentiality across multiple links, either by sequence numbering or by fragmentation and re-assembly, but this is neither elegant nor absolutely necessary.
そのような決断がないとき、まるですべてのプロトコルがオーダー保存を必要とするかのように送信所は行動しなければなりません。 事実上、主として単一のLANにおける使用のために設計された多くのプロトコルがします。 複数のリンクの向こう側にメッセージsequentialityを維持するためにプロトコルについて説明できました、どちらか断片化に付番するか、断片化による系列と再アセンブリで、しかし、これは、上品でなくて、また絶対に必要ではありません。
3.3. Maximum Receive Unit Considerations
3.3. 最大はユニット問題を受けます。
Please note that the negotiated MRU must be large enough to support the MAC Types that are negotiated for support, there being no fragmentation and re-assembly. Even Ethernet frames are larger than the default MRU of 1500 octets.
交渉されたMRUがサポートのために交渉されるMAC Typesは支持できるくらい大きくなければならないことに注意してください、断片化と再アセンブリが全くなくて。 イーサネットフレームさえ1500の八重奏のデフォルトMRUより大きいです。
3.4. Separation of Spanning Tree Domains
3.4. スパニングツリードメインの分離
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
ネットワークマネージャが2つの領域を異なったRoots(そして、潜在的に異なったSpanning Tree実現かアルゴリズム)と別々のSpanning Treesに論理的に分割するためにリンクにおけるBPDUsの交換を抑制したがっているのが想像できます。 in order to
Point-to-Point Protocol Extensions Working Group [Page 2] RFC 1220 Bridging Point-to-Point Protocol April 1991
プロトコル1991年4月にポイントツーポイントに橋を架ける二地点間プロトコル拡大作業部会[2ページ]RFC1220
do that, he must configure both ends to not exchange BPDUs on a link. For the sake of robustness, a bridge which is so configured must silently discard the BPDU of its neighbor, should it receive one.
それをしてください、そして、彼は、BPDUsをリンクと交換しないように両端を構成しなければなりません。 丈夫さのために、そのように構成される橋は静かに隣人のBPDUを捨てなければなりません、1を受け取るなら。
4. IEEE 802.1 Transparent Bridging
4. IEEE802.1の透明な橋を架けること
4.1. Overview of IEEE 802.1 Transparent Bridging
4.1. IEEE802.1の透明な橋を架けることの概観
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
未経験への好意と、最初に、Transparent Bridgingを説明しましょう。 本質的には、ネットワークにおける橋はそれぞれに主に気づかない孤立している実体として他のものの存在を手術します。 Transparent Bridgeは成るのにForwarding Databaseを維持します。
{address, interface}
アドレス、インタフェース
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. It goes on to check whether the Destination Address is in the database, and if so, either discards the message (if 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 describes Broadcast/Multicast behavior as well.
それがそれが受け取られたインタフェースのためのインタフェース識別子と共に受けるそれぞれのLAN送信のSource Addressを取っておくのによる記録。 それが、Destination Addressがデータベースにあるかをチェックし続けて、そうだとすれば、どちらかが、メッセージ(目的地とソースが同じインタフェースに位置しているなら)を捨てるか、または示されたインタフェースにメッセージを転送します。 それが受け取られたもの以外のすべてのインタフェースにDestination Addressがテーブルで見つけられないメッセージを転送します。 これはまた、Broadcast/マルチキャストの振舞いについて説明します。
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 IEEE 802.1(d) Spanning Tree Protocol is executed between the bridges to detect and logically remove redundant paths from the network.
明白な玉に傷は不確定(拒否であって、確定的過ぎる)の推進の振舞いがネットワークにおける冗長パスで起こるということです。 これを防ぐなら、TreeプロトコルにかかるIEEE 802.1(d)と呼ばれるプロトコルは、ネットワークから冗長パスを検出して、論理的、取り除くために橋の間で実行されます。
One system is elected as the "Root", which periodically emits a message called a Bridge Hello Protocol Data Unit, or BPDU, heard by all of its neighboring bridges. Each of these modifies and passes the BPDU on to its neighbors, and they to theirs, 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 (i.e., 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.
「根」(定期的にBridge HelloプロトコルData Unit、またはBPDUと呼ばれるメッセージを放つ)が隣接している橋のすべてで聞いたように1台のシステムが選出されます。 ネットワーク(それを回す一層の隣人が全くいないで、それはそこで死ぬ)で葉のLANセグメントに到着するか、またはメッセージが「根」に優れた経路を持っている橋によって止められるまで、それぞれのこれらは、BPDUを隣人に変更して、渡して、彼らを彼等のものに渡します。 この後者の場合では、トポロジー変化がネットワークの再計算を強制するまで、BPDUが受け取られたインタフェースは無視されます(すなわち、それがHot Standby状態に置かれます、そして、BPDU以外に、交通は全くそれに放たれていません、そして、それから受けられたすべての交通が捨てられます)。
4.2. IEEE 802.1 Remote Bridging Activity
4.2. IEEE802.1のリモート橋を架ける活動
There exist two basic sorts of bridges - ones that interconnect LANs directly, called Local Bridges, and ones that interconnect LANs via an intermediate medium such as a leased line, called Remote Bridges.
基本的な2種類の橋は存在しています--直接LANとインタコネクトするもの(呼ばれたLocalブリッジス、および専用線などの中間的媒体でLANとインタコネクトするもの)は、Remoteをブリッジスと呼びました。
Point-to-Point Protocol Extensions Working Group [Page 3] RFC 1220 Bridging Point-to-Point Protocol April 1991
プロトコル1991年4月にポイントツーポイントに橋を架ける二地点間プロトコル拡大作業部会[3ページ]RFC1220
The Point-to-Point Protocol might be used by a Remote Bridge.
PointからポイントへのプロトコルはRemote Bridgeによって使用されるかもしれません。
There is more than one proposal within the IEEE 802.1 Interworking Committee for modeling the Remote Bridge. In one model, the interconnecting serial link(s) are treated in the same way that a LAN is, having a standard IEEE 802.1 Link State; in another, the serial links operate in a mode quite different from the LANs that they interconnect. For the sake of simplicity of specification, the first model is adopted, although some of the good ideas from proponents of the second model are included or allowed for.
Remote Bridgeをモデル化するためのIEEE802.1Interworking Committeeの中に1つ以上の提案があります。 1つのモデルでは、内部連絡の連続のリンクはLANがそうです、標準のIEEE802.1Link州を持っていて、そうするのと同じように扱われます。 別のものでは、連続のリンクはそれらがインタコネクトするLANと全く異なったモードで作動します。 仕様の簡単さのために、第1代モデルは採用されます、第2代モデルの提案者からの名案のいくつかが、含まれているか、または考慮されますが。
Therefore, given that transparent bridging is configured on a line or set of lines, the specifics of the link state with respect to the bridge is defined by IEEE 802.1(d). The Bridge Protocol Data Unit, or BPDU, is defined there, as well as the algorithms for its use.
したがって、透明な橋を架けることが線の線かセットで構成されるなら、橋に関するリンク状態の詳細はIEEE 802.1(d)によって定義されます。 BridgeプロトコルData Unit、またはBPDUが使用のためのアルゴリズムと同様にそこで定義されます。
It is assumed that, if a Point-to-Point Link neighbor receives IEEE 802.1 BPDUs without rejecting them with the RFC 1171 Protocol-Reject LCP PDU, Transparent Bridging is permitted on the link.
802.1PointからLinkがIEEEを受けるのを近所付き合いさせるポイントへのRFC1171と共に彼らを拒絶することのないBPDUsがLCP PDUをプロトコルで拒絶するならTransparent Bridgingがリンクの上に受入れられると思われます。
4.3. IEEE 802.5 Source Routing
4.3. IEEE802.5ソースルート設定
The IEEE 802.5 Committee has defined a different approach to bridging for use on the Token Ring, called Source Routing. In this approach, the originating system has the responsibility of indicating what path that the message should follow. It does this, if the message is directed off the local ring, by including a variable length MAC header extension called the Routing Information Field, or RIF. The RIF consists of one 16 bit word of flags and parameters followed by zero or more ring-and-bridge identifiers. Each bridge en route determines from this "source route list" whether it should receive the message and how to forward it.
IEEE802.5CommitteeはSourceルート設定と呼ばれるToken Ringにおける使用のための橋を架けることへの異なるアプローチを定義しました。 このアプローチでは、由来しているシステムはメッセージが続くべきであるすべての経路を示す責任を持っています。 それはこれをします、メッセージが局所環で指示されるなら、経路情報Field、またはRIFと呼ばれる可変長MACヘッダー拡張子を含んでいることによって。 RIFがゼロがあとに続いた旗とパラメタの1つ16の噛み付いている単語から成るか、以上は、識別子を鳴らして、橋を架けます。 途中各橋は、この「送信元経路リスト」からメッセージを受け取るべきであるかどうかと、どのようにそれを進めるかを決定します。
The algorithm for Source Routing requires the bridge to be able to identify any interface by its ring-and-bridge identifier, and to be able to identify any of its OTHER interfaces likewise. When a packet is received which has the Routing Information Field (RIF) present, a boolean in the RIF is inspected to determine whether the ring-and- bridge identifiers are to be inspected in "forward" or "reverse" sense. In a "forward" search, the bridge looks for the ring-and- bridge identifier of the interface the packet was received on, and forwards the packet toward the ring identified in the ring-and-bridge identifier that follows it. In a "reverse" search, the bridge looks for the ring-and-bridge identifier of the OTHER INTERFACE, and delivers the packet to the indicated interface if such is found.
Sourceルート設定が、橋がリングと橋の識別子でどんなインタフェースも特定して、OTHERのどれかを特定できるのを必要とするので、アルゴリズムは同様に連結します。 そして、パケットが受け取られているとき、決定するために経路情報Field(RIF)プレゼント、RIFの論理演算子をどれに点検してあるか、リング、-、-橋の識別子は「前進」の、または、「逆」の意味で点検されることです。 そして、「前進」の検索では、橋がリングを探す、-、-それに続くリングと橋の識別子で特定されたリングに向かってパケットが受け取られて、パケットを送るインタフェースに関する識別子に橋を架けてください。 「逆」の検索では、橋は、OTHER INTERFACEに関するリングと橋の識別子を探して、そのようなものが見つけられるなら、示されたインタフェースにパケットを届けます。
The algorithms for handling multicasts ("Functional Addresses" and "Group Addresses") have been the subject of much discussion in 802.5,
取り扱いマルチキャスト(「機能アドレス」と「グループアドレス」)のためのアルゴリズムは802.5で、多くの議論の対象です。
Point-to-Point Protocol Extensions Working Group [Page 4] RFC 1220 Bridging Point-to-Point Protocol April 1991
プロトコル1991年4月にポイントツーポイントに橋を架ける二地点間プロトコル拡大作業部会[4ページ]RFC1220
and are likely to be the most troublesome for bridge implementations. Fortunately, they are beyond the scope of this document.
橋の実現に最も厄介であることがありそうです。 幸い、彼らはこのドキュメントの範囲を超えています。
4.4. IEEE 802.5 Remote Bridging Activity
4.4. IEEE802.5のリモート橋を架ける活動
There is no Remote Bridge proposal in IEEE 802.5 at this time, although IBM ships a remote Source Routing Bridge. Simplicity would dictate that we choose the same model for IEEE 802.5 Source Routing that was selected for IEEE 802.1, but necessity requires a ring number for the line in some cases. We allow for both models.
IBMはリモートSourceルート設定Bridgeを出荷しますが、Remote Bridge提案が全くこのとき、IEEE802.5にありません。 簡単さは、私たちがIEEE802.1のために選択されたIEEE802.5Sourceルート設定のための同じモデルを選ぶと決めるでしょうが、いくつかの場合、必要性は線のリング番号を必要とします。 私たちは両方のモデルを考慮します。
Given that source routing is configured on a line or set of lines, the specifics of the link state with respect to the bridge is defined by the IEEE 802.5 Addendum on Source Routing. The requisite PDUs for calculating the spanning tree (used for assuring that each ring will receive at most one copy of a multicast) are defined there, as well as the algorithms for their use. MAC PDUs (Beacon, Ring Management, etc) are specific to the MAU technology and are not exchanged on the line.
ソースルーティングが線の線かセットで構成されるなら、橋に関するリンク状態の詳細はSourceルート設定のときにIEEE802.5Addendumによって定義されます。 スパニングツリー(各リングがマルチキャストのコピー1部を高々受けることを保証するために、使用される)を計算するための必要なPDUsはそこで定義されます、彼らの使用のためのアルゴリズムと同様に。 MAC PDUs(標識、Ring Managementなど)はMAU技術に特定であり、線で交換されません。
4.5. Source Routing to Transparent Bridge Translation
4.5. わかりやすい橋の翻訳へのソースルート設定
IEEE 802 also has a subcommittee looking at the interoperation of Transparent Bridging and Source Routing. For the purposes of this standard, such a device is both a transparent and a source routing bridge, and will act on the line in both ways, just as it does on the LAN.
また、IEEE802は小委員会にTransparent BridgingとSourceルート設定のinteroperationを見させます。 この規格の目的のために、そのような装置がaともに透明であり、ソースルーティングは、両方の方法で線に橋を架けて、影響するでしょう、ちょうどLANでそうするように。
5. Traffic Services
5. 交通サービス
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 Frame Checksum Preservation、LAN Frame Checksum Generation、Tinygram Compression、および識別を含んでいます。
5.1. LAN Frame Checksum Preservation
5.1. 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.
IEEE802.1は、Extended LANが個々のLANが楽しむ非検出された誤りの同じ確率を楽しまなければならないのを規定します。 アルゴリズムに関してかなりの討論がありましたが、Frame Checksumが究極の受信機で受けたLANがオリジナルの送信機によって計算された同じ値であることを持っているほど他のアルゴリズムは全く提案されていません。 これを達成するのは、もちろん線プロトコルが端から端へLAN Frame Checksumを保存するのを必要とします。 プロトコルはこのアプローチに向かって最適化されます。
Point-to-Point Protocol Extensions Working Group [Page 5] RFC 1220 Bridging Point-to-Point Protocol April 1991
プロトコル1991年4月にポイントツーポイントに橋を架ける二地点間プロトコル拡大作業部会[5ページ]RFC1220
5.2. Traffic having no LAN Frame Checksum
5.2. LAN Frame Checksumが全くない交通
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 Frame Checksum保存に向かって最適化されるという事実は双子の疑問を引き起こします: 「アプローチは推論することなら何でものために容易にFrame Checksum保存を支持できないシステムによって使用されるべき、何ですか?」と「アプローチはシステムがメッセージを溯源するとき、使用されるべき、何です、したがって、どれに、Frame Checksum precalculatedが全くありませんか?」?
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つのアプローチはハードウェアサポートが入手できないならステーションがソフトウェアでFrame Checksumについて計算するのが必要であることです。 これは、深遠な驚愕にあって、Bridge/ルータにおける解釈の重大問題を提起するでしょう。
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 Frame Checksum保存を実行するステーションは既にこの問題を解決しなければなりません。 したがって、採用された解決策はFrame Checksumを全く持っていないメッセージが線の向こう側にタグ付けをされて、伝えられるということです。
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 Frame Checksum保存を実行しないシステムが埋め込まれたFCSを持っているフレームを受けるとき、それは、それ自身の使用のために引きずっている4つの八重奏を取り除くことによって、それを変換します。 どんなシステムも埋め込まれたFCSを全くLANに含まないフレームを進めるとき、それはFCSについて計算する方法でそれを進めます。
5.3. Tinygram Compression
5.3. Tinygram圧縮
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.
リモートイーサネットの橋を架けることにおける問題は橋を架けるために最も魅力的なプロトコルが低速(64KBPS)線で問題の傾向があるということです。 これらのプロトコルを定義する業者がZEROの八重奏でPDUをしばしば満たすのを観測することによって、これを部分的に軽減できます。 したがって、イーサネットかIEEE802.3PDUが最小のPDUサイズより小さい(1)である線から受信しました、そして、LANでそれを伝える前に、(2)は最後の4つの八重奏とPDUの残りの間にFrame Checksumがゼロを挿入しながら提示して、そっと歩くに違いないLANを持っています。 これらのプロトコルは、対話的なセッションに頻繁に使用されて、したがって、頻繁に小さくこれです。
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.
あいまいさを防ぐために、そっと歩くのを必要とするPDUsは明らかにタグ付けをされます。 圧縮は、送信所の選択にはあって、たぶん低速系列だけに実行されます、恐らく構成管理で。
The pseudo-code in Figure 1 describes the algorithms.
図1の中間コードはアルゴリズムを説明します。
Point-to-Point Protocol Extensions Working Group [Page 6] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[6ページ]RFC1220
5.4. LAN Identification
5.4. LAN識別
In some applications, it is useful to tag traffic by the user community it is a part of, and guarantee that it will be only emitted onto a LAN which is of the same community. The user community is defined by a LAN ID. Systems which choose to not implement this feature must assume that any frame received having a LAN ID is from a different community than theirs, and discard it.
使用目的によっては、ユーザーコミュニティのそばでトラフィックにタグ付けをするのは役に立ちます。同じ共同体のものであるLANに、aは離れて、それが放たれるだけであるのを保証します。 ユーザーコミュニティはLAN IDによって定義されます。 この特徴を実装しないのを選ぶシステムは、LAN IDを持ちながら受け取られたどんなフレームも彼等のものと異なった共同体からのそうであると仮定して、それを捨てなければなりません。
Point-to-Point Protocol Extensions Working Group [Page 7] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[7ページ]RFC1220
Figure 1: Tinygram Compression Pseudo-Code
図1: 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 */ TrailingOctet (PDU) == 0) /* or 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 */ } }
(ZeroPadCompressionEnabled、BridgedProtocolHeaderFormat=IEEE8023、PacketLength=Minimum8023PacketLength){ /**は広がり*ではなく、包含ではなく、八重奏がない先行、*どんな連続した走行、LAN FCSもMACヘッダーに取り外します。 */はセットしました(ZeroCompressionFlag)。 /*信号の受信機*/、(_Set(LAN_FCS_Present)です)、FCSはTrailingOctets(PDU、4)と等しいです。 /*ストアFCS*/RemoveTrailingOctets(PDU、4)。 /*が/がゆったり過ごすFCS*を取り外す、(PacketLength>14、/*が八重奏がない*/Appendbuf(PDU、4、FCS)を取り外すという/MACヘッダー*/TrailingOctet(PDU)=0)/*での*停止か最後の非ゼロ八重奏*/RemoveTrailingOctets(PDU、1) /*がFCS*/を回復する、ほか、(PacketLength>14、/*はMACヘッダー*/TrailingOctet(PDU)=0)/*において最後に八重奏がない*/RemoveTrailingOctets(PDU、1)を止めます; /*は八重奏*/を全く取り除きません。}
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 */ } }
(ZeroCompressionFlag)です。{ ヘッダーに設定された/*旗? *最小の802.3の長さ*の/にパケットを回復する//*が(ZeroCompressionFlag)をクリアします。 (_セット(LAN_FCS_プレゼント)です)、FCSはTrailingOctets(PDU、4)と等しいです。 /*ストアFCS*/RemoveTrailingOctets(PDU、4)。 /*はFCS*/Appendbuf(PDU、60--PacketLength、ゼロ); /*を取り除きます。ゼロ*/Appendbuf(PDU、4、FCS)を加えてください。 /*がFCS*/を回復する、ほか、Appendbuf(PDU、60--PacketLength、ゼロ);、/*はゼロ*/を加えます。}
Point-to-Point Protocol Extensions Working Group [Page 8] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[8ページ]RFC1220
6. Protocol Data Unit Formats
6. プロトコルデータ単位形式
6.1. Common LAN Traffic
6.1. 一般的なLANトラフィック
Figure 2: 802.3 Frame format
図2: 802.3 フレーム形式
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x31 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|I|Z|0| Count | MAC Type | LAN ID high word (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN ID low word (optional) | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address | Length/Type + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN FCS (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | potential line protocol pad + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | 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旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF| 0×03| 0×00| 0×31 + +++++++++++++++++++++++++++++++++|F|I|Z|0| カウント| MACはタイプします。| 高LAN ID単語(任意の)++++++++++++++++++++++++++++++++++| LANのIDの少ない単語(任意の)| 目的地マックーアドレス++++++++++++++++++++++++++++++++++| 目的地マックーアドレス++++++++++++++++++++++++++++++++++| ソースマックーアドレス++++++++++++++++++++++++++++++++++| ソースマックーアドレス| 長さ/タイプ++++++++++++++++++++++++++++++++++| LLCデータ++++++++++++++++++++++++++++++++++| ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN FCS(任意)の++++++++++++++++++++++++++++++++++| 潜在的系列プロトコルパッド++++++++++++++++++++++++++++++++++| HDLC CRC| HDLC旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For Bridging LAN traffic, the format of the frame on the line is as shown in Figures 2 or 3. This conforms to RFC 1171 section 3.1 "Frame Format". It also allows for RFC 1172 [2] negotiation of Protocol Field Compression and Address and Control Field Compression. It is recommended that devices which use controllers that require even memory addresses negotiate to NOT USE Protocol Field Compression on other than low speed links.
Bridging LANトラフィックのために、系列のフレームの形式は図2か3に示されるようにものです。 これは「フレーム形式」というRFC1171部3.1に従います。 また、それはプロトコルField Compression、Address、およびControl Field CompressionのRFC1172[2]交渉を考慮します。 メモリアドレスさえ必要とするコントローラを使用するデバイスが低速リンクを除いて、オンなNOT USEプロトコルField Compressionと交渉されるのは、お勧めです。
Point-to-Point Protocol Extensions Working Group [Page 9] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[9ページ]RFC1220
Figure 3: 802.4/802.5/FDDI Frame format
図3: 802.4/802.5/FDDI Frame形式
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x31 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|I|Z|0| Count | MAC Type | LAN ID high word (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAN ID low word (optional) | Pad Byte | Frame Control + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LLC data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional Data Link Layer padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | 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旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF| 0×03| 0×00| 0×31 + +++++++++++++++++++++++++++++++++|F|I|Z|0| カウント| MACはタイプします。| 高LAN ID単語(任意の)++++++++++++++++++++++++++++++++++| LANのIDの少ない単語(任意の)| パッドバイト| フレームコントロール++++++++++++++++++++++++++++++++++| 目的地マックーアドレス++++++++++++++++++++++++++++++++++| 目的地マックーアドレス| ソースマックーアドレス++++++++++++++++++++++++++++++++++| ソースマックーアドレス++++++++++++++++++++++++++++++++++| LLCデータ++++++++++++++++++++++++++++++++++| ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS(任意)の++++++++++++++++++++++++++++++++++| + +++++++++++++++++++++++++++++++++を水増しする任意のData Link Layer| HDLC CRC| HDLC旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of this message are as follows:
このメッセージの分野は以下の通りです:
Address Field and Control Field: As defined by RFC 1171
アドレス・フィールドとコントロールは以下をさばきます。 RFC1171によって定義されます。
Protocol Field: 0x0031
分野について議定書の中で述べてください: 0×0031
Flags: bits 0-3: length of the line protocol pad field. bit 4: Reserved, Set to Zero bit 5: Set if IEEE 802.3 Pad must be zero filled to minimum size bit 6: Set if the LAN ID Field is present bit 7: Set if the LAN FCS Field is present
旗: ビット0-3: 系列の長さはパッド分野ビット4について議定書の中で述べます: 予約されていて、ZeroへのSetは5に噛み付きました: ゼロが最小規模ビット6までいっぱいにされたならIEEE802.3Padがセットしなければならないなら、セットしてください: LAN ID Fieldが現在のビット7であるなら、セットしてください: LAN FCS Fieldが存在しているなら、セットします。
The "number of trailing "pad" octets is a deference to the fact that any point-to-point frame may have padding at the end. This
「引きずっている「パッド」八重奏の数はどんな二地点間フレームにも詰め物が終わりにあるかもしれないという事実へのa服従です。」 これ
Point-to-Point Protocol Extensions Working Group [Page 10] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[10ページ]RFC1220
number tells the receiving system how many octets to strip off the end.
数は、終わりでいくつの八重奏を剥取るかを受電方式に言います。
MAC Type: 0: Reserved 1: IEEE 802.3/Ethernet 2: IEEE 802.4 3: IEEE 802.5 4: FDDI other: Assigned by the Internet Assigned Numbers Authority
MACはタイプします: 0: 予約された1: IEEE802.3/イーサネット2: IEEE802.4 3: IEEE802.5 4: FDDI他: インターネット規定番号権威で、割り当てられます。
LAN ID: This optional 32 bit field identifies the Community of LANs which may be interested to receive this frame, as described in section 5.4. If the LAN ID flag is not set, then this field is not present, and the PDU is four octets shorter.
ランID: この32ビットの任意の分野はこのフレームを受け取りたがっているかもしれないLANのCommunityを特定します、セクション5.4で説明されるように。 LAN ID旗が設定されないなら、この分野は存在していません、そして、PDUは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. Since the MAC Type field defines the bit ordering, these are sent in MAC order. A pad octet is present to avoid odd machine address boundary problems.
コントロールを縁どってください: 802.4、802.5、およびFDDI LANに、それの1つがFCSによって保護されるDestinationマックーアドレスに先行するいくつかの八重奏があります。 MAC Type分野が噛み付いている注文を定義するので、MACオーダーでこれらを送ります。 パッド八重奏は、変な機械語アドレス境界問題を避けるために存在しています。
Destination MAC Address: As defined by the IEEE. Since the MAC Type field defines the bit ordering, this is sent in MAC order.
目的地マックーアドレス: IEEEによって定義されるように。 MAC Type分野が噛み付いている注文を定義するので、MACオーダーでこれを送ります。
Source MAC Address: As defined by the IEEE. Since the MAC Type field defines the bit ordering, this is sent in MAC order.
ソースマックーアドレス: IEEEによって定義されるように。 MAC Type分野が噛み付いている注文を定義するので、MACオーダーでこれを送ります。
LLC data: This is the remainder of the MAC frame. This is that portion of the frame which is (or would be were it present) protected by the LAN FCS; for example, the 802.5 Access Control field, and Status Trailer are not meaningful to transmit to another ring, and are omitted.
LLCデータ: これはMACフレームの残りです。 これはLAN FCSによって保護される(またはそれが存在しているならである)フレームのその一部です。 例えば、Access Controlがさばいて、Status Trailerが重要でない802.5は、別のリングに伝わって、省略されます。
LAN Frame Checksum: If present, this is the LAN FCS which was calculated by (or which appears to have been calculated by) the originating station. If the FCS Present flag is not set, then this field is not present, and the PDU is four octets shorter.
LANフレームチェックサム: 存在しているなら、これは(どれを計算してあるように見えます)起因するステーションによって計算されたLAN FCSです。 FCS Present旗が設定されないなら、この分野は存在していません、そして、PDUは4つの八重奏より短いです。
Optional Data Link Layer Padding RFC 1171 specifies that an arbitrary pad can be added after the data intended for transmission. The "Count" portion of the flag
任意のData Link Layer Padding RFC1171は、トランスミッションのために意図するデータの後に任意のパッドを加えることができると指定します。 旗の「カウント」一部
Point-to-Point Protocol Extensions Working Group [Page 11] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[11ページ]RFC1220
field contains the length of this pad, which may not exceed 15 octets.
分野はこのパッドの長さを含んでいます。(パッドは15の八重奏を超えないかもしれません)。
CRC-CCITT Mentioned primarily for clarity. The CRC used on the PPP link is separate from and unrelated to the LAN FCS.
主として明快のためのCRC-CCITT Mentioned。 PPPリンクの上に使用されるCRCはLAN FCSに別々であって、関係ありません。
6.2. IEEE 802.1 Bridge
6.2. IEEE802.1ブリッジ
This is the BPDU as defined by IEEE 802.1(d), without any MAC or 802.2 LLC header (these being functionally equivalent to the Address, Control, and Protocol Fields). The LAN Pad and Frame Checksum fields are likewise superfluous and absent. The Address and Control Fields are optional, subject to the Address and Control Field Compression negotiation.
IEEE 802.1(d)によって定義されるようにこれはBPDUです、どんなMACも802.2LLCヘッダー(Address、Control、およびProtocolフィールズにとって、機能上同等なこれらの存在)なしで。 LAN PadとFrame Checksum分野は、同様に余計であって、欠けています。 AddressとControlフィールズはAddressとControl Field Compression交渉を条件として任意です。
Figure 4: Bridge "Hello" PDU
図4: 「こんにちは」という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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x02 | 0x01 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPDU data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC | 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旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF| 0×03| 0×02| 0×01 + +++++++++++++++++++++++++++++++++| BPDUデータ++++++++++++++++++++++++++++++++++| ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HDLC CRC| HDLC旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of this message are as follows:
このメッセージの分野は以下の通りです:
Address Field and Control Field: As defined by RFC 1171
アドレス・フィールドとコントロールは以下をさばきます。 RFC1171によって定義されます。
Protocol Field: 0x0201
分野について議定書の中で述べてください: 0×0201
MAC Frame: 802.1(d) BPDU
MACは以下を縁どっています。 802.1(d) BPDU
Point-to-Point Protocol Extensions Working Group [Page 12] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[12ページ]RFC1220
6.3. IEEE 802 Network Control Protocol
6.3. IEEE802ネットワーク制御プロトコル
The Bridge Network Control Protocol is responsible for configuring, enabling, and disabling the bridges on both ends of the point-to- point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. BNCP packets may not be exchanged until LCP has reached the network-layer Protocol Configuration Negotiation phase. Likewise, LAN traffic may not be exchanged until BNCP has first opened the connection.
Bridge Network Controlプロトコルはポイントからポイントへのリンクの両端でブリッジを構成して、可能にして、無効にするのに原因となります。 Link Controlプロトコルのように、これはパケットの交換を通して達成されます。 LCPがネットワーク層プロトコルConfiguration Negotiationフェーズに達するまで、BNCPパケットは交換されないかもしれません。 同様に、BNCPが最初に接続を開くまで、LANトラフィックは交換されないかもしれません。
The Bridge Network Control Protocol is exactly the same as the Point- to-Point Link Control Protocol with the following exceptions:
Bridge Network Controlプロトコルはまさに以下の例外でポイントへのPoint Link Controlプロトコルと同じです:
Data Link Layer Protocol Field Exactly one Bridge Network Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8031 (BNCP).
プロトコルField Exactly1Bridge Network Controlプロトコルパケットがプロトコル分野がタイプを示すPPP Data Link Layerフレームの情報分野でカプセルに入れられるデータLink Layerは8031(BNCP)人に魔法をかけます。
Code field Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects.
分野Only Codes1をコード化する、7 (要求を構成する、Configure-Ack、Configure-Nak、Configure-廃棄物、Terminate-要求、Terminate-Ack、およびCode-廃棄物) 使用されます。 他のCodesは認識されていないとして扱われるべきであり、Code-廃棄物をもたらすはずです。
Timeouts BNCP packets may not be exchanged until the Link Control Protocol has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing to finish before timing out waiting for Configure-Ack or other response.
Link Controlプロトコルがネットワーク層プロトコルConfiguration Negotiationフェーズに達するまで、タイムアウトBNCPパケットは交換されないかもしれません。 実装は以前タイミングが外でConfigure-Ackか他の応答を待ち終えるのをLink Qualityテストを待つように準備されるべきです。
Configuration Option Types The Bridge Network Control Protocol has a separate set of Configuration Options. These permit the negotiation of the following items:
構成Option Types Bridge Network Controlプロトコルには、Configuration Optionsの別々のセットがあります。 これらは以下の項目の交渉を可能にします:
- MAC Types supported - Tinygram Compression support - LAN Identification support - Ring and Bridge Identification
- サポートされたMAC Types--Tinygram Compressionサポート--LAN Identificationサポート--リングとBridge Identification
6.4. IEEE 802.5 Remote Ring Identification Option
6.4. IEEE802.5のリモートリング識別オプション
Since the Remote Bridges are modeled as normal Bridges with a strange internal interface, each bridge needs to know the ring/bridge numbers of the bridges it is adjacent to. This is the subject of a Link Negotiation. The exchange of ring-and-bridge identifiers is done using this option on the Network Control Protocol.
Remoteブリッジスが普通のブリッジスとして奇妙な内部のインタフェースでモデル化されるので、各ブリッジは、それに隣接しているブリッジのリング/ブリッジ番号を知る必要があります。 これはLink Negotiationの対象です。 リングとブリッジ識別子の交換はNetwork Controlプロトコルでこのオプションを使用し終わっています。
Point-to-Point Protocol Extensions Working Group [Page 13] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[13ページ]RFC1220
The Token Ring Ring-and-Bridge Identifier, and its use, is specified by the IEEE 802.5 Addendum on Source Routing. It identifies the ring that the interface is attached to by its configured ring number, and itself by bridge number on the ring.
Tokenリング・リングとブリッジIdentifier、およびその使用はSourceルート設定のときにIEEE802.5Addendumによって指定されます。 それは、構成されたリング番号に従ってインタフェースが取り付けられるリングを特定して、リングのブリッジ番号に従って、それ自体を特定します。
Figure 5: Remote Ring Identification Option
図5: リモートリング識別オプション
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=1 |length = 4 | ring number |bridge#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =1をタイプしてください。|長さ=4| リング番号|ブリッジ#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 = IEEE 802.5 Source Routing Ring/Bridge Identifier
1=IEEE802.5ソースルート設定リング/ブリッジ識別子をタイプしてください。
Length 4 Octets
長さ4の八重奏
Ring Number A 12 bit number identifying the token ring, as defined in the IEEE 802.5 Source Routing Specification.
IEEE802.5Sourceルート設定Specificationで定義されるようにトークンリングを特定するNumber A12噛み付いている番号を鳴らしてください。
Bridge Number A 4 bit number identifying the bridge on the token ring, as defined in the IEEE 802.5 Source Routing Specification.
トークンリングの上でブリッジを特定するNumber A4噛み付いている番号をブリッジしてください、IEEE802.5Sourceルート設定Specificationで定義されるように。
6.5. IEEE 802.5 Line Identification Option
6.5. IEEE802.5回線識別オプション
This option permits the systems to treat the line as a visible "Token Ring", in accordance with the Source Routing algorithm. The bridges exchange ring-and-bridge identifiers using this option on the Network Control Protocol. The configured ring numbers must be identical in normal operation.
このオプションは、システムが目に見える「トークンリング」として系列を扱うことを許可します、Sourceルート設定アルゴリズムによると。 ブリッジは、Network Controlプロトコルでこのオプションを使用することでリングとブリッジ識別子を交換します。 構成されたリング番号は通常の操作が同じであるに違いありません。
The Token Ring Ring-and-Bridge Identifier, and its use, is specified by the IEEE 802.5 Addendum on Source Routing. It identifies the ring that the interface is attached to by its configured ring number, and itself by bridge number on the ring.
Tokenリング・リングとブリッジIdentifier、およびその使用はSourceルート設定のときにIEEE802.5Addendumによって指定されます。 それは、構成されたリング番号に従ってインタフェースが取り付けられるリングを特定して、リングのブリッジ番号に従って、それ自体を特定します。
Figure 6: Line Identification Option
図6: 回線識別オプション
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=2 |length = 4 | ring number |bridge#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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をタイプしてください。|長さ=4| リング番号|ブリッジ#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Point-to-Point Protocol Extensions Working Group [Page 14] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[14ページ]RFC1220
Type 2 = IEEE 802.5 Line "Ring/Bridge" Identifier
2=IEEE802.5線「リング/ブリッジ」識別子をタイプしてください。
Length 4 Octets
長さ4の八重奏
Ring Number A 12 bit number identifying the line, as defined in the IEEE 802.5 Source Routing Specification.
IEEE802.5Sourceルート設定Specificationで定義されるように系列を特定するNumber A12噛み付いている番号を鳴らしてください。
Bridge Number A 4 bit number identifying the bridge on the token ring, as defined in the IEEE 802.5 Source Routing Specification.
トークンリングの上でブリッジを特定するNumber A4噛み付いている番号をブリッジしてください、IEEE802.5Sourceルート設定Specificationで定義されるように。
6.6. MAC Type Support Selection
6.6. MACはサポート選択をタイプします。
The MAC Type Selection Option is provided to permit nodes to advertise what sort of traffic they are prepared to convey. A device negotiating a 1600 octet MRU, for example, may not be willing to support 802.5 (although it might, with certain changes necessary in the RIFs it passes, and given that the hosts it supports implement the 802.5 Maximum Frame Size correctly), and is definitely not prepared to support 802.4 or FDDI.
ノードがそれらが運ぶように準備されるどんな種類のトラフィックの広告を出すかを許可するためにMAC Type Selection Optionを提供します。 例えば1600年の八重奏MRUを交渉するデバイスは、802.5(それが渡すRIFsで必要なある変化でそうするかもしれなくて、それがサポートするホストが正しく802.5Maximum Frame Sizeを実装するなら)をサポートすることを望まないかもしれなくて、また確実に802.4かFDDIをサポートするように準備されません。
A system which does not announce the MAC Types that it supports may be assumed to support all MAC Types; it will discard those that it does not understand. A system which chooses to announce MAC Types is advising its neighbor that all unspecified MAC Types will be discarded. Announcement of multiple MAC Types is accomplished by placing multiple options in the Configure Request.
それがサポートするMAC Typesを発表しないシステムがすべてのMAC Typesをサポートすると思われるかもしれません。 それは理解していないものを捨てるでしょう。 MAC Typesを発表するのを選ぶシステムは、すべての不特定のMAC Typesが捨てられると隣人に忠告しています。 複数のMAC Typesの発表は、Configure Requestの複数のオプションを置くことによって、実行されます。
The Rejection of a MAC Type Announcement (in a Configure-Reject) is essentially a statement that traffic appropriate to the MAC Type, if encountered, will be forwarded on the link even though the receiving system has indicated it will discard it.
MAC Type Announcement(Configure-廃棄物の)のRejectionは本質的には受電方式が、それを捨てるのを示しましたが、遭遇するとリンクの上にMAC Typeに適切なトラフィックを進めるという声明です。
Figure 7: MAC Type Selection Option
図7: 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=3 |length = 3 | MAC Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =3をタイプしてください。|長さ=3| MACはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 3 = MAC Type Selector
3=MACタイプセレクタをタイプしてください。
Length 3 Octets
長さ3の八重奏
Point-to-Point Protocol Extensions Working Group [Page 15] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[15ページ]RFC1220
MAC Type Selector One of the values of the PDU's MAC Type Field that this system is prepared to receive and service.
このシステムが受けるように準備されるPDUのMAC Type Fieldの、そして、サービスの値のMAC Type Selector One。
6.7. Tinygram Compression
6.7. 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 permits the system to negotiate compression.
すべてのシステムがトランジットにおけるメッセージへの変更をするように準備されるというわけではありません。 高速系列では、それはたぶん取り組みの価値がありません。 このオプションは、システムが圧縮を交渉することを許可します。
Consistent with the behavior of other compression options in the Internet Point-to-Point set of protocols, no negotiation implies no compression. The systems need not agree on the setting of this parameter; one may be willing to decompress and the other not. A system which does not negotiate, or negotiates this option to be disabled, should never receive a compressed packet, however.
Pointからポイントへのプロトコルのインターネットセットにおける、他の圧縮オプションの振舞いと一致していて、交渉がないのは圧縮を全く含意しません。 システムはこのパラメタの設定に同意する必要はありません。 1つ、減圧する望みともう片方がそうでありませんように。 しかしながら、交渉しないか、または無効にされるこのオプションを交渉するシステムは圧縮されたパケットを決して受けるはずがありません。
Figure 8: Tinygram Compression Option
エイト環: 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=4 |length = 3 | Compression | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =4をタイプしてください。|長さ=3| 圧縮| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4 = Tinygram Compression Support Option
4=Tinygram圧縮サポートオプションをタイプしてください。
Length 3 Octets
長さ3の八重奏
Compression Enable/Disable If the value is 1, Tinygram Compression is enabled. If the value is 2, Tinygram Compression is disabled, and no decompression will occur.
圧縮Enable/はIfを無効にします。値は1、Tinygram Compressionが有効にされるということです。 値が2であるなら、Tinygram Compressionは障害があります、そして、減圧は全く起こらないでしょう。
6.8. LAN Identification Support
6.8. LAN識別サポート
Not all systems are prepared to make use of the LAN Identification field. This option enables the systems to negotiate its use.
すべてのシステムがLAN Identification分野を利用するように準備されるというわけではありません。 このオプションは、システムが使用を交渉するのを可能にします。
The parameter is advisory; if the value is "enabled", then there may exist labeled LANs beyond the system, and the system is prepared to service traffic to it. if the value is "disabled", then there are no labeled LANs beyond the system, and all such traffic will by definition be dropped. Therefore, a system which is advised that his peer does not service LAN Identifications need not forward such traffic on the link.
パラメタは顧問です。 値が「可能にされる」なら、システムを超えたラベルされたLANは存在するかもしれません、そして、システムはそれへの業務用輸送に準備されます。値は「障害がある」なら、システムを超えたLANがラベルされません、そして、そのようなすべてのトラフィックが定義上下げられるでしょう。 したがって、彼の同輩がLAN Identificationsを調整しないと忠告されるシステムはリンクの上にそのようなトラフィックを進める必要はありません。
Point-to-Point Protocol Extensions Working Group [Page 16] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[16ページ]RFC1220
The default value is that LAN Identification disabled.
デフォルト値はIdentificationが無効にしたそのLANです。
Figure 9: LAN Identification Option
図9: LAN識別オプション
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=5 |length = 3 | Identification| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =5をタイプしてください。|長さ=3| 識別| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 5 = LAN Identification Support Option
5=LAN識別サポートオプションをタイプしてください。
Length 3 Octets
長さ3の八重奏
Identification Enable/Disable If the value is 1, LAN Identification is enabled. If the value is 2, LAN Identification is disabled.
識別Enable/はIfを無効にします。値は1、LAN Identificationが有効にされるということです。 値が2であるなら、LAN Identificationは障害があります。
7. Acknowledgements
7. 承認
This document is a product of the Point-to-Point Protocol Extensions Working Group. Special thanks go to Steve Senum of Network Systems, Dino Farinacci of 3COM, and Rick Szmauz of Digital Equipment Corporation.
このドキュメントはPointからポイントへのプロトコルExtensions作業部会の製品です。 特別な感謝はNetwork SystemsのスティーブSenum、3COMのディーノ・ファリナッチ、およびDECのリックSzmauzに行きます。
8. Bibliography
8. 図書目録
[1] Perkins, D., "The Point-to-Point Protocol for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links", RFC 1171, CMU, July 1990.
[1] パーキンス、D.、「ポイントツーポイント接続の上のマルチプロトコルデータグラムの送信のための二地点間プロトコル」、RFC1171、米カーネギーメロン大学、1990年7月。
[2] Hobby R., and D. Perkins, "The Point-to-Point Protocol (PPP) Initial Configuration Options", RFC 1172, CMU, UC Davis, July 1990.
[2]趣味R.、およびD.パーキンス、「二地点間プロトコル(ppp)の初期の設定オプション」、RFC1172、米カーネギーメロン大学、UCデイヴィス、1990年7月。
[3] IEEE Draft Standard P802.1d/D9 MAC Bridges, Institute of Electrical and Electronic Engineers. Also Published as ISO DIS 10038, July 1989.
[3] IEEEは標準のP802.1d/D9 MACブリッジ、電気電子学会を作成します。 また、ISO不-10038、1989年7月として、発行されています。
[4] IEEE Draft Standard P802.5d/D13 Draft Addendum to ANSI/IEEE Std 802.5-1988 Token Ring MAC and PHY Specification Enhancement for Multiple-Ring Networks, Institute of Electrical and Electronic Engineers, May 1989.
[4] IEEEの草稿の標準のP802.5d/D13は複数のリングネットワークのためにANSI/IEEE Std802.5-1988トークンリングMACとPHY仕様増進に付加物を作成します、電気電子学会、1989年5月。
Point-to-Point Protocol Extensions Working Group [Page 17] RFC 1220 Bridging Point-to-Point Protocol April 1991
二地点間プロトコル4月が1991であるとブリッジする二地点間プロトコル拡大作業部会[17ページ]RFC1220
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
10. Author's Address
10. 作者のアドレス
Fred Baker Advanced Computer Communications 720 Santa Barbara Street Santa Barbara, CA 93101
フレッド・ベイカー・高度なコンピュータコミュニケーション720サンタバーバラ・通りサンタバーバラ、カリフォルニア 93101
Phone: (805) 963-9431
以下に電話をしてください。 (805) 963-9431
EMail: fbaker@ACC.COM Or send comments to: ietf-ppp@ucdavis.edu
メール: fbaker@ACC.COM 、または、以下のことのためにコメントを送ってください。 ietf-ppp@ucdavis.edu
Point-to-Point Protocol Extensions Working Group [Page 18]
二地点間プロトコル拡大作業部会[18ページ]
一覧
スポンサーリンク