[要約] 要約:RFC 3086は、ドメインごとの異なるサービスの定義とその仕様に関するルールを提供しています。 目的:このRFCの目的は、異なるサービスの要件を明確にし、ネットワークの品質を向上させるための指針を提供することです。

Network Working Group                                         K. Nichols
Request for Comments: 3086                                 Packet Design
Category: Informational                                     B. Carpenter
                                                                     IBM
                                                              April 2001
        

Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification

ドメインの動作ごとの差別化されたサービスの定義とその仕様のルール

Status of this Memo

本文書の位置付け

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

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

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

Copyright(c)The Internet Society(2001)。無断転載を禁じます。

Abstract

概要

The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header. The diffserv WG has defined the general architecture for differentiated services and has focused on the forwarding path behavior required in routers, known as "per-hop forwarding behaviors" (or PHBs). The WG has also discussed functionality required at diffserv (DS) domain edges to select (classifiers) and condition (e.g., policing and shaping) traffic according to the rules. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes.

差別化されたサービスフレームワークにより、エッジにルールを適用してトラフィック集合体を作成し、IPヘッダーのCodePointを使用してドメイン内の特定の転送パス処理でこれらのそれぞれを結合することにより、ネットワークドメイン内のサービス品質プロビジョニングを可能にします。Diffserv WGは、差別化されたサービスの一般的なアーキテクチャを定義し、「ホップ前転送行動」(またはPHB)として知られるルーターで必要な転送パスの動作に焦点を当てています。WGは、ルールに従って選択(分類器)と条件(ポリシングや形成など)を選択(分類剤)と条件(ポリシングや形成など)にするために、DiffServ(DS)ドメインエッジで必要な機能についても説明しています。DSドメインのQoS目標の短期的な変更は、必ずしもインテリアネットワークノードの動作を再構成することなく、これらのエッジの動作の構成のみを変更することにより実装されます。

The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, or PDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain. A PDB is characterized by specific metrics that quantify the treatment a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. A PDB specifies a forwarding path treatment for a traffic aggregate and, due to the role that particular choices of edge and PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact. The measurable parameters of a PDB should be suitable for use in Service Level Specifications at the network edge.

次のステップは、転送パスコンポーネント(PHB、分類器、トラフィックコンディショナー)を使用して、差別化されたサービスドメインをトランジットする際に特定の転送特性を経験するトラフィック集合体を構成するために使用する方法の例を策定することです。WGは、ドメインごとの動作という用語(PDB)を使用して、DSドメインを横切る特定のパケットセットが経験する動作を記述することを決定しました。PDBは、特定のDSCP(またはDSCPのセット)を使用したパケットのセットがDSドメインを通過するときに受け取る処理を定量化する特定のメトリックによって特徴付けられます。PDBは、トラフィックの集計の転送パス処理を指定し、結果として生じる属性でエッジとPHB構成の特定の選択が果たす役割により、転送パスとコントロールプレーンが相互作用する場所です。PDBの測定可能なパラメーターは、ネットワークエッジでのサービスレベルの仕様での使用に適している必要があります。

This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions.

このドキュメントでは、ドメインごとの動作を詳細に定義および説明し、PDB上のdiffserv WGへの貢献と、個々のPDB仕様に適用してWG製品として進行する手順に貢献するためにコンテンツと必要なコンテンツをレイアウトします。この形式は、PDB提出のワーキンググループレビューを促進するために指定されています。

Table of Contents

目次

    1. Introduction ................................................ 2
    2. Definitions ................................................. 4
    3. The Value of Defining Edge-to-Edge Behavior ................. 5
    4. Understanding PDBs .......................................... 7
    5. Format for Specification of Diffserv Per-Domain Behaviors ...13
    6. On PDB Attributes ...........................................16
    7. A Reference Per-Domain Behavior .............................19
    8. Guidelines for Advancing PDB Specifications .................21
    9. Security Considerations .....................................22
   10. Acknowledgements ............................................22
       References ..................................................22
       Authors' Addresses ..........................................23
       Full Copyright Statement ....................................24
        

1 Introduction

1はじめに

Differentiated Services allows an approach to IP Quality of Service that is modular, incrementally deployable, and scalable while introducing minimal per-node complexity [RFC2475]. From the end user's point of view, QoS should be supported end-to-end between any pair of hosts. However, this goal is not immediately attainable. It will require interdomain QoS support, and many untaken steps remain on the road to achieving this. One essential step, the evolution of the business models for interdomain QoS, will necessarily develop outside of the IETF. A goal of the diffserv WG is to provide the firm technical foundation that allows these business models to develop. The first major step will be to support edge-to-edge or intradomain QoS between the ingress and egress of a single network, i.e., a DS Domain in the terminology of RFC 2474. The intention is that this edge-to-edge QoS should be composable, in a purely technical sense, to a quantifiable QoS across a DS Region composed of multiple DS domains.

差別化されたサービスにより、モジュール式、漸進的に展開可能で、スケーラブルなIPサービスの品質へのアプローチが可能になり、最小のノードあたりの複雑さを導入します[RFC2475]。エンドユーザーの観点から、Qosは、ホストのペア間でエンドツーエンドをサポートする必要があります。ただし、この目標はすぐに達成できません。ドメイン間のQoSサポートが必要になり、これを達成するための多くの未脱色のステップが残っています。1つの重要なステップである、ドメイン間QoSのビジネスモデルの進化は、必然的にIETFの外側に発生します。DiffServ WGの目標は、これらのビジネスモデルが開発できるようにする確固たる技術基盤を提供することです。最初の主要なステップは、単一のネットワークの侵入と出口、つまりRFC 2474の用語のDSドメインの間のエッジツーエッジまたはドメイン内のQOをサポートすることです。意図は、このエッジツーエッジQosが必要であることです。純粋に技術的な意味で、複数のDSドメインで構成されるDS領域にわたって定量化可能なQoSに合成可能になります。

The Diffserv WG has finished the first phase of standardizing the behaviors required in the forwarding path of all network nodes, the per-hop forwarding behaviors or PHBs. The PHBs defined in RFCs 2474, 2597 and 2598 give a rich toolbox for differential packet handling by individual boxes. The general architectural model for diffserv has been documented in RFC 2475. An informal router model [MODEL] describes a model of traffic conditioning and other forwarding behaviors. However, technical issues remain in moving "beyond the box" to intradomain QoS models.

DIFFSERV WGは、すべてのネットワークノードの転送パス、ホップごとの転送動作またはPHBの転送パスで必要な動作を標準化する最初のフェーズを終了しました。RFCS 2474、2597、および2598で定義されているPHBは、個々のボックスによる差動パケット処理用のリッチツールボックスを提供します。Diffservの一般的な建築モデルは、RFC 2475に文書化されています。非公式のルーターモデル[モデル]は、トラフィックコンディショニングおよびその他の転送行動のモデルを説明しています。ただし、技術的な問題は、「ボックスを超えて」QOSモデルに移行することに残っています。

The ultimate goal of creating scalable end-to-end QoS in the Internet requires that we can identify and quantify behavior for a group of packets that is preserved when they are aggregated with other packets as they traverse the Internet. The step of specifying forwarding path attributes on a per-domain basis for a set of packets distinguished only by the mark in the DS field of individual packets is critical in the evolution of Diffserv QoS and should provide the technical input that will aid in the construction of business models. This document defines and specifies the term "Per-Domain Behavior" or PDB to describe QoS attributes across a DS domain.

インターネットでスケーラブルなエンドツーエンドQOSを作成するという究極の目標には、インターネットを通過するときに他のパケットと集約されたときに保存されるパケットのグループの動作を特定して定量化できることが必要です。個々のパケットのDSフィールドのマークによってのみ区別される一連のパケットのパスごとに転送パス属性を指定するステップは、diffserv Qosの進化に重要であり、建設を支援する技術的な入力を提供するはずですビジネスモデルの。このドキュメントは、DSドメイン全体のQoS属性を記述する「ドメインごとの動作」またはPDBという用語を定義および指定します。

Diffserv classification and traffic conditioning are applied to packets arriving at the boundary of a DS domain to impose restrictions on the composition of the resultant traffic aggregates, as distinguished by the DSCP marking , inside the domain. The classifiers and traffic conditioners are set to reflect the policy and traffic goals for that domain and may be specified in a TCA (Traffic Conditioning Agreement). Once packets have crossed the DS boundary, adherence to diffserv principles makes it possible to group packets solely according to the behavior they receive at each hop (as selected by the DSCP). This approach has well-known scaling advantages, both in the forwarding path and in the control plane. Less well recognized is that these scaling properties only result if the per-hop behavior definition gives rise to a particular type of invariance under aggregation. Since the per-hop behavior must be equivalent for every node in the domain, while the set of packets marked for that PHB may be different at every node, PHBs should be defined such that their characteristics do not depend on the traffic volume of the associated BA on a router's ingress link nor on a particular path through the DS domain taken by the packets. Specifically, different streams of traffic that belong to the same traffic aggregate merge and split as they traverse the network. If the properties of a PDB using a particular PHB hold regardless of how the temporal characteristics of the marked traffic aggregate change as it traverses the domain, then that PDB scales. (Clearly this assumes that numerical parameters such as bandwidth allocated to the particular PDB may be different at different points in the network, and may be adjusted dynamically as traffic volume varies.) If there are limits to where the properties hold, that translates to a limit on the size or topology of a DS domain that can use that PDB. Although useful single-link DS domains might exist, PDBs that are invariant with network size or that have simple relationships with network size and whose properties can be recovered by reapplying rules (that is, forming another diffserv boundary or edge to re-enforce the rules for the traffic aggregate) are needed for building scalable end-to-end quality of service.

DSSVの分類とトラフィックコンディショニングは、DSドメインの境界に到達するパケットに適用され、ドメイン内のDSCPマークによって区別されるように、結果のトラフィック集合体の構成に制限を課します。分類器とトラフィックコンディショナーは、そのドメインのポリシーとトラフィックの目標を反映するように設定されており、TCA(トラフィックコンディショニング契約)で指定される場合があります。パケットがDS境界を通過すると、DiffServの原則を順守することで、各ホップで受け取る動作(DSCPで選択された)だけに従ってパケットをグループ化できます。このアプローチには、転送パスと制御面の両方で、よく知られているスケーリングの利点があります。あまり認識されていないのは、これらのスケーリングプロパティが、ホップごとの動作定義が集約下で特定のタイプの不変性を生じた場合にのみ生じることです。ホップごとの動作はドメイン内のすべてのノードに相当する必要がありますが、そのPHBにマークされたパケットのセットはすべてのノードで異なる場合があるため、PHBは、その特性が関連する関連するトラフィックボリュームに依存しないように定義する必要があります。ルーターのイングレスリンクのBAも、パケットで取得したDSドメインを通る特定のパスでも。具体的には、同じトラフィックに属するトラフィックのさまざまなストリームが、ネットワークを横断するときにマージして分割されます。特定のPHBを使用してPDBの特性が、マークされたトラフィックの時間的特性がドメインを横断する際にどのように変化するかに関係なく保持されている場合、そのPDBはスケーリングします。(明らかに、これは、特定のPDBに割り当てられた帯域幅などの数値パラメーターがネットワーク内の異なるポイントで異なる場合があり、トラフィック量が異なるため、動的に調整される可能性があることを前提としています。)プロパティが保持する場所に制限がある場合、それはそのPDBを使用できるDSドメインのサイズまたはトポロジーを制限します。有用なシングルリンクDSドメインが存在する可能性がありますが、ネットワークサイズに不変であるか、ネットワークサイズと単純な関係を持ち、そのプロパティを再適用することで回復できるPDB(つまり、ルールを再強化するために別のdiffserv境界またはエッジを形成することができます。トラフィックアグリゲートの場合)は、スケーラブルなエンドツーエンドサービス品質を構築するために必要です。

