RFC2701 日本語訳

Network Working Group                                         G. Malkin
Request for Comments: 2701                              Nortel Networks
Category: Informational                                  September 1999

コメントを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 2701 ノーテルはカテゴリをネットワークでつなぎます: 情報の1999年9月

                            Nortel Networks
          Multi-link Multi-node PPP Bundle Discovery Protocol

ノーテルはマルチリンクマルチノードpppバンドル発見プロトコルをネットワークでつなぎます。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

Abstract

要約

   This document specifies a standard way for Multi-link PPP to operate
   across multiple nodes.  Both the mechanism by which the Bundle Head
   is discovered and the PPP fragment encapsulation are specified.

このドキュメントはMulti-リンクPPPが複数のノードの向こう側に作動する標準の方法を指定します。 Bundle Headが発見されるメカニズムとPPP断片カプセル化の両方が指定されます。

Acknowledgements

承認

   I would like to thank Joe Frazier for filling in some of the details
   and reviewing this document.

詳細のいくつかに記入して、このドキュメントを再検討して頂いて、ジョー・フレージャーに感謝申し上げます。

1.  Introduction

1. 序論

   Multi-link PPP [MP] allows a dial-in user to open multiple PPP
   connections to a given host.  In general, this is done on an on-
   demand basis.  That is, a secondary link, or multiple secondary
   links, are established when the data load on the primary link, and
   any previously established secondary links, nears capacity.  As the
   load decreases, the secondary link(s) may be disconnected.

マルチリンクPPP[MP]はダイヤルインのユーザに複数のPPP接続を与えられたホストに公開させます。 一般に、これが完了している、オンである、要求基礎。 プライマリリンク、およびどんな以前に確立したセカンダリリンクの上のデータ負荷が容量に近づくとき、すなわち、セカンダリリンク、または複数のセカンダリリンクが確立しています。 負荷が減少するのに従って、セカンダリリンク切断されるかもしれません。

   Many dial-in hosts which support multi-link PPP dial the same phone
   number for all links.  This implies that there exists a rotary at the
   Point Of Presence (POP) which routes incoming calls to a bank of
   modems.  These may be physically independent modems connected to
   Remote Access Server (RAS) and a rotary of analog phone lines, or a
   RAS with internal modems connected to analog lines or a T1/E1 or
   T3/E3 channel.  In any case, a given RAS can only handle just so many
   simultaneous connections.  A typical POP may need to support hundreds
   of connections, but no RAS today can handle that many.  This creates
   a problem when a user's primary PPP connection is established to one

マルチリンクPPPをサポートする多くのダイヤルインのホストがすべてのリンクに同じ電話番号にダイヤルします。 これは、モデムの列にかかってきた電話を発送するPoint Of Presence(POP)のロータリーが存在するのを含意します。これらは、Remote Access Server(RAS)につなげられた肉体的に独立しているモデムとアナログの電話回線のロータリー、または内部のモデムがアナログの系列、1T1/Eまたは3T3/Eのチャンネルに接続されるRASであるかもしれません。 どのような場合でも、与えられたRASはちょうどとても多くの同時接続を扱うことができるだけです。 典型的なPOPは、何百もの接続をサポートする必要があるかもしれませんが、今日のどんなRASも多くそれを扱うことができません。 ユーザのプライマリPPP接続が1つに確立されるとき、これは問題を生じさせます。

Malkin                       Informational                      [Page 1]

RFC 2701                          MMP                     September 1999

[1ページ]RFC2701MMP1999年9月の情報のマルキン

   RAS in a POP and a secondary connection is established to another.
   This may occur because the first RAS has no available modems, or
   because incoming calls are assigned to ports in a round-robin
   fashion, for example, and the second call is simply assigned to
   another RAS.

POPとセカンダリ接続におけるRASは別のものに確立されます。 最初のRASにはどんな利用可能なモデムもないか、例えば、かかってきた電話が連続ファッションでポートに割り当てられて、または2番目の呼び出しが単に別のRASに割り当てられるので、これは起こるかもしれません。

   The solution to this problem is to provide a mechanism by which a RAS
   can determine if a Multi-link PPP connection is a primary or
   secondary and, if a secondary, where the Bundle Head (the process
   within a RAS which reassembles the PPP fragments transmitted over the
   primary and secondary links) resides.  If the Bundle Head resides on
   a different RAS, a protocol must be used to transfer the PPP
   fragments to the RAS containing the Bundle Head so that the PPP frame
   can be reassembled.

