RFC2216 日本語訳
2216 Network Element Service Specification Template. S. Shenker, J.Wroclawski. September 1997. (Format: TXT=53655 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Shenker
Request for Comments: 2216 J. Wroclawski
Category: Informational Xerox PARC/MIT LCS
September 1997
Shenkerがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2216年のJ.Wroclawskiカテゴリ: 情報のゼロックスPARC/MIT LCS1997年9月
Network Element Service Specification Template
ネットワーク要素サービス仕様テンプレート
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. The specification template includes per-element requirements such as the service's packet handling behavior, parameters required and made available by the service, traffic specification and policing requirements, and traffic ordering relationships. It also includes evaluation criteria for elements providing the service, and examples of how the service might be implemented (by network elements) and used (by applications).
このドキュメントはネットワーク要素で提供されて、アプリケーションに利用可能なサービスを指定するためにフレームワークを定義します、複数のサービスの品質を提供するインターネットワークで。 ドキュメントは最初に、何らかの必要な文脈を提供します--関連定義と提案されたデータを含んでいるのは、サービス仕様ドキュメントが続くはずである「テンプレート」をフォーマットして、次に、指定します。 仕様テンプレートはサービスのパケット取り扱いの振舞いや、サービスと、トラフィック仕様と要件を取り締まることによって必要であり、利用可能にされたパラメタや、関係を命令するトラフィックなどの1要素あたりの要件を含んでいます。 また、それはサービスを提供する要素のための評価基準、およびサービスがどう実装されて(ネットワーク要素に従って)、利用されるかもしれないかに関する(アプリケーションで)例を含んでいます。
Introduction
序論
This document defines the framework used to specify the functionality of internetwork system components which support the the ability to provide multiple, dynamically selectable qualities of service to applications using an internetwork. The behavior of individual routers and subnetworks is captured as a set of "services", some or all of which may be offered by each element. The concatenation of these services along the end-to-end data paths used by an application provides overall quality of service control.
このドキュメントは複数の、そして、ダイナミックに選択可能なアプリケーションに対するサービスの品質を提供する能力をサポートするインターネットワークシステムの部品の機能性を指定するのにインターネットワークを使用することで使用されるフレームワークを定義します。 1セットの「サービス」として個々のルータとサブネットワークの動きを得ます。いくつかかそのすべてが各要素によって提供されるかもしれません。 終わりから端へのアプリケーションで使用されるデータ経路に沿ったこれらのサービスの連結はサービス制御の総合的な品質を提供します。
The definition of a service states what is required of a router (or, more generally, any network element; a router, switch, subnet, etc.) which supports a particular service. The service definition also
サービスの定義は特定のサービスをサポートするルータ(より一般に、いずれも要素をネットワークでつなぎます; ルータ、スイッチ、サブネットなど)が要求されることを述べます。 サービス定義も
Shenker & Wroclawski Informational [Page 1] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[1ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
specifies parameters used to invoke the service, the relationship between those parameters and the service delivered, and the end-to- end behavior obtained by concatenating several instances of the service.
サービスを呼び出すのに使用されるパラメタ、それらのパラメタとサービスの間に提供された関係、および終わりから終わりへのいくつかのサービスのインスタンスを連結することによって得られた振舞いを指定します。
Each service definition also specifies the interface between that service and the environment. This includes the parameters needed to invoke the service, informational parameters which the service must make available for use by setup, routing, and management mechanisms, and information which should be carried between end-nodes and network elements by those mechanisms in order to achieve the desired end-to- end behavior. However, a service definition does not describe the specific protocols or mechanisms used to establish state in the network elements for flows that use the described service.
また、それぞれのサービス定義はそのサービスと環境とのインタフェースを指定します。 これは、必要な終わりから終わりへの振舞いを達成するためにそれらのメカニズムによってエンドノードとネットワーク要素の間まで運ばれるべきであるサービスを呼び出すのに必要であるパラメタ、サービスがセットアップで使用に利用可能にしなければならない情報のパラメタ、ルーティング、管理メカニズム、および情報を含んでいます。 しかしながら、サービス定義は説明されたサービスを利用する流れのためにネットワーク要素に状態を証明するのに使用される特定のプロトコルかメカニズムについて説明しません。
Services defined following the guidelines of this document are intended for use both within the global Internet and private IP networks. In certain cases a concatenation of network element services may be used to provide a range of end-to-end behaviors, some more suited to a decentralized internet and some more appropriate for a tightly managed private network. This document points out places where such distinction may be appropriate.
このドキュメントのガイドラインに従って、定義されたサービスは使用のために世界的なインターネットとプライベートアイピーネットワークの中で意図します。 ある場合には、ネットワーク要素サービスの連結は、分散インターネットでそれ以上にしっかり管理された私設のネットワークに適切な状態で合って、さまざまな終わりから終わりに振舞いで、それ以上で提供するのに使用されるかもしれません。 このドキュメントはそのような区別が適切であるかもしれない場所を指摘します。
This document is comprised of three parts. The first defines some terms used both in this document and in the various service specification documents. The second discusses data formats and representations. The third portion of the document describes the various components of the service specification template.
このドキュメントは3つの部品から成ります。 1番目はこのドキュメントと様々なサービス仕様ドキュメントで使用されるいくつかの用語を定義します。 2番目はデータ形式と表現について議論します。 ドキュメントの3番目の一部がサービス仕様テンプレートの様々な部品について説明します。
Definitions
定義
The following terms are used throughout this document. Service specification documents should employ the same terms to express these concepts.
次の用語はこのドキュメント中で使用されます。 サービス仕様ドキュメントは、これらの概念を言い表すのに同じ用語を使うはずです。
o Quality of Service (QoS)
o サービスの質(QoS)
In the context of this document, quality of service refers to the nature of the packet delivery service provided, as described by parameters such as achieved bandwidth, packet delay, and packet loss rates. Traditionally, the Internet has offered a single quality of service, best-effort delivery, with available bandwidth and delay characteristics dependent on instantaneous load. Control over the quality of service seen by applications is exercised by adequate provisioning of the network infrastructure. In contrast, a network with dynamically controllable quality of service allows individual application sessions to request network packet delivery characteristics according to their perceived needs, and may provide
このドキュメントの文脈では、サービスの質は達成された帯域幅や、パケット遅れや、パケット損失率などのパラメタによって説明されるように提供されたパケットデリバリ・サービスの本質を示します。 伝統的に、インターネットはただ一つのサービスの質を提供しました、ベストエフォート型配送、瞬時に起こっている負荷に依存する利用可能な帯域幅と遅れの特性で。 アプリケーションで見られたサービスの質のコントロールはネットワークインフラの適切な食糧を供給することで運動させられます。 対照的に、ダイナミックに制御可能なサービスの質があるネットワークは、彼らの知覚された必要性に従って個々のアプリケーションセッションがネットワークパケット配信の特性を要求するのを許容して、前提とされるかもしれません。
Shenker & Wroclawski Informational [Page 2] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[2ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
different qualities of service to different applications. It should be understood that there is a range of useful possibilities between the two endpoints of providing no dynamic QoS control at all and providing extremely precise and accurate control of QoS parameters.
異なった異なったアプリケーションに対するサービスの品質。 ダイナミックなQoSコントロールを全く提供しないで、QoSパラメタの非常に正確で正確なコントロールを提供する2つの終点の間には、さまざまな役に立つ可能性があるのが理解されるべきです。
o Network Element
o ネットワーク要素
A "Network Element" (or the equivalent shorter form "Element"), is any component of an internetwork which directly handles data packets and thus is potentially capable of exercising QoS control over data flowing through it. Network elements include routers, subnetworks, and end-node operating systems. A QoS-capable network element is one which offers one or more of the services defined according to the rules given in this document. Note that this definition, by itself, preclude QoS-capable network elements that meet performance goals purely through adequate provisioning rather than active admission and traffic control mechanisms. A "QoS-aware" network element is one which supports the interfaces (described below) required by the service definitions. Thus, a QoS-aware network element need not actually offer any of the services defined according to the format of this document; it merely needs to know how to deny service requests.
「ネットワーク要素」(または、同等なより短いフォーム「要素」)は、直接データ・パケットを扱うインターネットワークのどんなコンポーネントでありも、その結果、潜在的にそれを通して流れるデータにQoSコントロールを及ぼすことができます。 ネットワーク要素はルータ、サブネットワーク、およびエンドノードオペレーティングシステムを含んでいます。QoSできるネットワーク要素は本書では与えられた規則に従って申し出1か一層のサービスが定義したものです。 この定義自体が活発な入場よりむしろ適切な食糧を供給することで純粋に性能目標を達成するQoSできるネットワーク要素とトラフィックコントロールメカニズムを排除することに注意してください。「QoS意識している」ネットワーク要素はサービス定義で必要であるインタフェース(以下で、説明される)をサポートするものです。 したがって、QoS意識しているネットワーク要素は実際にこのドキュメントの形式に従って定義されたサービスのどれかを提供する必要はありません。 それは、単にサービスのリクエストを否定する方法を知る必要があります。
o Flow
o 流れ
For the purposes of this document a flow is a set of packets traversing a network element all of which are covered by the same request for control of quality of service. At a given network element a flow may consist of the packets from a single application session, or it may be an aggregation comprising the combined data traffic from a number of application sessions.
このドキュメントの目的のために、流れはそれのすべてがサービスの質のコントロールを求める同じ要求でカバーされているネットワーク要素を横断する1セットのパケットです。 与えられたネットワーク要素では、流れはただ一つのアプリケーションセッションからのパケットから成るかもしれませんか、それが多くのアプリケーションセッションからの結合したデータ通信量を包括する集合であるかもしれません。
NOTE: this definition of a flow is different from that used in
IPv6, where a flow is defined as those packets with the same
source address and FlowID.
以下に注意してください。 流れのこの定義はIPv6で使用されるそれと異なっています。そこでは、流れが同じソースアドレスとFlowIDと共にそれらのパケットと定義されます。
Mechanisms used to associate a request for quality of service control with the packets covered by that request are beyond the scope of this document.
その要求でカバーされるパケットにサービスの質コントロールを求める要求を関連づけるのにおいて中古のメカニズムはこのドキュメントの範囲を超えています。
o Service
o サービス
The phrase "service" or "QoS Control Service" describes a named, coordinated set of QoS control capabilities provided by a single network element. The definition of a service includes a specification of the functions to be performed by the network
句の「サービス」か「QoSコントロールサービス」がただ一つのネットワーク要素によって提供されたQoSの命名されて、連携しているコントロール能力について説明します。 ネットワークによって実行されるように、サービスの定義は機能の仕様を含んでいます。
Shenker & Wroclawski Informational [Page 3] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[3ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
element, the information required by the element to perform these functions, and the information made available by the element to other elements of the system. A service is conceptually implemented within the "service module" contained within the network element.
要素..情報..必要..要素..実行..機能..情報..作る..利用可能..要素..要素..システム サービスはネットワーク要素の中に含まれた「機械船」の中で概念的に実装されます。
NOTE: The above defines a precise meaning for the word "service".
Service is a word which has a variety of meanings throughout the
networking community; the definition of "service" given here
refers specifically to the actions and responses of a single
network element such as a router or subnet. This contrasts with
the more end-to-end oriented definition of the same word seen in
some other networking contexts.
以下に注意してください。 上記は「サービス」という言葉のために正確な意味を定義します。 サービスはネットワーク共同体中にさまざまな意味を持っている単語です。 ここに与えられた「サービス」の定義は特にルータかサブネットなどのただ一つのネットワーク要素の動作と応答について言及します。 これはある他のネットワーク文脈で見られる同じ単語の、より多くの終わらせる終わりの指向の定義とひどく違います。
o Behavior
o 振舞い
A "behavior" is the QoS-related end-to-end performance seen by an application session. This behavior is the end result of composing the services offered by each network element along the path of the application's data flow.
「振舞い」は終わりから終わりへのアプリケーションセッションで見られたQoS関連の性能です。 この振舞いはアプリケーションのデータフローの経路に沿ったそれぞれのネットワーク要素によって提供されたサービスを構成するという結末です。
When each network element along a data flow path offers the same service, it is frequently possible to explain the resulting end-to- end behavior in a straightforward fashion. The behavior of a data flow path comprised of elements using different services is more complicated, and may in fact be undefined. A future version of this document may impose additional requirements on the service specification relating to multi-service concatenation.
データ流路に沿ったそれぞれのネットワーク要素が同じサービスを提供するとき、簡単なやり方で結果として起こる終わりから終わりへの振舞いについて説明するのは頻繁に可能です。 異なったサービスを利用する要素から成るデータ流路の振舞いは、より複雑であり、事実上、未定義であるかもしれません。 このドキュメントの将来のバージョンはマルチサービス連結に関連するサービス仕様に追加要件を課すかもしれません。
o Characterization
o 特殊化
A characterization is a computed approximation of the actual end-to- end behavior which would be seen by a flow requesting specific QoS services from the network. By providing additional information to the end-nodes before a flow is established, characterizations assist the end-nodes in choosing the services to be requested from the network.
特殊化は実際の終わりから終わりへのネットワークから特定のQoSサービスを要求する流れによって見られる振舞いの計算された近似です。 流れが確立される前に追加情報をエンドノードに提供することによって、特殊化はネットワークから要求されるためにサービスを選ぶのにエンドノードを助けます。
o Characterization Parameters
o 特殊化パラメタ
Characterizations are computed from a set of characterization parameters provided by each network element on the flow's path, and a composition function which computes the end-to-end characterization from those parameters. The composition function may in practice be executed in a distributed fashion by the setup or routing protocol, or the characterization parameters may be gathered to a single point and the characterization computed at that point.
特殊化は流れの経路のそれぞれのネットワーク要素によって提供された1セットの特殊化パラメタ、およびそれらのパラメタから終わりから終わりへの特殊化を計算する構成関数から計算されます。 構成機能が実際にはセットアップかルーティング・プロトコルによって分配されたファッションで実行されるかもしれませんか、または特殊化パラメタは1ポイントとその時計算された特殊化に集められるかもしれません。
Shenker & Wroclawski Informational [Page 4] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[4ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
Several characterizations may be computed for a single candidate data flow. Conversely, a service may provide no characterizations, and under some conditions no characterizations may be available to the end-nodes requesting QoS services.
いくつかの特殊化がただ一つの候補データフローのために計算されるかもしれません。 逆に、サービスは特殊化を全く提供しないかもしれません、そして、いくつかの状態の下で、どんな特殊化もQoSサービスを要求するエンドノードに利用可能でないかもしれません。
o Composition Function
o 構成機能
A composition function accepts characterization parameters as input and computes a characterization, as described above.
構成関数は、上で説明されるように入力されるように特殊化パラメタを受け入れて、特殊化を計算します。
o Traffic Specification (TSpec)
o トラフィック仕様(TSpec)
A Traffic Specification, or TSpec, is a description of the traffic pattern for which service is being requested. In general, the TSpec forms one side of a "contract" between the data flow and the service. Once a service request is accepted, the service module has agreed to provide a specific QoS as long as the flow's data traffic continues to be accurately described by the TSpec.
Traffic Specification、またはTSpecがサービスが要求されているトラフィック・パターンの記述です。 一般に、TSpecはデータフローとサービスとの「契約」の半面を形成します。 いったんサービスのリクエストを受け入れると、流れのデータ通信量が、TSpecによって正確に説明され続けている限り、機械船は、特定のQoSを提供するのに同意しました。
As examples, this specification might take the form of a token bucket filter (defined below) or an upper bound on the peak rate. Note that the traffic specification specifies the flow's *allowed* traffic pattern, not the flows *actual* traffic pattern. The behavior of a service when a flow's actual traffic does not conform to the traffic specification must be defined by the service (see "Policing" below).
例として、この仕様はピークレートでトークンバケットフィルタ(以下では、定義される)のフォームか上限を取るかもしれません。 トラフィック仕様が実際の*トラフィックが型に基づいて作る流れ*ではなく、*トラフィック・パターンが許容された流れの*を指定することに注意してください。 流れの実際のトラフィックがトラフィック仕様に従わないとき、サービスでサービスの振舞いを定義しなければなりません(以下の「取り締まり」を見てください)。
o Service Request Specification (RSpec)
o サービスのリクエスト仕様(RSpec)
A Service Request Specification, or RSpec, is a specification of the quality of service a flow wishes to request from a network element. The contents of a service request specification is highly specific to a particular service. As examples, these specifications might contain information about bandwidth allocated to the flow, maximum delays, or packet loss rates.
Service Request Specification、またはRSpecが流れがネットワーク要素から要求したがっているサービスの質の仕様です。 サービスのリクエスト仕様の内容は特定のサービスに非常に特定です。 例として、これらの仕様は流れ、最大の遅れ、またはパケット損失率に割り当てられた帯域幅の情報を含むかもしれません。
o Setup Protocol
o セットアッププロトコル
A setup protocol is used to carry QoS-related information from the end-nodes requesting QoS control to network elements which must exercise that control, and to install and maintain to required QoS control state in those network elements. A setup protocol may also be used to collect QoS-related information from interior network elements along an application's data flow path for ultimate delivery to end nodes. Examples of protocols which perform setup functions are RSVP [RFC 2205], ST-II [RFC 1819], and Q.2931.
セットアッププロトコルは、そのコントロールを運動させなければならない要素をネットワークでつないで、インストールするようQoSコントロールに要求するエンドノードからQoS関連の情報を運んで、それらのネットワーク要素で状態を制御するように必要なQoSに保守するのに使用されます。 また、セットアッププロトコルは、究極の配送がノードを終わらせるようにアプリケーションのデータ流路に沿って内部のネットワーク要素でQoS関連の情報を集めるのに使用されるかもしれません。 セットアップ機能を実行するプロトコルに関する例は、RSVP[RFC2205]と、ST-II[RFC1819]と、Q.2931です。
Shenker & Wroclawski Informational [Page 5] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[5ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
Note that other mechanisms, such as network management protocols, may also perform this function. The phrase "setup protocol" conventionally refers to a protocol with this function as its primary purpose.
また、ネットワーク管理プロトコルなどの他のメカニズムがこの機能を実行するかもしれないことに注意してください。 「セットアッププロトコル」という句はこの機能で慣習上プライマリ目的とプロトコルを呼びます。
o Token Bucket
o トークンバケツ
A Token Bucket is a particular form of traffic specification consisting of a "token rate" r and a "bucket size" b. Essentially, the r parameter specifies the continually sustainable data rate, while the b parameter specifies the extent to which the data rate can exceed the sustainable level for short periods of time. More specifically, the traffic must obey the rule that over all time periods, the amount of data sent cannot exceed rT+b, where T is the length of the time period.
Token Bucketは「トークンレート」rと「バケツサイズ」bから成る特定のフォームのトラフィック仕様です。 本質的には、rパラメタは絶えず持続可能なデータ信号速度を指定します、bパラメタがデータ信号速度が短い期間に持続可能なレベルを超えることができる範囲を指定しますが。 より明確に、トラフィックはすべての期間にわたって送られたデータ量がTが期間の長さであるrT+bを超えることができないという規則に従わなければなりません。
Token buckets are further discussed in [PARTRIDGE].
[PARTRIDGE]でさらにトークンバケツについて議論します。
o Token Bucket Filter
o トークンバケットフィルタ
A Token Bucket Filter is a filtering or policing function which differentiates those packets in a traffic flow which conform to a particular token bucket specification from those packets which do not. The specific treatment accorded nonconforming packets is not specified in this definition; common actions are relegating the packet to best effort service, discarding the packet, or marking the packet in some fashion.
Token Bucket Filterは交通の流れにおけるそうしないそれらのパケットからの特定のトークンバケツ仕様に従うそれらのパケットを差別化するフィルタリングか取り締まり機能です。 パケットを「非-従」わせながら一致される特殊療法はこの定義で指定されません。 一般的な動作は、何らかのファッションでベストエフォート型サービスにパケットを左遷するか、パケットを捨てるか、またはパケットをマークしています。
o Admission Control
o 入場コントロール
Admission control is the process of deciding whether a newly arriving request for service from a network element can be granted. This action must be performed by any service which wishes to offer absolute quantitative bounds on overall performance. It is not necessary for services which provide only relative statements about performance, such as the Internet's current best-effort service. The precise criteria for making the admission control decision are a specific to each particular service.
入場コントロールはネットワーク要素からのサービスを求める新たに到着している要求は承諾できるかどうか決めるプロセスです。 総合的な性能のときに絶対量的な領域を提供したがっているどんなサービスでもこの動作を実行しなければなりません。 それはインターネットの現在のベストエフォート型サービスなどの性能に関する相対的な声明だけを提供するサービスに必要ではありません。 入場コントロール決定をする正確な評価基準はそれぞれの特定のサービスへの詳細です。
o Policing
o 取り締まり
Policing is the set of actions triggered when a flow's actual data traffic characteristics exceed the expected values given in the flow's traffic specification. Services which require policing functions to operate correctly must specify both the action to be
取り締まりは流れの実際のデータ通信量の特性が流れのトラフィック仕様で与えられた期待値を超えているとき引き起こされた動作のセットです。 正しく必須を操作するために機能を取り締まるのを必要とするサービスが両方の動作を指定する、
Shenker & Wroclawski Informational [Page 6] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[6ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
taken when such discrepancies occur and the locations in the network where discrepancies are to be detected. Examples of such actions might include relegating the packet to best effort service, dropping packets, reshaping the traffic, or marking non-conforming traffic in some fashion.
検出される食い違いがことであるネットワークでそのような食い違いがいつ起こるか、そして、位置を取ります。 そのような動作に関する例は、ベストエフォート型サービスにパケットを左遷するのを含むかもしれません、パケットを下げて、何らかのファッションでトラフィックを造り直すか、または非の従うトラフィックをマークして。
o Interfaces
o インタフェース
The service module conceptually interacts with other portions of the network element through a number of interfaces. The service specification document should clearly define the specific data, including formats, which moves across each conceptual interface, and ensure that the mapping between conceptual interfaces and the specific mechanisms of the service being defined are clear.
機械船は多くのインタフェースを通して概念的にネットワーク要素の他の一部と対話します。 サービス仕様ドキュメントは明確に特定のデータを定義するはずです、はっきりと定義されるサービスの概念的なインタフェースと特定のメカニズムの間のマッピングがある形式(それぞれの向こう側に概念的な移動は、連結して、確実にする)を含んでいて。
Data Format and Representation
データの形式と表現
A service module will import and export a variety of data according to the specific requirements of the services the network element supports. Each service definition MUST specify the format of each such data item in an abstract manner. The information specified must be sufficient for the designer of a setup protocol to correctly select an appropriate concrete (packet) format for variables containing this data. At minimum, the following information must be given:
ネットワーク要素がサポートするサービスの決められた一定の要求に従って、機械船は、さまざまなデータを意味して、エクスポートするでしょう。 それぞれのサービス定義は抽象的な方法によるそのようなそれぞれのデータ項目の形式を指定しなければなりません。 セットアッププロトコルのデザイナーが正しくこのデータを含む変数のための適切な具体的な(パケット)形式を選択するように、指定された情報は十分でなければなりません。 最小限では、以下の情報を与えなければなりません:
- Type: whether the quantity is an enumeration, a numerical value,
etc.
- 以下をタイプしてください。 量が列挙であるか否かに関係なく、数値ですなど。
- Range: for numerical quantities, the minimum and maximum values
the quantity must be able to represent. For enumerated quantities,
an estimate of the maximum number of items which may need be
enumerated in the future, even if many of the values are currently
unused.
- 範囲: 数量、量が表すことができなければならない最小の、そして、最大の値のために。 列挙された量において、そうするかもしれない項目の最大数の見積りは将来列挙されなければなりません、値の多くが現在未使用であっても。
- Precision: the precision with which a numerical quantity must be
represented, and whether that precision is absolute (calling for an
integer quantity) or a percentage of the value (allowing for a
floating point quantity).
- 精度: 数量を表さなければならない精度と、その精度は絶対であるか、そして、(整数量を求めて)価値の割合(浮動小数点量を考慮します)。
The service definition SHOULD additionally specify a preferred concrete format for each data field, in the usual packet-layout format used in current Internet Standard documents or in some other accepted specification format. If the service definition contains these concrete definitions, they should be sufficiently complete and detailed to allow the service definition to be incorporated by reference into the specifications for setup protocols and other users of the specified data.
サービス定義SHOULDはさらに、各データ・フィールドのための都合のよい具体的な形式を指定します、現在のインターネットStandardドキュメントかある他の受け入れられた仕様形式に使用される普通のパケットレイアウト形式で。 サービス定義がこれらの具体的な定義を含んでいるなら、それらは、サービス定義が指定されたデータのセットアッププロトコルと他のユーザの仕様への参照で取り入れられるのを許容するために十分完全であって、詳細であるべきです。
Shenker & Wroclawski Informational [Page 7] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[7ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
NOTE: The wording above is intended to encourage the use of common
data formats by all protocols carrying data related to a specific
service, while not mandating this common format or infringing on
the freedom of protocol specification designers to define data
representations using alternative mechanisms such as ASN.1 or XDR.
以下に注意してください。 上の言葉遣いがこの一般的な形式を強制していない間、特定のサービスに関連するデータを運ぶか、またはASN.1かXDRなどの代替のメカニズムを使用することでプロトコル仕様デザイナーがデータ表現を定義する自由を侵害するすべてのプロトコルで一般的なデータ形式の使用を奨励することを意図します。
Service and Data Element Naming
サービスとデータ要素命名
End-nodes, network elements, setup protocols, and management entities within an integrated services internetwork need to exchange information about services, service invocation parameters, characterization parameters, and the intermediate variables and end results of composition functions. To support this requirement, a single uniform namespace is established for services and their parameters.
統合サービスインターネットワークの中のエンドノード、ネットワーク要素、セットアッププロトコル、および経営体は、サービス、サービス実施のパラメタ、特殊化パラメタ、および中間的変数の情報と構成機能の結末を交換する必要があります。 この要件をサポートするために、ただ一つの一定の名前空間はサービスとそれらのパラメタのために確立されます。
The namespace is a two-level hierarchy:
名前空間は2レベルの階層構造です:
<service_name>.<parameter_name>.
<サービス_名前><パラメタ_名前>。
Each of these elements is a integer numerical quantity.
それぞれのこれらの要素は整数数量です。
<Service Name> is an integer in the range 1 to 254. The number space is broken into three regions.
<サービスName>は1〜254に範囲の整数です。 3つの領域が数のスペースに細かく分けられます。
Service number 1 is used to indicate that the associated parameter is generic", and is not associated with a specific service. This use of generic parameters is described more fully in [RFC 2215].
「関連パラメタがジェネリックであることを示すために使用されるNo.1を修理し」て、特定のサービスに関連づけられません。 ジェネリックパラメタのこの使用は[RFC2215]で、より完全に説明されます。
The range from 2 to 127 used to name services defined by the IETF. Procedures for allocating service numbers in this region will be established by the IETF INT-SERV WG and the IANA. Services designed for public use should obtain a number from this space. The minimum requirement for doing so is a published RFC following the format described in this note.
2〜127までの範囲は以前はよくIETFによって定義されたサービスを命名していました。 この領域に認識番号を割り当てるための手順はIETF INT-SERV WGとIANAによって確立されるでしょう。 公共の使用のために設計されたサービスはこのスペースから数を得るべきです。 そうするための必要最小限はこの注意で説明された形式に続く発行されたRFCです。
Service numbers in the region above 127 are reserved for experimental or private services. Service designers may allocate numbers from this space at random for local experimental use. A policy for global but temporary allocation of these numbers may be established in the future if necessary.
127を超えた領域の認識番号は実験的であるか個人的なサービスのために予約されます。 サービスデザイナーは地方の実験用のためにこのスペースから数を無作為に割り当てるかもしれません。 必要なら、これらの数のグローバルな、しかし、一時的な配分のための方針は将来、確立されるかもしれません。
The value 0 is left unused to allow the direct mapping of parameter names to MIB object names, as described below.
値0はパラメタ名のダイレクトマッピングをMIBオブジェクト名に許容するために未使用でおかれます、以下で説明されるように。
The value 255 is reserved to facilitate future expansion of the service number space, if required.
値255は、必要なら、認識番号スペースの今後の拡張を容易にするために予約されます。
Shenker & Wroclawski Informational [Page 8] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[8ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
<Parameter_name> is a number in the range 1 to 254, allocated on a per-service basis. Within this range, the values 1 to 127 are reserved for assignment to parameters with a common, shared meaning across all services. These parameters are defined in [RFC 2215].
調査基準価格に割り当てて、<パラメタ_名前>は1〜254に範囲の数です。 この範囲の中では、値1〜127は課題のためにすべてのサービスの向こう側に一般的で、共有された意味でパラメタに予約されます。 これらのパラメタは[RFC2215]で定義されます。
Numbers for parameters specific to a service are assigned from the range 128-254 by the author of the service specification document.
サービスに特定のパラメタの数はサービス仕様ドキュメントの作者によって範囲128-254から割り当てられます。
The value 0 is left unused to allow the direct mapping of parameter names to MIB object names, as described below.
値0はパラメタ名のダイレクトマッピングをMIBオブジェクト名に許容するために未使用でおかれます、以下で説明されるように。
The value 255 is reserved to facilitate future expansion of the parameter number space, if required.
値255は、必要なら、パラメタ数のスペースの今後の拡張を容易にするために予約されます。
In addition to their uses within the integrated services framework, these <service_number>.<parameter_number> pairs should be used as last two levels of the MIB name when the corresponding values are made available to network management protocols.
ネットワーク管理プロトコルが換算値を入手するとき、統合サービスフレームワークの中の彼らの用途に加えて、><パラメタ_番号>が対にするこれらの<サービス_番号はMIB名の最後の2つのレベルとして使用されるべきです。
Specification Document Format
仕様ドキュメント・フォーマット
The following portion of this document describes the layout and contents of a service specification. Each service specification document MUST contain the sections marked [required] below, in the order listed. Each document SHOULD contain each of the remaining sections in the list below, unless there is a compelling argument that the presence of the section is not beneficial. Additional material, including references, should be included at the end of the document.
このドキュメントの以下の一部がサービス仕様のレイアウトと内容について説明します。 それぞれのサービス仕様ドキュメントはリストアップされたオーダーで以下にマークされた[必要です]セクションを含まなければなりません。 それぞれのドキュメントSHOULDは以下のリストにそれぞれの残っているセクションを含みます、セクションの存在が有益でないという無視できない主張がない場合。 指示するものを含む追加材料はドキュメントの端に含まれるべきです。
Some of these sections are normative, in that they describe specific requirements to which conformant implementations must adhere. Other sections are informational in nature, in that they describe necessary context and technical considerations important to the implementor of a service. The sections, and their nature (required or optional, and informational or normative) are listed below:
conformant実装が固守されなければならない決められた一定の要求について説明するので、これらの数人のセクションが規範的です。 他のセクションは現実に情報です、サービスの作成者にとって、重要な必要な文脈と技術的な問題について説明するので。 セクション、および下の記載された彼らの自然(必要であるか、任意の、そして、情報の、または、標準の):
o Components
o コンポーネント
The body of a service specification document incorporates the following sections:
サービス仕様ドキュメントのボディーは以下のセクションを組み込みます:
- End-to-End Behavior [required] [informational]
- 終わりから終わりへの振舞い[必要です][情報]です。
- Motivation [required] [informational]
- 動機[必要です][情報]です。
- Network Element Data Handling Requirements [required] [normative]
- ネットワーク要素データハンドリング要件[必要です][標準]です。
Shenker & Wroclawski Informational [Page 9] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[9ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
- Invocation Information [required] [normative]
- 実施の情報[必要です][標準]です。
- Exported Information [required] [normative]
- 情報[必要である]であるとエクスポートされます。[標準]です。
- Policing [required] [normative]
- 取り締まり[必要です][標準]です。
- Ordering and Merging [required] [normative]
- 注文と合併[必要です][標準]です。
- Guidelines for Implementors [optional] [informational]
- 作成者[任意の]へのガイドライン[情報]です。
- Evaluation Criteria [required] [informational]
- 評価基準[必要です][情報]です。
- Examples of Implementation [optional] [informational]
- 実装[任意の]に関する例[情報]です。
- Examples of Use [optional] [informational]
- 使用[任意の]に関する例[情報]です。
o End-to-end Behavior
o 終わりから終わりへの振舞い
This is a description of the behavior that results if all network elements along the path offer the same service, invoked with a defined set of parameters.
これは経路に沿ったすべてのネットワーク要素が定義されたセットのパラメタで呼び出された同じサービスを提供するなら結果として生じる振舞いの記述です。
In private networks it will generally be the case that the required end-to-end behavior is obtained by concatenation of network elements utilizing the same service and making significant use of characterizations.
私設のネットワークでは、一般に、同じサービスを利用して、特殊化の重要な使用をするネットワーク要素の連結で終わりから終わりへの必要な振舞いを得るのは、事実でしょう。
In the global Internet, this will not always be true. End-to-end behaviors will frequently be obtained through a concatenation of network elements supporting different services, including in some cases elements which exercise no QoS control at all. Mechanisms to characterize end-to-end behavior in this circumstance are not fully established at this time. Future versions of this document may impose additional requirements on service specifications to facilitate inter-service composition.
世界的なインターネットでは、これがいつも本当になるというわけではないでしょう。 異なったサービスをサポートするネットワーク要素の連結で終わりから終わりへの振舞いを頻繁に得るでしょう、いくつかの場合、QoSコントロールを全く運動させない要素を含んでいて。 この状況における終わりから終わりへの振舞いを特徴付けるメカニズムはこのとき、完全に確立されるというわけではありません。 このドキュメントの将来のバージョンは、相互サービス構成を容易にするために追加要件をサービス仕様に課すかもしれません。
This section is for informational purposes only.
このセクションは情報の目的だけのためのものです。
o Motivation
o 動機
This section discusses why this service is being defined. It describes what kinds of applications might make use of this service, and why this service might be more appropriate for those applications than other possible choices. This section is for informational purposes only.
このセクションは、このサービスがなぜ定義されているかを論じます。 それはどんな種類のアプリケーションがこのサービスを利用するかもしれないか、そして、それらのアプリケーションには、このサービスがなぜ他の可能な選択より適切であるかもしれないかを説明します。 このセクションは情報の目的だけのためのものです。
Shenker & Wroclawski Informational [Page 10] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[10ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
o Network Element Data Handling Requirements
o ネットワーク要素データハンドリング要件
This section contains a description of the QoS properties seen by data packets processed by a network element using this service. The description must clearly explain what variables are controlled, the degree of control exercised, and what aspects of the service's handling model are fixed or assumed. Examples of degree of control information include "this property must be mathematically assured" and "this property should be met under most conditions". An example of a stated assumption is "this service is assumed to have extremely low packet loss; delay targets must be met using admission control rather than by discarding packets when overloaded".
このセクションはネットワーク要素によってこのサービスを利用することで処理されたデータ・パケットによって見られたQoSの特性の記述を含みます。 記述で明確にどんな変数が制御されているかがわからなければならなくて、統制度が運動して、サービスの取り扱いの局面がモデル化することは、修理されているか、または想定されます。 制御情報の度合いに関する例は「特性を数学的に保証しなければならないこれ」を含んでいます、そして、「この特性はほとんどの条件のもとで満たされるべきです」。 述べられた仮定に関する例は「このサービスには非常に低いパケット損失があると思われます」です。 「遅れ目標は積みすぎられるとパケットを捨てるよりむしろ入場コントロールを使用することで達成されなければなりません。」
Requirements on packet handling SHOULD, when at all possible, be expressed as performance requirements rather than by specifying a a particular packet scheduling algorithm. The performance requirements might, for example, be a specification of the maximal packet delays or the minimal bandwidth share given to a flow.
可能であるときに、パケットに関する要件がSHOULDを扱って、a特定のパケットスケジューリングアルゴリズムを指定することによってというよりむしろ性能要件として言い表されてください。 例えば、性能要件は最大限度のパケット遅れか流れに与えられた最小量の帯域幅シェアの仕様であるかもしれません。
This section also specifies actions which the packet handling path is required to take to actively provide feedback to end-nodes about conditions at the network element. Such actions might include explicitly generated congestion feedback, indicated either as bits set in the header of data packets or separate control messages sent.
また、このセクションはパケット取り扱い経路がネットワーク要素で状態に関して活発にフィードバックをエンドノードに提供するために取るのに必要である動作を指定します。 そのような動作はビットがデータ・パケットのヘッダーにセットしたか、または別々のコントロールメッセージが発信したので示された明らかに生成している混雑フィードバックを含むかもしれません。
When writing this section of the service specification document, the authors' goal should be to specify the required behavior as precisely as necessary while still leaving adequate room for the implementation and architectural tradeoffs appropriate to different circumstances and classes of network elements. Successfully achieving this balance may require some care.
サービス仕様ドキュメントのこのセクションに書くとき、作者の目標はまだ実装と建築見返りの適切な余地を異なった事情とクラスのネットワーク要素に適切なままにしている間、まさに同じくらい必要な状態で必要な振舞いを指定することであるべきです。 首尾よくこのバランスを獲得するのは何らかの注意を必要とするかもしれません。
o Invocation Information
o 実施の情報
This section describes the set of parameters required by a service module to invoke the service, and a description of how the parameter values are used by the service module. For example, a hypothetical "bounded delay" service might be described as accepting a request indicating a delay target for the network element and the set of packets subject to that delay target, and processing packets in the given set with a delay of the target value or less.
このセクションはサービスを呼び出すために機械船によって必要とされたパラメタのセット、およびパラメタ値が機械船でどう使用されるかに関する記述について説明します。 例えば、仮定している「境界がある遅れ」サービスは目標値か以下の遅れで与えられたセットでネットワーク要素のための遅れ目標とその遅れ目標、および処理パケットを条件としたパケットのセットを示しながら申し込みに応じるとして記述されているかもしれません。
Necessary invocation information for most services can be broken into two parts, the Traffic Specification (TSpec) and the Service Request Specification (RSpec). The TSpec gives characteristics of the data
2つの部品、Traffic Specification(TSpec)、およびService Request Specification(RSpec)をほとんどのサービスのための必要な実施の情報に細かく分けることができます。 TSpecはデータの特性を与えます。
Shenker & Wroclawski Informational [Page 11] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[11ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
traffic to be handled, while the Rspec specifies the properties desired from the service. For example, a service offering a mathematical bound on delay might accept a TSpec giving the traffic flow's bandwidth and burstiness specified as a Token Bucket, and an RSpec giving the maximum tolerable queueing delay.
Rspecがサービスによって必要な特性を指定する間の扱われるべきトラフィック。 例えば、遅れに対しては数学のバウンドを提供するサービスが、交通の流れの帯域幅、Token Bucketとして指定されたburstiness、および最大の許容できる待ち行列遅れを与えるRSpecに与えながら、TSpecを受け入れるかもしれません。
A service accepting an invocation request may be thought of as entering into a "contract" to provide the service described by the RSpec as long as the flow's traffic continues to be described by the TSpec. If the flow's traffic pattern falls outside the bounds of the TSpec, the QoS provided to the flow may change. The precise nature of this change is also described by the service specification (see "Policing" below).
実施の要求を受け入れるサービスは流れのトラフィックが、TSpecによって説明され続けている限り、RSpecによって説明されたサービスを提供する「契約」に入ると考えられるかもしれません。 流れのトラフィック・パターンがTSpecの領域をそらせるなら、流れに提供されたQoSは変化するかもしれません。 また、この変化の正確な自然はサービス仕様で説明されます(以下の「取り締まり」を見てください)。
The RSPec and TSpec components of the invocation information should be specified separately and independently, as they will often be generated by different elements of the internetwork
実施の情報のRSPecとTSpecの部品は別々に、独自に指定されるべきです、それらがしばしばインターネットワークの異なった要素によって生成されるとき
All quantitative information specifications in this section should follow the guidelines given in the Data Formats section of this document, above.
このセクションのすべての量的な情報仕様がこのドキュメントのData Formats部で与えられたガイドラインに従うべきです、上です。
o Exported Information and Characterization Parameters
o 情報と特殊化パラメタであるとエクスポートされます。
This section describes information which must be collected and exported by the service module. Exported information is available to other modules of the network element, and by extension to setup protocols, routing protocols, network management tools, and the like.
このセクションは機械船で集められて、エクスポートしなければならない情報について説明します。 エクスポートしている情報はネットワーク要素の他のモジュール、およびプロトコル、ルーティング・プロトコル、ネットワークマネージメントツール、および同様のものをセットアップする拡大で利用可能です。
Information exported by service modules may be used in several ways. For example, quantities such as the amount of link bandwidth dedicated to the service and the set of data flows currently receiving the service are appropriate pieces of information to make available as network management variables.
機械船でエクスポートされた情報はいくつかの方法で使用されるかもしれません。 例えば、サービスに捧げられたリンク帯域幅の量や現在サービスを受けるデータフローのセットなどの量はネットワークマネージメント変数として利用可能にするのが適切である情報です。
A service definition may identify a particular subset of the information exported by a service module as characterization parameters. These characterization parameters may be used to compute or estimate the end-to-end behavior of a data flow traversing a concatenation of network service elements. They may also be used to characterize portions of the path for use by network elements (e.g., in computing the buffer necessary, an element may need to know something about the service characteristics of the upstream portion of the path). A service which defines characterization parameters also specifies the characterizations they are used to generate and the composition functions used to generate the characterizations.
サービス定義は特殊化パラメタとして機械船でエクスポートされた情報の特定の部分集合を特定するかもしれません。 これらの特殊化パラメタは、終わりから終わりがネットワーク・サービス要素の連結を横断するデータフローの振舞いであると計算するか、または見積もるのに使用されるかもしれません。 また、それらは、ネットワーク要素に従って使用のために経路の部分を特徴付けるのに使用されるかもしれません(例えば、バッファを計算するのにおいて、必要です、要素は経路の上流の部分のサービスの特性に関して何かを知る必要があるかもしれません)。 また、特殊化パラメタを定義するサービスはそれらが生成するのに使用されて、構成機能が特殊化を生成するのに使用した特殊化を指定します。
Shenker & Wroclawski Informational [Page 12] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[12ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
NOTE: Characterization parameters are identified as such by virtue
of being the inputs to a service's defined composition functions.
Because characterization parameters are part of a service's
overall exported data set, they are also available to other
functions, such as network management. The discussion below
relates solely to their use as characterization parameters, and is
not intended to limit other uses.
以下に注意してください。 サービスへの入力であることによるそのようなものが構成機能を定義したので、特殊化パラメタは特定されます。 特殊化パラメタがサービスの総合的なエクスポートしているデータセットの一部であるので、また、それらも他の機能に利用可能です、ネットワークマネージメントなどのように。 以下での議論は、特殊化パラメタとして唯一彼らの使用に関連して、他の用途を制限することを意図しません。
Characterization parameters may be relatively static quantities, such as the bandwidth available on a specific link, or relatively dynamic quantities, such as a running estimation of current packet delay.
特殊化パラメタは比較的静的な量であるかもしれません、特定のリンク、または比較的ダイナミックな量で利用可能な帯域幅などのように、現在のパケット遅れの実行している見積りのように。
Support for a service's defined characterization parameters is mandatory. Any network element offering this service must be able to measure, compute, or, if allowed by the specification, estimate the service's characterization parameters. Service designers are encouraged to understand the implications of specifying characterization parameters for a service, particularly with respect to not unduly restricting the choice of hardware and software architectures used to implement the network element.
サービスが特殊化パラメタを定義したので、サポートは義務的です。 このサービスを提供すると測定できなければならないどんなネットワーク要素にも、計算するか、または仕様で許容されているなら、サービスの特殊化パラメタを見積もってください。 サービスと、特にハードウェアの選択を過度に制限しないことに関して特殊化パラメタを指定しながらデザイナーが含意を理解しているよう奨励されて、ソフトウェア・アーキテクチャがネットワーク要素を実装するのに利用したサービス。
Characterization parameters are used by composing the values exported by each network element along a data flow's path according to a composition rule. For each parameter or set of parameters used to develop a characterization, the service specification must specify the composition rule to be used. These composition rules should result in characterizations that are independent of the order in which the element are composed; commutativity and associativity are sufficient but not necessary conditions for this.
特殊化パラメタは、構成規則に従ってデータフローの経路に沿ったそれぞれのネットワーク要素によってエクスポートされた値を構成することによって、使用されます。 特殊化を開発するのに使用されるそれぞれのパラメタかセットのパラメタとして、サービス仕様は、使用されるために構成規則を指定しなければなりません。 これらの構成規則は要素がどれであるかで構成されたオーダーから独立している特殊化をもたらすべきです。 交換性と会合性はこれのための十分な、しかし、必要でない状態です。
Characterization parameters are available through a general interface, and are provided in response to a request from some other module, such as a setup protocol or the routing protocol. The question of exactly how, or if, a specific protocol (e.g., RSVP) uses characterization parameters to generate characterizations is described in the specification of that specific protocol.
特殊化パラメタを一般的なインタフェースを通して利用可能であり、ある他のモジュールからの要求に対応して提供します、セットアッププロトコルやルーティング・プロトコルのように。 または、質問、ちょうどどのように、(例えば、RSVP)が特殊化を生成するのに特殊化パラメタを使用する特定のプロトコルはその特定のプロトコルの仕様で説明されます。
The correct use of characterization parameters supplied by service modules is a function of the setup, routing, or management protocol controlling the module. There is no absolute guarantee that characterizations will be available to end-nodes desiring to use a
機械船で提供された特殊化パラメタの正しい使用はモジュールを制御するセットアップ、ルーティング、または管理プロトコルの機能です。 aを使用するのが望ましくしながら特殊化が終わりノードに利用可能になるというどんな絶対保証もありません。
QoS control service. Service designers targeting services for the global Internet may wish to ensure that a service is useful even in the absence of characterizations, and to exhibit such uses in the "Examples" sections of the service description document.
QoSはサービスを制御します。 世界的なインターネットのためのサービスを狙うサービスデザイナーは、サービスが特殊化がないときでさえ役に立つのを保証して、サービス記述ドキュメントの「例」セクションのそのような用途を示したがっているかもしれません。
Shenker & Wroclawski Informational [Page 13] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[13ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
Conversely, the availability of characterizations may be mandatory in certain circumstances, particularly for private IP networks providing tightly controlled qualities of service for specific applications. Service designers targeting this environment should particularly ensure that the service provides adequate characterization parameters and composition functions to meet the needs of target audiences. It may be appropriate to specify the same basic service with additional characterizations for meeting specific requirements beyond those of the global Internet.
逆に、特殊化の有用性はある特定の状況では義務的であるかもしれません、特にしっかり制御された特定のアプリケーションのためのサービスの品質を提供するプライベートアイピーネットワークのために。 この環境を狙うサービスデザイナーは、サービスが対象者の需要を満たすために適切な特殊化パラメタと構成機能を提供するのを特に保証するべきです。 世界的なインターネットのものを超えて決められた一定の要求を満たすための追加特殊化で同じ基本サービスを指定するのは適切であるかもしれません。
Some useful "general" characterization parameters and corresponding composition rules are not associated with any specific service. These include the speed-of-light latency of communication links and available link bandwidth. These general characterization parameters are defined in [RFC 2215].
いくつかの役に立つ「一般的な」特殊化パラメタと対応する構成規則はどんな特定のサービスにも関連づけられません。 これらは通信リンクと利用可能なリンク帯域幅の光速潜在を含んでいます。 これらの一般的性質パラメタは[RFC2215]で定義されます。
Although every conformant implementation of a service is required to provide that service's characterization parameters, it is still possible that the desired characterization parameters will not be available for composition at all network elements in a path. This situation may arise when different network element services are used at different points in the end-to-end path, as may be required in a heterogeneous internetworking environment. For this reason, characterization parameters and composition function results conceptually include a "validity flag". A network element which is unable to provide the characterization parameter must set this flag, and otherwise leave parameter or composed value unchanged. Once set, the flag is preserved by the composition function, and serves as an indicator of the validity of the data when the final composed result is delivered to its destination.
あらゆるサービスのconformant実装がそのサービスの特殊化パラメタを提供するのに必要ですが、必要な特殊化パラメタが経路ですべてのネットワーク要素での構成に利用可能にならないのは、まだ可能です。 異なったネットワーク要素サービスが終わらせる終わりの異なったポイント経路で利用されるとき、この状況は起こるかもしれません、異種のインターネットワーキング環境で必要であるかもしれないように。 この理由で、特殊化パラメタと構成関数結果は概念的に「正当性旗」を含んでいます。 この旗を設定します。そうでなければ、特殊化パラメタを提供できないネットワーク要素は、パラメタか落ち着いた値を変わりがないままにしなければなりません。 いったん設定されると、旗は、構成機能によって保存されて、決勝が結果を構成したとき、データの正当性のインディケータが送付先に提供されるとき、役立ちます。
Protocols which transport characterization parameters and composition data must define and support a concrete representation for this validity flag, as well as for the characterization parameters themselves.
特殊化パラメタと構成データを輸送するプロトコルは、この正当性旗の具体的な表現を定義して、サポートしなければなりません、よく特殊化パラメタ自体のように。
NOTE: This service specification template does not allow a service definition to *require* that a setup or invocation mechanism used with the service perform any function other than transport of invocation parameters to the network elements and signalling of errors generated by the network elements to the end nodes. A notable example of this is that service specification documents may not require or assume that characterizations defined in the specification are actually computed or presented to the end nodes.
以下に注意してください。 このサービス仕様テンプレートは、*サービスと共に使用されるセットアップか実施のメカニズムが実施のパラメタの輸送以外のどんな機能もネットワーク要素に実行するのが必要であり、ネットワーク要素によってエンドノードに生成された誤りに合図しながら、サービス定義を*に許しません。 この注目に値する例はサービス仕様ドキュメントが、仕様に基づき定義された特殊化がエンドノードに実際に計算されるか、または提示されると必要でない、仮定しないかもしれないということです。
That point notwithstanding, the practical usefulness of a specific service may be highly dependent on the presence of some additional behavior in the networked system, such as the computation and
そしてそのポイントにもかかわらず、実用的な特定にサービスの有用性はネットワークでつながれたシステムでの何らかの追加振舞いの存在に非常に依存しているかもしれません、計算などのように。
Shenker & Wroclawski Informational [Page 14] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[14ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
presentation of characterizations to end-nodes or the reliable assurance that every network element in the path from sender to receivers supports the given service. Service specification authors are strongly encouraged to clearly explain the situation of their service in this regard. Statements such as:
エンドノードへの特殊化のプレゼンテーションか送付者から受信機までの経路のあらゆるネットワーク要素が与えられたサービスをサポートするという信頼できる保証。 サービス仕様作者が明確にこの点で彼らのサービスの状況について説明するよう強く奨励されます。 以下などの声明
The characterizations defined by this service serve as useful
hints to the application. However, the service is specifically
intended to be useful even if characterizations are not available.
このサービスで定義された特殊化は役に立つヒントとしてアプリケーションに機能します。 しかしながら、明確に、特殊化が利用可能でなくても、サービスが役に立つことを意図します。
or
または
The usefulness of this service depends strongly on the delivery of
both characterizations and the knowledge that all network elements
on the path support the service. Requests for this service when
characterizations are not available are likely to lead to
incorrect or misleading results.
このサービスの有用性は強く特殊化と経路のすべてのネットワーク要素がサービスをサポートするという知識の両方の配送に依存します。 特殊化が利用可能でないときに、このサービスを求める要求は不正確であるか紛らわしい結果に通じそうです。
are appropriate. It may also be useful to consider this point in the "Examples of Use" section described below.
適切。 また、以下で説明された「使用に関する例」セクションのこのポイントを考えるのも役に立つかもしれません。
NOTE: The possibility of modifying the overall architecture to provide information about the invoking protocol in a service request, and to allow a service to require that the invocation protocol support specific additional functionality, is an area of active study.
以下に注意してください。 総合的なアーキテクチャを変更するのが、呼び出しプロトコルの情報をサービスのリクエストに前提として、サービスが、実施のプロトコルが特定の追加機能性をサポートするのを必要とするのを許容する可能性は活発な研究の領域です。
o Policing
o 取り締まり
This portion of the service description describes the nature of policing used to enforce adherence to a flow's Traffic Specification. The specification document must specify the following points
サービス記述のこの部分は流れのTraffic Specificationに支持を強要するのに使用される取り締まりの自然について説明します。 仕様ドキュメントは以下のポイントを指定しなければなりません。
- Expected policing action. This is the action taken when packets
not conforming to the TSpec are detected. Example actions include
relegating nonconforming packets to best effort, immediately
dropping nonconforming packets, delaying these packets until they
once again "fit" into the TSpec, or "marking" nonconforming packets
in some way.
- 動作を取り締まりながら、予想されます。 これはTSpecに従わないパケットが検出されるとき取られた行動です。 例の動作は、ベストエフォート型の、そして、すぐに低下している「非-従」うパケットにパケットを「非-従」わせながら、左遷するのを含んでいます、もう一度TSpecに「合う」までこれらのパケットを遅らせるか、または何らかの方法で「非-従」うパケットを「マークし」て。
- Legality of alternative policing actions. The section must
specify whether actions not specifically mentioned in
specification's description of policing behavior are legal. For
example, a service description which specifies that nonconforming
packets are to be dropped should state whether an alternate action,
such as delaying these packets, is acceptable.
- 動作を取り締まる代替手段の合法。 セクションは、仕様の取り締まりの振舞いの記述で明確に言及しなかった動作が法的であるかどうか指定しなければなりません。 例えば、「非-従」うパケットが下げられることになっていると指定するサービス記述は、これらのパケットを遅らせなどなどの代替の動作が許容できるかどうかと述べるべきです。
Shenker & Wroclawski Informational [Page 15] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[15ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
- Location of policing actions in the internetwork. The description
of policing must specify where that policing is done. Possibilities
include "at the edges of the network only", "at every hop",
"heterogeneous branch points" (points where the branches of a
multicast tree converge and have different TSpecs reserved
downstream), and "source merge points" (points where multiple data
streams covered by a single resource reservation converge). The
specification should clearly state requirements about topology
information (for example "this is an edge node" or "this is a
source merge point") which must be available from the setup
protocol or another source.
- インターネットワークにおける取り締まり動作の位置。 取り締まりの記述は、どこでその取り締まりをするかを指定しなければなりません。 ポシビリティーズは「ネットワークの縁専用」、「あらゆるホップ」、「異種のブランチポイント」(マルチキャスト木の枝で一点に集めて、川下で異なったTSpecsを予約するポイント)、および「ソースマージポイント」(ただ一つの資源予約でカバーされた複数のデータ・ストリームが一点に集まるポイント)を含んでいます。 仕様はセットアッププロトコルか別のソースより利用可能であるに違いないトポロジー情報(例えば、「これは縁のノードである」か「これはソースマージポイントである」)に関する要件を明確に述べるべきです。
In this section the specification should also specify the legality
of policing at additional points in the network, beyond those
listed above. This is important due to technical effects such as
are described in the next paragraph.
また、このセクションでは、仕様はネットワークで追加ポイントでの取り締まりの合法を指定するべきです、上に記載されたものを超えて。 これは次のパラグラフで説明されるような技術的効果のために重要です。
Applicable additional technical considerations. If policing of data
flows is required or legal at points other than the flow's first
entry into the network, the service definition should describe any
additional technical considerations which affect the design of such
policing. For example, many potential services will allow a data
flow to become more bursty as it progresses through the network. If
such a service allows policing at points other than the network
edge, the traffic specification describing the flow will have to be
modified from that given by the application to the network to
account for this growing burstiness. Otherwise, it is likely that
the flow will be overpoliced, with packets being penalized
unnecessarily.
適切な追加技術的な問題。 データフローの取り締まりがネットワークへの流れの初記入以外のポイントで必要であるか、または法的であるなら、サービス定義はそのような取り締まりのデザインに影響するどんな追加技術的な問題についても説明するべきです。 例えば、多くの潜在的サービスによって、ネットワークを通して進歩をするとき、データフローは、より多くのburstyになるでしょう。 そのようなサービスが、ネットワーク縁以外のポイントで取り締まるのを許容すると、流れについて説明するトラフィック仕様は、この増加しているburstinessの原因になるようにアプリケーションで与えられたそれからネットワークまで変更されなければならないでしょう。 さもなければ、パケットが不必要に罰せられている状態で、流れは「過剰-取り締ま」られそうでしょう。
o Ordering and Merging
o 注文と合併
Ordering and merging come into play when a network element receives several invocation requests covering the same data flow. As examples, this could occur if several receivers of a multicast data flow requested QoS services for that flow using the RSVP setup protocol, or if a flow was subject to both a statically installed permanent invocation request and a dynamic request from a resource setup protocol.
ネットワーク要素が同じデータフローをカバーするいくつかの実施の要求を受け取るとき、注文と合併はプレーに入ります。 例として、マルチキャストデータフローの数台の受信機がRSVPセットアッププロトコルを使用することでその流れのためのQoSサービスを要求したか、または流れは静的にインストールされた永久的な実施の要求とリソースセットアッププロトコルからのダイナミックな要求の両方を受けることがあるなら、これは起こることができるでしょうに。
In this situation the service module must be able to answer questions about the ordering between different invocation requests, and must be able to generate a single new invocation request which meets the semantics of the setup protocol and the requirements of all the original requesters. Operationally, this is achieved by having the invoking protocol ask the service module, given a set of invocation requests I1...In, to compute a new request which results in the desired behavior.
この状況で、機械船は、異なった実施の要求の間の注文に関する質問に答えることができなければならなくて、セットアッププロトコルの意味論とすべてのオリジナルのリクエスタに関する必要条件を満たすただ一つの新しい実施の要求を生成することができなければなりません。 I1を実施の要求のセットに考えて、呼び出しプロトコルに機械船を尋ねさせることによって、操作上、これは達成されます…中では、新しい状態でaを計算するために、望まれた行動におけるどの結果を要求してくださいか。
Shenker & Wroclawski Informational [Page 16] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[16ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
Five operations must be defined in this section. These are:
このセクションで5つの操作を定義しなければなりません。 これらは以下の通りです。
- Ordering. The section must define an ordering relationship
between the service's TSpecs and RSpecs. This may be a partial
ordering, in that some TSpecs or RSpecs may be unordered with
respect to each other.
- 注文。 セクションはサービスのTSpecsとRSpecsとの注文関係を定義しなければなりません。 いくつかのTSpecsかRSpecsが互いに関して順不同のであるかもしれないこれは順序であるかもしれません。
- Summation. This function computes an invocation request which
represents the sum of N input invocation requests. Typically this
function is used to compute the size of a service request adequate
for a shared reservation for N different flows. It is desirable but
not required that this function compute the "least possible sum".
- 足し算。 この関数は合計N入力実施の要求を表す実施の要求を計算します。 通常、この機能は、N異なった流れの共有された予約に、適切なサービスのリクエストのサイズを計算するのに使用されます。 望ましいのですが、この関数が「最も可能でない合計」を計算するのは、必要ではありません。
- Minimum. This function computes the minimum of two TSpecs.
Typically this function is used to compute the TSpec for an actual
service invocation given a target TSpec for the service request and
a TSpec for the flow's actual traffic pattern. The minimum function
must compute the smallest TSpec adequate to describe the minimum of
the requested TSpec and the flow's actual traffic.
- 最小。 この関数は2TSpecsの最小限を計算します。 サービスのリクエストのための目標TSpecと流れの実際のトラフィック・パターンのためのTSpecを考えて、通常、この機能は、就航実施のためにTSpecを計算するのに使用されます。 最小の関数は要求されたTSpecと流れの実際のトラフィックの最小限について説明するために適切な最も小さいTSpecを計算しなければなりません。
- RSVP-Merge function. This function computes the invocation
request used to request service at an RSVP [RFC 2205] merge point.
The function must a) compute an appropriate invocation request for
a set of downstream reservations being merged, and b) generate
appropriate reservation parameters to be passed upstream by RSVP.
This function is described further below and in [RFC 2210].
- 機能をRSVP合併してください。 この関数はRSVP[RFC2205]マージポイントでサービスを要求するのに使用される実施の要求を計算します。 合併されている予約の川下の一式を求める適切な実施の要求を計算して、機能は生成しなければなりません。a) RSVPによって上流へ通過されるように、b)は適切な予約パラメタを生成します。 この機能はRFCの下と、そして、[RFC2210]で、より詳しく説明されます。
- Least Common Request function. This function computes an
invocation request sufficient to provide service at least
equivalent to any one of the original requests passed to the
function. This function differs from the RSVP-merge function in
that it simply computes an upper bound. It does not need to compute
new invocation parameters to be passed upstream by RSVP and cannot
utilize the second option discussed in "Notes on RSVP Merging"
below.
- 最少のCommon Requestは機能します。 この関数は機能に合格されたオリジナルの要求のどれかに少なくとも同等な状態でサービスを提供できるくらいの実施の要求を計算します。 この機能は単に上限を計算するという点においてRSVP-マージ機能と異なっています。 それは、RSVPによって上流へ通過されるように新しい実施のパラメタを計算する必要はなくて、以下の「RSVP合併に関する注」で議論した2番目のオプションを利用できません。
oo Notes on Ordering
Orderingの上のoo Notes
Typically the ordering relation will be described separately for the service's TSpec and RSpec. An invocation request is ordered with respect to another if and only if both its TSpec and its RSpec are similarly ordered with respect to each other.
通常、注文関係はサービスのTSpecとRSpecのために別々に説明されるでしょう。 実施の要求が別のものに関して注文される、TSpecとそのRSpecの両方である場合にだけ、同様に注文された互いはそうです。
For TSpecs, the basic ordering relation is well defined. TSpec A is substitutable for TSpec B if and only any flow that is compliant with TSpec B is also compliant with TSpec A. The service specification must explain how to compare two TSpecs to determine whether this is true.
TSpecsに関しては、基本的な注文関係はよく定義されます。 また、どんなだけTSpec Bと共に対応である流れもTSpec A.と共に対応します。そして、TSpec Bに、TSpec Aが代理可能である、サービス仕様で、これが本当であるかどうか決定するために2TSpecsを比較する方法がわからなければなりません。
Shenker & Wroclawski Informational [Page 17] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[17ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
For RSpecs, the ordering relation is dependent on the service. RSpec A is substitutable for RSpec B if the quality of service invoked by RSpec A is at least as good as the quality of service invoked by RSpec B. Since there is no precise mathematical description of "goodness" of quality of service, these ordering relations must be spelled out explicitly in the service description.
RSpecsに関しては、注文関係はサービスに依存しています。 RSpec Bに、RSpec Aによって呼び出されたサービスの質がそこにRSpec B.Sinceによって呼び出されたサービスの質がサービスの質の「善良」の正確な数学の記述でないのと少なくとも同じくらい良いならRSpec Aが代理可能である、サービス記述で明らかに関係を命令するこれらについて詳しく説明しなければなりません。
oo Notes on RSVP Merging
RSVP Mergingの上のoo Notes
The purpose of the RSVP merging function is to compute an invocation request which will provide service to the merged flow at least equivalent to that which any of the original requests would obtain for its corresponding unmerged flow. This equivalence may be obtained in two ways
RSVPが機能を合併する目的はオリジナルの要求のいずれも対応する非合併している流れとして得るそれに少なくとも同等な合併している流れに対するサービスを提供する実施の要求を計算することです。 2つの方法でこの等価性を得るかもしれません。
1) The merged request may be computed as an upper bound on the set
of original (unmerged) invocation requests. In this case, the
service offered by the merged request to any particular traffic
flow is identical to that offered by the largest unmerged request,
by definition.
1) 合併している要求は上限としてオリジナル(非合併される)の実施の要求のセットで計算されるかもしれません。 この場合、合併している要求でどんな特定の交通の流れにも提供されたサービスは定義上最も大きい非合併している要求で提供されたそれと同じです。
2) The merged request may be computed as a value smaller than the
upper bound on the set of original requests, but the results passed
upstream may restrict the traffic sources to behavior which makes
the merged and unmerged requests behave identically.
2) 合併している要求は上限より小さい値としてオリジナルの要求のセットで計算されるかもしれませんが、上流へ通過された結果はトラフィックソースを合併していて非合併している要求が同様に振る舞う振舞いに制限するかもしれません。
Note that the merging rules for a particular service may apply either option 1 or option 2 to the different components of a TSpec, as appropriate. The decision is typically made as follows:
特定のサービスのための合併している規則がオプション1かオプション2のどちらかをTSpecの異なった部品に適用するかもしれないことに注意してください、適宜。 決定を以下の通りに通常します:
When a downstream service module instance can tolerate a flow which
exceeds the parameter, the upper bound should be used. For example,
if the service supports policing to protect itself against excess
traffic, the traffic rate supported by a merged reservation might
be an upper bound across the traffic rates supported by each
unmerged reservation. The effect of this will be to install the
merged reservation at the local node and to inform each traffic
source of the largest traffic rate protected by reservation along
any *one* distribution path from the source to a receiver.
川下の機械船インスタンスがパラメタを超えている流れを許容できるなら、上限は使用されるべきです。 例えば、サービスが余分なトラフィックに対して我が身をかばうために取り締まりをサポートするなら、合併している予約でサポートされたトラフィックレートはそれぞれの非合併している予約でサポートされたトラフィックレートの向こう側の上限であるかもしれません。 この効果は、合併している予約をローカルのノードにインストールして、どんな*1*分配経路に沿っても予約でソースから受信機まで保護される中で最も大きいトラフィックレートについてそれぞれのトラフィックソースに知らせることでしょう。
When a downstream service module instance will not function
properly if the parameter is exceeded, the merged function should
select the least agressive value of the parameter to install and
pass upstream. In this case, the traffic sources will be informed
of a parameter value which is appropriate for *all* distribution
paths traversed by the traffic flow. For example, services which
can handle packets of only limited size can incorporate packet size
in the TSpec, and treat the parmeter as described in option 2. The
パラメタが超えられていると川下の機械船インスタンスが適切に機能しないと、合併している機能は、インストールして、上流へ通るためにパラメタの最少のagressive値を選択するべきです。 この場合、トラフィックソースはすべての*分配経路が交通の流れで横断した*に、適切なパラメタ価値で知識があるようになるでしょう。 例えば、限られたサイズだけのパケットを扱うことができるサービスは、オプション2で説明されるようにパケットサイズをTSpecに取り入れて、parmeterを扱うことができます。 The
Shenker & Wroclawski Informational [Page 18] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[18ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
effect of this will be to limit packet sizes in the flow to those
which can be handled by every instance of the service along the
flow's path.
この効果は流れにおけるパケットサイズを流れの経路に沿ってあらゆるサービスのインスタンスで扱うことができるものに制限することでしょう。
This merging calculation must be performed by the service module because it is specific to a particular service.
それが特定のサービスに特定であるので、機械船でこの合併している計算を実行しなければなりません。
oo Notes on Calculating Upper Bounds
Calculating Upper Boundsの上のoo Notes
Both the RSVP-Merge function and the Least Common Request function may make use of calculated upper bounds on TSpec and RSpec parameters.
RSVP-マージ機能とLeast Common Request機能の両方がTSpecとRSpecパラメタで計算された上限を利用するかもしれません。
The calculated upper bound need not be a least upper bound, nor do the various network elements along the path need to all use the same choice of upper bound. Any selection of invocation parameters Iu is compliant as long as it substitutable for each of the parameters I1...In from which it is calculated. Intuitively, one set of parameters is substitutable for another if the resulting quality of service is at least as desirable to all applications. A precise definition of this "substitutable for" function; the ordering relation, must be specified in the service definition. (It may be specified as the empty set, in which case merging of dissimilar requests will not be allowed). If the ordering function specified in this section gives a partial order (if it is possible for two RSpecs or TSpecs to be unordered), then a separate upper bound computation for the parmeter must be given as well.
計算された上限は上限である必要はありません、そして、経路に沿った様々なネットワーク要素は上限の同じ選択をすべて使用する必要はありません。 実施のパラメタIuのどんな選択もそれと同じくらい長い間、それぞれのパラメタI1に代理可能で対応します…それがどれであるかから計算されるところで。 結果として起こるサービスの品質がすべてのアプリケーションに少なくとも同じくらい望ましいなら、別のものに、1セットのパラメタは直観的に、代理可能です。 この「代理可能」機能の厳密な定義。 注文関係指定されたコネがサービス定義であったに違いないなら。 (それは空集合として指定されるかもしれません、その場合、異なった要求の合併は許されないでしょう。) このセクションで指定された注文機能が部分的なオーダーを与えるなら(2RSpecsかTSpecsが順不同のであることが、可能であるなら)、また、parmeterのための別々の上限計算を与えなければなりません。
oo Notes on Service Substitution
Service Substitutionの上のoo Notes
This portion of the service description may also note any relationships with other services which are strictly ordered with respect to the service being defined. Two services A and B are strictly ordered if it is always possible to substitute service B for the service A given a set of invocation parameters for service A. This ordering information may be used to allow network elements which provide service B to respond to requests for service A, even if the element does not provide service A directly. If the service specification describes such an inter-service ordering, it MUST also include a description of the invocation parameter mapping function for that ordering.
また、サービス記述のこの部分は定義されるサービスに関して厳密に注文される他のサービスとのどんな関係にも注意するかもしれません。 サービスのための1セットの実施のパラメタを考えて、サービスBを提供するネットワーク要素がサービスAを求める要求に反応するのを許容するのにおいてA.This注文情報が使用されているのが、いつもサービスAのための代わりのサービスBに可能であるなら、2つのサービスAとBが厳密に命令されます、要素が直接サービスAを提供しないでも。 また、サービス仕様がそのようなものについて説明するなら、相互サービスが注文される場合、それはその注文のために実施のパラメタマッピング機能の記述を含まなければなりません。
Substitution of of one service for another in cases where they are not strictly ordered is currently not supported. A future version of this document may augment the service specification format to support this capability.
代替、場合における別のもののための1つのサービスでは、それらがどこで厳密に注文されないかは現在、サポートされません。 このドキュメントの将来のバージョンは、この能力をサポートするためにサービス仕様形式を増大させるかもしれません。
Shenker & Wroclawski Informational [Page 19] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[19ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
o Guidelines for Implementors
o 作成者へのガイドライン
Many services may be defined in a manner which allows the range of behavior of a compliant network element to be rather broad. This section should provide some guidance as to what range of behaviors the author of the service specification expects the community to desire in their implementations. Because these guidelines depend on such imprecise and undefinable notions at "typical loads", these guidelines cannot be incorporated as part of a strict compliance test. Instead, they are for informational purposes only.
多くのサービスが対応するネットワーク要素の動きの範囲がかなり広いのを許容する方法で定義されるかもしれません。 サービス仕様の作者が、共同体がそれらの実装でどんな範囲の振舞いを望んでいると予想するかに関してこのセクションは何らかの指導を提供するべきです。 これらのガイドラインが「典型的な負荷」でそのような不正確で定義できない概念によるので、徹底順守テストの一部としてこれらのガイドラインを取り入れることができません。 代わりに、それらは情報の目的だけのためのものです。
o Evaluation Criteria
o 評価基準
Specific functional behaviors required of an implementation for conformance to a service specification is detailed in the previous sections. However, the service specifications are intended to allow a wide range of implementations, and these implementations will differ in performance. This section describes tests that can be used to evaluate a network element's implementation of a given service.
サービス仕様への順応があるので、実装について必要である特定の機能的な振舞いは前にセクションについて詳述しました。 しかしながら、サービス仕様がさまざまな実装を許容することを意図して、これらの実装は性能において異なるでしょう。 このセクションはネットワーク要素の与えられたサービスの実装を評価するのに使用できるテストについて説明します。
Implementors of service modules face a number of tradeoffs, and it is unlikely that a single implementation would be considered "best" under all circumstances. For instance, given the same service specification, an implementation appropriate for a low-speed link might target extremely high link utilization, while a different implementation might attempt to reduce non-loaded packet forwarding delay to the minimum at the expense of somewhat lower utilization of the link. The intention of the tests specified in this section should be to probe the tradeoffs made by the implementation designer, and to provide metrics useful to guide the customer's choice of an appropriate implementation for her needs.
機械船の作成者は多くの見返りに直面しています、そして、ただ一つの実装がすべての状況で「最も良い」と考えられるのは、ありそうもないです。 例えば、同じサービス仕様を考えて、低速リンクに、適切な実装は非常に高いリンク利用を狙うかもしれません、異なった実装が、リンクのいくらか低い利用を犠牲にして非満載のパケット推進遅れを最小限に減少させるのを試みるかもしれませんが。 このセクションで指定されたテストの意志は、実装デザイナーによって作られた見返りを調べて、彼女の必要性のために顧客の適切な実装の選択を誘導するために役に立つ測定基準を提供することであるべきです。
The tests specified in this section should be designed to operate on a single network element in isolation. This enables their use in a comparative rating system for QoS-aware network elements. In production networks, users will be more concerned with the end-to-end behavior obtained, which will depend not just on the particular network elements selected, but also on other factors such as the setup protocol and the bandwidth of the links. Some user-relevant performance factors are the rate of admission control rejections, the range of services offered, and the packet delay and drop rates in the various service classes. The form of any standardized end-to-end metrics and measurement tools for integrated service internetworks is not specified by this document or by service specification document which follow the format given here.
このセクションで指定されたテストは、ただ一つのネットワーク要素を分離して作動させるように設計されるべきです。 これはQoS意識しているネットワーク要素の比較評価体系における彼らの使用を可能にします。 生産ネットワークでは、ユーザは振舞いが入手した終わりから終わりにさらに関係があるでしょう。(それは、要素が選択した特定のネットワークだけではなく、セットアッププロトコルやリンクの帯域幅などの他の要素にも依存するでしょう)。 いくつかのユーザ関連している性能要素が、入場コントロール拒絶の速度と、提供されたサービスの範囲と、パケット遅れであり、様々なサービスのクラスでレートを下げます。 統合サービスインターネットワークのためのどんな標準化された終わりから終わりへの測定基準と測定ツールのフォームもこのドキュメントかサービス仕様ドキュメントによって指定されません(ここに与えられた書式に従います)。
This section is for informational purposes only.
このセクションは情報の目的だけのためのものです。
Shenker & Wroclawski Informational [Page 20] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[20ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
o Examples of Implementation
o 実装に関する例
This section describes example instantiations of the service. Often these will just be references to the literature, or brief sketches of how the service could be implemented. The purposes of the section are to to provide a more concrete sense of the service being specified and to provide pointers and hints to aid the implementor. However, the descriptions in this section are specifically not intended to exclude other implementation strategies.
このセクションはサービスの例の具体化について説明します。 しばしばこれらは、まさしくどうサービスを実装することができたかに関して文学の参照か、簡潔なスケッチになるでしょう。 指定されていて、より具体的なサービスの感覚を提供して、作成者を支援するために指針とヒントを提供するために、セクションの目的があります。 しかしながら、明確に、このセクションの記述が他の実装戦略を除くことを意図しません。
This section is for informational purposes only.
このセクションは情報の目的だけのためのものです。
o Examples of Use
o 使用に関する例
In order to provide more a more concrete sense of how this service might be used, this section describes some example uses of the service, for informational purposes only. The examples here are not meant to be exhaustive, and do not exclude in any way other uses of the service.
このサービスがどう利用されるかもしれないかに関する、より具体的な感覚を以上に提供するために、このセクションはいくつかのサービスの例の用途について説明します、情報の目的だけのために。 ここの例は、徹底的であることは意味されないで、また何らかの方法で他のサービスの用途を除きません。
This section is for informational purposes only.
このセクションは情報の目的だけのためのものです。
Security Considerations
セキュリティ問題
Security considerations are not discussed in this memo.
このメモでセキュリティ問題について議論しません。
References
参照
[PARTRIDGE] C. Partridge, Gigabit Networking, Addison Wesley Publishers (1994).
[ヤマウズラ] C.ヤマウズラ、ギガビットネットワーク、アディソンウエスリー出版社(1994)。
[RFC 2215] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC2215] Shenker、S.、およびJ.Wroclawski、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、1997年9月。
[RFC 2205] Braden, R., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] ブレーデン、R.、エド、etアル、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、9月1997日
[RFC 2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] 1997年9月のShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
[RFC 2211] Wroclawski, J., "Specification of the Controlled Load Quality of Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J.、「制御負荷サービスの質の仕様」、RFC2211、1997年9月。
[RFC 1819] Delgrossi, L., and L. Berger, Editors, "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995.
[RFC1819] Delgrossi、L.、およびL.バーガー、エディターズ、「インターネットストリームプロトコルバージョン2(ST2)は仕様を議定書の中で述べます--バージョンST2+」、RFC1819、1995年8月。
Shenker & Wroclawski Informational [Page 21] RFC 2216 Network Element Service Template September 1997
Shenker&Wroclawskiの情報[21ページ]のRFC2216はテンプレート1997年9月に要素サービスをネットワークでつなぎます。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
Authors' Address:
作者のアドレス:
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 Fax: 617-253-2673 EMail: jtw@lcs.mit.edu
以下に電話をしてください。 617-253-7885 Fax: 617-253-2673 メールしてください: jtw@lcs.mit.edu
Shenker & Wroclawski Informational [Page 22]
Shenker&Wroclawski情報です。[22ページ]
一覧
スポンサーリンク
