[要約] RFC 3754は、異なるサービス（DS）ネットワークでのIPマルチキャストに関するガイドラインです。このRFCの目的は、DSネットワークでの効果的なIPマルチキャストの実装と運用を支援することです。
Network Working Group R. Bless
Request for Comments: 3754 Univ. of Karlsruhe
Category: Informational K. Wehrle
Univ. of Tuebingen
April 2004
IP Multicast in Differentiated Services (DS) Networks
差別化されたサービス（DS）ネットワークのIPマルチキャスト
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 (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.
このドキュメントでは、RFC 2475（「差別化されたサービスのアーキテクチャ」）でのディスカッションで拡大している差別化されたサービス（DS）ネットワークでのIPマルチキャスト使用の問題について説明します。また、これらの問題の可能な解決策を示唆し、潜在的な実装モデルを説明し、シミュレーション結果を提示します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Management of Differentiated Services. . . . . . . . . . 2
2. Problems of IP Multicast in DS Domains . . . . . . . . . . . . 3
2.1. Neglected Reservation Subtree Problem (NRS Problem). . . 4
2.2. Heterogeneous Multicast Groups . . . . . . . . . . . . . 12
2.3. Dynamics of Any-Source Multicast . . . . . . . . . . . . 13
3. Solutions for Enabling IP-Multicast in Differentiated
Services Networks. . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Solution for the NRS Problem . . . . . . . . . . . . . . 13
3.2. Solution for Supporting Heterogeneous Multicast Groups . 15
3.3. Solution for Any-Source Multicast. . . . . . . . . . . . 16
4. Scalability Considerations . . . . . . . . . . . . . . . . . . 16
5. Deployment Considerations. . . . . . . . . . . . . . . . . . . 17
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
7. Implementation Model Example . . . . . . . . . . . . . . . . . 18
8. Proof of the Neglected Reservation Subtree Problem . . . . . . 19
8.1. Implementation of the Proposed Solution. . . . . . . . . 20
8.2. Test Environment and Execution . . . . . . . . . . . . . 21
9. Simulative Study of the NRS Problem and Limited Effort PHB . . 23
9.1. Simulation Scenario. . . . . . . . . . . . . . . . . . . 24
9.2. Simulation Results for Different Router Types. . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 31
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34
This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results.
このドキュメントでは、RFC 2475（「差別化されたサービスのアーキテクチャ」）でのディスカッションで拡大している差別化されたサービス（DS）ネットワークでのIPマルチキャスト使用の問題について説明します。また、これらの問題の可能な解決策を示唆し、潜在的な実装モデルを説明し、シミュレーション結果を提示します。
The "Differentiated Services" (DiffServ or DS) approach [1, 2, 3] defines certain building blocks and mechanisms to offer qualitatively better services than the traditional best-effort delivery service in an IP network. In the DiffServ Architecture [2], scalability is achieved by avoiding complexity and maintenance of per-flow state information in core nodes, and by pushing unavoidable complexity to the network edges. Therefore, individual flows belonging to the same service are aggregated, thereby eliminating the need for complex classification or managing state information per flow in interior nodes.
「差別化されたサービス」（DIFFSERVまたはDS）アプローチ[1、2、3]は、IPネットワークで従来のベストエフォート配信サービスよりも質的に優れたサービスを提供する特定のビルディングブロックとメカニズムを定義します。diffservアーキテクチャ[2]では、コアノード内のフローごとの状態情報の複雑さとメンテナンスを回避し、避けられない複雑さをネットワークエッジにプッシュすることにより、スケーラビリティが達成されます。したがって、同じサービスに属する個々のフローが集約されているため、内部ノードのフローあたりの複雑な分類や状態情報の管理の必要性が排除されます。
On the other hand, the reduced complexity in DS nodes makes it more complex to use those "better" services together with IP Multicast (i.e., point-to-multipoint or multipoint-to-multipoint communication). Problems emerging from this fact are described in section 2. Although the basic DS forwarding mechanisms also work with IP Multicast, some facts have to be considered which are related to the provisioning of multicast resources. It is important to integrate IP Multicast functionality into the architecture from the beginning, and to provide simple solutions for those problems that will not defeat the already gained advantages.
一方、DSノードの複雑さの低下により、これらの「より良い」サービスをIPマルチキャスト（つまり、ポイントツーマルチポイントまたはマルチポイントツーマルチポイント通信）を使用することがより複雑になります。この事実から出現する問題はセクション2で説明されています。基本的なDS転送メカニズムはIPマルチキャストでも機能しますが、マルチキャストリソースのプロビジョニングに関連するいくつかの事実を考慮する必要があります。IPマルチキャスト機能を最初からアーキテクチャに統合し、すでに獲得した利点を打ち負かすことのない問題に簡単なソリューションを提供することが重要です。
At least for Per-Domain Behaviors and services based on the EF PHB, admission control and resource reservation are required [14, 15]. Installation and updating of traffic profiles in boundary nodes is necessary. Most network administrators cannot accomplish this task manually, even for long term service level agreements (SLAs). Furthermore, offering services on demand requires some kind of signaling and automatic admission control procedures.
少なくともEF PHBに基づくドメインごとの行動とサービスには、入学管理とリソースの予約が必要です[14、15]。境界ノードでのトラフィックプロファイルのインストールと更新が必要です。ほとんどのネットワーク管理者は、長期的なサービスレベル契約（SLA）であっても、このタスクを手動で達成することはできません。さらに、オンデマンドでサービスを提供するには、何らかのシグナリングと自動入学制御手順が必要です。
However, no standardized resource management architecture for DiffServ domains exists. The remainder of this document assumes that at least some logical resource management entity is available to perform resource-based admission control and allotment functions. This entity may also be realized in a distributed fashion, e.g., within the routers themselves. Detailed aspects of the resource management realization within a DiffServ domain, as well as the interactions between resource management and routers or end-systems (e.g., signaling for resources), are out of scope of this document.
ただし、DiffServドメインの標準化されたリソース管理アーキテクチャは存在しません。このドキュメントの残りの部分では、少なくともいくつかの論理的なリソース管理エンティティがリソースベースの入場制御と割り当て機能を実行するために利用可能であると想定しています。このエンティティは、ルーター自体の内部で、分散型ファッションで実現することもできます。DiffServドメイン内のリソース管理実現の詳細な側面、およびリソース管理とルーターまたはエンドシステムの相互作用（リソースのシグナリングなど）は、このドキュメントの範囲外です。
Protocols for signaling a reservation request to a Differentiated Services Domain are required. For accomplishing end-system signaling to DS domains, RSVP [4] may be used with new DS specific reservation objects [5]. RSVP provides support for multicast scenarios and is already supported by many systems. However, application of RSVP in a DiffServ multicast context may lead to problems that are also described in the next section. The NSIS Working Group is currently defining new signaling protocols that may show a different behavior, but the WG has its current focus more on unicast flows than on multicast flows.
差別化されたサービスドメインへの予約要求を信号するためのプロトコルが必要です。DSドメインへの最終システムシグナル伝達を達成するために、RSVP [4]は、新しいDS固有の予約オブジェクト[5]で使用できます。RSVPは、マルチキャストシナリオのサポートを提供し、すでに多くのシステムでサポートされています。ただし、DiffServマルチキャストコンテキストでのRSVPの適用は、次のセクションで説明されている問題につながる可能性があります。NSISワーキンググループは現在、異なる動作を示す可能性のある新しいシグナル伝達プロトコルを定義していますが、WGはマルチキャストフローよりもユニキャストフローに現在焦点を当てています。
Although potential problems and the complexity of providing multicast with Differentiated Services are considered in a separate section of [2], both aspects have to be discussed in greater detail. The simplicity of the DiffServ Architecture and its DS node types is necessary to reach high scalability, but it also causes fundamental problems in conjunction with the use of IP Multicast in DS domains. The following subsections describe these problems for which a generic solution is proposed in section 3. This solution is as scalable as IP Multicast and needs no resource separation by using different codepoint values for unicast and multicast traffic.
潜在的な問題とマルチキャストを差別化されたサービスで提供する複雑さは、[2]の別のセクションで考慮されていますが、両方の側面について詳しく説明する必要があります。DiffservアーキテクチャとそのDSノードタイプのシンプルさは、高いスケーラビリティに達するために必要ですが、DSドメインでのIPマルチキャストの使用と併せて根本的な問題を引き起こします。次のサブセクションでは、セクション3でジェネリックソリューションが提案されているこれらの問題について説明します。このソリューションは、IPマルチキャストと同じくらいスケーラブルであり、ユニキャストとマルチキャストトラフィックに異なるCodePoint値を使用してリソース分離を必要としません。
Because Differentiated Services are unidirectional by definition, the point-to-multipoint communication is also considered as unidirectional. In traditional IP Multicast, any node can send packets spontaneously and asynchronously to a multicast group specified by their multicast group address, i.e., traditional IP Multicast offers a multipoint-to-multipoint service, also referred to as Any-Source Multicast. Implications of this feature are discussed in section 2.3.
定義により差別化されたサービスは一方向であるため、ポイントツーマルチポイント通信も単方向と見なされます。従来のIPマルチキャストでは、任意のノードは、マルチキャストグループアドレスで指定されたマルチキャストグループに自発的に非同期にパケットを送信できます。つまり、従来のIPマルチキャストは、任意のソースマルチキャストとも呼ばれるマルチポイントからマルチポイントサービスを提供します。この機能の意味については、セクション2.3で説明します。
For subsequent considerations we assume, unless stated otherwise, at least a unidirectional point-to-multipoint communication scenario in which the sender generates packets which experience a "better" Per-Hop-Behavior than the traditional default PHB, resulting in a service of better quality than the default best-effort service. In order to accomplish this, a traffic profile corresponding to the traffic conditioning specification has to be installed in the sender's first DS-capable boundary node. Furthermore, it must be assured that the corresponding resources are available on the path from the sender to all the receivers, possibly requiring adaptation of traffic profiles at involved domain boundaries. Moreover, on demand resource reservations may be receiver-initiated.
その後の考慮事項のために、特に明記されていない限り、少なくとも一方向のポイントツーマルチポイント通信シナリオでは、送信者が従来のデフォルトPHBよりも「より良い」ホップ障害を経験するパケットを生成するため、より良いサービスが得られます。デフォルトのベストエフォルトサービスよりも品質。これを達成するには、送信者の最初のDS対応境界ノードにトラフィックコンディショニング仕様に対応するトラフィックプロファイルをインストールする必要があります。さらに、対応するリソースが送信者からすべてのレシーバーへのパスで利用可能であることを保証する必要があり、おそらく関係するドメイン境界でトラフィックプロファイルを適応させる必要があります。さらに、オンデマンドリソースの予約は受信機によって開始される場合があります。
Typically, resources for Differentiated Services must be reserved before they are used. But in a multicast scenario, group membership is often highly dynamic, thereby limiting the use of a sender-initiated resource reservation in advance. Unfortunately, dynamic addition of new members of the multicast group using Differentiated Services can adversely affect other existing traffic if resources were not explicitly reserved before use. A practical proof of this problem is given in section 8.
通常、差別化されたサービスのリソースは、使用する前に予約する必要があります。しかし、マルチキャストのシナリオでは、グループメンバーシップは非常に動的であることが多いため、送信者が開始したリソース予約の使用が事前に制限されます。残念ながら、差別化されたサービスを使用してマルチキャストグループの新しいメンバーを動的に追加すると、使用前にリソースが明示的に予約されていない場合、他の既存のトラフィックに悪影響を与える可能性があります。この問題の実際的な証拠は、セクション8に示されています。
IP Multicast packet replication usually takes place when the packet is handled by the forwarding core (cf. Fig. 1), i.e., when it is forwarded and replicated according to the multicast forwarding table. Thus, a DiffServ capable node would also copy the content of the DS field [1] into the IP packet header of every replicate. Consequently, replicated packets get exactly the same DS codepoint (DSCP) as the original packet, and therefore experience the same forwarding treatment as the incoming packets of this multicast group. This is also illustrated in Fig. 1, where each egress interface comprises functions for (BA-) classification, traffic conditioning (TC), and queueing.
IPマルチキャストパケットレプリケーションは、通常、パケットが転送コアによって処理されるときに行われます（図1を参照）。つまり、マルチキャスト転送テーブルに従って転送および複製されます。したがって、DiffServ対応ノードは、DSフィールド[1]のコンテンツをすべての複製のIPパケットヘッダーにコピーします。その結果、複製されたパケットは、元のパケットとまったく同じDS CodePoint（DSCP）を取得するため、このマルチキャストグループの着信パケットと同じ転送処理が発生します。これを図1に示します。ここでは、各出口インターフェイスは（BA-）分類、トラフィックコンディショニング（TC）、およびキューイングの関数を含みます。
Interface A IP Forwarding Interface B
+-----------+ +--------------+ +-----------+
MC-flow | | | replication | | egress |
---->| ingress |---->|------+-------|----->|(class.,TC,|---->
| | | | | | queueing) |
+-----------+ | | | +-----------+
| | |
| | | Interface C
| | | +-----------+
| | | | egress |
| +-------|----->|(class.,TC,|---->
| | | queueing) |
+--------------+ +-----------+
Figure 1: Multicast packet replication in a DS node
図1：DSノードのマルチキャストパケットレプリケーション
Normally, the replicating node cannot test whether a corresponding resource reservation exists for a particular flow of replicated packets on an output link (i.e., its corresponding interface). This is because flow-specific information (e.g., traffic profiles) is usually not available in every boundary and interior node.
通常、複製ノードは、出力リンク上の複製されたパケットの特定のフロー（つまり、対応するインターフェイス）に対応するリソース予約が存在するかどうかをテストできません。これは、通常、すべての境界および内部ノードでフロー固有の情報（トラフィックプロファイルなど）が利用できないためです。
When a new receiver joins an IP Multicast group, a multicast routing protocol (e.g., DVMRP [6], PIM-DM [7] or PIM-SM [8]) grafts a new branch to an existing multicast tree in order to connect the new receiver to the tree. As a result of tree expansion, missing per-flow classification, and policing mechanisms, the new receiver will implicitly use the service of better quality, because of the "better" copied DSCP.
新しいレシーバーがIPマルチキャストグループに参加すると、マルチキャストルーティングプロトコル（例：DVMRP [6]、PIM-DM [7]、またはPIM-SM [8]）が既存のマルチキャストツリーに新しいブランチを接続して接続して接続します。ツリーへの新しいレシーバー。ツリーの拡張、流量あたりの分類の欠落、およびポリシングメカニズムの結果として、新しいレシーバーは、「より良い」コピーされたDSCPのために、より良い品質のサービスを暗黙的に使用します。
If the additional amount of resources which are consumed by the new part of the multicast tree are not taken into account by the domain resource management (cf. section 1.1), the currently provided quality of service of other receivers (with correct reservations) will be affected adversely or even violated. This negative effect on existing traffic contracts by a neglected resource reservation -- in the following designated as the Neglected Reservation Subtree Problem (NRS Problem) -- must be avoided under all circumstances. Strong admission control policies at the domain boundary will not help to prevent this problem either, because the new flow that inadmissibly consumes resources has its origin inside the domain.
マルチキャストツリーの新しい部分によって消費されるリソースの追加量がドメインリソース管理（セクション1.1を参照）によって考慮されていない場合、現在提供されている他のレシーバーのサービス品質（正しい予約）は影響を受けたり、違反したりすることさえあります。無視されたリソース予約による既存の交通契約に対するこのマイナスの影響 - 無視された予約サブツリー問題（NRS問題）として指定された以下では、あらゆる状況下で避ける必要があります。ドメイン境界での強力な入場管理ポリシーも、この問題を防ぐのに役立ちません。これは、リソースを容認できるほど消費する新しいフローがドメイン内にその起源を持っているからです。
One can distinguish two major cases of the NRS Problem. They show a different behavior depending on the location of the branching point. In order to compare their different effects, a simplistic example of a share of bandwidth is illustrated in Fig. 2 and is used in the following explanations. Neither the specific PHB types nor their assigned bandwidth share are important; however, their relative priority with respect to each other is of importance.
NRS問題の2つの主要なケースを区別できます。分岐点の位置に応じて、異なる動作を示します。それらのさまざまな効果を比較するために、帯域幅のシェアの単純な例を図2に示し、以下の説明で使用されています。特定のPHBタイプも割り当てられた帯域幅シェアも重要ではありません。ただし、互いに比較的優先されることは重要です。
40% 40% 20%
+--------------------+---------------------+------------+
|Expedited Forwarding| Assured Forwarding | Best-Effort|
+--------------------+---------------------+------------+
---------------------------------------------------------->
output link bandwidth
Figure 2: An example bandwidth share of different behavior aggregates
図2：異なる動作の帯域幅シェアの例
The bandwidth of the considered output link is shared by three types of services (i.e., by three behavior aggregates): Expedited Forwarding, Assured Forwarding, and the traditional Best-Effort service. In this example, we assume that routers perform strict priority queueing, where EF has the highest, AF the middle, and Best-Effort the lowest assigned scheduling priority. Though not mandatory for an EF implementation, a strict non-preemptive priority scheduler is one implementation option as described in section 5.1.1 of RFC 3247 [15]. Were Weighted Fair Queueing (WFQ) to be used, the described effects would essentially also occur, but with minor differences. In the following scenarios, it is illustrated that PHBs of equal or lower priority (in comparison to the multicast flow's PHB) are affected by the NRS problem.
考慮された出力リンクの帯域幅は、3つのタイプのサービス（つまり、3つの動作集計）によって共有されます。この例では、ルーターが厳密な優先順位キューイングを実行すると想定しています。ここでは、EFが最も高く、中央で、最も低い割り当てられたスケジューリングの優先順位を上回ります。EF実装には必須ではありませんが、厳密ではない非償還優先度スケジューラは、RFC 3247のセクション5.1.1 [15]で説明されている1つの実装オプションです。重み付けされた公正なキューイング（WFQ）が使用される場合、説明された効果も本質的に発生しますが、わずかな違いがあります。次のシナリオでは、（マルチキャストフローのPHBと比較して）等しいまたは低い優先度のPHBがNRS問題の影響を受けることが示されています。
The Neglected Reservation Subtree problem appears in two different cases:
無視された予約サブツリーの問題は、2つの異なるケースに表示されます。
o Case 1: If the branching point of the new subtree (at first only a branch) and the previous multicast tree is a (egress) boundary node, as shown in Fig. 3, the additional multicast flow now increases the total amount of used resources for the corresponding behavior aggregate on the affected output link. The total amount will be greater than the originally reserved amount. Consequently, the policing component in the egress boundary node drops packets until the traffic aggregate is in accordance with the traffic contract. But while dropping packets, the router can not identify the responsible flow (because of missing flow classification functionality), and thus randomly discards packets, whether they belong to a correctly behaving flow or not. As a result, there will no longer be any service guarantee for the flows with properly reserved resources.
o ケース1：新しいサブツリーの分岐点（最初は分岐のみ）と以前のマルチキャストツリーが（出口）境界ノードである場合、図3に示すように、追加のマルチキャストフローにより、使用済みリソースの総量が増加します。影響を受ける出力リンク上の対応する動作集約。総額は、当初予約された金額よりも大きくなります。その結果、Egress Boundaryノードのポリシングコンポーネントは、トラフィックの集計がトラフィック契約に従うまでパケットをドロップします。しかし、パケットをドロップしている間、ルーターは（フロー分類機能が欠落しているため）責任あるフローを識別することができず、したがって、それらが正しく動作するフローに属しているかどうかにかかわらず、パケットをランダムに破棄することはできません。その結果、適切に予約されたリソースを備えたフローのサービス保証はなくなります。
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ *) +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|###########|BN|####|IN|######|BN|####|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . \ .
. +--+ +--+ . \\ . \ .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A|
.+--+ +--+. +------+
|BN|........|BN|
+--+ +--+
||
S: Sender Recv.x: Receiver x FHN: First-Hop Node BN: Boundary Node IN: Interior Node ===: Multicast branch with reserved bandwidth ###: Multicast branch without reservation *) Bandwidth of EF aggregated on the output link is higher than actual reservation, EF aggregate will be limited in bandwidth without considering the responsible flow.
S：Sender Recv.X：受信機X FHN：最初のホップノードBN：境界ノードIN：インテリアノード===：予約帯域幅のあるマルチキャストブラン実際の予約よりも高いため、EF集合体は責任ある流れを考慮せずに帯域幅が制限されます。
Figure 3: The NRS Problem (case 1) occurs when Receiver B joins
図3：NRS問題（ケース1）が受信者Bが結合するときに発生します
In figure 3, it is assumed that receiver A is already attached to the egress boundary node (BN) of the first domain. Furthermore, resources are properly reserved along the path to receiver A and used by correspondingly marked packets. When receiver B joins the same group as receiver A, packets are replicated and forwarded along the new branch towards the second domain with the same PHB as for receiver A. If this PHB is EF, the new branch possibly exhausts allotted resources for the EF PHB, adversely affecting other EF users that receive their packets over the link that is marked with the *). The BN usually ensures that outgoing traffic aggregates to the next domain are conforming to the agreed traffic conditioning specification. The egress BN will, therefore, drop packets of the PHB type that are used for the multicast flow.
図3では、受信機Aが最初のドメインの出力境界ノード（BN）にすでに接続されていると想定されています。さらに、リソースはレシーバーAへのパスに沿って適切に予約され、それに応じてマークされたパケットによって使用されます。受信機BがレシーバーAと同じグループに結合すると、パケットはレシーバーAと同じPHBで2番目のドメインに向かって新しいブランチに沿って複製および転送されます。このPHBがEFである場合、新しいブランチはEF PHBに割り当てられたリソースを排出する可能性があります、 *）でマークされているリンク上にパケットを受け取る他のEFユーザーに悪影響を及ぼします。BNは通常、次のドメインへの発信トラフィックが合意されたトラフィックコンディショニング仕様に準拠していることを保証します。したがって、出力BNは、マルチキャストフローに使用されるPHBタイプのパケットをドロップします。
Other PHBs of lower or higher priority are not affected adversely in this case. The following example in Fig. 4. illustrates this for two PHBs.
この場合、優先度が低いまたは高い他のPHBは悪影響を受けません。図4の次の例は、2つのPHBのこれを示しています。
+------------------+---------------------+--------------+------+
| Expedited Forw. | Expedited Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| EF with and without reservation share | 40 % | 20% |
| 40% of reserved EF aggregate. | | |
| -> EF packets with reservation and | | |
| without reservation will be | | |
| discarded! | | |
+------------------+---------------------+--------------+------+
(a) Excess flow has EF codepoint
(a) 過剰な流れにはEF CodePointがあります
+------------------+---------------------+--------------+------+
| Expedited Forw. | Assured Forwarding | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| | AF with & without reservation share| 20 % |
| | 40% of reserved EF aggregate. | |
| 40% | -> EF packets with reservation and | |
| | without reservation will be | |
| | discarded! | |
+------------------+---------------------+--------------+------+
(b) Excess flow has AF codepoint
(b) 過剰な流れにはaf codepointがあります
Figure 4: Resulting share of bandwidth in a egress boundary node with a neglected reservation of (a) an Expedited Forwarding flow or (b) an Assured Forwarding flow.
図4：（a）迅速な転送フローまたは（b）保証された転送フローの留保が無視された出口境界ノードの帯域幅の結果のシェア。
Fig. 4 shows the resulting share of bandwidth in cases when (a) Expedited Forwarding and (b) Assured Forwarding is used by the additional multicast branch causing the NRS Problem. Assuming that the additional traffic would use another 30% of the link bandwidth, Fig. 4 (a) illustrates that the resulting aggregate of Expedited Forwarding (70% of the outgoing link bandwidth) is throttled down to its originally reserved 40%. In this case, the amount of dropped EF bandwidth is equal to the amount of excess bandwidth. Consequently, the original Expedited Forwarding aggregate (which had 40% of the link bandwidth reserved) is also affected by packet losses. The other services, e.g., Assured Forwarding or Best-Effort, are not disadvantaged.
図4は、（a）迅速な転送と（b）NRS問題を引き起こす追加のマルチキャストブランチによって使用される場合の帯域幅のシェアを示しています。追加のトラフィックがリンク帯域幅のさらに30％を使用すると仮定すると、図4（a）は、結果として生じる迅速な転送の集合体（発信リンク帯域幅の70％）が元々予約された40％にスロットされていることを示しています。この場合、ドロップされたEF帯域幅の量は、過剰な帯域幅の量に等しくなります。したがって、元の迅速な転送骨材（リンク帯域幅の40％が予約されている）もパケット損失の影響を受けます。他のサービス、たとえば、保証された転送やベストエフォルトは、不利な立場にありません。
Fig. 4 (b) shows the same situation for Assured Forwarding. The only difference is that now Assured Forwarding is solely affected by discards, as the other services will still get their guarantees. In either case, packet losses are restricted to the misbehaving service class by the traffic meter and policing mechanisms in boundary nodes. Moreover, the latter problem (case 1) occurs only in egress boundary nodes because they are responsible for ensuring that the traffic leaving the Differentiated Services domain is not more than the following ingress boundary node will accept. Therefore, those violations of SLAs will already be detected and processed in egress boundary nodes.
図4（b）は、保証された転送のための同じ状況を示しています。唯一の違いは、他のサービスが依然として保証を取得するため、現在の保証転送は廃棄のみの影響を受けていることです。どちらの場合でも、パケットの損失は、トラフィックメーターと境界ノードのポリシングメカニズムによる不正行為のサービスクラスに制限されています。さらに、後者の問題（ケース1）は、差別化されたサービスドメインを離れるトラフィックが次のイングレス境界ノードを受け入れることにすぎないことを確認する責任があるため、出口境界ノードでのみ発生します。したがって、これらのSLAの違反は既に検出され、出力境界ノードで処理されます。
o Case 2: The Neglected Reservation Subtree problem can also occur if the branching point between the previous multicast tree and the new subtree is located in an interior node (as shown in Fig. 5). In Fig. 5, it is assumed that receivers A and B have already joined the multicast group and have reserved resources accordingly. The interior node in the second domain starts replication of multicast packets as soon as receiver C joins. Because the router is not equipped with metering or policing functions, it will not recognize any amount of excess traffic and will forward the new multicast flow. If the latter belongs to a higher priority service, such as Expedited Forwarding, bandwidth of the aggregate is higher than the aggregate's reservation at the new branch and will use bandwidth from lower priority services.
o ケース2：前のマルチキャストツリーと新しいサブツリーの間の分岐点が内部ノードにある場合、無視された予約サブツリー問題も発生する可能性があります（図5に示すように）。図5では、受信機AとBがすでにマルチキャストグループに参加しており、それに応じてリソースを予約していると想定されています。2番目のドメインの内部ノードは、受信機Cが結合するとすぐにマルチキャストパケットの複製を開始します。ルーターには計量機能やポリシング機能が装備されていないため、過剰なトラフィックの量を認識せず、新しいマルチキャストフローを転送します。後者が、迅速な転送などのより高い優先サービスに属している場合、集合体の帯域幅は新しい支店での集計の予約よりも高く、優先度の低いサービスの帯域幅を使用します。
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|===========|BN|====|IN|======|BN|===|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . # .
. +--+ +--+ . \\ . # *) .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A| #
.+--+ +--+. +------+ #
|BN|........|BN| +------+
+--+ +--+ |Recv.C|
|| +------+
FHN: First-Hop Node, BN: Boundary Node, Recv.x: Receiver x
S: Sender, IN: Interior Node
===: Multicast branch with reserved bandwidth
###: Multicast branch without reservation
*) Bandwidth of EF aggregated on the output link is higher than
actual reservation, EF aggregate will be limited in bandwidth
without considering the responsible flow
Figure 5: Neglected Reservation Subtree problem case 2 after join of receiver C
図5：レシーバーcの結合後の予約サブツリー問題ケース2
The additional amount of EF without a corresponding reservation is forwarded together with the aggregate which has a reservation. This results in no packet losses for Expedited Forwarding as long as the resulting aggregate is not higher than the output link bandwidth. Because of its higher priority, Expedited Forwarding gets as much bandwidth as needed and as is available. The effects on other PHBs are illustrated by the following example in Fig. 6.
対応する予約なしの追加量のEFは、予約がある集合体とともに転送されます。これにより、結果の集合体が出力リンク帯域幅よりも高くない限り、迅速な転送のパケット損失はありません。優先度が高いため、迅速な転送は、必要に応じて利用可能な帯域幅を得ることができます。他のPHBへの影響は、図6の次の例で説明されています。
+------------------+---------------------+--------------+------+
| Expedited Forw. | Expedited Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| 40% | 30% | 30% | 0% |
+------------------+---------------------+--------------+------+
EF with reservation and the excess flow use together 70%
of the link bandwidth because EF, with or without reservation,
has the highest priority.
(a) Excess flow has EF codepoint
(a) 過剰な流れにはEF CodePointがあります
+------------------+---------------------+--------------+------+
| Expedited Forw. | Assured Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| 40% | 60% | 0% |
| | (10% loss) | |
+------------------+---------------------+--------------+------+
AF with reservation and the excess flow use together 60%
of the link bandwidth because EF has the highest priority
(-> 40%). 10% of AF packets will be lost.
(b) Excess flow has AF codepoint
(b) 過剰な流れにはaf codepointがあります
Figure 6: Resulting share of bandwidth in an interior node with a neglected reservation of (a) an Expedited Forwarding flow or (b) an Assured Forwarding flow
図6：（a）迅速な転送フローまたは（b）保証された転送フローの予約が無視された内部ノードの帯域幅の結果のシェア
The result of case 2 is that there is no restriction for Expedited Forwarding, but as Fig. 6 (a) shows, other services will be extremely disadvantaged by this use of non-reserved resources. Their bandwidth is used by the new additional flow. In this case, the additional 30% Expedited Forwarding traffic preempts resources from the Assured Forwarding traffic, which in turn preempts resources from the best-effort traffic, resulting in 10% packet losses for the Assured Forwarding aggregate, and a complete loss of best-effort traffic. The example in Fig. 6 (b) shows that this can also happen with lower priority services like Assured Forwarding. When a reservation for a service flow with lower priority is neglected, other services (with even lower priority) can be reduced in their quality (in this case the best-effort service). As shown in the example, the service's aggregate causing the NRS problem can itself be affected by packet losses (10% of the Assured Forwarding aggregate is discarded). Besides the described problems of case 2, case 1 will occur in the DS boundary node of the next DS domain that performs traffic metering and policing for the service aggregate.
ケース2の結果は、迅速な転送に制限がないことですが、図6（a）が示すように、他のサービスはこの非予定のリソースの使用によって非常に不利な立場にあります。それらの帯域幅は、新しい追加フローによって使用されます。この場合、追加の30％の迅速な転送トラフィックにより、リソースが保証された転送トラフィックからリソースを先取りし、リソースを最良のエフォルトトラフィックから先取りし、保証された転送の総計で10％のパケット損失をもたらし、ベストの完全な損失をもたらします - 努力トラフィック。図6（b）の例は、これが保証された転送などの優先度の低いサービスでも発生する可能性があることを示しています。優先度が低いサービスフローの予約が無視されると、他のサービス（優先度がさらに低い）が品質を減らすことができます（この場合、最良のサービス）。この例に示すように、NRS問題を引き起こすサービスの集合体自体は、パケット損失の影響を受ける可能性があります（保証された転送の集計の10％は破棄されます）。ケース2の説明されている問題に加えて、ケース1は、サービス集合体のトラフィックメーターとポリシングを実行する次のDSドメインのDS境界ノードで発生します。
Directly applying RSVP to Differentiated Services would also result in temporary occurrence of the NRS Problem. A receiver has to join the IP multicast group to receive the sender's PATH messages, before being able to send a resource reservation request (RESV message). Thus, the join message on the link for receiving PATH messages can cause the NRS Problem, if this situation is not handled in a special way (e.g., by marking all PATH messages with codepoint 0 and dropping or re-marking all other data packets of the multicast flow).
RSVPを差別化されたサービスに直接適用すると、NRS問題が一時的に発生します。レシーバーは、リソース予約リクエスト（RESVメッセージ）を送信する前に、送信者のパスメッセージを受信するためにIPマルチキャストグループに参加する必要があります。したがって、パスメッセージを受信するためのリンクの結合メッセージは、この状況が特別な方法で処理されない場合、NRSの問題を引き起こす可能性があります（たとえば、すべてのパスメッセージをCodePoint 0でマークし、他のすべてのデータパケットをドロップまたは再マークすることによりマルチキャストフロー）。
Heterogeneous multicast groups contain one or more receivers, which would like to get another service or quality of service as the sender provides or other receiver subsets currently use. A very important characteristic which should be supported by Differentiated Services is that participants requesting a best-effort quality only should also be able to participate in a group communication which otherwise utilizes a better service class. The next better support for heterogeneity provides concurrent use of more than two different service classes within a group. Things tend to get even more complex when not only different service classes are required, but also different values for quality parameters within a certain service class.
不均一なマルチキャストグループには、1つ以上のレシーバーが含まれています。これは、送信者が提供する別のサービスまたはサービスの品質を取得し、現在使用している他のレシーバーサブセットを取得したいと考えています。差別化されたサービスによってサポートされるべき非常に重要な特徴は、最良のエフォルト品質のみを要求する参加者は、より良いサービスクラスを利用するグループコミュニケーションにも参加できる必要があることです。不均一性に対する次のより良いサポートは、グループ内で2つ以上の異なるサービスクラスの同時使用を提供します。さまざまなサービスクラスが必要であるだけでなく、特定のサービスクラス内の品質パラメーターの異なる値も、さらに複雑になる傾向があります。
A further problem is to support heterogeneous groups with different service classes in a consistent way. It is possible that some services will not be comparable to each other so that one service cannot be replaced by the other, and both services have to be provided over the same link within this group.
さらなる問題は、異なるサービスクラスを持つ異種グループを一貫した方法でサポートすることです。一部のサービスは互いに匹敵しないため、あるサービスを他のサービスに置き換えることができず、両方のサービスをこのグループ内の同じリンクで提供する必要がある可能性があります。
Because an arbitrary new receiver that wants to get the different service can be grafted to any point of the current multicast delivery tree, even interior nodes may have to replicate packets using the different service. At a first glance, this seems to be a contradiction with respect to simplicity of the interior nodes, because they do not even have a profile available and should now convert the service of quality of individual receivers. Consequently, in order to accomplish this, interior nodes have to change the codepoint value during packet replication.
さまざまなサービスを取得したい任意の新しいレシーバーは、現在のマルチキャスト配信ツリーの任意のポイントに接ぎ木できるため、インテリアノードでさえ、異なるサービスを使用してパケットを複製する必要がある場合があります。一見、これは内部ノードの単純さに関して矛盾しているようです。なぜなら、それらは利用可能なプロファイルさえ持っておらず、今では個々のレシーバーの品質のサービスを変換する必要があるからです。その結果、これを達成するために、インテリアノードはパケットレプリケーション中にコードポイント値を変更する必要があります。
Basically, within an IP multicast group, any participant (actually, it can be any host not even receiving packets of this multicast group) can act as a sender. This is an important feature which should also be available in case a specific service other than best-effort is used within the group. Differentiated Services possess, conceptually, a unidirectional character. Therefore, for every multicast tree implied by a sender, resources must be reserved separately if simultaneous sending should be possible with a better service. This is even true if shared multicast delivery trees are used (e.g., with PIM-SM or Core Based Trees). If not enough resources are reserved for a service within a multicast tree allowing simultaneous sending of more than one participant, the NRS problem will occur again. The same argument applies to half-duplex reservations which would share the reserved resources by several senders, because it cannot be ensured by the network that exactly one sender sends packets to the group. Accordingly, the corresponding RSVP reservation styles "Wildcard Filter" and "Shared-Explicit Filter" [4] cannot be supported within Differentiated Services. The Integrated Services approach is able to ensure the half-duplex nature of the traffic, because every router can check each packet for its conformance with the installed reservation state.
基本的に、IPマルチキャストグループ内では、参加者（実際、このマルチキャストグループのパケットを受け取っていないホストでもあります）は、送信者として機能します。これは、Best-Effort以外の特定のサービスがグループ内で使用されている場合にも利用できる重要な機能です。差別化されたサービスは、概念的には一方向の特徴を持っています。したがって、送信者が暗示するすべてのマルチキャストツリーについて、より良いサービスで同時送信が可能になる場合は、リソースを個別に予約する必要があります。これは、共有マルチキャスト配信ツリーが使用されている場合でも当てはまります（たとえば、PIM-SMまたはコアベースのツリーを使用）。複数の参加者を同時に送信できるマルチキャストツリー内のサービスに十分なリソースが予約されていない場合、NRSの問題が再び発生します。同じ引数は、正確に1つの送信者がグループにパケットを送信することをネットワークで保証することができないため、いくつかの送信者が予約リソースを共有するハーフダプレックス予約に適用されます。したがって、対応するRSVP予約スタイル「WildCardフィルター」と「共有エクスプリティフィルター」[4]は、差別化されたサービス内ではサポートできません。統合されたサービスアプローチは、すべてのルーターがインストールされた予約状態との適合性を確認できるため、トラフィックの半分二重性の性質を確保することができます。
The problems described in the previous section are mainly caused by the simplicity of the Differentiated Services architecture. Solutions that do not introduce additional complexity need to be introduced so as to not diminish the scalability of the DiffServ approach. This document suggests a straightforward solution for most of the problems.
前のセクションで説明した問題は、主に差別化されたサービスアーキテクチャの単純さによって引き起こされます。DiffServアプローチのスケーラビリティを低下させないように、追加の複雑さを導入しないソリューションを導入する必要があります。このドキュメントは、ほとんどの問題に対する簡単なソリューションを示唆しています。
The proposed solution consists conceptually of the following three steps that are described in more detail later.
提案されたソリューションは、以下の3つのステップの概念的に構成されており、後で詳しく説明します。
1. A new receiver joins a multicast group that is using a DiffServ service. Multicast routing protocols accomplish the connection of the new branch to the (possibly already existing) multicast delivery tree as usual.
1. 新しいレシーバーは、DiffServサービスを使用しているマルチキャストグループに参加します。マルチキャストルーティングプロトコルは、新しいブランチと（おそらく既存の）マルチキャスト配信ツリーと通常どおりに接続されています。
2. The unauthorized use of resources is avoided by re-marking at branching nodes all additional packets departing down the new branch. At first, the new receiver will get all packets of the multicast group without quality of service. The management entity of the correspondent DiffServ domain may get informed about the extension of the multicast tree.
2. リソースの不正使用は、新しいブランチを離れるすべての追加パケットを分岐することで再マークすることにより回避されます。最初は、新しいレシーバーは、サービス品質なしでマルチキャストグループのすべてのパケットを取得します。特派員のdiffservドメインの管理エンティティは、マルチキャストツリーの拡張について情報を得ることができます。
3. If a pre-issued reservation is available for the new branch or somebody (receiver, sender or a third party) issues one, the management entity instructs the branching router to set the corresponding codepoint for the demanded service.
3. 新しいブランチまたは誰か（受信者、送信者、または第三者）が1つを発行するために事前に発行された予約が利用可能である場合、管理エンティティは分岐ルーターに、要求されたサービスの対応するコードポイントを設定するよう指示します。
Usage of resources which were not previously reserved must be prevented. In the following example, we consider a case where the join of a new receiver to a DS multicast group requires grafting of a new branch to an already existing multicast delivering tree. The connecting node that joins both trees converts the codepoint (and therefore the Per-Hop Behavior) to a codepoint of a PHB which is similar to the default PHB in order to provide a best-effort-like service for the new branch. More specifically, this particular PHB can provide a service that is even worse than the best-effort service of the default PHB. See RFC 3662 [16] for a corresponding Lower Effort Per-Domain Behavior.
以前に予約されていなかったリソースの使用を防ぐ必要があります。次の例では、新しいレシーバーをDSマルチキャストグループに結合するには、すでに既存のマルチキャスト配信ツリーに新しいブランチをグラフトする必要がある場合を検討します。両方のツリーを結合する接続ノードは、新しいブランチにベストエフォルトのようなサービスを提供するために、デフォルトのPHBに似たPHBのコードポイントにコードポイント（したがってホップごとの動作）を変換します。より具体的には、この特定のPHBは、デフォルトのPHBの最高のエフォルトサービスよりもさらに悪いサービスを提供できます。ドメインあたりの対応する低い努力については、RFC 3662 [16]を参照してください。
The conversion to this specific PHB could be necessary in order to avoid unfairness being introduced within the best-effort service aggregate, and, which results from the higher amount of resource usage of the incoming traffic belonging to the multicast group. If the rate at which re-marked packets are injected into the outgoing aggregate is not reduced, those re-marked packets will probably cause discarding of other flow's packets in the outgoing aggregate if resources are scarce.
この特定のPHBへの変換は、マルチキャストグループに属する着信トラフィックのリソース使用量が多いことに起因する、最高のエフォルトサービスの総計内で不公平が導入されるのを防ぐために必要になる可能性があります。再マーク化されたパケットが発信骨材に注入された速度が減少しない場合、それらの再マ化されたパケットは、リソースが不足している場合、発信骨材に他のフローのパケットを破棄する可能性があります。
Therefore, the re-marked packets from this multicast group should be discarded more aggressively than other packets in this outgoing aggregate. This could be accomplished by using an appropriately configured PHB (and a related DSCP) for those packets. In order to distinguish this kind of PHB from the default PHB, it is referred to as the Limited Effort (LE) PHB (which can be realized by an appropriately configured AF PHB [9] or Class Selector Compliant PHB [1]) throughout this document. Merely dropping packets more aggressively at the re-marking node is not sufficient, because there may be enough resources in the outgoing behavior aggregate (BA) to transmit every re-marked packet without having to discard any other packets within the same BA. However, resources in the next node may be short for this particular BA. Those "excess" packets, therefore, must be identifiable at this node.
したがって、このマルチキャストグループからの再マークされたパケットは、この発信集合体の他のパケットよりも積極的に破棄する必要があります。これは、これらのパケットに適切に構成されたPHB（および関連するDSCP）を使用することで実現できます。この種のPHBをデフォルトのPHBと区別するために、これは限られた努力（LE）PHB（これは、これを通して適切に構成されたAF PHB [9]またはクラスセレクターに準拠したPHB [1]によって実現できます）と呼ばれます。書類。再マークノードでパケットをより積極的にドロップするだけでは十分ではありません。これは、同じBA内の他のパケットを破棄することなく、すべての再マークされたパケットを送信するのに十分なリソースがある可能性があるためです。ただし、次のノードのリソースは、この特定のBAの略である場合があります。したがって、これらの「過剰」パケットは、このノードで識別できる必要があります。
Re-marking packets is only required at branching nodes, whereas all other nodes of the multicast tree (such with outdegree 1) replicate packets as usual. Because a branching node may also be an interior node of a domain, re-marking of packets requires conceptually per-flow classification. Though this seems to be in contradiction to the DiffServ philosophy of a core that avoids per-flow states, IP multicast flows are different from unicast flows: traditional IP multicast forwarding and multicast routing are required to install states per multicast group for every outgoing link anyway. Therefore, re-marking in interior nodes is scalable to the same extent as IP multicast (cf. section 4).
再マルキングパケットは、分岐ノードでのみ必要ですが、マルチキャストツリーの他のすべてのノード（outustegree 1を含む）は、通常どおりにパケットを複製します。分岐ノードはドメインのインテリアノードでもある可能性があるため、パケットの再マークには概念的に流量分類が必要です。これは、流量あたりの状態を回避するコアの拡散哲学と矛盾しているようですが、IPマルチキャストフローはユニキャストフローとは異なります。。したがって、内部ノードでの再マークは、IPマルチキャストと同じ程度までスケーラブルです（セクション4を参照）。
Re-marking with standard DiffServ mechanisms [10] for every new branch requires activation of a default traffic profile. The latter accomplishes re-marking by using a combination of an MF-classifier and a marker at an outgoing link that constitutes a new branch. The classifier will direct all replicated packets to a marker that sets the new codepoint. An alternative implementation is described in section 7.
新しいブランチごとに標準のDiffServメカニズム[10]を使用して再マークするには、デフォルトのトラフィックプロファイルのアクティブ化が必要です。後者は、新しいブランチを構成する発信リンクでMF分類器とマーカーの組み合わせを使用することにより、再マークを達成します。分類器は、すべての複製されたパケットを新しいコードポイントを設定するマーカーに向けます。代替の実装については、セクション7で説明します。
The better service will only be provided if a reservation request was processed and approved by the resource management function. That means an admission control test must be performed before resources are actually used by the new branch. In case the admission test is successful, the re-marking node will be instructed by the resource management to stop re-marking and to use the original codepoint again (conceptually by removing the profile).
リソース管理機能によって予約リクエストが処理および承認された場合にのみ、より良いサービスが提供されます。つまり、新しいブランチがリソースを実際に使用する前に、入場制御テストを実行する必要があります。入場テストが成功した場合、リソース管理がリソース管理によって指示され、再マッキングを停止し、元のCodePointを再度使用するように指示されます（プロファイルを削除することにより）。
In summary, only those receivers will obtain a better service within a DiffServ multicast group, which previously reserved the corresponding resources in the new branch with assistance of the resource management. Otherwise, they get a quality which might be even lower than best-effort.
要約すると、これらのレシーバーのみが、リソース管理の支援を受けて新しいブランチの対応するリソースを以前に予約していたDiffservマルチキャストグループ内でより良いサービスを取得します。そうでなければ、彼らは最高のエフォルトよりもさらに低い品質を得る。
In this document, considerations are limited to provisioning different service classes, but not different quality parameters within a certain service class.
このドキュメントでは、考慮事項はさまざまなサービスクラスのプロビジョニングに限定されていますが、特定のサービスクラス内の異なる品質パラメーターではありません。
The proposed concept from section 3.1 provides a limited solution of the heterogeneity problem. Receivers are allowed to obtain a Limited Effort service without a reservation, so that at least two different service classes within a multicast group are possible. Therefore, it is possible for any receiver to participate in the multicast session without getting any quality of service. This is useful if a receiver just wants to see whether the content of the multicast group is interesting enough, before requesting a better service which must be paid for (like snooping into a group without prior reservation).
セクション3.1の提案された概念は、不均一性の問題の限られた解決策を提供します。レシーバーは、予約なしで限られた努力サービスを取得することができます。そのため、マルチキャストグループ内の少なくとも2つの異なるサービスクラスが可能になります。したがって、サービスの品質を得ることなく、受信者がマルチキャストセッションに参加することができます。これは、レシーバーがマルチキャストグループのコンテンツが十分に興味深いかどうかを確認したい場合に役立ちます。
Alternatively, a receiver might not be able to receive this better quality of service (e.g., because it is mobile and uses a wireless link of limited capacity), but it may be satisfied with the reduced quality, instead of getting no content at all.
あるいは、レシーバーはこの優れたサービスの品質を受け取ることができない場合があります（たとえば、モバイルであり、容量のワイヤレスリンクを使用しているため）が、コンテンツをまったく取得するのではなく、品質の低下に満足する場合があります。
Additionally, applying the RSVP concept of listening for PATH messages before sending any RESV message is feasible again. Without using the proposed solution, this would have caused the NRS Problem.
さらに、RESVメッセージを送信する前にパスメッセージをリスニングするというRSVPコンセプトを適用することは再び実行可能です。提案されたソリューションを使用せずに、これはNRSの問題を引き起こしていたでしょう。
Theoretically, the proposed approach in section 7 also supports more than two different services within one multicast group, because the additional field in the multicast routing table can store any DSCP value. However, this would work only if PHBs can be ordered, so that the "best" PHB among different required PHBs downstream is chosen to be forwarded on a specific link. This is mainly a management issue and is out of the scope of this document.
理論的には、セクション7で提案されたアプローチは、マルチキャストルーティングテーブルの追加フィールドにDSCP値を保存できるため、1つのマルチキャストグループ内で2つ以上の異なるサービスもサポートしています。ただし、これはPHBを注文できる場合にのみ機能するため、特定のリンクに転送されるように選択されます。これは主に管理上の問題であり、このドキュメントの範囲外です。
More advanced concepts may also support conditional re-marking in dependence on the group address and DSCP value. This is useful if the group uses different PHBs (e.g., for flows to different transport protocol ports) and the re-marking should thus additionally depend on the DSCP value of an incoming packet.
より高度な概念は、グループアドレスとDSCP値に依存して条件付きの再マークをサポートする可能性があります。これは、グループが異なるPHBを使用している場合（たとえば、異なる輸送プロトコルポートへのフロー）、したがって、再マークすることは、着信パケットのDSCP値にさらに依存する必要がある場合に役立ちます。
Every participant would have to initiate an explicit reservation to ensure the possibility of sending to the group with a better service quality, regardless of whether other senders within the group already use the same service class simultaneously. This would require a separate reservation for each sender-rooted multicast tree.
すべての参加者は、グループ内の他の送信者がすでに同じサービスクラスを同時に使用しているかどうかにかかわらず、より良いサービス品質でグループに送る可能性を確保するために、明示的な予約を開始する必要があります。これには、各送信者がルートしたマルチキャストツリーごとに個別の予約が必要です。
However, in the specific case of best-effort service (the default PHB), it is nevertheless possible for participants to send packets to the group anytime without requiring any additional mechanisms. The reason for this is that the first DS-capable boundary node will mark those packets with the DSCP of the default PHB because of a missing traffic profile for this particular sender. The first DS capable boundary nodes should therefore always classify multicast packets based on both the sender's address and the multicast group address.
ただし、Best-Effortサービス（デフォルトPHB）の特定のケースでは、参加者が追加のメカニズムを必要とせずにいつでもグループにパケットを送信することが可能です。この理由は、この特定の送信者のトラフィックプロファイルが欠落しているため、最初のDS対応境界ノードがデフォルトPHBのDSCPでそれらのパケットをマークするためです。したがって、最初のDS対応境界ノードは、送信者のアドレスとマルチキャストグループアドレスの両方に基づいて、常にマルチキャストパケットを分類する必要があります。
The proposed solution does not add complexity to the DS architecture or to a DS node, nor does it change the scalability properties of DiffServ. With current IP multicast routing protocols, a multicast router has to manage and hold state information per traversing multicast flow. The suggested solution scales to the same extent as IP multicast itself, because the proposed re-marking may occur per branch of a multicast flow. This re-marking is logically associated with an addition to the multicast routing state that is required anyway. In this respect, re-marking of packets for multicast flows in interior nodes is not considered as a scalability problem or to be in contradiction to the DiffServ approach itself. It is important to distinguish the multicast case from existing justifiable scalability concerns relating to re-marking packets of unicast flows within interior routers. Moreover, the decision of when to change a re-marking policy is not performed by the router, but by some management entity at a time scale which is different from the time scale at the packet forwarding level.
提案されたソリューションでは、DSアーキテクチャやDSノードに複雑さを追加することも、DiffServのスケーラビリティプロパティを変更しません。現在のIPマルチキャストルーティングプロトコルを使用すると、マルチキャストルーターは、マルチキャストフローを横断するごとに状態情報を管理および保持する必要があります。提案されたソリューションは、マルチキャストフローのブランチごとに提案された再マルキングが発生する可能性があるため、IPマルチキャスト自体と同程度までスケーリングします。この再マッキングは、とにかく必要なマルチキャストルーティング状態への追加に論理的に関連付けられています。この点で、内部ノードのマルチキャストフロー用のパケットの再マークは、スケーラビリティの問題とは見なされず、Diffservアプローチ自体と矛盾しているとは考えられていません。マルチキャストケースを、内部ルーター内のユニキャストフローの再マークパケットに関連する既存の正当なスケーラビリティの懸念と区別することが重要です。さらに、再マークポリシーを変更するタイミングの決定は、ルーターによって行われるのではなく、パケット転送レベルでの時間スケールとは異なるタイムスケールの一部の管理エンティティによって実行されます。
The solution proposed in section 3.1 can be deployed on most router platforms available today. Architectures that perform routing and forwarding functions in software could be updated by a new software release.
セクション3.1で提案されているソリューションは、今日入手可能なほとんどのルータープラットフォームに展開できます。ソフトウェアでルーティングと転送機能を実行するアーキテクチャは、新しいソフトウェアリリースによって更新できます。
However, there may be some specialized hardware platforms that are currently not able to deploy the proposed solution from section 7. This may be the case when a multicast packet is directly duplicated on the backplane of the router, so that all outgoing interfaces read the packet in parallel. Consequently, the codepoint cannot be changed for a subset of these outgoing interfaces and the NRS problem can not be solved directly in the branching point.
ただし、現在提案されているソリューションをセクション7から展開できないいくつかの専門のハードウェアプラットフォームがある場合があります。これは、マルチキャストパケットがルーターのバックプレーンに直接複製されている場合があるため、すべての発信インターフェイスがパケットを読み取るようにします。並行して。したがって、これらの発信インターフェイスのサブセットに対してコードポイントを変更することはできず、NRS問題は分岐点で直接解決することはできません。
In this case, there exist several alternative solutions:
この場合、いくつかの代替ソリューションが存在します。
1. As mentioned in section 3.1, if traffic conditioning mechanisms can be applied on the outgoing packets at the individual output interfaces, a combination of classifier and marker may be used for each branch.
1. セクション3.1で述べたように、個々の出力インターフェイスの発信パケットにトラフィックコンディショニングメカニズムを適用できる場合、各ブランチに分類器とマーカーの組み合わせを使用できます。
2. The change of the codepoint for subtrees without properly allocated resources could take place in the following downstream router. There, for every incoming packet of the considered multicast group, the codepoint would be changed to the value that the previous router should have set. If a LAN (e.g., a high-speed switching LAN) is attached to the considered outgoing interface, then on every router connected to the LAN, packets of the considered group should be changed on the incoming interface by standard DiffServ mechanisms.
2. 適切に割り当てられたリソースのないサブツリーのコードポイントの変更は、次の下流ルーターで行われる可能性があります。そこでは、考慮されたマルチキャストグループのすべての着信パケットについて、コードポイントは以前のルーターが設定する値に変更されます。LAN（たとえば、高速スイッチングLAN）が考慮された発信インターフェイスに接続されている場合、LANに接続されたすべてのルーターで、標準的なDiffservメカニズムにより、受信グループのパケットを着信インターフェイスで変更する必要があります。
Future releases of router architectures may support the change of the codepoint directly in the replication process as proposed in section 7.
ルーターアーキテクチャの将来のリリースは、セクション7で提案されているように、複製プロセスのコードポイントの変更を直接サポートする場合があります。
Basically, the security considerations in [1] apply. The proposed solution does not imply new security aspects. If a join of arbitrary end-systems to a multicast group is not desired (thereby receiving a lower than best-effort quality) the application usually has to exclude these participants. This can be accomplished by using authentication, authorization, or ciphering techniques at the application level -- like in traditional IP multicast scenarios.
基本的に、[1]のセキュリティ上の考慮事項が適用されます。提案されたソリューションは、新しいセキュリティの側面を意味するものではありません。マルチキャストグループへの任意の最終システムの結合が望まれない場合（それにより、ベストエフォルトよりも低い品質を受け取る）、アプリケーションは通常、これらの参加者を除外する必要があります。これは、従来のIPマルチキャストシナリオのように、アプリケーションレベルで認証、承認、または暗号化手法を使用することで実現できます。
Moreover, it is important to consider the security of corresponding management mechanisms, because they are used to activate re-marking of multicast flows. On the one hand, functions for instructing the router to mark or re-mark packets of multicast flows are attractive targets to perform theft of service attacks. On the other hand, their security depends on the router management mechanisms which are used to realize this functionality. Router management should generally be protected against unauthorized use, therefore preventing those attacks as well.
さらに、マルチキャストフローの再マルキングをアクティブにするために使用されるため、対応する管理メカニズムのセキュリティを考慮することが重要です。一方では、ルーターにマルチキャストフローのパケットをマークまたは再マークするように指示するための機能は、サービス攻撃の盗難を実行するための魅力的なターゲットです。一方、彼らのセキュリティは、この機能を実現するために使用されるルーター管理メカニズムに依存します。ルーター管理は一般に不正使用から保護されるべきであるため、これらの攻撃も防止する必要があります。
One possibility of implementing the proposed solution from section 3.1 is described in the following. It has to be emphasized that other realizations are also possible, and this description should not be understood as a restriction on potential implementations. The benefit of the following described implementation is that it does not require any additional classification of multicast groups within an aggregate. It serves as a proof of concept that no additional complexity is necessary to implement the proposed general solution described in section 3.
セクション3.1から提案されたソリューションを実装する可能性の1つは、以下で説明されています。他の実現も可能であることを強調する必要があり、この説明は潜在的な実装の制限として理解されるべきではありません。以下の説明された実装の利点は、集計内のマルチキャストグループの追加の分類を必要としないことです。セクション3で説明されている提案された一般的なソリューションを実装するために、追加の複雑さが必要ないという概念の証明として機能します。
Because every multicast flow has to be considered by the multicast routing process (in this context, this notion signifies the multicast forwarding part and not the multicast route calculation and maintenance part, cf. Fig. 1), the addition of an extra byte in each multicast routing table entry containing the DS field, and thus its DS codepoint value per output link (resp. virtual interface, see Fig. 8), results in nearly no additional cost. Packets will be replicated by the multicast forwarding process, so this is also the right place for setting the correct DSCP values of the replicated packets. Their DSCP values are not copied from the incoming original packet, but from the additional DS field in the multicasting routing table entry for the corresponding output link (only the DSCP value must be copied, while the two remaining bits are ignored and are present for simplification reasons only). This field initially contains the codepoint of the LE PHB if incoming packets for this specific group do not carry the codepoint of the default PHB.
すべてのマルチキャストフローは、マルチキャストルーティングプロセスで検討する必要があるため（このコンテキストでは、この概念はマルチキャストの転送部品を意味し、マルチキャストルートの計算とメンテナンスパーツ、図1を参照）、それぞれに追加のバイトを追加することです。DSフィールドを含むマルチキャストルーティングテーブルエントリ、したがって、出力リンクごとのDSコードポイント値（仮想インターフェイス、図8を参照）は、ほぼ追加コストが発生しません。パケットはマルチキャスト転送プロセスによって複製されるため、これは複製されたパケットの正しいDSCP値を設定するのに適した場所でもあります。それらのDSCP値は、着信の元のパケットからコピーされませんが、対応する出力リンクのマルチリキャストルーティングテーブルエントリの追加のDSフィールドからコピーされます（DSCP値のみをコピーする必要がありますが、残りの2つのビットは無視され、単純化のために存在します理由のみ）。このフィールドには、この特定のグループの着信パケットがデフォルトのPHBのコードポイントを運ばない場合、このフィールドには最初にLE PHBのコードポイントが含まれています。
When a packet arrives with the default PHB, the outgoing replicates should also get the same codepoint in order to retain the behavior of current common multicast groups using the default PHB. A router configuration message changes the DSCP values in the multicast routing table and may also carry the new DSCP value which should be set in the replicated packets. It should be noted that although re-marking may also be performed by interior nodes, the forwarding performance will not be decreased, because the decision of when and what to re-mark is made by the management (control plane).
パケットがデフォルトのPHBを使用して到着すると、デフォルトのPHBを使用して現在の一般的なマルチキャストグループの動作を保持するために、発信レプリケートも同じコードポイントを取得する必要があります。ルーター構成メッセージは、マルチキャストルーティングテーブルのDSCP値を変更し、複製されたパケットで設定する必要がある新しいDSCP値を搭載する場合があります。再マークもインテリアノードによって実行される場合がありますが、転送パフォーマンスは低下しません。
Multicast Other List
Destination Fields of
Address virtual Inter- DS
interfaces face ID Field
+--------------------------------+ +-------------------+
| X | .... | *-------------------->| C | (DSCP,CU) |
|--------------------------------| +-------------------+
| Y | .... | *-----------+ | D | (DSCP,CU) |
|--------------------------------| | +-------------------+
| ... | .... | ... | |
. . . . | +-------------------+
. ... . .... . ... . +-------->| B | (DSCP,CU) |
+--------------------------------+ +-------------------+
| ... | .... | ... | | D | (DSCP,CU) |
+--------------------------------+ +-------------------+
| ... | ... |
. . .
. . .
Figure 8: Multicast routing table with additional fields for DSCP values
図8：DSCP値の追加フィールドを備えたマルチキャストルーティングテーブル
In the following, it is shown that the NRS problem actually exists and occurs in reality. Hence, the problem and its solution was investigated using a standard Linux Kernel (v2.4.18) and the Linux-based implementation KIDS [11].
以下では、NRSの問題が実際に存在し、実際に発生することが示されています。したがって、標準のLinuxカーネル（v2.4.18）とLinuxベースの実装Kids [11]を使用して、問題とその解決策を調査しました。
Furthermore, the proposed solution for the NRS problem has been implemented by enhancing the multicast routing table, as well as the multicast routing behavior in the Linux kernel. In the following section, the modifications are briefly described.
さらに、NRS問題の提案されたソリューションは、Linuxカーネルのマルチキャストルーティング動作と同様に、マルチキャストルーティングテーブルを強化することにより実装されています。次のセクションでは、変更について簡単に説明します。
Additional measurements with the simulation model simulatedKIDS [12] will be presented in section 9. They show the effects of the NRS problem in more detail and also the behavior of the BAs using or not using the Limited Effort PHB for re-marking.
シミュレーションモデルシミュレーションKID [12]を使用した追加の測定値は、セクション9で提示されます。それらは、NRS問題の効果をより詳細に示し、また、リマークに限られた努力PHBを使用するか使用しないBASの動作を示します。
As described in section 3.1, the proposed solution for avoiding the NRS Problem is an extension of each routing table entry in every Multicast router by one byte. In the Linux OS, the multicast routing table is implemented by the "Multicast Forwarding Cache (MFC)". The MFC is a hash table consisting of an "mfc-cache"-entry for each combination of the following three parameters: sender's IP address, multicast group address, and incoming interface.
セクション3.1で説明されているように、NRS問題を回避するための提案されたソリューションは、すべてのマルチキャストルーターの各ルーティングテーブルエントリの1バイトで拡張されています。Linux OSでは、マルチキャストルーティングテーブルは「マルチキャスト転送キャッシュ（MFC）」によって実装されています。MFCは、次の3つのパラメーターの組み合わせの各組み合わせの「MFCキャッシュ」エントリで構成されるハッシュテーブルです：送信者のIPアドレス、マルチキャストグループアドレス、および着信インターフェイス。
The routing information in a "mfc-cache"-entry is kept in an array of TTLs for each virtual interface. When the TTL is zero, a packet matching to this "mfc-cache"-entry will not be forwarded on this virtual interface. Otherwise, if the TTL is less than the packet's TTL, the latter will be forwarded on the interface with a decreased TTL.
「MFCキャッシュ」エントリのルーティング情報は、各仮想インターフェイスのTTLの配列に保持されます。TTLがゼロの場合、この「MFC-Cache」エントリに一致するパケットは、この仮想インターフェイスに転送されません。それ以外の場合、TTLがパケットのTTLよりも少ない場合、後者はTTLの減少とともにインターフェイスに転送されます。
In order to set an appropriate codepoint if bandwidth is allocated on an outgoing link, we added a second array of bytes -- similar to the TTL array -- for specifying the codepoint that should be used on a particular virtual interface. The first six bits of the byte contain the DSCP that should be used, and the seventh bit indicates whether the original codepoint in the packet has to be changed to the specified one (=0) or has to be left unchanged (=1). The default entry of the codepoint byte is zero; so initially, all packets will be re-marked to the default DSCP.
帯域幅が発信リンクに割り当てられている場合に適切なコードポイントを設定するために、特定の仮想インターフェイスで使用する必要があるコードポイントを指定するために、TTLアレイと同様の2番目のバイトを追加しました。バイトの最初の6ビットには、使用する必要があるDSCPが含まれており、7番目のビットは、パケット内の元のコードポイントを指定されたもの（= 0）に変更する必要があるか、変更されていない場合（= 1）かどうかを示します。CodePointバイトのデフォルトエントリはゼロです。したがって、最初は、すべてのパケットがデフォルトのDSCPに再マ化されます。
Furthermore, we modified the multicast forwarding code for considering this information while replicating multicast packets. To change an "mfc-cache"-entry we implemented a daemon for exchanging the control information with a management entity (e.g., a bandwidth broker). Currently, the daemon uses a proprietary protocol, but migration to the COPS protocol (RFC 2748) is planned.
さらに、マルチキャストパケットを複製しながら、この情報を検討するためにマルチキャスト転送コードを変更しました。「MFCキャッシュ」を変更するために、管理情報を管理エンティティ（帯域幅のブローカーなど）と交換するためにデーモンを実装しました。現在、デーモンは独自のプロトコルを使用していますが、COPSプロトコル（RFC 2748）への移行が計画されています。
Sender
+---+ FHN: First Hop Node
| S | BN: Boundary Node
+---+
+#
+#
+#
+---+ +--+ +------+
|FHN|++++++++++++|BN|+++++++++++| host |
| |############| |***********| B |
+---+ +--+## +------+
+# #
+# #
+# #
+------+ +------+
|host A| |host C|
+------+ +------+
+++ EF flow (group1) with reservation
### EF flow (group2) with reservation
*** EF flow (group2) without reservation
Figure 8.1: Evaluation of NRS-Problem described in Figure 3
図8.1：図3で説明するNRSの問題の評価
In order to prove case 1 of the NRS problem, as described in section 2.1, the testbed shown in Figure 8.1 was built. It is a reduced version of the network shown in Figure 5 and consists of two DS-capable nodes, an ingress boundary node and an egress boundary node. The absence of interior nodes does not have any effect on to the proof of the described problem.
セクション2.1で説明されているように、NRS問題のケース1を証明するために、図8.1に示すテストベッドが構築されました。これは、図5に示すネットワークの縮小バージョンであり、2つのDS対応ノード、侵入境界ノード、および出口境界ノードで構成されています。内部ノードの欠如は、説明されている問題の証明に影響を与えません。
The testbed is comprised of two Personal Computers (Pentium III at 450 Mhz, 128 MB Ram, 3 network cards Intel eepro100) used as DiffServ nodes, as well as one sender and three receiver systems (also PCs). On the routers, KIDS has been installed and an mrouted (Multicast Routing Daemon) was used to perform multicast routing. The network was completely built of separate 10BaseT Ethernet segments in full-duplex mode. In [11], we evaluated the performance of the software routers and found out that even a PC at 200Mhz had no problem handling up to 10Mbps DS traffic on each link. Therefore, the presented measurements are not a result of performance bottlenecks caused by these software routers.
テストベッドは、2つのパーソナルコンピューター（450 MHzのPentium III、128 MB RAM、3つのネットワークカードIntel EEPRO100）で構成され、DiffServノードとして使用されます。ルーターでは、子供がインストールされ、Mrouted（マルチキャストルーティングデーモン）がマルチキャストルーティングを実行するために使用されました。ネットワークは、全二重モードの個別の10Basetイーサネットセグメントで完全に構築されました。[11]では、ソフトウェアルーターのパフォーマンスを評価し、200MHzのPCでさえ、各リンクで最大10Mbps DSトラフィックを処理するのに問題がないことがわかりました。したがって、提示された測定値は、これらのソフトウェアルーターによって引き起こされるパフォーマンスボトルネックの結果ではありません。
The sender generated two shaped UDP traffic flows of 500kbps (packets of 1.000 byte constant size) each and sent them to multicast group 1 (233.1.1.1) and 2 (233.2.2.2). In both measurements, receiver A had a reservation along the path to the sender for each flow, receiver B had reserved for flow 1, and C for flow 2. Therefore, two static profiles are installed in the ingress boundary node with 500kbps EF bandwidth and a token bucket size of 10.000 bytes for each flow.
送信者は、それぞれ500kbpsの2つの形状のUDPトラフィックフロー（1.000バイト定数のパケット）を生成し、マルチキャストグループ1（233.1.1.1）と2（233.2.2.2）に送信しました。どちらの測定でも、受信機Aは各フローの送信者へのパスに沿って予約し、レシーバーBはフロー1に予約されていました。各フローの10.000バイトのトークンバケットサイズ。
In the egress boundary node, one profile has been installed for the output link to host B and one related for the output link to host C. Each of them permits up to 500kbps Expedited Forwarding, but only the aggregate of Expedited Forwarding traffic carried on the outgoing link is considered.
出力境界ノードでは、ホストBへの出力リンクとホストCへの出力リンクに関連する1つのプロファイルが1つのプロファイルがインストールされています。それぞれが最大500kbpsの迅速な転送を許可しますが、迅速な転送トラフィックの集合体のみが発信リンクが考慮されます。
In measurement 1, the hosts A and B joined to group 1, while A, B, and C joined to group 2. Those joins are using a reservation for the group towards the sender. Only the join of host B to group 2 has no admitted reservation. As described in section 2.1, this will cause the NRS problem (case 1). Metering and policing mechanisms in the egress boundary node throttle down the EF aggregate to the reserved 500kbps, and do not depend on whether or not individual flows have been reserved.
測定1では、ホストAとBがグループ1に参加し、A、B、およびCがグループ2に参加しました。参加者は、グループの予約を送信者に使用しています。グループ2へのホストBの結合のみが認められた予約はありません。セクション2.1で説明されているように、これはNRSの問題を引き起こします（ケース1）。出口境界ノードの計量およびポリシングメカニズムは、EF集計を予約された500kbpsにスロットルし、個々のフローが予約されているかどうかに依存しません。
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 250kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 250kbps| |
+---------+--------+--------+--------+
Figure 8.2: Results of measurement 1 (without the
proposed solution): Average bandwidth of
each flow.
--> Flows of group 1 and 2 on the link to
host B share the reserved aggregate of
group 1.
Figure 8.2 shows the obtained results. Host A and C received their flows without any interference. But host B received data from group 1 with only half of the reserved bandwidth, so one half of the packets have been discarded. Figure 8.2 also shows that receiver B got the total amount of bandwidth for group 1 and 2, that is exactly the reserved 500kbps. Flow 2 got Expedited Forwarding without actually having reserved any bandwidth and additionally violated the guarantee of group 1 on that link.
図8.2は、得られた結果を示しています。ホストAとCは、干渉なしにフローを受け取りました。しかし、ホストBは、予約された帯域幅の半分しかないグループ1からデータを受け取ったため、パケットの半分が破棄されました。図8.2は、レシーバーBがグループ1と2の帯域幅の合計量を獲得したことも示しています。これは、まさに予約された500kbpsです。Flow 2は、実際に帯域幅を確保せずに迅速な転送を受け、さらにそのリンクのグループ1の保証に違反しました。
For measurement 2, the previously presented solution (cf. section 3.1) has been installed in the boundary node. Now, while duplicating the packets, whether the codepoint has to be changed to Best-Effort (or Limited Effort) or whether it can be just duplicated is checked. In this measurement, it changed the codepoint for group 2 on the link to Host B to Best-Effort.
測定2の場合、以前に提示されたソリューション（セクション3.1を参照）が境界ノードにインストールされています。これで、パケットを複製しながら、CodePointをBest-Effort（または限られた努力）に変更する必要があるか、それを複製できるかどうかがチェックされます。この測定では、ホストBへのリンク上のグループ2のコードポイントをBest-Eftortに変更しました。
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 500kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 500kbps| |
+---------+--------+--------+--------+
Figure 8.3: Results of measurement 1 (with the
proposed solution): Average bandwidth of
each flow.
--> Flow of group 1 on the link to host B
gets the reserved bandwidth of group 1.
The flow of group 2 has been re-marked to
Best-Effort.
Results of this measurement are presented in Figure 8.3. Each host received its flows with the reserved bandwidth and without any packet loss. Packets from group 2 are re-marked in the boundary node so that they have been treated as best-effort traffic. In this case, they got the same bandwidth as the Expedited Forwarding flow, and because there was not enough other traffic on the link present, there was no need to discard packets.
この測定の結果を図8.3に示します。各ホストは、パケットの損失なしに、予約された帯域幅でフローを受け取りました。グループ2のパケットは、境界ノードに再マ化されているため、最高のエフォルトトラフィックとして扱われます。この場合、彼らは迅速な転送フローと同じ帯域幅を得ました。また、存在するリンクに他のトラフィックが十分ではなかったため、パケットを破棄する必要はありませんでした。
The above measurements confirm that the Neglected Reservation Subtree problem is to be taken seriously and that the presented solution will solve it.
上記の測定では、無視された予約サブツリーの問題が真剣に受け止められ、提示されたソリューションがそれを解決することを確認します。
This section shows some results from a simulative study which shows the correctness of the proposed solution and the effect of re-marking the responsible flow to Limited Effort. A proof of the NRS problem has also been given in section 8 and in [13]. This section shows the benefit for the default Best Effort traffic when Limited Effort is used for re-marking instead of Best Effort. The results strongly motivate the use of Limited Effort.
このセクションでは、提案された解決策の正確性と、責任ある流れを限られた努力に再装着する効果を示すシミュレーション研究の結果を示しています。NRS問題の証明もセクション8および[13]に示されています。このセクションでは、ベスト努力ではなく再マークに限られた努力が使用されている場合、デフォルトのベストエフェクショントラフィックの利点を示しています。結果は、限られた努力の使用を強く動機付けています。
In the following scenario, the boundary nodes had a link speed of 10 Mpbs and Interior Routers had a link speed of 12 Mbps. In boundary nodes, a 5 Mbps aggregate for EF has been reserved.
次のシナリオでは、境界ノードのリンク速度は10 mpbsで、内部ルーターのリンク速度は12 mbpsでした。境界ノードでは、EFの5 Mbps凝集体が予約されています。
When Limited Effort was used, LE got 10% capacity (0.5Mpbs) from the original BE aggregate and BE 90% (4.5Mbps) of the original BE aggregate capacity. The bandwidth between LE and BE is shared by using WFQ scheduling.
努力が限られている場合、Leは元のBe Gregigateから10％の容量（0.5MPBS）を獲得し、元のBe総容量の90％（4.5Mbps）になりました。LEとBEの間の帯域幅は、WFQスケジューリングを使用して共有されます。
The following topology was used, where Sx is a sender, BRx a boundary node, IRx an interior node, and Dx a destination/receiver.
SXは送信者、BRXが境界ノード、IRXインテリアノード、DXが宛先/レシーバーであるため、次のトポロジが使用されました。
+--+ +--+ +---+ +--+
|S1| |S0| /=|BR5|=====|D0|
+--+ +--+ // +---+ +--+
\\ || //
\\ || //
+--+ \+---+ +---+ +---+ +---+ +--+
|S2|===|BR1|=====|IR1|=====|IR2|======|BR3|=====|D1|
+--+ +---+ /+---+ +---+ +---+ +--+
// \\ +--+
// \\ /=|D2|
+--+ +---+ // \\ // +--+
|S3|===|BR2|=/ +---+/
+--+ +---+ /=|BR4|=\
|| +--+ // +---+ \\ +--+
+--+ |D4|=/ \=|D3|
|S4| +--+ +--+
+--+
Figure 9.1: Simulation Topology
図9.1：シミュレーショントポロジ
The following table shows the flows in the simulation runs, e.g., EF0 is sent from Sender S0 to Destination D0 with a rate of 4 Mbps using an EF reservation.
次の表は、シミュレーションの実行中のフローを示しています。たとえば、EF0は、EF予約を使用して4 Mbpsのレートで送信者S0から宛先D0に送信されます。
In the presented cases (I to IV), different amounts of BE traffic were used to show the effects of Limited Effort in different cases. The intention of these four cases is described after the table.
提示されたケース（I〜IV）では、さまざまな量の交通量を使用して、さまざまなケースでの限られた努力の影響を示しました。これらの4つのケースの意図は、テーブルの後に説明されています。
In all simulation models, EF sources generated constant rate traffic with constant packet sizes using UDP.
すべてのシミュレーションモデルで、EFソースは、UDPを使用して一定のパケットサイズで一定の速度トラフィックを生成しました。
The BE sources also generated constant rate traffic, where BE0 used UDP, and BE1 used TCP as a transport protocol.
BEソースはまた、BE0がUDPを使用し、BE1がTCPを輸送プロトコルとして使用した一定のレートトラフィックも生成しました。
+----+--------+-------+----------+-----------+-----------+---------+
|Flow| Source | Dest. | Case I | Case II | Case III | Case IV |
+----+--------+-------+----------+-----------+-----------+---------+
| EF0| S0 | D0 | 4 Mbps | 4 Mbps | 4 Mbps | 4 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| EF1| S1 | D1 | 2 Mbps | 2 Mbps | 2 Mbps | 2 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| EF2| S2 | D2 | 5 Mbps | 5 Mbps | 5 Mbps | 5 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| BE0| S3 | D3 | 1 Mbps | 2.25 Mbps | 0.75 Mbps |3.75 Mbps|
+----+--------+-------+----------+-----------+-----------+---------+
| BE1| S4 | D4 | 4 Mbps | 2.25 Mbps | 0.75 Mbps |3.75 Mbps|
+----+--------+-------+----------+-----------+-----------+---------+
Table 9.1: Direction, amount and Codepoint of flows in the four simulation cases (case I to IV)
表9.1：4つのシミュレーションケースのフローの方向、量、コードポイント（ケースIからIV）
The four cases (I to IV) used in the simulation runs had the following characteristics:
シミュレーションの実行で使用される4つのケース（I〜IV）には、次の特性がありました。
Case I: In this scenario, the BE sources sent together exactly 5 Mbps, so there is no congestion in the BE queue.
ケースI：このシナリオでは、BEソースが正確に5 Mbpsで送信されるため、beキューに混雑はありません。
Case II: BE is sending less than 5 Mbps, so there is space available in the BE queue for re-marked traffic. BE0 and BE1 are sending together 4.5 Mbps, which is exactly the share of BE when LE is used. So, when multicast packets are re-marked to LE because of the NRS problem, the LE should get 0.5 Mbps and BE 4.5 Mbps, which is still enough for BE0 and BE1. LE should not show a greedy behavior and should not use resources from BE.
ケースII：BEは5 Mbps未満を送信しているため、再マークされたトラフィックのためのキューにはスペースがあります。Be0とBe1は4.5 Mbpsを一緒に送信しています。これは、LEが使用されるときにまさにBEのシェアです。したがって、NRSの問題のためにマルチキャストパケットがLEに再マ化されている場合、LEは0.5 Mbpsを取得し、4.5 Mbpsである必要があります。leは貪欲な行動を示すべきではなく、beからのリソースを使用すべきではありません。
Case III: In this case, BE is very low. BE0 and BE1 use together only 1.5 Mbps. So when LE is used, it should be able to use the unused bandwidth resources from BE.
ケースIII：この場合、BEは非常に低いです。Be0とBe1は一緒に1.5 Mbpsのみを使用します。したがって、LEを使用すると、BEから未使用の帯域幅リソースを使用できるはずです。
Case IV: BE0 and BE1 send together 7.5 Mbps so there is congestion in the BE queue. In this case, LE should get 0.5 Mbps (not more and not less).
ケースIV：be0とbe1は7.5 mbpsを一緒に送信して、be queueに混雑があります。この場合、LEは0.5 Mbpsを取得する必要があります（それ以上ではなく）。
In each scenario, loss rate and throughput of the considered flows and aggregates have been metered.
各シナリオでは、考慮されたフローと凝集体の損失率とスループットが計算されています。
When the branching point of a newly added multicast subtree is located in an interior node, the NRS problem can occur as described in section 2.1 (Case 2).
新しく追加されたマルチキャストサブツリーの分岐点が内部ノードにある場合、セクション2.1（ケース2）で説明されているように、NRSの問題が発生する可能性があります。
In the simulation runs presented in the following four subsections, D3 joins to the multicast group of sender S0 without making any reservation or resource allocation. Consequently, a new branch is added to the existing multicast tree. The branching point issued by the join of D3 is located in IR2. On the link to BR3, no bandwidth was allocated for the new flow (EF0).
次の4つのサブセクションで提示されたシミュレーションの実行では、D3は予約やリソースの割り当てを行うことなく、Sender S0のマルチキャストグループに結合します。その結果、既存のマルチキャストツリーに新しいブランチが追加されます。D3の結合によって発行された分岐点は、IR2にあります。BR3へのリンクでは、新しいフロー（EF0）に帯域幅が割り当てられませんでした。
The metered throughput of flows on the link between IR2 and BR3 in the four different cases is shown in the following four subsections. The situation before the new receiver joins is shown in the second column. The situation after the join without the proposed solution is shown in column three. The fourth column presents the results when the proposed solution of section 3.1 is used and the responsible flow is re-marked to LE.
次の4つのサブセクションには、4つの異なるケースでIR2とBR3の間のリンク上のフローの計量スループットが示されています。新しいレシーバーが参加する前の状況は、2番目の列に表示されます。提案されたソリューションなしの結合後の状況を列3に示します。4番目の列は、セクション3.1の提案されたソリューションが使用され、責任あるフローがLEに再マ化されたときの結果を示します。
9.2.1.1. Case I:
9.2.1.1. ケースI：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.007 Mbps | LE0: 0.504 Mbps |
|achieved| EF1: 2.001 Mbps | EF1: 2.003 Mbps | EF1: 2.000 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.009 Mbps | EF2: 5.000 Mbps |
|put | BE0: 1.000 Mbps | BE0: 0.601 Mbps | BE0: 1.000 Mbps |
| | BE1: 4.000 Mbps | BE1: 0.399 Mbps | BE1: 3.499 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.003 Mbps | EF: 11.019 Mbps | EF: 7.000 Mbps |
|through-| BE: 5.000 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 34.8 % | BE0: 0 % |
| | BE1: 0 % | BE1: 59.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
9.2.1.2. Case II:
9.2.1.2. ケースII：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.003 Mbps | LE0: 0.500 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.005 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.248 Mbps | BE0: 0.941 Mbps | BE0: 2.253 Mbps |
| | BE1: 2.252 Mbps | BE1: 0.069 Mbps | BE1: 2.247 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.002 Mbps | EF: 11.009 Mbps | EF: 7.003 Mbps. |
|through-| BE: 4.500 Mbps | BE: 1.010 Mbps | BE: 4.500 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 58.0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 57.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
9.2.1.3. Case III:
9.2.1.3. ケースIII：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 3.998 Mbps | LE0: 3.502 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.000 Mbps | EF2: 5.002 Mbps | EF2: 5.003 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.572 Mbps | BE0: 0.748 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.429 Mbps | BE1: 0.748 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.000 Mbps | EF: 11.001 Mbps | EF: 7.004 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.001 Mbps | BE: 1.496 Mbps |
|put | LE: --- | LE: --- | LE: 3.502 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 12.5 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 19.7 % | BE0: 0 % |
| | BE1: 0 % | BE1: 32.6 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
9.2.1.4. Case IV:
9.2.1.4. ケースIV：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.001 Mbps | LE0: 0.500 Mbps |
|achieved| EF1: 2.018 Mbps | EF1: 2.000 Mbps | EF1: 2.003 Mbps |
|through-| EF2: 5.005 Mbps | EF2: 5.001 Mbps | EF2: 5.007 Mbps |
|put | BE0: 2.825 Mbps | BE0: 1.000 Mbps | BE0: 3.425 Mbps |
| | BE1: 2.232 Mbps | BE1: --- | BE1: 1.074 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.023 Mbps | EF: 11.002 Mbps | EF: 7.010 Mbps |
|through-| BE: 5.057 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 75.0 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 23.9 % | BE0: 73.3 % | BE0: 0 % |
| | BE1: 41.5 % | BE1: --- | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
NOTE: BE1 has undefined throughput and loss in situation "after join (no re-marking)", because TCP is going into retransmission back-off timer phase and closes the connection after 512 seconds.
注：BE1は、TCPが再送信バックオフタイマーフェーズに入り、512秒後に接続を閉じるため、「結合後（再マークなし）」の状況でスループットと損失を未定義にしています。
When the branching point of a newly added multicast subtree is located in a boundary node, the NRS problem can occur as described in section 2.1 (Case 1).
新しく追加されたマルチキャストサブツリーの分岐点が境界ノードにある場合、セクション2.1（ケース1）で説明されているように、NRSの問題が発生する可能性があります。
In the simulation runs presented in the following four subsections, D3 joins to the multicast group of sender S1 without making any reservation or resource allocation. Consequently, a new branch is added to the existing multicast tree. The branching point issued by the join of D3 is located in BR3. On the link to BR4, no bandwidth was allocated for the new flow (EF1).
次の4つのサブセクションで提示されたシミュレーションの実行では、D3は予約やリソースの割り当てを行うことなく、Sender S1のマルチキャストグループに結合します。その結果、既存のマルチキャストツリーに新しいブランチが追加されます。D3の結合によって発行された分岐点は、BR3にあります。BR4へのリンクでは、新しいフロー（EF1）に帯域幅が割り当てられませんでした。
The metered throughput of the flows on the link between BR3 and BR4 in the four different cases is shown in the following four subsections. The situation before the new receiver joins is shown in the second column. The situation after the join but without the proposed solution is shown in column three. The fourth column presents results when the proposed solution of section 3.1 is used and the responsible flow is re-marked to LE.
次の4つのサブセクションには、4つの異なるケースでBR3とBR4の間のリンク上のフローの計量されたスループットが示されています。新しいレシーバーが参加する前の状況は、2番目の列に表示されます。結合後の状況は、提案されたソリューションがない状況を列3に示します。4番目の列は、セクション3.1の提案されたソリューションが使用され、責任あるフローがLEに再マ化された場合の結果を示します。
9.2.2.1. Case I:
9.2.2.1. ケースI：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.489 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 3.512 Mbps | EF2: 5.002 Mbps |
|put | BE0: 1.000 Mbps | BE0: 1.000 Mbps | BE0: 1.004 Mbps |
| | BE1: 4.000 Mbps | BE1: 4.002 Mbps | BE1: 3.493 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.002 Mbps | EF: 5.001 Mbps | EF: 5.002 Mbps |
|through-| BE: 5.000 Mbps | BE: 5.002 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 25.6 % | LE1: 73.4 % |
|loss | EF2: 0 % | EF2: 29.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
9.2.2.2. Case II:
9.2.2.2. ケースII：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.520 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.003 Mbps | EF2: 3.482 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.249 Mbps | BE0: 2.249 Mbps | BE0: 2.245 Mbps |
| | BE1: 2.252 Mbps | BE1: 2.252 Mbps | BE1: 2.252 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.003 Mbps | EF: 5.002 Mbps | EF: 5.002 Mbps |
|through-| BE: 4.501 Mbps | BE: 4.501 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 24.0 % | LE1: 74.8 % |
|loss | EF2: 0 % | EF2: 30.4 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
9.2.2.3. Case III:
9.2.2.3. ケースIII：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.084 Mbps | LE1: 2.000 Mbps |
|through-| EF2: 5.001 Mbps | EF2: 3.919 Mbps | EF2: 5.000 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.752 Mbps | BE0: 0.750 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.748 Mbps | BE1: 0.750 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.001 Mbps | EF: 5.003 Mbps | EF: 5.000 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.500 Mbps | BE: 1.500 Mbps |
|put | LE: --- | LE: --- | LE: 2.000 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 45.7 % | LE1: 0 % |
|loss | EF2: 0 % | EF2: 21.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
9.2.2.4. Case IV:
9.2.2.4. ケースIV：
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.201 Mbps | LE1: 0.500 Mbps |
|through-| EF2: 5.048 Mbps | EF2: 3.803 Mbps | EF2: 5.004 Mbps |
|put | BE0: 2.638 Mbps | BE0: 2.535 Mbps | BE0: 3.473 Mbps |
| | BE1: 2.379 Mbps | BE1: 2.536 Mbps | BE1: 1.031 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.048 Mbps | EF: 5.004 Mbps | EF: 5.004 Mbps |
|through-| BE: 5.017 Mbps | BE: 5.071 Mbps | BE: 4.504 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 40.0 % | LE1: 68.6 % |
|loss | EF2: 0 % | EF2: 23.0 % | EF2: 0 % |
|rate | BE0: 30.3 % | BE0: 32.1 % | BE0: 0 % |
| | BE1: 33.3 % | BE1: 32.7 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
The authors wish to thank Mark Handley and Bill Fenner for their valuable comments on this document. Special thanks go to Milena Neumann for her extensive efforts in performing the simulations. We would also like to thank the KIDS simulation team [12].
著者は、この文書に関する貴重なコメントをしてくれたマーク・ハンドリーとビル・フェナーに感謝します。シミュレーションを実行するための広範な努力について、ミレナノイマンに感謝します。また、Kids Simulationチーム[12]に感謝したいと思います。
[1] 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.
[1] Nichols、K.、Blake、S.、Baker、F。and D. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[2] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、RFC 2475、1998年12月。
[3] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[3] Nichols、K。およびB. Carpenter、「ドメインの動作ごとの差別化されたサービスの定義とその仕様の規則」、RFC 3086、2001年4月。
[4] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1", RFC 2205, September 1997.
[4] Braden、R.、ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource Reservation Protocol（RSVP） - バージョン1」、RFC 2205、1997年9月。
[5] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[5] Bernet、Y。、「RSVP DCLASSオブジェクトの形式」、RFC 2996、2000年11月。
[6] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[6] Waitzman、D.、Partridge、C。and S. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、RFC 1075、1988年11月。
[7] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, L., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[7] Estrin、D.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、L.、Sharma、P。and L. wei、 "Protocol Independent Multicast-Sparseモード（PIM-SM）：プロトコル仕様」、RFC 2362、1998年6月。
[8] Adams, A., Nicholas, J. and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM) Protocol Specification (Revised)", Work in Progress.
[8] Adams、A.、Nicholas、J。and W. Siadak、「プロトコル独立マルチキャスト - 密度モード（PIM -DM）プロトコル仕様（改訂）」、進行中の作業。
[9] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group" RFC 2597, June 1999.
[9] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」RFC 2597、1999年6月。
[10] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for DiffServ Routers", RFC 3290, May 2002.
[10] Bernet、Y.、Blake、S.、Grossman、D。and A. Smith、「Diffservルーターの非公式管理モデル」、RFC 3290、2002年5月。
[11] R. Bless, K. Wehrle. Evaluation of Differentiated Services using an Implementation under Linux, Proceedings of the Intern. Workshop on Quality of Service (IWQOS'99), London, 1999.
[11] R.祝福、K。ウェール。Linuxの下での実装を使用した差別化されたサービスの評価、インターンの議事録。サービス品質に関するワークショップ（IWQOS'99）、ロンドン、1999年。
[12] K. Wehrle, J. Reber, V. Kahmann. A simulation suite for Internet nodes with the ability to integrate arbitrary Quality of Service behavior, Proceedings of Communication Networks And Distributed Systems Modeling And Simulation Conference (CNDS 2001), Phoenix (AZ), January 2001.
[12] K. Wehrle、J。Reber、V。Kahmann。2001年1月、フェニックス（AZ）、フェニックス（AZ）、任意のサービス行動、および分散システムモデリングおよびシミュレーション会議（CNDS 2001）を統合する機能を備えたインターネットノードのシミュレーションスイート。
[13] R. Bless, K. Wehrle. Group Communication in Differentiated Services Networks, Internet QoS for the Global Computing 2001 (IQ 2001), IEEE International Symposium on Cluster Computing and the Grid, May 2001, Brisbane, Australia, IEEE Press.
[13] R.祝福、K。ウェール。差別化されたサービスネットワークにおけるグループコミュニケーション、グローバルコンピューティング2001（IQ 2001）のインターネットQos、クラスターコンピューティングおよびグリッドに関するIEEE国際シンポジウム、2001年5月、オーストラリア、ブリスベン、IEEEプレス。
[14] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[14] Davie、B.、Charny、A.、Bennett、J.C.R.、Benson、K.、Le Boudec、J.Y.、Courtney、W.、Davari、S.、Firoiu、V.、D。Stiliadis、「迅速な転送PHB（-hop行動） "、RFC 3246、2002年3月。
[15] Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C. and K.K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
[15] Charny、A.、Bennett、J.C.R.、Benson、K.、Le Boudec、J.Y.、Chiu、A.、Courtney、W.、Davari、S.、Firoiu、V.、Kalmanek、C。and K.K.Ramakrishnan、「EF PHBの新しい定義（迅速な転送ごとの行動）の補足情報」、RFC 3247、2002年3月。
[16] Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[16] Bless、R.、Nichols、K。、およびK. Wehrle、「差別化されたサービスのドメインごとの努力（PDB）の低い」、RFC 3662、2003年12月。
Comments and questions related to this document can be addressed to one of the authors listed below.
このドキュメントに関連するコメントと質問は、以下にリストされている著者の1人に宛ててください。
Roland Bless Institute of Telematics Universitaet Karlsruhe (TH) Zirkel 2 76128 Karlsruhe, Germany
Roland Bless Institute of Telematics Universitaet Carlsruhe（Th）Zirkel 2 76128 Karlsruhe、ドイツ
Phone: +49 721 608 6413
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless
Klaus Wehrle University of Tuebingen WSI - Computer Networks and Internet / Protocol Engineering & Distributed Systems Morgenstelle 10c 72076 Tuebingen, Germany
Klaus Wehrle University of Tuebingen WSI-コンピューターネットワークとインターネット /プロトコルエンジニアリング＆分散システムMorgenstelle 10C 72076 Tuebingen、ドイツ
EMail: Klaus.Wehrle@uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~wehrle/
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。