There is a clear distinction between the definition of a Per-Domain Behavior in a DS domain and a service that might be specified in a Service Level Agreement. The PDB definition is a technical building block that permits the coupling of classifiers, traffic conditioners, specific PHBs, and particular configurations with a resulting set of specific observable attributes which may be characterized in a variety of ways. These definitions are intended to be useful tools in configuring DS domains, but the PDB (or PDBs) used by a provider is not expected to be visible to customers any more than the specific PHBs employed in the provider's network would be. Network providers are expected to select their own measures to make customer-visible in contracts and these may be stated quite differently from the technical attributes specified in a PDB definition, though the configuration of a PDB might be taken from a Service Level Specification (SLS). Similarly, specific PDBs are intended as tools for ISPs to construct differentiated services offerings; each may choose different sets of tools, or even develop their own, in order to achieve particular externally observable metrics. Nevertheless, the measurable parameters of a PDB are expected to be among the parameters cited directly or indirectly in the Service Level Specification component of a corresponding SLA.

DSドメインのドメインごとの動作の定義と、サービスレベル契約で指定される可能性のあるサービスとの間には明確な区別があります。PDB定義は、分類器、トラフィックコンディショナー、特定のPHB、および特定の観察可能な属性のセットをさまざまな方法で特徴付ける可能性のある特定の構成の結合を可能にする技術的な構成要素です。これらの定義は、DSドメインの構成に役立つツールになることを目的としていますが、プロバイダーが使用するPDB(またはPDB)は、プロバイダーのネットワークで採用されている特定のPHB以上のものを顧客に表示することは期待されていません。ネットワークプロバイダーは、契約で顧客に魅了されるようにする独自の手段を選択することが期待されています。これらは、PDB定義で指定された技術的属性とはまったく異なると述べられる場合がありますが、PDBの構成はサービスレベルの仕様(SLS)から取得される場合があります。。同様に、特定のPDBは、ISPが差別化されたサービス提供を構築するためのツールとして意図されています。それぞれが異なるツールセットを選択するか、特定の外部的に観察可能なメトリックを実現するために、独自のツールを開発することさえできます。それにもかかわらず、PDBの測定可能なパラメーターは、対応するSLAのサービスレベル仕様コンポーネントで直接または間接的に引用されるパラメーターの1つになると予想されます。

This document defines Differentiated Services Per-Domain Behaviors and specifies the format that must be used for submissions of particular PDBs to the Diffserv WG.

このドキュメントは、ドメインごとの差別化されたサービスを定義し、特定のPDBのDiffServ WGへの提出に使用する必要がある形式を指定します。

2 Definitions

2つの定義

The following definitions are stated in RFCs 2474 and 2475 and are repeated here for easy reference:

次の定義はRFCS 2474および2475に記載されており、簡単に参照するためにここで繰り返されます。

" Behavior Aggregate: a collection of packets with the same codepoint crossing a link in a particular direction.

「動作の集合体:同じコードポイントが特定の方向にリンクを横切るパケットのコレクション。

" Differentiated Services Domain: a contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. A differentiated services domain can represent different administrative domains or autonomous systems, different trust regions, different network technologies (e.g., cell/frame), hosts and routers, etc. Also DS domain.

「差別化されたサービスドメイン:差別化されたサービスポリシーの一貫したセットが調整された方法で管理されるインターネットの連続部分。差別化されたサービスドメインは、異なる管理ドメインまたは自律システム、異なる信頼領域、異なるネットワークテクノロジーを表すことができます(例:セル/フレーム)、ホストおよびルーターなど。DSドメインも。

" Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction. A differentiated services boundary typically is found at the ingress to the first-hop differentiated services-compliant router (or network node) that a host's packets traverse, or at the egress of the last-hop differentiated services-compliant router or network node that packets traverse before arriving at a host. This is sometimes referred to as the boundary at a leaf router. A differentiated services boundary may be co-located with a host, subject to local policy. Also DS boundary.

「差別化されたサービスの境界:分類器とトラフィックコンディショナーが展開される可能性が高いDSドメインのエッジ。差別化されたサービス境界は、イングレスノードと出口ノードにさらに下位になります。特定のトラフィック方向の境界リンクのノード。通常、差別化されたサービス境界は、ホストのパケットがトラバースを移動する最初の差別化されたサービスに準拠したルーター(またはネットワークノード)の侵入時に、または最後の出口に見られます。ホップ差別化されたサービスに準拠したルーターまたはネットワークノードは、ホストに到着する前にパケットを横断することができます。これは、リーフルーターの境界と呼ばれることもあります。差別化されたサービス境界は、ローカルポリシーの対象となるホストと共同住宅されている場合があります。DS境界。

To these we add:

これらに追加します:

" Traffic Aggregate: a collection of packets with a codepoint that maps to the same PHB, usually in a DS domain or some subset of a DS domain. A traffic aggregate marked for the foo PHB is referred to as the "foo traffic aggregate" or "foo aggregate" interchangeably. This generalizes the concept of Behavior Aggregate from a link to a network.

「トラフィックアグリゲート:同じPHBにマッピングするコードポイントを備えたパケットのコレクション、通常はDSドメインまたはDSドメインのサブセット。「foo gregate」は互換性があります。これは、ネットワークへのリンクからの動作の概念を一般的に一般化します。

" Per-Domain Behavior: the expected treatment that an identifiable or target group of packets will receive from "edge-to-edge" of a DS domain. (Also PDB.) A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB.

「ドメインごとの動作:識別可能またはターゲットグループがDSドメインの「エッジとエッジ」から受け取る予想治療(PDB。)特定のPHB(または、該当する場合、PHBのリスト))トラフィックコンディショニングの要件は、各PDBに関連付けられています。

" A Service Level Specification (SLS) is a set of parameters and their values which together define the service offered to a traffic stream by a DS domain. It is expected to include specific values or bounds for PDB parameters.

「サービスレベルの仕様(SLS)は、DSドメインによってトラフィックストリームに提供されるサービスを一緒に定義する一連のパラメーターとその値です。PDBパラメーターの特定の値または境界を含めることが期待されます。

3 The Value of Defining Edge-to-Edge Behavior

3エッジとエッジの動作を定義する値

As defined in section 2, a PDB describes the edge-to-edge behavior across a DS domain's "cloud." Specification of the transit expectations of packets matching a target for a particular diffserv behavior across a DS domain will both assist in the deployment of single-domain QoS and will help enable the composition of end-to-end, cross-domain services. Networks of DS domains can be connected to create end-to-end services by building on the PDB characteristics without regard to the particular PHBs used. This level of abstraction makes it easier to compose cross-domain services as well as making it possible to hide details of a network's internals while exposing information sufficient to enable QoS.

セクション2で定義されているように、PDBは、DSドメインの「クラウド」にわたるエッジツーエッジの動作について説明しています。DSドメイン全体の特定のDiffServの動作のターゲットと一致するパケットの通過期待の仕様は、単一ドメインQoSの展開を支援し、エンドツーエンドのクロスドメインサービスの構成を可能にするのに役立ちます。DSドメインのネットワークを接続して、使用する特定のPHBに関係なくPDB特性を構築することにより、エンドツーエンドサービスを作成できます。このレベルの抽象化により、クロスドメインサービスを構成しやすくなり、QoSを有効にするのに十分な情報を公開しながら、ネットワークの内部の詳細を隠すことができます。

Today's Internet is composed of multiple independently administered domains or Autonomous Systems (ASs), represented by the "clouds" in figure 1. To deploy ubiquitous end-to-end quality of service in the Internet, business models must evolve that include issues of charging and reporting that are not in scope for the IETF. In the meantime, there are many possible uses of quality of service within an AS and the IETF can address the technical issues in creating an intradomain QoS within a Differentiated Services framework. In fact, this approach is quite amenable to incremental deployment strategies.

今日のインターネットは、図1の「クラウド」で表される複数の独立したドメインまたは自律システム(ASS)で構成されています。IETFの範囲内ではない報告。それまでの間、ASには多くの可能なサービスの使用が可能であり、IETFは差別化されたサービスフレームワーク内でイントマンQoSを作成する際の技術的な問題に対処できます。実際、このアプローチは、増分展開戦略に非常に適しています。

Where DS domains are independently administered, the evolution of the necessary business agreements and future signaling arrangements will take some time, thus, early deployments will be within a single administrative domain. Putting aside the business issues, the same technical issues that arise in interconnecting DS domains with homogeneous administration will arise in interconnecting the autonomous systems (ASs) of the Internet.

DSドメインが独立して管理されている場合、必要なビジネス契約と将来のシグナリングの取り決めの進化には時間がかかります。したがって、早期展開は単一の管理ドメイン内にあります。ビジネスの問題を除けば、DSドメインを相互接続する際に均一な投与で発生するのと同じ技術的な問題は、インターネットの自律システム(ASS)を相互接続する際に発生します。

                 ----------------------------------------
                 |                AS2                   |
                 |                                      |
    -------      |     ------------     ------------    |
    | AS1 |------|-----X           |    |          |    |
    -------      |     |           |    Y          |    |        -------
                 |     |           |   /|          X----|--------| AS3 |
                 |     |           |  / |          |    |        -------
                 |     |           | /  ------------    |
                 |     |           Y      |             |
                 |     |           | \  ------------    |
    -------      |     |           |  \ |          |    |
    | AS4 |------|-----X           |   \|          |    |
    -------      |     |           |    Y          X----|------
                 |     |           |    |          |    |
                 |     ------------     ------------    |
                 |                                      |
                 |                                      |
                 ----------------------------------------
        

Figure 1: Interconnection of ASs and DS Domains

図1:ASSおよびDSドメインの相互接続

A single AS (e.g., AS2 in figure 1) may be composed of subnetworks and, as the definition allows, these can be separate DS domains. An AS might have multiple DS domains for a number of reasons, most notable being to follow topological and/or technological boundaries and to separate the allocation of resources. If we confine ourselves to the DS boundaries between these "interior" DS domains, we avoid the non-technical problems of setting up a service and can address the issues of creating characterizable PDBs.