この問題への解決はRASがMulti-リンクPPP接続が予備選挙かそれとも2番目であるかを決定できるメカニズムとどこを2番目であるなら提供するかために、Bundle Head(プライマリの、そして、セカンダリのリンクの上に伝えられたPPP断片を組み立て直すRASの中のプロセス)が住んでいるということです。 Bundle Headが異なったRASに住んでいるなら、PPPフレームを組み立て直すことができるようにBundle Headを含むRASにPPP断片を移すのにプロトコルを使用しなければなりません。

   Section 2 of this document specifies the Discovery Mechanism.
   Section 3 specifies the Transfer Protocol.  Section 4 specifies the
   configuration parameters needed for the Discovery Protocol.

このドキュメントのセクション2はディスカバリーMechanismを指定します。 セクション3はTransferプロトコルを指定します。 セクション4はディスカバリープロトコルに必要である設定パラメータを指定します。

2.  Bundle Head Discovery Mechanism

2. バンドルヘッド発見メカニズム

   When a user dials into a RAS and negotiates Multi-link PPP (MP)
   during the Link Control Protocol (LCP) phase, the RAS must determine
   which one of the following three cases exists:

ユーザがRASにダイヤルして、Link Controlプロトコル(LCP)段階の間Multi-リンクPPP(MP)を交渉するとき、RASは、以下の3つのケースのどの1つが存在するかを決定しなければなりません:

   1- This is the primary (first) link of the MP connection.  In this
      case, the RAS should create the Bundle Head.

1 これはMP接続のプライマリ(最初に)のリンクです。 この場合、RASはBundle Headを作成するべきです。

   2- This is a secondary link of the MP connection and the Bundle Head
      resides on this RAS.  In this case, the RAS should add the link to
      the Bundle (standard MP).

2 これはMP接続のセカンダリリンクであり、Bundle HeadはこのRASに住んでいます。 この場合、RASはBundle(標準のMP)にリンクを加えるべきです。

   3- This is a secondary link of the MP connection and the Bundle Head
      resides on a different RAS.  In this case, the RAS should
      establish a path (see section 3) to the RAS that has the Bundle
      Head, and use that path to transfer MP fragments.

