RFC2678 日本語訳

2678 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. September 1999. (Format: TXT=18087 bytes) (Obsoletes RFC2498) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        J. Mahdavi
Request for Comments: 2678             Pittsburgh Supercomputing Center
Obsoletes: 2498                                               V. Paxson
Category: Standards Track         Lawrence Berkeley National Laboratory
                                                         September 1999

Mahdaviがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2678ピッツバーグスーパーコンピューティングセンターは以下を時代遅れにします。 2498年のV.パクソンカテゴリ: 研究所1999年9月の国家の標準化過程ローレンス・バークレー

                IPPM Metrics for Measuring Connectivity

測定の接続性のためのIPPM測定基準

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

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

1. Introduction

1. 序論

   Connectivity is the basic stuff from which the Internet is made.
   Therefore, metrics determining whether pairs of hosts (IP addresses)
   can reach each other must form the base of a measurement suite.  We
   define several such metrics, some of which serve mainly as building
   blocks for the others.

接続性はインターネットが作られている基本的なものです。 したがって、ホスト(IPアドレス)の組が互いに連絡できるかどうか決定する測定基準は測定スイートのベースを形成しなければなりません。 私たちは主に他のもののためのブロックのようないくつかの測定基準を定義します。その或るものは役立ちます。

   This memo defines a series of metrics for connectivity between a pair
   of Internet hosts.  It builds on notions introduced and discussed in
   RFC 2330, the IPPM framework document.  The reader is assumed to be
   familiar with that document.

このメモは1組のインターネット・ホストの間の接続性のために一連の測定基準を定義します。 それはRFC2330、IPPM枠組みのドキュメントで紹介されて、議論した概念に建てられます。 読者がそのドキュメントによく知られさせると思われます。

   The structure of the memo is as follows:

メモの構造は以下の通りです:

 +    An analytic metric, called Type-P-Instantaneous-Unidirectional-
      Connectivity, will be introduced to define one-way connectivity at
      one moment in time.
 +    Using this metric, another analytic metric, called Type-P-
      Instantaneous-Bidirectional-Connectivity, will be introduced to
      define two-way connectivity at one moment in time.
 +    Using these metrics, corresponding one- and two-way analytic
      metrics are defined for connectivity over an interval of time.

+、分析的なメートル法の、そして、呼ばれたType-P瞬時に起こっている単方向の接続性であり、時間内に1つの瞬間に片道接続性を定義するために導入するでしょう。 + これほどメートル法の使用、別の分析的なメートル法の、そして、呼ばれたType-P瞬時に起こっている双方向の接続性、時間内にある瞬間に両用接続性を定義するために、導入するでしょう。 +がこれらの測定基準を使用して、対応するものと両用分析的な測定基準は時間の間隔の間の接続性のために定義されます。

Mahdavi & Paxson            Standards Track                     [Page 1]

RFC 2678        IPPM Metrics for Measuring Connectivity   September 1999

接続性1999年9月に測定するためのMahdaviとパクソン標準化過程[1ページ]RFC2678IPPM測定基準

 +    Using these metrics, an analytic metric, called Type-P1-P2-
      Interval-Temporal-Connectivity, will be introduced to define a
      useful notion of two-way connectivity between two hosts over an
      interval of time.
 +    Methodologies are then presented and discussed for estimating
      Type-P1-P2-Interval-Temporal-Connectivity in a variety of
      settings.

+ これらの測定基準を使用する分析的なメートル法の、そして、呼ばれたType-P1-P2間隔時の接続性、時間の間隔の間の2人のホストの間の両用接続性の役に立つ概念を定義するために、導入するでしょう。 さまざまな設定でType-P1-P2の間隔の時の接続性を見積もるために+ 方法論について次に、提示されて、議論します。

   Careful definition of Type-P1-P2-Interval-Temporal-Connectivity and
   the discussion of the metric and the methodologies for estimating it
   are the two chief contributions of the memo.

Type-P1-P2の間隔の時の接続性の慎重な定義、メートル法の議論、およびそれを見積もるための方法論はメモの2つの主要な貢献です。

2. Instantaneous One-way Connectivity

2. 瞬時に起こっている片道接続性

2.1. Metric Name:

2.1. メートル法の名前:

   Type-P-Instantaneous-Unidirectional-Connectivity

P瞬時に起こっている単方向の接続性をタイプしてください。

2.2. Metric Parameters:

2.2. メートル法のパラメタ:

 +    Src, the IP address of a host
 +    Dst, the IP address of a host
 +    T, a time

+ Src、ホスト+DstのIPアドレス、ホスト+T、時間のIPアドレス

2.3. Metric Units:

2.3. メートル制:

   Boolean.

ブール。

2.4. Definition:

2.4. 定義:

   Src has *Type-P-Instantaneous-Unidirectional-Connectivity* to Dst at
   time T if a type-P packet transmitted from Src to Dst at time T will
   arrive at Dst.

時TにSrcからDstまで伝えられたPをタイプしているパケットがDstに到着するなら、Srcは時Tに*タイプP瞬時に起こっている単方向接続性*をDstに持っています。

2.5. Discussion:

2.5. 議論:

   For most applications (e.g., any TCP connection) bidirectional
   connectivity is considerably more germane than unidirectional
   connectivity, although unidirectional connectivity can be of interest
   for some security applications (e.g., testing whether a firewall
   correctly filters out a "ping of death").  Most applications also
   require connectivity over an interval, while this metric is
   instantaneous, though, again, for some security applications
   instantaneous connectivity remains of interest.  Finally, one might
   not have instantaneous connectivity due to a transient event such as
   a full queue at a router, even if at nearby instants in time one does
   have connectivity.  These points are addressed below, with this
   metric serving as a building block.

ほとんどのアプリケーション、(どんなTCP接続) 例えば、双方向の接続性は単方向の接続性よりかなり適切です、単方向の接続性がいくつかのセキュリティアプリケーション(例えば、ファイアウォールが正しく「死のピング」を無視するか否かに関係なく、テストする)に関しておもしろいことができますが。 また、ほとんどのアプリケーションが必要である、これほどメートル法である間の間隔の間の接続性は瞬時に起こっています、瞬時に起こっている接続性がいくつかのセキュリティアプリケーションのために一方関心を残していますが。 最終的に、1つには、瞬時に起こっている接続性がルータにおける完全な待ち行列などの一時的事象のためないかもしれません、1つに接続性が時間内にの近い瞬間にあっても。 これらのポイントはブロックとして以下にこのメートル法の給仕で記述されます。

Mahdavi & Paxson            Standards Track                     [Page 2]

RFC 2678        IPPM Metrics for Measuring Connectivity   September 1999

接続性1999年9月に測定するためのMahdaviとパクソン標準化過程[2ページ]RFC2678IPPM測定基準

   Note also that we have not explicitly defined *when* the packet
   arrives at Dst.  The TTL field in IP packets is meant to limit IP
   packet lifetimes to 255 seconds (RFC 791).  In practice the TTL field
   can be strictly a hop count (RFC 1812), with most Internet hops being
   much shorter than one second.  This means that most packets will have
   nowhere near the 255 second lifetime.  In principle, however, it is
   also possible that packets might survive longer than 255 seconds.
   Consideration of packet lifetimes must be taken into account in
   attempts to measure the value of this metric.

また、私たちが、**パケットがいつDstに到着するかを明らかに定義していないことに注意してください。 IPパケットのTTL分野はIPパケット生存期間から255秒(RFC791)を制限することになっています。 実際には、TTL分野は、厳密にホップカウント(RFC1812)であって、ほとんどのインターネットホップが多く1秒より不足している場合があります。 これは、ほとんどのパケットが255の近くのどこにも第2生涯を持たないことを意味します。 しかしながら、原則として、また、パケットが255秒より長い間生き残るのも、可能です。 メートル法でこの値を測定する試みでパケット生存期間の考慮を考慮に入れなければなりません。

   Finally, one might assume that unidirectional connectivity is
   difficult to measure in the absence of connectivity in the reverse
   direction.  Consider, however, the possibility that a process on
   Dst's host notes when it receives packets from Src and reports this
   fact either using an external channel, or later in time when Dst does
   have connectivity to Src.  Such a methodology could reliably measure
   the unidirectional connectivity defined in this metric.

最終的に、人は、単方向の接続性は反対の方向の接続性がないとき測定するのが難しいと仮定するかもしれません。 しかしながら、Dstであるときに、Dstのホストの過程が、それがいつSrcからパケットを受けて、この事実を報告するかに外部のチャンネルを使用することで注意するか、または中では、後で時間がSrcに接続性を持っている可能性を考えてください。 そのような方法論はこれでメートル法で定義された単方向の接続性を確かに測定するかもしれません。