単一のAS(例:図1のAS2)は、サブネットワークで構成されている場合があり、定義で許可されているように、これらはDSドメインを個別にすることができます。ASは、いくつかの理由で複数のDSドメインを持っている可能性があります。最も注目すべきは、トポロジーおよび/または技術の境界に従い、リソースの割り当てを分離することです。これらの「インテリア」DSドメイン間のDS境界に限定すると、サービスのセットアップの非技術的な問題を回避し、特徴づけられるPDBを作成する問題に対処できます。

The incentive structure for differentiated services is based on upstream domains ensuring their traffic conforms to the Traffic Conditioning Agreements (TCAs) with downstream domains and downstream domains enforcing that TCA, thus metrics associated with PDBs can be sensibly computed. The letters "X" and "Y" in figure 1 represent the DS boundary routers containing traffic conditioners that ensure and enforce conformance (e.g., shapers and policers). Although policers and shapers are expected at the DS boundaries of ASs (the "X" boxes), they might appear anywhere, or nowhere, inside the AS. Specifically, the boxes at the DS boundaries internal to the AS (the "Y" boxes) may or may not condition traffic. Technical guidelines for the placement and configuration of DS boundaries should derive from the attributes of a particular PDB under aggregation and multiple hops.

差別化されたサービスのインセンティブ構造は、上流のドメインに基づいており、トラフィックがTCAを強制するトラフィックコンディショニング契約(TCA)に準拠していることを保証します。図1の「x」と「y」の文字は、適合性(シェイパーやポリサーなど)を確保および実施するトラフィックコンディショナーを含むDS境界ルーターを表しています。ポリサーとシェイパーは、ASのDS境界(「X」ボックス)で予想されますが、AS内にどこにもどこにも表示されない場合があります。具体的には、as( "y"ボックス)の内部のDS境界のボックスは、トラフィックを条件付ける場合と条件付けられない場合があります。DS境界の配置と構成に関する技術的ガイドラインは、集約および複数のホップの下での特定のPDBの属性から派生する必要があります。

This definition of PDB continues the separation of forwarding path and control plane described in RFC 2474. The forwarding path characteristics are addressed by considering how the behavior at every hop of a packet's path is affected by the merging and branching of traffic aggregates through multiple hops. Per-hop behaviors in nodes are configured infrequently, representing a change in network infrastructure. More frequent quality-of-service changes come from employing control plane functions in the configuration of the DS boundaries. A PDB provides a link between the DS domain level at which control is exercised to form traffic aggregates with quality-of-service goals across the domain and the per-hop and per-link treatments packets receive that results in meeting the quality-of-service goals.

このPDBの定義は、RFC 2474に記載されている転送パスと制御プレーンの分離を継続します。転送パスの特性は、パケットのパスのすべてのホップでの動作が複数のホップを介した交通集合体の融合と分岐によってどのように影響を受けるかを考慮することで対処されます。ノード内のホップごとの動作は、ネットワークインフラストラクチャの変化を表すことなく、まれに構成されています。より頻繁なサービス品質の変更は、DS境界の構成にコントロールプレーン機能を使用することから生じます。PDBは、ドメイン全体のサービス品質目標を持つトラフィック集合体を形成するために制御が行使されるDSドメインレベルの間のリンクを提供し、ホップごとのトリートメントとリンクごとのトリートメントが受け取った結果、その結果が得られます。サービス目標。

4 Understanding PDBs

4 PDBの理解

4.1 Defining PDBs
4.1 PDBの定義

RFCs 2474 and 2475 define a Differentiated Services Behavior Aggregate as "a collection of packets with the same DS codepoint crossing a link in a particular direction" and further state that packets with the same DSCP get the same per-hop forwarding treatment (or PHB) everywhere inside a single DS domain. Note that even if multiple DSCPs map to the same PHB, this must hold for each DSCP individually. In section 2 of this document, we introduced a more general definition of a traffic aggregate in the diffserv sense so that we might easily refer to the packets which are mapped to the same PHB everywhere within a DS domain. Section 2 also presented a short definition of PDBs which we expand upon in this section: Per-Domain Behavior: the expected treatment that an identifiable or target group of packets will receive from "edge to edge" of a DS domain. A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB.

RFCS 2474および2475は、差別化されたサービス動作の集約を「特定の方向にリンクを交差する同じDSコードポイントを備えたパケットのコレクション」として定義し、同じDSCPを持つパケットが同じパーホップ転送処理(またはPHB)を取得することをさらに述べています。単一のDSドメイン内のどこにでも。複数のDSCPが同じPHBにマッピングされたとしても、これは各DSCPに対して個別に保持する必要があることに注意してください。このドキュメントのセクション2では、DSドメイン内のどこにでも同じPHBにマッピングされたパケットを簡単に参照できるように、DiffServの意味でトラフィックの集計のより一般的な定義を導入しました。セクション2では、このセクションで拡張するPDBの短い定義も提示しました。ドメインごとの動作:識別可能またはターゲットのパケットグループがDSドメインの「エッジへ」から受け取る予想治療。特定のPHB(または、該当する場合はPHBのリスト)とトラフィックコンディショニング要件は、各PDBに関連付けられています。

Each PDB has measurable, quantifiable, attributes that can be used to describe what happens to its packets as they enter and cross the DS domain. These derive from the characteristics of the traffic aggregate that results from application of classification and traffic conditioning during the entry of packets into the DS domain and the forwarding treatment (PHB) the packets get inside the domain, but can also depend on the entering traffic loads and the domain's topology. PDB attributes may be absolute or statistical and they may be parameterized by network properties. For example, a loss attribute might be expressed as "no more than 0.1% of packets will be dropped when measured over any time period larger than T", a delay attribute might be expressed as "50% of delivered packets will see less than a delay of d milliseconds, 30% will see a delay less than 2d ms, 20% will see a delay of less than 3d ms." A wide range of metrics is possible. In general they will be expressed as bounds or percentiles rather than as absolute values.

各PDBには、DSドメインを入力して交差するときにパケットが何が起こるかを説明するために使用できる測定可能で定量化可能な属性があります。これらは、DSドメインと転送処理(PHB)へのパケットの入力中の分類とトラフィックコンディショニングの適用に起因するトラフィック集約の特性に由来します。ドメインのトポロジー。PDB属性は絶対的または統計的である可能性があり、ネットワークプロパティによってパラメーター化される場合があります。たとえば、損失属性は、「tよりも大きい期間にわたって測定されるとパケットの0.1%を超えない」と表現することができます。dミリ秒の遅延、30%は2D ms未満の遅延が見られ、20%は3D ms未満の遅延が見られます。」幅広いメトリックが可能です。一般に、それらは絶対値としてではなく、境界またはパーセンタイルとして表現されます。

A PDB is applied to a target group of packets arriving at the edge of the DS domain. The target group is distinguished from all arriving packets by use of packet classifiers [RFC2475] (where the classifier may be "null"). The action of the PDB on the target group has two parts. The first part is the the use of traffic conditioning to create a traffic aggregate. During traffic conditioning, conformant packets are marked with a DSCP for the PHB associated with the PDB (see figure 2). The second part is the treatment experienced by packets from the same traffic aggregate transiting the interior of a DS domain, between and inside of DS domain boundaries. The following subsections further discuss these two effects on the target group that arrives at the DS domain boundary.

PDBは、DSドメインの端に到着するパケットのターゲットグループに適用されます。ターゲットグループは、パケット分類器[RFC2475](分類器が「ヌル」である可能性がある)を使用して、到着するすべてのパケットと区別されます。ターゲットグループに対するPDBの作用には2つの部分があります。最初の部分は、トラフィックコンディショニングを使用してトラフィックの集計を作成することです。トラフィックコンディショニング中、コンフォーマントパケットには、PDBに関連付けられたPHBのDSCPがマークされています(図2を参照)。2番目の部分は、DSドメインの内部をDSドメイン境界内と内部の内部を通過する同じトラフィック集合体からのパケットによって経験される治療です。次のサブセクションでは、DSドメイン境界に到達するターゲットグループに対するこれら2つの効果についてさらに説明します。

           -----------   ------------   --------------------   foo
arriving _|classifiers|_|target group|_|traffic conditioning|_ traffic
packets   |           | |of packets  | |& marking (for foo) |  aggregate
           -----------   ------------   --------------------
        

Figure 2: Relationship of the traffic aggregate associated with a PDB to arriving packets

図2:PDBに関連するトラフィック集合体の到着パケットへの関係

4.1.1 Crossing the DS edge: the effects of traffic conditioning on the target group
4.1.1 DSエッジの交差:ターゲットグループに対するトラフィックコンディショニングの影響

This effect is quantified by the relationship of the emerging traffic aggregate to the entering target group. That relationship can depend on the arriving traffic pattern as well as the configuration of the traffic conditioners. For example, if the EF PHB [RFC2598] and a strict policer of rate R are associated with the foo PDB, then the first part of characterizing the foo PDB is to write the relationship between the arriving target packets and the departing foo traffic aggregate. In this case, "the rate of the emerging foo traffic aggregate is less than or equal to the smaller of R and the arrival rate of the target group of packets" and additional temporal characteristics of the packets (e.g., burst) may be specified as desired. Thus, there is a "loss rate" on the arriving target group that results from sending too much traffic or the traffic with the wrong temporal characteristics. This loss rate should be entirely preventable (or controllable) by the upstream sender conforming to the traffic conditioning associated with the PDB specification.

この効果は、新興トラフィックの集計と入力ターゲットグループとの関係によって定量化されます。その関係は、到着するトラフィックパターンとトラフィックコンディショナーの構成に依存する可能性があります。たとえば、EF PHB [RFC2598]とレートRの厳格なポリサーがFOO PDBに関連付けられている場合、FOO PDBの特徴づけの最初の部分は、到着するターゲットパケットと出発するFOOトラフィック集合体との関係を記述することです。この場合、「新興のFooトラフィックの総計の速度はRの小さいか等しいか等しく、パケットのターゲットグループの到着速度」とパケットの追加の時間的特性(例えば、バースト)を指定することができます。望ましい。したがって、到着するターゲットグループには、トラフィックやトラフィックが間違っていることから生じる「損失率」があります。この損失率は、PDB仕様に関連するトラフィックコンディショニングに準拠する上流の送信者によって完全に予防可能(または制御可能)する必要があります。

The issue of "who is in control" of the loss (or demotion) rate helps to clearly delineate this component of PDB performance from that associated with transiting the domain. The latter is completely under control of the operator of the DS domain and the former is used to ensure that the entering traffic aggregate conforms to the traffic profile to which the operator has provisioned the network. Further, the effects of traffic conditioning on the target group can usually be expressed more simply than the effects of transiting the DS domain on the traffic aggregate's traffic profile.

損失(または降格)率の「誰が制御しているか」の問題は、ドメインの通過に関連するものからPDBパフォーマンスのこのコンポーネントを明確に描写するのに役立ちます。後者はDSドメインのオペレーターを完全に制御しており、前者は、入力するトラフィックの集計が、オペレーターがネットワークをプロビジョニングしているトラフィックプロファイルに適合するように使用されます。さらに、ターゲットグループに対するトラフィックコンディショニングの効果は、通常、トラフィック集合体のトラフィックプロファイルに対するDSドメインを通過する効果よりも単純に表現できます。

