RFC2215 日本語訳

Network Working Group                                        S. Shenker
Request for Comments: 2215                                J. Wroclawski
Category: Standards Track                            Xerox PARC/MIT LCS
                                                         September 1997

Shenkerがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2215年のJ.Wroclawskiカテゴリ: 標準化過程ゼロックスPARC/MIT LCS1997年9月

                General Characterization Parameters for
                  Integrated Service Network Elements

統合サービスネットワークElementsへの一般的性質パラメタ

Status of this Memo

このMemoの状態

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

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

Abstract

要約

   This memo defines a set of general control and characterization
   parameters for network elements supporting the IETF integrated
   services QoS control framework. General parameters are those with
   common, shared definitions across all QoS control services.

このメモはIETFの統合サービスがQoSコントロールフレームワークであるとサポートする1セットの一般的なコントロールとネットワーク要素のための特殊化パラメタを定義します。 一般的指標は一般的で、共有された定義がすべてのQoSコントロールサービスのむこうにあるそれらです。

1. Introduction

1. 序論

   This memo defines the set of general control and characterization
   parameters used by network elements supporting the integrated
   services framework.  "General" means that the parameter has a common
   definition and shared meaning across all QoS control services.

このメモは統合サービスフレームワークをサポートするネットワーク要素に従ってパラメタが使用した一般的なコントロールと特殊化のセットを定義します。 「一般」は、パラメタがすべてのQoSコントロールサービスの向こう側に一般的な定義と共有された意味を持っていることを意味します。

   Control parameters are used by applications to provide information to
   the network related to QoS control requests. An example is the
   traffic specification (TSpec) generated by application senders and
   receivers.

管理パラメータは、QoSコントロール要求に関連するネットワークに情報を提供するのにアプリケーションで使用されます。 例はアプリケーション送付者と受信機によって生成されたトラフィック仕様(TSpec)です。

   Characterization parameters are used to discover or characterize the
   QoS management environment along the path of a packet flow requesting
   active end-to-end QoS control.  These characterizations may
   eventually be used by the application requesting QoS control, or by
   other network elements along the path. Examples include information
   about which QoS control services are available along a network path
   and estimates of the available path bandwidth.

特殊化パラメタは、終わりからエンドへのQoS動作制御を要求しながらパケット流動の経路に沿ってQoS経営環境を発見するか、または特徴付けるのに使用されます。 これらの特殊化は結局、QoSコントロールを要求するアプリケーション、または経路に沿った他のネットワーク要素によって使用されるかもしれません。 例はQoSコントロールサービスが利用可能な経路帯域幅のネットワーク経路と見積りに沿って利用可能である情報を含んでいます。

   Individual QoS control service specifications may refer to these
   parameter definitions as well as defining additional parameters
   specific to the needs of that service.

独特のQoSコントロールサービス仕様はそのサービスの必要性に特定の追加パラメタを定義することと同様にこれらのパラメタ定義について言及するかもしれません。

Shenker & Wroclawski        Standards Track                     [Page 1]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[1ページ]。

   Parameters are assigned machine-oriented ID's using a method
   described in [RFC 2216] and summarized here.  These ID's may be used
   within protocol messages (e.g., as described in [RFC 2210]) or
   management interfaces to describe the parameter values present. Each
   parameter ID is composed from two numerical fields, one identifying
   the service associated with the parameter (the <service_number>), and
   the other (the <parameter_number>) identifying the parameter itself.
   Because the definitions of the parameters defined in this note are
   common to all QoS control services, the <parameter_number> values for
   the parameters defined here are assigned from the "general
   parameters" range (1 - 127).

マシン指向のIDが[RFC2216]で説明されて、ここへまとめられたメソッドを使用するのはパラメタに割り当てられます。 IDのこれらのものは、値が提示するパラメタについて説明するのにプロトコルメッセージ(例えば、[RFC2210]で説明されるように)か管理インタフェースの中で使用されるかもしれません。 それぞれのパラメタIDは、パラメタ自体を特定しながら、2つの数字の分野、パラメタに関連しているサービスを特定する1つ(<サービス_番号>)、およびもう片方(<パラメタ_番号>)から構成されます。 この注意で定義されたパラメタの定義がすべてのQoSコントロールサービスに共通であるので、ここで定義されたパラメタのための<パラメタ_数の>値は「一般的指標」範囲(1--127)から割り当てられます。

      NOTE: <parameter_numbers> in the range 128 - 254 name parameters
      with definitions specific to a particular QoS control service. In
      contrast to the general parameters described here, it is necessary
      to consider both the <service_number> and <parameter_number> to
      determine the meaning of the parameter.

以下に注意してください。 128--254が特定のQoSに特定の定義でパラメタと命名する範囲の<パラメタ_数の>はサービスを制御します。 ここで説明された一般的指標と対照して、<サービス_番号>と<パラメタ_番号>の両方がパラメタの意味を決定すると考えるのが必要です。

      Service number 1 is reserved for use as described in Section 2 of
      this note. Service numbers 2 through 254 will be allocated to
      individual QoS control services. Currently, Guaranteed service
      [RFC 2212] is allocated number 2, and Controlled-load service [RFC
      2211] is allocated number 5.

認識番号1は使用のためにこの注意のセクション2で説明されるように予約されます。 個々のQoSコントロールサービスに認識番号2〜254を割り当てるでしょう。 現在、Guaranteedサービス[RFC2212]にNo.2を割り当てます、そして、Controlled-負荷サービス[RFC2211]にNo.5を割り当てます。

   In this note, the textual form

この注意、原文のフォームで

                    <service_number, parameter_number>

<サービス_番号、パラメタ_数の>。

   is used to write a service_number, parameter_number pair.  The range
   of possible of service_number and parameter_number values specified
   in [RFC 2216] allow the parameter ID to directly form the tail
   portion of a MIB object ID representing the parameter. This
   simplifies the task of making parameter values available to network
   management applications.

サービス_番号、パラメタ_数の組に書くために、使用されます。 [RFC2216]がパラメタを表すMIBオブジェクトIDのテール部分をパラメタIDを直接形成させるサービス_番号と値が指定したパラメタ_番号で可能の範囲。 これはパラメタ値をネットワークマネージメントアプリケーションに利用可能にするタスクを簡素化します。

   The definition of each parameter used to characterize a path through
   the network describes two types of values; local and composed.  A
   Local value gives information about a single network element.
   Composed values reflect the running composition of local values along
   a path, specified by some composition rule.  Each parameter
   definition specifies the composition rule for that parameter. The
   composition rule tells how to combine an incoming composed value
   (from the already-traversed portion of the path) and the local value,
   to give a new composed value which is passed to the next network
   element in the path. Note that the composition may proceed either

ネットワークを通して経路を特徴付けるのに使用されるそれぞれのパラメタの定義は2つのタイプの値について説明します。 地方であって落ち着いています。 Local値はただ一つのネットワーク要素に関して知らせます。 落ち着いた値は何らかの構成規則で指定された経路に沿って地方の値の実行している構成を反映します。 それぞれのパラメタ定義はそのパラメタに構成規則を指定します。 構成規則は、経路の次のネットワーク要素に通過される新しい落ち着いた値を与えるために入って来る落ち着いた値(経路の既に横断された部分からの)と地方の値を結合する方法を教えます。 構成が続くかもしれないことに注意してください。

Shenker & Wroclawski        Standards Track                     [Page 2]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[2ページ]。

   downstream, toward the receiver(s), or upstream, toward the sender.
   Each parameter may give only one definition for the local value, but
   may potentially give more than one definition for composition rules
   and composed values. This is because it may be useful to compose the
   same local value several times following different composition rules.

送付者に向かった受信機、または上流に向かった川下。 各パラメタは、地方の値のために1つの定義だけを与えますが、構成規則と落ち着いた値のために潜在的に1つ以上の定義を与えるかもしれません。 これは異なった構成規則に従って、何度か同じ地方の値を構成するのが役に立つかもしれないからです。

   Because characterization parameters are used to compute the
   properties of a specific path through the internetwork, all
   characterization parameter definitions are conceptually "per-next-
   hop", as opposed to "per interface" or "per network element".  In
   cases where the network element is (or is controlling) a shared media
   or large-cloud subnet, the element may need to provide different
   values for different next-hops within the cloud.  In practice, it may
   be appropriate for vendors to choose and document a tolerance range,
   such that if all next-hop values are within the tolerance range only
   a single value need be stored and provided.