3. Instantaneous Two-way Connectivity

3. 瞬時に起こっている両用接続性

3.1. Metric Name:

3.1. メートル法の名前:

   Type-P-Instantaneous-Bidirectional-Connectivity

P瞬時に起こっている双方向の接続性をタイプしてください。

3.2. Metric Parameters:

3.2. メートル法のパラメタ:

 +    A1, the IP address of a host
 +    A2, the IP address of a host
 +    T, a time

+ A1、ホスト+A2のIPアドレス、ホスト+T、時間のIPアドレス

3.3. Metric Units:

3.3. メートル制:

   Boolean.

ブール。

3.4. Definition:

3.4. 定義:

   Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional-
   Connectivity* at time T if address A1 has Type-P-Instantaneous-
   Unidirectional-Connectivity to address A2 and address A2 has Type-P-
   Instantaneous-Unidirectional-Connectivity to address A1.

アドレスのA1とA2には、アドレスA1にType-P瞬時に起こっている記述する単方向接続性A2の、そして、アドレスのA2があるならTにA1を記述するType-Pの瞬時に起こっている単方向の接続性があるとき、*タイプP瞬時に起こって双方向の接続性*があります。

3.5. Discussion:

3.5. 議論:

   An alternative definition would be that A1 and A2 are fully connected
   if at time T address A1 has instantaneous connectivity to address A2,
   and at time T+dT address A2 has instantaneous connectivity to A1,
   where T+dT is when the packet sent from A1 arrives at A2.  This
   definition is more useful for measurement, because the measurement

代替の定義は、A2を記述するためにはアドレスA1に瞬時に起こっている接続性が時TにあるならA1とA2が完全に接続されるということであるだろう、時間T+dTアドレスA2に瞬時に起こっている接続性をA1に持っています。そこでは、T+dTがA1から送られたパケットがA2に到着する時です。 この定義が測定により役に立つ、測定

Mahdavi & Paxson            Standards Track                     [Page 3]

RFC 2678        IPPM Metrics for Measuring Connectivity   September 1999

接続性1999年9月に測定するためのMahdaviとパクソン標準化過程[3ページ]RFC2678IPPM測定基準

   can use a reply from A2 to A1 in order to assess full connectivity.
   It is a more complex definition, however, because it breaks the
   symmetry between A1 and A2, and requires a notion of quantifying how
   long a particular packet from A1 takes to reach A2.  We postpone
   discussion of this distinction until the development of interval-
   connectivity metrics below.

完全な接続性を評価するのにA2からA1までの回答を使用できます。 A2に達するのがA1とA2の間の対称を破って、どれくらい長い間定量化するかでは、A1からの特定のパケットが取るという概念を必要とするので、しかしながら、それは、より複雑な定義です。 私たちは以下での間隔接続性測定基準の開発までこの区別の議論を延期します。

4. One-way Connectivity

4. 片道接続性

4.1. Metric Name:

4.1. メートル法の名前:

   Type-P-Interval-Unidirectional-Connectivity

P間隔単方向の接続性をタイプしてください。

4.2. Metric Parameters:

4.2. メートル法のパラメタ:

 +    Src, the IP address of a host
 +    Dst, the IP address of a host
 +    T, a time
 +    dT, a duration
   {Comment:  Thus, the closed interval [T, T+dT] denotes a time
   interval.}

+ Src、ホスト+DstのIPアドレス、ホスト+T、時間+dT、持続時間のIPアドレスコメントしてください: その結果、[T、T+dT]が時間間隔を指示する閉じている間隔

4.3. Metric Units:

4.3. メートル制:

   Boolean.

ブール。

4.4. Definition:

4.4. 定義:

   Address Src has *Type-P-Interval-Unidirectional-Connectivity* to
   address Dst during the interval [T, T+dT] if for some T' within [T,
   T+dT] it has Type-P-instantaneous-connectivity to Dst.

'アドレスSrcには、[T、T+dT]それの中のT'がいくつかに関してType-Pの瞬時に起こっている接続性をDstに持っているなら、間隔[T、T+dT]の間にDstを記述する*タイプP-間隔単方向接続性*があります。

5. Two-way Connectivity

5. 両用接続性

5.1. Metric Name:

5.1. メートル法の名前:

   Type-P-Interval-Bidirectional-Connectivity

P間隔の双方向の接続性をタイプしてください。