A PDB may also apply traffic conditioning at DS domain egress. The effect of this conditioning on the overall PDB attributes would be treated similarly to the ingress characteristics (the authors may develop more text on this in the future, but it does not materially affect the ideas presented in this document.)

PDBは、DSドメイン出口でトラフィックコンディショニングを適用する場合があります。全体的なPDB属性に対するこの条件付けの効果は、侵入特性と同様に扱われます(著者は将来これについてより多くのテキストを開発することができますが、この文書に示されているアイデアに実質的に影響しません)。

4.1.2 Crossing the DS domain: transit effects
4.1.2 DSドメインの交差:トランジット効果

The second component of PDB performance is the metrics that characterize the transit of a packet of the PDB's traffic aggregate between any two edges of the DS domain boundary shown in figure 3. Note that the DS domain boundary runs through the DS boundary routers since the traffic aggregate is generally formed in the boundary router before the packets are queued and scheduled for output. (In most cases, this distinction is expected to be important.) DSCPs should not change in the interior of a DS domain as there is no traffic conditioning being applied. If it is necessary to reapply the kind of traffic conditioning that could result in remarking, there should be a DS domain boundary at that point, though such an "interior" boundary can have "lighter weight" rules in its TCA. Thus, when measuring attributes between locations as indicated in figure 3, the DSCP at the egress side can be assumed to have held throughout the domain.

PDBパフォーマンスの2番目のコンポーネントは、図3に示すDSドメイン境界の任意の2つのエッジ間のPDBのトラフィックのパケットのパケットのトランジットを特徴付けるメトリックです。集計は、一般に、パケットがキューに出され、出力がスケジュールされる前に境界ルーターに形成されます。(ほとんどの場合、この区別は重要であると予想されます。)DSCPは、トラフィックコンディショニングが適用されないため、DSドメインの内部に変更されないはずです。発言につながる可能性のあるトラフィックコンディショニングの種類を再適用する必要がある場合は、その時点でDSドメインの境界があるはずですが、そのような「内部」境界はTCAに「軽量」ルールを持つことができます。したがって、図3に示すように、場所間で属性を測定する場合、出口側のDSCPはドメイン全体に保持されていると想定できます。

                               -------------
                               |           |
                          -----X           |
                               |           |
                               |   DS      |
                               |   domain  X----
                               |           |
                          -----X           |
                               |           |
                               -------------
        

Figure 3: Range of applicability of attributes of a traffic aggregate associated with a PDB (is between the points marked "X")

図3:PDBに関連付けられたトラフィック集合体の属性の適用可能性の範囲(「x」とマークされたポイント間の間)

Though a DS domain may be as small as a single node, more complex topologies are expected to be the norm, thus the PDB definition must hold as its traffic aggregate is split and merged on the interior links of a DS domain. Packet flow in a network is not part of the PDB definition; the application of traffic conditioning as packets enter the DS domain and the consistent PHB through the DS domain must suffice. A PDB's definition does not have to hold for arbitrary topologies of networks, but the limits on the range of applicability for a specific PDB must be clearly specified.

DSドメインは単一のノードと同じくらい小さい場合がありますが、より複雑なトポロジが標準になると予想されるため、トラフィックの集合体が分割され、DSドメインの内部リンクにマージされるため、PDB定義が保持されなければなりません。ネットワーク内のパケットフローは、PDB定義の一部ではありません。パケットとしてのトラフィックコンディショニングの適用では、DSドメインに入り、DSドメインを介して一貫したPHBで十分です。PDBの定義は、ネットワークの任意のトポロジを保持する必要はありませんが、特定のPDBの適用性の範囲の制限を明確に指定する必要があります。

In general, a PDB operates between N ingress points and M egress points at the DS domain boundary. Even in the degenerate case where N=M=1, PDB attributes are more complex than the definition of PHB attributes since the concatenation of the behavior of intermediate nodes affects the former. A complex case with N and M both greater than one involves splits and merges in the traffic path and is non-trivial to analyze. Analytic, simulation, and experimental work will all be necessary to understand even the simplest PDBs.

一般に、PDBはn侵入点とDSドメイン境界での出口点の間を動作します。n = m = 1の退化した場合でさえ、中間ノードの挙動の連結が前者に影響するため、PDB属性はPHB属性の定義よりも複雑です。nとmの両方を1つ以上の複雑なケースには、交通経路に分割とマージを伴い、分析するのは重要ではありません。分析、シミュレーション、および実験作業はすべて、最も単純なPDBを理解するために必要です。

4.2 Constructing PDBs
4.2 PDBの構築

A DS domain is configured to meet the network operator's traffic engineering goals for the domain independently of the performance goals for a particular flow of a traffic aggregate. Once the interior routers are configured for the number of distinct traffic aggregates that the network will handle, each PDB's allocation at the edge comes from meeting the desired performance goals for the PDB's traffic aggregate subject to that configuration of packet schedulers and bandwidth capacity. The configuration of traffic conditioners at the edge may be altered by provisioning or admission control but the decision about which PDB to use and how to apply classification and traffic conditioning comes from matching performance to goals.

DSドメインは、トラフィックの特定のフローのパフォーマンス目標とは無関係に、ドメインのネットワークオペレーターのトラフィックエンジニアリング目標を満たすように構成されています。ネットワークが処理する個別のトラフィック集合体の数に対して内部ルーターが構成されると、エッジでの各PDBの割り当ては、パケットスケジューラーと帯域幅容量の構成に従って、PDBのトラフィック集合体の目的のパフォーマンス目標を満たすことから生じます。エッジでのトラフィックコンディショナーの構成は、プロビジョニングまたは入学制御によって変更される場合がありますが、どのPDBを使用するか、分類とトラフィックコンディショニングを適用する方法についての決定は、パフォーマンスのマッチングから得られます。

For example, consider the DS domain of figure 3. A PDB with an explicit bound on loss must apply traffic conditioning at the boundary to ensure that on the average no more packets are admitted than can emerge. Though, queueing internal to the network may result in a difference between input and output traffic over some timescales, the averaging timescale should not exceed what might be expected for reasonably sized buffering inside the network. Thus if bursts are allowed to arrive into the interior of the network, there must be enough capacity to ensure that losses don't exceed the bound. Note that explicit bounds on the loss level can be particularly difficult as the exact way in which packets merge inside the network affects the burstiness of the PDB's traffic aggregate and hence, loss.

たとえば、図3のDSドメインを考慮してください。損失時に明示的なバインドされたPDBは、境界にトラフィックコンディショニングを適用して、平均して出現するよりも多くのパケットが認められないようにする必要があります。ただし、ネットワークの内部キューイングは、いくつかのタイムスケールで入力トラフィックと出力トラフィックの違いをもたらす可能性がありますが、ネットワーク内での合理的なサイズのバッファリングに予想されることを平均化するタイムスケールを超えてはなりません。したがって、バーストがネットワークの内部に到着することが許可されている場合、損失が境界を超えないようにするのに十分な能力がなければなりません。ネットワーク内でパケットがマージされる正確な方法がPDBのトラフィックの集合体の破裂、したがって損失に影響するため、損失レベルの明示的な境界は特に困難になる可能性があることに注意してください。

PHBs give explicit expressions of the treatment a traffic aggregate can expect at each hop. For a PDB, this behavior must apply to merging and diverging traffic aggregates, thus characterizing a PDB requires understanding what happens to a PHB under aggregation. That is, PHBs recursively applied must result in a known behavior. As an example, since maximum burst sizes grow with the number of microflows or traffic aggregate streams merged, a PDB specification must address this. A clear advantage of constructing behaviors that aggregate is the ease of concatenating PDBs so that the associated traffic aggregate has known attributes that span interior DS domains and, eventually, farther. For example, in figure 1 assume that we have configured the foo PDB on the interior DS domains of AS2. Then traffic aggregates associated with the foo PDB in each interior DS domain of AS2 can be merged at the shaded interior boundary routers. If the same (or fewer) traffic conditioners as applied at the entrance to AS2 are applied at these interior boundaries, the attributes of the foo PDB should continue to be used to quantify the expected behavior. Explicit expressions of what happens to the behavior under aggregation, possibly parameterized by node in-degrees or network diameters, are necessary to determine what to do at the internal aggregation points. One approach might be to completely reapply the traffic conditioning at these points; another might employ some limited rate-based remarking only.

PHBは、各ホップでトラフィックの集合体が予想できる治療の明示的な表現を与えます。PDBの場合、この動作は、交通集約のマージと分岐の分岐に適用する必要があります。したがって、PDBを特徴付けるには、集約下でPHBに何が起こるかを理解する必要があります。つまり、PHBが再帰的に適用されると、既知の動作をもたらす必要があります。例として、最大バーストサイズはマイクロフローの数またはトラフィック集約ストリームの数で増加するため、PDB仕様はこれに対処する必要があります。凝集する行動を構築することの明確な利点は、PDBを連結しやすいことであり、関連するトラフィックの集合体がインテリアDSドメインにまたがって、最終的には遠くにある既知の属性を持っているようにします。たとえば、図1では、AS2の内部DSドメインでFOO PDBを構成したと想定しています。次に、AS2の各インテリアDSドメインのFOO PDBに関連付けられたトラフィック集約は、日陰の内部境界ルーターでマージできます。AS2の入り口に適用された同じ(または少ない)トラフィックコンディショナーがこれらの内部境界に適用される場合、Foo PDBの属性を引き続き使用して、予想される動作を定量化する必要があります。おそらく、ノード内またはネットワークの直径によってパラメーター化される可能性のある集約下での動作に何が起こるかについての明示的な表現は、内部集約ポイントで何をすべきかを決定するために必要です。1つのアプローチは、これらのポイントでトラフィックコンディショニングを完全に再適用することです。別のものは、限られたレートベースのリマークのみを採用する場合があります。

Multiple PDBs may use the same PHB. The specification of a PDB can contain a list of PHBs and their required configuration, all of which would result in the same PDB. In operation, it is expected that a single domain will use a single PHB to implement a particular PDB, though different domains may select different PHBs. Recall that in the diffserv definition [RFC2474], a single PHB might be selected within a domain by a list of DSCPs. Multiple PDBs might use the same PHB in which case the transit performance of traffic aggregates of these PDBs will, of necessity, be the same. Yet, the particular characteristics that the PDB designer wishes to claim as attributes may vary, so two PDBs that use the same PHB might not be specified with the same list of attributes.

複数のPDBが同じPHBを使用する場合があります。PDBの仕様には、PHBとその必要な構成のリストを含めることができ、そのすべてが同じPDBになります。動作中は、単一のドメインが単一のPHBを使用して特定のPDBを実装することが予想されますが、異なるドメインが異なるPHBを選択する場合があります。DiffServ定義[RFC2474]では、DSCPSのリストによってドメイン内で単一のPHBが選択される可能性があることを思い出してください。複数のPDBが同じPHBを使用する場合があり、その場合、これらのPDBの交通凝集体の輸送パフォーマンスは、必然的に同じである可能性があります。しかし、PDB設計者が属性として請求したい特定の特性は異なる場合があるため、同じPHBを使用する2つのPDBは、同じ属性リストで指定されない場合があります。