特殊化パラメタがインターネットワークを通して特定の経路の特性を計算するのに使用されるので、すべての特殊化パラメタ定義は概念的に使用されます。「次のホップ」、または「インタフェース」と対照的に「ネットワーク要素」単位で。 ネットワーク要素が(または、制御しています)共有されたメディアか大きい雲のサブネットである場合では、要素は、雲の中で異なった次のホップに異価を提供する必要があるかもしれません。 実際には、ベンダーが寛容範囲を選んで、記録するのは、適切であるかもしれません、寛容範囲だけの中にすべての次のホップ値があるなら、ただ一つの値を保存して、提供しなければならないように。

   Local and composed characterization parameter values have distinct
   ID's so that a network management entity can examine the value of
   either a local or path-composed parameter at any point within the
   network.

地方の、そして、落ち着いた特殊化パラメタ値には、異なったIDのものが、ネットワークマネージメント実体がネットワークの中で任意な点で地方の、または、経路で落ち着いたパラメタの値を調べることができるように、あります。

   Each parameter definition includes a description of the minimal
   properties, such as range and precision, required of any wire
   representation of that parameter's values. Each definition also
   includes an XDR [RFC 1832] description of the parameter, describing
   an appropriate external (wire) data representation for the
   parameter's values. This dual definition is intended to encourage a
   common wire representation format whenever possible, while still
   allowing other representations when required by the specific
   circumstances (e.g., ASN.1 within SNMP).

それぞれのパラメタ定義は最小量の特性の記述を含んでいます、範囲や精度のように、そのパラメタの値のどんなワイヤ表現でも、必要です。 また、各定義はパラメタのXDR[RFC1832]記述を含んでいます、パラメタの値の適切な外部の(ワイヤ)データ表現について説明して。 特定の事情(例えば、SNMPの中のASN.1)が必要であるとまだ他の表現を許容している間、可能であるときはいつも、この二元的な定義が一般的なワイヤ表現形式を奨励することを意図します。

   The message formats specified in [RFC 2210] for use with the RSVP
   setup protocol use the XDR data representation parameters.

[RFC2210]でRSVPセットアッププロトコルで使用に指定されたメッセージ・フォーマットはXDRデータ表現パラメタを使用します。

   All of the parameters described in this note are mandatory, in the
   sense that a network element claiming to support integrated service
   must recognize arriving values in setup and management protocol
   messages, process them correctly, and export a reasonable value in
   response. For some parameters, the specification requires that the
   network element compute and export an *accurate* local value. For
   other parameters, it is acceptable for the network element to
   indicate that it cannot compute and export an accurate local value.
   The definition of these parameters provides a reserved value which
   indicates "indeterminate" or "invalid". This value signals that an
   element cannot process the parameter accurately, and consequently
   that the result of the end-to-end composition is also questionable.

この注意で説明されたパラメタのすべてが義務的です、統合サービスをサポートすると主張するネットワーク要素が応答で到着がセットアップと管理プロトコルでメッセージを評価すると認めて、正しくそれらを処理して、適正価値をエクスポートしなければならないという意味で。 いくつかのパラメタに関しては、仕様は、ネットワーク要素が、*が正確な*地方の値であると計算して、エクスポートするのを必要とします。 他のパラメタに関しては、ネットワーク要素が正確な地方の値を計算して、エクスポートすることができないのを示すのは、許容できます。 これらのパラメタの定義は「不確定」か「病人」を示す予約された値を提供します。 この値は要素が正確にパラメタを処理できないで、また、その結果、終わりから終わりへの構成の結果も疑わしいのを示します。

Shenker & Wroclawski        Standards Track                     [Page 3]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[3ページ]。

      NOTE (temporary): Previous versions of this and the RSVP use
      document used both the reserved-value approach and a separate
      INVALID flag to record this fact.  Now, the reserved-value
      approach is used exclusively. This is so that any protocol which
      retrieves a parameter value, including SNMP, can carry the invalid
      indication without needing a separate flag. The INVALID flag
      remains in the RSVP message format but is reserved for use only
      with a possible future service-composition scheme.

以下に注意してください(一時的な)。 この事実を記録するのに予約された価値的研究法と別々のINVALID旗の両方を使用しましたこの旧バージョンとRSVP使用が、ドキュメントである。 現在、予約された価値的研究法は排他的に使用されます。 これは、SNMPを含むパラメタ値を検索するどんなプロトコルも別々の旗を必要としないで無効の指示を運ぶことができるためのそうです。 INVALID旗は、RSVPメッセージ・フォーマットに残っていますが、使用のために単に可能な将来のサービス構成体系で予約されます。

2. Default and Service-Specific Values for General Parameters

2. 一般的指標のためのデフォルトとサービス特有の値

   General parameters have a common *definition* across all QoS control
   services. Frequently, the same *value* of a general parameter will be
   correct for all QoS control services offered by a network element. In
   this circumstance, there is no need to export a separate copy of the
   value for each QoS control service; instead the node can export one
   number which applies to all supported services.

一般的指標はすべてのQoSコントロールサービスの向こう側に一般的な*定義*を持っています。 頻繁に、一般的指標の同じ*値*はネットワーク要素によって提供されたすべてのQoSコントロールサービスに正しくなるでしょう。 この状況に、それぞれのQoSコントロールサービスのために価値の別々のコピーをエクスポートする必要は全くありません。 代わりに、ノードはサービスであるとサポートされたすべてに適用される1つの数をエクスポートすることができます。

   A general parameter value which applies to all services supported at
   a network node is called a default or global value. For example, if
   all of the QoS control services provided at a node support the same
   maximum packet size, the node may export a single default value for
   the PATH_MTU parameter described in Section 3, rather than providing
   a separate copy of the value for each QoS control service. In the
   common case, this reduces both message size and processing overhead
   for the setup protocol.

ネットワーク・ノードでサポートされたすべてのサービスに適用される一般的指標値はデフォルトかグローバルな値と呼ばれます。 例えば、QoSコントロールサービスのすべてがノードサポートのときに同じ最大のパケットサイズを提供したなら、ノードは、それぞれのQoSコントロールサービスに価値の別々のコピーを提供するよりセクション3でむしろ説明されたPATH_MTUパラメタのためにただ一つのデフォルトが値であるとエクスポートするかもしれません。 よくある例では、これはセットアッププロトコルのためにメッセージ規模と処理オーバヘッドの両方を下げます。

   Occasionally an individual service needs to report a value differing
   from the default value for a particular general parameter. For
   example, if the implementation of Guaranteed Service [RFC 2212] at a
   router is restricted by scheduler or hardware considerations to a
   maximum packet size smaller than supported by the router's best-
   effort forwarding path, the implementation may wish to export a
   "service-specific" value of the PATH_MTU parameter so that
   applications using the Guaranteed service will function correctly.

時折、個々のサービスは、特定の一般的指標のためにデフォルト値と異なっている値を報告する必要があります。 例えば、ルータにおけるGuaranteed Service[RFC2212]の実装がスケジューラかハードウェア問題によってルータの最も良い取り組み推進経路によってサポートされるより小さい最大のパケットサイズに制限されるなら、実装は、Guaranteedサービスを利用するアプリケーションが正しく機能するように、PATH_MTUパラメタの「サービス特有」の値をエクスポートしたがっているかもしれません。

   In the example above, the router might supply a value of 1500 for the
   default PATH_MTU parameter, and a value of 250 for the PATH_MTU
   parameter applying to guaranteed service. In this case, the setup
   protocol providing path characterization carries (and delivers to the
   application) both a value for Guaranteed service and a value for
   other services.