5.2. Metric Parameters:

5.2. メートル法のパラメタ:

 +    A1, the IP address of a host
 +    A2, the IP address of a host
 +    T, a time
 +    dT, a duration
   {Comment:  Thus, the closed interval [T, T+dT] denotes a time
   interval.}

+ A1、ホスト+A2のIPアドレス、ホスト+T、時間+dT、持続時間のIPアドレスコメントしてください: その結果、[T、T+dT]が時間間隔を指示する閉じている間隔

Mahdavi & Paxson            Standards Track                     [Page 4]

RFC 2678        IPPM Metrics for Measuring Connectivity   September 1999

接続性1999年9月に測定するためのMahdaviとパクソン標準化過程[4ページ]RFC2678IPPM測定基準

5.3. Metric Units:

5.3. メートル制:

   Boolean.

ブール。

5.4. Definition:

5.4. 定義:

   Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity*
   between them during the interval [T, T+dT] if address A1 has Type-P-
   Interval-Unidirectional-Connectivity to address A2 during the
   interval and address A2 has Type-P-Interval-Unidirectional-
   Connectivity to address A1 during the interval.

アドレスA1には間隔の間にA2を記述するType-P間隔単方向の接続性があって、アドレスA2に間隔の間にA1を記述するType-P-間隔単方向接続性があるなら、アドレスのA1とA2の間には、*タイプP-間隔双方向の接続性*が間隔[T、T+dT]の間、あります。

5.5. Discussion:

5.5. 議論:

   This metric is not quite what's needed for defining "generally
   useful" connectivity - that requires the notion that a packet sent
   from A1 to A2 can elicit a response from A2 that will reach A1.  With
   this definition, it could be that A1 and A2 have full-connectivity
   but only, for example, at time T1 early enough in the interval [T,
   T+dT] that A1 and A2 cannot reply to packets sent by the other.  This
   deficiency motivates the next metric.

いったい定義に必要であるものが「一般に、役に立たない」というこのメートル法の接続性(パケットがA1からA2まで発信したという概念を必要とする)はA1に達するA2から応答を引き出すことができます。 この定義で、A1とA2には完全な接続性があるということであるかもしれませんが、例えば単に間隔[T、T+dT]の十分前の時間T1のときに、そのA1とA2はもう片方によって送られたパケットに答えることができません。 この欠乏はメートル法であることで次を動機づけます。

6. Two-way Temporal Connectivity

6. 両用時の接続性

6.1. Metric Name:

6.1. メートル法の名前:

   Type-P1-P2-Interval-Temporal-Connectivity

P1-P2の間隔の時の接続性をタイプしてください。

6.2. Metric Parameters:

6.2. メートル法のパラメタ:

 +    Src, the IP address of a host
 +    Dst, the IP address of a host
 +    T, a time
 +    dT, a duration
   {Comment:  Thus, the closed interval [T, T+dT] denotes a time
   interval.}

+ Src、ホスト+DstのIPアドレス、ホスト+T、時間+dT、持続時間のIPアドレスコメントしてください: その結果、[T、T+dT]が時間間隔を指示する閉じている間隔

6.3. Metric Units:

6.3. メートル制:

   Boolean.

ブール。

Mahdavi & Paxson            Standards Track                     [Page 5]

RFC 2678        IPPM Metrics for Measuring Connectivity   September 1999

接続性1999年9月に測定するためのMahdaviとパクソン標準化過程[5ページ]RFC2678IPPM測定基準

6.4. Definition:

6.4. 定義:

   Address Src has *Type-P1-P2-Interval-Temporal-Connectivity* to
   address Dst during the interval [T, T+dT] if there exist times T1 and
   T2, and time intervals dT1 and dT2, such that:

回の時間間隔のT1、T2、dT1、およびdT2が存在するなら、アドレスSrcは間隔[T、T+dT]の間、Dstを記述するためにタイプ-P1-P2間隔時の接続性*であるのに*を持っています、そのようなものによって:

 +    T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT].
 +    T1+dT1 <= T2.
 +    At time T1, Src has Type-P1 instantanous connectivity to Dst.
 +    At time T2, Dst has Type-P2 instantanous connectivity to Src.
 +    dT1 is the time taken for a Type-P1 packet sent by Src at time T1
      to arrive at Dst.
 +    dT2 is the time taken for a Type-P2 packet sent by Dst at time T2
      to arrive at Src.