The specification of the transit expectations of PDBs across domains both assists in the deployment of QoS within a DS domain and helps enable the composition of end-to-end, cross-domain services to proceed by making it possible to hide details of a domain's internals while exposing characteristics necessary for QoS.

ドメイン全体のPDBの輸送期待の仕様は、DSドメイン内でのQoSの展開を支援し、ドメインの内部の詳細を非表示にすることができるようにすることで、エンドツーエンドのクロスドメインサービスの構成が進むことができます。QoSに必要な特性を公開しながら。

4.3 PDBs using PHB Groups
4.3 PHBグループを使用したPDB

The use of PHB groups to construct PDBs can be done in several ways. A single PHB member of a PHB group might be used to construct a single PDB. For example, a PDB could be defined using just one of the Class Selector Compliant PHBs [RFC2474]. The traffic conditioning for that PDB and the required configuration of the particular PHB would be defined in such a way that there was no dependence or relationship with the manner in which other PHBs of the group are used or, indeed, whether they are used in that DS domain. In this case, the reasonable approach would be to specify this PDB alone in a document which expressly called out the conditions and configuration of the Class Selector PHB required.

PDBを構築するためにPHBグループを使用することは、いくつかの方法で実行できます。PHBグループの単一のPHBメンバーを使用して、単一のPDBを構築することができます。たとえば、PDBは、クラスセレクターに準拠したPHBの1つのみを使用して定義できます[RFC2474]。そのPDBのトラフィックコンディショニングと特定のPHBの必要な構成は、グループの他のPHBが使用される方法と依存または関係がないように定義されます。DSドメイン。この場合、合理的なアプローチは、必要なクラスセレクターPHBの条件と構成を明示的に呼び出すドキュメントでこのPDBのみを指定することです。

A single PDB can be constructed using more than one PHB from the same PHB group. For example, the traffic conditioner described in RFC 2698 might be used to mark a particular entering traffic aggregate for one of the three AF1x PHBs [RFC2597] while the transit performance of the resultant PDB is specified, statistically, across all the packets marked with one of those PHBs.

同じPHBグループから複数のPHBを使用して、単一のPDBを構築できます。たとえば、RFC 2698で説明されているトラフィックコンディショナーを使用して、3つのAF1X PHBS [RFC2597]のいずれかの特定の入力トラフィックアグリゲートをマークするために使用できます。それらのPHBの。

A set of related PDBs might be defined using a PHB group. In this case, the related PDBs should be defined in the same document. This is appropriate when the traffic conditioners that create the traffic aggregates associated with each PDB have some relationships and interdependencies such that the traffic aggregates for these PDBs should be described and characterized together. The transit attributes will depend on the PHB associated with the PDB and will not be the same for all PHBs in the group, though there may be some parameterized interrelationship between the attributes of each of these PDBs. In this case, each PDB should have a clearly separate description of its transit attributes (delineated in a separate subsection) within the document. For example, the traffic conditioner described in RFC 2698 might be used to mark arriving packets for three different AF1x PHBs, each of which is to be treated as a separate traffic aggregate in terms of transit properties. Then a single document could be used to define and quantify the relationship between the arriving packets and the emerging traffic aggregates as they relate to one another. The transit characteristics of packets of each separate AF1x traffic aggregate should be described separately within the document.

関連するPDBのセットは、PHBグループを使用して定義される場合があります。この場合、関連するPDBを同じドキュメントで定義する必要があります。これは、各PDBに関連付けられているトラフィック集合体を作成するトラフィックコンディショナーに、これらのPDBのトラフィック集合体を一緒に記述し、特徴付ける必要があるため、何らかの関係と相互依存関係がある場合に適切です。トランジット属性は、PDBに関連付けられたPHBに依存し、グループ内のすべてのPHBで同じではありませんが、これらの各PDBの属性間にパラメーター化された相互関係がある場合があります。この場合、各PDBには、ドキュメント内のトランジット属性(個別のサブセクションで描写されている)の明確な別個の説明が必要です。たとえば、RFC 2698で説明されているトラフィックコンディショナーは、3つの異なるAF1X PHBの到着パケットをマークするために使用できます。それぞれは、輸送特性の観点から個別のトラフィック集計として扱われます。次に、単一のドキュメントを使用して、到着するパケットと、互いに関連する際に新たなトラフィック集合体との関係を定義および定量化できます。個別のAF1xトラフィック集約の各パケットのトランジット特性については、ドキュメント内で個別に説明する必要があります。

Another way in which a PHB group might be used to create one PDB per PHB might have decoupled traffic conditioners, but some relationship between the PHBs of the group. For example, a set of PDBs might be defined using Class Selector Compliant PHBs [RFC2474] in such a way that the traffic conditioners that create the traffic aggregates are not related, but the transit performance of each traffic aggregate has some parametric relationship to the other. If it makes sense to specify them in the same document, then the author(s) should do so.

PHBグループを使用してPHBごとに1つのPDBを作成する別の方法では、トラフィックコンディショナーが分離された可能性がありますが、グループのPHB間の関係があります。たとえば、一連のPDBは、トラフィック集合体を作成するトラフィックコンディショナーが関連していないように、クラスセレクター準拠のPHB [RFC2474]を使用して定義される場合がありますが、各トラフィックアグリゲートのトランジットパフォーマンスは他のトラフィックのパラメトリックな関係を持っています。。同じドキュメントでそれらを指定することが理にかなっている場合、著者はそうする必要があります。

4.4 Forwarding path vs. control plane
4.4 転送パス対コントロールプレーン

A PDB's associated PHB, classifiers, and traffic conditioners are all in the packet forwarding path and operate at line rates. PHBs, classifiers, and traffic conditioners are configured in response to control plane activity which takes place across a range of time scales, but, even at the shortest time scale, control plane actions are not expected to happen per-packet. Classifiers and traffic conditioners at the DS domain boundary are used to enforce who gets to use the PDB and how the PDB should behave temporally. Reconfiguration of PHBs might occur monthly, quarterly, or only when the network is upgraded. Classifiers and traffic conditioners might be reconfigured at a few regular intervals during the day or might happen in response to signalling decisions thousands of times a day. Much of the control plane work is still evolving and is outside the charter of the Diffserv WG. We note that this is quite appropriate since the manner in which the configuration is done and the time scale at which it is done should not affect the PDB attributes.

PDBに関連するPHB、分類子、トラフィックコンディショナーはすべてパケット転送パスにあり、ラインレートで動作します。PHB、分類器、およびトラフィックコンディショナーは、さまざまな時間スケールで行われるコントロールプレーンアクティビティに応じて構成されていますが、最短時間スケールでさえ、コントロールプレーンのアクションはパケットごとに発生するとは予想されません。DSドメイン境界の分類器とトラフィックコンディショナーは、誰がPDBを使用するか、PDBが時間的にどのように動作するかを強制するために使用されます。PHBの再構成は、毎月、四半期ごと、またはネットワークがアップグレードされた場合にのみ発生する場合があります。分類器とトラフィックコンディショナーは、日中にいくつかの通常の間隔で再構成されるか、1日に数千回のシグナル決定に応じて発生する可能性があります。コントロールプレーンの作業の多くはまだ進化しており、diffserv WGの憲章の外にあります。これは、構成が行われる方法とそれが行われる時間スケールがPDB属性に影響しないため、非常に適切であることに注意してください。

5 Format for Specification of Diffserv Per-Domain Behaviors

5ドメインごとの拡散挙動の仕様のための形式

PDBs arise from a particular relationship between edge and interior (which may be parameterized). The quantifiable characteristics of a PDB must be independent of whether the network edge is configured statically or dynamically. The particular configuration of traffic conditioners at the DS domain edge is critical to how a PDB performs, but the act(s) of configuring the edge is a control plane action which can be separated from the specification of the PDB.

PDBは、エッジとインテリアの特定の関係から生じます(パラメーター化される場合があります)。PDBの定量化可能な特性は、ネットワークエッジが静的に構成されているか動的に構成されているかどうかに依存する必要があります。DSドメインエッジでのトラフィックコンディショナーの特定の構成は、PDBのパフォーマンスにとって重要ですが、エッジを構成する法律は、PDBの仕様から分離できるコントロールプレーンアクションです。

The following sections must be present in any specification of a Differentiated Services PDB. Of necessity, their length and content will vary greatly.

次のセクションは、差別化されたサービスPDBの仕様に存在する必要があります。必然的に、それらの長さとコンテンツは大きく異なります。

5.1 Applicability Statement
5.1 アプリケーションステートメント

All PDB specs must have an applicability statement that outlines the intended use of this PDB and the limits to its use.

すべてのPDB仕様には、このPDBの意図された使用とその使用の制限の概要を示す適用性ステートメントが必要です。

5.2 Technical specification
5.2 技術仕様

This section specifies the rules or guidelines to create this PDB, each distinguished with "may", "must" and "should." The technical specification must list the classification and traffic conditioning required (if any) and the PHB (or PHBs) to be used with any additional requirements on their configuration beyond that contained in RFCs. Classification can reflect the results of an admission control process. Traffic conditioning may include marking, traffic shaping, and policing. A Service Provisioning Policy might be used to describe the technical specification of a particular PDB.

このセクションでは、このPDBを作成するルールまたはガイドラインを指定します。それぞれが「5月」、「必須」、「必須」で区別されます。技術仕様には、必要な分類とトラフィックコンディショニング(存在する場合)とPHB(またはPHB)を、RFCSに含まれるものを超えて構成に関する追加要件を使用して使用する必要があります。分類は、入場制御プロセスの結果を反映しています。トラフィックコンディショニングには、マーキング、トラフィックシェーピング、ポリシングが含まれます。特定のPDBの技術仕様を説明するために、サービスプロビジョニングポリシーを使用する場合があります。

5.3 Attributes
5.3 属性

A PDB's attributes tell how it behaves under ideal conditions if configured in a specified manner (where the specification may be parameterized). These might include drop rate, throughput, delay bounds measured over some time period. They may be bounds, statistical bounds, or percentiles (e.g., "90% of all packets measured over intervals of at least 5 minutes will cross the DS domain in less than 5 milliseconds"). A wide variety of characteristics may be used but they must be explicit, quantifiable, and defensible. Where particular statistics are used, the document must be precise about how they are to be measured and about how the characteristics were derived.

PDBの属性は、指定された方法で構成された場合(仕様がパラメーター化される場合がある場合)、理想的な条件下でどのように動作するかを示します。これらには、ドロップレート、スループット、ある期間にわたって測定された遅延境界が含まれる場合があります。それらは、境界、統計の境界、またはパーセンタイルである可能性があります(たとえば、「少なくとも5分間の間隔で測定されたすべてのパケットの90%が5ミリ秒未満でDSドメインを通過する」)。さまざまな特性を使用できますが、それらは明示的で定量化可能で、防御可能でなければなりません。特定の統計が使用されている場合、ドキュメントは、それらの測定方法と特性がどのように導き出されたかについて正確でなければなりません。