例では、上に、ルータはデフォルトPATH_MTUパラメタのための1500年の値、および保証されたサービスに適用されるPATH_MTUパラメタのための250の値を供給するかもしれません。 この場合、経路特殊化を提供するセットアッププロトコルは他のサービスのためにGuaranteedサービスのための値と値の両方を運びます(そして、アプリケーションに配送します)。

   The distinction between default and service-specific parameter values
   makes no sense for non-general parameters (those defined by a
   specific QoS control service, rather than this note), because both
   the definition and value of the parameter are always specific to the
   particular service.

デフォルトとサービス特有のパラメタ値の区別は非一般的指標(この注意よりむしろ特定のQoSコントロールサービスで定義されたもの)のために意味をなさないです、定義とパラメタの値の両方がいつも特定のサービスに特定であるので。

Shenker & Wroclawski        Standards Track                     [Page 4]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[4ページ]。

   The distinction between default and service-specific values for
   general parameters is reflected in the parameter ID name space.  This
   allows network nodes, setup protocols, and network management tools
   to distinguish default from service-specific values, and to determine
   which service a service-specific parameter value is associated with.

一般的指標のためのデフォルトとサービス特有の値の区別はスペースというパラメタID名に反映されます。 これで、ネットワーク・ノード、セットアッププロトコル、およびネットワークマネージメントツールをサービス特有の値とデフォルトを区別して、サービス特有のパラメタ値がどのサービスに関連しているかを決定します。

   Service number 1 is used to indicate the default value. A parameter
   value identified by the ID:

認識番号1は、デフォルト値を示すのに使用されます。 IDによって特定されたパラメタ値:

                           <1, parameter_number>

<1、パラメタ_数の>。

   is a default value, which applies to all services unless it is
   overridden by a service-specific value for the same parameter.

デフォルト値(それが適用しない場合、すべてのサービスに適用される)は同じパラメタのためにサービス特有の値によってくつがえされますか?

   A parameter value identified by the ID:

IDによって特定されたパラメタ値:

                    <service_number, parameter_number>

<サービス_番号、パラメタ_数の>。

   where service_number is not equal to 1, is a service-specific value.
   It applies only to the service identified by service_number.

サービス_数が1と等しくなく、サービス特有の値であるところ。 それはサービス_数によって特定されたサービスだけに適用されます。

   These service-specific values are also called override values.  This
   is because when both service-specific and default values are present
   for a parameter, the service-specific value overrides the default
   value (for the service to which it applies). The rules for composing
   service-specific and global general parameters support this override
   capability.  The basic rule is to use the service-specific value if
   it exists, and otherwise the global value.

また、これらのサービス特有の値はオーバーライド値と呼ばれます。 これはともにサービス特有、そして、デフォルト値がパラメタのために存在しているとき、サービス特有の値がデフォルト値(それが適用されるサービスのための)をくつがえすからです。 サービス特有の、そして、グローバルな一般的指標を構成するための規則は、このオーバーライドが能力であるとサポートします。 存在しているならサービス特有が評価する使用、およびそうでなければ、グローバルな値には基本的な規則があります。

   A complete summary of the characterization parameter composition
   process is given below. In this summary, the "arriving value" is the
   incompletely composed parameter value arriving from a neighbor node.
   The "local value" is the (global or service-specific) value made
   available by the local node. The "result" is the newly composed value
   to be sent to the next node on the data path.

特殊化パラメタ構成プロセスの完全な概要を以下にします。 この概要では、「到着値」は隣人ノードから到着する不完全に落ち着いたパラメタ値です。 「地方の値」はローカルのノードによって利用可能にされた(グローバルであるかサービス特有)の値です。 「結果」はデータ経路の次のノードに送られる新たに構成された値です。

     1. Examine the <service_number, parameter_number> pair associated
     with the arriving value. This information is conveyed by the setup
     protocol together with the arriving value.

1. <サービス_番号、到着に関連している>組が評価するパラメタ_番号を調べてください。 この情報は到着値と共にセットアッププロトコルによって伝えられます。

     2. If the arriving value is for a parameter specific to a single
     service (this is true when the parameter_number is larger than
     128), compose the arriving value with the local value exported by
     the specified service, and pass the result to the next hop. In this
     case there is no need to consider global values, because the
     parameter itself is specific to just one service.

2. 到着値がただ一つのサービスに特定のパラメタのためのもの(パラメタ_数が128より大きいときに、これは本当である)であるなら、地方の値が指定されたサービスでエクスポートされている状態で、到着値を構成してください、そして、次のホップに結果を通過してください。 この場合、グローバルな値を考える必要は全くありません、パラメタ自体がちょうど1つのサービスに特定であるので。

Shenker & Wroclawski        Standards Track                     [Page 5]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[5ページ]。

     3. If the arriving value is a service-specific value for a
     generally defined parameter (the parameter_number is 127 or less,
     and the service_number is other than 1), and the local
     implementation of that service also exports a service-specific
     value for the parameter, compose the service-specific arriving
     value and the service-specific local value of the parameter, and
     pass the result as a service-specific value to the next-hop node.

3. 到着値が一般に、定義されたパラメタのためのサービス特有の値(パラメタ_数は127以下です、そして、1を除いて、サービス_数がある)であり、また、そのサービスの地方の実装がパラメタのためにサービス特有の値をエクスポートするなら、サービス特有の到着値とパラメタのサービス特有の地方の値を構成してください、そして、サービス特有の値として次のホップノードに結果を通過してください。

     4. If the arriving value is a service-specific value for a general
     parameter (the parameter_number is 127 or less, and the
     service_number is other than 1), and the local implementation of
     that service does *not* export a service-specific value, compose
     the service-specific arriving value with the global value for that
     parameter exported by the local node, and pass the result as a
     service-specific value to the next-hop node.

4. 到着値が一般的指標のためのサービス特有の値(パラメタ_数は127以下です、そして、1を除いて、サービス_数がある)であり、そのサービスの地方の実装が*輸出ではなく、*にサービス特有の値をするなら、ローカルのノードによってエクスポートされたそのパラメタのためにグローバルな値でサービス特有の到着値を構成してください、そして、サービス特有の値として次のホップノードに結果を通過してください。

     5. If the arriving value is a global value for a general parameter
     (parameter_number is 127 or less, and the service_number is 1), and
     the local implementation of *any* service exports a service-
     specific value for that general parameter, compose the arriving
     (global) value with the service-specific value for that parameter
     exported by the local service, and pass the result as a service-
     specific value to the next-hop node. This will require adding a new
     data field to the message passed to the next hop, to hold the newly
     generated service-specific value. Repeat this process for each
     service that exports a service-specific value for the parameter.

5. 到着値が一般的指標(パラメタ_数は127以下です、そして、サービス_数は1である)のためのグローバルな値と、どんな*サービスもその一般的指標のためにサービスの特定の値をエクスポートする*の地方の実装であるなら、ローカル・サービスでエクスポートされたそのパラメタのためにサービス特有の値で到着(グローバルな)値を構成してください、そして、サービスの特定の値として次のホップノードに結果を通過してください。 これは、新たに生成しているサービス特有の値を保持するために次のホップに通過されたメッセージに新しいデータ・フィールドを追加するのを必要とするでしょう。 パラメタのためにサービス特有の値をエクスポートする各サービスのためにこのプロセスを繰り返してください。

     6. If the arriving value is a global value for a general parameter
     (the service_number is 1, and the parameter_number is 127 or less),
     compose the arriving (global) value with the global parameter value
     exported by the local node, and pass the result as a global
     (service 1) value to the next-hop node. This step is performed
     whether or not any service-specific values were generated and
     exported in step 5.

6. 到着値が一般的指標のためのグローバルな値(サービス_数は1です、そして、パラメタ_数は127以下である)であるなら、グローバルなパラメタ値がローカルのノードによってエクスポートされている状態で、到着(グローバルな)値を構成してください、そして、グローバルな(サービス1)値として次のホップノードに結果を通過してください。 どんなサービス特有の値もステップ5で生成されて、エクスポートされたか否かに関係なく、このステップは実行されます。

3. General Parameter Definitions

3. 一般的指標定義

 3.1 NON-IS_HOP flag parameter

3.1NON、-_HOPは旗のパラメタです。

   This parameter provides information about the presence of network
   elements which do not implement QoS control services along the data
   path.