+ T1、T1+dT1、T2、T2+dT2がすべて[T、T+dT]にあります。 + T1+dT1<=T2。 時間T1の+、SrcはType-P1 instantanousの接続性をDstに持っています。 時間T2の+、DstはType-P2 instantanousの接続性をSrcに持っています。 + dT1はSrcによってDstに到着する時間T1に送られたType-P1パケットにかかる時間です。 + dT2はDstによってSrcに到着する時間T2に送られたType-P2パケットにかかる時間です。

6.5. Discussion:

6.5. 議論:

   This metric defines "generally useful" connectivity -- Src can send a
   packet to Dst that elicits a response.  Because many applications
   utilize different types of packets for forward and reverse traffic,
   it is possible (and likely) that the desired responses to a Type-P1
   packet will be of a different type Type-P2.  Therefore, in this
   metric we allow for different types of packets in the forward and
   reverse directions.

これほどメートル法、定義、「一般に役に立つ」接続性--Srcは応答を引き出すDstにパケットを送ることができます。 多くのアプリケーションが前進の、そして、逆の交通に異なったタイプのパケットを利用するので、異なったタイプType-P2にはType-P1パケットへの必要な応答があるのは、可能、そして、(ありそう。)です。 したがって、これでは、メートル法の私たちは、フォワードで異なったタイプのパケットを考慮して、指示を逆にします。

6.6. Methodologies:

6.6. 方法論:

   Here we sketch a class of methodologies for estimating Type-P1-P2-
   Interval-Temporal-Connectivity.  It is a class rather than a single
   methodology because the particulars will depend on the types P1 and
   P2.

ここに、私たちは、Type-P1-P2が間隔の時の接続性であると見積もるために方法論のクラスについてスケッチします。 子細がタイプのP1とP2によるので、それはただ一つの方法論よりむしろクラスです。

6.6.1. Inputs:

6.6.1. 入力:

 +    Types P1 and P2, addresses A1 and A2, interval [T, T+dT].
 +    N, the number of packets to send as probes for determining
      connectivity.
 +    W, the "waiting time", which bounds for how long it is useful to
      wait for a reply to a packet.
   Required: W <= 255, dT > W.

+ タイプのP1とP2、アドレスA1とA2、間隔[T、T+dT]。 + N、接続性を決定するための徹底的調査として送るパケットの数。 + W、パケットに回答を待つのがどれくらい長い間役に立つようにバウンドする「待ち時間。」 必要: W<は255、dT>Wと等しいです。

6.6.2. Recommended values:

6.6.2. 推奨値:

   dT = 60 seconds.
   W = 10 seconds.
   N = 20 packets.

60dT=秒。 10W=秒。 Nは20のパケットと等しいです。

Mahdavi & Paxson            Standards Track                     [Page 6]

RFC 2678        IPPM Metrics for Measuring Connectivity   September 1999

接続性1999年9月に測定するためのMahdaviとパクソン標準化過程[6ページ]RFC2678IPPM測定基準

6.6.3. Algorithm:

6.6.3. アルゴリズム:

 +    Compute N *sending-times* that are randomly, uniformly distributed
      over [T, T+dT-W].
 +    At each sending time, transmit from A1 a well-formed packet of
      type P1 to A2.
 +    Inspect incoming network traffic to A1 to determine if a
      successful reply is received.  The particulars of doing so are
      dependent on types P1 & P2, discussed below.  If any successful
      reply is received, the value of the measurement is "true".  At
      this point, the measurement can terminate.
 +    If no successful replies are received by time T+dT, the value of
      the measurement is "false".

+は[T、T+dT-W]の上に分配されていた状態で無作為で、一様にそうであるN*発信回*を計算します。 それぞれの+が時間を送って、タイプP1のよく形成されたパケットをA1からA2に伝えてください。 +は、うまくいっている回答が受け取られているかどうか決定するために入って来るネットワークトラフィックをA1に点検します。 そうする子細は以下で議論したタイプP1とP2に依存しています。 何かうまくいっている回答が受け取られているなら、測定の値は「本当です」。 ここに、測定は終わることができます。 うまくいっている回答でないならT+dT、測定の値が「誤っている」時によって+は受け取られます。

6.6.4. Discussion:

6.6.4. 議論:

   The algorithm is inexact because it does not (and cannot) probe
   temporal connectivity at every instant in time between [T, T+dT].
   The value of N trades off measurement precision against network
   measurement load.  The state-of-the-art in Internet research does not
   yet offer solid guidance for picking N.  The values given above are
   just guidelines.