Advice to a network operator would be to use these as guidelines in creating a service specification rather than use them directly. For example, a "loss-free" PDB would probably not be sold as such, but rather as a service with a very small packet loss probability.

ネットワークオペレーターへのアドバイスは、これらを直接使用するのではなく、サービス仕様を作成する際のガイドラインとして使用することです。たとえば、「損失のない」PDBは、おそらくそのように販売されるのではなく、非常に小さなパケット損失確率を持つサービスとして販売されるでしょう。

5.4 Parameters
5.4 パラメーター

The definition and characteristics of a PDB may be parameterized by network-specific features; for example, maximum number of hops, minimum bandwidth, total number of entry/exit points of the PDB to/from the diffserv network, maximum transit delay of network elements, minimum buffer size available for the PDB at a network node, etc.

PDBの定義と特性は、ネットワーク固有の機能によってパラメーター化される場合があります。たとえば、ホップの最大数、最小帯域幅、DiffservネットワークへのPDBのEntr/Exitポイントの総数、ネットワーク要素の最大トランジット遅延、ネットワークノードでのPDBで利用可能な最小バッファサイズなど。

5.5 Assumptions
5.5 仮定

In most cases, PDBs will be specified assuming lossless links, no link failures, and relatively stable routing. This is reasonable since otherwise it would be very difficult to quantify behavior and this is the operating conditions for which most operators strive. However, these assumptions must be clearly stated. Since PDBs with specific bandwidth parameters require that bandwidth to be available, the assumptions to be stated may include standby capacity. Some PDBs may be specifically targeted for cases where these assumptions do not hold, e.g., for high loss rate links, and such targeting must also be made explicit. If additional restrictions, especially specific traffic engineering measures, are required, these must be stated.

ほとんどの場合、PDBは、ロスレスリンク、リンク障害なし、比較的安定したルーティングを想定して指定されます。それ以外の場合は、行動を定量化することが非常に困難であり、これがほとんどのオペレーターが努力する動作条件であるため、これは妥当です。ただし、これらの仮定は明確に述べられなければなりません。特定の帯域幅パラメーターを備えたPDBは、その帯域幅を利用可能にする必要があるため、述べられる仮定にはスタンバイ容量が含まれる場合があります。一部のPDBは、これらの仮定が保持されない場合、たとえば高い損失率リンクの場合、そのようなターゲティングも明示的にする必要があります。追加の制限、特に特定の交通工学の措置が必要な場合は、これらを記載する必要があります。

Further, if any assumptions are made about the allocation of resources within a diffserv network in the creation of the PDB, these must be made explicit.

さらに、PDBの作成におけるDiffServネットワーク内のリソースの割り当てについて仮定がなされた場合、これらを明示的にする必要があります。

5.6 Example Uses
5.6 例の使用

A PDB specification must give example uses to motivate the understanding of ways in which a diffserv network could make use of the PDB although these are not expected to be detailed. For example, "A bulk handling PDB may be used for all packets which should not take any resources from the network unless they would otherwise go unused. This might be useful for Netnews traffic or for traffic rejected from some other PDB by traffic policers."

PDB仕様は、DiffServネットワークがPDBを使用できる方法の理解を動機付けるための例を提供する必要がありますが、これらは詳細には予想されていません。たとえば、「PDBのバルクハンドリングは、ネットワークからリソースを使用しない限り、ネットワークからリソースを取得してはならないすべてのパケットに使用できます。これは、NetNewsトラフィックや、トラフィックポリサーによって他のPDBから拒否されたトラフィックに役立つ場合があります。」

5.7 Environmental Concerns (media, topology, etc.)
5.7 環境への懸念(メディア、トポロジなど)

Note that it is not necessary for a provider to expose which PDB (if a commonly defined one) is being used nor is it necessary for a provider to specify a service by the PDB's attributes. For example, a service provider might use a PDB with a "no queueing loss" characteristic in order to specify a "very low loss" service.

プロバイダーがどのPDB(一般的に定義されている場合)が使用されているかを公開する必要はないことも、プロバイダーがPDBの属性によってサービスを指定する必要もありません。たとえば、サービスプロバイダーは、「非常に低い損失」サービスを指定するために、「キューイングなし」特性を持つPDBを使用する場合があります。

This section is to inject realism into the characteristics described above. Detail the assumptions made there and what constraints that puts on topology or type of physical media or allocation.

このセクションは、上記の特性にリアリズムを注入することです。そこに行われた仮定と、トポロジーまたは物理メディアまたは割り当ての種類にどのような制約があるかを詳述します。

5.8 Security Considerations for each PDB
5.8 各PDBのセキュリティ上の考慮事項

This section should include any security considerations that are specific to the PDB. Is it subject to any unusual theft-of-service or denial-of-service attacks? Are any unusual security precautions needed?

このセクションには、PDBに固有のセキュリティ上の考慮事項を含める必要があります。異常な盗難盗難またはサービス拒否攻撃の対象ですか?珍しいセキュリティ上の注意事項は必要ですか?

It is not necessary to repeat the general security discussions in [RFC2474] and [RFC2475], but a reference should be included. Also refer to any special security considerations for the PHB or PHBs used.

[RFC2474]および[RFC2475]で一般的なセキュリティディスカッションを繰り返す必要はありませんが、参照を含める必要があります。また、使用したPHBまたはPHBの特別なセキュリティ上の考慮事項も参照してください。

6 On PDB Attributes

6 PDB属性について

As discussed in section 4, measurable, quantifiable attributes associated with each PDB can be used to describe what will happen to packets using that PDB as they cross the domain. In its role as a building block for the construction of interdomain quality-of-service, a PDB specification should provide the answer to the question: Under what conditions can we join the output of this domain to another under the same traffic conditioning and expectations? Although there are many ways in which traffic might be distributed, creating quantifiable, realizable PDBs that can be concatenated into multi-domain services limits the realistic scenarios. A PDB's attributes with a clear statement of the conditions under which the attributes hold is critical to the composition of multi-domain services.

セクション4で説明したように、各PDBに関連付けられた測定可能な定量化可能な属性を使用して、そのPDBがドメインを横切るときにパケットを使用して何が起こるかを説明できます。ドメイン間のサービス品質の構築のための構成要素としての役割において、PDB仕様は質問に対する答えを提供する必要があります。このドメインの出力を同じトラフィックコンディショニングと期待の下で別のドメインにどの条件に結合できますか?トラフィックを配布する方法はたくさんありますが、マルチドメインサービスに連結できる定量化可能な実現可能なPDBを作成すると、現実的なシナリオが制限されます。属性が保持する条件の明確なステートメントを持つPDBの属性は、マルチドメインサービスの構成にとって重要です。

There is a clear correlation between the strictness of the traffic conditioning and the quality of the PDB's attributes. As indicated earlier, numerical bounds are likely to be statistical or expressed as a percentile. Parameters expressed as strict bounds will require very precise mathematical analysis, while those expressed statistically can to some extent rely on experiment. Section 7 gives the example of a PDB without strict traffic conditioning and concurrent work on a PDB with strict traffic conditioning and attributes is also in front of the WG [VW]. This section gives some general considerations for characterizing PDB attributes.

トラフィックコンディショニングの厳格さとPDBの属性の品質との間には明確な相関があります。前に示したように、数値の境界は統計的またはパーセンタイルとして表される可能性があります。厳密な境界として表されるパラメーターには、非常に正確な数学的分析が必要になりますが、統計的に表現されたパラメーターは実験にある程度依存することができます。セクション7では、厳密なトラフィックコンディショニングと、厳密なトラフィックコンディショニングと属性を備えたPDBでの同時作業のないPDBの例も、WG [VW]の前にあります。このセクションでは、PDB属性を特徴付けるための一般的な考慮事項を示します。

There are two ways to characterize PDBs with respect to time. First are properties over "long" time periods, or average behaviors. A PDB specification should report these as the rates or throughput seen over some specified time period. In addition, there are properties of "short" time behavior, usually expressed as the allowable burstiness in a traffic aggregate. The short time behavior is important in understanding buffering requirements (and associated loss characteristics) and for metering and conditioning considerations at DS boundaries. For short-time behavior, we are interested primarily in two things: 1) how many back-to-back packets of the PDB's traffic aggregate will we see at any point (this would be metered as a burst) and 2) how large a burst of packets of this PDB's traffic aggregate can appear in a queue at once (gives queue overflow and loss). If other PDBs are using the same PHB within the domain, that must be taken into account.

時間に関してPDBを特徴付ける方法は2つあります。1つ目は、「長い」期間、または平均的な動作にわたるプロパティです。PDB仕様は、指定された期間にわたって見られるレートまたはスループットとしてこれらを報告する必要があります。さらに、「短い」時間行動の特性があり、通常はトラフィックの集合体で許容される爆発として表されます。短い時間の動作は、バッファリング要件(および関連する損失特性)を理解し、DS境界での計量とコンディショニングの考慮事項を理解する上で重要です。短時間の動作のために、私たちは主に2つのことに興味があります:1)PDBのトラフィック集合体の連続したパケットの数(これはバーストとして計算される)と2)このPDBのトラフィック集合体のパケットのバーストは、一度にキューに表示される可能性があります(キューのオーバーフローと損失を与えます)。他のPDBがドメイン内で同じPHBを使用している場合、それは考慮する必要があります。

6.1 Considerations in specifying long-term or average PDB attributes
6.1 長期的または平均PDB属性を指定する際の考慮事項

To characterize the average or long-term behavior for the foo PDB we must explore a number of questions, for instance: Can the DS domain handle the average foo traffic flow? Is that answer topology dependent or are there some specific assumptions on routing which must hold for the foo PDB to preserve its "adequately provisioned" capability? In other words, if the topology of D changes suddenly, will the foo PDB's attributes change? Will its loss rate dramatically increase?

FOO PDBの平均または長期の動作を特徴付けるには、たとえば、DSドメインが平均FOOトラフィックフローを処理できますか?その答えトポロジーに依存しているのですか、それとも「適切にプロビジョニングされた」機能を保持するためにFOO PDBが保持しなければならないルーティングにいくつかの具体的な仮定がありますか?言い換えれば、Dのトポロジーが突然変化した場合、Foo PDBの属性は変わりますか?その損失率は劇的に増加しますか?

Let domain D in figure 4 be an ISP ringing the U.S. with links of bandwidth B and with N tails to various metropolitan areas. Inside D, if the link between the node connected to A and the node connected to Z goes down, all the foo traffic aggregate between the two nodes must transit the entire ring: Would the bounded behavior of the foo PDB change? If this outage results in some node of the ring now having a larger arrival rate to one of its links than the capacity of the link for foo's traffic aggregate, clearly the loss rate would change dramatically. In this case, topological assumptions were made about the path of the traffic from A to Z that affected the characteristics of the foo PDB. If these topological assumptions no longer hold, the loss rate of packets of the foo traffic aggregate transiting the domain could change; for example, a characteristic such as "loss rate no greater than 1% over any interval larger than 10 minutes." A PDB specification should spell out the assumptions made on preserving the attributes.

