RFC1934 日本語訳
1934 Ascend's Multilink Protocol Plus (MP+). K. Smith. April 1996. (Format: TXT=87072 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Smith Request For Comments: 1934 Ascend Communications Category: Informational April 1996
コメントを求めるワーキンググループK.スミスの要求をネットワークでつないでください: 1934はコミュニケーションカテゴリを昇ります: 情報の1996年4月
Ascend's Multilink Protocol Plus (MP+)
上昇、そのうえ、マルチリンクプロトコルです。(MP+)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document proposes an extension to the PPP Multilink Protocol (MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP.
このドキュメントはPPP Multilinkプロトコル(MP)[1]に拡大を提案します。 マルチリンクプロトコルPlus(MP+)は、MPによって添付される複数のデータ・リンクを管理するための新しい制御プロトコルです。
Table Of Contents
目次
1. Introduction.................................................2
1.1 Functional Description...............................2
1.2 Conventions..........................................3
2. General Overview.............................................3
2.1 Operation............................................4
3. MP+ Frame Formats............................................4
3.1 Error Control (EC) Layer.............................6
3.1.1 Error Control State Machine..................7
3.2 Multilink Plus Control Messages......................9
3.3 Multilink Plus Message Formats......................10
3.3.1 VERSION_EXCHANGE_REQ Message Format.........10
3.3.2 VERSION_EXCHANGE_RSP Message Format.........12
3.3.3 ADD_REQ Message Format......................13
3.3.4 ADD_RSP Message Format......................15
3.3.5 ADD_COMPLETE Message Format.................16
3.3.6 REMOVE_REQ Message Format...................17
3.3.7 REMOVE_RSP Message Format...................17
3.3.8 REMOVE_COMPLETE Message Format..............18
3.3.9 CLOSE_REQ Message Format....................19
3.3.10 CLOSE_RSP Message Format....................19
3.3.11 REMOTE_MGMT_REQ Message Format..............20
3.3.12 REMOTE_MGMT_RSP Message Format..............20
3.3.13 REMOTE_MGMT_RX_REQ Message Format...........21
3.3.14 REMOTE_MGMT_TX_REQ Message Format...........22
3.3.15 REMOTE_MGMT_TX_RSP Message Format...........22
3.3.16 CLEAR_REQ Message Format....................23
3.4 Events..............................................23
1. 序論…2 1.1 機能的な記述…2 1.2のコンベンション…3 2. 概要…3 2.1操作…4 3. MP+フレーム形式…4 3.1誤り制御(EC)は層にされます…6 3.1 .1誤り制御州のマシン…7 3.2 マルチリンクプラスコントロールメッセージ…9 3.3 マルチリンクプラスメッセージ・フォーマット…10 3.3 .1バージョン_は_REQメッセージ・フォーマットを交換します…10 3.3 .2バージョン_は_RSPメッセージ・フォーマットを交換します…12 3.3 .3 _REQメッセージ・フォーマットを加えてください…13 3.3 .4 _RSPメッセージ・フォーマットを加えてください…15 3.3 .5 _完全なメッセージ・フォーマットを加えてください…16 3.3 .6 _REQメッセージ・フォーマットを取り除いてください…17 3.3 .7 _RSPメッセージ・フォーマットを取り除いてください…17 3.3 .8 _完全なメッセージ・フォーマットを取り除いてください…18 3.3 .9 _REQメッセージ・フォーマットを閉じてください…19 3.3 .10 _RSPメッセージ・フォーマットを閉じてください…19 3.3 .11 リモート_管理_REQメッセージ・フォーマット…20 3.3 .12 リモート_管理_RSPメッセージ・フォーマット…20 3.3 .13 リモート_管理_RX_REQメッセージ・フォーマット…21 3.3 .14 リモート_管理_テキサス_REQメッセージ・フォーマット…22 3.3 .15 リモート_管理_テキサス_RSPメッセージ・フォーマット…22 3.3 .16 _REQメッセージ・フォーマットをクリアしてください…23 3.4のイベント…23
Smith Informational [Page 1] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[1ページ]のRFC1934マルチリンクプロトコルと1996年4月
3.5 State Machine.......................................25
3.5.1 States......................................25
3.5.2 Common Actions..............................26
3.5.3 MP+STATE_INITIAL state machine..............32
3.5.4 MP+STATE_IDLE state machine.................35
3.5.5 MP+STATE_ADD state machine..................37
3.5.6 MP+STATE_REMOVE state machine...............41
3.5.7 MP+STATE_CLOSE state machine................44
4. PPP LCP Extensions..........................................46
5. Security Considerations.....................................47
6. References..................................................47
7. Author's Address............................................47
3.5 マシンを述べてください…25 3.5 .1 述べます。25 3.5 .2 一般的な動作…26 3.5 .3MP+州_INITIALはマシンを述べます…32 3.5 .4MP+州_IDLEはマシンを述べます…35 3.5 .5MP+州_ADDはマシンを述べます…37 3.5 .6MP+州_、削除、マシンを述べてください…41 3.5 .7MP+州_CLOSEはマシンを述べます…44 4. ppp LCP拡張子…46 5. セキュリティ問題…47 6. 参照…47 7. 作者のアドレス…47
1. Introduction
1. 序論
The PPP Multilink Protocol (MP), is a set of features that provide inverse multiplexing at the packet/fragment level by bundling multiple independent links between a fixed pair of systems, providing a virtual link with greater bandwidth than any of the constituent members.
PPP Multilinkプロトコル(MP)はパケット/断片レベルで固定組のシステムの間の複数の独立しているリンクを添付することによって逆さのマルチプレクシングを提供する1セットの特徴であり、提供は構成員のいずれよりも大きい帯域幅との仮想のリンクです。
Once multiple channels have been established MP is responsible for managing channel use to insure in-sequence delivery of user packets.
複数のチャンネルがいったん確立されると、MPは連続してユーザパケットの配送を保障するためにチャンネル使用を管理するのに責任があります。
MP+ is an extension to MP that adds an inband control channel to provide a new level of session management and control.
MP+は新しいレベルのセッション管理とコントロールを提供するために「不-バンド」制御チャンネルを加えるMPへの拡大です。
MP+ also allows remote device management of (unconfigured) systems. This feature allows a network operations center to dial into an unconfigured system and remotely manage it, before ethernet interface, IP address, and other LCP and system configuration information is entered. (This does require local configuration of the WAN interfaces to the extent required to answer an incoming call).
また+が(非構成しました)システムこの特徴の遠隔装置管理を許すMPは、ネットワーク操作センターに非構成されたシステムにダイヤルして、それを離れて管理させます、イーサネットインタフェース、IPアドレス、他のLCP、およびシステム構成情報が入力される前に。 (これは範囲へのインタフェースがかかってきた電話に答えるのを必要としたWANの地方の構成を必要とします。)
1.1 Functional Description
1.1 機能的な記述
The features of MP+ include:
MP+の特徴は:
* Ability to negotiate to add and subtract channels when bandwidth
needs change.
* 帯域幅であるときに、チャンネルを加減するのを交渉する能力は変化を必要とします。
* Phone number management so calling stations need not know every
possible number; answering stations can manage their own resources.
* したがって、呼んでいるステーションが必要とする電話番号経営者側はあらゆる可能な数を知っているというわけではありません。 応答局はそれら自身のリソースに対処できます。
* A simple remote management interface.
* 簡単なリモート管理は連結します。
Smith Informational [Page 2] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[2ページ]のRFC1934マルチリンクプロトコルと1996年4月
To perform the above functions MP+ is split into a call management layer and a reliable delivery layer. The call management layer is the source and sink of MP+ control messages. The reliable delivery layer adds a simple acknowledge and retry mechanism.
上の機能を実行するために、MP+は呼び出し管理層と信頼できる配信層に分けられます。 呼び出し管理層は、MP+コントロールメッセージのソースと流し台です。 信頼できる配信層は簡単な状態でaを加えます。メカニズムを承認して、再試行してください。
MP+ only takes network bandwidth when in the process of performing a user request, e.g. adding and subtracting bandwidth.
MP+はユーザ要求、例えば、付加を実行することの途中にネットワーク回線容量と引き帯域幅を取るだけです。
NOTE: Neither MP, or MP+ define the process that makes the bandwidth requirement determination. That is outside the scope of either of these protocols and will likely be implementation dependent.
以下に注意してください。 MPもMP+も帯域幅を要件決断にするプロセスを定義しません。 それは、これらのプロトコルのどちらかの範囲の外にあって、おそらく実装に依存するようになるでしょう。
1.2 Conventions
1.2 コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
MUST, SHALL or MANDATORY -- the item is an absolute requirement
of the specification.
SHALLかMANDATORY--項目は仕様に関する絶対条件であるに違いありません。
SHOULD or RECOMMENDED -- the item should generally be followed
for all but exceptional circumstances.
SHOULDかRECOMMENDED--一般に、商品はほとんど例外的な事情のために従われるべきです。
MAY or OPTIONAL -- the item is truly optional and may be followed
or ignored according to the needs of the implementor.
5月かOPTIONAL--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
2. General Overview
2. 概要
PPP
In order to establish communications over a point-to-point link,
each end of the PPP [2] 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.
ポイントツーポイント接続の上でコミュニケーションを確立するPPP In命令、PPP[2]リンクの各端は最初に、リンク確立段階の間、データ・リンクを構成するためにパケットをLCPに送らなければなりません。 リンクが設立された後に、PPPは認証フェーズに備えます。
MP The goal of multilink operation is to bundle multiple
independent links between a fixed pair of systems, providing a
virtual link with greater bandwidth than any of the constituent
members.
マルチリンク操作の目標が複数の独立者を添付することになっているMPは固定組のシステムの間でリンクします、構成員のいずれよりも大きい帯域幅を仮想のリンクに提供して。
MP+ MP+ is also negotiated during initial LCP option negotiation. A
system indicates to its peer that it is willing to do MP+ by
sending the MP+ option as part of the initial LCP option
negotiation. The MP+ option MUST NOT be negotiated unless MP is
also negotiated. When used, MP+ adds a virtual unit-to-unit
control channel.
また、MP+MP+は初期のLCPオプション交渉の間、交渉されます。 システムは、初期のLCPオプション交渉の一部としてMP+オプションを送ることによってMP+をしても構わないと思っているのを同輩に示します。 また、MPが交渉されない場合、MP+オプションを交渉してはいけません。 使用されると、+が、ユニット・コントロールへの仮想のユニットがチャネルを開設すると言い足すMPです。
A peer may elect to:
同輩は、以下のことを選ぶかもしれません。
Smith Informational [Page 3] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[3ページ]のRFC1934マルチリンクプロトコルと1996年4月
Acknowledge both the MP and MP+ options, indicating that both MP and MP+ will be used.
+がそうするMPとMPの両方が使用されるのを示して、MPとMP+オプションの両方を承諾してください。
Acknowledge the MP option and reject the MP+ option. Operation will fall back to MP.
MPオプションを承諾してください、そして、MP+オプションを拒絶してください。 操作はMPへ後ろへ下がるでしょう。
Reject both options. Standard PPP will be used for this connection.
両方のオプションを拒絶してください。 標準のPPPはこの接続に使用されるでしょう。
2.1. Operation
2.1. 操作
Standard PPP
In standard PPP the LCP negotiation phase is followed by an
optional authentication phase, and then one or more NCPs are
initiated.
任意の認証フェーズは交渉が位相を合わせる標準のPPP In標準のPPP LCPのあとに続いています、そして、次に、1つ以上のNCPが開始されます。
PPP with MP The LCP negotiation phase and authentication phase are
identical to standard PPP. The ability to initiate an MP
aggregate data link is indicated by sending an MP option - as
described in [1].
LCP交渉フェーズと認証が位相を合わせるMPがいるPPPは標準のPPPと同じです。 MP集合体データリンクを開始する能力は、[1]で説明されるようにMPオプションを送ることによって、示されます。
PPP with MP and MP+ When MP+ is negotiated at LCP startup, the same
procedures are followed as when MP is negotiated alone. The MP+
LCP option is negotiated to indicate the ability to use the MP+
feature.The first connection between endpoints causes the MP+
process to be started for the connection.
MP+であるときに、MPとMP+がいるPPPはLCP始動で交渉されて、同じ手順はMPが単独で交渉される時として従われています。 MP+LCPオプションは、接続のために終点の間のMP+feature.The最初の接続を使用する能力でMP+プロセスを始めるのを示すために交渉されます。
3. MP+ Frame Formats
3. MP+フレーム形式
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x73 |
+-+-+-+-+-------+---------------+
MP Header: |1|1|0|0|0|0|0|1| seq # high |
+-+-+-+-+-------+---------------+
| sequence number low bits |
+---------------+---------------+
| control data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
+---------------+---------------+ pppヘッダー: | アドレス0xff| コントロール0x03| +---------------+---------------+ | PID(H)0x00| PID(L)0x73| +-+-+-+-+-------+---------------+ MPヘッダー: |1|1|0|0|0|0|0|1| seq#高値| +-+-+-+-+-------+---------------+ | 一連番号低ビット| +---------------+---------------+ | 制御データ| | . | | . | | . | +---------------+---------------+ ppp FCS: | FCS| +---------------+---------------+
Figure 1: Multilink Plus Frame Format (long sequence number format)
図1: マルチリンクプラスフレーム形式(長いひと続きの出来事数の書式)
Smith Informational [Page 4] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[4ページ]のRFC1934マルチリンクプロトコルと1996年4月
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x73 |
+-+-+-+-+-------+---------------+
MP Header: |1|1|0|1| sequence number |
+-+-+-+-+-------+---------------+
| control data |
| . |
| . |
| . |
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
+---------------+---------------+ pppヘッダー: | アドレス0xff| コントロール0x03| +---------------+---------------+ | PID(H)0x00| PID(L)0x73| +-+-+-+-+-------+---------------+ MPヘッダー: |1|1|0|1| 一連番号| +-+-+-+-+-------+---------------+ | 制御データ| | . | | . | | . | +---------------+---------------+ ppp FCS: | FCS| +---------------+---------------+
Figure 2: Multilink Plus Frame Format (short sequence number format)
図2: マルチリンクプラスフレーム形式(短い一連番号形式)
MP+ frames use a similar structure to MP fragments.
MP+フレームはMP断片に類似構造物を使用します。
The MP+ assigned PID is designated 00 73.
MP+割り当てられたPIDは00 73に指定されます。
MP+ control uses the following two rules:
MP+コントロールは以下の2つの規則を使用します:
- MP+ control frames have their own sequence number space,
controlled by MP+.
- MP+制御フレームには、MP+によって制御されたそれら自身の一連番号スペースがあります。
- MP+ control frames MUST NOT be fragmented.
- MP+制御フレームを断片化してはいけません。
NOTE: Implementations of this protocol prior to the date of submission
of this specification to the IETF use the same PID as MP, but
sets the LSB of the reserved bits in the MP header to 1 - this
is how the MP+ packets are discriminated from MP fragments.
So the header of the MP+ packet looks like:
以下に注意してください。 この仕様のIETFへの服従の日以前このプロトコルの実装は、MPと同じPIDを使用しますが、1へのMPヘッダーに予約されたビットのLSBをはめ込みます--これはMP+パケットがMP断片とどう区別されるかということです。 それで、MP+パケットのヘッダーは似ています:
00 3d c1 ......
00 3d c1…
As compared to an MP packet that looks like:
MPパケットと比べて、それに似ています:
00 3d c0 ...... or
00 3d 80 ...... or
00 3d 40 ......
00 3d c0…、00 3d80…、00 3d40…
Smith Informational [Page 5] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[5ページ]のRFC1934マルチリンクプロトコルと1996年4月
3.1. Error Control (EC) Layer (MP+ control only)
3.1. 誤り制御(EC)層(MP+コントロール専用)
The error control layer that runs over the virtual inband channel is as simple as it can get, while handling the possibility of errors on the line.
事実上の「不-バンド」チャンネルをひく誤り制御層は系列で誤りの可能性を扱っている間、得ることができるのと同じくらい簡単です。
An assumption is made that errors are infrequent, and that at the same time messages are rarely, if ever, dropped on the floor. The implication of this is that "timing out" on retransmission of messages does no harm. If a message cannot get through, then it simply is retried some number of times. After giving up, the only recourse is to notify the call management layer (of MP) that the session has died.
誤りが珍しく、同時にメッセージがめったにそうでないという仮定は、されます、かつてなら、床で下げられて。 この含意はメッセージの「再-トランスミッション」の「外では、調節します」に危害を加えないということです。 メッセージが通ることができないなら、それは単に再試行されます。何らかの回数。 あきらめた後に、唯一の償還請求はセッションが死んだことを呼び出し管理層(MPの)に通知することです。
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x73 |
+-+-+-+-+-------+---------------+
MP+ Header: |1|1|0|0|0|0|0|1| seq # high |
+-+-+-+-+-------+---------------+
| sequence number low bits |
+---------------+---------------+
EC Header: | Error Control Message Type |
| 32 bits reserved |
+---------------+---------------+
MP+ Data: | MP+ Message | May not be
| | present.
+---------------+---------------+ pppヘッダー: | アドレス0xff| コントロール0x03| +---------------+---------------+ | PID(H)0x00| PID(L)0x73| +-+-+-+-+-------+---------------+ MP+ヘッダー: |1|1|0|0|0|0|0|1| seq#高値| +-+-+-+-+-------+---------------+ | 一連番号低ビット| +---------------+---------------+ ECヘッダー: | 誤り制御メッセージタイプ| | 予約された32ビット| +---------------+---------------+ MP+データ: | MP+メッセージ| ないかもしれません。| | 存在。
Figure 3: MP+ control message format (shown long sequence number
format)
図3: MP+コントロールメッセージ・フォーマット(示された長いひと続きの出来事数の書式)
Error Control Message Type:
誤り制御メッセージタイプ:
1 DATA_MSG: This message contains MP+ data transferred
between the peers.
1 データ_エムエスジー: このメッセージは同輩の間に移されたMP+データを含んでいます。
2 ACK_MSG: An acknowledgement of a previous data message.
2 ACK_エムエスジー: 前のデータメッセージの承認。
When set to DATA_MSG, the remainder of the frame contains an MP+ Control message.
DATA_MSGに設定されると、フレームの残りはMP+コントロールメッセージを含んでいます。
When set to ACK_MSG, the remainder of the frame consists only of the PPP Frame Check Sum (FCS).
ACK_MSGに設定されると、フレームの残りはPPP Frame Check Sum(FCS)だけから成ります。
Smith Informational [Page 6] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[6ページ]のRFC1934マルチリンクプロトコルと1996年4月
3.1.1. Error Control State Machine
3.1.1. 誤り制御州のマシン
This layer is controlled by a simple state machine. There are three states:
この層は簡単な州のマシンによって制御されます。 3つの州があります:
Stopped There is no connection between peers.
止まっているThereは同輩の間の接続ではありません。
Idle There is a connection between peers;
no unacknowledged messages pending.
使用されていないThereは同輩の間の接続です。 未定の不承認のメッセージがありません。
Pending There is a connection between peers;
awaiting an acknowledgement to the
last message sent.
未定のThereは同輩の間の接続です。 最後のメッセージに承認を待つのは発信しました。
Messages from the call management layer are queued for transmission whenever the link is in the pending state. For simplicity, only one outstanding message may be in the link at any given time. The entire procedure is defined in table 1.
リンクが未定の状態にあるときはいつも、呼び出し管理層からのメッセージはトランスミッションのために列に並ばせられます。 簡単さのために、1つの傑出しているメッセージしかその時々でリンクにないかもしれません。 全体の手順はテーブル1で定義されます。
Event State
______________________________________________________________________
Stopped Idle Pending
======================================================================
Start 1,Idle -,* -,*
______________________________________________________________________
Received ACK_MSG ** 2,Start 5,Idle|Pending
current tx sequence number
______________________________________________________________________
Received ACK_MSG ** -,* -,*
last tx sequence number
______________________________________________________________________
Received ACK_MSG ** 2,Start 2,Start
other tx sequence number
______________________________________________________________________
Received DATA_MSG ** 6,* 6,*
current rx sequence number
______________________________________________________________________
Received DATA_MSG ** 7,* 7,*
previous rx sequence number
______________________________________________________________________
Received DATA_MSG ** 2,Start 2,Start
other rx sequence number
______________________________________________________________________
Receive Invalid Frame ** 2,Start 2,Start
______________________________________________________________________
Retransmit Timer Expire ** ** 4,Start|*
______________________________________________________________________
イベント状態______________________________________________________________________ 止められて、未定の状態で怠けてください。====================================================================== 1を始めてくださいといって、怠けてください、-、*、-、*______________________________________________________________________ 容認されたACK_MSG**2(始め5)は怠けます。|未定の現在のtx一連番号______________________________________________________________________ ACK_MSGが受けた、**-*-*は最後に一連番号をtxします。______________________________________________________________________ 容認されたACK_MSG**2、Start2、他のtx一連番号のStart______________________________________________________________________ 容認されたDATA_MSG**6、*6、*現在のrx一連番号______________________________________________________________________ 容認された_DATA MSG**7、*7、前の*rx一連番号______________________________________________________________________ 容認されたDATA_MSG**2、Start2、他のrx一連番号のStart______________________________________________________________________ 無効のフレーム**2、始め2、始めを受けてください。______________________________________________________________________ 再送信タイマは****4を吐き出して、始まってください。|* ______________________________________________________________________
Smith Informational [Page 7] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[7ページ]のRFC1934マルチリンクプロトコルと1996年4月
______________________________________________________________________ Transmit Request from call -,* 3,Pending 8,* management layer ______________________________________________________________________ Stop 9,Start 9,Start 9,Start ______________________________________________________________________
______________________________________________________________________ 呼び出しからRequestを伝えてください、-**3、Pending8、管理は層にされます。______________________________________________________________________ 9を止めてください、そして、始め9(始め9)は始まります。______________________________________________________________________
Table 1: Error Control State Machine
テーブル1: 誤り制御州のマシン
Legend:
伝説:
- No action
- 動作がありません。
* Stay in same state
* 同じ状態にいてください。
** Invalid or meaningless event for state, ignored.
** 無効の、または、状態に、無意味なイベント無視されて。
Notes:
注意:
[1] Data from the call management layer will always be copied before
being queued for transmission. The call management layer is
responsible for its own buffers.
[1] トランスミッションのために列に並ばせられる前に呼び出し管理層からのデータはいつもコピーされるでしょう。 呼び出し管理層はそれ自身のバッファに原因となります。
[2] MP always copies data for transmission and returns immediately.
Any buffers allocated to build control messages MUST be released
immediately upon return from MP transmission requests.
[2] MPは、いつもトランスミッションのためのデータをコピーして、すぐに、戻ります。 すぐリターンのときにMP送信要求からコントロールメッセージを築き上げるために割り当てられたどんなバッファも発表しなければなりません。
Actions:
動作:
1 Reset rx sequence number
Reset tx sequence number
Reset tx retransmit count
Stop retransmit timer
1 リセットrx一連番号Reset tx一連番号Reset txはカウントStop再送信タイマを再送します。
2 Report error to user
Stop retransmit timer
Stop frame transmit timer
Free buffers
2 Stopが縁どるユーザStop再送信タイマへのレポートエラーはタイマFreeバッファを伝えます。
3 Save call management message in pending transmit queue
Build DATA_MSG from first message in pending transmit
queue using current tx sequence number.
Send message to MP for transmission.
Reset tx retransmit count
管理が中で未定の状態で通信するという要求以外の3は未定のコネが現在のtx一連番号を使用することで待ち行列を伝えるという最初のメッセージから待ち行列Build DATA_MSGを伝えます。 トランスミッションのためにメッセージをMPに送ってください。 リセットtxはカウントを再送します。
Smith Informational [Page 8] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[8ページ]のRFC1934マルチリンクプロトコルと1996年4月
4 Increment tx retransmit count
If tx retransmit count >= RETRANSMIT_COUNT
Action 2 (followed by state change to the Start state)
else
Build DATA_MSG from first message in pending
transmit queue using current tx sequence number.
Send message to MP for transmission.
4増分のtxは再送されます。If txが未定の状態で最初のメッセージからのカウント>=RETRANSMIT_COUNT Action2(Start状態への州の変化はあとに続いています)のほかのBuild DATA_MSGを再送するカウントは、現在のtx一連番号を使用することで待ち行列を伝えます。 トランスミッションのためにメッセージをMPに送ってください。
5 Dequeue first element on pending transmit queue and release
its buffer
Increment the tx sequence number
Stop the retransmit timer
if pending transmit queue not empty
Build DATA_MSG from first message in pending
transmit queue using current tx sequence number.
Send message to MP for transmission.
Reset tx retransmit count
待ち行列を伝えてください。そうすれば、リリースはバッファIncrement tx一連番号Stopを伝えます。5が未定の状態で最初の要素をデキューする、未定であるなら、再送信タイマは未定のコネが現在のtx一連番号を使用することで待ち行列を伝えるという最初のメッセージからどんな待ち行列の空のBuild DATA_MSGも伝えません。 トランスミッションのためにメッセージをMPに送ってください。 リセットtxはカウントを再送します。
6 Build ACK_MSG using the current rx sequence number
Send ack message to MP for transmission
Pass message to call managment layer
Increment rx sequence number
managmentを層のIncrement rx一連番号と呼ぶトランスミッションPassメッセージに現在のrx一連番号Send ackメッセージをMPに使用して、6はACK_MSGを造ります。
7 Build ACK_MSG using the previous rx sequence number
Send the ack message to MP for transmission
トランスミッションに前のrx一連番号SendにackメッセージをMPに使用して、7はACK_MSGを造ります。
8 Add the message to the end of the pending transmit queue
8は、未定の終わりまでのメッセージが待ち行列を伝えると言い足します。
9 Stop retransmit timer
Free buffers
9 停止再送信タイマFreeバッファ
3.2. Multilink Plus Control Messages
3.2. マルチリンクプラスコントロールメッセージ
Message Type Value
VERSION_EXCHANGE_REQ 1
VERSION_EXCHANGE_RSP 2
ADD_REQ 3
ADD_RSP 4
ADD_COMPLETE 5
REMOVE_REQ 6
REMOVE_RSP 7
REMOVE_COMPLETE 8
CLOSE_REQ 9
CLOSE_RSP 10
REMOTE_MGMT_REQ 11
REMOTE_MGMT_RSP 12
REMOTE_MGMT_RX_REQ 13
REMOTE_MGMT_TX_REQ 14
タイプ値のバージョン_交換_REQ1バージョン_交換_RSP2が、_REQ3が、_RSP4が、_完全な5が__削除、削除、_REQ6の_RSP7の完全な8閉鎖_REQ9閉鎖_RSP10のリモート_管理_REQ11のリモート_管理_RSP12のリモート__管理RX_REQ13の遠く離れた_管理_テキサスREQを取り外すと言い足すと言い足すと言い足すというメッセージ、14
Smith Informational [Page 9] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[9ページ]のRFC1934マルチリンクプロトコルと1996年4月
REMOTE_MGMT_TX_RSP 15
CLEAR_REQ 16
リモート__管理テキサス_RSP15は_REQ16をきれいにします。
3.3. Multilink Plus Message Formats
3.3. マルチリンクプラスメッセージ・フォーマット
The fields of all messages defined here MUST be encoded/decoded in Network Byte Order (big endian).
Network Byte Order(ビッグエンディアン)でここで定義されたすべてのメッセージの分野をコード化されなければならないか、または解読しなければなりません。
3.3.1. VERSION_EXCHANGE_REQ Message Format
3.3.1. バージョン_交換_REQメッセージ・フォーマット
The version exchange message is sent by the call originator to inform the answerer the version of the MP+ protocol being used as well as any other information that may need to be conveyed outside of the normal PPP parameter negotiation.
バージョン交換メッセージは通常のPPPパラメタ交渉の外まで運ばれるためにそうするかもしれないいかなる他の情報と同様に使用されるMP+プロトコルのバージョンがそうしなければならないanswererに知らせる呼び出し創始者によって送られます。
+---------------+---------------+ | Message type | | 0x00000001 | +---------------+---------------+ | Protocol Version | +---------------+---------------+ | Protocol Revision | +---------------+---------------+ | Session Identifier | +---------------+---------------+ | Hardware Type | +---------------+---------------+ | Nailed Mode | +---------------+---------------+ | Use Multiple Trunk Groups | +---------------+---------------+ | Descriptor Length | +---------------+---------------+ | Descriptor | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000001| +---------------+---------------+ | プロトコルバージョン| +---------------+---------------+ | プロトコル改正| +---------------+---------------+ | セッション識別子| +---------------+---------------+ | ハードウェアタイプ| +---------------+---------------+ | 打ち付けられたモード| +---------------+---------------+ | 複数のトランクグループを使用してください。| +---------------+---------------+ | 記述子の長さ| +---------------+---------------+ | 記述子| +---------------+---------------+
Figure 4: Version Exchange Request
図4: バージョン交換要求
A message sent from call originator to call answerer specifying the callers protocol version and other state info and requesting the answerer to respond with its version info.
メッセージは、バージョンインフォメーションで応じるために呼び出し創始者から呼び出しanswerer指定までの訪問者にプロトコルバージョンと他の州のインフォメーションを送って、answererを要求に送りました。
Protocol Version:
caller MP+ protocol version number.
2 octets fixed length (initially 1)
バージョンについて議定書の中で述べてください: 訪問者MP+プロトコルバージョン番号。 長さが固定された2つの八重奏(初めは、1)
Smith Informational [Page 10] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[10ページ]のRFC1934マルチリンクプロトコルと1996年4月
Protocol Revision:
caller MP+ protocol revision number.
2 octets fixed length (initially 4)
改正について議定書の中で述べてください: 訪問者MP+プロトコル改訂番号。 長さが固定された2つの八重奏(初めは、4)
Session Identifier:
A non-zero identifier unique to the caller.
2 octets fixed length.
セッション識別子: 訪問者にユニークな非ゼロ識別子。 2つの八重奏が長さを固定しました。
Hardware Type:
caller hardware type (can be vendor defined).
2 octets fixed length.
ハードウェアタイプ: 訪問者ハードウェアタイプ(定義されたベンダーであることができます)。 2つの八重奏が長さを固定しました。
Nailed Mode:
caller nailed mode from the session profile.
2 octets fixed length.
打ち付けられたモード: 訪問者はセッションプロフィールからモードを打ち付けました。 2つの八重奏が長さを固定しました。
Use Multiple Trunk Groups:
non-zero if the call may use channels from multiple trunk
groups.
2 octets fixed length
複数のトランクグループを使用してください: 呼び出しが複数のトランクからチャンネルを使用するかもしれないなら、非ゼロは分類されます。 長さが固定された2つの八重奏
Descriptor Length:
length of the end point descriptor.
2 octets fixed length
記述子の長さ: エンドポイント記述子の長さ。 長さが固定された2つの八重奏
Descriptor:
the end point descriptor. This field allows for vendor
specific identification of the peer.
Variable length as defined above.
記述子: エンドポイント記述子。 この分野は同輩のベンダーの特定の識別を考慮します。 上で定義される可変長。
Smith Informational [Page 11] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[11ページ]のRFC1934マルチリンクプロトコルと1996年4月
3.3.2. VERSION_EXCHANGE_RSP Message Format
3.3.2. バージョン_交換_RSPメッセージ・フォーマット
The version exchange response message is sent by the call answerer in response to a version exchange request message. The answerer uses the message to inform the caller the version of the MP+ protocol being used as well as any other information that needs to be conveyed outside of the normal PPP parameter negotiation.
バージョン交換応答メッセージはバージョン交換要求メッセージに対応して呼び出しanswererによって送られます。 answererはMP+のバージョンが議定書の中で述べる通常のPPPパラメタ交渉の外まで運ばれる必要があるいかなる他の情報と同様に使用されている訪問者に知らせるメッセージを使用します。
+---------------+---------------+ | Message type | | 0x00000002 | +---------------+---------------+ | Protocol Version | +---------------+---------------+ | Protocol Revision | +---------------+---------------+ | Session Identifier | +---------------+---------------+ | Hardware Type | +---------------+---------------+ | Nailed Mode | +---------------+---------------+ | Use Multiple Trunk Groups | +---------------+---------------+ | Descriptor Length | +---------------+---------------+ | Descriptor | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000002| +---------------+---------------+ | プロトコルバージョン| +---------------+---------------+ | プロトコル改正| +---------------+---------------+ | セッション識別子| +---------------+---------------+ | ハードウェアタイプ| +---------------+---------------+ | 打ち付けられたモード| +---------------+---------------+ | 複数のトランクグループを使用してください。| +---------------+---------------+ | 記述子の長さ| +---------------+---------------+ | 記述子| +---------------+---------------+
Figure 5: Version Exchange Response
図5: バージョン交換応答
A message sent from call answerer to the call originator specifying the answerers protocol version and other state info. Sent in response to receiving a version exchange request.
メッセージは呼び出しanswererからanswerersプロトコルバージョンと他の州のインフォメーションを指定する呼び出し創始者まで発信しました。 バージョン交換要求を受け取ることに対応して、発信しました。
Protocol Version:
caller MP+ protocol version number.
2 octets fixed length (initially 1)
バージョンについて議定書の中で述べてください: 訪問者MP+プロトコルバージョン番号。 長さが固定された2つの八重奏(初めは、1)
Protocol Revision:
caller MP+ protocol revision number.
2 octets fixed length (initially 4)
改正について議定書の中で述べてください: 訪問者MP+プロトコル改訂番号。 長さが固定された2つの八重奏(初めは、4)
Session Identifier:
A non-zero identifier unique to the answerer.
2 octets fixed length.
セッション識別子: answererにユニークな非ゼロ識別子。 2つの八重奏が長さを固定しました。
Smith Informational [Page 12] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[12ページ]のRFC1934マルチリンクプロトコルと1996年4月
Hardware Type:
caller hardware type (can be vendor defined).
2 octets fixed length.
ハードウェアタイプ: 訪問者ハードウェアタイプ(定義されたベンダーであることができます)。 2つの八重奏が長さを固定しました。
Nailed Mode:
caller nailed mode from the session profile.
2 octets fixed length.
打ち付けられたモード: 訪問者はセッションプロフィールからモードを打ち付けました。 2つの八重奏が長さを固定しました。
Use Multiple Trunk Groups:
non-zero if call may use channels from multiple trunk groups.
2 octets fixed length
複数のトランクグループを使用してください: 呼び出しが複数のトランクからチャンネルを使用するかもしれないなら、非ゼロは分類されます。 長さが固定された2つの八重奏
Descriptor Length:
length of the remote descriptor in 4-octet units.
2 octets fixed length
記述子の長さ: 4八重奏のユニットのリモート記述子の長さ。 長さが固定された2つの八重奏
Descriptor:
the remote unit descriptor. This field allows for vendor
specific identification of the peer.
Variable length Nx4 octets long - total length defined above.
記述子: リモートユニット記述子。 この分野は同輩のベンダーの特定の識別を考慮します。 八重奏が切望する可変長Nx4--全長は上を定義しました。
3.3.3. ADD_REQ Message Format
3.3.3. _REQメッセージ・フォーマットを加えてください。
A message of this type is sent by either caller or answerer to initiate an increase of bandwidth. When sent by the caller the request is asking for permission to dial a certain number of channels; the response will contain permission and the phone numbers of the channels to dial. When sent by the answerer, this message contains the phone numbers to dial. The message looks like:
このタイプに関するメッセージは、帯域幅の増加を起こすために訪問者かanswererのどちらかによって送られます。 訪問者によって送られると、要求はある数のチャンネルにダイヤルする許可を求めています。 応答はダイヤルするチャンネルの許可と電話番号を含むでしょう。 answererによって送られると、このメッセージはダイヤルする電話番号を含んでいます。 メッセージに似ています:
+---------------+---------------+ | Message type | | 0x00000003 | +---------------+---------------+ | Number of channels requested | +---------------+---------------+ | Number of phone numbers | +---------------+---------------+ | A phone number list for | | each phone number | | . | | . | | . | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000003| +---------------+---------------+ | 要求されたチャンネルの数| +---------------+---------------+ | 電話番号の数| +---------------+---------------+ | A電話番号は記載します。| | 各電話番号| | . | | . | | . | +---------------+---------------+
Figure 6: Add Request
図6: 要求を加えてください。
Smith Informational [Page 13] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[13ページ]のRFC1934マルチリンクプロトコルと1996年4月
A message sent by either caller or answerer to request that additional bandwidth be added to a session.
追加帯域幅がセッションに加えられるよう要求するために訪問者かanswererのどちらかによって送られたメッセージ。
Number of channels requested:
The maximum number of channels to add.
2 octets fixed length.
チャンネルの数は要求しました: 加えるチャンネルの最大数。 2つの八重奏が長さを固定しました。
Number of phone numbers:
The number of phone numbers provided. This
value will always be zero when the caller
initiates an add and will be at least
Number of channels requested when the answerer
initiates the add.
2 octets fixed length.
電話番号の数: 電話番号の数は提供されました。 訪問者開始であるときに、この値がいつもゼロになる、加えて、少なくともanswerer開始であるときに要求されたチャンネルのNumberである、加えてください。 2つの八重奏が長さを固定しました。
Phone number list:
A list of up to 32 phone number lists
containing the phone numbers to call.
Each description is of fixed length as described below:
電話番号リスト: 電話をする電話番号を含んでいて、最大32電話番号のリストはリストアップされています。 各記述は以下で説明されるように固定長のものです:
Each phone number is represented by a phone number list.
The format of a phone number list is:
各電話番号は電話番号リストによって表されます。 電話番号リストの形式は以下の通りです。
+---------------+---------------+ | in use flag | +---------------+---------------+ | call service type | +---------------+---------------+ | Phone number | | 20 octets | | plus null terminator | | (21 octet total) | | | | | | | | | | | | | | +---------------+ | | Must be 0 | +---------------+---------------+ | must be 0 | +---------------+---------------+
+---------------+---------------+ | 使用中に、弛んでください。| +---------------+---------------+ | サービスタイプに電話をしてください。| +---------------+---------------+ | 電話番号| | 20の八重奏| | プラスヌルターミネータ| | (21八重奏合計) | | | | | | | | | | | | | | +---------------+ | | 0でなければなりません。| +---------------+---------------+ | 0でなければなりません。| +---------------+---------------+
Figure 7: Phone number list
図7: 電話番号リスト
Smith Informational [Page 14] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[14ページ]のRFC1934マルチリンクプロトコルと1996年4月
A structure containing information about a connection within the system.
システムの中に接続の情報を含む構造。
in use flag:
non-zero if the phone number indicated
in this descriptor is currently in use.
2 octets fixed length
使用中に、弛んでください: 非ゼロは、電話番号であるならこれで記述子が現在使用中であることを示しました。 長さが固定された2つの八重奏
call service type:
Defines the type of service, switched, nailed,
or other, associated with a phone number.
1 Nailed
2 Switched
>=3 Undefined
サービスタイプに電話をしてください: 何らかの打ち付けられた電話番号に関連している切り換えられたサービスのタイプを定義します。 1は未定義の状態で2の切り換えられた>=3を打ち付けました。
Phone number:
The null terminated phone number of this channel.
Fixed length 21 octets. Each octet contains IA5 character
representation of a digit (or #, *).
電話番号: ヌルはこのチャンネルの電話番号を終えました。 固定長21八重奏。 各八重奏はケタ(または、#、*)のIA5文字表示を含んでいます。
Must be 0:
Filler to force alignment to 32-bit boundary.
0でなければなりません: 32ビットの境界に整列を強制するフィラー。
3.3.4 ADD_RSP Message Format
3.3.4 _RSPメッセージ・フォーマットを加えてください。
A message of this type gives permission to dial some number of channels and, when sent by the answerer of the original call, gives the phone numbers of channels to dial.
このタイプに関するメッセージは、何らかの数のチャンネルにダイヤルする許可を与えて、オリジナルの呼び出しのanswererによって送られると、ダイヤルするチャンネルの電話番号を与えます。
+---------------+---------------+ | Message type | | 0x00000004 | +---------------+---------------+ | Number of channels allowed | +---------------+---------------+ | Number of phone numbers | +---------------+---------------+ | A phone number list for | | each phone number | | . | | . | | . | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000004| +---------------+---------------+ | 許容されたチャンネルの数| +---------------+---------------+ | 電話番号の数| +---------------+---------------+ | A電話番号は記載します。| | 各電話番号| | . | | . | | . | +---------------+---------------+
Figure 8: Add Response
エイト環: 応答を加えてください。
Smith Informational [Page 15] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[15ページ]のRFC1934マルチリンクプロトコルと1996年4月
A message sent by either caller or answerer to indicate the number of channels that may be added to a session.
セッションに加えられるかもしれないチャンネルの数を示すために訪問者かanswererのどちらかによって送られたメッセージ。
Number of channels allowed:
The actual number of channels to add. This
may be less than the number requested.
2 octets fixed length.
チャンネルの数は許容しました: 加えるチャンネルの実数。 これは数が要求したより少ないかもしれません。 2つの八重奏が長さを固定しました。
Number of phone numbers:
The number of phone numbers provided. This
value will always be zero when sent by the
caller and will be at least channelCount
when sent by the answerer.
2 octets fixed length.
電話番号の数: 電話番号の数は提供されました。 この値は、訪問者によって送られるといつもゼロであり、answererによって送られると、少なくともchannelCountになるでしょう。 2つの八重奏が長さを固定しました。
Phone number list:
A list of up to 32 phone number lists
containing the phone numbers to call.
Each description is of fixed length as described above.
電話番号リスト: 電話をする電話番号を含んでいて、最大32電話番号のリストはリストアップされています。 各記述は上で説明されるように固定長のものです。
3.3.5. ADD_COMPLETE Message Format
3.3.5. _完全なメッセージ・フォーマットを加えてください。
This message is sent by the caller to the answerer after all calls have been placed. The message is used to notify the answerer that the add transaction is complete and it may return to the idle state.
すべての電話が出された後にこのメッセージは訪問者によってanswererに送られます。 メッセージがより多くのanswererにそれに通知するのに使用される、トランザクションが完全であり、それが活動していない状態に戻るかもしれないと言い足してください。
+---------------+---------------+ | Message type | | 0x00000005 | +---------------+---------------+ | Channels added | +---------------+---------------+ | Must be zero | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000005| +---------------+---------------+ | チャンネルは加えました。| +---------------+---------------+ | ゼロでなければなりません。| +---------------+---------------+
Figure 9: Add Complete
図9: 完全な状態で、加えてください。
A message sent by caller to indicate the number of channels that were added successfully. This message was added in MP+ Version 1.1.
首尾よく加えられたチャンネルの数を示すために訪問者によって送られたメッセージ。 このメッセージはMP+バージョン1.1で加えられました。
Channels added:
The actual number of channels added.
2 octets fixed length
チャンネルは加えました: 加えられたチャンネルの実数。 長さが固定された2つの八重奏
Must be zero:
Padding to 32-bit boundary.
2 octets fixed length
ゼロでなければなりません: 32ビットの境界に、そっと歩きます。 長さが固定された2つの八重奏
Smith Informational [Page 16] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[16ページ]のRFC1934マルチリンクプロトコルと1996年4月
3.3.6. REMOVE_REQ Message Format
3.3.6. _REQメッセージ・フォーマットを取り除いてください。
A message of this type is sent when a peer decides, for any reason, to remove channels from use. The purpose of the message is to tell the remote end of the remove and give it a chance to adjust the number of channels to remove.
同輩が、どんな理由でも使用からチャンネルを免職すると決めると、このタイプに関するメッセージを送ります。 メッセージの目的がリモートエンドを言うことになっている、数を調整する機会にチャンネルが取り外すのを移して、与えてください。
+---------------+---------------+ | Message type | | 0x00000006 | +---------------+---------------+ | Number of channels to remove | +---------------+---------------+ | Must be zero | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000006| +---------------+---------------+ | 免職するチャンネルの数| +---------------+---------------+ | ゼロでなければなりません。| +---------------+---------------+
Figure 10: Remove Request
図10: 要求を取り除いてください。
A message sent by either caller or answerer to request that bandwidth be removed from a session.
帯域幅がセッションから取り除かれるよう要求するために訪問者かanswererのどちらかによって送られたメッセージ。
Number of channels to remove:
The maximum number of channels to remove.
2 octets fixed length
免職するチャンネルの数: 免職するチャンネルの最大数。 長さが固定された2つの八重奏
Must be zero:
Padding to 32-bit boundary.
2 octets fixed length
ゼロでなければなりません: 32ビットの境界に、そっと歩きます。 長さが固定された2つの八重奏
3.3.7. REMOVE_RSP Message Format
3.3.7. _RSPメッセージ・フォーマットを取り除いてください。
This message is sent in response to a remove request. The responder specifies the number of channels that can be removed. If the response specifies 0 channels the remove is cancelled.
メッセージがaに対応して送られるこれは要求を取り除きます。 応答者は免職できるチャンネルの数を指定します。 取り外してください。応答が0個のチャンネルを指定する、取り消されます。
+---------------+---------------+ | Message type | | 0x00000007 | +---------------+---------------+ | Number of channels to remove | +---------------+---------------+ | Must be zero | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000007| +---------------+---------------+ | 免職するチャンネルの数| +---------------+---------------+ | ゼロでなければなりません。| +---------------+---------------+
Figure 11: Remove Response
図11: 応答を取り除いてください。
Smith Informational [Page 17] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[17ページ]のRFC1934マルチリンクプロトコルと1996年4月
A message sent in response to a remove request specifying the number of channels that the peer agrees can be removed.
aに対応して送られたメッセージは同輩が免職できるのに同意するチャンネルの数を指定する要求を取り除きます。
Number of channels to remove:
The maximum number of channels to remove.
May be zero, in which case the remove is
cancelled.
2 octets fixed length
免職するチャンネルの数: 免職するチャンネルの最大数。 取り外してください。その場合ゼロであるかもしれない、取り消されます。 長さが固定された2つの八重奏
Must be zero:
Padding to 32-bit boundary.
2 octets fixed length
ゼロでなければなりません: 32ビットの境界に、そっと歩きます。 長さが固定された2つの八重奏
3.3.8. REMOVE_COMPLETE Message Format
3.3.8. _完全なメッセージ・フォーマットを取り除いてください。
This message is sent by the initiator of a remove transaction when the agreed upon number of channels have been removed. The message is used to notify the peer that the remove transaction is complete and it may return to the idle state.
このメッセージは創始者によって送られます。aでは、チャンネルの数での同意を取り除いたときにはトランザクションを取り除いてください。 取り外してください。メッセージが同輩に通知するのに使用される、それ、トランザクションは完全であり、それは活動していない状態に戻ってもよいです。
+---------------+---------------+ | Message type | | 0x00000008 | +---------------+---------------+ | Number of channels removed | +---------------+---------------+ | Must be zero | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000008| +---------------+---------------+ | 免職されたチャンネルの数| +---------------+---------------+ | ゼロでなければなりません。| +---------------+---------------+
Figure 12: Remove Complete
図12: 完全な状態で、取り外してください。
A message sent by the caller or answerer to indicate how many channels were actually removed. This message was added in MP+ CM version 1.1.
訪問者によって送られたメッセージかいくつが精神を集中するかを示すanswererが実際に取り外されました。 このメッセージはMP+CMバージョン1.1で加えられました。
Number of channels removed:
The number of channels that were removed.
2 octets fixed length
チャンネルの数は取り除きました: 免職されたチャンネルの数。 長さが固定された2つの八重奏
Must be zero:
Padding to 32-bit boundary.
2 octets fixed length
ゼロでなければなりません: 32ビットの境界に、そっと歩きます。 長さが固定された2つの八重奏
Smith Informational [Page 18] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[18ページ]のRFC1934マルチリンクプロトコルと1996年4月
3.3.9. CLOSE_REQ Message Format
3.3.9. _REQメッセージ・フォーマットを閉じてください。
This message is sent when the peer requests to close the whole session. This is typically due to a configuration option that indicates when a system should request to close the session (an example being, a link has been idle for greater than a preconfigured time period).
全体のセッションを終えるという同輩要求であるときに、このメッセージを送ります。 これが通常、システムがいつ閉鎖にセッションを要求するはずであるかを示すa設定オプションのためである、(ある例のaリンクが使用されていない、あらかじめ設定された期間より長い、)
+---------------+---------------+ | Message type | | 0x00000009 | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000009| +---------------+---------------+
Figure 13: MP+ close request.
図13: MP+厳密な要求。
There are no data fields associated with this message.
このメッセージに関連しているどんなデータ・フィールドもありません。
3.3.10. CLOSE_RSP Message Format
3.3.10. _RSPメッセージ・フォーマットを閉じてください。
If the peer agrees that closing the session is acceptable based on it's own configuration (an example reject reason would be that the peer is configured with a *minimum* number of channels to keep active).
同輩が、セッションを終えるのが許容できるのに同意するなら、それに基づいているのは、自己の構成(例の廃棄物理由は同輩が*最小の*番号のチャンネルで構成されて、アクティブな状態で保つということである)です。
+---------------+---------------+ | Message type | | 0x0000000a | +---------------+---------------+ | OK To Close | +---------------+---------------+ | Must be zero | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0x0000000a| +---------------+---------------+ | 閉じるために、OKです。| +---------------+---------------+ | ゼロでなければなりません。| +---------------+---------------+
Figure 14: MP+ close response
図14: MP+厳密な応答
The response to a close request. May be sent by caller or answerer.
厳密な要求への応答。 訪問者かanswererによって送られるかもしれません。
OK To Close:
If non-zero, peer said I can close all channels.
2 octets fixed length
閉鎖へのOK: 非ゼロであるなら、同輩は、私がオール・チャンネルを閉じることができると言いました。 長さが固定された2つの八重奏
Must be zero:
Padding to 32-bit boundary.
2 octets fixed length
ゼロでなければなりません: 32ビットの境界に、そっと歩きます。 長さが固定された2つの八重奏
Smith Informational [Page 19] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[19ページ]のRFC1934マルチリンクプロトコルと1996年4月
3.3.11. REMOTE_MGMT_REQ Message Format
3.3.11. リモート_管理_REQメッセージ・フォーマット
This message is sent from a master station to a slave station when the master wishes to manage the remote station. The message is also used to cancel remote management once it's been started.
マスターが遠隔局を管理したがっているとき、このメッセージを主局から従局に送ります。 また、メッセージは、それがいったん始められたあとにリモート管理を中止するのに使用されます。
+---------------+---------------+ | Message type | | 0x0000000b | +---------------+---------------+ | Mode | +---------------+---------------+ | Must be zero | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0x0000000b| +---------------+---------------+ | モード| +---------------+---------------+ | ゼロでなければなりません。| +---------------+---------------+
Figure 15: Remote Management Request
図15: リモート管理要求
A message sent from master to slave to initiate or clear a remote management session.
メッセージはリモート管理セッションを開始するか、またはクリアするために身を粉にして働くマスターから発信しました。
Mode:
One to start session. Zero to stop session.
2 octets fixed length
モード: スタートセッションまでの1。 停止セッションまでゼロに合わせます。 長さが固定された2つの八重奏
Must be zero:
Padding to 32-bit boundary.
2 octets fixed length
ゼロでなければなりません: 32ビットの境界に、そっと歩きます。 長さが固定された2つの八重奏
3.3.12. REMOTE_MGMT_RSP Message Format
3.3.12. リモート_管理_RSPメッセージ・フォーマット
The slave side of a remote management session has the opportunity to reject remote management. The master side is informed of accept/deny status via the remote management response.
リモート管理セッションの奴隷側には、リモート管理を拒絶する機会があります。 側は知識があるマスターが、リモート管理応答で状態を受け入れるか、または否定します。
+---------------+---------------+ | Message type | | 0x0000000c | +---------------+---------------+ | Mode | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0x0000000c| +---------------+---------------+ | モード| +---------------+---------------+
Figure 16: Remote Management Response
図16: リモート管理応答
A message sent from slave to master to allow or deny initiation of a remote management session.
メッセージは、リモート管理セッションの開始を許容するか、または否定するために奴隷からマスターまで発信しました。
Smith Informational [Page 20] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[20ページ]のRFC1934マルチリンクプロトコルと1996年4月
Mode:
One to accept session. Zero to deny session.
2 octets fixed length
モード: セッションを受け入れる1。 セッションを否定するために、ゼロに合わせます。 長さが固定された2つの八重奏
Must be zero:
Padding to 32-bit boundary.
2 octets fixed length
ゼロでなければなりません: 32ビットの境界に、そっと歩きます。 長さが固定された2つの八重奏
3.3.13. REMOTE_MGMT_RX_REQ Message Format
3.3.13. リモート_管理_RX_REQメッセージ・フォーマット
This message type is used to convey keyboard input from the management master to be processed by the management slave. The message format consists of an octet count (in network byte order) and then an array of octets to be processed. It looks like:
このメッセージタイプは、管理奴隷によって処理されるように管理マスターからキーボード入力を伝えるのに使用されます。 メッセージ・フォーマットは、処理されるために八重奏カウント(ネットワークバイトオーダーにおける)と次に、八重奏の勢ぞろいから成ります。 それに似ています:
+---------------+---------------+ | Message type | | 0x0000000d | +---------------+---------------+ | character count | +---------------+---------------+ | array of characters | | . | | . | | . | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0x0000000d| +---------------+---------------+ | キャラクタカウント| +---------------+---------------+ | キャラクタの配列| | . | | . | | . | +---------------+---------------+
Figure 17: Remote Management Receive Request
図17: リモート管理は要求を受け取ります。
A message sent from master to slave, conveying keystrokes typed on the masters keyboard that will be processed by the slave.
メッセージはマスターから奴隷まで発信しました、奴隷によって処理されるマスターキーボードにタイプされたキーストロークを伝えて。
character count:
Number of characters to process.
2 octets fixed length
キャラクタカウント: 処理するキャラクタの数。 長さが固定された2つの八重奏
array of characters:
Array of characters to process.
キャラクタの配列: 処理するキャラクタの配列。
Smith Informational [Page 21] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[21ページ]のRFC1934マルチリンクプロトコルと1996年4月
3.3.14. REMOTE_MGMT_TX_REQ Message Format
3.3.14. リモート_管理_テキサス_REQメッセージ・フォーマット
The remote management slave conveys output to be displayed on the masters terminal with a remote management transmit request message. Only one message may be outstanding. The next transmit request may not be sent until the previous has been acknowledged.
リモート管理による端末のマスターの上に表示するために出力されて、奴隷が伝えるリモート管理は要求メッセージを伝えます。 1つのメッセージだけが傑出しているかもしれません。 次は要求を伝えます。前が承認されるまで、送られないかもしれません。
+---------------+---------------+ | Message type | | 0x0000000e | +---------------+---------------+ | character count | +---------------+---------------+ | array of characters | | . | | . | | . | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0x0000000e| +---------------+---------------+ | キャラクタカウント| +---------------+---------------+ | キャラクタの配列| | . | | . | | . | +---------------+---------------+
Figure 18: Remote Management Transmit Request
図18: リモート管理は要求を伝えます。
A message sent from slave to master, conveying output to be output on the master's display.
メッセージはマスターのディスプレイの出力になるように出力を伝えるマスタリングする奴隷から発信しました。
Character count:
Number of characters to process.
2 octets fixed length
キャラクターカウント: 処理するキャラクタの数。 長さが固定された2つの八重奏
array of characters:
Array of characters to process.
キャラクタの配列: 処理するキャラクタの配列。
3.3.15. REMOTE_MGMT_TX_RSP Message Format
3.3.15. リモート_管理_テキサス_RSPメッセージ・フォーマット
This message is used to acknowledge remote management transmit requests. The slave may send the next transmit request once this message has been received.
このメッセージは、リモート管理が要求を伝えると認めるのに使用されます。 奴隷は発信するかもしれません。いったんこのメッセージを受け取ると、次は要求を伝えます。
+---------------+---------------+ | Message type | | 0x0000000f | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0x0000000f| +---------------+---------------+
Figure 19: Remote Management Transmit Response
図19: リモート管理は応答を伝えます。
There are no data fields associated with this message.
このメッセージに関連しているどんなデータ・フィールドもありません。
Smith Informational [Page 22] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[22ページ]のRFC1934マルチリンクプロトコルと1996年4月
3.3.16. CLEAR_REQ Message Format
3.3.16. 明確な_REQメッセージ・フォーマット
A message sent to initiate a friendly shutdown of an MP+ link. The sender will stop sending data immediately. The receiver of the message will also stop sending user data and start a clean shutdown of all NCPs and the LCP of each member link of the bundle. When the last member link terminates, the session is completely closed.
メッセージは、MP+リンクの好意的な閉鎖を開始するために発信しました。 送付者は、すぐにデータを送るのを止めるでしょう。 メッセージの受信機は、また、利用者データを送るのを止めて、バンドルのそれぞれのメンバーリンクのすべてのNCPとLCPの清潔な閉鎖を始めるでしょう。 最後のメンバーリンクが終わるとき、セッションは完全に終えられます。
+---------------+---------------+ | Message type | | 0x00000010 | +---------------+---------------+
+---------------+---------------+ | メッセージタイプ| | 0×00000010| +---------------+---------------+
Figure 20: Clear Request
図20: 明確な要求
There are no data fields associated with this message.
このメッセージに関連しているどんなデータ・フィールドもありません。
3.4. Events
3.4. イベント
The MP+ state machine is event driven. Reception of an event triggers an action and possibly a state change. The events processed by the MP+ state machine can be roughly classed into two types:
MP+州のマシンはイベントドリブンです。 イベントのレセプションは動作とことによると州の変化の引き金となります。 およそMP+州のマシンによって処理されたイベントは2つのタイプに分類できます:
Events that originate within the unit, e.g. notification that a
call has cleared, an MP+ session may be started, etc.
ユニットの中に起因するイベント、例えば、呼び出しがクリアしてあって、MP+セッションが始められるかもしれないという通知など
Events that originate with the reception of an MP+ control
message from the peer unit.
同輩ユニットからのMP+コントロールメッセージのレセプションの発案であるイベント。
Both types are processed by the state machine in the sequence they occurred. The events processed are:
両方のタイプは系列の州のマシンによって処理されて、彼らが起こったということです。 処理されたイベントは以下の通りです。
MP+START_SESSION: Notification from PPP/MP that an
MP+ session is starting.
MP+スタート_セッション: PPP/MPからのMP+セッションが始めであることであるという通知。
MP+SESSION_DOWN: Notification from the error-control
layer that end-to-end connectivity
has been lost and control messages can
not be delivered.
mp+セッション_はダウンします: 誤り制御層からの終わりから終わりへの接続性が失われたという通知とコントロールメッセージを提供できません。
MP+SESSION_TERM: Session termination notification from
PPP/MP. This event is not sent until
the last channel of a multi-channel
session is cleared.
_用語MP+セッション: PPP/MPからのセッション終了通知。 マルチチャンネルセッションの最後のチャンネルがきれいにされるまで、このイベントは送られません。
MP+TIMER_EXPIRED: Timers are used in various states and
sub-states. This event is signaled whenever
a timer expires.
MP+タイマ_有効期限: タイマは様々な州とサブ州で使用されます。 タイマが期限が切れるときはいつも、このイベントは合図されます。
Smith Informational [Page 23] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[23ページ]のRFC1934マルチリンクプロトコルと1996年4月
MP+CALL_COMPLETE: A call placed during an add request has
completed. The call may have succeeded or
failed.
MP+呼び出し_は以下を完成します。 出された電話、要求が完成したと言い足してください。 呼び出しは、成功したか、または失敗したかもしれません。
MP+UTILIZATION: Notification from MP/PPP that link
utilization has crossed a threshold and that
channels may need to be added/removed.
(The number of channels to add/remove will be
passed with the notification).
MP+利用: MP/PPPからのリンク利用が敷居に交差したという向けられる通知は、加えられるか、または取り除かれる必要があるかもしれません。 (加えるか、または免職するチャンネルの数は通知で通過されるでしょう。)
MP+RX_VERSION_REQ: A Version Exchange request message has
been received from the peer.
MP+RX_バージョン_REQ: 同輩からバージョンExchange要求メッセージを受け取りました。
MP+RX_VERSION_RSP: A Version Exchange response message has
been received from the peer.
MP+RX_バージョン_RSP: 同輩からバージョンExchange応答メッセージを受け取りました。
MP+ADD_REQ: An Add request message has been received
from the peer.
mp+は_REQを加えます: 同輩からAdd要求メッセージを受け取りました。
MP+ADD_RSP: An Add response message has been received
from the peer.
mp+は_RSPを加えます: 同輩からAdd応答メッセージを受け取りました。
MP+ADD_COMP: An Add Complete message has been received
from the peer.
mp+は_コンピュータを加えます: 同輩からAdd Completeメッセージを受け取りました。
MP+REMOVE_REQ: A Remove request message has been received
from the peer.
+ _削除、MP REQ: 同輩からRemove要求メッセージを受け取りました。
MP+REMOVE_RSP: A Remove response message has been
received from the peer.
+ _削除、MP RSP: 同輩からRemove応答メッセージを受け取りました。
MP+REMOVE_COMP: A Remove Complete message has been received
from the peer.
mp+は_コンピュータを取り外します: 同輩からRemove Completeメッセージを受け取りました。
MP+RX_RM_REQ: A Remote Management request has been received
from the peer.
MP+RX_RM_REQ: 同輩からRemote Management要求を受け取りました。
MP+RX_RM_RSP: A Remote Management response has been received
from the peer.
MP+RX_RM_RSP: 同輩からRemote Management応答を受けました。
MP+RX_RM_RX_REQ: A Remote Management Receive Request has been
received from the far end.
+ MP RX_RM_RX_REQ: 遠端からRemote Management Receive Requestを受け取りました。
MP+RX_RM_TX_REQ: A Remote Management Transmit Request has
been received from the peer.
_MP+RX_RM_テキサスREQ: 同輩からRemote Management Transmit Requestを受け取りました。
Smith Informational [Page 24] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[24ページ]のRFC1934マルチリンクプロトコルと1996年4月
MP+RX_RM_TX_RSP: A Remote Management Transmit Response has
been received from the peer.
_MP+RX_RM_テキサスRSP: 同輩からRemote Management Transmit Responseを受け取りました。
MP+RX_CLEAR: A request to shut down the session has been
received from the peer.
MP+RX_はきれいにされます: 同輩からセッションを止めるという要求を受け取りました。
MP+CLOSE_REQ: A Close Request message has been received
from the peer.
_MP+閉鎖REQ: 同輩からClose Requestメッセージを受け取りました。
MP+CLOSE_RSP: A Close Response message has been received
from the peer.
_MP+閉鎖RSP: 同輩からClose Responseメッセージを受け取りました。
MP+START_RM Request to start a remote management session
with this station being the master.
+ マスターであるこのステーションとのリモート管理セッションを始めるMP START_RM Request。
MP+SEND_RMS: Request to send data to a remote management
master from a slave.
mp+は_RMSを送ります: データを奴隷からリモート管理マスターに送るよう要求します。
MP+SEND_RMM: Request to send data to a remote management
slave from a master.
mp+は_RMMを送ります: 発信するために、リモート管理へのデータがマスターから身を粉にして働くよう要求してください。
MP+RECV_RMM: Request to send an ack to a remote management
slave for data received from the slave.
+ MP RECV_RMM: データのためにリモート管理の奴隷にackを送るのが奴隷から受信されたよう要求してください。
MP+STOP_RM: Request to stop a remote management session.
_MP+停止RM: リモート管理セッションを停止に要求してください。
3.5. State Machine
3.5. 州のマシン
3.5.1 States
3.5.1 州
To ease readability and understanding the major states are considered as separate state machines, each having two to four sub-states. The sub-states are named by the letters, A, B, C, and D. State information is maintained for every interface.
軽くなるように、それぞれ2〜4つのサブ州を持っていて、読み易さと主要な州を理解しているのは別々の州のマシンであるとみなされます。 サブ州は手紙で命名されて、A、B、C、およびD.州情報はあらゆるインタフェースに保守されます。
The major states are:
主要な州は以下の通りです。
MP+STATE_INITIAL: The state of an unused session. Session table
entries are intialized to this state at startup
and return to this state when sessions are
terminated.
MP+州の_は以下に頭文字をつけます。 未使用のセッションの状態。 セッションテーブル項目は、始動でこの状態にintializedされて、セッションが終えられるとき、この状態に戻ります。
MP+STATE_IDLE: The state of an active session that is not
performing any MP+ function.
MP+州の_は怠けます: どんなMP+機能も実行していない活発なセッションの状態。
MP+STATE_ADD: The state of a session when an add transaction is
in progress.
MP+州の_、追加:。 セッションの状態、いつ、トランザクションが進行していると言い足してくださいか。
Smith Informational [Page 25] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[25ページ]のRFC1934マルチリンクプロトコルと1996年4月
MP+STATE_REMOVE: The state of a session when a remove transaction is
in progress.
MP+州の_は取り外します: aがトランザクションを取り除くセッションの状態は進行しています。
MP+STATE_CLOSE: The state of a session that is in the process of
being closed.
MP+州の_は閉じます: あることの途中にあるセッションの状態は休みました。
State transitions are triggered by the reception of an event. Tables 2 through 6 contain the state tables for the major states. All state tables use the following symbols.
状態遷移はイベントのレセプションによって引き起こされます。 テーブル2〜6は主要な州へのステートテーブルを含んでいます。 すべてのステートテーブルが以下のシンボルを使用します。
- No action
- 動作がありません。
* Stay in same state
* 同じ状態にいてください。
+ Target state is defined by the action taken
+ 目標状態は取られた行動で定義されます。
** An error has occurred, log an error message but no
state change.
** 誤りが発生して、ログは、エラーメッセージにもかかわらず、州の変化ではありません。
States and sub-state transitions are noted as state:sub-state, e.g., initial:A. Alternative transitions are listed on separate lines.
州とサブ状態遷移はサブ状態の、そして、例えば、初期の状態として注意されます: A。 代替の変遷は別々の系列に記載されています。
3.5.2 Common Actions
3.5.2 一般的な動作
Some actions are common to all states, they are defined here.
いくつかの動作がすべての州に共通である、それらはここで定義されます。
Error Close Action
誤りの厳密な動作
Called to close a session when an error occurs. Actions are:
誤りが発生するセッションに近くに呼びかけました。 動作は以下の通りです。
[1] Stop timer if running.
[1] 稼働するなら、タイマを止めてください。
[2] Log an error message.
[2] エラーメッセージを登録してください。
[3] Close the MP+EC layer for this session.
[3] このセッションのためにMP+EC層を閉じてください。
[4] Close MP for this session
[4] このセッションのためにMPを閉じてください。
[5] Clean up, restore state variables to their initial state.
[5] 掃除してください、そして、州の変数をそれらの初期状態に回復してください。
Term Action
用語動作
Processed when a MP+SESSION_TERM event occurs in most states.
Actions are:
MP+SESSION_TERMイベントがほとんどの州に起こるとき、処理されます。 動作は以下の通りです。
[1] Stop timer if running.
[1] 稼働するなら、タイマを止めてください。
[2] Close the MP+EC layer for this session.
[2] このセッションのためにMP+EC層を閉じてください。
Smith Informational [Page 26] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[26ページ]のRFC1934マルチリンクプロトコルと1996年4月
[3] Call the passed termination callback function if not null.
[3] 通っている終了コールバック機能かヌルに電話をしてください。
[4] Clean up, restore state variables to their initial state.
[4] 掃除してください、そして、州の変数をそれらの初期状態に回復してください。
Ignore Action
動作を無視してください。
We don't care about this event in this state. Do nothing.
私たちはこの状態でこのイベントを心配しません。 何もしないでください。
Timer Action
タイマ動作
This action is called when a timer expires in one of the on-line
states. The timer is used to implement add and remove locks. A
lock is set when an add or remove fails and is not cleared until
a bandwidth change or the timer expires. This keeps us from
retrying add's and subtracts until there is a likelyhood that it
will succeed.
タイマがオンライン州の1つで期限が切れるとき、この動作は呼ばれます。 使用されるタイマは、道具に加えて、錠を取り外します。 錠がいつを設定するかことである、帯域幅変化かタイマが期限が切れるまで、やり損ないを加えるか、または取り除いて、クリアされません。 そして、私たちがこれによって再試行できない、加える、それが引き継ぐ「ありそう-時代」があるまで、引きます。
[1] Check add lock flag.
[1] チェックはロック旗を加えます。
[1] If set an add lock occured last timeout period so
triple the timeout value (to a max of 81 minutes).
[1] 設定される、錠が最後のタイムアウト時間をoccuredしたと言い足してくださいので、タイムアウト価値(81分の最大への)を3倍にしてください。
[2] If not set restore the timeout value to its initial
value of one minute.
[2] 設定されないなら、1分の初期の値にタイムアウト値を回復してください。
[2] Clear the add lock flag.
[2] クリアしてください、ロック旗を加えてください。
[3] Clear the remove lock flag.
[3] クリアしてください、ロック旗を取り外してください。
[4] Restart the retry timer.
[4] 再試行タイマを再開してください。
Enter Remove [local] Action
入る、[地方]の動作を取り除いてください。
The local unit is initiating a remove transaction. The desired
bandwidth is given.
地方のユニットはaを開始するとトランザクションが取り除かれるということです。 必要な帯域幅を与えます。
[1] Restart the idle timer.
[1] 使用されていないタイマを再開してください。
[2] Calculate number of channels to remove (difference between
number in use and number in desired).
[2] 免職するチャンネル(使用中の数と中で望まれていた数の違い)の数について計算してください。
[3] Build and send a remove request and send to remote.
[3] aを建てて、送ってください。要求を取り除いてください、そして、リモートに発信してください。
[4] Go to REMOVE:A.
[4] 取り外しに行ってください: A。
Smith Informational [Page 27] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[27ページ]のRFC1934マルチリンクプロトコルと1996年4月
Enter Remove [remote] Action
入る、[リモート]の動作を取り除いてください。
The remote unit is initiating a remove transaction. The incoming
message contains the number of channels to remove.
リモート単位はaを開始するとトランザクションが取り除かれるということです。 入力メッセージは免職するチャンネルの数を含んでいます。
[1] Restart the idle timer.
[1] 使用されていないタイマを再開してください。
[2] Request the number of channels required. If greater than the
number available after removing the number of channels indicated
in the incoming message reduce the number of channels to remove
and set a remove lock.
[2] チャンネルの数が必要であるよう要求してください。 入力メッセージで示されたチャンネルの数を取り除いた後に有効な数が取り外すためにチャンネルの数を減少させるよりすばらしくて設定しているaが取り外されるなら、ロックしてください。
[3] Build a remove response message indicating the number of
channels we will allow the requester to remove and send to the
remote.
[3] aがリモートに移して、送るために私たちがリクエスタを許すつもりであるチャンネルの数を示す応答メッセージを移す体格。
[4] Go to REMOVE:B.
[4] 取り外しに行ってください: B。
Enter Add [local] Action
入る、[地方]の動作を加えてください。
The local unit is initiating an add transaction. We are given
the number of channels desired. The steps are:
地方のユニットが開始している、トランザクションを加えてください。 望まれていたチャンネルの数を私たちに与えます。 ステップは以下の通りです。
[1] Restart the idle timer.
[1] 使用されていないタイマを再開してください。
[2] Calculate number of channels to add (difference between
number desired and number in use).
[2] 加える(望まれていた数と使用中の数の違い)ためにチャンネルの数について計算してください。
[3] Reserve number of channels, retrieving their phone numbers.
[3] 彼らの電話番号を検索して、チャンネルの数を予約してください。
[4] If number of channels reserved less than the number desired
set an add lock.
[4] チャンネルの数が数が望んでいた以下を予約したならセットしてください、ロックするように言い足してください。
[5] If number of channels reserved greater than zero.
[5] チャンネルの数がゼロ以上を予約したなら。
[1] Build an add request. If the answerer the request
includes the phone numbers for the caller to dial.
[1] 建ててください、要求を加えてください。 answererであるなら、要求は訪問者がダイヤルする電話番号を含んでいます。
[2] If caller, go to ADD:A.
[2] 訪問者であるなら、ADDに行ってください: A。
[3] If answerer, go to ADD:C.
[3] answererであるなら、ADDに行ってください: C。
[6] Go to IDLE state.
[6] IDLE状態に行ってください。
Smith Informational [Page 28] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[28ページ]のRFC1934マルチリンクプロトコルと1996年4月
Enter Remove [remote] Action
入る、[リモート]の動作を取り除いてください。
The remote unit is initiating a remove transaction. The
incoming message contains the number of channels to remove.
リモート単位はaを開始するとトランザクションが取り除かれるということです。 入力メッセージは免職するチャンネルの数を含んでいます。
[1] Clear the remove lock.
[1] クリアしてください、錠を取り外してください。
[2] Restart the idle timer.
[2] 使用されていないタイマを再開してください。
[3] Request the number of channels required. If greater
than the number available after removing the number of
channels indicated in the incoming message reduce the
number of channels to remove.
[3] チャンネルの数が必要であるよう要求してください。 入力メッセージで示されたチャンネルの数を取り除いた後に有効な数より大きいなら、取り外すためにチャンネルの数を減少させてください。
[4] Build a remove response message indicating the number
of channels we will allow the requester to remove and
send to the remote.
[4] aがリモートに移して、送るために私たちがリクエスタを許すつもりであるチャンネルの数を示す応答メッセージを移す体格。
[5] Go to REMOVE, sub-state B.
[5] 削除、サブ州のBに行ってください。
Enter Add [remote answerer] Action
Add[リモートanswerer]動作に入ってください。
We've received a message from the remote requesting that
bandwidth be added. The message contains the number of
channels to add. Since the remote is the answerer, the mes-
sage also contains the phone nubmers to dial. We may dial
less than the number requested.
私たちはリモート要求からの帯域幅が加えられるというメッセージを受け取りました。 メッセージは加えるチャンネルの数を含んでいます。 以来リモートことがanswererである、また、mes賢人は電話nubmersをダイヤルに含みます。 私たちは数が要求した以下にダイヤルするかもしれません。
[1] Restart idle timer.
[1] 使用されていないタイマを再開してください。
[2] If the number of channels requested will put us over
the maximum number of channels allowed for the session
reduce the channel count.
[2] 要求されたチャンネルの数が私たちを渡航するなら、セッションのために許容されたチャンネルの最大数はチャンネルカウントを抑えます。
[3] For each channel to add,
[3] それぞれに関して、加えるには、精神を集中してください。
[1] Integrate the phone number returned from the
answerer with the original phone number dialed.
[1] 元の電話番号がダイヤルされている状態でanswererから返された電話番号を統合してください。
[2] Request that a session be extended by dialing
the integrated phone number. A callback is
passed with the request so call success or fail-
ure can be reported back to MP+.
[2] セッションが統合電話番号にダイヤルすることによって延ばされるよう要求してください。 コールバックは通過されて、したがって、要求で、成功が呼んでいるということであるかMPへの報告された後部が+であることができたならureに失敗してください。
[4] Go to ADD:B. Note: This change must actu-
ally occur before requesting the first outgoing call.
If not, the callback could be called (and ignored)
because the session is not in the correct state.
[4] 加えに行ってください: B。 以下に注意してください。 この変化は同盟国が最初の発信電話を要求しながら起こるactuがそうしなければなりません。 そうでなければ、セッションが正しい状態にないので、コールバックを呼ぶことができました(そして、無視されます)。
Smith Informational [Page 29] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[29ページ]のRFC1934マルチリンクプロトコルと1996年4月
Enter Add [remote caller] Action
Add[リモート訪問者]動作に入ってください。
We've received a message from the remote requesting that
bandwidth be added. The message contains the number of
channels to add. Since the remote is the caller, it needs
us to send the phone numbers to dial. We may send fewer
phone numbers than requested
私たちはリモート要求からの帯域幅が加えられるというメッセージを受け取りました。 メッセージは加えるチャンネルの数を含んでいます。 以来リモートことが訪問者である、それは私たちがダイヤルする電話番号を送る必要があります。 私たちは要求されているより少ない電話番号を送るかもしれません。
[1] Restart idle timer.
[1] 使用されていないタイマを再開してください。
[2] If the number of channels requested will put us over
the maximum number of channels allowed for the session
reduce the channel count.
[2] 要求されたチャンネルの数が私たちを渡航するなら、セッションのために許容されたチャンネルの最大数はチャンネルカウントを抑えます。
[3] Reserve the adjusted number of channels, retrieving
their phone numbers.
[3] 彼らの電話番号を検索して、チャンネルの調整された数を予約してください。
[4] If the number of channels reserved is less than the
adjusted number requested.
[4] チャンネルの数であるなら、予約されているのは、調整された数が要求した以下です。
[5] Build an add response message, including the phone
numbers for the channels we will let the caller add
and send it to the far end.
[5] 建ててください、応答メッセージを加えてください、私たちが訪問者にそれを遠端に加えて、送らせるつもりであるチャンネルのための電話番号を含んでいて。
[6] Go to ADD:C.
[6] 加えに行ってください: C。
Enter Idle Action
無駄な動きに入ってください。
The IDLE state is entered at the end of normal transactions.
At entry the current status of the connection should be
checked and new transactions initiated if necessary. To be
safe, we can also use this state as a catch all place to
release any bandwidth reserved for adds. The functions to
perform are:
IDLE状態は正常なトランザクションの終わりに入れられます。 エントリーでは、接続の現在の状態が必要なら、開始されたチェックの、そして、新しいトランザクションであるべきです。 また、安全に、なるように、すべてが予約されていた状態でどんな帯域幅もリリースするために置くキャッチが加えるように私たちはこの状態を使用できます。 実行する機能は以下の通りです。
[1] Restart the idle timer using the current retry value.
[1] 現在の再試行値を使用して、使用されていないタイマを再開してください。
[2] Release any reserved bandwidth not actually in use.
[2] 実際に使用中でないあらゆる予約された帯域幅をリリースしてください。
[3] Check if bandwidth change reqested during last trans-
action. If change indicated:
[3] 帯域幅変化が最後の移-動作の間、reqestedされたかどうかチェックしてください。 変化は示しました:
[1] Query channel counts.
[1] チャンネルカウントについて質問してください。
[2] If current bandwidth less than suggested band-
width and removes are not locked, store the
requested bandwidth and initiate a remove trans-
action (Enter Remove Action).
要求された帯域幅を保存して、示されるより少ない現在の帯域幅が幅を括って、取り外されるなら、[2]はロックされません、そして、開始aは移-動作を取り除きます(Remove Actionに入ってください)。
Smith Informational [Page 30] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[30ページ]のRFC1934マルチリンクプロトコルと1996年4月
[3] If current bandwidth greater than suggested
bandwidth and adds are not locked:
[3] 現在の帯域幅示されるより大きい帯域幅である、加える、ロックされません:
[1] Store the requested bandwidth.
[1] 要求された帯域幅を保存してください。
[2] Intiate an add transaction (Enter Add
[local] Action).
[2] Intiate、トランザクションを加えてください(Addの[地方]の動作に入ってください)。
[4] Go to the IDLE state.
[4] IDLE状態に行ってください。
Remote Management Request Action
リモート管理は動作を要求します。
We received a request to start/stop remote management.
If this is a start request
If we can/allow remote management:
Build and send a Remote management response Allow
message.
Else
Build and send a Remote management response Deny
message.
Else (this is a stop)
Notify the remote management slave process to terminate.
私たちはリモート管理を始めるか、または止めるという要求を受け取りました。 私たちはこれによる始めがIfを要求するということであるならそうすることができます。/はリモート管理を許容します: Remote管理応答Allowメッセージを築き上げて、送ってください。 そして、ほかのBuild、Remote管理応答Denyメッセージを送ってください。 ほかに(これは停止である)、通知してください。終えるリモート管理奴隷プロセス。
Remote Management Response Action
リモート管理応答動作
We received a response to our remote management start request.
If the response was an Allow response
Notify the remote management master process, we can
start sending keystrokes/commands
Else
The peer denied the request, so notify the remote
management master process of failure.
私たちは私たちのリモート管理スタート要求への応答を受けました。 応答がAllow応答であったなら、リモート管理がマスタリングするNotifyは処理します、私たちが、要求が否定された同輩のElseをキーストローク/コマンドに送り始めることができます、したがって、失敗のリモート管理マスタープロセスに通知してください。
Remote Management Receive Data Action
リモート管理受信データ動作
We (the slave) received data from the remote management master.
Pass the received data to the remote management slave process.
This is typically keystroke data received from the remote user
interface.
私たち(奴隷)はリモート管理マスターからデータを受け取りました。 リモート管理奴隷プロセスに受信データを通過してください。 通常、これはリモート・ユーザーインタフェースから受け取られたキーストロークデータです。
Remote Management Transmit Data Action
リモート管理はデータ動作を伝えます。
We (the master) received data from the remote management slave.
Pass the received data to the remote management master process.
This is typically screen-updates to be passed to the user
interface.
私たち(マスター)はリモート管理の奴隷からデータを受け取りました。 リモート管理マスタープロセスに受信データを通過してください。 通常、これはユーザーインタフェースに通過されるスクリーンアップデートです。
Smith Informational [Page 31] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[31ページ]のRFC1934マルチリンクプロトコルと1996年4月
Remote Management Transmit Data Response Action
リモート管理はデータ応答動作を伝えます。
We (the slave) received an ack to data we previously sent to the
master. Notify the remote management slave process so that it
can queue further transmissions.
私たち(奴隷)は以前にマスターに送ったデータにackを受け取りました。 さらなるトランスミッションを列に並ばせることができるように、リモート管理奴隷プロセスに通知してください。
Remote management (Master) start Action
リモート管理(マスター)はActionを始動します。
Build a REMOTE_MGMT_REQ start message and send to the far end.
Send a proceeding message to the RM master process.
REMOTE_MGMT_REQ開始メッセージを築き上げてください、そして、遠端に発信してください。 RMマスタープロセスに進行メッセージを送ってください。
Remote management (Slave) data Action
リモート管理(奴隷)データAction
Build a REMOTE_MGMT_TX_REQ message with the data passed from
the remote management slave process, send it to the far end.
データがリモート管理奴隷プロセスから通過されている状態で、REMOTE_MGMT_テキサス_REQメッセージを築き上げてください、そして、それを遠端に送ってください。
Remote management (Master) data Action
リモート管理(マスター)データAction
Build a REMOTE_MGMT_RX_REQ message with data passed from the
remote management master process, send it to the far end.
データがリモート管理マスタープロセスから通過されている状態で、REMOTE_MGMT_RX_REQメッセージを築き上げてください、そして、それを遠端に送ってください。
Remote management data acknowledgement Action
リモート管理データ承認Action
Build a REMOTE_MGMT_TX_RSP message and send it so the slave can
send the next block. There is no data associated with this
message.
REMOTE_MGMT_テキサス_RSPメッセージを築き上げてください、そして、奴隷が次のブロックを送ることができるように、それを送ってください。 このメッセージに関連しているどんなデータもありません。
Remote management (Master) stop Action
リモート管理(マスター)はActionを止めます。
Build a REMOTE_MGMT_REQ stop message and send to the far end.
REMOTE_MGMT_REQ停止メッセージを築き上げてください、そして、遠端に発信してください。
3.5.3. MP+STATE_INITIAL state machine
3.5.3. MP+州_INITIAL州のマシン
All sessions start from this state, sub-state A. The state is not exited until version exchange succeeds.
すべてのセッションがこの状態、サブ州のA.から始めます。バージョン交換が成功するまで、状態は出られません。
The sub-states are:
サブ州は以下の通りです。
A Initial state
B Sent version request, waiting for version response.
C Waiting for version request.
バージョン応答を待つInitial州のB Sentバージョン要求。 バージョン要求を待つC。
Smith Informational [Page 32] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[32ページ]のRFC1934マルチリンクプロトコルと1996年4月
Event Sub-state
______________________________________________________________________
A B C
======================================================================
MP+START_SESSION 1,+ ** **
______________________________________________________________________
MP+SESSION_DOWN ** 2,Initial:A 2,Initial:A
______________________________________________________________________
MP+SESSION_TERM ** 3,Initial:A 3,Initial:A
______________________________________________________________________
MP+TIMER_EXPIRED ** 4,Initial:A 7,Initial:B
______________________________________________________________________
MP+RX_VERSION_REQ ** 8,Initial:A 5,+
______________________________________________________________________
MP+RX_VERSION_RSP ** 6,+ **
______________________________________________________________________
MP+START_RM 9,* 9,* 9,*
______________________________________________________________________
All other events ** ** **
______________________________________________________________________
イベントサブ状態______________________________________________________________________ B C====================================================================== mp+ + スタート_セッション1、****______________________________________________________________________ + セッション_下に**2イニシャル: (A2)が頭文字をつけるMP: A______________________________________________________________________ _用語**3イニシャル: (A3)が頭文字をつけるMP+セッション: A______________________________________________________________________ : 7は、_の満期のMP+タイマ**4が: Bに頭文字をつけるのに頭文字をつけます。______________________________________________________________________ MP+RX_バージョン_REQ**8、: 5、+に頭文字をつけてください。______________________________________________________________________ + MP+RX_バージョン_RSP**6、**______________________________________________________________________ mp+始め_RM9、*9、*9、*______________________________________________________________________ 他のすべてのイベント******______________________________________________________________________
Table 2: Initial State Machine
テーブル2: 初期状態マシン
Actions:
動作:
1 Start timer, 60 seconds if originator, 30 seconds if answerer.
1 answererであるならタイマ、60秒を創始者、30秒であるなら始めてください。
Start MP+
MP+を始めてください。
If originator
創始者です。
Build and send version exchange request
バージョン交換要求を組み込んで、送ってください。
Go to INITIAL, sub-state B.
INITIAL、サブ州のBに行ってください。
Go to INITIAL, sub-state C.
INITIAL、サブ州のCまで行ってください。
2 Do Error Close Action, go to INITIAL, sub-state A.
2 Error Close Actionをしてください、そして、INITIAL、サブ州のAに行ってください。
3 Do Term Action, go to INITIAL, sub-state A.
3 Term Actionをしてください、そして、INITIAL、サブ州のAに行ってください。
4 Do Error Close Action, go to INITIAL, sub-state A.
4 Error Close Actionをしてください、そして、INITIAL、サブ州のAに行ってください。
5 Stop the idle timer.
5は使用されていないタイマを止めます。
Compare protocol versions, if they do not match Do Error Close
Action, go to INITIAL, sub-state A.
Do Error Close Actionを合わせないなら、プロトコルバージョンを比較してください、そして、INITIAL、サブ州のAに行ってください。
Smith Informational [Page 33] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[33ページ]のRFC1934マルチリンクプロトコルと1996年4月
Store off info received from remote.
かけ離れるのから受け取られたオフインフォメーションを保存してください。
Build a version exchange response and send to remote end.
バージョン交換応答を組み込んでください、そして、リモートエンドに発信してください。
Do Enter Idle Action which causes a state change.
州の変化を引き起こすEnter Idle Actionをしてください。
6 Stop the retry timer.
6は再試行タイマを止めます。
Compare protocol versions, if they do not match Do Error Close
Action, go to INITIAL, sub-state A.
Do Error Close Actionを合わせないなら、プロトコルバージョンを比較してください、そして、INITIAL、サブ州のAに行ってください。
Store off info received from remote.
かけ離れるのから受け取られたオフインフォメーションを保存してください。
Check the base channel count in the callers profile.
訪問者プロフィールでベースチャンネルカウントをチェックしてください。
If greater than 1
1より大きい
Set the requested bandwidth to the base channel count.
ベースチャンネルカウントに要求された帯域幅を設定してください。
Do Enter Add Caller action which causes a state change.
州の変化を引き起こす動作をEnter Add Callerにしてください。
Do Enter Idle Action which causes a state change.
州の変化を引き起こすEnter Idle Actionをしてください。
7 Both sides think they are the answerer. This is possible if both
dial each other at the same time and the first channel that
completed PPP negotiation happened to be the channel associated
with the incoming call on both units. We resolve this by trying
to become the originator.
If both sides try to become the originator the one with the
largest endpoint discriminator will fall back to being the
answerer.
7つの両側が、それらがanswererであると思います。 両方が同時に互いにダイヤルするなら、これは可能です、そして、第1代PPP交渉を終了したチャンネルはたまたま両方のユニットにおけるかかってきた電話に関連しているチャンネルでした。 私たちは、創始者になろうとすることによって、これを決議します。 両側が創始者になろうとすると、最も大きい終点弁別器があるものはanswererであることへ後ろへ下がるでしょう。
Restart Idle timer at 60 seconds
60秒にIdleタイマを再開してください。
Build and send Version Exchange Request message
バージョンExchange Requestメッセージを築き上げて、送ってください。
Go to Initial:B
: Bに頭文字をつけに行ってください。
8 Both sides think they are the originator. This can happen if
both dial each other at the same time and the first channel
that completed PPP negotiation happened to be the channel
associated with the originating call on both units. MP+
determines which will be the caller and which the answerer by
comparing the endpoind discriminator in the version exchange
request with the local endpoint discriminator. The unit with
the smaller endpoint is arbitrarily called the originator. The
actions are:
8つの両側が、彼らが創始者であると思います。 両方が同時に互いにダイヤルするなら、これは起こることができます、そして、第1代PPP交渉を終了したチャンネルはたまたま両方のユニットにおける起因する呼び出しに関連しているチャンネルでした。 MP+は、どれが訪問者になるだろうか、そして、バージョン交換でendpoind弁別器を比較するのによるanswererが地方の終点弁別器でどれを要求するかを決心しています。 より小さい終点があるユニットは任意に創始者と呼ばれます。 動作は以下の通りです。
Smith Informational [Page 34] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[34ページ]のRFC1934マルチリンクプロトコルと1996年4月
Compare local endpoint discriminator with endpoint discrimator
in message.
メッセージで地方の終点弁別器を終点discrimatorと比べてください。
If local endpoint discriminator is less than the remote value
we are the caller, ignore the incoming message.
地方の終点弁別器がリモート値以下であるなら、私たちは訪問者であり、入力メッセージを無視してください。
Otherwise, if local endpoint discriminator is greater than the
remote value we are the answerer:
さもなければ、地方の終点弁別器がリモート値より大きいなら、私たちはanswererです:
Compare protocol versions, if they do not match
Do Error Close Action, go to INITIAL, sub-state A.
Do Error Close Actionを合わせないなら、プロトコルバージョンを比較してください、そして、INITIAL、サブ州のAに行ってください。
Store off info received from remote.
かけ離れるのから受け取られたオフインフォメーションを保存してください。
Build a version exchange response and send to remote end.
バージョン交換応答を組み込んでください、そして、リモートエンドに発信してください。
Do Enter Idle Action which causes a state change.
州の変化を引き起こすEnter Idle Actionをしてください。
If the two values match, there is a problem, Do Error Close
Action,go to INITIAL, sub-state A.
Do Error Close Action、2つの値が合っているなら、問題があって、INITIAL、サブ州のAに行ってください。
9 Log an error message.
Notify the user interface of remote management failure.
9はエラーメッセージを登録します。 リモート管理失敗のユーザーインタフェースに通知してください。
3.5.4. MP+STATE_IDLE state machine
3.5.4. MP+州_IDLE州のマシン
The Idle state is the state of an active session with no call management activity in progress.
Idle状態は進行している呼び出し管理活動は活発なセッションの状態です。
There are no sub-states.
サブ州が全くありません。
Event State
_____________________________________________
A
=============================================
MP+SESSION_DOWN 1,Initial:A
_____________________________________________
MP+SESSION_TERM 2,Initial:A
_____________________________________________
MP+TIMER_EXPIRED 3,*
_____________________________________________
MP+UTILIZATION 4,+
_____________________________________________
MP+RX_ADD_REQ 5,+
_____________________________________________
MP+RX_REMOVE_REQ 6,Remove:B
_____________________________________________
MP+RX_RM_REQ 7,+
イベント状態_____________________________________________ A============================================= mp+セッション_イニシャル: 下に1、A_____________________________________________ イニシャル: _用語2MP+セッション、A_____________________________________________ MP+タイマ_は3、*を吐き出しました。_____________________________________________ mp+ 利用4、+_____________________________________________ MP+RX_は_REQ5、+を加えます。_____________________________________________ MP+RX_は_REQ6を取り外して、: Bを取り除いてください。_____________________________________________ + mp RX_RM_REQ7、+
Smith Informational [Page 35] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[35ページ]のRFC1934マルチリンクプロトコルと1996年4月
_____________________________________________ MP+RX_RM_RSP 8,+ _____________________________________________ MP+RX_RM_RX_REQ 9,+ _____________________________________________ MP+RX_RM_TX_REQ 10,+ _____________________________________________ MP+RX_RM_TX_RSP 11,+ _____________________________________________ MP+RX_CLOSE_REQ 12,+ _____________________________________________ MP+START_RM 13,* _____________________________________________ MP+SEND_RMS 14,* _____________________________________________ MP+SEND_RMM 15,* _____________________________________________ MP+RECV_RMM 16,* _____________________________________________ MP+STOP_RM 17,* _____________________________________________ All other events ** _____________________________________________
_____________________________________________ + mp RX_RM_RSP8、+_____________________________________________ mp+ RX_RM_RX_REQ9、+_____________________________________________ mp+ RX_RM_テキサス_REQ10、+_____________________________________________ mp+ RX_RM_テキサス_RSP11、+_____________________________________________ MP+RX_は_REQ12、+を閉じます。_____________________________________________ mp+始め_RM13、*_____________________________________________ _RMS14、*をmp+は送ります。_____________________________________________ _RMM15、*をmp+は送ります。_____________________________________________ mp+ RECV_RMM16、*_____________________________________________ mp+停止_RM17、*_____________________________________________ 他のすべてのイベント**_____________________________________________
Table 3: Idle State Machine
テーブル3: 使用されていない州のマシン
Actions:
動作:
1 Do Error Close Action, go to INITIAL, sub-state A.
1 Error Close Actionをしてください、そして、INITIAL、サブ州のAに行ってください。
2 Do Term Action, go to INITIAL, sub-state A.
2 Term Actionをしてください、そして、INITIAL、サブ州のAに行ってください。
3 Do Timer Action.
3はタイマ動作をします。
4 Note that a bandwidth change has been reqested.
4は、帯域幅変化がreqestedされたことに注意します。
Do Enter Idle Action which may cause a state change.
州の変化を引き起こすかもしれないEnter Idle Actionをしてください。
5 If we are the caller:
Do Enter Add [remote answerer] Action.
Else
Do Enter Add [remote caller] Action.
5 私たちが訪問者であるなら: Enter Add[リモートanswerer]に動作してください。 ほかのDo Enter Add[リモート訪問者]動作。
6 Do Enter Remove [remote] Action
6が入力される、[リモート]の動作を取り除いてください。
7 Do Remote Management Request Action
7はリモート管理要求動作をします。
8 Do Remote Management Response Action
8はリモート管理応答動作をします。
Smith Informational [Page 36] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[36ページ]のRFC1934マルチリンクプロトコルと1996年4月
9 Do Remote Management Receive Data Action
9はリモート管理受信データ動作をします。
10 Do Remote Management Transmit Data Action
10、リモート管理はデータ動作を伝えます。
11 Do Remote Management Transmit Data Response Action
11、リモート管理はデータ応答動作を伝えます。
12 Clear remove lock.
If local recommended channels == 0, then:
send a Close Response message with OK To Close
set to TRUE.
Else
send a Close Response message with OK To Close
set to FALSE.
Do Enter Idle Action.
12を儲けます。錠を取り外してください。 0、ローカルのお勧めのチャンネル=その時なら: TRUEに用意ができているOK To CloseがあるClose Responseメッセージを送ってください。 ほかに、発信してください。OK To CloseがあるClose ResponseメッセージはFALSEにセットしました。 無駄な動きに入ってください。
13 Do Remote management (Master) start Action
13はRemote管理(マスター)スタートActionをします。
14 Do Remote management (Slave) data Action
14はRemote管理(奴隷)データActionをします。
15 Do Remote management (Master) data Action
15はRemote管理(マスター)データActionをします。
16 Do Remote management data acknowledgement Action
16はRemote管理データ承認Actionをします。
17 Do Remote management (Master) stop Action
17はRemote管理(マスター)停止Actionをします。
3.5.5. MP+STATE_ADD state machine
3.5.5. MP+州_ADD州のマシン
The add state is used by both caller and answerer when an add transaction is in progress.
状態が訪問者とanswererの両方によって使用されると言い足してください、いつ、トランザクションが進行していると言い足してくださいか。
The sub-states are:
サブ州は以下の通りです。
A Add request sent to answerer, waiting for add response
from the answerer.
B Caller waiting for call complete notification for calls
placed.
C Answerer waiting for add complete message from caller.
Add要求がanswerer、待ちに発信した、answererから応答を加えてください。 呼び出しのための完全な通知がした電話のB訪問者の待ち。 C、より多くのAnswererに待っている、訪問者から完全なメッセージを加えてください。
Smith Informational [Page 37] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[37ページ]のRFC1934マルチリンクプロトコルと1996年4月
Event Sub-state
______________________________________________________________________
A B C
======================================================================
MP+SESSION_DOWN 1,Initial:A 7,Closing:A 1,Initial:A
______________________________________________________________________
MP+SESSION_TERM 2,Initial:A 7,Closing:B 2,Initial:A
______________________________________________________________________
MP+TIMER_EXPIRED 3,+ 3,+ 3,+
______________________________________________________________________
MP+UTILIZATION 4,* 4,* 4,*
______________________________________________________________________
MP+CALL_COMPLETE ** 8,Idle:A **
______________________________________________________________________
MP+RX_VERSION_REQ -,* ** **
______________________________________________________________________
MP+ADD_REQ 5,Add:B ** **
______________________________________________________________________
MP+ADD_RSP 6,+ ** **
______________________________________________________________________
MP+ADD_COMP ** ** 9,Idle:A
______________________________________________________________________
MP+RX_RM_REQ 10,+ 10,+ 10,+
______________________________________________________________________
MP+RX_RM_RSP 11,+ 11,+ 11,+
______________________________________________________________________
MP+RX_RM_RX_REQ 12,+ 12,+ 12,+
______________________________________________________________________
MP+RX_RM_TX_REQ 13,+ 13,+ 13,+
______________________________________________________________________
MP+RX_RM_TX_RSP 14,+ 14,+ 14,+
______________________________________________________________________
MP+RX_REMOVE_REQ -,* ** **
______________________________________________________________________
MP+START_RM 15,* 15,* 15,*
______________________________________________________________________
MP+SEND_RMS 16,* 16,* 16,*
______________________________________________________________________
MP+SEND_RMM 17,* 17,* 17,*
______________________________________________________________________
MP+RECV_RMM 18,* 18,* 18,*
______________________________________________________________________
MP+STOP_RM 19,* 19,* 19,*
______________________________________________________________________
All other events ** ** **
______________________________________________________________________
イベントサブ状態______________________________________________________________________ B C====================================================================== + セッション_下に1閉鎖: (イニシャル: A7、A1)が頭文字をつけるMP: A______________________________________________________________________ _用語2閉鎖: (イニシャル: A7、B2)が頭文字をつけるMP+セッション: A______________________________________________________________________ mp+タイマ+ _満期の3、+ 3、3、+______________________________________________________________________ mp+利用4、*4、*4、*______________________________________________________________________ 怠けてください: MP+呼び出し_は**8を完成して、**______________________________________________________________________ MP+RX_バージョン_REQ、-、*****______________________________________________________________________ mp+が_追加:、REQ5、B***を加える、*______________________________________________________________________ + _RSP6、****をmp+は加えます。______________________________________________________________________ mp+は_コンピュータ****9を加えて、: Aを空費してください。______________________________________________________________________ + + MP+RX_RM_REQ10、10、10、+______________________________________________________________________ + + MP+RX_RM_RSP11、11、11、+______________________________________________________________________ mp+ + + RX_RM_RX_REQ12、12、12、+______________________________________________________________________ mp+ + + RX_RM_テキサス_REQ13、13、13、+______________________________________________________________________ mp+ + + RX_RM_テキサス_RSP14、14、14、+______________________________________________________________________ MP+RX_が_REQを取り外す、-、*****______________________________________________________________________ mp+始め_RM15、*15、*15、*______________________________________________________________________ _RMS16、*16、*16、*をmp+は送ります。______________________________________________________________________ _RMM17、*17、*17、*をmp+は送ります。______________________________________________________________________ mp+ RECV_RMM18、*18、*18、*______________________________________________________________________ mp+停止_RM19、*19、*19、*______________________________________________________________________ 他のすべてのイベント******______________________________________________________________________
Table 4: Add State Machine
テーブル4: 州のマシンを加えてください。
Smith Informational [Page 38] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[38ページ]のRFC1934マルチリンクプロトコルと1996年4月
Actions:
動作:
1 Phone numbers (may) have been reserved, they must be released
before the normal error processing occurs.
1電話番号(may)が予約されて、通常のエラー処理が起こる前にそれらをリリースしなければなりません。
Release all reserved phone numbers
すべての予約された電話番号をリリースしてください。
Do Error Close Action.
誤りの厳密な動作をしてください。
2 Phone nubmers (may) have been reserved, they must be released
before the normal close processing occurs.
2電話nubmers (may)は予約されて、通常の厳密な処理が起こる前にそれらをリリースしなければなりません。
Release all reserved phone numbers
すべての予約された電話番号をリリースしてください。
Do Term Action.
用語動作をしてください。
3 Do Timer Action
3はタイマ動作をします。
4 Note that a bandwidth change has been reqested. This will be
processed the next time IDLE state is entered.
4は、帯域幅変化がreqestedされたことに注意します。 これはIDLE状態が入られる次の時に処理されるでしょう。
5 An add collision has occured. Since the answerer has sent phone
numbers we will try to use what he as sent, within the limits of
the local system.
5、衝突がoccuredされたと言い足してください。 answererが電話番号を送ったので、私たちはことを使用しようとするでしょう。ローカルシステムの限界の中で送られる彼。
Compare local channels to add with current channels to
add.
加えるために現在のチャンネルで加えるために市内回線を比較してください。
If the local channels to add is less than the remote
channels to add
加える市内回線であるなら、リモートチャンネル以下は加えることになっていますか?
If the remote number of channels requested will
put us over the maximum number of channels
allowed for the session reduce the channel count
and set an add lock.
要求されたチャンネルのリモート数が私たちを渡航するなら、セッションのために許容されたチャンネルの最大数がチャンネルカウントを抑えて、セットする、ロックするように言い足してください。
Re-reserve the channels. If the number reserved
are less than the number of phone numbers
provided by the far end, set an add lock and
reduce the number of channels to add to what we
could reserve.
チャンネルを再予約してください。 予約された数が遠端によって提供された電話番号の数より少ないなら、セットしてください、私たちが予約できたことに加えるためにチャンネルの数をロックして、減少させるように言い足してください。
Now treat the remote add request as if it were an add
response and process by:
今度は、扱ってください、まるでそれがあるかのようにリモートが要求を加える、応答を加えてください、そして、以下で処理してください。
Integrate the phone number returned from the
answerer with the original phone number dialed.
元の電話番号がダイヤルされている状態でanswererから返された電話番号を統合してください。
Smith Informational [Page 39] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[39ページ]のRFC1934マルチリンクプロトコルと1996年4月
Request that a session be extended by dialing
the integrated phone number. A callback is
passed with the request so call success or
failure can be reported back to MP+.
セッションが統合電話番号にダイヤルすることによって延ばされるよう要求してください。 コールバックは、成功に電話をしてください。さもないと、MP+に失敗の報告を持ちかえることができるように要求で通過されます。
Go to ADD:B. Note: This change must actually
occur before requesting the first outgoing call.
If not, the callback could be called (and
ignored) because the session is not in the
correct state.
加えに行ってください: B。 以下に注意してください。 最初の発信電話を要求する前に、この変化は実際に起こらなければなりません。 そうでなければ、セッションが正しい状態にないので、コールバックを呼ぶことができました(そして、無視されます)。
6 If the answerer provided fewer phone numbers than requested set
an add lock.
answererが要求されているより少ない電話番号を提供したなら6がセットした、ロックするように言い足してください。
If the number of channels is zero send an add complete message
(there's nothing to do) and go to the IDLE state.
チャンネルの数がゼロであるなら発信してください、完全なメッセージを追加してください、そして、(何もすることがありません)IDLE状態に行ってください。
For each phone number returned
返された各電話番号のために
Integrate the phone number returned from the answerer
with the original phone number dialed.
元の電話番号がダイヤルされている状態でanswererから返された電話番号を統合してください。
Request that a session be extended by dialing the
integrated phone number. A callback is passed with the
request so call success or failure can be reported back
to MP+.
セッションが統合電話番号にダイヤルすることによって延ばされるよう要求してください。 コールバックは、成功に電話をしてください。さもないと、MP+に失敗の報告を持ちかえることができるように要求で通過されます。
Go to ADD:B. Note: This change must actually occur before
requesting the first outgoing call. If not, the callback could
be called (and ignored) because the session is not in the correct
state.
加えに行ってください: B。 以下に注意してください。 最初の発信電話を要求する前に、この変化は実際に起こらなければなりません。 そうでなければ、セッションが正しい状態にないので、コールバックを呼ぶことができました(そして、無視されます)。
7 Restart idle timer for abort.
7はアボートのために使用されていないタイマを再開します。
8 Increment the count of calls completed.
8は終了する呼び出しのカウントを増加します。
If the call succeeded, increment the count of calls that
succeeded.
呼び出しが成功したなら、成功した呼び出しのカウントを増加してください。
If the count of calls completed equals the number of calls placed
呼び出しのカウントが呼び出しの数が置いた同輩を完成したなら
If number of calls completed is not the same as the
nubmer that succeeded set an add lock.
終了する呼び出しの数が成功したnubmerがセットしたのと同じでない、ロックするように言い足してください。
Build an add complete message and send it to the far end.
成型、完全なメッセージを加えてください、そして、それを遠端に送ってください。
If at least one channel was added clear any remove lock.
少なくとも1個のチャンネルがはっきりと加えられたなら、いずれも錠を取り外します。
Smith Informational [Page 40] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[40ページ]のRFC1934マルチリンクプロトコルと1996年4月
Go to the IDLE state.
IDLE状態に行ってください。
9 If number of channels requested not equal to number connected
set add lock.
数の連結集合と等しくない要求されたチャンネルの数が加えるなら、9はロックされます。
If at least one channel was added clear any remove lock.
少なくとも1個のチャンネルがはっきりと加えられたなら、いずれも錠を取り外します。
Go to the IDLE state.
IDLE状態に行ってください。
10 Do Remote Management Request Action
10はリモート管理要求動作をします。
11 Do Remote Management Response Action
11はリモート管理応答動作をします。
12 Do Remote Management Receive Data Action
12はリモート管理受信データ動作をします。
13 Do Remote Management Transmit Data Action
13、リモート管理はデータ動作を伝えます。
14 Do Remote Management Transmit Data Response Action
14、リモート管理はデータ応答動作を伝えます。
15 Do Remote management (Master) start Action
15はRemote管理(マスター)スタートActionをします。
16 Do Remote management (Slave) data Action
16はRemote管理(奴隷)データActionをします。
17 Do Remote management (Master) data Action
17はRemote管理(マスター)データActionをします。
18 Do Remote management data acknowledgement Action
18はRemote管理データ承認Actionをします。
19 Do Remote management (Master) stop Action
19はRemote管理(マスター)停止Actionをします。
3.5.6. MP+STATE_REMOVE state machine
3.5.6. MP+州_、削除、州のマシン
The state of a session while processing a remove transaction.
セッションの州はaを処理している間、トランザクションを取り除きます。
The sub-states are:
サブ州は以下の通りです。
A Remove request sent, waiting for remove response
B Remove response sent, waiting for remove complete
Remove応答が送った応答Bを取り除いて、待つのを待っていて、Remove要求が発信した、完全な状態で、取り外してください。
Smith Informational [Page 41] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[41ページ]のRFC1934マルチリンクプロトコルと1996年4月
Event Sub-state
_________________________________________________________
A B
=========================================================
MP+SESSION_DOWN 1,Initial:A 1,Initial:A
_________________________________________________________
MP+SESSION_TERM 2,Initial:A 2,Initial:A
_________________________________________________________
MP+TIMER_EXPIRED 3,+ 3,+
_________________________________________________________
MP+UTILIZATION 4,* 4,*
_________________________________________________________
MP+RX_ADD_REQ 5,+ **
_________________________________________________________
MP+RX_REMOVE_REQ 6,+ **
_________________________________________________________
MP+RX_REMOVE_RSP 7,Idle:A **
_________________________________________________________
MP+RX_REMOVE_COMP ** 8,Idle:A
_________________________________________________________
MP+RX_CLOSE_REQ -,* **
_________________________________________________________
MP+RX_RM_REQ 9,* 9,*
_________________________________________________________
MP+RX_RM_RSP 10,* 10,*
_________________________________________________________
MP+RX_RM_RX_REQ 11,* 11,*
_________________________________________________________
MP+RX_RM_TX_REQ 12,* 12,*
_________________________________________________________
MP+RX_RM_TX_RSP 13,* 13,*
_________________________________________________________
MP+START_RM 14,* 14,*
_________________________________________________________
MP+SEND_RMS 15,* 15,*
_________________________________________________________
MP+SEND_RMM 16,* 16,*
_________________________________________________________
MP+RECV_RMM 17,* 17,*
_________________________________________________________
MP+STOP_RM 18,* 18,*
_________________________________________________________
All other events ** **
_________________________________________________________
イベントサブ状態_________________________________________________________ B========================================================= + セッション_下に1イニシャル: (A1)が頭文字をつけるMP: A_________________________________________________________ _用語2イニシャル: (A2)が頭文字をつけるMP+セッション: A_________________________________________________________ mp+タイマ+ _満期の3、3、+_________________________________________________________ mp+利用4、*4、*_________________________________________________________ + _REQ5、**をMP+RX_は加えます。_________________________________________________________ + _REQ6、**をMP+RX_は取り除きます。_________________________________________________________ 怠けてください: MP+RX_は_RSP7を取り外して、**_________________________________________________________ MP+RX_は_コンピュータ**8を取り外して、: Aを空費してください。_________________________________________________________ MP+RX_閉鎖_REQ、-、***_________________________________________________________ + mp RX_RM_REQ9、*9、*_________________________________________________________ + mp RX_RM_RSP10、*10、*_________________________________________________________ mp+ RX_RM_RX_REQ11、*11、*_________________________________________________________ mp+ RX_RM_テキサス_REQ12、*12、*_________________________________________________________ mp+ RX_RM_テキサス_RSP13、*13、*_________________________________________________________ mp+始め_RM14、*14、*_________________________________________________________ _RMS15、*15、*をmp+は送ります。_________________________________________________________ _RMM16、*16、*をmp+は送ります。_________________________________________________________ mp+ RECV_RMM17、*17、*_________________________________________________________ mp+停止_RM18、*18、*_________________________________________________________ 他のすべてのイベント****_________________________________________________________
Table 5: Remove State Machine
テーブル5: 州のマシンを取り外してください。
Smith Informational [Page 42] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[42ページ]のRFC1934マルチリンクプロトコルと1996年4月
Actions:
動作:
1 Do Error Close Action
1 誤りの厳密な動作をしてください。
2 Do Term Action
2は用語動作をします。
3 Do Timer Action
3はタイマ動作をします。
4 Note that a bandwidth change has been reqested. This will be
processed the next time IDLE state is entered.
4は、帯域幅変化がreqestedされたことに注意します。 これはIDLE状態が入られる次の時に処理されるでしょう。
5 Our remove conflicted with the remote end Add. The add takes
preference.
衝突されて、取り外してください。5、私たち、リモートエンドAdd。 加えてください。好みで取ります。
Set a remove lock.
設定aは錠を取り外します。
If we are the caller Do Enter Add [remote answerer] Action .
私たちが訪問者Do Enter Add[リモートanswerer]動作であるなら。
Otherwise Do Enter Add [remote caller] Action .
そうでなければ、Do Enter Add[リモート訪問者]動作。
6 Two remove requests collided. We give preference to the caller
(an arbitrary decision).
2は要求を取り除きます。6、衝突しました。 私たちは訪問者(専断)に優先を与えます。
If caller, ignore message.
訪問者であるなら、メッセージを無視してください。
Else
Check maximum number of channels needed by the local end.
Reduce the requested remove count and set a remove lock if
necessary.
地方の終わりまでに必要であるほかのCheck最大数のチャンネル。 カウントを取り除いて、設定されて、要求を減少させてください。必要なら、aは錠を取り外します。
Build and send a remove response to the remote.
aを建てて、送ってください。リモートへの応答を取り除いてください。
Go to Remove:B.
取り外しに行ってください: B。
7 Compare the number of channels requested with the number allowed
in the response. If fewer allowed set a remove lock.
7は数が応答で許容されている状態で要求されたチャンネルの数を比較します。 設定aが許容されていないなら、錠を取り外してください。
Look at the current bandwidth. If the number to remove would
bring the current bendwidth below requirements reduce the number
of channels to remove.
現在の帯域幅を調べてください。 取り除く数が要件の下でbendwidthを決済するなら、取り外すためにチャンネルの数を減少させてください。
If still channels to remove:
Remove the channels.
Clear any add lock.
Send a remove complete indicating the number of channels removed.
それでも、取り外すチャンネルであるなら: チャンネルを免職してください。 はっきりと、いずれも、ロックするように言い足します。 aを送ってください。完全な状態で、チャンネルの数が取り外したのを示しながら、取り外してください。
8 If at least one channel was removed clear any add lock.
8 はっきりと少なくとも1個のチャンネルを免職したなら、いずれも、ロックするように言い足します。
Smith Informational [Page 43] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[43ページ]のRFC1934マルチリンクプロトコルと1996年4月
9 Do Remote Management Request Action
9はリモート管理要求動作をします。
10 Do Remote Management Response Action
10はリモート管理応答動作をします。
11 Do Remote Management Receive Data Action
11はリモート管理受信データ動作をします。
12 Do Remote Management Transmit Data Action
12、リモート管理はデータ動作を伝えます。
13 Do Remote Management Transmit Data Response Action
13、リモート管理はデータ応答動作を伝えます。
14 Do Remote management (Master) start Action
14はRemote管理(マスター)スタートActionをします。
15 Do Remote management (Slave) data Action
15はRemote管理(奴隷)データActionをします。
16 Do Remote management (Master) data Action
16はRemote管理(マスター)データActionをします。
17 Do Remote management data acknowledgement Action
17はRemote管理データ承認Actionをします。
18 Do Remote management (Master) stop Action
18はRemote管理(マスター)停止Actionをします。
3.5.7. MP+STATE_CLOSE state machine
3.5.7. MP+州_CLOSE州のマシン
The close state is used when we are gracefully closing a session or when we were notified that a session terminated mid-transaction.
近い状態は私たちが優雅にセッションかいつを終えているかとき、使用されて、私たちがセッションが中間のトランザクションを終えたことに通知されたということです。
The sub-states are:
サブ州は以下の通りです。
A Waiting for call complete after session down notification
B Waiting for call complete after session terminate
notification.
C Waiting for close response after session close request
sent.
セッションの後に完全な呼び出しのためのWaitingが通知を終えるというセッション下に通知Bの後に完全な呼び出しのためのWaiting。 セッションの厳密な要求の後に厳密な応答を待つCが発信しました。
Event Sub-state
______________________________________________________________________
A B C
======================================================================
MP+SESSION_DOWN ** -,* 7,Initial:A
______________________________________________________________________
MP+SESSION_TERM 1,Close:B ** 8,Initial:A
______________________________________________________________________
MP+TIMER_EXPIRED 2,Initial:A 5,Initial:A 6,*
______________________________________________________________________
MP+UTILIZATION -,* -,* 9,*
______________________________________________________________________
MP+CALL_COMPLETE 3,+ 6,Initial:A **
______________________________________________________________________
MP+ADD_REQ ** -,* 10,+
イベントサブ状態______________________________________________________________________ B C====================================================================== MP+セッション_下に**、-、イニシャル: *7、A______________________________________________________________________ _用語1閉鎖: (B**8)が頭文字をつけるMP+セッション: A______________________________________________________________________ MP+タイマ_は初期でイニシャル: 2、A5を吐き出しました: A6、*______________________________________________________________________ MP+利用、-、*、-、*9、*______________________________________________________________________ MP+呼び出し_は初期で+ 3、6を完成します: **______________________________________________________________________ mp+が_REQ**を加える、-、*10、+
Smith Informational [Page 44] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[44ページ]のRFC1934マルチリンクプロトコルと1996年4月
______________________________________________________________________ MP+REMOVE_REQ ** ** 11,Remove:B ______________________________________________________________________ MP+CLOSE_REQ -,* -,* 12,* ______________________________________________________________________ MP+CLOSE_RSP -,* -,* 13,+ ______________________________________________________________________ MP+START_RM 4,* 4,* 4,* ______________________________________________________________________ All other events ** ** ** ______________________________________________________________________
______________________________________________________________________ mp+は_REQ****11を取り除いて、: Bを取り除いてください。______________________________________________________________________ _MP+閉鎖REQ、-、*、-、*12、*______________________________________________________________________ _MP+閉鎖RSP、-、*、-、*13、+______________________________________________________________________ mp+始め_RM4、*4、*4、*______________________________________________________________________ 他のすべてのイベント******______________________________________________________________________
Table 6: Close State Machine
テーブル6: 近い州のマシン
Actions:
動作:
1 The session was closed while waiting for call completes.
Just go to Close:B.
セッションは電話を待つ間、終えられました。1、終了します。 ただCloseに行ってください: B。
2 We timed out waiting for completes. Just process the link down,
now.
Do Error Close Action.
私たちが出かけている待ちを調節した2、完成します。 まさしくリンクが現在倒すプロセス。 誤りの厳密な動作をしてください。
3 Increment the number of calls complete.
3は完全な状態で呼び出しの数を増加します。
If equal to the number of calls placed then:
Do Error Close Action, go to Initial:A.
Else
No state change.
呼び出しの数への同輩がその時入賞したなら: Initialに行ってください: Error Close Actionをしてください、そして、A。 ほかのいいえ州の変化。
4 Log an error message.
Notify the user interface of remote management failure.
4はエラーメッセージを登録します。 リモート管理失敗のユーザーインタフェースに通知してください。
5 We didn't get all the notifications that we expect. Give up and
close the session anyway. Do Term Action .
5 私たちは予想するすべての通知を得ませんでした。 とにかくセッションをあきらめて、終えてください。 用語動作をしてください。
6 Increment the number of calls complete.
6は完全な状態で呼び出しの数を増加します。
If equal to the number of calls placed then:
Do Term Action, go to Initial:A.
Else
No state change
呼び出しの数への同輩がその時入賞したなら: Initialに行ってください: Term Actionをしてください、そして、A。 ほかのいいえ州の変化
7 Do Error Close Action
7は誤りの厳密な動作をします。
8 Do Term Action
8は用語動作をします。
9 Note that a bandwidth change has been reqested. This will be
9は、帯域幅変化がreqestedされたことに注意します。 これはそうでしょう。
Smith Informational [Page 45] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[45ページ]のRFC1934マルチリンクプロトコルと1996年4月
processed the next time IDLE state is entered.
IDLE状態が入られる次の時に処理されます。
10 This is an Add & Close collision. Add wins. Perform current
remote add action.
If we are originator
Do Add [Remote Answerer] Action
else
Do Add [Remote Caller] Action
10 これはAdd&Close衝突です。 勝利を加えてください。 電流リモートな状態で実行してください。動作を加えてください。 私たちが創始者Do Add[リモートAnswerer]の動作のほかのDo Add[リモートCaller]動作であるなら
11 This is a Remove & Close collision, the Remove will win:
Set remove lock to FALSE
Do Remove [Remote] Action.
11 これがRemove&Close衝突である、Removeは勝つでしょう: 設定されて、FALSE Do Removeの[リモート]の動作に錠を取り外してください。
12 This is a Close collision. But since we both agree:
If we are originator
Send a Close Response with okToClose set to TRUE.
Else
Send a Close Response with okToClose set to FALSE.
12 これはClose衝突です。 私たち二人は以下に同意します。 私たちが創始者Sendであるなら、okToCloseとClose ResponseはTRUEにセットしました。 ほかに、okToCloseとSend a Close ResponseはFALSEにセットしました。
13 If Close Response is received with okToClear is TRUE then:
Do Term Action
Else
set remove lock to TRUE and do Enter Idle Action.
okToClearと共にClose Responseを受け取るなら、その時、13はTRUEです: Term Action Elseセットは、TRUEに錠を取り外して、Enter Idle Actionをしますか?
4. PPP LCP Extensions
4. ppp LCP拡張子
MP+ Configuration Option
MP+設定オプション
The Multilink Protocol Plus introduces the use of an additional LCP Configuration Option:
MultilinkプロトコルPlusは追加LCP Configuration 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 = 22 | length = 4 | Currently unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =22をタイプしてください。| 長さ=4| 現在、未使用です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: MP+ Option
図21: MP+オプション
Type - 22.
タイプしてください--22。
NOTE: The current implementation uses option 0. This is not an assigned number, so an IANA assigned official identifier has been obtained (22).
以下に注意してください。 現在の実装はオプション0を使用します。 これが規定番号でないので、公式の識別子が割り当てられたIANAを入手しました。(22)。
The option, when sent to a peer, advises the peer that:
同輩に送ると、オプションは、以下のことと同輩に忠告します。
the unit is capable of running the MP+ protocol;
ユニットはMP+プロトコルを実行できます。
Smith Informational [Page 46] RFC 1934 Multilink Protocol Plus April 1996
スミス情報[46ページ]のRFC1934マルチリンクプロトコルと1996年4月
The peer can accept or reject the option.
同輩は、オプションを受け入れるか、または拒絶できます。
NOTE: The MP+ option MUST NOT be included unless MP is also negotiated.
以下に注意してください。 また、MPが交渉されない場合、MP+オプションを含んではいけません。
5. Security Considerations
5. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
6. References
6. 参照
[1] K. Sklower, B. Lloyd, G. McGregor, D. Carr, "The PPP Multilink
Protocol (MP)".
[1] K.Sklower、B.ロイド、G.マクレガー、D.カー、「pppマルチリンクは(MP)について議定書の中で述べます」。
[2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, Daydreamer, July 1994.
[2] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、空想家、1994年7月。
7. Author's Address
7. 作者のアドレス
Kevin Smith Ascend Communications 1275 Harbor Bay Parkway Alameda, CA 94502
ケビン・スミスはParkwayアラメダ、コミュニケーション1275港Bayカリフォルニア 94502を昇ります。
Phone: (510) 769-6001 FAX: (510) 814-2300 EMail: ksmith@ascend.com
以下に電話をしてください。 (510) 769-6001 Fax: (510) 814-2300 メールしてください: ksmith@ascend.com
Smith Informational [Page 47]
スミスInformationalです。[47ページ]
一覧
スポンサーリンク
