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