図4のドメインDを、帯域幅Bのリンクとさまざまな大都市圏へのn尾で米国を鳴らすISPとします。D内部では、Aに接続されたノードとZに接続されたノード間のリンクがダウンすると、2つのノード間のすべてのFOOトラフィックがリング全体を通過する必要があります。FOOPDBの境界挙動は変化しますか?この停止により、リングの一部のノードが、Fooのトラフィックの集計のリンクの容量よりもリンクの1つに大きな到着率を持つようになった場合、明らかに損失率は劇的に変化します。この場合、FOO PDBの特性に影響を与えるAからZへのトラフィックの経路について、トポロジカルな仮定がなされました。これらのトポロジカルな仮定がもはや保持されない場合、ドメインを通過するFooトラフィックのパケットの損失率は変化する可能性があります。たとえば、「10分を超える間隔で1%以下」などの特性。PDB仕様は、属性の保存に関する仮定を綴る必要があります。

                  ____X________X_________X___________          /
                 /                                   \    L   |
         A<---->X                                     X<----->|  E
                |                                     |       |
                |               D                     |        \
         Z<---->X                                     |
                |                                     |
                 \___________________________________/
                         X                 X
        

Figure 4: ISP and DS domain D connected in a ring and connected to DS domain E

図4:リングで接続され、DSドメインEに接続されているISPおよびDSドメインD

6.2 Considerations in specifying short-term or bursty PDB attributes
6.2 短期的またはバーストPDB属性を指定する際の考慮事項

Next, consider the short-time behavior of the traffic aggregate associated with a PDB, specifically whether permitting the maximum bursts to add in the same manner as the average rates will lead to properties that aggregate or under what conditions this will lead to properties that aggregate. In our example, if domain D allows each of the uplinks to burst p packets into the foo traffic aggregate, the bursts could accumulate as they transit the ring. Packets headed for link L can come from both directions of the ring and back-to-back packets from foo's traffic aggregate can arrive at the same time. If the bandwidth of link L is the same as the links of the ring, this probably does not present a buffering problem. If there are two input links that can send packets to queue for L, at worst, two packets can arrive simultaneously for L. If the bandwidth of link L equals or exceeds twice B, the packets won't accumulate. Further, if p is limited to one, and the bandwidth of L exceeds the rate of arrival (over the longer term) of foo packets (required for bounding the loss) then the queue of foo packets for link L will empty before new packets arrive. If the bandwidth of L is equal to B, one foo packet must queue while the other is transmitted. This would result in N x p back-to- back packets of this traffic aggregate arriving over L during the same time scale as the bursts of p were permitted on the uplinks. Thus, configuring the PDB so that link L can handle the sum of the rates that ingress to the foo PDB doesn't guarantee that L can handle the sum of the N bursts into the foo PDB.

次に、PDBに関連付けられたトラフィック集合体の短時間の動作を検討します。特に、最大バーストが平均レートと同じ方法で追加できるかどうかを検討します。。この例では、ドメインDが各アップリンクをFOOトラフィックの集合体に破裂させることができる場合、リングを通過するときにバーストが蓄積する可能性があります。リンクLに向かうパケットは、リングの両方向から来ることができ、Fooのトラフィックアグリゲートからの連続したパケットは同時に到達できます。リンクLの帯域幅がリングのリンクと同じ場合、これはおそらくバッファリングの問題を提示しないでしょう。Lのキューにパケットを送信できる2つの入力リンクがある場合、最悪の場合、2つのパケットがLに対して同時に到着できます。LinkLの帯域幅が2回Bを超える場合、パケットは蓄積しません。さらに、Pが1に制限され、Lの帯域幅がFOOパケットの到着率(長期的に)を超える場合(損失の境界に必要)、リンクLのFOOパケットのキューは新しいパケットが到着する前に空になります。Lの帯域幅がBに等しい場合、1つのFooパケットがキューに並んでいる間、もう1つは送信されます。これにより、UPLINKSでPのバーストが許可されたのと同じ時間スケール中にLに到着するこのトラフィック集合体のN X Pバックツーバックパケットが生じます。したがって、Link LがFOO PDBに侵入するレートの合計を処理できるようにPDBを構成して、LがNバーストの合計をFOO PDBに処理できることを保証しません。

If the bandwidth of L is less than B, then the link must buffer Nxpx(B-L)/B foo packets to avoid loss. If the PDB is getting less than the full bandwidth L, this number is larger. For probabilistic bounds, a smaller buffer might do if the probability of exceeding it can be bounded.

Lの帯域幅がB未満の場合、リンクは損失を回避するためにNXPX(B-L)/B FOOパケットをバッファリングする必要があります。PDBが完全な帯域幅Lよりも少なくなっている場合、この数値は大きくなります。確率的境界の場合、それを超える確率が境界を獲得できる場合、より小さなバッファーが行う可能性があります。