時間内にいつも瞬間に[T、T+dT]の間で(and cannot)徹底的調査時でない接続性をするので、アルゴリズムは不正確です。 Nの値はネットワーク測定負荷に対して測定精度を交換します。 インターネット研究における最先端は選択N.のためにまだ確実な指導を提供していません。上に与えられた値はただガイドラインです。

6.6.5. Specific methodology for TCP:

6.6.5. TCPのための特定の方法論:

   A TCP-port-N1-port-N2 methodology sends TCP SYN packets with source
   port N1 and dest port N2 at address A2.  Network traffic incoming to
   A1 is interpreted as follows:

TCPポートN1ポートN2方法論はアドレスA2のソースポートN1とdestポートN2と共にパケットをTCP SYNに送ります。 A1へのネットワークトラフィック入来は以下の通り解釈されます:

 +    A SYN-ack packet from A2 to A1 with the proper acknowledgement
      fields and ports indicates temporal connectivity.  The measurement
      terminates immediately with a value of "true".  {Comment: if, as a
      side effect of the methodology, a full TCP connection has been
      established between A1 and A2 -- that is, if A1's TCP stack
      acknowledges A2's SYN-ack packet, completing the three-way
      handshake -- then the connection now established between A1 and A2
      is best torn down using the usual FIN handshake, and not using a
      RST packet, because RST packets are not reliably delivered.  If
      the three-way handshake is not completed, however, which will
      occur if the measurement tool on A1 synthesizes its own initial
      SYN packet rather than going through A1's TCP stack, then A1's TCP
      stack will automatically terminate the connection in a reliable
      fashion as A2 continues transmitting the SYN-ack in an attempt to
      establish the connection.  Finally, we note that using A1's TCP
      stack to conduct the measurement complicates the methodology in
      that the stack may retransmit the initial SYN packet, altering the
      number of probe packets sent.}

+ A2からA1までのSYN-ackパケットは適切な承認分野とポートで時の接続性を示します。 測定はすぐ「本当」の値で終わります。 {コメント: 普通のFIN握手を使用して、RSTパケットは使用しないことで最も上手に現在A1とA2の間で確立されている接続を取りこわします、完全なTCP接続がA1とA2に方法論の副作用と書き立てられたなら(A1のTCPスタックがA2のSYN-ackパケットを承認するなら、それは3方向ハンドシェイクを終了しています)RSTパケットが確かに届けられないので。 しかしながら、3方向ハンドシェイクが終了されていないと、A2が、接続を確立する試みでSYN-ackを伝え続けるのに従って、A1の上の測定ツールがそれ自身の初期のSYNパケットを統合するとどれがA1のTCPスタック、当時のA1のTCPスタックを通るよりむしろ起こるかが自動的に信頼できるファッションで接続を終えるでしょう。 最終的に、私たちは、測定を行うのにA1のTCPスタックを使用するとスタックが初期のSYNパケットを再送するかもしれないので方法論が複雑にされることに注意します、パケットが送った探測装置の数を変更して。}

Mahdavi & Paxson            Standards Track                     [Page 7]

RFC 2678        IPPM Metrics for Measuring Connectivity   September 1999

接続性1999年9月に測定するためのMahdaviとパクソン標準化過程[7ページ]RFC2678IPPM測定基準

 +    A RST packet from A2 to A1 with the proper ports indicates
      temporal connectivity between the addresses (and a *lack* of
      service connectivity for TCP-port-N1-port-N2 - something that
      probably should be addressed with another metric).
 +    An ICMP port-unreachable from A2 to A1 indicates temporal
      connectivity between the addresses (and again a *lack* of service
      connectivity for TCP-port-N1-port-N2).  {Comment: TCP
      implementations generally do not need to send ICMP port-
      unreachable messages because a separate mechanism is available
      (sending a RST).  However, RFC 1122 states that a TCP receiving an
      ICMP port-unreachable MUST treat it the same as the equivalent
      transport-level mechanism (for TCP, a RST).}
 +    An ICMP host-unreachable or network-unreachable to A1 (not
      necessarily from A2) with an enclosed IP header matching that sent
      from A1 to A2 *suggests* a lack of temporal connectivity.  If by
      time T+dT no evidence of temporal connectivity has been gathered,
      then the receipt of the ICMP can be used as additional information
      to the measurement value of "false".

