RFC2125 日本語訳
2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP BandwidthAllocation Control Protocol (BACP). C. Richards, K. Smith. March 1997. (Format: TXT=49213 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Richards
Request for Comments: 2125 Shiva Corporation
Category: Standards Track K. Smith
Ascend Communications, Inc.
March 1997
コメントを求めるワーキンググループC.リチャーズの要求をネットワークでつないでください: 2125年のシバ神社のCategory: 標準化過程K.スミスは1997年のコミュニケーションInc.行進のときに昇ります。
The PPP Bandwidth Allocation Protocol (BAP)
The PPP Bandwidth Allocation Control Protocol (BACP)
ppp帯域幅配分プロトコル(BAP)ppp帯域幅調節プロトコル(BACP)
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 to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol [2]. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to co- ordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection.
このドキュメントはPPPマルチリンクプロトコル[2]をサポートする実現のダイナミックな帯域幅配分を管理する方法を提案します。 Bandwidth Allocationプロトコル(BAP)を定義することによって、これをします、関連制御プロトコルと同様に、Bandwidth Allocation Controlプロトコル(BACP)。 マルチリンクバンドルでのリンクの数を管理するのにBAPを使用できます。 BAPはどの同輩がマルチリンク接続の間帯域幅を管理することに関するどの決定に責任があるかを指定することと同様にマルチリンクバンドルで個々のリンクを加えて、取り外す共同縦座標とデータグラムを定義します。
Table of Contents
目次
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 3
2. New LCP Configuration Option .......................... 3
2.1 Link Discriminator .............................. 3
3. BACP Operation ........................................ 4
4. BACP Configuration Options ............................ 5
4.1 Favored-Peer .................................... 5
5. BAP Operation ......................................... 7
5.1 Link Management ................................. 7
5.2 Bandwidth Management ............................ 8
5.3 BAP Packets ..................................... 8
5.4 Race Conditions ................................. 9
5.5 BAP Datagram Format ............................. 9
5.5.1 Call-Request .................................... 12
5.5.2 Call-Response ................................... 12
1. 序論… 2 1.1 要件の仕様… 2 1.2用語… 3 2. 新しいLCP設定オプション… 3 2.1 弁別器をリンクしてください… 3 3. BACP操作… 4 4. BACP設定オプション… 5 4.1 好評な同輩… 5 5. BAP操作… 7 5.1 管理をリンクしてください… 7 5.2 帯域幅管理… 8 5.3 BAPパケット… 8 5.4の競合条件… 9 5.5 BAPデータグラム形式… 9 5.5 .1発呼要求… 12 5.5 .2呼び出し応答… 12
Richards & Smith Standards Track [Page 1] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[1ページ]。
5.5.3 Callback-Request ................................ 13
5.5.4 Callback-Response ............................... 13
5.5.5 Link-Drop-Query-Request ......................... 13
5.5.6 Link-Drop-Query-Response ........................ 13
5.5.7 Call-Status-Indication .......................... 14
5.5.8 Call-Status-Response ............................ 14
6. BAP Datagram Options .................................. 14
6.1 Link-Type ....................................... 15
6.2 Phone-Delta ..................................... 17
6.2.1 Phone-Delta Sub-Options ......................... 18
6.3 No-Phone-Number-Needed .......................... 19
6.4 Reason .......................................... 20
6.5 Link-Discriminator .............................. 21
6.6 Call-Status ..................................... 21
Appendix - List of BAP datagrams and associated fields ....... 23
ACKNOWLEDEMENTS .............................................. 23
SECURITY CONSIDERATIONS ...................................... 23
REFERENCES ................................................... 24
CHAIR'S ADDRESS .............................................. 24
EDITORS'S ADDRESSES .......................................... 24
5.5.3 回収要求… 13 5.5 .4回収応答… 13 5.5 .5リンク低下質問要求… 13 5.5 .6 リンク低下質問応答… 13 5.5 .7 指示に状態に電話をしてください… 14 5.5 .8 応答に状態に電話をしてください… 14 6. BAPデータグラムオプション… 14 6.1 リンクでタイプしてください… 15 6.2電話デルタ… 17 6.2 .1 電話デルタサブオプション… 18 6.3 数が必要としなかった電話全く… 19 6.4 推論してください… 20 6.5リンク弁別器… 21 6.6呼び出し状態… 21 付録--BAPデータグラムと関連分野のリスト… 23ACKNOWLEDEMENTS… 23 セキュリティ問題… 23の参照箇所… 24 議長のアドレス… 24エディターズのアドレス… 24
1. Introduction
1. 序論
As PPP multilink implementations become increasingly common, there is a greater need for some conformity in how to manage bandwidth over such links. BACP and BAP provide a flexible yet robust way of managing bandwidth between 2 peers. BAP does this by defining Call- Control packets and a protocol that allows peers to co-ordinate the actual bandwidth allocation and de-allocation. Phone number deltas may be passed in the Call-Control packets to minimize the end user's configuration.
PPPマルチリンク実現がますます一般的になるとき、そのようなリンクの上にどう帯域幅を管理するかの何らかの一致に関するより大きな必要性があります。 BACPとBAPは2人の同輩の間の帯域幅を管理するフレキシブルな、しかし、強健な方法を提供します。 BAPは、Callコントロールパケットと同輩が実際の帯域幅配分と反-配分を調整できるプロトコルを定義することによって、これをします。 電話番号デルタは、エンドユーザの構成を最小にするためにCall-コントロールパケットで通過されるかもしれません。
1.1. Specification of Requirements
1.1. 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized.
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
「必要である」というThis単語、または形容詞が、定義が仕様に関する絶対条件であることを意味しなければなりません。
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
Thisは定義がある手段を言葉で表してはいけません。仕様の絶対禁止。
SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
「推薦される」というSHOULD This単語、または形容詞が、この項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意を理解されて、異なったコースを選ぶ前に、慎重に熟慮しなければなりません。
Richards & Smith Standards Track [Page 2] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[2ページ]。
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
5月のThis単語、または「任意である」という形容詞が、この項目が許容セットの代替手段の1つであることを意味します。 オプションを含んでいる別の実現で共同利用するようにこのオプションを含んでいない実現を準備しなければなりません。
1.2. Terminology
1.2. 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
peer The other end of the point-to-point link
他が終わらせるポイントツーポイント接続の同輩
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of the
silently discarded packet, and SHOULD record the event in a
statistics counter.
さらに処理しながら、静かにThis手段を実現がパケットを捨てる捨ててください。 実現SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
BOD (bandwidth on demand)
BOD refers to the ability of a system to allocate and remove
links in a multilink system to change the bandwidth of a
multilink bundle. This may be done in response to changing
line conditions and it also may be done in response to changing
resource conditions. In either case, changing bandwidth
dynamically during a multilink connection is referred to as
BOD.
BOD(オンデマンドの帯域幅)BODはシステムがマルチリンクバンドルの帯域幅を変えるためにマルチリンクシステムでリンクを割り当てて、取り外す能力について言及します。 線状態を変えることに対応してこれをするかもしれません、そして、また、リソース状態を変えることに対応してそれをするかもしれません。 どちらの場合ではも、マルチリンク接続の間、ダイナミックに帯域幅を変えるのはBODと呼ばれます。
2. New LCP Configuration Option
2. 新しいLCP設定オプション
Implementations MUST implement LCP as defined in [1]. LCP MUST be in the Network-Layer Protocol phase before BACP can be negotiated.
実現は[1]で定義されるようにLCPを実行しなければなりません。 BACPを交渉できる前にLCP MUSTはNetwork-層のプロトコルフェーズにおいてそうです。
2.1. Link Discriminator
2.1. リンク弁別器
Description
記述
This LCP Configuration Option is used to declare a unique
discriminator for the link that the option is sent over. This
option MUST be negotiated by LCP on every link. BAP uses the link
discriminator to differentiate the various links in a multilink
bundle. Each link in a multilink bundle MUST have a unique
discriminator. The discriminator is independent for each peer, so
each link may have 2 different LCP Link Discriminator values, one
for each peer. When the Link Discriminator is sent in a BAP
packet, the transmitter sends the Link Discriminator Option value
received from its peer in the peer's LCP Configure Request packet.
このLCP Configuration Optionは、リンクへのオプションが送られるユニークな弁別器が終わっていると宣言するのに使用されます。あらゆるリンクの上のLCPはこのオプションを交渉しなければなりません。 BAPは、マルチリンクバンドルで様々なリンクを微分するのにリンク弁別器を使用します。 マルチリンクバンドルでの各リンクには、ユニークな弁別器がなければなりません。 各同輩にとって、弁別器が独立しているので、各リンクには、2つの異なったLCP Link Discriminator値(各同輩あたり1つ)があるかもしれません。 BAPパケットでLink Discriminatorを送るとき、送信機は同輩のLCP Configure Requestパケットの同輩からLink Discriminator Option対価領収を送ります。
Richards & Smith Standards Track [Page 3] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[3ページ]。
A summary of the Link Discriminator LCP Option format is shown below. The fields are transmitted from left to right.
Link Discriminator 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 | Length | Link Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
23 for Link Discriminator option.
23 Link Discriminatorオプションのために。
Length
長さ
4
4
Link Discriminator
リンク弁別器
The Link Discriminator field is 2 octets in Length, and it
contains a unique identifier used to indicate a particular link in
a multilink bundle. The Link Discriminator for a link MUST be
unique among the Link Discriminators assigned by this endpoint for
this bundle. The Link Discriminator MAY be assigned in a
sequential, monotonically increasing manner.
Link Discriminator分野はLengthの2つの八重奏です、そして、それはマルチリンクバンドルで特定のリンクを示すのに使用されるユニークな識別子を含んでいます。 リンクへのLink Discriminatorはこのバンドルのためにこの終点によって割り当てられたLink Discriminatorsの中でユニークであるに違いありません。 Link Discriminatorは連続して、単調に増加する方法で割り当てられるかもしれません。
3. BACP Operation
3. BACP操作
BACP uses the same packet exchange mechanism as the Link Control Protocol defined in [1]. BACP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase. BACP packets received before this phase is reached should be silently discarded.
BACPは[1]で定義されたLink Controlプロトコルと同じパケット交換メカニズムを使用します。 PPPがNetwork-層のプロトコルフェーズに達するまで、BACPパケットを交換してはいけません。 このフェーズに達する前に受け取られたBACPパケットは静かに捨てられるべきです。
BACP is negotiated once per multilink bundle. If BACP is negotiated on any of the links in a multilink bundle, it is opened for all of the links in the bundle.
BACPはマルチリンクバンドルに一度交渉されます。 BACPがリンクのどれかに関してマルチリンクバンドルで交渉されるなら、それはバンドルでのリンクのすべてのために開かれます。
The Bandwidth Allocation Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions:
Bandwidth Allocation Controlプロトコルはまさに以下の例外でLink Controlプロトコル[1]と同じです:
Data Link Layer Protocol Field
データリンク層プロトコル分野
Exactly one BACP packet is encapsulated in the Information
field of PPP Data Link Layer frames where the Protocol field
indicates Type hex c02b (Bandwidth Allocation Control
Protocol).
ちょうど1つのBACPパケットがプロトコル分野がType十六進法c02b(帯域幅Allocation Controlプロトコル)を示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。
Richards & Smith Standards Track [Page 4] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[4ページ]。
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.
Codes1だけ、通じて、7 (要求を構成する、Configure-Ack、Configure-Nak、Configure-廃棄物、Terminate-要求、Terminate- Ack、およびCode-廃棄物) 使用されます。 他のCodesは認識されていないとして扱われるべきであり、Code-廃棄物をもたらすはずです。
Configuration Option Types
設定オプションタイプ
BACP has a distinct set of Configuration Options, which are
defined in the next section.
BACPには、Configuration Optionsの異なったセットがあります。(Configuration Optionsは次のセクションで定義されます)。
4. BACP Configuration Options
4. BACP設定オプション
BACP Configuration Options allow negotiation of desirable BACP parameters. These options are used in Config-Request, Config-Ack, Config-Nak, and Config-Reject packets. BACP uses the same Configuration Option format defined for LCP [1], with a seperate set of Options.
BACP Configuration Optionsは望ましいBACPパラメタの交渉を許します。 これらのオプションはConfig-要求、Config-Ack、Config-Nak、およびConfig-廃棄物パケットで使用されます。 BACPはLCP[1]のためにOptionsのseperateセットで定義された同じConfiguration Option書式を使用します。
Current values of BACP Configuration Options are assigned as follows:
BACP Configuration Optionsの現行価値は以下の通り割り当てられます:
1 Favored-Peer
1人の好評な同輩
4.1. Favored-Peer
4.1. 好評な同輩
Description
記述
This Configuration Option is used to determine which peer is
favored in the event of a race condition in which 2 peers
simultaneously transmit the same BAP request. Each peer
negotiates a 4 octet magic number, which is successfully
negotiated when the 2 Magic-Numbers are different. The favored
peer is the peer that transmits the lowest Magic-Number in its
Favored-Peer Configuration Option.
このConfiguration Optionは、どの同輩が2人の同輩が同時に同じBAP要求を伝える競合条件の場合、支持されるかを決定するのに使用されます。 各同輩は4八重奏マジックナンバーを交渉します。(2つのマジック番号が異なっているとき、それは、首尾よく交渉されます)。 好評な同輩はFavored-同輩Configuration Optionにおける最も下位のマジック数を伝える同輩です。
The Favored-Peer Configuration Option MUST be implemented.
Favored-同輩Configuration Optionを実行しなければなりません。
Richards & Smith Standards Track [Page 5] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[5ページ]。
BACP will usually be negotiated after only one link of a multilink
bundle has reached the Network-Layer Protocol phase. In this
situation, it is acceptable for the peer that initiated the
connection to use a Magic-Number of 1, and the peer that responded
to the connection to use a Magic-Number of 0xFFFFFFFF. If a
multilink bundle has been established with links that were
originated by each peer, or if it is not clear which peer has
initiated a link (on a leased line, for example), then a random
number MUST be used for the Magic-Number. Refer to the
description of the LCP Magic-Number Configuration Option in [1]
for an explanation of how to create a useful random number.
マルチリンクバンドルの1個のリンクだけがNetwork-層のプロトコルフェーズに達した後に通常、BACPは交渉されるでしょう。 この状況で、接続を開始した同輩にとって、マジック数の1、およびマジック数を使用するために接続に応じた0xFFFFFFFFの同輩を使用するのは許容できます。 マルチリンクバンドルが各同輩によって溯源されたリンクで確立されたか、またはどの同輩がリンク(例えば専用線の上に)を開始したかが、明確でないなら、マジック数に乱数を使用しなければなりません。 どう役に立つ乱数を作成するかに関する説明のための[1]のLCPマジック数のConfiguration Optionの記述を参照してください。
When a Configure-Request is received with a Favored-Peer
Configuration Option, the received Magic-Number is compared with
the Magic-Number of the last Configure-Request sent to the peer.
If the two Magic-Numbers are different, then the Favored-Peer
negotiation has been successful, and the Favored-Peer Option
SHOULD be acknowledged. If the two Magic-Numbers are equal, a
Configure-Nak MUST be sent specifying a different Magic-Number
value. A new Configure-Request SHOULD NOT be sent to the peer
until normal processing would cause it to be sent (that is, until
a Configure-Nak is received or the Restart timer runs out).
Favored-同輩Configuration Optionと共にConfigure-要求を受け取るとき、同輩に送る最後のConfigure-要求のマジック数に容認されたマジック数をたとえます。 2つのマジック番号が異なるなら、承認されていて、Favored-同輩交渉にはうまくいってFavoredじっと見Option SHOULDであることがあるその時です。 2つのマジック番号が等しいなら、Configure-Nakに異なったマジック数の値を指定させなければなりません。 A新しい、SHOULD NOTが正常処理でそれを送るだろうまで(すなわち、Configure-Nakが受け取られているか、またはRestartタイマがなくなるまで)同輩に送られるようConfigure要求してください。
A summary of the Favored-Peer Option format is shown below. The fields are transmitted from left to right.
Favored-同輩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 | Length | Magic-Number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Magic-Number (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| マジックナンバー+++++++++++++++++++++++++++++++++マジックナンバー(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1 for Favored-Peer
1 好評な同輩のために
Length
長さ
6
6
Magic-Number
マジックナンバー
The Magic-Number field is four octets, and indicates a number
which is very likely to be unique to one end of the link. A
Magic-Number of zero is illegal and MUST always be Nak'd.
マジックナンバーフィールドは、4つの八重奏であり、非常にありそうな数がリンクの片端に特有であることを示します。 マジック数のゼロは、不法であり、いつもあるに違いありません。Nakはそうするでしょう。
Richards & Smith Standards Track [Page 6] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[6ページ]。
5. BAP Operation
5. BAP操作
5.1. Link Management
5.1. リンク管理
BAP defines packets, parameters and negotiation procedures to allow two endpoints to negotiate gracefully adding and dropping links from a multilink bundle. An implementation can:
BAPは、優雅に交渉するためにマルチリンクバンドルからリンクを加えて、落としながら2つの終点を許容するためにパケット、パラメタ、および交渉手順を定義します。 実現はそうすることができます:
o Request permission to add a Link to a bundle (Call-Request)
o バンドルにLinkを加える許可を要求してください。(発呼要求)
o Request that the peer add a link to a bundle via a callback
(Callback-Request)
o 同輩が回収でバンドルにリンクを加えるよう要求してください。(回収要求)
o Negotiate with the peer to drop a link from a bundle (this
implies that the peer can refuse) (Link-Drop-Query-Request)
o バンドルからリンクを落とす同輩と交渉してください(これは、同輩が拒否できるのを含意します)。(リンク低下質問要求)
After BACP reaches the opened state, either peer MAY request that another link be added to the bundle by sending a BAP Call- or Callback-Request packet. A Call-Request packet is sent if the implementation wishes to originate the call for the new link, and a Callback-Request packet is sent if the implementation wishes its peer to originate the call for the new link. The implementation receiving a Call- or Callback-Request MUST respond with a Call- or Callback- Response with a valid Response Code.
BACPが開かれた状態に達した後に、どちらの同輩も、別のリンクがBAP CallかCallback-リクエスト・パケットを送ることによってバンドルに加えられるよう要求するかもしれません。 実現が新しいリンクのための呼び出しを溯源したいなら、Call-リクエスト・パケットを送ります、そして、実現が、同輩が新しいリンクのための呼び出しを溯源する必要があるなら、Callback-リクエスト・パケットを送ります。 CallかCallback-要求を受け取る実現は有効なResponse CodeとのCallかCallback応答で応じなければなりません。
After BACP reaches the opened state, either peer MAY request that a link be dropped from the bundle. A BAP Link-Drop-Query-Request packet is sent to the peer to negotiate dropping a link. The peer MUST respond with a Link-Drop-Query-Response. If the peer is agreeable to dropping the link the implementation MUST issue an LCP Terminate-Request to initiate dropping the link.
BACPが開かれた状態に達した後に、どちらの同輩も、リンクがバンドルから落とされるよう要求するかもしれません。 リンクを落としながら交渉するためにBAP Link低下質問リクエスト・パケットを同輩に送ります。 同輩はLink低下質問応答で応じなければなりません。 同輩がリンクを落とすのに快いなら、リンクを落として、実現は開始するLCP Terminate-要求を出さなければなりません。
If an implementation wishes to force dropping a link without negotiation, it should simply send an LCP Terminate-Request packet on the link (without sending any BAP Link-Drop-Query-Request).
実現が交渉のないリンクを低下しているのに強制したいなら、それは単にリンク(どんなBAP Link低下質問要求も送ることのない)にLCP Terminate-リクエスト・パケットを送るべきです。
After an LCP Terminate-Request is sent an implementation SHOULD stop transmitting data packets on that link, but still continue to receive and process data packets normally until receipt of a Terminate-Ack from the peer. The receiver of an LCP Terminate-Request SHOULD stop transmitting packets before issuing the Terminate-Ack. This procedure will insure that no data is lost in either direction.
LCP Terminate-要求に実現を送った後に、SHOULDは、そのリンクの上にデータ・パケットを伝えるのを止めますが、それでも、通常、同輩からデータ・パケットをTerminate-Ackの領収書まで受けて、処理し続けてください。 Terminate-Ackを発行する前にパケットを伝えるLCP Terminate-要求SHOULD停止の受信機。 この手順は、データが全くどちらの方向にも失われていないのを保障するでしょう。
Richards & Smith Standards Track [Page 7] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[7ページ]。
5.2. Bandwidth Management
5.2. 帯域幅管理
BAP allows two peer implementations to manage the bandwidth available to the protocols using the multilink bundle by negotiating when to add and drop links (See Link Management). Use of the negotiation features of BAP makes it unnecessary to require a 'common' algorithm for determining when to add and remove links in a multilink bundle.
BAPは、2つの同輩実現にいつ加えるか、そして、低下リンクを交渉することによってマルチリンクバンドルを使用することでプロトコルに利用可能な帯域幅を管理させます(Link Managementを見てください)。 BAPの交渉機能の使用で、マルチリンクバンドルでいつリンクを加えて、取り外すかを決定するための'一般的な'アルゴリズムを必要とするのは不要になります。
BOD decisions can be based on link utilization. A BAP implementation may monitor its transmit traffic, both transmit and receive traffic, or choose not to monitor traffic in either direction. If a server system implements bi-directional monitoring, it will allow BOD operation with a client that does not monitor traffic in either direction, which will minimize the end-user's configuration. When an implementation decides that it is time to remove a link due to traffic monitoring, it MUST transmit a Link-Drop-Query-Request to inquire if the peer agrees to drop a link from the current multilink bundle. When an implementation receives a Link-Drop-Query-Request, it SHOULD base its response on the traffic it is monitoring. It MUST NOT base its response solely on its receive data heuristics.
BOD決定はリンク利用に基づくことができます。 BAP実現がモニターするかもしれない、それ、交通を伝えるか、両方が交通を送受信するか、またはどちらの方向にも交通をモニターしないのを選んでください。 サーバシステムが双方向のモニターを実行すると、それはエンドユーザの構成を最小にするどちらの方向にも交通をモニターしないクライアントとの操作をBODに許すでしょう。 実現が、交通モニターのためもうリンクを取り外すべき時間であると決めると、それは同輩が、現在のマルチリンクバンドルからリンクを落とすのに同意するかどうか問い合わせるというLink低下質問要求を伝えなければなりません。 実現がaを受けるとき、Linkは質問要求を落として、それはSHOULDベースです。それがモニターしている交通のその応答。 それは唯一応答を受信データ発見的教授法に基礎づけてはいけません。
The operation of the Link-Drop-Query-Request and -Response datagrams causes a link in a multilink bundle to be left up as long as either implementation that is monitoring link utilization determines that it is necessary.
Link低下質問要求と応答データグラムの操作で、リンク利用をモニターしているどちらの実現も、それが必要であることを決定する限り、マルチリンクバンドルでのリンクを掲げます。
BOD decisions can also be based on the resources (e.g., physical port, B-channel, etc.) available to an implementation. For example, an implementation might remove a link from a multilink bundle to answer an incoming voice call, or might add a link when a line becomes free due to the termination of a separate PPP call on another port. An implementation MUST use an LCP Terminate-Request to remove a link due to a resource condition.
また、BOD決定は実現に利用可能なリソース(例えば、物理的なポート、Bチャネルなど)に基づくことができます。 例えば、実現は、入って来る音声通話に答えるためにマルチリンクバンドルからリンクを取り外すか、または線が別のポートにおける別々のPPP呼び出しの終了のために自由になると、リンクを加えるかもしれません。 実現はリソース状態のためリンクを取り外すというLCP Terminate-要求を使用しなければなりません。
5.3. BAP Packets
5.3. BAPパケット
All of the BAP Request and Indication packets require a Response packet in response before taking any action.
どんな行動も取る前に、BAP RequestとIndicationパケットのすべてが応答でResponseパケットを必要とします。
An implementation MUST set a timer when sending a Request or Indication packet. The value of this timer SHOULD depend on the type and speed of the link or links in use. Upon expiration of this timer, the implementation MUST retransmit the request or indication, with an identical identification number. This procedure will insure that the peer receives the proper request or indication even if a packet is lost during transmission. If a response packet is lost the peer will realize that this is not a new request or indication packet.
RequestかIndicationパケットを送るとき、実現はタイマを設定しなければなりません。 このタイマSHOULDの値は使用中のリンクかリンクのタイプと速度に頼っています。 このタイマの満了のときに、実現は同じ識別番号で要求か指示を再送しなければなりません。 この手順は、パケットがトランスミッションの間、失われても同輩が適切な要求か指示を受け取るのを保障するでしょう。 応答パケットが無くなると、同輩はこれが新しい要求でない、また指示パケットでないとわかるでしょう。
Richards & Smith Standards Track [Page 8] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[8ページ]。
If the number of retransmissions exceeds the number supported by the implementation for this packet, the implementation MAY take appropriate recovery action. For example, if no response to a Link- Drop-Query-Request is received after 2 retransmissions, an implementation MAY initiate dropping the link by sending an LCP Terminate-Request for that link.
「再-トランスミッション」の数がこのパケットのための実現で支持された数を超えているなら、実現は適切な回復処置を取るかもしれません。 例えば、Link低下質問要求へのどんな応答も受け取られていないなら、2「再-トランスミッション」、それを求めるLCP Terminate-要求を送ることによってリンクを落とす実現5月の開始の後に、リンクしてください。
Since BAP packets help determine the amount of bandwidth available to an implementation, PPP SHOULD give them priority over other data packets when transmitting. This will help insure the prompt addition and removal of links in a multilink bundle. This is especially important when adding links to a bundle due to bandwidth constraints.
BAPパケットが、実現に利用可能な帯域幅の量を測定するのを助けるので、伝わるとき、PPP SHOULDは他のデータ・パケットにそれらを優先させます。 これは、マルチリンクバンドルにおける、リンクの迅速な添加と取り外しを保障するのを助けるでしょう。 帯域幅規制のためバンドルにリンクを加えるとき、これは特に重要です。
5.4. Race Conditions
5.4. 競合条件
In order to resolve race conditions, an implementation MUST implement the BACP Favored-Peer Configuration Option.
競合条件を決議するために、実現はBACP Favored-同輩Configuration Optionを実行しなければなりません。
A race condition can occur if both implementations send a Call- Request, Callback-Request or Link-Drop-Query-Request at the same time. These race conditions should be solved as follows:
両方の実現が同時にCall要求、Callback-要求またはLink低下質問要求を送るなら、競合条件は起こることができます。 これらの競合条件は以下の通り解決されるべきです:
If each implementation sends a Call-Request or Callback-Request at
the same time, the implementation with the lowest BACP Favored-
Peer Magic-Number value SHOULD be favored.
各実現が同時にCall-要求かCallback-要求を送るなら、最も低いBACP Favored同輩マジック数の値のSHOULDが支持されている状態で、実現します。
If each implementation sends a Link-Drop-Query-Request at the same
time, the same scheme SHOULD be used as for Call-Requests.
各実現がLinkが同時に質問要求が低下していて、同じ計画SHOULDを送るなら、Call-要求のように、使用されてください。
5.5. BAP Datagram Format
5.5. BAPデータグラム形式
Description
記述
Before any BAP packets may be communicated, PPP MUST reach the
Network-Layer Protocol phase, and BACP MUST reach the opened
state.
どんなBAPパケットも伝えられるかもしれない前に、PPP MUSTはNetwork-層のプロトコルフェーズに達します、そして、BACP MUSTは開かれた状態に達します。
Exactly one BAP packet is encapsulated in the Information field of
PPP Data Link Layer frames where the Protocol field indicates type
hex c02d (Bandwidth Allocation Protocol).
ちょうど1つのBAPパケットがプロトコル分野がタイプ十六進法c02d(帯域幅Allocationプロトコル)を示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。
Because ISDN Terminal Adapters sometimes are used to do multilink
with a non-multilink aware client, BAP datagrams MUST NOT be
compressed or encrypted. Otherwise, the ISDN TA may not be able
to properly intercept BAP datagrams needed to control the
multilink connection. This refers to compression of the whole
datagram; Address-and-Control-Field-Compression and Protocol-
Field-Compression are allowed if properly negotiated.
ISDNティーエーが非マルチリンクの意識しているクライアントと共にマルチリンクをするのに時々使用されるので、BAPデータグラムを、圧縮されてはいけないか、コード化してはいけません。 さもなければ、ISDN TAは適切にマルチリンク接続を監督するのに必要であるBAPデータグラムを妨害できないかもしれません。 これは全体のデータグラムの圧縮を示します。 プロトコル分野圧縮は、アドレスとコントロールは圧縮をさばいて、許容されますが、適切に交渉されています。
Richards & Smith Standards Track [Page 9] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[9ページ]。
The maximum length of a BAP packet transmitted over a PPP link is
the same as the maximum length of the Information field of a PPP
data link layer frame.
PPPリンクの上に伝えられたBAPパケットの最大の長さはPPPデータ・リンク層フレームの情報分野の最大の長さと同じです。
Bandwidth Allocation Protocol datagrams can be catagorized as
either Request, Indication or Response packets. Every Request and
Indication datagram has a corresponding Response packet. Request
and Indication datagrams have a slightly different format from
Response datagrams, as the Response datagrams include a Response
Code octet.
Request、IndicationかResponseパケットのどちらかとして帯域幅Allocationプロトコルデータグラムをcatagorizedされることができます。 あらゆるRequestとIndicationデータグラムには、対応するResponseパケットがあります。 要求とIndicationデータグラムには、Responseデータグラムからのわずかに異なった形式があります、ResponseデータグラムがResponse Code八重奏を含んでいるとき。
All of the BAP datagrams MUST be supported by an implementation.
However, that does not mean an implementation must support all BAP
datagram actions. An implementation MAY send a Request-Rej to a
Request that it does not implement.
実現でBAPデータグラムのすべてを支持しなければなりません。 しかしながら、それは、実現がすべてのBAPデータグラム動作を支持しなければならないことを意味しません。 Request-レイは実現でそれが実行しないRequestに行くかもしれません。
A summary of the Bandwidth Allocation Protocol datagram Request and Indication packet format is shown below. The fields are transmitted from left to right.
RequestとIndicationパケットがフォーマットするBandwidth Allocationプロトコルデータグラムの概要は以下に示されます。 野原は左から右まで伝えられます。
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 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+-+-+-+-+
A summary of the Bandwidth Allocation Protocol datagram Response packet format is shown below. The fields are transmitted from left to right.
Bandwidth AllocationプロトコルデータグラムResponseパケット・フォーマットの概要は以下に示されます。 野原は左から右まで伝えられます。
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 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Code | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
The Type field is one octet and identifies the type of BAP
datagram packet. Datagram types are defined as follows. This
field is coded in binary coded hexadecimal.
Type分野は、1つの八重奏であり、BAPデータグラムパケットのタイプを特定します。 データグラムタイプは以下の通り定義されます。 この分野は2進のコード化された16進でコード化されます。
Richards & Smith Standards Track [Page 10] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[10ページ]。
01 Call-Request
02 Call-Response
03 Callback-Request
04 Callback-Response
05 Link-Drop-Query-Request
06 Link-Drop-Query-Response
07 Call-Status-Indication
08 Call-Status-Response
01 発呼要求02呼び出し応答03回収要求04回収応答05リンク低下質問要求06リンク低下質問応答07呼び出し状態指示08呼び出し状態応答
The various types of BAP datagrams are explained in the following
sections.
様々なタイプのBAPデータグラムは以下のセクションで説明されます。
Identifier
識別子
The Identifier field is one octet and is binary coded. It aids in
matching Requests and Indications with Responses. Call-Status-
Indication packets MUST use the same Identifier as was used by the
original Call-Request or Callback-Request that was used to
initiate the call. All other Request or Indication packets MUST
use a unique Identifier for each new Request or Indication. All
Response packets MUST use the same Identifier as the Identifier in
the Request or Indication packet being responded to. When re-
transmitting a request or indication, the Identifier MUST be the
same as the Identifier used on the previous transmission of the
request or indication.
Identifier分野は、1つの八重奏であり、コード化されていた状態で2進です。 それはRequestsとIndicationsをResponsesに合わせる際に支援されます。 パケットが同じIdentifierを使用しなければならない呼び出し状態指示は呼び出しを開始するのに使用されたオリジナルのCall-要求かCallback-要求で使用されました。 他のすべてのRequestかIndicationパケットが各新しいRequestかIndicationにユニークなIdentifierを使用しなければなりません。 すべてのResponseパケットが応じるRequestかIndicationパケットでIdentifierと同じIdentifierを使用しなければなりません。 要求か指示を再伝えるとき、Identifierは要求か指示の前の送信のときに使用されたIdentifierと同じであるに違いありません。
Length
長さ
The Length field is two octets and indicates the length of the
packet including the Type, Identifier, Length and Options fields.
It is binary encoded. Octets outside the range of the Length field
should be treated as Data Link Layer padding and should be ignored
on reception.
Length分野は、2つの八重奏であり、Type、Identifier、Length、およびOptions分野を含むパケットの長さを示します。 それはコード化されていた状態で2進です。 Data Link Layerがそっと歩いて、レセプションで無視されるべきであるとき、Length分野の範囲の外での八重奏は扱われるべきです。
Response Code
応答コード
The Response Code is only present in Response datagrams. It is
binary coded and can have the following values:
Response Codeは単にResponseデータグラムに存在しています。コード化されていた状態で2進であり、以下の値を持つことができます:
00000000 Request-Ack
00000001 Request-Nak
00000010 Request-Rej
00000011 Request-Full-Nak
00000000要求-Ack00000001要求-Nak00000010Requestレイ00000011、完全なNakを要求してください。
The Request-Ack Response Code is sent to indicate that the Request
or Indication command is valid and was successfully received by an
implementation. The Request-Nak Response Code is sent to indicate
that the Request command was received, but an implementation does
Request-Ack Response CodeをRequestかIndicationコマンドが有効であることを示すために送って、実現で首尾よく受け取りました。 Requestコマンドが受け取られたのを示すためにRequest-Nak Response Codeを送りますが、実現はします。
Richards & Smith Standards Track [Page 11] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[11ページ]。
not want the requested action performed at this time. If a
Response containing a Request-Nak Response Code is received, the
original Request MAY be retried after an implementation determines
that sufficient time has elapsed. The Request-Rej Response Code
is sent to indicate that the Request command received by an
implementation is not implemented (i.e., if reception of a
particular request type is not supported by the peer.) The
Request-Full-Nak Response Code is sent to indicate that the
Request command was received, but an implementation does not want
the requested action performed. The Request-Full-Nak is used to
indicate that an implementation has reached the maximum (for a
Call- or Callback-Request) or the minimum (for a Link-Drop-Query-
Request) bandwidth configured or available for this multilink
bundle. If a Response containing a Request-Full-Nak Response Code
is received, the original Request SHOULD NOT be retried until the
total bandwidth of the multilink bundle has changed.
このとき要求された動作を実行して欲しくはありません。 Request-Nak Response Codeを含むResponseが受け取られているなら、実現が、十分な時間が経過したことを決定した後にオリジナルのRequestは再試行されるかもしれません。 実現で受け取られたRequestコマンドが実行されないのを示すためにRequest-レイResponse Codeを送ります(すなわち、特定の要求タイプのレセプションが同輩が支持されないなら)。 Requestコマンドを受け取りましたが、実現は要求された動作を実行するのを必要でないのを示すためにRequestの完全なNak Response Codeを送ります。 Requestの完全なNakは、実現が最大(CallかCallback-要求のための)かこのマルチリンクバンドルに構成されたか利用可能な最小(Link-低下質問要求のための)の帯域幅に達したのを示すのに使用されます。 Requestの完全なNak Response Codeを含むのはResponseであるなら受け取られています、オリジナルのRequest SHOULD。マルチリンクバンドルの合計帯域幅が変化するまで、再試行されないでください。
Data
データ
The Data field is variable in length, and will usually contain the
list of zero or more BAP Options that the sender desires to
transmit. The format of BAP Options is described in a later
chapter.
Data分野は、長さで可変であり、通常、ゼロのリストか送付者が伝えることを望んでいるより多くのBAP Optionsを含むでしょう。 BAP Optionsの形式は後の章で説明されます。
5.5.1. Call-Request
5.5.1. 発呼要求
Before originating a call to add another link to a multilink bundle, an implementation MUST transmit a Call-Request packet. This will inform the receiver of the request to add another link to the bundle and give the receiver a chance to inform the implementation of the phone number of a free port that can be called.
マルチリンクバンドルに別のリンクを加えるという要求を溯源する前に、実現はCall-リクエスト・パケットを伝えなければなりません。 これは、別のリンクをバンドルに加えるという要求の受信機を知らせて、呼ぶことができる自由港の電話番号の実現を知らせる機会を受信機に与えるでしょう。
The options field MUST include the Link-Type option. The options field MAY include the No-Phone-Number and/or the Reason options.
オプション分野はLink-タイプオプションを含まなければなりません。 オプション分野はいいえ電話番号、そして/または、Reasonオプションを含むかもしれません。
Upon reception of a Call-Request, a Call-Response datagram MUST be transmitted.
Call-要求のレセプションでは、Call-応答データグラムを送らなければなりません。
5.5.2. Call-Response
5.5.2. 呼び出し応答
An implementation MUST transmit a Call-Response datagram in response to a received Call-Request datagram. If the Call-Request is acceptable, the Call-Response MUST have a Response Code of Request- Ack. The Phone-Delta option MUST be included in a Call-Response packet with a Response Code of Request-Ack unless the Call-Request included the No-Phone-Number option. The options field MAY include the Reason and/or Link-Type options.
実現は容認されたCall-要求データグラムに対応してCall-応答データグラムを送らなければなりません。 Call-要求が許容できるなら、Call-応答には、Request- AckのResponse Codeがなければなりません。 Call-要求が電話番号がないオプションを含んでいなかったなら、Request-AckのResponse Codeと共にCall-応答パケットに電話デルタのオプションを含まなければなりません。 オプション分野はReason、そして/または、Link-タイプオプションを含むかもしれません。
Richards & Smith Standards Track [Page 12] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[12ページ]。
5.5.3. Callback-Request
5.5.3. 回収要求
An implementation that wants its peer to originate another link to add to the multilink bundle MUST transmit a Callback-Request packet to its peer. This will inform the receiver of the request to add another link to the bundle along with the number to be called.
同輩がマルチリンクバンドルに加えるために別のリンクを溯源する必要がある実現はCallback-リクエスト・パケットを同輩に伝えなければなりません。 これは、呼ばれるために数に伴うバンドルへの別のリンクを加えるという要求の受信機を知らせるでしょう。
The options field MUST include the Link-Type and Phone-Delta options. The Reason option MAY also be included.
オプション分野はLink-タイプと電話デルタのオプションを含まなければなりません。 また、Reasonオプションは含まれるかもしれません。
Upon reception of a Callback-Request, a Callback-Response datagram MUST be transmitted.
Callback-要求のレセプションでは、Callback-応答データグラムを送らなければなりません。
5.5.4. Callback-Response
5.5.4. 回収応答
An implementation MUST transmit a Callback-Response datagram in response to a received Callback-Request datagram. If the Callback- Request is acceptable, the Callback-Response MUST have a Response Code of Request-Ack. A Callback-Response packet MAY include the Link-Type option.
実現は容認されたCallback-要求データグラムに対応してCallback-応答データグラムを送らなければなりません。 Callback要求が許容できるなら、Callback-応答には、Request-AckのResponse Codeがなければなりません。 Callback-応答パケットはLink-タイプオプションを含むかもしれません。
5.5.5. Link-Drop-Query-Request
5.5.5. リンク低下質問要求
An implementation that determines that a link is no longer needed and wishes to negotiate dropping it (e.g., based on a throughput BOD decision), MUST transmit a Link-Drop-Query-Request packet. The options field MUST include the Link-Discriminator option (containing the receiver's Link-Discriminator), and MAY include the Reason option.
リンクはもう必要でないことを決定して、交渉したがっている実現は、それ(例えば、スループットBOD決定に基づいている)を落として、Link低下質問リクエスト・パケットを伝えなければなりません。 オプション分野は、Link-弁別器オプション(受信機のLink-弁別器を含んでいる)を含まなければならなくて、Reasonオプションを含むかもしれません。
Upon reception of a Link-Drop-Query-Request, an implementation MUST transmit a Link-Drop-Query-Response datagram. The Response-Code will be Request-Ack if it agrees to drop the link; if it does not agree to drop the link the Response-Code will be Request-Nak or Request-Full- Nak. After the receipt of a Link-Drop-Query-Response with a Response Code of Request-Ack, the transmitter of the Link-Drop-Query-Request MUST initiate tear down of the indicated link by sending an LCP Terminate-Request packet on the designated link.
Link低下質問要求のレセプションでは、実現はLinkが質問応答が低下しているデータグラムを送らなければなりません。 リンクを落とすのに同意するなら、Response-コードはRequest-Ackになるでしょう。 リンクを落とすのに同意しないと、Response-コードはRequest-NakかRequest完全なNakになるでしょう。 Request-AckのResponse CodeとのLink低下質問応答の領収書の後に、Link低下質問要求の送信機は示されたリンクでLCP Terminate-リクエスト・パケットを指定されたリンクに送ることによって下がっている裂け目を開始しなければなりません。
5.5.6. Link-Drop-Query-Response
5.5.6. リンク低下質問応答
An implementation transmits a Link-Drop-Query-Response datagram in response to a received Link-Drop-Query-Request datagram. If the implementation agrees (e.g., based on its throughput BOD algorithm) to reduce the bandwidth of the multilink bundle, then the Response Code MUST be set to Request-Ack.
実現は容認されたLink低下質問要求データグラムに対応してLinkが質問応答が低下しているデータグラムを送ります。 実現が、マルチリンクバンドルの帯域幅を減少させるのに同意するなら(例えば、スループットBODアルゴリズムに基づいています)、Response CodeはRequest-Ackに用意ができなければなりません。
Richards & Smith Standards Track [Page 13] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[13ページ]。
The Reason option MAY be included in the Link-Drop-Query-Response packet.
ReasonオプションはLinkが質問応答が低下しているパケットに含まれるかもしれません。
The Link-Drop-Query-Request datagram MUST be supported, as well as the underlying implementation to respond to it. This means that a Link-Drop-Query-Response with a Response Code of Request-Rej MUST NOT be transmitted in response to a Link-Drop-Query-Request.
基本的な実現と同様にそれに応じるためにLink低下質問要求データグラムを支えなければなりません。 これは、Link低下質問要求に対応してRequest-レイのResponse CodeとのLink低下質問応答を伝えてはいけないことを意味します。
5.5.7. Call-Status-Indication
5.5.7. 指示に状態に電話をしてください。
After an implementation attempts to add a link to a bundle as the result of a Call-Request or a Callback-Request, it MUST send a Call- Status-Indication packet to its peer to indicate if the attempt to add the link succeeded or failed. One Indication MUST be sent for each attempt made. For each Call-Status-Indication packet transmitted with the Call-Status Option Action octet set to Retry, a subsequent Call-Status-Indication packet MUST be sent to indicate the success or failure of the retry. The Call-Status option MUST be included to inform the receiver of the status of the attempt to add a link and the action the implementation will take in case of failure. The reason option MAY also be included in the Call-Status-Indication packet.
実現が、Call-要求かCallback-要求の結果としてバンドルにリンクを加えるのを試みた後に、それは、リンクを加える試みが成功したか、または失敗したかを示すためにCall状態指示パケットを同輩に送らなければなりません。 された各試みのために1Indicationを送らなければなりません。 Call-状態Option Action八重奏セットでRetryに伝えられたそれぞれのCall状態指示パケットに関しては、再試行の成否を示すためにその後のCall状態指示パケットを送らなければなりません。 リンクを加える試みと実現が失敗の場合に取る行動の状態の受信機を知らせるためにCall-状態オプションを含まなければなりません。 また、理由オプションはCall状態指示パケットに含まれるかもしれません。
Upon reception of a Call-Status-Indication packet which indicates a failure, an implementation may log the failure and reason code. Upon reception of any Call-Status-Indication packet, a Call-Status- Response datagram MUST be transmitted.
失敗を示すCall状態指示パケットのレセプションでは、実現は失敗と理由コードを登録するかもしれません。 どんなCall状態指示パケット、データグラムがそうしなければならないCall-状態応答のレセプションではも、伝えられてください。
5.5.8. Call-Status-Response
5.5.8. 応答に状態に電話をしてください。
An implementation transmits a Call-Status-Response datagram in response to a received Call-Status-Indication datagram. The Response Code field MUST be set to Request-Ack in this packet. The Reason option MAY be included in this packet.
実現は容認されたCall状態指示データグラムに対応してCall状態応答データグラムを送ります。 このパケットにResponse Code分野をRequest-Ackに設定しなければなりません。 Reasonオプションはこのパケットに含まれるかもしれません。
6. BAP Datagram Options
6. BAPデータグラムオプション
BAP Datagram Options are used in various BAP packets. Their use in various packets is as defined below. The format of these options loosely follows the formatting conventions of LCP Configuration Options. When there are multiple BAP Options in one BAP packet, the options MAY be transmitted in any order.
BAPデータグラムOptionsは様々なBAPパケットで使用されます。 以下で定義されるとして様々なパケットにおける彼らの使用があります。 これらのオプションの形式は緩くLCP Configuration Optionsの形式コンベンションに続きます。 複数のBAP Optionsが1つのBAPパケットにあるとき、オプションは順不同に伝えられるかもしれません。
Richards & Smith Standards Track [Page 14] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[14ページ]。
A summary of the BAP Option format is shown below. The fields are transmitted from left to right.
BAP Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
The type field is one octet, and indicates the type of the BAP
Datagram Option. This field is binary coded Hexadecimal. The
following options are currently defined:
タイプ分野は、1つの八重奏であり、BAPデータグラムOptionのタイプを示します。 この分野は2進のコード化されたHexadecimalです。 以下のオプションは現在、定義されます:
01 Link-Type
02 Phone-Delta
03 No-Phone-Number-Needed
04 Reason
05 Link-Discriminator
06 Call-Status
01 リンク型02電話デルタ03数が必要としなかった電話全く04理由05リンク弁別器06呼び出し状態
Length
長さ
The Length field is one octet, and indicates the length of this
BAP Option including the Type, Length, and Data fields.
Length分野は、1つの八重奏であり、Type、Length、およびData分野を含むこのBAP Optionの長さを示します。
Data
データ
The Data field is zero or more octets, and contains information
specific to the BAP Option. The format and length of the Data
field is determined by the Type and Length fields.
Data分野は、ゼロか、より多くの八重奏であり、BAP Optionに特定の情報を含んでいます。 Data分野の形式と長さはTypeとLength分野のそばで決定しています。
6.1. Link-Type
6.1. リンク型
Description
記述
This option indicates the general type of link indicated for the
operation being performed. This option does not indicate a
specific link type, rather it gives some general characteristics
of the desired link type. This option MAY be used along with
other knowledge (i.e., the type of the other link(s) in the bundle
or user configuration) to determine the type of link desired to be
used in the operation. It MUST be included in a Call- or
Callback-Request, and MAY be included in a Call- or Callback-
Response.
このオプションは実行される操作のために示されたリンクの一般型を示します。 このオプションは特定のリンク型を示さないで、むしろそれは必要なリンク型のいくつかの一般的特色を与えます。 このオプションは、リンクのタイプが、操作に使用されることを望んでいたことを決定するのに他の知識(すなわち、バンドルかユーザ構成の他のリンクのタイプ)と共に使用されるかもしれません。 それは、CallかCallback-要求に含まなければならなくて、CallかCallback応答に含まれるかもしれません。
Richards & Smith Standards Track [Page 15] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[15ページ]。
A summary of the Link-Type BAP Option format is shown below. The fields are transmitted from left to right.
Link-タイプBAP 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 | Length | Link Speed (kbps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Type |
+-+-+-+-+-+-+-+-+
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
タイプ
01 for Link-Type.
01 リンク型のために。
Length
長さ
The Length field is one octet, and indicates the length of this
BAP Option including the Type, Length and Link Type fields.
Length分野は、1つの八重奏であり、Type、Length、およびLink Type分野を含むこのBAP Optionの長さを示します。
Link Speed
リンク速度
The Link Speed field is 2 octets, and indicates the requested
speed of the desired link in kilobits per second. This field is
coded as 2 binary coded hexadecimal octets, with the most
significant octet sent first.
Link Speed分野は、2つの八重奏であり、1秒あたりのキロビットにおける、必要なリンクの要求された速度を示します。 2バイナリーが最初に最も重要な八重奏を送って16進八重奏をコード化したので、この分野はコード化されます。
Link Type
リンク型
The Link Type field is a bit mask. It is 1 octet in length. Bit
0 of the Link Type field corresponds to bit 39 of the Link-Type
BAP Option as described above. If a bit is set, it indicates
support of the corresponding link type. If the link indicated is
different than the supported link types, no bit will be set.
Otherwise, at least one bit MUST be set. If an implementation
supports more than one link type, more than one bit MAY be set.
Link Type分野はしばらくマスクです。 それは長さが1つの八重奏です。 Link Type分野のビット0は上で説明されるようにLink-タイプBAP Optionのビット39に対応しています。 しばらくが決められるなら、それは対応するリンク型のサポートを示します。 示されたリンクが支持されたリンク型と異なると、ビットは全く設定されないでしょう。 さもなければ、少なくとも1ビットを設定しなければなりません。 実現が1人以上のリンク型を支持するなら、1ビット以上は設定されるかもしれません。
Bit Link type
--- -------------
0 ISDN
1 X.25
2 analog
3 switched digital (non-ISDN)
4 ISDN data over voice
5-7 reserved
ビットLinkはタイプします。--- ------------- 0 ISDN1X.25 2のアナログの3は4つのデジタル(非ISDNの)のISDNデータを5-7が控えた声の上に切り換えました。
If the Length field contains more bits than are defined by this
specification, then any bits that are not defined should be
Length分野がこの仕様で定義されるより多くのビットを含んでいるなら、定義されないどんなビットもそうであるべきです。
Richards & Smith Standards Track [Page 16] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[16ページ]。
ignored. In order to allow for future expansion of this field, it
is important to properly support receiving a Link Type field
longer than what is defined by this specification. If the Length
field is shorter than the number of bits defined, then the
implementation should set all bits not received to 0.
無視にされる。 この分野の今後の拡大を考慮するために、この仕様で定義されることより長い間Link Type野原を受けるのを適切に支持するのは重要です。 Length分野がビットの数が定義したより短いなら、実現は0に受け取られなかったすべてのビットを設定するべきです。
6.2. Phone-Delta
6.2. 電話デルタ
Description
記述
The BAP Phone-Delta Option is used by an implementation to give
its peer the information needed to make a call. Due to the
difficulty of determining which dialing prefixes (if any) are
necessary to dial a given phone number/national destination
code/country code combination, the phone number to be dialed will
be based on a previously known number. This MAY be the original
number used to establish the first link of the multilink bundle, a
number configured by the user, the phone number used to make a
callback connection, or a number determined in some other way.
The Phone-Delta Option will consist of a Subscriber-Number Sub-
Option along with a Unique-Digits Sub-Option that indicates how
many of the digits of the Subscriber-Number are unique among the
ports in use, previously used, and to be used in the multilink
bundle. There is also an optional Phone-Number-Sub-Address Sub-
Option.
BAP電話Optionデルタは、情報が作る必要があった同輩に呼び出しを与えるのに実現で使用されます。 どのダイヤルする接頭語(もしあれば)が与えられた電話番号/国家の目的地コード/国名略号組み合わせにダイヤルするのに必要であるかを決定するという困難のため、ダイヤルされるべき電話番号は以前に知られている数に基づくでしょう。 これはマルチリンクバンドルの最初のリンクを証明するのに使用される元の数であるかもしれません、とユーザ、回収接続を作るのに使用される電話番号、またはある他の方法で決定している数に従って、数が構成しました。 電話OptionデルタはSubがSubscriber-数のケタのいくつが以前に使用された使用中のポートの中でユニークであるかを示すUnique-ケタSub-オプションと共にゆだねるSubscriber-数から成るでしょう、そして、マルチリンクに使用されるのは荷物をまとめます。 また、任意の電話番号サブAddress Subのオプションがあります。
An implementation MAY include more than one Phone-Delta option in
a response. This indicates that there is more than one phone
number that can be used for the requested operation. The Phone-
Delta option MUST appear in a Callback-Request. It also MUST
appear in a Call-Response with a Response Code set to Request-Ack
if the Call-Request did not contain the No-Phone-Number option.
It MAY be included in the Call-Status-Indication packet.
実現は応答における1つ以上の電話デルタのオプションを含むかもしれません。 これは、要求された操作に使用できる1つ以上の電話番号があるのを示します。 電話デルタオプションはCallback-要求に現れなければなりません。 また、Call-要求が電話番号がないオプションを含まなかったなら、それはResponse CodeセットによるCall-応答にRequest-Ackにおいて現れなければなりません。 それはCall状態指示パケットに含まれるかもしれません。
A summary of the Phone-Delta BAP Option format is shown below. The fields are transmitted from left to right.
電話デルタBAP 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 | Length |Sub-Option Type| Sub-Option Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ|サブオプションタイプ| サブOptionレン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブオプション… +-+-+-+-+-+-+-+-+
Type
タイプ
02 for Phone-Delta.
02 電話デルタのために。
Richards & Smith Standards Track [Page 17] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[17ページ]。
Length
長さ
The Length field is one octet, and indicates the length of this
BAP Option including the Type, Length, and Sub-Option fields.
Length分野は、1つの八重奏であり、Type、Length、およびSub-オプション・フィールドを含むこのBAP Optionの長さを示します。
Sub-Option Type
サブオプションタイプ
The following Sub-Option Types are defined for the Phone-Delta
option.
以下のSub-オプションTypesは電話デルタのオプションのために定義されます。
01 Unique-Digits
02 Subscriber-Number
03 Phone-Number-Sub-Address
01 ユニークなケタ02加入者番号03電話数のサブアドレス
Sub-Option Length
サブオプションの長さ
The Sub-Option Length field is one octet, and indicates the length
of this BAP Sub-Option including the Sub-Option Type, Sub-Option
Length, and Sub-Option fields.
Sub-オプションLength分野は、1つの八重奏であり、Sub-オプションType、Sub-オプションLength、およびSub-オプション・フィールドを含んでいて、このBAP Sub-オプションの長さを示します。
6.2.1. Phone-Delta Sub-Options
6.2.1. 電話デルタサブオプション
Unique-Digits
ユニークなケタ
The Unique-Digits Sub-Option field consists of one octet that is a
count of the number of rightmost digits of the Subscriber-Number
that are different from the set of phone numbers of the ports used
in this multilink connection. (For example, if the first port of
a multilink bundle has a phone number of 123456789, and an
implementation wanted its peer to call a port with a phone number
of 123456888, the Unique-Digits octet would be 3.) If the Phone-
Number-Sub-Address Sub-Option is present, the Unique-Digits Sub-
Option MUST NOT include any of the Sub Address digits in its count
of different rightmost digits.
Unique-ケタSub-オプション・フィールドはこのマルチリンク接続に使用されるポートの電話番号のセットと異なったSubscriber-数の一番右のケタの数のカウントである1つの八重奏から成ります。 (例えば、マルチリンクバンドルの最初のポートには123456789の電話番号があって、実現が、同輩が123456888の電話番号でポートを呼ぶ必要があるなら、Unique-ケタ八重奏は3でしょうに。) 電話の数のサブAddress Subのオプションが存在しているなら、SubオプションがカウントにおけるSub Addressケタのいずれも含んではいけないUnique-ケタ異なった一番右のケタです。
This field is required.
この分野が必要です。
Subscriber-Number
加入者番号
This field is the phone number of the port that should be called
by the peer. Any digits that precede the rightmost unique digits
of the Subscriber-Number are provided for informational purposes
only, and do not need to be included in this field. This field is
an ASCII string and MUST contain only ASCII characters indicating
valid phone number digits. This field is required.
この分野は同輩によって呼ばれるべきであるポートの電話番号です。 Subscriber-数の一番右のユニークなケタに先行するどんなケタも、情報の目的だけに前提とされて、この分野に含まれる必要はありません。 この分野は、ASCIIストリングであり、有効な電話番号ケタを示すASCII文字だけを含まなければなりません。 この分野が必要です。
Richards & Smith Standards Track [Page 18] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[18ページ]。
Phone-Number-Sub-Address
数のサブアドレスに電話をしてください。
This field is the sub address of the port to be called by the
peer. This sub-option SHOULD only be used for an ISDN call. This
field is an ASCII string and only contains valid phone number
digits. This field is optional.
この分野は同輩によって呼ばれるポートの潜水艦アドレスです。 このサブオプションSHOULD、ISDN呼び出しに単に使用されてください。 この分野は、ASCIIストリングであり、有効な電話番号ケタを含むだけです。 この分野は任意です。
6.3. No-Phone-Number-Needed
6.3. 数が必要としなかった電話全く
Description
記述
The No-Phone-Number option indicates that the calling
implementation is already configured with the phone number of its
multilink peer and the answering implementation MUST NOT include
the Phone Number option in the response. This may be for security
reasons, for configuration reasons, or for any other reason.
電話番号がないオプションは、呼ぶ実現がマルチリンク同輩の電話番号によって既に構成されるのを示します、そして、回答実現は応答における電話Numberオプションを含んではいけません。 これは安全保障上の理由で、構成理由、またはいかなる他の理由でもあるかもしれません。
This option MAY be used in a Call-Request packet.
このオプションはCall-リクエスト・パケットで使用されるかもしれません。
A summary of the No-Phone-Number BAP Option format is shown below. The fields are transmitted from left to right.
電話番号がないBAP Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
03 for No-Phone-Number.
03 どんな電話番号のためにも、そうしません。
Length
長さ
2
2
Richards & Smith Standards Track [Page 19] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[19ページ]。
6.4. Reason
6.4. 理由
Description
記述
This option is used to indicate a reason for the Request or
Response. It is meant to be used for informational purposes only.
This option MAY be used in any BAP packet.
このオプションは、RequestかResponseの理由を示すのに使用されます。 それは情報の目的だけに使用されることになっています。 このオプションはどんなBAPパケットでも使用されるかもしれません。
A summary of the Reason BAP Option format is shown below. The fields are transmitted from left to right.
Reason BAP 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 | Length | Reason String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
04 for Reason.
04 理由で。
Length
長さ
The Length field is one octet, and indicates the length of this
BAP Option including the Type, Length and Reason String fields.
Length分野は、1つの八重奏であり、Type、Length、およびReason String分野を含むこのBAP Optionの長さを示します。
Reason String
理由ストリング
This is an ASCII string. The content of the field is
implementation dependent. An implementation MAY ignore the Reason
String field.
これはASCIIストリングです。 分野の内容は実現に依存しています。 実現はReason String分野を無視するかもしれません。
Richards & Smith Standards Track [Page 20] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[20ページ]。
6.5. Link-Discriminator
6.5. リンク弁別器
Description
記述
The Link-Discriminator option MUST be used in a Link-Drop-Query-
Request datagram. This option is used to inform the receiver of a
Link-Drop-Query-Request of which link will be dropped.
Link質問要求を落としているデータグラムでLink-弁別器オプションを使用しなければなりません。 このオプションは、どのリンクが落とされるかに関するLink低下質問要求の受信機を知らせるのに使用されます。
A summary of the Link-Discriminator BAP Option format is shown below. The fields are transmitted from left to right.
Link-弁別器BAP 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 | Length | Link Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
05 for Link-Discriminator
05 リンク弁別器のために
Length
長さ
4
4
Link Discriminator
リンク弁別器
The Link Discriminator field is 2 octets in length. It contains
the Link Discriminator that was contained in the LCP Link-
Discriminator Configuration Option sent by the receiver of the
packet containing the Link Discriminator.
Link Discriminator分野は長さが2つの八重奏です。 それはLink Discriminatorを含んでいて、パケットの受信機によって送られたLCP Link弁別器Configuration Optionに含まれたLink Discriminatorを含んでいます。
6.6. Call-Status
6.6. 呼び出し状態
Description
記述
The Call-Status option MUST be used in a Call-Status-Indication
datagram. This option is used to inform the receiver of the
Call-Status-Indication datagram of the status of the completed
call attempt, as well as a possible action that will be taken (if
the call failed).
Call状態指示データグラムでCall-状態オプションを使用しなければなりません。 このオプションは完了呼試みの状態のCall状態指示データグラムの受信機を知らせるのに使用されます、取られる可能な行動と同様に(呼び出しが失敗したなら)。
Richards & Smith Standards Track [Page 21] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[21ページ]。
A summary of the Call-Status BAP Option format is shown below. The fields are transmitted from left to right.
Call-状態BAP 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 | Length | Status | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
06 for Call-Status.
06 呼び出し状態に。
Length
長さ
4
4
Status
状態
The Status field is 1 octet in length. If the call was
successful, the value MUST be set to 0. A non-zero value
indicates a call failure. A value of 255 indicates a non-specific
failure, and a more specific call status MAY be indicated by using
the same number as the Q.931 cause value (i.e., 1 is unassigned
number, 17 is user busy, etc.)
Status分野は長さが1つの八重奏です。 呼び出しがうまくいったなら、0に値を設定しなければなりません。 非ゼロ値は呼び出し失敗を示します。 255の値は特定されない失敗を示します、そして、より特定の呼び出し状態は、Q.931原因価値と同じ数を使用することによって、示されるかもしれません。(数はすなわち、1に割り当てられないで、17はユーザ忙しいですなど)
Action
動作
The Action octet indicates what action the calling implementation is taking after a failed call. If the call was sucessful, the Action octet MUST be set to 0.
Action八重奏は、呼ぶ実現が失敗した呼び出しの後にどんな行動を取っているかを示します。 呼び出しがsucessfulだったなら、Action八重奏を0に設定しなければなりません。
The Action octet can have the following values:
Action八重奏は以下の値を持つことができます:
0 - No retry
1 - Retry
0(いいえ再試行1)は再試行されます。
Richards & Smith Standards Track [Page 22] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[22ページ]。
Appendix
付録
List of BAP datagrams and associated fields.
BAPデータグラムと関連分野のリスト。
datagram mandatory fields allowed options
-------- ----------------- ---------------
Call-Request Link-Type No-Phone-Number
Call-Response Phone-Delta
Link-Type
Callback-Request Link-Type
Phone-Delta
Callback-Response Link-Type
Link-Drop-Query-Request Link-Discriminator
Link-Drop-Query-Response
Call-Status-Indication Call-Status Phone-Delta
Call-Status-Response
データグラムの義務的な分野は選択を許しました。-------- ----------------- --------------- 発呼要求リンク型電話番号がない呼び出し応答電話デルタリンク型回収要求リンク型電話デルタ回収応答リンク型リンク低下質問要求リンク弁別器リンク低下質問応答呼び出し状態指示呼び出し状態電話デルタ呼び出し状態応答
The Reason option is allowed to be included with any BAP datagram.
ReasonオプションはどんなBAPデータグラムでも含むことができます。
History of BACP
BACPの歴史
The first version of BACP was written by Craig Richards of Shiva Corporation. This version was enhanced and improved by the MPCP Working Group, a collaborative effort of 3Com, Ascend, Bay Networks, Cisco, Microsoft, Shiva, US Robotics and Xylogics.
BACPの最初のバージョンはシバ神社のクレイグ・リチャーズによって書かれました。 このバージョンは、MPCP作業部会、3Comの共同努力、Ascend、ベイネットワークス、シスコ、マイクロソフト、シバ神、米国Robotics、およびXylogicsによって高められて、改良されました。
Acknowledgements
承認
Kevin Smith of Ascend for his contributions based on his work on the MP+ Specification. Gerry Meyer and Robert Myhill of Shiva for their early comments and improvements. Andy Nicholson of Microsoft for his improvements to the bandwidth management scheme. Dana Blair and Andy Valencia of Cisco, Cheng Chen and Dan Brennan of 3Com for their good ideas as part of the MPCP Working Group. All of the members of the MPCP working group for their ability to work with their competitors with enthusiasm to produce a better protocol for the industry.
MP+仕様に対する彼の仕事に基づく彼の貢献のためのAscendのケビン・スミス。 彼らの早めのコメントと改良のためのシバ神のゲリー・マイヤーとロバートMyhill。 帯域幅管理計画への彼の進歩のためのマイクロソフトのアンディ・ニコルソン。 MPCP作業部会の一部としてのそれらの名案のための3Comのシスコのダナ・ブレアとアンディ・バレンシア、チェン・チェン、およびダン・ブレナン。 産業のために、より良いプロトコルを作成するために熱意をもっている彼らの競争相手と共に働く彼らの能力のためのMPCPワーキンググループのメンバーのすべて。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Richards & Smith Standards Track [Page 23] RFC 2125 PPP BACP March 1997
リチャーズとスミスStandardsは1997年のppp BACP行進のときにRFC2125を追跡します[23ページ]。
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, Daydreamer, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、空想家、1994年7月。
[2] Sklower, Lloyd, McGregor, Carr & Coradetti, "The PPP Multilink
Protocol", RFC 1990, University of California, Berkeley, Lloyd
Internetworking, Newbridge Networks Corporation, Sidewalk
Software, August 1996.
[2] Sklower、ロイド、マクレガー、カー、およびCoradetti、「pppマルチリンクは議定書を作ります」、RFC1990、カリフォルニア大学バークレイ校ロイドInternetworking、ニューブリッジネットワークス社、歩道ソフトウェア、1996年8月。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。
(614)451-1883
(614)451-1883
EMail: karl@ascend.com
メール: karl@ascend.com
Editors' Addresses
エディタのアドレス
Craig Richards
Shiva Corporation
28 Crosby Drive
Bedford, MA 01730
VOICE +1 617 270 8419
FAX +1 617 270 8599
クレイグリチャーズシバ神社28のクロズビー・Driveベッドフォード、MA 01730が+1 8419年の617 270ファックス+1 617 270を声に出す、8599
EMail: crich@us.shiva.com
メール: crich@us.shiva.com
Kevin Smith
Ascend Communications, Inc.
1275 Harbor Bay Parkway
Alameda, CA 94501
CA
ケビン・スミスはコミュニケーションInc.1275港湾のParkwayカリフォルニア94501アラメダ(カリフォルニア)を昇ります。
EMail: kevin@ascend.com
メール: kevin@ascend.com
Richards & Smith Standards Track [Page 24]
リチャーズとスミス標準化過程[24ページ]
一覧
スポンサーリンク