More generally, for router indegree of d, bursts of foo packets might arrive on each input. Then, in the absence of any additional traffic conditioning, it is possible that dxpx(# of uplinks) back-to-back foo packets can be sent across link L to domain E. Thus the DS domain E must permit these much larger bursts into the foo PDB than domain D permits on the N uplinks or else the foo traffic aggregate must be made to conform to the TCA for entering E (e.g., by shaping).

より一般的には、DのルーターのINDEGREの場合、FOOパケットのバーストが各入力に到着する可能性があります。次に、追加のトラフィックコンディショニングがない場合、dxpx(uplinks of uplinks)をバックツーバックのfooパケットをリンクlを介してドメインEに送信できる可能性があります。ドメインDよりもFOO PDBは、nアップリンクで許可されます。そうしないと、FOOトラフィック集約は、Eを入力するためにTCAに適合する必要があります(たとえば、シェーピングによって)。

What conditions should be imposed on a PDB and on the associated PHB in order to ensure PDBs can be concatenated, as across the interior DS domains of figure 1? Traffic conditioning for constructing a PDB that has certain attributes across a DS domain should apply independently of the origin of the packets. With reference to the example we've been exploring, the TCA for the PDB's traffic aggregate entering link L into domain E should not depend on the number of uplinks into domain D.

図1の内部DSドメイン全体でPDBを連結できるようにするために、PDBおよび関連するPHBにどのような条件を課す必要がありますか?DSドメイン全体に特定の属性を持つPDBを構築するためのトラフィックコンディショニングは、パケットの起源とは独立して適用する必要があります。私たちが調査してきた例を参照して、PDBのトラフィック集計のTCAは、リンクLをドメインEに入力してください。ドメインDへのアップリンクの数に依存しないでください。

6.3 Remarks
6.3 備考

This section has been provided as motivational food for thought for PDB specifiers. It is by no means an exhaustive catalog of possible PDB attributes or what kind of analysis must be done. We expect this to be an interesting and evolutionary part of the work of understanding and deploying differentiated services in the Internet. There is a potential for much interesting research work. However, in submitting a PDB specification to the Diffserv WG, a PDB must also meet the test of being useful and relevant by a deployment experience, described in section 8.

このセクションは、PDB仕様の考え方の動機付けの食べ物として提供されています。可能なPDB属性の徹底的なカタログや、どのような分析を行う必要があるかを徹底的にカタログすることではありません。これは、インターネットで差別化されたサービスを理解し、展開する作業の興味深く進化的な部分になると予想しています。多くの興味深い研究作業の可能性があります。ただし、PDB仕様をDIFFSERV WGに送信する際には、PDBはセクション8で説明されている展開エクスペリエンスによって有用で関連性があるというテストを満たす必要があります。

7 A Reference Per-Domain Behavior

7ドメインごとの参照動作

The intent of this section is to define as a reference a Best Effort PDB, a PDB that has little in the way of rules or expectations.

このセクションの意図は、参照として定義することです。最適な努力PDB、ルールや期待の邪魔をしていないPDBです。

7.1 Best Effort PDB
7.1 最善の努力PDB
7.1.1 Applicability
7.1.1 適用可能性

A Best Effort (BE) PDB is for sending "normal internet traffic" across a diffserv network. That is, the definition and use of this PDB is to preserve, to a reasonable extent, the pre-diffserv delivery expectation for packets in a diffserv network that do not require any special differentiation. Although the PDB itself does not include bounds on availability, latency, and packet loss, this does not preclude Service Providers from engineering their networks so as to result in commercially viable bounds on services that utilize the BE PDB. This would be analogous to the Service Level Guarantees that are provided in today's single-service Internet.

最善の努力(BE)PDBは、DiffServネットワーク全体に「通常のインターネットトラフィック」を送信するためのものです。つまり、このPDBの定義と使用は、特別な差別化を必要としないDiffServネットワーク内のパケットに対するディフセルブ配信前の期待を合理的に保存することです。PDB自体には、可用性、待ち時間、パケット損失の境界線は含まれていませんが、これは、BE PDBを利用するサービスの商業的に実行可能な境界をもたらすために、サービスプロバイダーがネットワークをエンジニアリングすることを妨げるものではありません。これは、今日のシングルサービスインターネットで提供されるサービスレベルの保証に類似しています。

In the present single-service commercial Internet, Service Level Guarantees for availability, latency, and packet delivery can be found on the web sites of ISPs [WCG, PSI, UU]. For example, a typical North American round-trip latency bound is 85 milliseconds, with each service provider's site information specifying the method of measurement of the bounds and the terms associated with these bounds contractually.

現在のシングルサービスコマーシャルインターネットでは、ISP [WCG、PSI、UU]のWebサイトで、可用性、待ち時間、パケット配信のためのサービスレベルの保証があります。たとえば、典型的な北米の往復レイテンシバウンドは85ミリ秒であり、各サービスプロバイダーのサイト情報は、これらの境界に関連する境界の測定方法と契約上の用語を指定します。

7.1.2 TCS and PHB configurations
7.1.2 TCSおよびPHB構成

There are no restrictions governing rate and bursts of packets beyond the limits imposed by the ingress link. The network edge ensures that packets using the PDB are marked for the Default PHB (as defined in [RFC2474]), but no other traffic conditioning is required. Interior network nodes apply the Default PHB on these packets.

イングレスリンクによって課される制限を超えたパケットの爆発を管理する制限はありません。ネットワークエッジは、PDBを使用したパケットがデフォルトのPHBにマークされることを保証します([RFC2474]で定義されている)が、他のトラフィックコンディショニングは必要ありません。インテリアネットワークノードは、これらのパケットにデフォルトのPHBを適用します。

7.1.3 Attributes of this PDB
7.1.3 このPDBの属性

"As much as possible as soon as possible".

「できるだけ早くできるだけ早く」。

Packets of this PDB will not be completely starved and when resources are available (i.e., not required by packets from any other traffic aggregate), network elements should be configured to permit packets of this PDB to consume them.

このPDBのパケットは完全に飢えているわけではなく、リソースが利用可能である場合(つまり、他のトラフィック集合体からのパケットで必要とされない場合)、ネットワーク要素は、このPDBのパケットがそれらを使用できるように構成する必要があります。

Network operators may bound the delay and loss rate for services constructed from this PDB given knowledge about their network, but such attributes are not part of the definition.

ネットワークオペレーターは、ネットワークに関する知識を与えられたこのPDBから作成されたサービスの遅延と損失率をバインドする場合がありますが、そのような属性は定義の一部ではありません。

7.1.4 Parameters
7.1.4 パラメーター

None.

なし。

7.1.5 Assumptions
7.1.5 仮定

A properly functioning network, i.e., packets may be delivered from any ingress to any egress.

適切に機能するネットワーク、つまり、パケットは、任意の侵入から任意の出口に配信される場合があります。

7.1.6 Example uses
7.1.6 例の使用

1. For the normal Internet traffic connection of an organization.

1. 組織の通常のインターネットトラフィック接続用。

2. For the "non-critical" Internet traffic of an organization.

2. 組織の「批判的ではない」インターネットトラフィック用。

3. For standard domestic consumer connections

3. 標準の国内消費者接続用

7.1.7 Environmental Concerns
7.1.7 環境への懸念

There are no environmental concerns specific to this PDB.

このPDBに固有の環境上の懸念はありません。

7.1.8 Security Considerations for BE PDB
7.1.8 BE PDBのセキュリティ上の考慮事項

There are no specific security exposures for this PDB. See the general security considerations in [RFC2474] and [RFC2475].

このPDBの特定のセキュリティエクスポージャーはありません。[RFC2474]および[RFC2475]の一般的なセキュリティ上の考慮事項を参照してください。

8 Guidelines for writing PDB specifications

PDB仕様を作成するための8つのガイドライン

G1. Following the format given in this document, write a draft and submit it as an Internet Draft. The document should have "diffserv" as some part of the name. Either as an appendix to the draft, or in a separate document, provide details of deployment experience with measured results on a network of non-trivial size carrying realistic traffic and/or convincing simulation results (simulation of a range of modern traffic patterns and network topologies as applicable). The document should be brought to the attention of the diffserv WG mailing list, if active.

G1。このドキュメントに記載されている形式に従って、ドラフトを書き、インターネットドラフトとして送信します。ドキュメントには、名前の一部として「diffserv」が必要です。ドラフトの付録として、または別のドキュメントで、現実的なトラフィックおよび/または説得力のあるシミュレーション結果を運ぶ非自明なサイズのネットワークで測定された結果を備えた展開エクスペリエンスの詳細を提供します(最新のトラフィックパターンとネットワークのシミュレーション該当するトポロジー)。文書は、アクティブな場合は、DiffServ WGメーリングリストの注意を払う必要があります。

G2. Initial discussion should focus primarily on the merits of the PDB, though comments and questions on the claimed attributes are reasonable. This is in line with the Differentiated Services goal to put relevance before academic interest in the specification of PDBs. Academically interesting PDBs are encouraged, but would be more appropriate for technical publications and conferences, not for submission to the IETF. (An "academically interesting" PDB might become a PDB of interest for deployment over time.)

G2。最初の議論は、主にPDBのメリットに焦点を当てる必要がありますが、主張された属性に関するコメントと質問は合理的です。これは、PDBの仕様に学業上の関心の前に関連性を置くための差別化されたサービス目標と一致しています。学術的に興味深いPDBは奨励されていますが、IETFへの提出ではなく、技術出版物や会議により適しています。(「学問的に興味深い」PDBは、時間の経過とともに展開に関心のあるPDBになる可能性があります。)

The implementation of the following guidelines varies, depending on whether there is an active diffserv working group or not.

次のガイドラインの実装は、アクティブなDiffServワーキンググループがあるかどうかによって異なります。

Active Diffserv Working Group path:

アクティブなDiffServワーキンググループパス:

G3. Once consensus has been reached on a version of a draft that it is a useful PDB and that the characteristics "appear" to be correct (i.e., not egregiously wrong) that version of the draft goes to a review panel the WG co-chairs set up to audit and report on the characteristics. The review panel will be given a deadline for the review. The exact timing of the deadline will be set on a case-by-case basis by the co-chairs to reflect the complexity of the task and other constraints (IETF meetings, major holidays) but is expected to be in the 4-8 week range. During that time, the panel may correspond with the authors directly (cc'ing the WG co-chairs) to get clarifications. This process should result in a revised draft and/or a report to the WG from the panel that either endorses or disputes the claimed characteristics.

G3。ドラフトのバージョンでコンセンサスに到達すると、それは有用なPDBであり、特性が「見える」と「つまり、ひどく間違っていない)という特性がWG共同議長セットのレビューパネルに送られます。監査と特性について報告します。レビューパネルには、レビューの期限が与えられます。締め切りの正確なタイミングは、タスクの複雑さやその他の制約(IETF会議、主要な休日)を反映するために、共同議長によってケースバイケースで設定されますが、4-8週間であると予想されます。範囲。その間、パネルは著者に直接対応し(WG共同議長をcc」して、説明を得ることができます。このプロセスは、請求された特性を承認または争うかのいずれかをパネルからWGに改訂されたドラフトおよび/またはレポートをもたらす必要があります。

G4. If/when endorsed by the panel, that draft goes to WG last call. If not endorsed, the author(s) can give an itemized response to the panel's report and ask for a WG Last Call.

G4。パネルによって承認された場合、そのドラフトはWGの最後の呼び出しに送られます。承認されていない場合、著者はパネルのレポートに項目化された応答を提供し、WGの最後の呼び出しを求めることができます。

G5. If/when passes Last Call, goes to ADs for publication as a WG Informational RFC in our "PDB series".

G5。最終通話に合格した場合、「PDBシリーズ」でWG情報RFCとして公開のために広告に移動します。

If no active Diffserv Working Group exists:

アクティブなDiffServワーキンググループが存在しない場合:

G3. Following discussion on relevant mailing lists, the authors should revise the Internet Draft and contact the IESG for "Expert Review" as defined in section 2 of RFC 2434 [RFC2434].

G3。 関連するメーリングリストに関する議論に続いて、著者はインターネットのドラフトを修正し、RFC 2434 [RFC2434]のセクション2で定義されている「エキスパートレビュー」についてIESGに連絡する必要があります。

G4. Subsequent to the review, the IESG may recommend publication of the Draft as an RFC, request revisions, or decline to publish as an Informational RFC in the "PDB series".

G4。レビューに続いて、IESGは、ドラフトのRFCとしての公開、リクエストの改訂、または「PDBシリーズ」で情報RFCとして公開されることを拒否することを推奨する場合があります。

9 Security Considerations

9つのセキュリティ上の考慮事項

The general security considerations of [RFC2474] and [RFC2475] apply to all PDBs. Individual PDB definitions may require additional security considerations.

[RFC2474]および[RFC2475]の一般的なセキュリティ上の考慮事項は、すべてのPDBに適用されます。個々のPDB定義には、追加のセキュリティに関する考慮事項が必要になる場合があります。

10 Acknowledgements

10の謝辞

The ideas in this document have been heavily influenced by the Diffserv WG and, in particular, by discussions with Van Jacobson, Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush, Frank Kastenholz, Aaron Falk, and a host of other people who should be acknowledged for their useful input but not be held accountable for our mangling of it. Grenville Armitage coined "per domain behavior (PDB)" though some have suggested similar terms prior to that. Dan Grossman, Bob Enger, Jung-Bong Suk, and John Dullaert reviewed the document and commented so as to improve its form.

この文書のアイデアは、Diffserv WGの影響を強く受けています。特に、Van Jacobson、Dave Clark、Lixia Zhang、Geoff Huston、Scott Bradner、Randy Bush、Frank Kastenholz、Aaron Falk、その他のホストとの議論有用な意見を認められるべきであるが、私たちのマングリングについて責任を負うべきではない人々。グレンビルアーミテージは「ドメインの動作ごと(PDB)」を生み出しましたが、それ以前に同様の用語を提案している人もいます。ダン・グロスマン、ボブ・エンジャー、ユング・ボン・スク、ジョン・ダラートは文書をレビューし、その形式を改善するためにコメントしました。

References

参考文献

[RFC2474] Nichols, K., Blake, S. Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

[RFC2474] Nichols、K.、Blake、S。Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド(DSフィールド)の定義」、RFC 2474、1998年12月。

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", December 1998.

[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、1998年12月。

[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.

[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。

[RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.

[RFC2598] Jacobson、V.、Nichols、K。およびK. Poduri、「迅速な転送PHB」、RFC 2598、1999年6月。

[RFC2698] Heinanen, J. and R. Geurin, "A Two Rate Three Color Marker", RFC 2698, June 1999.

[RFC2698] Heinanen、J。およびR. Geurin、「A Rate Three Color Marker」、RFC 2698、1999年6月。

[MODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for Diffserv Routers", Work in Progress.

[モデル] Bernet、Y.、Blake、S.、Grossman、D。、およびA. Smith、「Diffservルーターの非公式管理モデル」は進行中です。

[MIB] Baker, F., Chan, K. and A. Smith, "Management Information Base for the Differentiated Services Architecture", Work in Progress.

[MIB] Baker、F.、Chan、K。およびA. Smith、「差別化されたサービスアーキテクチャの管理情報ベース」、進行中の作業。

[VW] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual Wire' Per-Domain Behavior", Work in Progress.

[VW] Jacobson、V.、Nichols、K。およびK. Poduri、「ドメインごとの「仮想ワイヤー」の動作」は、進行中の作業です。

[WCG] Worldcom, "Internet Service Level Guarantee", http://www.worldcom.com/terms/service_level_guarantee/ t_sla_terms.phtml

[WCG] Worldcom、「インターネットサービスレベル保証」、http://www.worldcom.com/terms/service_level_guarantee/ t_sla_terms.phtml

[PSI] PSINet, "Service Level Agreements", http://www.psinet.com/sla/

[psi] psinet、「サービスレベル契約」、http://www.psinet.com/sla/

[UU] UUNET USA Web site, "Service Level Agreements", http://www.us.uu.net/support/sla/

[uu] uunet USA Webサイト、「サービスレベル契約」、http://www.us.uu.net/support/sla/

[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for IANA Considerations", BCP 26, RFC 2434, October 1998.

[RFC2434] Alvestrand、H。およびT. Narten、「IANAの考慮事項のガイドライン」、BCP 26、RFC 2434、1998年10月。

Authors' Addresses

著者のアドレス

Kathleen Nichols Packet Design, LLC 2465 Latham Street, Third Floor Mountain View, CA 94040 USA

Kathleen Nichols Packet Design、LLC 2465 Latham Street、3階のマウンテンビュー、CA 94040 USA

   EMail: nichols@packetdesign.com
        

Brian Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA

ブライアンカーペンターIBM C/O ICAIR SUITE 150 1890 MAPLE AVENUE EVANSTON、IL 60201 USA

   EMail: brian@icair.org
        

Full Copyright Statement

完全な著作権声明

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

Copyright(c)The Internet Society(2001)。無断転載を禁じます。

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

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

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

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

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

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

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

RFCエディター機能の資金は現在、インターネット協会によって提供されています。