このパラメタはデータ経路に沿ってQoSコントロールがサービスであると実装しないネットワーク要素の存在の情報を提供します。

   The local value of the parameter is 1 if the network element does not
   implement the relevant QoS control service, or knows that there is a
   break in the chain of elements which implement the service.  The
   local parameter is 0 otherwise.  The local parameter is assigned
   parameter_number 1.

ネットワーク要素が、関連QoSがコントロールサービスであると実装しないか、またはサービスを実装する要素のチェーンには中断があるのを知っているなら、パラメタの地方の値は1です。 そうでなければ、ローカルのパラメタは0です。 パラメタ_No.1はローカルのパラメタに割り当てられます。

Shenker & Wroclawski        Standards Track                     [Page 6]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[6ページ]。

   The composition rule for this parameter is the OR function. A
   composed parameter value of 1 arriving at the endpoint of a path
   indicates that at least one point along the path does not offer the
   indicated QoS control service.  The parameter_number for the composed
   quantity is 2.

このパラメタのための構成規則はOR機能です。 経路の終点に到着する1の落ち着いたパラメタ値は、経路に沿った少なくとも1ポイントが示されたQoSコントロールサービスを提供しないのを示します。 落ち着いた量のパラメタ_数は2です。

   The global NON_IS_HOP flag parameter thus has the ID <1,2>. If this
   flag is set, it indicates that one or more network elements along the
   application's data path does not support the integrated services
   framework at all. An example of such an element would be an IP router
   offering only best-effort packet delivery and not supporting any
   resource reservation requests.

グローバルなNON_による_その結果、HOP旗のパラメタにはID<1、2>があるということです。 この旗が設定されるなら、それは、アプリケーションのデータ経路に沿った要素がそうしない1つ以上のネットワークが全く統合サービスフレームワークをサポートするのを示します。 そのような要素に関する例はベストエフォート型パケット配信だけを提供して、少しのリソース予約の要請もサポートしないIPルータでしょう。

   Obviously, a network element which does not support this
   specification will not know to set this flag.  The actual
   responsibility for determining that a network node does not support
   integrated services may fall to the network element, the setup
   protocol, or a manual configuration operation and is dependent on
   implementation and usage.  This calculation must be conservative.
   For example, a router sending packets into an IP tunnel must assume
   that the tunneled packets will not receive QoS control services
   unless it or the setup protocol can prove otherwise.

この仕様がこの旗を設定するのを知らないサポートではなく、明らかにそうするネットワーク要素。 ネットワーク・ノードが統合サービスを支えないことを決定することへの実際の責任は、ネットワーク要素、セットアッププロトコル、または手動の構成操作に落下するかもしれなくて、実装と用法に依存しています。 この計算は保守的であるに違いありません。 例えば、IPトンネルにパケットを送るルータは、それかセットアッププロトコルがそうでないと判明できないとトンネルを堀られたパケットがQoSコントロールサービスを受けないと仮定しなければなりません。

   Service-specific versions of the NON_IS_HOP flag indicate that one or
   more network elements along a path don't support the particular
   service. For example, the flag parameter identified by ID <2,2> being
   set indicates that some network element along the path does not
   support the Guaranteed service, though it might support another
   service such as Controlled-Load.

NON_のサービス特有のバージョンはHOPが旗を揚げさせる_が、経路に沿った1つ以上のネットワーク要素が特定のサービスをサポートしないのを示すということです。 例えば、用意ができているID<2、2>によって特定された旗のパラメタは、経路に沿った何らかのネットワーク要素がGuaranteedサービスをサポートしないのを示します、Controlled-負荷などの別のサービスをサポートするかもしれませんが。

   If the global NON_IS_HOP flag <1,2> is set for a path, the receiver
   (network element or application) should consider the values of all
   other parameters defined in this specification, including service-
   specific NON_IS_HOP flags, as possibly inaccurate. If a service
   specific NON_IS_HOP flag is set for a path, the receiver should
   consider the values of all other parameters associated with that
   service as possibly inaccurate.

グローバルなNON_が_であるなら、HOP旗の<1、2>は経路のときに予定されて、受信機(ネットワーク要素かアプリケーション)はこの仕様に基づき定義された他のすべてのパラメタの値を考えるはずであり、サービスの特定のNON_を含むのは、_HOP旗です、ことによると不正確であるとして。 サービスの特定のNON_が_であるなら、HOP旗は経路のときに予定されて、受信機は、そのサービスがことによると不正確な状態で他のすべてのパラメタの値が関連していると考えるはずです。

   The NON_IS_HOP parameter may be represented in any form which can
   express boolean true and false. However, note that a network element
   must set this flag precisely when it does *not* fully understand the
   format or data representation of an arriving protocol message
   (because it does not support the specified service). Therefore, the
   data representation used for this parameter by setup and management
   protocols must allow the parameter value to be read and set even if
   the network element cannot otherwise parse the protocol message.

NON_による_HOPパラメタが論理演算子を本当に、そして虚偽で言い表すことができるどんなフォームにも表されるかもしれないということです。 しかしながら、まさにそれが*完全でなく*をするとネットワーク要素がこの旗を設定しなければならないというメモは到着しているプロトコルメッセージの形式かデータ表現を理解しています(指定されたサービスをサポートしないので)。 したがって、そうでなければ、ネットワーク要素がプロトコルメッセージを分析できないでも、このパラメタにセットアップと管理プロトコルによって使用されるデータ表現は、パラメタ値が読まれて、設定されるのを許容しなければなりません。

Shenker & Wroclawski        Standards Track                     [Page 7]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[7ページ]。

   An appropriate XDR description of this parameter is:

このパラメタの適切なXDR記述は以下の通りです。

                             bool NON_IS_HOP;

bool NON_は_HOPです。

   However, the standard XDR data encoding for this description will not
   meet the requirement described above unless other restrictions are
   placed on message formats. An alternative data representation may be
   more appropriate.

しかしながら、この記述のための標準のXDR zデータの符号化は他の制限がメッセージ・フォーマットに関して課されない場合上で説明された必要条件を満たさないでしょう。 代替のデータ表現は、より適切であるかもしれません。

      NOTE: The message format described for RSVP in [RFC 2210] carries
      this parameter as a single-bit flag, referred to as the "break
      bit".

以下に注意してください。 [RFC2210]のRSVPのために説明されたメッセージ・フォーマットは「中断ビット」と呼ばれた単一のビット旗としてこのパラメタを運びます。

 3.2 NUMBER_OF_IS_HOPS

3.2 _の数の_は_ホップです。

   IS stands for "integrated services aware".  An integrated services
   aware network element is one that conforms to the various
   requirements described in this and other referenced documents.  The
   network element need not offer a specific service, but if it does it
   must support and characterize the service in conformance with the
   relevant specification, and if it does not it must correctly set the
   NON_IS_HOP flag parameter for the service. For completeness, the
   local parameter is assigned the parameter_number 3.

表す、「意識していた状態でサービスを統合しました」。 ネットワーク要素がこれで説明された様々な要件に従うものであることを意識している統合サービスと他の参照をつけられたドキュメント。 そうするなら、関連仕様で順応におけるサービスをサポートして、特徴付けなければなりません、そして、ネットワーク要素は特定のサービスを提供する必要はありませんが、正しく設定された必須をそれにするというわけではないなら、NON_はサービスのための_HOP旗のパラメタです。 完全性において、パラメタ_No.3はローカルのパラメタに割り当てられます。

   The composition rule for this parameter is to increment the counter
   by one at each IS-aware hop.  This quantity, when composed end-to-
   end, informs the endpoint of the number of integrated-services aware
   network elements traversed along the path.  The parameter_number for
   this composed parameter is 4.

このパラメタのための構成規則がカウンタをそれぞれの1つ増加することである、-、意識、跳んでください。 落ち着いた終わりから終わりであるとき、この量は経路に沿って横断された統合サービスの意識しているネットワーク要素の数の終点を知らせます。 この落ち着いたパラメタのパラメタ_数は4です。

   Values of the composed parameter will range from 1 to 255, limited by
   the bound on IP hop count.

IPホップカウントのときにバウンドで制限されて、落ち着いたパラメタの値は1〜255まで及ぶでしょう。

   The XDR representation of this parameter is:

このパラメタのXDR表現は以下の通りです。

                      unsigned int NUMBER_OF_IS_HOPS;

未署名のint NUMBER_OF_は_ホップスです。

 3.3. AVAILABLE_PATH_BANDWIDTH

3.3. 利用可能な_経路_帯域幅

   This parameter provides information about the bandwidth available
   along the path followed by a data flow.  The local parameter is an
   estimate of the bandwidth the network element has available for
   packets following the path.  Computation of the value of this
   parameter should take into account all information available to the
   network element about the path, taking into consideration
   administrative and policy controls on bandwidth, as well as physical
   resources.

このパラメタはデータフローがあとに続いた経路に沿って利用可能な帯域幅の情報を提供します。 ローカルのパラメタはネットワーク要素が経路に続くパケットに利用可能にする帯域幅の見積りです。 このパラメタの値の計算は経路に関するネットワーク要素に利用可能なすべての情報を考慮に入れるべきです、帯域幅で管理と方針コントロールを考慮に入れて、物理資源と同様に。

Shenker & Wroclawski        Standards Track                     [Page 8]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[8ページ]。

      NOTE: This parameter should reflect, as closely as possible, the
      actual bandwidth available to packets following a path. However,
      the bandwidth available may depend on a number of factors not
      known to the network element until a specific QoS request is in
      place, such as the destination(s) of the packet flow, the service
      to be requested by the flow, or external policy information
      associated with a reservation request.  Because the parameter must
      in fact be provided before any specific QoS request is made, it is
      frequently difficult to provide the parameter accurately. In
      circumstances where the parameter cannot be provided accurately,
      the network element should make the best attempt possible, but it
      is acceptable to overestimate the available bandwidth by a
      significant amount.

以下に注意してください。 このパラメタはできるだけ密接に小道をたどるパケットに利用可能な実際の帯域幅を反映するべきです。 しかしながら、利用可能な帯域幅を特定のQoS要求が適所にあるまでネットワーク要素に知られない多くの要因に依存するかもしれません、パケット流動の目的地などのように、流れ、または予約の要請に関連している対外政策情報によって要求されるべきサービス。 どんな特定のQoS要求もする前に事実上パラメタを提供しなければならないので、正確にパラメタを提供するのは頻繁に難しいです。 正確にパラメタを提供できない事情では、ネットワーク要素で最も良い試みは可能になるはずですが、かなりの量に従って利用可能な帯域幅を過大評価するのは許容できます。

   The parameter_number for AVAILABLE_PATH_BANDWIDTH is 5. The global
   parameter <1, 5> is an estimate of the bandwidth available to any
   packet following the path, without consideration of which (if any)
   QoS control service the packets may be subject to.

AVAILABLE_PATH_BANDWIDTHのパラメタ_数は5です。 グローバルなパラメタ<1、5>は何か経路に続くパケットに利用可能な帯域幅であって、パケットは無償でどの(もしあれば)QoSコントロールサービスを受けることがあるかもしれないかに関する見積りです。

   In cases where a particular service is administratively or
   technically restricted to a limited portion of the overall available
   bandwidth, the service module may wish to export an override
   parameter which specifies this smaller bandwidth value.

特定のサービスが総合的な利用可能な帯域幅の限られた部分に行政上か技術的に制限される場合では、機械船はこのより小さい帯域幅値を指定するオーバーライドパラメタをエクスポートしたがっているかもしれません。

   The composition rule for this parameter is the MIN function. The
   composed value is the minimum of the network element's value and the
   previously composed value. This quantity, when composed end-to-end,
   informs the endpoint of the minimal bandwidth link along the path
   from sender to receiver.  The parameter_number for the composed
   minimal bandwidth along the path is 6.

このパラメタのための構成規則はMIN機能です。 落ち着いた値はネットワーク要素の値と以前に落ち着いた価値の最小限です。 落ち着いた終わりから終わりであるとき、この量は経路に沿って送付者から受信機まで最小量の帯域幅リンクの終点を知らせます。経路に沿った落ち着いた最小量の帯域幅のパラメタ_数は6です。

   Values of this parameter are measured in bytes per second.  The
   representation must be able to express values ranging from 1 byte per
   second to 40 terabytes per second, about what is believed to be the
   maximum theoretical bandwidth of a single strand of fiber.

このパラメタの値は1秒あたりのバイトで測定されます。 表現は1秒あたり1バイトから40まで1秒あたりのテラバイトに及ぶ値を言い表すことができなければなりません、何がファイバーの単一ストランドの最大の理論上の帯域幅であると信じられているかに関して。

   Particularly for large bandwidths, only the first few digits are
   significant, so the use of a floating point representation, accurate
   to at least 0.1%, is encouraged.

特に大きい帯域幅に関しては、最初の数ケタだけが重要であるので、浮動小数点表示の少なくとも0.1%に正確な使用は奨励されます。

   The XDR representation for this parameter is:

このパラメタのXDR表現は以下の通りです。

                      float AVAILABLE_PATH_BANDWIDTH;

AVAILABLE_PATH_BANDWIDTHを浮かべてください。

   For values of this parameter only valid non-negative floating point
   numbers are allowed. Negative numbers (including "negative zero"),
   infinities, and NAN's are not allowed.

このパラメタの値だけにおいて、有効な非否定的な浮動小数点は許容されています。 負数(「負のゼロ」を含んでいる)、無辺際、およびNANのものは許容されていません。

Shenker & Wroclawski        Standards Track                     [Page 9]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[9ページ]。

      NOTE: An implementation which utilizes general-purpose hardware or
      software IEEE floating-point support may wish to verify that
      arriving parameter values meet these requirements before using the
      values in floating-point computations, in order to avoid
      unexpected exceptions or traps.

以下に注意してください。 汎用のハードウェアかソフトウェアのIEEEの浮動小数点のサポートを利用する実装は、浮動小数点の計算に値を使用する前に到着しているパラメタ値がこれらの必要条件を満たすことを確かめたがっているかもしれません、予期していなかった例外か罠を避けるために。

   If the network element cannot or chooses not to provide an estimate
   of path bandwidth, it may export a local value of zero for this
   parameter.  A network element or application receiving a composed
   value of zero for this parameter must assume that the actual
   bandwidth available is unknown.

または、ネットワーク要素がそうすることができない、経路帯域幅では、このパラメタのためにゼロのa地方の値をエクスポートするかもしれないという見積りを提供しないのを選びます。 このパラメタのためにゼロの落ち着いた値を受けるネットワーク要素かアプリケーションが、利用可能な実際の帯域幅が未知であると仮定しなければなりません。

 3.4 MINIMUM_PATH_LATENCY

3.4 最小の_経路_潜在

   The local parameter is the latency of the packet forwarding process
   associated with the network element, where the latency is defined to
   be the *smallest* possible packet delay added by the network element.
   This delay results from speed-of-light propagation delay, from packet
   processing limitations, or both. It does not include any variable
   queuing delay which may be present.

ローカルのパラメタはネットワーク要素に関連しているパケット推進プロセスの潜在です。そこでは、潜在が、ネットワーク要素によって加えられた*可能な限り小さい*パケット遅れになるように定義されます。 この遅れはパケット処理制限、または両方からの光速伝播遅延から生じます。 それは存在するかもしれない遅れを列に並ばせるどんな変数も含んでいません。

   The purpose of this parameter is to provide a baseline minimum path
   latency for use with services which provide estimates or bounds on
   additional path delay, such as Guaranteed [RFC 2212].  Together with
   the queuing delay bound offered by Guaranteed and similar services,
   this parameter gives the application knowledge of both the minimum
   and maximum packet delivery delay.  Knowing both the minimum and
   maximum latency experienced by data packets allows the receiving
   application to accurately compute its de-jitter buffer requirements.