そして、+ 適切なポートがあるA2からA1までのRSTパケットがアドレスの間の時の接続性を示す、(TCPポートN1ポートN2のためのサービスの接続性の*不足*--、別のものがメートル法でたぶん記述されるべきである何か) + ポートA2からA1まで手の届かないICMPはアドレス(そして、再びTCPポートN1ポートN2のためのサービスの接続性の*不足*)の間の時の接続性を示します。 しかしながら、RFC1122がポート手が届かない状態でICMPを受けるそのa TCPを述べるというコメントは扱わなければなりません。別々のメカニズムが利用可能であるので(RSTを送って)、一般に、: TCP実現は手の届かないメッセージをICMPポートに送る必要はありません。同じように同等な輸送レベルメカニズム(TCPのためのRST)としてそれを扱ってください。 + 時の接続性のICMP A1(必ずA2でないのからの)にホスト手の届かないかネットワーク手の届かない同封のIPヘッダーがA1から*が示すA2に送られたそれを合わせていて*a不足。 時の接続性に関する証拠が全く時間T+dTによって集められていないなら、追加情報として「誤ること」の測定値にICMPの領収書を使用できます。

   {Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.}

コメントしてください: 同様の方法論がICMP Echo、UDPなどに必要です。

7. Acknowledgments

7. 承認

   The comments of Guy Almes, Martin Horneffer, Jeff Sedayao, and Sean
   Shapira are appreciated.

ガイAlmes、マーチン・ホルネッファー、ジェフSedayao、およびショーン・シャピーラのコメントに感謝します。

8. Security Considerations

8. セキュリティ問題

   As noted in RFC 2330, active measurement techniques, such as those
   defined in this document, can be abused for denial-of-service attacks
   disguised as legitimate measurement activity.  Furthermore, testing
   for connectivity can be used to probe firewalls and other security
   mechnisms for weak spots.

RFC2330に述べられるように、正統の測定活動に変装するサービス不能攻撃のために本書では定義されたものなどのアクティブな測定技術を乱用できます。 その上、ファイアウォールと他のセキュリティmechnismsを弱いスポットに調べるのに接続性がないかどうかテストするのを使用できます。

9. References

9. 参照

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
              1812, June 1995.

[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。

   [RFC1122]  Braden, R., Editor, "Requirements for Internet Hosts --
              Communication Layers", STD, 3, RFC 1122,  October 1989.

[RFC1122] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、RFC1122、10月1989STD、3、日

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330, May
              1998.

[RFC2330] パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マシス(「IPパフォーマンス測定基準のための枠組み」、RFC2330)は1998がそうするかもしれません。

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。

Mahdavi & Paxson            Standards Track                     [Page 8]

RFC 2678        IPPM Metrics for Measuring Connectivity   September 1999

接続性1999年9月に測定するためのMahdaviとパクソン標準化過程[8ページ]RFC2678IPPM測定基準

10. Authors' Addresses

10. 作者のアドレス

   Jamshid Mahdavi
   Pittsburgh Supercomputing Center
   4400 5th Avenue
   Pittsburgh, PA  15213
   USA

第5Jamshid Mahdaviピッツバーグスーパーコンピューティングセンター4400Avenue PA15213ピッツバーグ(米国)

   EMail: mahdavi@psc.edu

メール: mahdavi@psc.edu

   Vern Paxson
   MS 50A-3111
   Lawrence Berkeley National Laboratory
   University of California
   Berkeley, CA  94720
   USA

バーン・パクソン・MS50A-3111ローレンス・カリフォルニア大学バークレー、国家の研究所カリフォルニア94720米国バークレー

   Phone: +1 510/486-7504
   EMail: vern@ee.lbl.gov

以下に電話をしてください。 +1 510/486-7504 メールしてください: vern@ee.lbl.gov

Mahdavi & Paxson            Standards Track                     [Page 9]

RFC 2678        IPPM Metrics for Measuring Connectivity   September 1999

接続性1999年9月に測定するためのMahdaviとパクソン標準化過程[9ページ]RFC2678IPPM測定基準

11.  Full Copyright Statement

11. 完全な著作権宣言文

   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機能のための基金は現在、インターネット協会によって提供されます。

Mahdavi & Paxson            Standards Track                    [Page 10]

Mahdaviとパクソン標準化過程[10ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

DATE_PART関数 日付要素を数値で求める

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る