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
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）インターネット協会（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.
この文書では、IPマルチキャストの問題は、RFC 2475での議論（「差別化サービスのアーキテクチャ」）に拡大し、差別化サービス（DS）ネットワークでの使用について説明します。また、これらの問題に対する可能な解決策を提案する可能性のある実装モデルを記述し、シミュレーション結果を示します。
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.
この文書では、IPマルチキャストの問題は、RFC 2475での議論（「差別化サービスのアーキテクチャ」）に拡大し、差別化サービス（DS）ネットワークでの使用について説明します。また、これらの問題に対する可能な解決策を提案する可能性のある実装モデルを記述し、シミュレーション結果を示します。
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マルチキャストと一緒にそれらの「よりよい」サービスを使用することができる（すなわち、ポイント・ツー・マルチポイント又はマルチポイントツーマルチポイント通信）。この事実から出てくる問題は、基本的なDSの転送メカニズムはまた、IPマルチキャストで動作するが、セクション2に記載されており、いくつかの事実は、マルチキャストリソースのプロビジョニングに関連していると考えることがあります。最初からアーキテクチャに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] [5]新しいDS特定予約オブジェクトと共に使用することができます。 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マルチキャストの使用と併せて根本的な問題が発生します。以下のサブセクションでは、この溶液は、IPマルチキャストのようにスケーラブルであり、ユニキャストおよびマルチキャストトラフィックに対して異なるコードポイント値を用いて何リソース分離を必要としない一般的な溶液はセクション3で提案されているこれらの問題を記載しています。
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.
それはマルチキャスト転送テーブルに従って転送及び複製されるときにパケットが転送コア（図1参照）、すなわち、によって処理されるときにIPマルチキャストパケット複製が通常行われます。したがって、DiffServの可能なノードは、[1]すべての複製のIPパケットヘッダ内にDSフィールドの内容をコピーします。したがって、複製パケットは元のパケットとまったく同じDSコードポイント（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に示されており、以下の説明で使用されています。特定のPHBの種類も、割り当てられた帯域幅のシェアどちらが重要です。しかし、互いに対するそれらの相対的な優先度は重要です。
40% 40% 20%
+--------------------+---------------------+------------+
|Expedited Forwarding| Assured Forwarding | Best-Effort|
+--------------------+---------------------+------------+
---------------------------------------------------------->
output link bandwidth
Figure 2: An example bandwidth share of different
behavior aggregates
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は、最高有する中央からAF、およびベストエフォート最低の割り当てスケジューリング優先度ここで、ルータは完全優先キューイングを行うと仮定する。 RFC 3247 [15]のセクション5.1.1に記載したようにEFの実装のために必須ではないけれども、厳密ノンプリエンプティブ優先スケジューラは、一の実装オプションです。均等化キューイング（WFQ）が使用された、記載された効果は、本質的にも、しかし、わずかな違いが生じるであろう。次のシナリオでは、（マルチキャストフローのPHBと比較して）同等またはより低い優先度のPHBは、NRSの問題の影響を受けていることが示されています。
The Neglected Reservation Subtree problem appears in two different cases:
放置された予約のサブツリーの問題は、二つの異なる場合に表示されます。
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：（最初のみ分岐で）新しいサブツリーの分岐点場合は、図2に示すように、前のマルチキャストツリーは、（出力）境界ノードである図3に示すように、追加のマルチキャストフローが現在使用の総量を増加させます影響を受けた出力リンクに対応する行動の集約のためのリソース。合計金額は当初予約量よりも大きくなります。トラフィック集合がトラフィック契約に従ってなるまでこれにより、出口境界ノードでポリシングコンポーネントがパケットをドロップ。パケットをドロップしながら、しかし、ルータは（が見つからないため、フロー分類機能の）責任のフローを識別することができないため、ランダムに彼らが正しく動作フローか属しているかどうか、パケットを破棄します。その結果、もはや適切に確保されたリソースを持つフローの任意のサービス保証はありません。
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：送信者Recv.x：ファーストホップノードBN：境界ノードの場合：インテリアノードは===：###予約済みの帯域幅を持つマルチキャストブランチ：レシーバは、FHN X）予約*なしマルチキャストブランチをEFの帯域幅は、出力リンクに集約EFの集約が責任流れを考慮せずに、帯域幅に制限されます、実際の予約よりも高くなっています。
Figure 3: The NRS Problem (case 1) occurs when Receiver
B joins
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と同じグループに参加するとき、パケットが複製され、このPHBは、EF、EFのPHBのための可能性の排気に割り当てられたリソースの新しいブランチである場合、受信機Aの場合と同じPHBを有する第2のドメインに向けて新たな分岐に沿って転送されます、悪）*が付いているリンクの上に自分のパケットを受信し、他の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コードポイントを有します
+------------------+---------------------+--------------+------+
| 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コードポイントを有します
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は既にマルチキャストグループに参加しており、それに応じてリソースを予約しているものとします。第二ドメインの内部ノードは、すぐに受信機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
===インテリアノード：：###の予約帯域幅を持つマルチキャストブランチ：EFの予約*なしマルチキャスト分岐）帯域幅の集約レシーバのx S：送信者にFHN：最初のホップノード、BN：Recv.x境界ノード、出力リンクは、EFの集約が責任流れを考慮せずに、帯域幅に制限されます、実際の予約よりも高くなっています
Figure 5: Neglected Reservation Subtree problem case 2
after join of receiver C
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への影響は、図3の次の例により例示される。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コードポイントを有します
+------------------+---------------------+--------------+------+
| 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コードポイントを有します
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の結果は、緊急転送のために制限がないことであるが、図1と図6（a）に示します。彼らの帯域幅は、新しい追加のフローによって使用されます。この場合、追加の30％の緊急転送トラフィックは順番に保証転送の集計のために、10％のパケットロスが生じ、ベストエフォートトラフィックから資源を先取り保証転送トラフィック、からの資源を先取りし、BEST-の完全な喪失エフォート型トラフィック。図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メッセージ）を送信できるようになる前に、送信者のPATHメッセージを受信するIPマルチキャストグループに参加する必要があります。このような状況は、例えば、コードポイント0ですべてのPATHメッセージをマークし、落下やで（特別な方法で処理されない場合はこのように、NRS問題を引き起こす可能性がPATHメッセージを受信するためのリンクに参加メッセージを、他のすべてのデータパケットを再マーキングマルチキャストフロー）。
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つの以上の受信機を含みます。差別化サービスによってサポートされる必要があり、非常に重要な特徴は、唯一のベストエフォート型の品質を要求する参加者もそうでない場合は、より良いサービスクラスを利用してグループ通信に参加することができるはずです。異質性のための次のより良いサポートは、グループ内の二つ以上の異なるサービスクラスの同時使用を提供します。物事は異なるサービスクラスではないだけが必要な場合でも、より複雑な取得する傾向があるが、また、特定のサービスクラス内の品質パラメータの異なる値。
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.
さらなる問題は、一貫した方法で異なるサービスクラスとの異種グループをサポートすることです。 1つのサービスは、他に置き換えることができないように、いくつかのサービスが相互に比較することはできないだろうということが可能であり、そして両方のサービスは、このグループ内で同じリンクを介して提供されなければなりません。
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マルチキャストグループ内で、任意の参加者は、送信者としての役割を果たすことができます（実際には、それもこのマルチキャストグループのパケットを受信していない任意のホストすることができます）。また、これはベストエフォート型以外の特定のサービスは、グループ内で使用されている場合に利用可能であるべき重要な機能です。差別化サービスは、概念的には、一方向の文字を持っています。同時送信は、より良いサービスを可能にするかどうしたがって、送信者によって暗示すべてのマルチキャストツリーのために、リソースを個別に予約する必要があります。共有マルチキャスト配信ツリー（例えば、PIM-SMまたはコアベースツリーで）使用される場合にも当てはまります。十分でないリソースが複数の参加者の同時送信可能マルチキャストツリー内のサービスのために予約されている場合は、NRSの問題が再び発生します。同じ引数が、それは正確に一つの送信者がグループにパケットを送信したネットワークにより確保することができないので、いくつかの送信者によって確保されたリソースを共有する半二重の予約に適用されます。したがって、対応するRSVP予約スタイル「ワイルドカードフィルタ」と「共有、明示的なフィルタは、」[4]差別化サービス内でサポートすることができません。サービス統合型アプローチは、すべてのルータが設置予約状態との適合のために各パケットをチェックすることができるので、トラフィックの半二重性を確保することができます。
3. Solutions for Enabling IP-Multicast in Differentiated Services Networks
差別化サービスネットワークにおけるIPマルチキャストを有効にするため3.ソリューション
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）に十分なリソースが存在し得るので、単に再マーキングノードでより積極的にパケットをドロップすることは、十分ではありません。しかし、次のノード内のリソースは、この特定の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).
（例えば出次数1）マルチキャストツリーの他のすべてのノードがいつものようにパケットを複製し、一方、再マーキングパケットのみ、分岐ノードで必要とされます。分岐ノードは、ドメインの内部のノードであってもよいので、再マーキングパケットの概念的フローごとの分類を必要とします。これは、フローごとの状態を回避コアのDiffServの理念に矛盾であると思われるが、IPマルチキャストフローは、ユニキャストフローとは異なります。伝統的な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).
予約要求が処理およびリソース管理機能により、承認された場合は、より良いサービスにのみ提供されます。これは、リソースが実際に新しいブランチで使用される前に、アドミッション制御テストが実行されなければならないことを意味します。入学試験が成功した場合に、再マーキングノードは、再マーキングを停止し、（概念的にプロファイルを削除することにより）再び元のコードポイントを使用するようにリソース管理によって指示されます。
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からの提案のコンセプトは異質の問題の制限されたソリューションを提供します。マルチキャストグループ内の少なくとも二つの異なるサービスクラスが可能であるように受信機は、予約なし限定エフォートサービスを得るために許可されています。すべての受信機がサービスのどのような品質を得ることなく、マルチキャストセッションに参加するため、それが可能です。受信機はちょうど（事前予約なしのグループにスヌープのような）のために支払わなければならない、より良いサービスを要求する前に、マルチキャストグループの内容が十分に面白いかどうかを見たい場合に便利です。
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メッセージを送信する前に、PATHメッセージのリスニングの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.
マルチキャストルーティングテーブル内の追加フィールドは、任意のDSCP値を格納することができるので、理論的には、セクション7で提案されたアプローチはまた、1つのマルチキャストグループ内で二つ以上の異なるサービスをサポートします。しかし、これは別の必須のPHBの中で「最高」PHBは、下流の特定のリンク上で転送されるように選択されるように、の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.
参加者はいつでも任意の追加メカニズムを必要とせずにグループにパケットを送信するためしかし、ベストエフォート型のサービス（デフォルト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値が着信元のパケットからコピーされていないが、残りの2ビットは無視されている間、対応する出力リンクのためのマルチキャストルーティングテーブルエントリに追加DSフィールドから（のみDSCP値は、コピーされなければならず、簡略化のために存在します理由の場合のみ）。この特定のグループの着信パケットにデフォルトの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
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.
シミュレーションモデルsimulatedKIDS [12]と追加の測定は、彼らがより詳細にNRS問題の影響も使用または再マーキングに限定エフォートPHBを使用していないのBAの挙動を示す部9に表示されます。
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）」によって実現されます。送信者のIPアドレス、マルチキャストグループアドレス、着信インタフェース：MFCは、次の3つのパラメータの組み合わせごとに、「MFC-キャッシュ」-entryからなるハッシュ・テーブルです。
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-キャッシュ」-entry内のルーティング情報は、各仮想インターフェースのためのTTLのアレイに保持されます。 TTLがゼロの場合、この「MFC-キャッシュ」-entryへのパケットマッチングは、この仮想インターフェイスに転送されることはありません。 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配列に類似 - - 特定の仮想インタフェース上で使用されるべきコードポイントを特定するための帯域幅が発信リンクに割り当てられている場合、適切なコードポイントを設定するために、我々は、バイトの二番目の配列を追加しました。バイトの第6ビットを使用すべきであるDSCPを含み、第7ビットは、パケットの元のコードポイントが、指定に変更しなければならない（= 0）又は（= 1）のまましなければならないかどうかを示します。コードポイントのバイトのデフォルトのエントリはゼロです。そう、最初は、すべてのパケットは、デフォルトの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-キャッシュ」-entryを変更するために、我々は、管理エンティティ（例えば、帯域幅ブローカー）との間で制御情報を交換するためのデーモンを実施しました。現在、デーモンは独自のプロトコルを使用しますが、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
+++予約なし予約と予約### EFフロー（グループ2）とEFフロー（GROUP1）*** EFフロー（グループ2）
Figure 8.1: Evaluation of NRS-Problem described in
Figure 3
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.
テストベッドは、二つのDiffServノードとして使用されるパーソナルコンピュータ（450 MHzでのPentium III 128 MBのRAM、3ネットワークカードインテルeepro100では）、ならびに1つの送信者三個のレシーバシステム（またPCS）から構成されています。ルータ上で、（マルチキャストルーティングデーモン）KIDSがインストールされていて、マルチキャストルーティング、マルチキャストルーティングを実行するために使用しました。ネットワークは、完全に全二重モードで別の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（1.000バイト一定サイズのパケット）各二成形UDPトラフィックフローを生成し、マルチキャストグループ1にそれらを送信し（233.1.1.1）と2（233.2.2.2）。両方の測定では、受信機Aは、したがって、2つの静的プロファイルは、最高500kbpsのEF帯域幅を有する入口境界ノードでフロー2のフローごとに、送信者へのパスに沿って予約、Bは、フロー1のために予約していた受信機、及びCインストールされていたと各フローのための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.
出口境界ノードでは、1つのプロファイルは、Bおよびそれらのそれぞれは、最高500kbps緊急転送まで可能C.をホストするために、出力リンクに関連する1つをホストする出力リンク用にインストールされていますが、緊急転送トラフィックの唯一の集合体は、上で搬送します発信リンクが考慮されます。
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.
A、B、及びCは、それらが送信者に向かってグループの予約を使用している参加グループ2に参加しながら、測定1において、ホストA及びBは、グループ1に参加しました。グループ2に、ホストBの参加のみなし入院予約を持っていません。セクション2.1で説明したように、これはNRS問題（ケース1）を引き起こすであろう。計量および予約最高500kbpsにEF集合ダウン出口境界ノードスロットルにおけるポリシングメカニズムは、個々のフローが予約されているか否かに依存しません。
+--------+--------+--------+
| 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はまた、それが正確に予約最高500kbpsであり、受信機Bがグループ1および2のための帯域幅の総量を得たことを示しています。フロー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）境界ノードにインストールされています。さて、コードポイントは、ベストエフォート（または限定エフォート）またはそれだけでチェックされている複製することができるかどうかを変更する必要があるかどうか、パケットを複製しながら。この測定では、ベストエフォートにホストBにリンク上でグループ2のためのコードポイントを変更しました。
+--------+--------+--------+
| 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総容量の原稿から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の）では、BEトラフィックの異なる量が異なる場合に限定努力の効果を示すために使用されました。これら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例（IVへI）は、次のような特徴を持っていました：
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は：未満5 Mbpsのを送信しているBEので、再マークされたトラフィックのためのBEキューの空きスペースがあります。 BE0とBE1は一緒LEを使用する場合、正確にBEのシェアで4.5 Mbpsのを、送信しています。だから、マルチキャストパケットが原因NRSの問題のLEに再マークされている場合、LEは0.5 Mbpsのを取得し、まだBE0とBE1のために十分である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：BEキュー内の輻輳があるので、BE0とBE1が一緒に7.5 Mbpsのを送信します。この場合、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は、任意の予約やリソース割り当てを行うことなく、送信者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.
四つの異なる場合においてIR2とBR3との間のリンク上のフローの計量されたスループットは、次の4つのサブセクションに示されています。新しい受信機が参加する前に状況が2番目の列に示されています。提案された解決策なしで加入後の状況は、3列目に示されています。セクション3.1の提案された解決策が使用され、責任流れがLEに再マークされているときに第4列は結果を示します。
+--------+-----------------+-----------------+------------------+
| | 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
+--------+-----------------+-----------------+------------------+
| | 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
+--------+-----------------+-----------------+------------------+
| | 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
+--------+-----------------+-----------------+------------------+
| | 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.
注：TCPが再送バックオフタイマー段階に入ると、512秒後に接続を閉じているのでBE1は、「後（無再マーキングなし）参加する」状況でスループットと損失を未定義ました。
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は、任意の予約やリソース割り当てを行うことなく、送信者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.
四つの異なる場合においてBR3とBR4との間のリンク上のフローの計量されたスループットは、次の4つのサブセクションに示されています。新しい受信機が参加する前に状況が2番目の列に示されています。参加した後しかし、提案されたソリューションは、カラム3に示されているなしの状況。セクション3.1の提案された解決策が使用され、責任流れがLEに再マークされているときに第4列は結果を示します。
+--------+-----------------+-----------------+------------------+
| | 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
+--------+-----------------+-----------------+------------------+
| | 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
+--------+-----------------+-----------------+------------------+
| | 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
+--------+-----------------+-----------------+------------------+
| | 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シミュレーションチーム[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]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.ブラック、 "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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、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]ニコルズ、K.とB.大工、「自分仕様のための差別化サービスドメイン単位の行動とルールの定義」、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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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.、ヤマウズラ、C。およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、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.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、L.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード（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]アダムス、A.、ニコラス、J.およびW. Siadak、 "プロトコル独立マルチキャスト - デンスモード（PIM-DM）（改訂）プロトコル仕様"、ProgressのWork。
[9] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group" RFC 2597, June 1999.
[9] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ" 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.、ブレイク、S.、グロスマン、D.とA.スミス、 "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. Wehrleのブレス。 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。サービスの動作の任意の品質を統合する能力を持つインターネットノードのシミュレーションスイート、通信ネットワークの議事分散システムのモデリングとシミュレーション会議（CNDS 2001）、フェニックス（AZ）、2001年1月。
[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. Wehrleのブレス。差別化サービスネットワークにおけるグループ通信、インターネットQoSのグローバル・コンピューティング2001（IQ 2001）のために、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]デイビー、B.、Charny、A.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、コートニー、W.、Davari、S.、Firoiu、V.およびD. Stiliadis、「緊急転送PHB（ホップ単位動作）」、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.、ベネット、J.C.R.、ベンソン、K.、ルBoudec、J.Y.、チウ、A.、コートニー、W.、Davari、S.、Firoiu、V.、Kalmanek、C.およびK.K.ラマクリシュナン、「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.
、RFC 3662、2003年12月 "微分されたサービスのために下位エフォート当たりドメイン行動（PDB）" [16]ブレス、R.、ニコルズ、K.及びK. Wehrleの、。
Comments and questions related to this document can be addressed to one of the authors listed below.
このドキュメントに関連するコメントや質問は、下記の著者の一人に対処することができます。
Roland Bless Institute of Telematics Universitaet Karlsruhe (TH) Zirkel 2 76128 Karlsruhe, Germany
ローランドは、カールスルーエのテレマティクス大学（TH）Zirkel 2 76128カールスルーエ、ドイツの研究所を祝福します
Phone: +49 721 608 6413 EMail: bless@tm.uka.de URI: http://www.tm.uka.de/~bless
電話：+49 721 608 6413 Eメール：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
チュービンゲン、ドイツ72076コンピュータネットワークとインターネット/プロトコル・エンジニアリング＆分散システムMorgenstelle 10C - チュービンゲンWSIのクラウスWehrleの大学
EMail: Klaus.Wehrle@uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/~wehrle/
電子メール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。