このパラメタの目的は追加経路遅れの見積りか領域を提供するサービスと共に基線の最小の経路潜在を使用に提供することです、Guaranteed[RFC2212]などのように。 遅れバウンドがGuaranteedと同様のサービスで提供した列を作りと共に、このパラメタは最小の、そして、最大のパケット配信遅れに関するアプリケーション知識を与えます。 データ・パケットによって経験された最小の、そして、最大の潜在を知っているのに、受信アプリケーションは正確に反-ジターバッファ要件を計算できます。

   Note that the quantity characterized by this parameter is the
   absolute smallest possible value for the packet processing and
   transmission latency of the network element. This value is the
   quantity required to provide the end hosts with jitter bounds. The
   parameter does *not* provide an upper-bound estimate of minimum
   latency, which might be of interest for best-effort traffic and QoS
   control services which do not explicitly offer delay bounds. In other
   words, the parameter will always underestimate, rather than
   overestimate, latency, particularly in multicast and large cloud
   situations.

このパラメタによって特徴付けられた量がネットワーク要素のパケット処理とトランスミッション潜在のための絶対可能な限り小さい値であることに注意してください。 この値はジター領域を終わりのホストに提供するのに必要である量です。 パラメタは最小の潜在の上限見積りを*でないのが提供する*にします。(潜在は明らかに遅れ領域を提供しないベストエフォート型トラフィックとQoSコントロールサービスに関しておもしろいかもしれません)。 言い換えれば、パラメタはいつも過大評価するよりむしろ特にマルチキャストと大きい雲の状況における潜在を過小評価するでしょう。

   When packets traversing a network element may experience different
   minimal latencies over different paths, this parameter should, if
   possible, report an accurate latency value for each path. For
   example, when an ATM point-multipoint virtual circuit is used to
   implement IP multicast, the mechanism that implements this parameter
   for the ATM cloud should ideally compute a separate value for each
   destination. Doing this may require cooperation between the ingress

ネットワーク要素を横断するパケットが異なった経路の上で異なった最小量の潜在を経験するとき、できれば、このパラメタは正確な潜在値を各経路に報告するべきです。 ATMのポイント多点の仮想の回路がIPマルチキャストを実装するのに使用されるとき、例えば、ATM雲のためのこのパラメタを実装するメカニズムは理想的に各目的地に別々の値を計算するはずです。 これをするのはイングレスの間の協力を必要とするかもしれません。

Shenker & Wroclawski        Standards Track                    [Page 10]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[10ページ]。

   and egress elements bounding the multi-access communication cloud.
   The method by which this cooperation is achieved, and the choice of
   which IP-level network element actually provides and composes the
   value, is technology-dependent.

そして、マルチアクセスコミュニケーションが曇らせる出口要素制限。 この協力が達成されるメソッド、および選択はどのIP-レベルネットワーク要素が実際に値を提供して、構成するかを技術依存しています。

   An alternative choice is to provide the same value of this parameter
   for all paths through the cloud. The value reported must be the
   smallest latency for any possible path. Note that in this situation,
   QoS control services (e.g., Guaranteed) which provide an upper bound
   on latency cannot simply add their queuing delay to the value
   computed by this parameter; they must also compensate for path delays
   above the minimum. In this case the range between the minimum and
   maximum packet delays reported to the application may be larger than
   actually occurs, because the application will be told about the
   minimum delay along the shortest path and the maximum delay along the
   actual path.  This is acceptable in most situations.

代替の選択は雲を通してすべての経路のためのこのパラメタの同じ値を提供することです。 報告された値はどんな可能な経路への最もわずかな潜在でなければなりません。 この状況で、潜在で上限を提供するQoSコントロールサービス(例えば、Guaranteed)が、値へ遅れを列に並ばせるのがこのパラメタによって計算されたと絶対に言い足すことができないことに注意してください。 また、彼らは最小限より上で経路遅れを補わなければなりません。 この場合、遅れが報告した最小の、そして、最大のパケットの間の範囲は実際に起こるよりアプリケーションに大きいかもしれません、アプリケーションが実際の経路に沿って最短パスと最大の遅れに沿って最小の遅れに関して話されるので。 これはほとんどの状況で許容できます。

   A third alternative is to report the "indeterminate" value, as
   specified below.  In this circumstance the client application may
   either deduce a minimum path latency through measurement, or assume a
   value of zero.

3番目の代替手段は以下で指定されるとして「不確定」の値を報告することです。 この状況では、クライアントアプリケーションは、測定で最小の経路潜在を推論するか、またはゼロの値を仮定するかもしれません。

   The composition rule for this parameter is summation with a clamp of
   (2**32 - 1) on the maximum value. This quantity, when composed end-
   to-end, informs the endpoint of the minimal packet delay along the
   path from sender to receiver. The parameter_number for the latency of
   the network element's link is 7. The parameter_number for the
   cumulative latency along the path is 8.

このパラメタのための構成規則は最大値の(2**32--1)の留め金がある足し算です。 落ち着いた終わりから終わりであるとき、この量は経路に沿って送付者から受信機まで最小量のパケット遅れの終点を知らせます。ネットワーク要素のリンクの潜在のパラメタ_数は7です。 経路に沿った累積している潜在のパラメタ_数は8です。

   The latencies are reported in units of one microsecond. An individual
   element can advertise a latency value between 1 and 2**28 (somewhat
   over two minutes) and the total latency added across all elements can
   range as high as (2**32)-2. If the sum of the different elements
   delays exceeds (2**32)-2, the end-to-end advertised delay should be
   reported as indeterminate. This is described below.

潜在は1マイクロセカンドのユニットで報告されます。 個々の要素は1と2**28の間の潜在値(いくらか2分以上)の広告を出すことができます、そして、すべての要素の向こう側に加えられた総潜在は(2**32)-2と同じくらい上に及ぶことができます。 異なった要素遅れの合計が-2を超えているなら(2**32)、終わりから終わりへの広告を出している遅れは不確定として報告されるべきです。 これは以下で説明されます。

   Note that while the granularity of measurement is microseconds, a
   conforming element is free to actually measure delays more loosely.
   The minimum requirement is that the element estimate its delay
   accurately to the nearest 100 microsecond granularity. Elements that
   can measure more accurately are, of course, encouraged to do so.

測定の粒状がマイクロセカンドですが、従う要素が実際に無料で、より緩く遅れを測定できることに注意してください。 必要最小限は要素が正確に100マイクロセカンドの最も近い粒状に遅れを見積もっているということです。 測定できる要素がそうするよう、より正確にもちろん奨励されます。

      NOTE: Measuring in milliseconds is not acceptable, because if the
      minimum delay value is a millisecond, a path with several hops
      will lead to a composed delay of at least several milliseconds,
      which is likely to be misleading.

以下に注意してください。 ミリセカンドで測定するのは許容できません、いくつかのホップがある経路が最小の遅れ値が1ミリセカンドであるなら、紛らわしい傾向がある少なくとも数人のミリセカンドの落ち着いた遅れにつながるので。

Shenker & Wroclawski        Standards Track                    [Page 11]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[11ページ]。

   The XDR description of this parameter is:

このパラメタのXDR記述は以下の通りです。

                    unsigned int MINIMUM_PATH_LATENCY;

未署名の_int MINIMUM_PATH LATENCY。

   The distinguished value (2**32)-1 is taken to mean "indeterminate
   latency". A network element which cannot accurately predict the
   latency of packets it is processing should set its local parameter to
   this value. Because the composition function limits the composed sum
   to this value, receipt of this value at a network element or
   application indicates that the true path latency is not known. This
   may happen because one or more network elements could not supply a
   value, or because the range of the composition calculation was
   exceeded.

「不確定の潜在」を意味するために顕著な値(2**32)の-1を取ります。 正確にそれが処理しているパケットの潜在を予測できないネットワーク要素はこの値にローカルのパラメタを設定するはずです。 構成機能が落ち着いた合計をこの値に制限するので、ネットワーク要素かアプリケーションにおけるこの価値の領収書は、本当の経路潜在が知られていないのを示します。 1つ以上のネットワーク要素が値を供給できなかったか、または構成計算の範囲が超えられていたので、これは起こるかもしれません。

 3.5. PATH_MTU

3.5. 経路_MTU

   This parameter computes the maximum transmission unit (MTU) for
   packets following a data path.  This value is required to invoke QoS
   control services which require that IP packet size be strictly
   limited to a specific MTU. Existing MTU discovery mechanisms cannot
   be used because they provide information only to the sender and they
   do not directly allow for QoS control services to specify MTU's
   smaller than the physical MTU.

