RFC1990 日本語訳
1990 The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G.McGregor, D. Carr, T. Coradetti. August 1996. (Format: TXT=53271 bytes) (Obsoletes RFC1717) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Sklower
Request for Comments: 1990 University of California, Berkeley
Obsoletes: 1717 B. Lloyd
Category: Standards Track G. McGregor
Lloyd Internetworking
D. Carr
Newbridge Networks Corporation
T. Coradetti
Sidewalk Software
August 1996
Sklowerがコメントのために要求するワーキンググループK.をネットワークでつないでください: 1990 カリフォルニア大学バークレイ校は以下を時代遅れにします。 1717年のB.ロイドカテゴリ: 標準化過程G.マクレガーロイドインターネットワーキングD.カーニューブリッジネットワークス社のT.Coradetti歩道ソフトウェア1996年8月
The PPP Multilink Protocol (MP)
pppマルチリンクプロトコル(MP)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols.
このドキュメントは複数の論理的なデータ・リンクの向こう側にデータグラムを分けて、再結合して、配列するための方法を提案します。 この仕事は、元々ISDNで複数の運搬人チャンネルを搾取する願望によって動機づけられましたが、等しく複数のPPPリンクが2台のシステムを接続するどんな状況にも適切です、asyncリンクを含んでいて。 これは新しいPPP[2]オプションとプロトコルによって達成されます。
The differences between the current PPP Multilink specification (RFC 1717) and this memo are explained in Section 11. Any system implementing the additional restrictions required by this memo will be backwards compatible with conforming RFC 1717 implementations.
現在のPPP Multilink仕様(RFC1717)とこのメモの違いはセクション11で説明されます。 後方に、RFC1717実現を従わせるのと互換性があった状態でこれが必要であることで、メモがあるという追加制限を実行するどんなシステム。
Acknowledgements
承認
The authors specifically wish to thank Fred Baker of ACC, Craig Fox of Network Systems, Gerry Meyer of Spider Systems, Dan Brennan of Penril Datability Networks, Vernon Schryver of SGI (for the comprehensive discussion of padding), and the members of the IP over Large Public Data Networks and PPP Extensions working groups, for much useful discussion on the subject.
作者はLarge Public Data NetworksとPPP Extensionsワーキンググループの上で明確にACCのフレッド・ベイカー、Network Systemsのクレイグフォックス、Spider Systemsのゲリー・マイヤー、Penril Datability Networksのダン・ブレナン、SGI(詰め物の網羅的な議論のための)のヴァーノンSchryver、およびIPのメンバーに感謝したがっています、問題についての多くの役に立つ議論のために。
Sklower, et. al. Standards Track [Page 1] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ................................................ 2 1.1. Motivation ................................................ 2 1.2. Functional Description .................................... 3 1.3. Conventions ............................................... 4 2. General Overview ............................................ 4 3. Packet Formats .............................................. 7 3.1. Padding Considerations .................................... 10 4. Trading Buffer Space Against Fragment Loss .................. 10 4.1. Detecting Fragment Loss ................................... 11 4.2. Buffer Space Requirements ................................. 12 5. PPP Link Control Protocol Extensions ........................ 13 5.1. Configuration Option Types ................................ 13 5.1.1. Multilink MRRU LCP option ............................... 14 5.1.2. Short Sequence Number Header Format Option .............. 15 5.1.3. Endpoint Discriminator Option ........................... 15 6. Initiating use of Multilink Headers ......................... 19 7. Closing Member links ........................................ 20 8. Interaction with Other Protocols ............................ 20 9. Security Considerations ..................................... 21 10. References ................................................. 21 11. Differences from RFC 1717 .................................. 22 11.1. Negotiating Multilink, per se ............................ 22 11.2. Initial Sequence Number defined .......................... 22 11.3. Default Value of the MRRU ................................ 22 11.4. Config-Nak of EID prohibited ............................. 22 11.5. Uniformity of Sequence Space ............................. 22 11.6. Commencing and Abating use of Multilink Headers .......... 23 11.7. Manual Configuration and Bundle Assignment ............... 23 12. Authors' Addresses ......................................... 24
1. 序論… 2 1.1. 動機… 2 1.2. 機能的な記述… 3 1.3. コンベンション… 4 2. 概要… 4 3. パケット形式… 7 3.1. 問題を水増しします… 10 4. 断片の損失に対してバッファ領域を取り引きします… 10 4.1. 断片の損失を検出します… 11 4.2. スペース要件をバッファリングしてください… 12 5. pppは制御プロトコル拡大をリンクします… 13 5.1. 設定オプションタイプ… 13 5.1.1. マルチリンクMRRU LCPオプション… 14 5.1.2. 短い一連番号ヘッダー形式オプション… 15 5.1.3. 終点弁別器オプション… 15 6. Multilink Headersの使用を開始します… 19 7. メンバーを閉じるのはリンクされます… 20 8. 他のプロトコルとの相互作用… 20 9. セキュリティ問題… 21 10. 参照… 21 11. RFC1717からの違い… 22 11.1. そういうもののMultilinkを交渉すること。 22 11.2. 定義されたSequence Numberに頭文字をつけてください… 22 11.3. MRRUのデフォルト値… 22 11.4. 禁止されたEIDのコンフィグ-Nak… 22 11.5. 系列スペースの一様性… 22 11.6. Multilink Headersの始めとAbating使用… 23 11.7. 手動の構成とバンドル課題… 23 12. 作者のアドレス… 24
1. Introduction
1. 序論
1.1. Motivation
1.1. 動機
Basic Rate and Primary Rate ISDN both offer the possibility of opening multiple simultaneous channels between systems, giving users additional bandwidth on demand (for additional cost). Previous proposals for the transmission of internet protocols over ISDN have stated as a goal the ability to make use of this capability, (e.g., Leifer et al., [1]).
基本的なRateとPrimary Rate ISDNはともに、複数の同時のチャンネルを開ける可能性をシステムの間に提供します、オンデマンドの追加帯域幅(別途費用のための)をユーザに与えて。 ISDNの上のインターネットプロトコルの送信のための前の提案が目標としてこの能力を利用する能力を述べた、(例えば、ライファー他([1]))。
There are proposals being advanced for providing synchronization between multiple streams at the bit level (the BONDING proposals); such features are not as yet widely deployed, and may require additional hardware for end system. Thus, it may be useful to have a purely software solution, or at least an interim measure.
噛み付いているレベル(BONDING提案)における複数の流れの間に同期を提供するために進められる提案があります。 そのような特徴は、まだ広く配備されていなくて、エンドシステムのための追加ハードウェアを必要とするかもしれません。 その結果、純粋にaを持っているのは役に立つかもしれません。ソフトウェアソリューション、または少なくとも一時的な方策。
Sklower, et. al. Standards Track [Page 2] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[2ページ]。
There are other instances where bandwidth on demand can be exploited, such as using a dialup async line at 28,800 baud to back up a leased synchronous line, or opening additional X.25 SVCs where the window size is limited to two by international agreement.
他の例がオンデマンドの帯域幅を利用できるところにあります、賃貸された同期線を支援するのに2万8800ボーでダイアルアップasync線を使用するか、または国際協定でウィンドウサイズが2に制限される追加X.25 SVCsを開くのなどように。
The simplest possible algorithms of alternating packets between channels on a space available basis (which might be called the Bank Teller's algorithm) may have undesirable side effects due to reordering of packets.
スペースの利用可能ベース(Bank Tellerのアルゴリズムと呼ばれるかもしれない)のチャンネルの間の交互のパケットの可能な限り簡単なアルゴリズムには、パケットを再命令するのによる望ましくない副作用があるかもしれません。
By means of a four-byte sequencing header, and simple synchronization rules, one can split packets among parallel virtual circuits between systems in such a way that packets do not become reordered, or at least the likelihood of this is greatly reduced.
4バイトの配列ヘッダー、および簡単な同期規則によって、1つはシステムの間の平行な仮想のサーキットの中でパケットが再命令されるようにならないか、または少なくともこの見込みが大いに減少するような方法でパケットを分けることができます。
1.2. Functional Description
1.2. 機能的な記述
The method discussed here is similar to the multilink protocol described in ISO 7776 [4], but offers the additional ability to split and recombine packets, thereby reducing latency, and potentially increase the effective maximum receive unit (MRU). Furthermore, there is no requirement here for acknowledged-mode operation on the link layer, although that is optionally permitted.
ここで議論した方法は、ISO7776[4]で説明されたマルチリンクプロトコルと同様ですが、パケットを分けて、再結合させる追加能力を提供します、その結果、レイテンシ、および潜在的に有効な最大が受け取る増加を抑えます。ユニット(MRU)。 その上、それは任意に受入れられますが、要件は全くリンクレイヤにおける承認されたモード操作のためにここにありません。
Multilink is based on an LCP option negotiation that permits a system to indicate to its peer that it is capable of combining multiple physical links into a "bundle". Only under exceptional conditions would a given pair of systems require the operation of more than one bundle connecting them.
マルチリンクはシステムが、複数の物理的なリンクを「バンドル」に結合できるのを同輩に示すことを許可するLCPオプション交渉に基づいています。 システムの与えられた組は例外的な条件だけのもとでそれらを接続する1つ以上のバンドルの操作を必要とするでしょう。
Multilink is negotiated during the initial LCP option negotiation. A system indicates to its peer that it is willing to do multilink by sending the multilink option as part of the initial LCP option negotiation. This negotiation indicates three things:
マルチリンクは初期のLCPオプション交渉の間、交渉されます。 システムは、初期のLCPオプション交渉の一部としてマルチリンクオプションを送ることによってマルチリンクをしても構わないと思っているのを同輩に示します。 この交渉は3つのことを示します:
1. The system offering the option is capable of combining multiple
physical links into one logical link;
1. オプションを提供するシステムは複数の物理的なリンクを1個の論理的なリンクに結合できます。
2. The system is capable of receiving upper layer protocol data
units (PDU) fragmented using the multilink header (described
later) and reassembling the fragments back into the original PDU
for processing;
2. システムはマルチリンクヘッダー(後で説明される)を使用することで断片化された上側の層のプロトコルデータ単位(PDU)と断片が処理のためにオリジナルのPDUに支持する組み立て直すことを受けることができます。
3. The system is capable of receiving PDUs of size N octets where N
is specified as part of the option even if N is larger than the
maximum receive unit (MRU) for a single physical link.
3. システムはNが単一の物理的なリンクへの最大が受信されるより大きい単位(MRU)であってもNがオプションの一部として指定されるところでサイズN八重奏のPDUsを受けることができます。
Sklower, et. al. Standards Track [Page 3] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[3ページ]。
Once multilink has been successfully negotiated, the sending system is free to send PDUs encapsulated and/or fragmented with the multilink header.
マルチリンクがいったん首尾よく交渉されると、送付システムは無料でマルチリンクヘッダーと共に要約される、そして/または、断片化されたPDUsを送ることができます。
1.3. Conventions
1.3. コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
o MUST, SHALL or MANDATORY -- the item is an absolute requirement
of the specification.
o SHALLかMANDATORY--項目は仕様に関する絶対条件であるに違いありません。
o SHOULD or RECOMMENDED -- the item should generally be followed
for all but exceptional circumstances.
o SHOULDかRECOMMENDED--一般に、商品はほとんど例外的な事情のために従われるべきです。
o MAY or OPTIONAL -- the item is truly optional and may be
followed or ignored according to the needs of the implementor.
o 5月かOPTIONAL--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
2. General Overview
2. 概要
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an Authentication phase in which the authentication protocols can be used to determine identifiers associated with each system connected by the link.
ポイントツーポイント接続の上でコミュニケーションを確立して、PPPリンクの各端は、最初に、Link特権階級段階の間、データ・リンクを構成するためにパケットをLCPに送らなければなりません。 リンクが設立された後に、PPPはリンクによって接続される各システムに関連している識別子を決定するのに認証プロトコルを使用できるAuthenticationフェーズに備えます。
The goal of multilink operation is to coordinate multiple independent links between a fixed pair of systems, providing a virtual link with greater bandwidth than any of the constituent members. The aggregate link, or bundle, is named by the pair of identifiers for two systems connected by the multiple links. A system identifier may include information provided by PPP Authentication [3] and information provided by LCP negotiation. The bundled links can be different physical links, as in multiple async lines, but may also be instances of multiplexed links, such as ISDN, X.25 or Frame Relay. The links may also be of different kinds, such as pairing dialup async links with leased synchronous links.
マルチリンク操作の目標は固定組のシステムの間の複数の独立しているリンクを調整することです、構成員のいずれよりも大きい帯域幅を仮想のリンクに提供して。 集合リンク、またはバンドルが複数のリンクによって接続された2台のシステムのための識別子の組によって命名されます。 システム識別子はPPP Authentication[3]によって提供された情報とLCP交渉で提供された情報を含むかもしれません。 束ねられたリンクは異なった物理的なリンクであるかもしれません、また、多重送信されたリンクの例であるかもしれなくて複数のasync線のように、ISDN、X.25またはFrame Relayなどのように。 また、リンクは賃貸された同期リンクとの組み合わせダイアルアップasyncリンクなどの異種のものであるかもしれません。
We suggest that multilink operation can be modeled as a virtual PPP link-layer entity wherein packets received over different physical link-layer entities are identified as belonging to a separate PPP network protocol (the Multilink Protocol, or MP) and recombined and sequenced according to information present in a multilink fragmentation header. All packets received over links identified as belonging to the multilink arrangement are presented to the same network-layer protocol processing machine, whether they have multilink headers or not.
私たちは、マルチリンク断片化ヘッダーの現在の情報によると、異なった物理的なリンクレイヤ実体の上に受け取られたパケットが別々のPPPネットワーク・プロトコル(Multilinkプロトコル、またはMP)に属すとして特定されて、再結合して、配列される仮想のPPPリンクレイヤ実体としてマルチリンク操作をモデル化できることを提案します。 マルチリンクアレンジメントに属すとして特定されたリンクの上に受け取られたすべてのパケットが同じネットワーク層プロトコル加工機に提示されます、それらにマルチリンクヘッダーがあるか否かに関係なく。
Sklower, et. al. Standards Track [Page 4] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[4ページ]。
The packets to be transmitted using the multilink procedure are encapsulated according to the rules for PPP where the following options would have been manually configured:
規則に従って、マルチリンク手順を使用することで伝えられるべきパケットは以下のオプションが手動で構成されたPPPのためにカプセルに入れられます:
o No async control character Map
o No Magic Number
o No Link Quality Monitoring
o Address and Control Field Compression
o Protocol Field Compression
o No Compound Frames
o No Self-Describing-Padding
o Link Quality Monitoring o asyncのoいいえのマジックNumber o制御文字MapノーがないAddressとControl Field CompressionのCompound FramesのoいいえのSelfの説明しているoプロトコルField Compression oいいえ詰め物
According to the rules specified in RFC1661, this means that an implementation MUST accept reassembled packets with and without leading zeroes present in the Protocol Field of the reassembled packet. Although it is explicitly forbidden below to include the Address and Control fields (usually, the two bytes FF 03) in the material to be fragmented, it is a good defensive programming practice to accept the packet anyway, ignoring the two bytes if present, as that is what RFC1661 specifies.
RFC1661で指定された規則に従って、実現が受け入れなければならないこの手段は組み立て直されたパケットのプロトコルFieldの現在の主なゼロのあるなしにかかわらずパケットを組み立て直しました。 以下で断片化されるために、材料にAddressとControl分野(通常2バイトFF03)を含んでいるのが明らかに禁じられますが、とにかくパケットを受け入れるのは、良い防衛的なプログラミング練習です、存在しているなら2バイトを無視して、それがRFC1661が指定することであるので。
As a courtesy to implementations that perform better when certain alignment obtains, it is suggested that a determination be made when a bundle is created on whether to transmit leading zeroes by examining whether PFC has been negotiated on the first link admitted into a bundle. This determination should be kept in force so long as a bundle persists.
実現への礼儀として、それは、より上手にいつを実行するか。ある整列が得る、PFCがバンドルを認められた最初のリンクに関して交渉されたかどうか調べることによって主なゼロを伝えるかどうかに関してバンドルを作成するとき、決断をすることが提案されます。 バンドルが持続している限り、この決断は有効に保たれるべきです。
Of course, individual links are permitted to have different settings for these options. As described below, member links SHOULD negotiate Self-Describing-Padding, even though pre-fragmented packets MUST NOT be padded. Since the Protocol Field Compression mode on the member link allows a sending system to include a leading byte of zero or not at its discretion, this is an alternative mechanism for generating even-length packets.
もちろん、個々のリンクにはこれらのオプションのための異なった設定があることが許可されています。 以下で説明されたメンバーリンクとして、あらかじめ断片化しているパケットを水増ししてはいけませんが、SHOULDはそっと歩くと説明するSelfを交渉します。 送付システムがメンバーリンクのプロトコルField Compressionモードで自己判断でゼロの主なバイトを含むことができるので、これは長ささえのパケットを発生させるための代替のメカニズムです。
LCP negotiations are not permitted on the bundle itself. An implementation MUST NOT transmit LCP Configure-Request, -Reject, -Ack, -Nak, Terminate-Request or -Ack packets via the multilink procedure, and an implementation receiving them MUST silently discard them. (By "silently discard" we mean to not generate any PPP packets in response; an implementation is free to generate a log entry registering the reception of the unexpected packet). By contrast, other LCP packets having control functions not associated with changing the defaults for the bundle itself are permitted. An implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo- Request, Echo-Reply and Discard-Request Packets.
LCP交渉はバンドル自体で受入れられません。 実現はマルチリンク手順でLCP Configure-要求、廃棄物、-Ack、-Nak、Terminate-要求または-Ackパケットを伝えてはいけません、そして、それらを受ける実現は静かにそれらを捨てなければなりません。 (私たちは、「静かに捨ててください」と応答でどんなPPPパケットも発生させないのを意図します; 実現は予期していなかったパケットのレセプションを登録するログエントリーを無料で発生させることができます。) 対照的に、バンドル自体のためにデフォルトを変えると関連づけられなかったコントロール機能を持っている他のLCPパケットが受入れられます。 実現はLCP Code-廃棄物、プロトコル廃棄物、Echo要求、Echo-回答、およびDiscard-要求Packetsを伝えるかもしれません。
Sklower, et. al. Standards Track [Page 5] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[5ページ]。
The effective MRU for the logical-link entity is negotiated via an LCP option. It is irrelevant whether Network Control Protocol packets are encapsulated in multilink headers or not, or even over which link they are sent, once that link identifies itself as belonging to a multilink arrangement.
論理的なリンク実体のための有効なMRUはLCPオプションで交渉されます。 マルチリンクヘッダーでNetwork Controlプロトコルパケットをカプセルに入れるかどうか、またはどれがリンクされるかの上にさえ彼らを送るかが無関係です、そのリンクはマルチリンクアレンジメントに属すことであるといったん名乗ると。
Note that network protocols that are not sent using multilink headers cannot be sequenced. (And consequently will be delivered in any convenient way).
マルチリンクヘッダーが使用させられないネットワーク・プロトコルは配列できないことに注意してください。 (そして、その結果、どんな便利な方法でも渡すでしょう。)
For example, consider the case in Figure 1. Link 1 has negotiated network layers NL 1, NL 2, and MP between two systems. The two systems then negotiate MP over Link 2.
例えば、図1におけるケースを考えてください。 リンク1は2台のシステムの間でネットワーク層NL1、NL2、およびMPを交渉しました。次に、2台のシステムがLink2の上でMPを交渉します。
Frames received on link 1 are demultiplexed at the data link layer according the PPP network protocol identifier and can be sent to NL 1, NL 2, or MP. Link 2 will accept frames with all network protocol identifiers that Link 1 does.
リンク1の上に受け取られたフレームは、PPPネットワークプロトコル識別子データ・リンク層で反多重送信して、NL1、NL2、またはMPに送ることができます。 リンク2はLink1がするすべてのネットワークプロトコル識別子でフレームを受け入れるでしょう。
Frames received by MP are further demultiplexed at the network layer according to the PPP network protocol identifier and sent to NL 1 or NL 2. Any frames received by MP for any other network layer protocols are rejected using the normal protocol reject mechanism.
MPによって受け取られたフレームは、PPPネットワークプロトコル識別子に従ったネットワーク層でさらに反多重送信されていてNL1かNL2に送られます。 いかなる他のネットワーク層プロトコルのためにもMPによって受け取られたどんなフレームも、正常なプロトコル廃棄物メカニズムを使用することで拒絶されます。
Sklower, et. al. Standards Track [Page 6] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[6ページ]。
Figure 1. Multilink Overview.
図1。 マルチリンク概観。
Network Layer
-------------
______ ______
/ \ / \
| NL 1 | | NL 2 |
\______/ \______/
| | | | | |
| | +-------------o-o-o-+
| +------+ +-----+ | | |
| | | | | |
| +------o--o-------+ + |
| | |__|_ | |
| | / \ | |
| | | MLCP | <--- Link Layer
| | \______/ Demultiplexing
| | | | |
| | | | |
| | | <--- Virtual Link
| | | | |
| | | | |
| | | | |
| | + | |
___|_| | ___|_|
/ \ | / \
| LCP |------+-----| LCP | <--- Link Layer
\______/ \______/ Demultiplexing
| |
| |
Link 1 Link 2
ネットワーク層------------- ______ ______ / \ / \ | NL1| | NL2| \______/ \______/ | | | | | | | | +-------------o-o-o-+ | +------+ +-----+ | | | | | | | | | | +------o--o-------+ + | | | |__|_ | | | | / \ | | | | | MLCP| <-- リンクレイヤ| | \______/逆多重化| | | | | | | | | | | | | <-- 仮想のリンク| | | | | | | | | | | | | | | | | + | | ___|_| | ___|_| / \ | / \ | LCP|------+-----| LCP| <-- リンク層の\______/ \______/逆多重化| | | | リンク1リンク2
3. Packet Formats
3. パケット・フォーマット
In this section we describe the layout of individual fragments, which are the "packets" in the Multilink Protocol. Network Protocol packets are first encapsulated (but not framed) according to normal PPP procedures, and large packets are broken up into multiple segments sized appropriately for the multiple physical links. Although it would otherwise be permitted by the PPP spec, implementations MUST NOT include the Address and Control Field in the logical entity to be fragmented. A new PPP header consisting of the Multilink Protocol Identifier, and the Multilink header is inserted before each section. (Thus the first fragment of a multilink packet in PPP will have two headers, one for the fragment, followed by the header for the packet itself).
このセクションで、私たちは個々の断片のレイアウトについて説明します。(断片はMultilinkプロトコルで「パケット」です)。 正常なPPP手順に応じて、ネットワークプロトコルパケットは最初にカプセルに入れられます、そして、(しかし、縁どられません)大きいパケットは適切に複数の物理的なリンクに大きさで分けられた複数のセグメントに壊れます。 そうでなければ、それはPPP仕様によって受入れられるでしょうが、実現は、断片化されるために論理的な実体にAddressとControl Fieldを含んではいけません。 MultilinkプロトコルIdentifier、およびMultilinkヘッダーから成る新しいPPPヘッダーはそうです。各セクションの前に挿入されます。 (その結果、PPPのマルチリンクパケットの最初の断片には、2個のヘッダー、パケット自体のためにヘッダーによって従われた断片のためのものがあるでしょう。)
Sklower, et. al. Standards Track [Page 7] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[7ページ]。
Systems implementing the multilink procedure are not required to fragment small packets. There is also no requirement that the segments be of equal sizes, or that packets must be broken up at all. A possible strategy for contending with member links of differing transmission rates would be to divide the packets into segments proportion to the transmission rates. Another strategy might be to divide them into many equal fragments and distribute multiple fragments per link, the numbers being proportional to the relative speeds of the links.
マルチリンク手順を実行するシステムは、小型小包を断片化するのに必要ではありません。 また、セグメントが等しいサイズのそうかパケットが全く壊れなければならないという要件が全くありません。 異なった通信速度のメンバーリンクを競争するための可能な戦略はパケットを通信速度へのセグメント割合に分割するだろうことです。 別の戦略は、それらを多くの等しい断片に分割して、リンク(リンクの相対速度に比例している数)単位で複数の断片を分配することであるかもしれません。
PPP multilink fragments are encapsulated using the protocol identifier 0x00-0x3d. Following the protocol identifier is a four byte header containing a sequence number, and two one bit fields indicating that the fragment begins a packet or terminates a packet. After negotiation of an additional PPP LCP option, the four byte header may be optionally replaced by a two byte header with only a 12 bit sequence space. Address & Control and Protocol ID compression are assumed to be in effect. Individual fragments will, therefore, have the following format:
PPPマルチリンク断片は、0×00プロトコル識別子0x3dを使用することでカプセルに入れられます。 プロトコル識別子に従うのは、一連番号を含む4バイトのヘッダーです、そして、2時1分は断片がパケットを始めるか、またはパケットを終えるのを示す分野に噛み付きました。 追加PPP LCPオプションの交渉の後に、2バイトのヘッダーは12ビットの系列スペースだけで任意に4バイトのヘッダーの後任になるかもしれません。 アドレス、Control、およびプロトコルID圧縮が有効であると思われます。 したがって、個々の断片には、以下の形式があるでしょう:
Figure 2: Long Sequence Number Fragment Format.
図2: 長いひと続きの出来事番号は形式を断片化します。
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-+-+-+-+---------------+
MP Header: |B|E|0|0|0|0|0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
+---------------+---------------+ pppヘッダー: | アドレス0xff| コントロール0x03| +---------------+---------------+ | PID(H)0x00| PID(L) 0x3d| +-+-+-+-+-+-+-+-+---------------+ MPヘッダー: |B|E|0|0|0|0|0|0|一連番号| +-+-+-+-+-+-+-+-+---------------+ | 一連番号(L)| +---------------+---------------+ | 断片データ| | . | | . | | . | +---------------+---------------+ ppp FCS: | FCS| +---------------+---------------+
Sklower, et. al. Standards Track [Page 8] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[8ページ]。
Figure 3: Short Sequence Number Fragment Format.
図3: 短い一連番号断片形式。
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
+---------------+---------------+ pppヘッダー: | アドレス0xff| コントロール0x03| +---------------+---------------+ | PID(H)0x00| PID(L) 0x3d| +-+-+-+-+-------+---------------+ MPヘッダー: |B|E|0|0| 一連番号| +-+-+-+-+-------+---------------+ | 断片データ| | . | | . | | . | +---------------+---------------+ ppp FCS: | FCS| +---------------+---------------+
The (B)eginning fragment bit is a one bit field set to 1 on the first fragment derived from a PPP packet and set to 0 for all other fragments from the same PPP packet.
(B)eginning断片ビットは他のすべての断片のために同じPPPパケットからPPPパケットとセットから0まで引き出された最初の断片の1に設定された1ビットの分野です。
The (E)nding fragment bit is a one bit field set to 1 on the last fragment and set to 0 for all other fragments. A fragment may have both the (B)eginning and (E)nding fragment bits set to 1.
(E)nding断片ビットは他のすべての断片のための0への最後の断片とセットの1に設定された1ビットの分野です。 断片で、(B)eginningと(E)nding断片ビットの両方を1に設定するかもしれません。
The sequence field is a 24 bit or 12 bit number that is incremented for every fragment transmitted. By default, the sequence field is 24 bits long, but can be negotiated to be only 12 bits with an LCP configuration option described below.
系列分野は24ビットであるかあらゆる断片のために増加される12ビットの数が伝わりました。 デフォルトで、系列分野を長さ24ビットですが、LCP設定オプションが以下で説明されている12ビットだけになるように交渉できます。
Between the (E)nding fragment bit and the sequence number is a reserved field, whose use is not currently defined, which MUST be set to zero. It is 2 bits long when the use of short sequence numbers has been negotiated, 6 bits otherwise.
(E)nding断片ビットと一連番号の間に、予約された分野(使用が現在、定義されないで、ゼロに設定しなければならない)があります。 短い一連番号の使用が別の方法で6ビット交渉されたとき、それは長さ2ビットです。
In this multilink protocol, a single reassembly structure is associated with the bundle. The multilink headers are interpreted in the context of this structure.
このマルチリンクプロトコルでは、ただ一つの再アセンブリ構造はバンドルに関連しています。 マルチリンクヘッダーはこの構造の文脈で解釈されます。
The FCS field shown in the diagram is inherited from the normal framing mechanism from the member link on which the packet is transmitted. There is no separate FCS applied to the reconstituted packet as a whole if transmitted in more than one fragment.
ダイヤグラムで示されたFCS分野は正常な縁どりメカニズムからパケットが伝えられるメンバーリンクから引き継がれます。 1個以上の断片で伝えられるなら全体で再編成されたパケットに適用されたどんな別々のFCSもありません。
Sklower, et. al. Standards Track [Page 9] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[9ページ]。
3.1. Padding Considerations
3.1. 問題を水増しします。
Systems that support the multilink protocol SHOULD implement Self- Describing-Padding. A system that implements self-describing-padding by definition will either include the padding option in its initial LCP Configure-Requests, or (to avoid the delay of a Configure-Reject) include the padding option after receiving a NAK containing the option.
マルチリンクプロトコルSHOULDを支持するシステムがSelfの説明している詰め物を実行します。 定義上そっと歩くと説明する自己を実行するシステムは、初期のLCP Configure-要求に詰め物オプションを含んでいるか、またはオプションを含むNAKを受けた後に、詰め物オプションを含むでしょう(Configure-廃棄物の遅れを避ける)。
A system that must pad its own transmissions but does not use Self- Describing-Padding when not using multilink, MAY continue to not use Self-Describing-Padding if it ensures by careful choice of fragment lengths that only (E)nding fragments of packets are padded. A system MUST NOT add padding to any packet that cannot be recognized as padded by the peer. Non-terminal fragments MUST NOT be padded with trailing material by any other method than Self-Describing-Padding.
それ自身のトランスミッションを水増ししなければなりませんが、マルチリンクを使用しないときSelfの説明している詰め物を使用しないシステム、パケットの(E)nding断片だけがそっと歩いているのを断片の長さの慎重な選択で確実にするなら、そっと歩くと説明するSelfを使用しなく続けるかもしれません。 システムは同輩がそっと歩くように認識できないどんなパケットにも詰め物を加えてはいけません。 引きずっている材料でそっと歩くと説明するSelfよりいかなる他の方法でも非端末断片を水増ししてはいけません。
A system MUST ensure that Self-Describing-Padding as described in RFC 1570 [11] is negotiated on the individual link before transmitting any multilink data packets if it might pad non-terminal fragments or if it would use network or compression protocols that are vulnerable to padding, as described in RFC 1570. If necessary, the system that adds padding MUST use LCP Configure-NAK's to elicit a Configure- Request for Self-Describing-Padding from the peer.
システムは、非端末断片を水増しするかもしれないか、または傷つきやすいネットワークか圧縮プロトコルを使用するならどんなマルチリンクデータ・パケットも伝える前にRFC1570[11]で説明されるSelf説明詰め物が個々のリンクに関してRFC1570で説明されるようにそっと歩くと交渉されるのを確実にしなければなりません。 必要なら、詰め物を加えるシステムは、同輩からそっと歩くと説明するSelfを求めるConfigure要求を聞き出すのにLCP Configure-NAKのものを使用しなければなりません。
Note that LCP Configure-Requests can be sent at any time on any link, and that the peer will always respond with a Configure-Request of its own. A system that pads its transmissions but uses no protocols other than multilink that are vulnerable to padding MAY delay ensuring that the peer has Configure-Requested Self-Describing- Padding until it seems desireable to negotiate the use of Multilink itself. This permits the interoperability of a system that pads with older peers that support neither Multilink nor Self-Describing- Padding.
いつでも、LCP Configure-要求をどんなリンクにも送ることができて、同輩がいつもそれ自身のConfigure-要求で応じることに注意してください。 トランスミッションを水増ししますが、マルチリンク以外の詰め物に傷つきやすいプロトコルがないのを使用するシステムは、同輩にはMultilink自身の使用を交渉するのが「望-可能」に思えるまでConfigureによって要求されたSelfについて説明している詰め物があるのを確実にするのを遅らせるかもしれません。 これはMultilinkもSelfについて説明していない詰め物も支持するより年取った同輩と共にそっと歩くシステムの相互運用性を可能にします。
4. Trading Buffer Space Against Fragment Loss
4. 断片の損失に対してバッファ領域を取り引きします。
In a multilink procedure one channel may be delayed with respect to the other channels in the bundle. This can lead to fragments being received out of order, thus increasing the difficulty in detecting the loss of a fragment. The task of estimating the amount of space required for buffering on the receiver becomes more complex because of this. In this section we discuss a technique for declaring that a fragment is lost, with the intent of minimizing the buffer space required, yet minimizing the number of avoidable packet losses.
マルチリンク手順で、1個のチャンネルが他のチャンネルに関してバンドルで遅れるかもしれません。 これは受け取られる断片に故障していた状態で通じることができます、その結果、断片の損失を検出しながら、困難を増やします。 スペースの合計が受信機の上のバッファリングに必要であると見積もるタスクはこれのために、より複雑になります。 このセクションで、私たちは断片が必要であるバッファ領域を最小にする意図になくされていると宣言するためのテクニックについて議論します、まだ回避可能なパケット損失の数を最小にしていて。
Sklower, et. al. Standards Track [Page 10] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[10ページ]。
4.1. Detecting Fragment Loss
4.1. 断片の損失を検出します。
On each member link in a bundle, the sender MUST transmit fragments with strictly increasing sequence numbers (modulo the size of the sequence space). This requirement supports a strategy for the receiver to detect lost fragments based on comparing sequence numbers. The sequence number is not reset upon each new PPP packet, and a sequence number is consumed even for those fragments which contain an entire PPP packet, i.e., one in which both the (B)eginning and (E)nding bits are set.
バンドルでのそれぞれのメンバーリンクの上では、送付者が厳密に増加する一連番号で断片を伝えなければならない、(法、系列スペースのサイズ) この要件は、一連番号を比較することに基づいて無くなっている断片を検出するために受信機のための戦略を支持します。 一連番号はそれぞれの新しいPPPパケットにリセットされません、そして、一連番号は全体のPPPパケット(すなわち、(B)eginningと(E)ndingビットの両方が設定されるもの)を含むそれらの断片のためにさえ消費されます。
An implementation MUST set the sequence number of the first fragment transmited on a newly-constructed bundle to zero. (Joining a secondary link to an exisiting bundle is invisible to the protocol, and an implementation MUST NOT reset the sequence number space in this situation).
実現は新たに組み立てられたバンドルでゼロにtransmitedされた最初の断片の一連番号を設定しなければなりません。 (二次リンクをexisitingバンドルに接合するのはプロトコルに目に見えません、そして、実現はこの状況における一連番号スペースをリセットしてはいけません。)
The receiver keeps track of the incoming sequence numbers on each link in a bundle and maintains the current minimum of the most recently received sequence number over all the member links in the bundle (call this M). The receiver detects the end of a packet when it receives a fragment bearing the (E)nding bit. Reassembly of the packet is complete if all sequence numbers up to that fragment have been received.
The receiver keeps track of the incoming sequence numbers on each link in a bundle and maintains the current minimum of the most recently received sequence number over all the member links in the bundle (call this M). The receiver detects the end of a packet when it receives a fragment bearing the (E)nding bit. Reassembly of the packet is complete if all sequence numbers up to that fragment have been received.
A lost fragment is detected when M advances past the sequence number of a fragment bearing an (E)nding bit of a packet which has not been completely reassembled (i.e., not all the sequence numbers between the fragment bearing the (B)eginning bit and the fragment bearing the (E)nding bit have been received). This is because of the increasing sequence number rule over the bundle. Any sequence number so detected is assumed to correspond to a fragment which has been lost.
A lost fragment is detected when M advances past the sequence number of a fragment bearing an (E)nding bit of a packet which has not been completely reassembled (i.e., not all the sequence numbers between the fragment bearing the (B)eginning bit and the fragment bearing the (E)nding bit have been received). This is because of the increasing sequence number rule over the bundle. Any sequence number so detected is assumed to correspond to a fragment which has been lost.
An implementation MUST assume that if a fragment bears a (B)eginning bit, that the previously numbered fragment bore an (E)nding bit. Thus if a packet is lost bearing the (E)nding bit, and the packet whose fragment number is M contains a (B)eginning bit, the implementation MUST discard fragments for all unassembled packets through M-1, but SHOULD NOT discard the fragment bearing the new (B)eginning bit on this basis alone.
An implementation MUST assume that if a fragment bears a (B)eginning bit, that the previously numbered fragment bore an (E)nding bit. Thus if a packet is lost bearing the (E)nding bit, and the packet whose fragment number is M contains a (B)eginning bit, the implementation MUST discard fragments for all unassembled packets through M-1, but SHOULD NOT discard the fragment bearing the new (B)eginning bit on this basis alone.
The detection of a lost fragment, whose sequence number was deduced to be U, causes the receiver to discard all fragments up to the lowest numbered fragment with an ending bit (possibly deduced) greater than or equal to U. However, the quantity M may jump into the middle of a chain of packets which can be successful completed.
The detection of a lost fragment, whose sequence number was deduced to be U, causes the receiver to discard all fragments up to the lowest numbered fragment with an ending bit (possibly deduced) greater than or equal to U. However, the quantity M may jump into the middle of a chain of packets which can be successful completed.
Sklower, et. al. Standards Track [Page 11] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 11] RFC 1990 PPP Multilink August 1996
Fragments may be lost due to corruption of individual packets or catastrophic loss of the link (which may occur only in one direction). This version of the multilink protocol mandates no specific procedures for the detection of failed links. The PPP link quality management facility, or the periodic issuance of LCP echo- requests could be used to achieve this.
Fragments may be lost due to corruption of individual packets or catastrophic loss of the link (which may occur only in one direction). This version of the multilink protocol mandates no specific procedures for the detection of failed links. The PPP link quality management facility, or the periodic issuance of LCP echo- requests could be used to achieve this.
Senders SHOULD avoid keeping any member links idle to maximize early detection of lost fragments by the receiver, since the value of M is not incremented on idle links. Senders SHOULD rotate traffic among the member links if there isn't sufficient traffic to overflow the capacity of one link to avoid idle links.
Senders SHOULD avoid keeping any member links idle to maximize early detection of lost fragments by the receiver, since the value of M is not incremented on idle links. Senders SHOULD rotate traffic among the member links if there isn't sufficient traffic to overflow the capacity of one link to avoid idle links.
Loss of the final fragment of a transmission can cause the receiver to stall until new packets arrive. The likelihood of this may be decreased by sending a null fragment on each member link in a bundle that would otherwise become idle immediately after having transmitted a fragment bearing the (E)nding bit, where a null fragment is one consisting only of a multilink header bearing both the (B)egin and (E)nding bits (i.e., having no payload). Implementations concerned about either wasting bandwidth or per packet costs are not required to send null fragments and may elect to defer sending them until a timer expires, with the marginally increased possibility of lengthier stalls in the receiver. The receiver SHOULD implement some type of link idle timer to guard against indefinite stalls.
Loss of the final fragment of a transmission can cause the receiver to stall until new packets arrive. The likelihood of this may be decreased by sending a null fragment on each member link in a bundle that would otherwise become idle immediately after having transmitted a fragment bearing the (E)nding bit, where a null fragment is one consisting only of a multilink header bearing both the (B)egin and (E)nding bits (i.e., having no payload). Implementations concerned about either wasting bandwidth or per packet costs are not required to send null fragments and may elect to defer sending them until a timer expires, with the marginally increased possibility of lengthier stalls in the receiver. The receiver SHOULD implement some type of link idle timer to guard against indefinite stalls.
The increasing sequence per link rule prohibits the reallocation of fragments queued up behind a failing link to a working one, a practice which is not unusual for implementations of ISO multilink over LAPB [4].
The increasing sequence per link rule prohibits the reallocation of fragments queued up behind a failing link to a working one, a practice which is not unusual for implementations of ISO multilink over LAPB [4].
4.2. Buffer Space Requirements
4.2. Buffer Space Requirements
There is no amount of buffering that will guarantee correct detection of fragment loss, since an adversarial peer may withhold a fragment on one channel and send arbitrary amounts on the others. For the usual case where all channels are transmitting, you can show that there is a minimum amount below which you could not correctly detect packet loss. The amount depends on the relative delay between the channels, (D[channel-i,channel-j]), the data rate of each channel, R[c], the maximum fragment size permitted on each channel, F[c], and the total amount of buffering the transmitter has allocated amongst the channels.
There is no amount of buffering that will guarantee correct detection of fragment loss, since an adversarial peer may withhold a fragment on one channel and send arbitrary amounts on the others. For the usual case where all channels are transmitting, you can show that there is a minimum amount below which you could not correctly detect packet loss. The amount depends on the relative delay between the channels, (D[channel-i,channel-j]), the data rate of each channel, R[c], the maximum fragment size permitted on each channel, F[c], and the total amount of buffering the transmitter has allocated amongst the channels.
When using PPP, the delay between channels could be estimated by using LCP echo request and echo reply packets. (In the case of links of different transmission rates, the round trip times should be adjusted to take this into account.) The slippage for each channel
When using PPP, the delay between channels could be estimated by using LCP echo request and echo reply packets. (In the case of links of different transmission rates, the round trip times should be adjusted to take this into account.) The slippage for each channel
Sklower, et. al. Standards Track [Page 12] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 12] RFC 1990 PPP Multilink August 1996
is defined as the bandwidth times the delay for that channel relative to the channel with the longest delay, S[c] = R[c] * D[c,c-worst]. (S[c-worst] will be zero, of course!)
is defined as the bandwidth times the delay for that channel relative to the channel with the longest delay, S[c] = R[c] * D[c,c-worst]. (S[c-worst] will be zero, of course!)
A situation which would exacerbate sequence number skew would be one in which there is extremely bursty traffic (almost allowing all channels to drain), and then where the transmitter would first queue up as many consecutively numbered packets on one link as it could, then queue up the next batch on a second link, and so on. Since transmitters must be able to buffer at least a maximum- sized fragment for each link (and will usually buffer up at least two) A receiver that allocates any less than S[1] + S[2] + ... + S[N] + F[1] + ... + F[N], will be at risk for incorrectly assuming packet loss, and therefore, SHOULD allocate at least twice that.
A situation which would exacerbate sequence number skew would be one in which there is extremely bursty traffic (almost allowing all channels to drain), and then where the transmitter would first queue up as many consecutively numbered packets on one link as it could, then queue up the next batch on a second link, and so on. Since transmitters must be able to buffer at least a maximum- sized fragment for each link (and will usually buffer up at least two) A receiver that allocates any less than S[1] + S[2] + ... + S[N] + F[1] + ... + F[N], will be at risk for incorrectly assuming packet loss, and therefore, SHOULD allocate at least twice that.
5. PPP Link Control Protocol Extensions
5. PPP Link Control Protocol Extensions
If reliable multilink operation is desired, PPP Reliable Transmission [6] (essentially the use of ISO LAPB) MUST be negotiated prior to the use of the Multilink Protocol on each member link.
If reliable multilink operation is desired, PPP Reliable Transmission [6] (essentially the use of ISO LAPB) MUST be negotiated prior to the use of the Multilink Protocol on each member link.
Whether or not reliable delivery is employed over member links, an implementation MUST present a signal to the NCP's running over the multilink arrangement that a loss has occurred.
Whether or not reliable delivery is employed over member links, an implementation MUST present a signal to the NCP's running over the multilink arrangement that a loss has occurred.
Compression may be used separately on each member link, or run over the bundle (as a logical group link). The use of multiple compression streams under the bundle (i.e., on each link separately) is indicated by running the Compression Control Protocol [5] but with an alternative PPP protocol ID.
Compression may be used separately on each member link, or run over the bundle (as a logical group link). The use of multiple compression streams under the bundle (i.e., on each link separately) is indicated by running the Compression Control Protocol [5] but with an alternative PPP protocol ID.
5.1. Configuration Option Types
5.1. Configuration Option Types
The Multilink Protocol introduces the use of additional LCP Configuration Options:
The Multilink Protocol introduces the use of additional LCP Configuration Options:
o Multilink Maximum Received Reconstructed Unit
o Multilink Short Sequence Number Header Format
o Endpoint Discriminator
o Multilink Maximum Received Reconstructed Unit o Multilink Short Sequence Number Header Format o Endpoint Discriminator
Sklower, et. al. Standards Track [Page 13] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 13] RFC 1990 PPP Multilink August 1996
5.1.1. Multilink MRRU LCP option
5.1.1. Multilink MRRU LCP option
Figure 4: Multilink MRRU LCP option
Figure 4: Multilink MRRU LCP option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 17 | Length = 4 | Max-Receive-Reconstructed-Unit|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 17 | Length = 4 | Max-Receive-Reconstructed-Unit| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The presence of this LCP option indicates that the system sending it implements the PPP Multilink Protocol. If not rejected, the system will construe all packets received on this link as being able to be processed by a common protocol machine with any other packets received from the same peer on any other link on which this option has been accepted.
The presence of this LCP option indicates that the system sending it implements the PPP Multilink Protocol. If not rejected, the system will construe all packets received on this link as being able to be processed by a common protocol machine with any other packets received from the same peer on any other link on which this option has been accepted.
The Max-Receive-Reconstructed unit field is two octets, and specifies the maximum number of octets in the Information fields of reassembled packets. A system MUST be able to receive the full 1500 octet Information field of any reassembled PPP packet although it MAY attempt to negotiate a smaller, or larger value. The number 1500 here comes from the specification for the MRU LCP option in PPP; if this requirement is changed in a future version of RFC 1661, the same rules will apply here.
The Max-Receive-Reconstructed unit field is two octets, and specifies the maximum number of octets in the Information fields of reassembled packets. A system MUST be able to receive the full 1500 octet Information field of any reassembled PPP packet although it MAY attempt to negotiate a smaller, or larger value. The number 1500 here comes from the specification for the MRU LCP option in PPP; if this requirement is changed in a future version of RFC 1661, the same rules will apply here.
A system MUST include the LCP MRRU option in every LCP negotiation intended to instantiate a bundle or to join an existing bundle. If the LCP MRRU option is offered on a link which is intended to join an existing bundle, a system MUST offer the same Max-Receive- Reconstruct-Unit value previously negotiated for the bundle.
A system MUST include the LCP MRRU option in every LCP negotiation intended to instantiate a bundle or to join an existing bundle. If the LCP MRRU option is offered on a link which is intended to join an existing bundle, a system MUST offer the same Max-Receive- Reconstruct-Unit value previously negotiated for the bundle.
A system MUST NOT send any multilink packets on any link unless its peer has offered the MMRU LCP option and the system has configure- Ack'ed it during the most recent LCP negotiation on that link. A system MAY include the MMRU LCP option in a configure-NAK, if its peer has not offered it (until, according to PPP rules, the peer configure-Reject's it).
A system MUST NOT send any multilink packets on any link unless its peer has offered the MMRU LCP option and the system has configure- Ack'ed it during the most recent LCP negotiation on that link. A system MAY include the MMRU LCP option in a configure-NAK, if its peer has not offered it (until, according to PPP rules, the peer configure-Reject's it).
Note: the MRRU value conveyed im this option corresponds to the MRU of the bundle when conceptualized as a PPP entity; but the rules for the Multilink MRRU option are different from the LCP MRU option, as some value MUST be offered in every LCP negotiation, and that confirmation of this option is required prior to multilink interpretation.
Note: the MRRU value conveyed im this option corresponds to the MRU of the bundle when conceptualized as a PPP entity; but the rules for the Multilink MRRU option are different from the LCP MRU option, as some value MUST be offered in every LCP negotiation, and that confirmation of this option is required prior to multilink interpretation.
Sklower, et. al. Standards Track [Page 14] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 14] RFC 1990 PPP Multilink August 1996
5.1.2. Short Sequence Number Header Format Option
5.1.2. Short Sequence Number Header Format Option
Figure 5: Short Sequence Number Header Format Option
Figure 5: Short Sequence Number Header Format Option
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 18 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 18 | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option advises the peer that the implementation wishes to receive fragments with short, 12 bit sequence numbers. When a peer system configure-Ack's this option, it MUST transmit all multilink packets on all links of the bundle with 12 bit sequence numbers or configure-Reject the option. If 12 bit sequence numbers are desired, this option MUST be negotiated when the bundle is instantiated, and MUST be explicitly included in every LCP configure request offered by a system when the system intends to include that link in an existing bundle using 12 bit sequence numbers. If this option is never negotiated during the life of a bundle, sequence numbers are 24 bits long.
This option advises the peer that the implementation wishes to receive fragments with short, 12 bit sequence numbers. When a peer system configure-Ack's this option, it MUST transmit all multilink packets on all links of the bundle with 12 bit sequence numbers or configure-Reject the option. If 12 bit sequence numbers are desired, this option MUST be negotiated when the bundle is instantiated, and MUST be explicitly included in every LCP configure request offered by a system when the system intends to include that link in an existing bundle using 12 bit sequence numbers. If this option is never negotiated during the life of a bundle, sequence numbers are 24 bits long.
An implementation wishing to transmit multilink fragments with short sequence numbers MAY include the multilink short sequence number in a configure-NAK to ask that the peer respond with a request to receive short sequence numbers. The peer is not compelled to respond with the option.
An implementation wishing to transmit multilink fragments with short sequence numbers MAY include the multilink short sequence number in a configure-NAK to ask that the peer respond with a request to receive short sequence numbers. The peer is not compelled to respond with the option.
5.1.3. Endpoint Discriminator Option
5.1.3. Endpoint Discriminator Option
Figure 7: Endpoint Discriminator Option
Figure 7: Endpoint Discriminator Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 19 | Length | Class | Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 19 | Length | Class | Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Endpoint Discriminator Option represents identification of the system transmitting the packet. This option advises a system that the peer on this link could be the same as the peer on another existing link. If the option distinguishes this peer from all others, a new bundle MUST be established from the link being negotiated. If this option matches the class and address of some other peer of an existing link, the new link MUST be joined to the bundle containing the link to the matching peer or MUST establish a new bundle, depending on the decision tree shown in (1) through (4) below.
The Endpoint Discriminator Option represents identification of the system transmitting the packet. This option advises a system that the peer on this link could be the same as the peer on another existing link. If the option distinguishes this peer from all others, a new bundle MUST be established from the link being negotiated. If this option matches the class and address of some other peer of an existing link, the new link MUST be joined to the bundle containing the link to the matching peer or MUST establish a new bundle, depending on the decision tree shown in (1) through (4) below.
Sklower, et. al. Standards Track [Page 15] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 15] RFC 1990 PPP Multilink August 1996
To securely join an existing bundle, a PPP authentication protocol [3] must be used to obtain authenticated information from the peer to prevent a hostile peer from joining an existing bundle by presenting a falsified discriminator option.
To securely join an existing bundle, a PPP authentication protocol [3] must be used to obtain authenticated information from the peer to prevent a hostile peer from joining an existing bundle by presenting a falsified discriminator option.
This option is not required for multilink operation. If a system does not receive the Multilink MRRU option, but does receive the Endpoint Discriminator Option, and there is no manual configuration providing outside information, the implementation MUST NOT assume that multilink operation is being requested on this basis alone.
This option is not required for multilink operation. If a system does not receive the Multilink MRRU option, but does receive the Endpoint Discriminator Option, and there is no manual configuration providing outside information, the implementation MUST NOT assume that multilink operation is being requested on this basis alone.
As there is also no requirement for authentication, there are four sets of scenarios:
As there is also no requirement for authentication, there are four sets of scenarios:
(1) No authentication, no discriminator:
All new links MUST be joined to one bundle, unless
there is manual configuration to the contrary.
It is also permissible to have more than one manually
configured bundle connecting two given systems.
(1) No authentication, no discriminator: All new links MUST be joined to one bundle, unless there is manual configuration to the contrary. It is also permissible to have more than one manually configured bundle connecting two given systems.
(2) Discriminator, no authentication:
Discriminator match -> MUST join matching bundle,
discriminator mismatch -> MUST establish new bundle.
(2) Discriminator, no authentication: Discriminator match -> MUST join matching bundle, discriminator mismatch -> MUST establish new bundle.
(3) No discriminator, authentication:
Authenticated match -> MUST join matching bundle,
authenticated mismatch -> MUST establish new bundle.
(3) No discriminator, authentication: Authenticated match -> MUST join matching bundle, authenticated mismatch -> MUST establish new bundle.
(4) Discriminator, authentication:
Discriminator match and authenticated match -> MUST join bundle,
discriminator mismatch -> MUST establish new bundle,
authenticated mismatch -> MUST establish new bundle.
(4) Discriminator, authentication: Discriminator match and authenticated match -> MUST join bundle, discriminator mismatch -> MUST establish new bundle, authenticated mismatch -> MUST establish new bundle.
The option contains a Class which selects an identifier address space and an Address which selects a unique identifier within the class address space.
The option contains a Class which selects an identifier address space and an Address which selects a unique identifier within the class address space.
This identifier is expected to refer to the mechanical equipment associated with the transmitting system. For some classes, uniqueness of the identifier is global and is not bounded by the scope of a particular administrative domain. Within each class, uniqueness of address values is controlled by a class dependent policy for assigning values.
This identifier is expected to refer to the mechanical equipment associated with the transmitting system. For some classes, uniqueness of the identifier is global and is not bounded by the scope of a particular administrative domain. Within each class, uniqueness of address values is controlled by a class dependent policy for assigning values.
Each endpoint may chose an identifier class without restriction. Since the objective is to detect mismatches between endpoints erroneously assumed to be alike, mismatch on class alone is sufficient. Although no one class is recommended, classes which have
Each endpoint may chose an identifier class without restriction. Since the objective is to detect mismatches between endpoints erroneously assumed to be alike, mismatch on class alone is sufficient. Although no one class is recommended, classes which have
Sklower, et. al. Standards Track [Page 16] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 16] RFC 1990 PPP Multilink August 1996
universally unique values are preferred.
universally unique values are preferred.
This option is not required to be supported either by the system or the peer. If the option is not present in a Configure-Request, the system MUST NOT generate a Configure-Nak of this option for any reason; instead it SHOULD behave as if it had received the option with Class = 0, Address = 0. If a system receives a Configure-Nak or Configure-Reject of this option, it MUST remove it from any additional Configure-Request.
This option is not required to be supported either by the system or the peer. If the option is not present in a Configure-Request, the system MUST NOT generate a Configure-Nak of this option for any reason; instead it SHOULD behave as if it had received the option with Class = 0, Address = 0. If a system receives a Configure-Nak or Configure-Reject of this option, it MUST remove it from any additional Configure-Request.
The size is determined from the Length field of the element. For some classes, the length is fixed, for others the length is variable. The option is invalid if the Length field indicates a size below the minimum for the class.
The size is determined from the Length field of the element. For some classes, the length is fixed, for others the length is variable. The option is invalid if the Length field indicates a size below the minimum for the class.
An implementation MAY use the Endpoint Discriminator to locate administration or authentication records in a local database. Such use of this option is incidental to its purpose and is deprecated when a PPP Authentication protocol [3] can be used instead. Since some classes permit the peer to generate random or locally assigned address values, use of this option as a database key requires prior agreement between peer administrators.
An implementation MAY use the Endpoint Discriminator to locate administration or authentication records in a local database. Such use of this option is incidental to its purpose and is deprecated when a PPP Authentication protocol [3] can be used instead. Since some classes permit the peer to generate random or locally assigned address values, use of this option as a database key requires prior agreement between peer administrators.
The specification of the subfields are:
The specification of the subfields are:
Type
19 = for Endpoint Discriminator
Type 19 = for Endpoint Discriminator
Length
3 + length of Address
Length 3 + length of Address
Class
The Class field is one octet and indicates the identifier
address space. The most up-to-date values of the LCP Endpoint
Discriminator Class field are specified in the most recent
"Assigned Numbers" RFC [7]. Current values are assigned as
follows:
Class The Class field is one octet and indicates the identifier address space. The most up-to-date values of the LCP Endpoint Discriminator Class field are specified in the most recent "Assigned Numbers" RFC [7]. Current values are assigned as follows:
0 Null Class
0 Null Class
1 Locally Assigned Address
1 Locally Assigned Address
2 Internet Protocol (IP) Address
2 Internet Protocol (IP) Address
3 IEEE 802.1 Globally Assigned MAC Address
3 IEEE 802.1 Globally Assigned MAC Address
4 PPP Magic-Number Block
4 PPP Magic-Number Block
Sklower, et. al. Standards Track [Page 17] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 17] RFC 1990 PPP Multilink August 1996
5 Public Switched Network Directory Number
5 Public Switched Network Directory Number
Address
The Address field is one or more octets and indicates the
identifier address within the selected class. The length and
content depend on the value of the Class as follows:
Address The Address field is one or more octets and indicates the identifier address within the selected class. The length and content depend on the value of the Class as follows:
Class 0 - Null Class
Class 0 - Null Class
Maximum Length: 0
Maximum Length: 0
Content:
This class is the default value if the option is not
present in a received Configure-Request.
Content: This class is the default value if the option is not present in a received Configure-Request.
Class 1 - Locally Assigned Address
Class 1 - Locally Assigned Address
Maximum Length: 20
Maximum Length: 20
Content:
Content:
This class is defined to permit a local assignment in the
case where use of one of the globally unique classes is not
possible. Use of a device serial number is suggested. The
use of this class is deprecated since uniqueness is not
guaranteed.
This class is defined to permit a local assignment in the case where use of one of the globally unique classes is not possible. Use of a device serial number is suggested. The use of this class is deprecated since uniqueness is not guaranteed.
Class 2 - Internet Protocol (IP) Address
Class 2 - Internet Protocol (IP) Address
Fixed Length: 4
Fixed Length: 4
Content:
Content:
An address in this class contains an IP host address as
defined in [8].
An address in this class contains an IP host address as defined in [8].
Class 3 - IEEE 802.1 Globally Assigned MAC Address
Class 3 - IEEE 802.1 Globally Assigned MAC Address
Fixed Length: 6
Fixed Length: 6
Content:
Content:
An address in this class contains an IEEE 802.1 MAC address
in canonical (802.3) format [9]. The address MUST have the
global/local assignment bit clear and MUST have the
multicast/specific bit clear. Locally assigned MAC
addresses should be represented using Class 1.
An address in this class contains an IEEE 802.1 MAC address in canonical (802.3) format [9]. The address MUST have the global/local assignment bit clear and MUST have the multicast/specific bit clear. Locally assigned MAC addresses should be represented using Class 1.
Sklower, et. al. Standards Track [Page 18] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 18] RFC 1990 PPP Multilink August 1996
Class 4 - PPP Magic-Number Block
Class 4 - PPP Magic-Number Block
Maximum Length: 20
Maximum Length: 20
Content:
Content:
This is not an address but a block of 1 to 5 concatenated
32 bit PPP Magic-Numbers as defined in [2]. This class
provides for automatic generation of a value likely but not
guaranteed to be unique. The same block MUST be used by an
endpoint continuously during any period in which at least
one link is in the LCP Open state. The use of this class
is deprecated.
This is not an address but a block of 1 to 5 concatenated 32 bit PPP Magic-Numbers as defined in [2]. This class provides for automatic generation of a value likely but not guaranteed to be unique. The same block MUST be used by an endpoint continuously during any period in which at least one link is in the LCP Open state. The use of this class is deprecated.
Note that PPP Magic-Numbers are used in [2] to detect
unexpected loopbacks of a link from an endpoint to itself.
There is a small probability that two distinct endpoints
will generate matching magic-numbers. This probability is
geometrically reduced when the LCP negotiation is repeated
in search of the desired mismatch, if a peer can generate
uncorrelated magic-numbers.
Note that PPP Magic-Numbers are used in [2] to detect unexpected loopbacks of a link from an endpoint to itself. There is a small probability that two distinct endpoints will generate matching magic-numbers. This probability is geometrically reduced when the LCP negotiation is repeated in search of the desired mismatch, if a peer can generate uncorrelated magic-numbers.
As used here, magic-numbers are used to determine if two
links are in fact from the same peer endpoint or from two
distinct endpoints. The numbers always match when there is
one endpoint. There is a small probability that the
numbers will match even if there are two endpoints. To
achieve the same confidence that there is not a false match
as for LCP loopback detection, several uncorrelated magic-
numbers can be combined in one block.
As used here, magic-numbers are used to determine if two links are in fact from the same peer endpoint or from two distinct endpoints. The numbers always match when there is one endpoint. There is a small probability that the numbers will match even if there are two endpoints. To achieve the same confidence that there is not a false match as for LCP loopback detection, several uncorrelated magic- numbers can be combined in one block.
Class 5 - Public Switched Network Directory Number
Class 5 - Public Switched Network Directory Number
Maximum Length: 15
Maximum Length: 15
Content:
Content:
An address in this class contains an octet sequence as
defined by I.331 (E.164) representing an international
telephone directory number suitable for use to access the
endpoint via the public switched telephone network [10].
An address in this class contains an octet sequence as defined by I.331 (E.164) representing an international telephone directory number suitable for use to access the endpoint via the public switched telephone network [10].
6. Initiating use of Multilink Headers
6. Initiating use of Multilink Headers
When the use of the Multilink protocol has been negotiated on a link (say Y), and the link is being added to a bundle which currently contains a single existing link (say X), a system MUST transmit a Multilink-encapsulated packet on X before transmitting any Multilink-
When the use of the Multilink protocol has been negotiated on a link (say Y), and the link is being added to a bundle which currently contains a single existing link (say X), a system MUST transmit a Multilink-encapsulated packet on X before transmitting any Multilink-
Sklower, et. al. Standards Track [Page 19] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 19] RFC 1990 PPP Multilink August 1996
encapsulated packets on Y.
encapsulated packets on Y.
Since links may be added and removed from a bundle without destroying the state associated with it, the fragment should be assigned the appropriate (next) fragment number. As noted earlier, the first fragment transmitted in the life of a bundle is assigned fragment number 0.
Since links may be added and removed from a bundle without destroying the state associated with it, the fragment should be assigned the appropriate (next) fragment number. As noted earlier, the first fragment transmitted in the life of a bundle is assigned fragment number 0.
7. Closing Member links
7. Closing Member links
Member links may be terminated according to normal PPP LCP procedures using LCP Terminate-Request and Terminate-Ack packets on that member link. Since it is assumed that member links usually do not reorder packets, receipt of a terminate ack is sufficient to assume that any multilink protocol packets ahead of it are at no special risk of loss.
Member links may be terminated according to normal PPP LCP procedures using LCP Terminate-Request and Terminate-Ack packets on that member link. Since it is assumed that member links usually do not reorder packets, receipt of a terminate ack is sufficient to assume that any multilink protocol packets ahead of it are at no special risk of loss.
Receipt of an LCP Terminate-Request on one link does not conclude the procedure on the remaining links.
Receipt of an LCP Terminate-Request on one link does not conclude the procedure on the remaining links.
So long as any member links in the bundle are active, the PPP state for the bundle persists as a separate entity. However, if the there is a unique link in the bundle, and all the other links were closed gracefully (with Terminate-Ack), an implementation MAY cease using multilink headers.
So long as any member links in the bundle are active, the PPP state for the bundle persists as a separate entity. However, if the there is a unique link in the bundle, and all the other links were closed gracefully (with Terminate-Ack), an implementation MAY cease using multilink headers.
If the multilink procedure is used in conjunction with PPP reliable transmission, and a member link is not closed gracefully, the implementation should expect to receive packets which violate the increasing sequence number rule.
If the multilink procedure is used in conjunction with PPP reliable transmission, and a member link is not closed gracefully, the implementation should expect to receive packets which violate the increasing sequence number rule.
8. Interaction with Other Protocols
8. Interaction with Other Protocols
In the common case, LCP, and the Authentication Control Protocol would be negotiated over each member link. The Network Protocols themselves and associated control exchanges would normally have been conducted once, on the bundle.
In the common case, LCP, and the Authentication Control Protocol would be negotiated over each member link. The Network Protocols themselves and associated control exchanges would normally have been conducted once, on the bundle.
In some instances it may be desirable for some Network Protocols to be exempted from sequencing requirements, and if the MRU sizes of the link did not cause fragmentation, those protocols could be sent directly over the member links.
In some instances it may be desirable for some Network Protocols to be exempted from sequencing requirements, and if the MRU sizes of the link did not cause fragmentation, those protocols could be sent directly over the member links.
Although explicitly discouraged above, if there were several member links connecting two implementations, and independent sequencing of two protocol sets were desired, but blocking of one by the other was not, one could describe two multilink procedures by assigning
Although explicitly discouraged above, if there were several member links connecting two implementations, and independent sequencing of two protocol sets were desired, but blocking of one by the other was not, one could describe two multilink procedures by assigning
Sklower, et. al. Standards Track [Page 20] RFC 1990 PPP Multilink August 1996
Sklower, et. al. Standards Track [Page 20] RFC 1990 PPP Multilink August 1996
multiple endpoint identifiers to a given system. Each member link, however, would only belong to one bundle. One could think of a physical router as housing two logically separate implementations, each of which is independently configured.
multiple endpoint identifiers to a given system. Each member link, however, would only belong to one bundle. One could think of a physical router as housing two logically separate implementations, each of which is independently configured.
A simpler solution would be to have one link refuse to join the bundle, by sending a Configure-Reject in response to the Multilink LCP option.
A simpler solution would be to have one link refuse to join the bundle, by sending a Configure-Reject in response to the Multilink LCP option.
9. Security Considerations
9. Security Considerations
Operation of this protocol is no more and no less secure than operation of the PPP authentication protocols [3]. The reader is directed there for further discussion.
Operation of this protocol is no more and no less secure than operation of the PPP authentication protocols [3]. The reader is directed there for further discussion.
10. References
10. References
[1] Leifer, D., Sheldon, S., and B. Gorsline, "A Subnetwork Control
Protocol for ISDN Circuit-Switching", University of Michigan
(unpublished), March 1991.
[1] Leifer, D., Sheldon, S., and B. Gorsline, "A Subnetwork Control Protocol for ISDN Circuit-Switching", University of Michigan (unpublished), March 1991.
[2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, Daydreamer, July 1994.
[2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.
[3] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC
1334, Lloyd Internetworking, Daydreamer, October 1992.
[3] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, Lloyd Internetworking, Daydreamer, October 1992.
[4] International Organisation for Standardization, "HDLC -
Description of the X.25 LAPB-Compatible DTE Data Link
Procedures", International Standard 7776, 1988
[4] International Organisation for Standardization, "HDLC - Description of the X.25 LAPB-Compatible DTE Data Link Procedures", International Standard 7776, 1988
[5] Rand, D., "The PPP Compression Control Protocol (CCP)", PPP
Extensions Working Group, RFC 1962, June 1996.
[5] Rand, D., "The PPP Compression Control Protocol (CCP)", PPP Extensions Working Group, RFC 1962, June 1996.
[6] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
1994
[6] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 1994
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
[8] Postel, J., Editor, "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, USC/Information Sciences
Institute, September 1981.
[8] Postel, J., Editor, "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.
[9] Institute of Electrical and Electronics Engineers, Inc., "IEEE
Local and Metropolitan Area Networks: Overview and Architecture",
IEEE Std. 802-1990, 1990.
[9] Institute of Electrical and Electronics Engineers, Inc., "IEEE Local and Metropolitan Area Networks: Overview and Architecture", IEEE Std. 802-1990, 1990.
Sklower, et. al. Standards Track [Page 21] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[21ページ]。
[10] The International Telegraph and Telephone Consultative Committee
(CCITT), "Numbering Plan for the ISDN Area", Recommendation I.331
(E.164), 1988.
[10]国際電信電話諮問委員会(CCITT)、「ISDN領域のための付番プラン」、推薦I.331(E.164)、1988。
[11] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer,
January 1994.
[11] シンプソン、W.、エディタ、「ppp LCP拡張子」、RFC1570、空想家、1994年1月。
11. Differences from RFC 1717
11. RFC1717からの違い
This section documents differences from RFC 1717. There are restrictions placed on implementations that were absent in RFC 1717; systems obeying these restrictions are fully interoperable with RFC 1717 - compliant systems.
このセクションはRFC1717から違いを記録します。 RFC1717で欠けている実現に関して課される制限があります。 これらの制限に従うシステムはRFC1717と共に完全に共同利用できます--対応するシステム。
11.1. Negotiating Multilink, per se
11.1. Multilinkを交渉することそういうものの。
RFC 1717 permitted either the use of the Short Sequence Number Header Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU) options by themselves to indicate the intent to negotiate multilink. This specification forbids the use of the SSNHF option by itself; but does permit the specific of both options together. Any implementation which otherwise conforms to rfc1717 and also obeys this restriction will interoperate with any RFC 1717 implementation.
RFC1717は、Short Sequence Number Header Format(SSNHF)の使用か自分たちによるMaximum Reconstructed Receive Unit(MRRU)オプションのどちらかがマルチリンクを交渉する意図を示すのを可能にしました。 この仕様自体はSSNHFオプションの使用を禁じます。 しかし、両方のオプションの特定を一緒に可能にします。 そうでなければ、rfc1717に従って、またこの制限に従うどんな実現もどんなRFC1717実現でも共同利用するでしょう。
11.2. Initial Sequence Number defined
11.2. 定義された初期のSequence Number
This specification requires that the first sequence number transmitted after the virtual link has reached to open state be 0.
この仕様は、仮想のリンクに状態を開くために達した後に伝えられた最初の一連番号が0であることを必要とします。
11.3. Default Value of the MRRU
11.3. MRRUのデフォルト値
This specfication removes the default value for the MRRU, (since it must always be negotiated with some value), and specifies that an implementation must be support an MRRU with same value as the default MRU size for PPP.
このspecficationがMRRUのためにデフォルト値を取り除く、(いつも何らかの値とそれを交渉しなければならないので)、実現がPPPのためのデフォルトMRUサイズと同じ値でMRRUを支持することであるに違いないと指定します。
11.4. Config-Nak of EID prohibited
11.4. 禁止されたEIDのコンフィグ-Nak
This specification forbids the config-Naking of an EID for any reason.
この仕様はいずれのためのEIDのコンフィグ-Naking理由を禁じます。
11.5. Uniformity of Sequence Space
11.5. 系列スペースの一様性
This specification requires that the same sequence format be employed on all links in a bundle.
この仕様は、同じ系列形式がすべてのリンクの上にバンドルで使われるのを必要とします。
Sklower, et. al. Standards Track [Page 22] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[22ページ]。
11.6. Commencing and Abating use of Multilink Headers
11.6. Multilink Headersの始めとAbating使用
This memo specifies how one should start the use of Multilink Headers when a link is added, and under what circumstances it is safe to discontinue their use.
このメモはリンクが加えられるとき、どのようにMultilink Headersの使用を始めるべきであるか、そして、彼らの使用を中止するのがどんな状況で安全であるかを指定します。
11.7. Manual Configuration and Bundle Assignment
11.7. 手動の構成とバンドル課題
The document explicitly permits multiple bundles to be manually configured in the absence of both the Endpoint Descriminator and any form of authentication.
ドキュメントは、複数のバンドルがEndpoint Descriminatorとどんな形式の認証の両方が不在のとき手動で構成されるのを明らかに可能にします。
Sklower, et. al. Standards Track [Page 23] RFC 1990 PPP Multilink August 1996
et Sklower、アル。 規格はpppマルチリンク1996年8月にRFC1990を追跡します[23ページ]。
13. Authors' Addresses
13. 作者のアドレス
Keith Sklower Computer Science Department 384 Soda Hall, Mail Stop 1776 University of California Berkeley, CA 94720-1776
キースSklowerコンピュータ理学部384ソーダホール、1776カリフォルニア大学バークレー、メールStopカリフォルニア94720-1776
Phone: (510) 642-9587 EMail: sklower@CS.Berkeley.EDU
以下に電話をしてください。 (510) 642-9587 メールしてください: sklower@CS.Berkeley.EDU
Brian Lloyd Lloyd Internetworking 3031 Alhambra Drive Cameron Park, CA 95682
ブライアンロイドロイドInternetworking3031アルハンブラ宮殿ドライブキャメロン公園、カリフォルニア 95682
Phone: (916) 676-1147 EMail: brian@lloyd.com
以下に電話をしてください。 (916) 676-1147 メールしてください: brian@lloyd.com
Glenn McGregor Lloyd Internetworking 3031 Alhambra Drive Cameron Park, CA 95682
グレンマクレガーロイドInternetworking3031アルハンブラ宮殿ドライブキャメロン公園、カリフォルニア 95682
Phone: (916) 676-1147 EMail: glenn@lloyd.com
以下に電話をしてください。 (916) 676-1147 メールしてください: glenn@lloyd.com
Dave Carr Newbridge Networks Corporation 600 March Road P.O. Box 13600 Kanata, Ontario, Canada, K2K 2E6
Kanata、デーヴカーニューブリッジネットワークス社600の3月の道路P.O. Box13600オンタリオ(カナダ)K2K2E6
Phone: (613) 591-3600 EMail: dcarr@Newbridge.COM
以下に電話をしてください。 (613) 591-3600 メールしてください: dcarr@Newbridge.COM
Tom Coradetti Sidewalk Software 1190 Josephine Road Roseville, MN 55113
トムCoradetti歩道ソフトウェア1190ジョセフィーヌ・Roadローズビル、ミネソタ 55113
Phone: (612) 490 7856 EMail: 70761.1664@compuserve.com
以下に電話をしてください。 (612) 490 7856はメールされます: 70761.1664@compuserve.com
Sklower, et. al. Standards Track [Page 24]
et Sklower、アル。 標準化過程[24ページ]
一覧
スポンサーリンク