3 これはMP接続のセカンダリリンクであり、Bundle Headは異なったRASに住んでいます。 この場合、RASは、経路(セクション3を見る)をBundle Headを持っているRASに確立して、MP断片を移すのにその経路を使用するべきです。

   In operation, a RAS will make the determination for case 2 first
   (because it is the easiest and requires no communication with other
   RASes.  If the Bundle Head is not local, the Discovery Protocol is
   used to determine where the Bundle Head is, if it exists at all.

それは、最も簡単であり、他のRASesとのコミュニケーションを全く必要としません。RASが最初に稼働中であり、ケース2のための決断をする、(Bundle Headが地方でないなら、ディスカバリープロトコルはBundle Headがどこにあるかを決定するのに使用されます、少しでも存在しているなら。

Malkin                       Informational                      [Page 2]

RFC 2701                          MMP                     September 1999

[2ページ]RFC2701MMP1999年9月の情報のマルキン

2.1 Packet Format

2.1 パケット・フォーマット

   See "IANA Considerations" (section 6) for UDP port number assignment.

UDPポートナンバー課題に関して「IANA問題」(セクション6)を見てください。

   A Discovery Message has the following format:

ディスカバリーMessageには、以下の形式があります:

      +------+------+------------+------+----======----+
      | type |length| random ID  | hash | endpoint ID  |
      +------+------+------------+------+----======----+

+------+------+------------+------+----======----+ | タイプ|長さ| 無作為のID| ハッシュ| 終点ID| +------+------+------------+------+----======----+

   where:

どこ:

   type - 2 octets

タイプ--2つの八重奏

      Message type: 1-query, 2-response.

メッセージタイプ: 1質問と、2応答です。

   length - 2 octets

長さ--2つの八重奏

      The length (in octets) of the endpoint ID.

終点IDの長さ(八重奏における)。

   Random ID - 4 octets

無作為のID--4つの八重奏

      A random identifier generated by the RAS used to resolve
      contention.  See "Contention Handling" (section 2.4) for the use
      of this field.

RASによって生成された無作為の識別子は以前はよく主張を決議していました。 この分野の使用のための「主張取り扱い」(セクション2.4)を見てください。

   hash - 2 octets

ハッシュ--2つの八重奏

      The unsigned sum (modulo 2^16) of the unsigned octets of the
      Endpoint ID.  A value of zero indicates that no hash has been
      generated.  See "Endpoint Identifier Matching" (section 2.2) for
      the use of this field.

Endpoint IDの未署名の八重奏の未署名の合計(法2^16)。 ゼロの値は、ハッシュが全く生成されていないのを示します。 この分野の使用のための「終点識別子マッチング」(セクション2.2)を見てください。

   endpoint ID - variable length

終点ID--可変長

      The endpoint identifier of the connection.  From the discovery
      protocol's point of view, this is an opaque value.  However, to
      ensure multi-vendor interoperability, the format of this field
      must be defined.  The descriptions of, and legal values for, the
      fields in the endpoint ID are defined in [MP].

接続に関する終点識別子。 発見プロトコルの観点から、これは不透明な値です。 しかしながら、マルチベンダ相互運用性を確実にするために、この分野の書式を定義しなければなりません。 記述、正当な値、終点IDにおける分野は[MP]で定義されます。

Malkin                       Informational                      [Page 3]

RFC 2701                          MMP                     September 1999

[3ページ]RFC2701MMP1999年9月の情報のマルキン

         +------+------+--==--+------+------+--==--+------+--==--+
         |remote|remote|remote|local |local |local |user  | user |
         |EPD   |EPD   |EPD   |EPD   |EPD   |EPD   |name  | name |
         |class |length|data  |class |length|data  |length| data |
         +------+------+--==--+------+------+--==--+------+--==--+

+------+------+--==--+------+------+--==--+------+--==--+ |リモート|リモート|リモート|ローカル|ローカル|ローカル|ユーザ| ユーザ| |EPD|EPD|EPD|EPD|EPD|EPD|名前| 名前| |クラス|長さ|データ|クラス|長さ|データ|長さ| データ| +------+------+--==--+------+------+--==--+------+--==--+

      Notes:
         EPD = EndPoint Descriminator.
         remote = dial-in host.
         local = RAS.
         class and length fields are 1-octet in length.
         data fields are of variable (including zero) length.

注意: クラスと長さの分野は長さが1八重奏です。EPD=EndPoint Descriminatorリモート=ダイヤルインのホスト地方の=RASデータ・フィールドは可変な(ゼロを含んでいる)長さのものです。

   The MP protocol requires that the RASes all have the same Local EPD.
   For MMP, this implies that a RAS may not use its IP or Ethernet
   address as an EPD.  This also implies that all RASes on a rotary must
   have the same EPD.  RASes on different rotaries may share different
   EPDs.  The Local EPD is included in the endpoint identifier to ensure
   that RASes on different rotaries, but sharing a common Ethernet, will
   not join a particular discovery if the Remote EPDs just happen to be
   the same.

MPプロトコルは、RASesにはすべて、同じLocal EPDがあるのを必要とします。 MMPに関しては、これは、RASがEPDとしてそのIPかイーサネット・アドレスを使用しないかもしれないのを含意します。 また、これは、ロータリーのすべてのRASesには同じEPDがなければならないのを含意します。 異なったロータリーのRASesは異なったEPDsを共有するかもしれません。 Local EPDは異なったロータリーのそのRASesを確実にするために終点識別子に含まれていますが、一般的なイーサネットを共有して、Remote EPDsがただたまたま同じであるなら、特定の発見に参加しないでしょう。

   Except for unicast Response Messages, all messages are sent to the
   multicast address specified in "IANA Considerations".  If a system
   cannot send multicast messages, the limited broadcast address
   (255.255.255.255) should be used.

ユニキャストResponse Messagesを除いて、「IANA問題」で指定されたマルチキャストアドレスにすべてのメッセージを送ります。 システムがマルチキャストメッセージ、限られた放送演説を送ることができない、(255.255 .255 .255は)使用されるべきです。

2.2 Endpoint Identifier Matching

2.2 終点識別子マッチング

   Comparing Endpoint IDs can be time consuming.  First, the classes of
   the EPDs must be determined, then the values compared.  These
   comparisons might be fast arithmetic compares or slow octet-wise
   compares of 20-octet long values.  To improve performance, because
   the protocol is time-driven, the hash field may be used for a fast
   comparison.

Endpoint IDを比較するのは時間がかかっている場合があります。 まず最初にEPDsのクラスが決定しているに違いない、そして、値は比較されました。 これらの比較は、速い演算が比較されるということであるか八重奏が教えた状態で、遅くなるかもしれません。20八重奏の長い値を比較します。 プロトコルが時間駆動であるので性能を向上させるために、ハッシュ分野は速い比較に使用されるかもしれません。

   When a Bundle Head is created, the hash is created and stored along
   with the Endpoint ID.  When a Query or Response Message is generated,
   the hash is created and stored in the message.  When a RAS receives a
   message, it can do a quick comparison of the hash in the message to
   the hashes in its tables.  If a hash does not match, the Endpoint ID
   cannot match.  However, if a hash does match, the Endpoint IDs must
   be properly compared to verify the match.

Bundle Headが作成されるとき、ハッシュは、Endpoint IDと共に作成されて、保存されます。 QueryかResponse Messageが発生しているとき、ハッシュは、メッセージに作成されて、保存されます。 RASがメッセージを受け取るとき、それはテーブルでメッセージにおける、ハッシュの迅速な比較がハッシュにできます。 ハッシュが合っていないなら、Endpoint IDは合うことができません。 しかしながら、ハッシュが合っているなら、マッチについて確かめるために適切にEndpoint IDを比較しなければなりません。

Malkin                       Informational                      [Page 4]

RFC 2701                          MMP                     September 1999

[4ページ]RFC2701MMP1999年9月の情報のマルキン

   Obviously, there is a cost associated with creating the hashes, but
   they are created only once per message and once for each Bundle Head
   creation.  However, the comparisons occur multiple times in multiple
   RASes for each new secondary connection.  Therefore, there is a net
   savings in processing.

1メッセージあたりの一度、それぞれのBundle Head作成のためにいったんだけ明らかに、ハッシュを作成すると関連している費用がありますが、それらは作成されます。 しかしながら、比較はそれぞれの新しいセカンダリ接続のための複数のRASesに複数の回起こります。 したがって、処理には正味の貯蓄があります。

2.3 Protocol Operation

2.3 プロトコル操作

   Throughout this section, configurable variables are specified by
   their names (e.g., ROBUSTNESS refers to the number of transmits).

このセクション中では、構成可能な変数がそれらの名前によって指定される、(例えば、ROBUSTNESSが数を参照する、伝える、)

   The Discovery Protocol begins by multicasting ROBUSTNESS Query
   Messages at QUERY_INTERVAL intervals.  If no Response Message for
   that Request is received within QUERY_INTERVAL of the last broadcast
   (a total time of ROBUSTNESS * QUERY_INTERVAL), the RAS assumes that
   this is the primary link and begins to build the Bundle Head.  It
   then sends a multicast Response Message (in case another link comes
   up after the time-out but before the Bundle Head is built).  If a
   Response Message is received (i.e., a Bundle Head exists on another
   RAS), no additional Query Messages are sent and the RAS establishes a
   path to the RAS containing the Bundle Head.

QUERY_INTERVAL間隔を置いて、ディスカバリープロトコルはマルチキャスティングROBUSTNESS Query Messagesで始まります。 最後の放送(ROBUSTNESS*QUERY_INTERVALの合計時)のQUERY_INTERVALの中にそのRequestのためのResponse Messageを全く受け取らないなら、RASは、これがプライマリリンクであると仮定して、Bundle Headを造り始めます。 そして、それはマルチキャストResponse Messageを送ります(タイムアウトの後にもかかわらず、Bundle Headが組立している前を除いて、別のリンクが来るといけないので)。 Response Messageが受け取られているなら(すなわち、Bundle Headは別のRASに存在しています)、どんな追加Query Messagesも送りません、そして、RASはBundle Headを含むRASに経路を確立します。

   If a RAS receives a Query Message for an MP connection for which it
   has the Bundle Head, it sends a unicast Response Message to the
   querier.  Note that no repetition of the Response Message is
   necessary because, if it is lost, the querier's next query message
   will trigger a new Response Message.

RASがそれがBundle Headを持っているMP接続のためにQuery Messageを受けるなら、それはユニキャストResponse Messageをquerierに送ります。 それが無くなると、querierの次の質問メッセージが新しいResponse Messageの引き金となるので、Response Messageのどんな反復も必要でないことに注意してください。

2.4 Contention Handling

2.4 主張取り扱い

   If, while sending Query Messages, a Query Message for the same MP
   connection is received, it indicates that the Dial-in Node has
   brought up multiple links simultaneously.  The resolution to this
   contention is to elect the bundle head.  To do this, each RAS waits
   until all Query Messages are sent (ROBUSTNESS * QUERY_INTERVAL).  At
   that time, the RAS with the lowest Random ID becomes the Bundle Head.
   If two or more RASes have the same Random ID, the RAS with the lowest
   IP address becomes the Bundle Head.  That RAS then sends TWO Response
   Messages, with a QUERY_INTERVAL interval, and indicates to the MP
   process that a Bundle Head should be formed.  When the other RAS(es)
   receive the Response Message, they cease broadcasting (if they
   haven't already sent ROBUSTNESS Query Messages), stop listening for
   additional Response Messages, and indicate to their respective MP
   processes where the Bundle Head resides.

同じMP接続のためのQuery MessageがQuery Messagesを送る間、受け取られているなら、それは、中のDial Nodeが同時に複数のリンクを持って来たのを示します。 この主張への解決はバンドルヘッドを選出することです。 これをするために、各RASは(ROBUSTNESS*QUERY_INTERVAL)をすべてのQuery Messagesに送るまで待っています。 その時、最も低いRandom IDがあるRASはBundle Headになります。 2RASesに同じRandom IDがあるなら、最も低いIPアドレスがあるRASはBundle Headになります。 そしてそのRASは、QUERY_INTERVAL間隔があるTWO Response Messagesを送って、Bundle Headが形成されるべきであるのをMPプロセスに示します。 もう片方のRAS(es)がResponse Messageを受けるとき、彼らは、放送するのを(彼らが既にROBUSTNESS Query Messagesを送らないなら)やめて、追加Response Messagesの聞こうとするのを止めて、Bundle Headがどこに住んでいるかを自分達のそれぞれのMPプロセスに示します。

   Note that a RAS generates a Random ID for each connection and uses
   that value for all Query and Response messages associated with that
   connection.  The same Random ID must not be reused until it can be

RASが各接続のためにRandom IDを生成して、その接続に関連しているすべてのQueryとResponseメッセージにその値を使用することに注意してください。 それが再利用できるまで、同じRandom IDを再利用してはいけません。

Malkin                       Informational                      [Page 5]

RFC 2701                          MMP                     September 1999

[5ページ]RFC2701MMP1999年9月の情報のマルキン

   guaranteed that another RAS will not mistake the message for an old
   message from a previous connection.  For this reason, it is
   recommended that the Random ID be either monotonically increasing or
   a clock value (either time since boot or time of day).

別のRASが前の接続からメッセージを古いメッセージに間違えないのを保証しました。 この理由で、Random IDが単調にどちらかであることが増加しながらお勧めである、または時計は(ブーツ以来の時間か時刻のどちらか)を評価します。

2.5 MP Operation

2.5 MP操作

   MP must use the following algorithm to ensure that there are no
   windows of vulnerability during which multiple Bundle Heads might be
   created for the same MP connection.

MPは、複数のBundleヘッズが同じMP接続のために作成されるかもしれない脆弱性の窓が全くないのを保証するのに以下のアルゴリズムを使用しなければなりません。

   When an MP link is negotiated, MP first checks to see if it already
   has the Bundle Head for this connection (i.e., is this a secondary
   link).  If it does, it should attach to it and not initiate a
   discovery.  As an optimization, if MP does not have a Bundle Head for
   this connection, but does have a existing secondary link for it, MP
   should attach to the known Bundle Head without initiating discovery.

MPリンクが交渉されるとき、MPは、最初に、この接続に関してそれが既にBundle Headを持つかどうか確認するためにチェックします(すなわち、これはセカンダリリンクです、)。 そうするなら、それは、それに付いて、発見を開始するべきではありません。 最適化として、MPがこの接続のためにBundle Headを持っていませんが、それのために既存のセカンダリリンクを持っているなら、発見を開始しないで、MPは知られているBundle Headに付くべきです。

   If MP knows of no Bundle Head for this connection, it should initiate
   a discovery.  If the discovery should locate a Bundle Head, it should
   attach to the indicated bundle head.  If no Bundle Head is found, MP
   should create a Bundle Head.

MPがこの接続でBundle Headを全く知らないなら、それは発見を開始するべきです。 発見がそうするなら、Bundle Headの場所を見つけてください、そして、それは示されたバンドルヘッドに付くべきです。 Bundle Headが全く見つけられないなら、MPはBundle Headを作成するべきです。

   When a RAS determines that it is to become the Bundle Head for a
   connection, it should establish the Bundle Head as quickly as
   possible so Query Messages for that connection from other RASes will
   be recognized.  If a RAS indicates that it will become the Bundle
   Head, but delays establishment of it, other RASes may time out on
   their discovery and begin to establish additional Bundle Heads of
   their own.

RASが、それが接続のためのBundle Headになることになっていることを決定すると、できるだけはやくBundle Headを設立するべきであるので、他のRASesからのその接続のためのQuery Messagesは認識されるでしょう。 そして、RASがそれがBundle Headになるのを示しますが、それの設立を遅らせるなら、他のRASesが遅らせる、彼らの発見でのタイムアウト、それら自身の追加Bundleヘッズを確立し始めてください。

3.  Transfer Protocol

3. 転送プロトコル

   The Layer 2 Tunneling Protocol (L2TP) [L2TP] will be used to transfer
   PPP fragments from a RAS containing a secondary link to the RAS
   containing the Bundle Head.  By specifying the use of an existing
   protocol, it is neither necessary to create nor implement a new
   protocol.

Layer2Tunnelingプロトコル(L2TP)[L2TP]は、Bundle Headを含むRASへのセカンダリリンクを含むRASからPPP断片を移すのに使用されるでしょう。 既存のプロトコルの使用を指定することによって、それは、作成するのに必要でなくて、また道具のa新しいプロトコルではありません。

4.  Configuration

4. 構成

   There are two required configuration switches and one conditional
   configuration switch.  None of the switches are optional.

2個の必要な設定スイッチと1個の条件付きの設定スイッチがあります。 スイッチのいずれも任意ではありません。

Malkin                       Informational                      [Page 6]

RFC 2701                          MMP                     September 1999

[6ページ]RFC2701MMP1999年9月の情報のマルキン

4.1 Robustness - required

4.1 丈夫さ--必要です。

   This switch sets the number of transmits (repetitions) for Query
   Messages.  It may be set between 1 and 15.  The default is 3.  Be
   aware that lower settings may create windows of vulnerability.
   Higher settings may cause MP timeouts, but may be needed on very
   lossy or congested networks.

このスイッチが数を設定する、Query Messagesのために(反復)を伝えます。 それは1と15の間設定されるかもしれません。 デフォルトは3です。 下側の設定が脆弱性の窓を作成するかもしれないのを意識してください。 より高い設定が、MPにタイムアウトを引き起こしますが、まさしくその損失性か混雑しているネットワークで必要であるかもしれません。

4.2 Query Interval - required

4.2はIntervalについて質問します--必要です。

   This switch sets the interval between Query Messages and the interval
   between multicast Response Messages.  It should be calibrated in
   deciseconds (1/10 second) and may be set between 1 and 15.  The
   default is 1.  Be aware that higher settings may cause MP timeouts,
   but may be needed on very slow systems/networks.

このスイッチはマルチキャストResponse MessagesのQuery Messagesと間隔の間隔を設定します。 それは、deciseconds(2番目)で較正されるべきであり、1と15の間設定されるかもしれません。 デフォルトは1です。 より高い設定がMPにタイムアウトを引き起こしますが、非常に遅いシステム/ネットワークで必要であるかもしれないことを意識してください。

4.3 TTL - conditional

4.3TTL--、条件付き

   This switch sets the IP Time-To-Live (TTL) of all Discovery packets.
   For systems which are using the limited broadcast address, this
   switch should not be implemented and the TTL should be set to 1.  The
   default value should be 1.

このスイッチはすべてのディスカバリーパケットのIP生きるTime(TTL)を設定します。 限られた放送演説を使用しているシステムにおいてこのスイッチを実装するべきではありません、そして、TTLは1に用意ができるべきです。 デフォルト値は1であるべきです。

5.  Security Considerations

5. セキュリティ問題

   No security is designed into the Discovery Mechanism.  When not
   forwarding multicast packets (or when using the limited broadcast
   address), the discovery packets are restricted to a single LAN.  If
   the LAN is physically secure, there is no need for software security.
   If the multicast packets are forwarded, but the range is limited to a
   small, physically secure network (e.g., a POP), there is still no
   need for software security.  If the discovery packets are allowed to
   cross an internet (and this is NOT recommended for timing reasons),
   authentication of RASes may be done with IPSEC.  For increased
   security on a LAN, or in a POP, IPSEC may still be used.

セキュリティは全くディスカバリーMechanismに設計されていません。 マルチキャストパケットを進めないとき(限られた放送演説を使用するとき)、発見パケットは単一のLANに制限されます。 LANが肉体的に安全であるなら、ソフトウェアセキュリティの必要は全くありません。 マルチキャストパケットを進めますが、範囲を小さくて、肉体的に安全なネットワーク(例えば、POP)に制限するなら、ソフトウェアセキュリティの必要は全くまだありません。 発見パケットがインターネットに交差できるなら(これはタイミング理由で推薦されません)、IPSECと共にRASesの認証をするかもしれません。 LANの上、または、POPの増強されたセキュリティのために、IPSECはまだ使用されているかもしれません。

   L2TP security is discussed in [L2TP].

[L2TP]でL2TPセキュリティについて議論します。

6.  IANA Considerations

6. IANA問題

   UDP port number: 581
   Multicast address: 224.0.1.69

UDPは数を移植します: 581 マルチキャストアドレス: 224.0.1.69

Malkin                       Informational                      [Page 7]

RFC 2701                          MMP                     September 1999

[7ページ]RFC2701MMP1999年9月の情報のマルキン

7.  References

7. 参照

   [MP]    Sklower, K., Lloyd, B., McGregor, G., Carr, D. and
           T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
           August 1996.

[mp]Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.、およびT.Coradetti、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1990、1996年8月。

   [L2TP]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
           and B. Palter, "Layer Two Tunneling Protocol "L2TP"",  RFC
           2661, August 1999.

[L2TP]Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。

Author's Address

作者のアドレス

   Gary Scott Malkin
   Nortel Networks
   11 Elizabeth Drive
   Chelmsford, MA  01824-4111

ゲーリースコットマルキンノーテルネットワーク11エリザベスはチェルムズフォード、MA01824-4111を運転します。

   Phone: +1 (978) 250-3635
   Email: gmalkin@nortelnetworks.com

以下に電話をしてください。 +1 (978) 250-3635 メールしてください: gmalkin@nortelnetworks.com

Malkin                       Informational                      [Page 8]

RFC 2701                          MMP                     September 1999

[8ページ]RFC2701MMP1999年9月の情報のマルキン

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Malkin                       Informational                      [Page 9]

マルキンInformationalです。[9ページ]