データ経路に続いて、このパラメタはパケットのために、マキシマム・トランスミッション・ユニット(MTU)を計算します。 この値が、IPパケットサイズが厳密に特定のMTUに制限されるのを必要とするQoSコントロールサービスを呼び出すのに必要です。 情報を送付者だけに提供するので、既存のMTU発見メカニズムを使用できません、そして、それらはQoSコントロールサービスが物理的なMTUより小さくMTUのものを指定するのを直接許容しません。

   The local characterization parameter is the IP MTU, where the MTU of
   a network element is defined to be the maximum transmission unit the
   network element can accommodate without fragmentation, including IP
   and upper-layer protocol headers but not including link level
   headers.  The composition rule is to take the minimum of the network
   element's MTU and the previously composed value.  This quantity, when
   composed end-to-end, informs the endpoint of the maximum transmission
   unit that can traverse the path from sender to receiver without
   fragmentation.  The parameter_number for the MTU of the network
   element's link is 9.  The parameter_number for the composed MTU along
   the path is 10.

ローカルの特殊化パラメタはIP MTUです、IPと上側の層のプロトコルヘッダーを含んでいますが、リンク・レベルヘッダーは含んでいなくて。そこでは、ネットワーク要素のMTUが、ネットワーク要素が断片化なしで収容できるマキシマム・トランスミッション・ユニットになるように定義されます。 構成規則はネットワーク要素のMTUの最小限と以前に落ち着いた値を取ることです。 落ち着いた終わりから終わりであるとき、この量は断片化なしで経路を送付者から受信機まで横断できるマキシマム・トランスミッション・ユニットの終点を知らせます。 ネットワーク要素のリンクのMTUのパラメタ_数は9です。 経路に沿った落ち着いたMTUのパラメタ_数は10です。

   A correct and valid value of this parameter must be provided by all
   IS-aware network elements.

すべてでこのパラメタの正しくて有効な値を提供しなければならない、-、意識、要素をネットワークでつないでください。

   A specific service module may specify an MTU smaller than that of the
   overall network element by overriding this parameter with one giving
   the service's MTU value. A service module may not specify an MTU
   value larger than that given by the global parameter.

特定の機械船はサービスのMTU値を与えながら1でこのパラメタに優越するのによる総合的なネットワーク要素のものより小さいMTUを指定するかもしれません。 機械船はグローバルなパラメタによって与えられたそれより大きいMTU値を指定しないかもしれません。

   Values of this parameter are measured in bytes.  The representation
   must be able to express values ranging from 1 byte to 2**32-1 bytes.

このパラメタの値はバイトで測定されます。 表現は1バイトから2**32-1バイトまで及ぶ値を言い表すことができなければなりません。

Shenker & Wroclawski        Standards Track                    [Page 12]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[12ページ]。

   The XDR description of this parameter is:

このパラメタのXDR記述は以下の通りです。

                          unsigned int PATH_MTU;

未署名のint PATH_MTU。

 3.6. TOKEN_BUCKET_TSPEC

3.6. _トークン_バケツTSPEC

   This parameter is used to describe data traffic parameters using a
   simple token bucket filter. This parameter is used by data senders to
   describe the traffic parameters of traffic it expects to generate,
   and by QoS control services to describe the parameters of traffic for
   which the reservation should apply. It is defined as a general rather
   than service-specific parameter because the same traffic description
   may be used by several QoS control services in some situations.

このパラメタは、簡単なトークンバケットフィルタを使用することでデータ通信量パラメタについて説明するのに使用されます。 このパラメタは、予約が申し込まれるべきであるトラフィックのパラメタについて説明するのにそれが生成すると予想するトラフィックのトラフィックパラメタについて説明するデータ送付者、およびQoSコントロールサービスで使用されます。 同じトラフィック記述がいくつかの状況でいくつかのQoSコントロールサービスで使用されるかもしれないので、それはサービス特有であるというよりむしろ一般的なパラメタと定義されます。

      NOTE: All previous definitions in this note have described
      "characterization parameters", with local values set by network
      elements to characterize their behavior and composition rules to
      give the resulting end-to-end behavior. The TOKEN_BUCKET_TSPEC is
      not a characterization parameter, because intermediate nodes
      within the network do not export local values for
      TOKEN_BUCKET_TSPECs. The TOKEN_BUCKET_TSPEC is simply a data
      structure definition given here because it is common to more than
      one QoS control service.

以下に注意してください。 この注意との前のすべての定義が「特殊化パラメタ」について説明しました、ネットワーク要素によって終わりから終わりへの結果として起こる振舞いを与えるために彼らの振舞いと構成規則を特徴付けるように設定された地方の値で。 ネットワークの中の中間的ノードがTOKEN_BUCKET_TSPECsのために地方の値をエクスポートしないので、TOKEN_BUCKET_TSPECは特殊化パラメタではありません。 TOKEN_BUCKET_TSPECは単にそれが1つ以上のQoSコントロールサービスに共通であるのでここに与えられたデータ構造定義です。

   The TOKEN_BUCKET_TSPEC parameter is assigned parameter_number 127.

パラメタ_No.127はTOKEN_BUCKET_TSPECパラメタに割り当てられます。

   The TOKEN_BUCKET_TSPEC takes the form of a token bucket specification
   plus a peak rate [p], minimum policed unit [m], and a maximum packet
   size [M].

TOKEN_BUCKET_TSPECはトークンバケツ仕様、ピークレート[p]、最小の取り締まられた単位[m]、および最大のパケットサイズ[M]の形を取ります。

   The token bucket specification includes an average or token rate [r]
   and a bucket depth [b].  Both [r] and [b] must be positive.

トークンバケツ仕様は平均かトークンレート[r]とバケツの深さ[b]を含んでいます。 [r]と[b]の両方が積極的であるに違いありません。

   The token rate [r] is measured in bytes of IP datagrams per second.
   Values of this parameter may range from 1 byte per second to 40
   terabytes per second. In practice, only the first few digits of the
   [r] and [p] parameters are significant, so the use of floating point
   representations, accurate to at least 0.1% is encouraged.

トークンレート[r]は1秒あたりのバイトのIPデータグラムで測定されます。 このパラメタの値は1秒あたり1バイトから40まで1秒あたりのテラバイトに及ぶかもしれません。 少なくとも0.1%に正確な浮動小数点表示の使用が重要であることで、実際には、[r]と[p]パラメタの最初の数ケタだけが重要です。奨励にされる。

   The bucket depth, [b], is measured in bytes. Values of this parameter
   may range from 1 byte to 250 gigabytes. In practice, only the first
   few digits of the [b] parameter are significant, so the use of
   floating point representations, accurate to at least 0.1% is
   encouraged.

バケツの深さ([b])はバイトで測定されます。 このパラメタの値は1バイトから250のギガバイトまで及ぶかもしれません。 少なくとも0.1%に正確な浮動小数点表示の使用が重要であることで、実際には、[b]パラメタの最初の数ケタだけが重要です。奨励にされる。

   The peak traffic rate [p] is measured in bytes of IP datagrams per
   second. Values of this parameter may range from 1 byte per second to
   40 terabytes per second. In practice, only the first few digits of

ピークトラフィックレート[p]は1秒あたりのバイトのIPデータグラムで測定されます。 このパラメタの値は1秒あたり1バイトから40まで1秒あたりのテラバイトに及ぶかもしれません。 習慣、最初の数ケタだけ

Shenker & Wroclawski        Standards Track                    [Page 13]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[13ページ]。

   the [r] and [p] parameters are significant, so the use of floating
   point representations, accurate to at least 0.1% is encouraged. The
   peak rate value may be set to positive infinity, indicating that it
   is unknown or unspecified.

少なくとも0.1%に正確な浮動小数点表示の使用が重要であることで、[r]と[p]パラメタは重要です。奨励にされる。 それが未知である、または不特定であることを示して、ピークレート価値は陽の無限に設定されるかもしれません。

   The range of values allowed for these parameters is intentionally
   large to allow for future network technologies. A particular network
   element is not expected to support the full range of values.

これらのパラメタのために許容された値の範囲は、将来のネットワーク技術を考慮するために故意に大きいです。 特定のネットワーク要素が最大限の範囲の値をサポートしないことが期待されます。

   The minimum policed unit, [m], is an integer measured in bytes.  This
   size includes the application data and all protocol headers at or
   above the IP level (IP, TCP, UDP, RTP, etc.). It does not include the
   link-level header size, because these headers will change in size as
   the packet crosses different portions of the internetwork.

最小の取り締まられた単位([m])はバイトで測定された整数です。 このサイズはレベルにおいて、または、IPレベル(IP、TCP、UDP、RTPなど)を超えてアプリケーションデータとすべてのプロトコルヘッダーを含んでいます。 それはリンク・レベルヘッダーサイズを含んでいません、パケットがインターネットワークの異なった部分を越えるのに応じてこれらのヘッダーがサイズで変化するので。

   All IP datagrams less than size [m] are treated as being of size m
   for purposes of resource allocation and policing. The purpose of this
   parameter is to allow reasonable estimation of the per-packet
   resources needed to process a flow's packets (maximum packet rate can
   be computed from the [b] and [m] terms) and to reasonably bound the
   bandwidth overhead consumed by the flow's link-level packet headers.
   The maximum bandwidth overhead consumed by link-level headers when
   carrying a flow's packets is bounded by the ratio of the link-level
   header size to [m]. Without the [m] term, it would be necessary to
   compute this bandwidth overhead assuming that every flow was always
   sending minimum-sized packets, which is unacceptable.

サイズ[m]より少ないすべてのIPデータグラムが資源配分と取り締まりの目的のためにサイズmの存在として扱われます。 このパラメタの目的は帯域幅オーバーヘッドが流れのリンク・レベルパケットのヘッダーで消費した流れのパケット([b]と[m]用語から最大のパケットレートを計算できる)を処理して、合理的にバウンドするのに必要である1パケットあたりのリソースの合理的な見積りを許容することです。 リンク・レベルヘッダーサイズ対[m]の比率に従って、流れのパケットを運ぶときリンク・レベルヘッダーによって消費された最大の帯域幅オーバーヘッドは境界があります。 [m]用語がなければ、あらゆる流れがいつも最小限サイズのパケットを送ったと仮定するこの帯域幅オーバーヘッドを計算するのが必要でしょう。(オーバーヘッドは容認できません)。

   The maximum packet size, [M], is the biggest packet that will conform
   to the traffic specification; it is also measured in bytes.  Any
   packets of larger size sent into the network may not receive QoS-
   controlled service, since they are considered to not meet the traffic
   specification.

最大のパケットサイズ([M])はトラフィック仕様に従う最も大きいパケットです。 また、それはバイトで測定されます。 ネットワークに送られたより大きいサイズのどんなパケットもQoSの制御サービスを受けないかもしれません、彼らがトラフィック仕様を満たさないと考えられるので。

   Both [m] and [M] must be positive, and [m] must be less then or equal
   to [M].

[m]と[M]の両方が積極的であるに違いなく、[m]は以下がその時か[M]への同輩であったなら積極的でなければなりません。

   The XDR description of this parameter is:

このパラメタのXDR記述は以下の通りです。

         struct {
           float r;
           float b;
           float p;
           unsigned m;
           unsigned M;
         } TOKEN_BUCKET_TSPEC;

struct浮遊物r; 浮遊物b; pを浮かべます; 未署名のm; 未署名のM;のTOKEN_BUCKET_TSPEC。

Shenker & Wroclawski        Standards Track                    [Page 14]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[14ページ]。

   For the fields [r] and [b] only valid non-negative floating point
   numbers are allowed. Negative numbers (including "negative zero),
   infinities, and NAN's are not allowed.

分野[r]と[b]だけにおいて、有効な非否定的な浮動小数点は許容されています。 負数、(包含、「負のゼロ)、無辺際、およびNANが許容されていない、」

   For the field [p], only valid non-negative floating point numbers or
   positive infinity are allowed. Negative numbers (including "negative
   zero), negative infinities, and NAN's are not allowed.

分野[p]において、有効な非否定的な浮動小数点だけか陽の無限が許容されています。 負数、(包含、「負のゼロ)、無辺際、およびNANが許容されていないネガ、」

      NOTE: An implementation which utilizes general-purpose hardware or
      software IEEE floating-point support may wish to verify that
      arriving parameter values meet these requirements before using the
      values in floating-point computations, in order to avoid
      unexpected exceptions or traps.

以下に注意してください。 汎用のハードウェアかソフトウェアのIEEEの浮動小数点のサポートを利用する実装は、浮動小数点の計算に値を使用する前に到着しているパラメタ値がこれらの必要条件を満たすことを確かめたがっているかもしれません、予期していなかった例外か罠を避けるために。

4. Security Considerations

4. セキュリティ問題

   Implementation of the characterization parameters described in this
   memo creates no known new avenues for malicious attack on the network
   infrastructure.  Implementation of these characterization parameters
   does, of necessity, reveal some additional information about a
   network's performance, which in extremely rare circumstances could be
   viewed as a security matter by the network provider.

このメモで説明された特殊化パラメタの実装は悪意ある攻撃のためにどんな知られている新しい大通りもネットワークインフラに作成しません。 これらの特殊化パラメタの実装はします、必要であり、ネットワークの性能に関する何らかの追加情報を明らかにしてください。(非常にまれな事情では、セキュリティがネットワーク内の提供者で重要であるときに、性能を見ることができました)。

5. References

5. 参照

   [RFC 2005] Braden, R., Ed., et. al., "Resource Reservation Protocol
   (RSVP) - Version 1 Functional Specification", RFC 2205, September
   1997.

[RFC2005] ブレーデン、R.、エド、etアル、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、9月1997日

   [RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
   Services", RFC 2210, September 1997.

[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。

   [RFC 2216] Shenker, S., and J. Wroclawski, "Network Element QoS
   Control Service Specification Template", RFC 2216, September 1997.

[RFC2216] Shenker、S.、およびJ.Wroclawski、「ネットワーク要素QoS制御サービス仕様テンプレート」、RFC2216、1997年9月。

   [RFC 2212] Shenker, S., Partridge, C., and R. Guerin "Specification
   of the Guaranteed Quality of Service", RFC 2212, September 1997.

[RFC2212]のShenker、S.、ヤマウズラ、C.、およびR.ゲラン、「保証されたサービスの質の仕様」、RFC2212、9月1997日

   [RFC 2211] Wroclawski, J., "Specification of the Controlled Load
   Quality of Service", RFC 2211, September 1997.

[RFC2211] Wroclawski、J.、「制御負荷サービスの質の仕様」、RFC2211、1997年9月。

   [RFC 1832] Srinivansan, R., "XDR: External Data Representation
   Standard", RFC 1832, August 1995.

Srinivansan、[RFC1832]R.、「XDR:」 「外部データ表現規格」、RFC1832、1995年8月。

Shenker & Wroclawski        Standards Track                    [Page 15]

RFC 2215          General Characterization Parameters     September 1997

Shenker&Wroclawski規格は一般的性質パラメタ1997年9月にRFC2215を追跡します[15ページ]。

Authors' Addresses

作者のアドレス

   Scott Shenker
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304-1314

コヨーテヒル・Roadパロアルト、スコットShenkerゼロックスPARC3333カリフォルニア94304-1314

   Phone: 415-812-4840
   Fax:   415-812-4471
   EMail: shenker@parc.xerox.com

以下に電話をしてください。 415-812-4840 Fax: 415-812-4471 メールしてください: shenker@parc.xerox.com

   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139

ジョンWroclawski MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139

   Phone: 617-253-7885
   Ffax:  617-253-2673 (FAX)
   EMail: jtw@lcs.mit.edu

以下に電話をしてください。 617-253-7885Ffax: 617-253-2673(ファックスする)に、メールしてください: jtw@lcs.mit.edu

Shenker & Wroclawski        Standards Track                    [Page 16]

Shenker&Wroclawski標準化過程[16ページ]