RFC3754 日本語訳
3754 IP Multicast in Differentiated Services (DS) Networks. R. Bless,K. Wehrle. April 2004. (Format: TXT=86533 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Bless
Request for Comments: 3754 Univ. of Karlsruhe
Category: Informational K. Wehrle
Univ. of Tuebingen
April 2004
作業部会R.をネットワークでつないでください。コメントを求める要求を祝福してください: 3754年のカールスルーエカテゴリの大学: Tuebingen2004年4月の情報のK.ウェールレ大学
IP Multicast in Differentiated Services (DS) Networks
微分されたサービス(DS)ネットワークにおけるIPマルチキャスト
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
このドキュメントはDifferentiated Services(DS)ネットワークにおけるIP Multicast使用の問題について議論します、RFC2475(「微分されたサービスの構造」)で議論について詳述して。 それは、また、これらの問題の可能な解決を示して、潜在的実現モデルについて説明して、シミュレーションの結果を提示します。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 微分されたサービスの管理。 . . . . . . . . . 2 2. DSドメイン. . . . . . . . . . . . 3 2.1のIPマルチキャストの問題。 予約下位木問題(NRS問題)を無視しました。 . . 4 2.2. 種々雑多なマルチキャストグループ. . . . . . . . . . . . . 12 2.3。 力学、いくらか、-、ソース、マルチキャスト. . . . . . . . . . . . 13 3 微分されたサービスネットワークでIP-マルチキャストを可能にするためのソリューション。 . . . . . . . . . . . . . . . . . . . . . . 13 3.1. NRS問題. . . . . . . . . . . . . . 13 3.2のためのソリューション。 種々雑多なマルチキャストグループ. 15 3.3を支持するためのソリューション。 ソリューション、いくらか、-、ソース、マルチキャスト。 . . . . . . . . . . . 16 4. スケーラビリティ問題. . . . . . . . . . . . . . . . . . 16 5。 展開問題。 . . . . . . . . . . . . . . . . . . 17 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 18 7. 実現モデルの例. . . . . . . . . . . . . . . . . 18 8。 無視された予約下位木問題. . . . . . 19 8.1の証拠。 提案されたソリューションの実現。 . . . . . . . . 20 8.2. 環境と実行. . . . . . . . . . . . . 21 9をテストしてください。 NRS問題と株式会社努力PHB. . 23のまねた研究
Bless & Wehrle Informational [Page 1] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[1ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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
9.1. シミュレーションシナリオ。 . . . . . . . . . . . . . . . . . . 24 9.2. 異なったルータタイプのためのシミュレーションの結果。 . . . . . 26 10. 承認. . . . . . . . . . . . . . . . . . . . . . . 31 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1。 引用規格. . . . . . . . . . . . . . . . . . 31 11.2。 有益な参照. . . . . . . . . . . . . . . . . 31 12。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 33 13。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 34
1. Introduction
1. 序論
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.
このドキュメントはDifferentiated Services(DS)ネットワークにおけるIP Multicast使用の問題について議論します、RFC2475(「微分されたサービスの構造」)で議論について詳述して。 それは、また、これらの問題の可能な解決を示して、潜在的実現モデルについて説明して、シミュレーションの結果を提示します。
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 Architecture[2]では、スケーラビリティは、コアノードにおける、1流れあたりの州の情報の複雑さと維持を避けて、ネットワーク縁に避けられない複雑さを押すことによって、達成されます。 したがって、同じサービスに属す個々の流れが集められます、その結果、複雑な分類の必要性を排除するか、または内部のノードで1流れあたりの州の情報を管理して。
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 Multicast(多点からすなわち、ポイントツーマルチポイントかマルチポイント通信)と共にそれらの「より良い」サービスを利用するのは、より複雑になります。 この事実から出て来ることにおける問題はセクション2で説明されます。 また、基本的なDS推進メカニズムはIP Multicastと共に動作しますが、いくつかの事実が考えられなければなりません(マルチキャストリソースの食糧を供給するのに関連します)。 始めからIP Multicastの機能性を構造と統合して、既に獲得された利点を破らないそれらの問題の簡単な解決法を提供するのは重要です。
1.1. Management of Differentiated Services
1.1. 微分されたサービスの管理
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.
少なくともPer-ドメインBehaviorsとEF PHBに基づくサービスにおいて、入場コントロールと資源予約が必要です[14、15]。 境界ノードにおける、交通プロフィールのインストールとアップデートが必要です。 ほとんどのネットワーク管理者は長期サービスレベル協定(SLA)のためにさえ手動でこのタスクを達成できません。 その上、オンデマンドのサービスを提供するのはある種のシグナリングと自動入場コントロール手順を必要とします。
Bless & Wehrle Informational [Page 2] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[2ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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.
Differentiated Services Domainに予約の要請に合図するためのプロトコルが必要です。 エンドシステムシグナリングをDSドメインに達成するために、RSVP[4]は新しいDS特定の予約物[5]と共に使用されるかもしれません。 RSVPはマルチキャストシナリオのサポートを提供して、多くのシステムによって既に支持されます。しかしながら、DiffServマルチキャスト文脈における、RSVPのアプリケーションはまた、次のセクションで説明される問題を引き起こすかもしれません。 NSIS作業部会は現在、異なった振舞いを示しているかもしれない新しいシグナリングプロトコルを定義していますが、WGはマルチキャスト流れよりユニキャスト流れに現在の焦点を持っています。
2. Problems of IP Multicast in DS Domains
2. DSドメインのIPマルチキャストの問題
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.
Differentiated Servicesをマルチキャストに提供する潜在的な問題と複雑さは別々のセクションの[2]で考えられますが、詳細によりすばらしい両方の局面について議論しなければなりません。 DiffServ ArchitectureとそのDSノード種別の簡単さが高いスケーラビリティに達するのに必要ですが、それはまた、DSドメインでのIP Multicastの使用に関連して基本的な問題を引き起こします。 以下の小区分は一般的な解決策がセクション3で提案されるこれらの問題について説明します。 この解決策は、IP Multicastと同じくらいスケーラブルであり、ユニキャストとマルチキャスト交通に異なったcodepoint値を使用することによって、リソース分離を全く必要としません。
Because Differentiated Services are unidirectional by definition, the point-to-multipoint communication is also considered as unidirectional. In traditional IP Multicast, any node can send packets spontaneously and asynchronously to a multicast group specified by their multicast group address, i.e., traditional IP Multicast offers a multipoint-to-multipoint service, also referred to as Any-Source Multicast. Implications of this feature are discussed in section 2.3.
Differentiated Servicesが定義上単方向ので、また、ポイントツーマルチポイントコミュニケーションは単方向と考えられます。 伝統的なIP Multicastでは、どんなノードもそれらのマルチキャストグループアドレスによって指定されたマルチキャストグループにパケットを自然に、そして非同期に送ることができます、すなわち、伝統的なIP Multicastは多点から多点に対するまた、Any-ソースMulticastと呼ばれたサービスを提供します。 セクション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
その後の問題のために、別の方法で述べられない場合、私たちは少なくとも送付者が「伝統的なデフォルトPHBより良い」Perホップ振舞いを経験するパケットを発生させる単方向のポイントツーマルチポイントコミュニケーションシナリオを仮定しません、デフォルトより良質にベストエフォート型サービスのサービスをもたらして。 in order to
Bless & Wehrle Informational [Page 3] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[3ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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.
これ(仕様が送付者の最初のDSできる境界ノードにインストールされるために持っている交通調節に対応する交通プロフィール)を達成してください。 その上、対応するリソースが経路で送付者からすべての受信機まで利用可能であることを保証しなければなりません、ことによるとかかわったドメイン境界で交通プロフィールの適合を必要として。 そのうえ、オンデマンドの資源予約は受信機によって開始されているかもしれません。
2.1. Neglected Reservation Subtree Problem (NRS Problem)
2.1. 無視された予約下位木問題(NRS問題)
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.
彼らが使用されている前に通常、Differentiated Servicesのためのリソースを予約しなければなりません。 しかし、マルチキャストシナリオでは、グループ会員資格はしばしば非常にダイナミックです、その結果、あらかじめ、送付者の開始している資源予約の使用を制限します。 残念ながら、リソースが使用の前に明らかに予約されなかったなら、Differentiated Servicesを使用するマルチキャストグループの新しいメンバーのダイナミックな追加は他の既存の交通に悪影響を与えることができます。 セクション8でこの問題の実用的な証拠を与えます。
IP Multicast packet replication usually takes place when the packet is handled by the forwarding core (cf. Fig. 1), i.e., when it is forwarded and replicated according to the multicast forwarding table. Thus, a DiffServ capable node would also copy the content of the DS field [1] into the IP packet header of every replicate. Consequently, replicated packets get exactly the same DS codepoint (DSCP) as the original packet, and therefore experience the same forwarding treatment as the incoming packets of this multicast group. This is also illustrated in Fig. 1, where each egress interface comprises functions for (BA-) classification, traffic conditioning (TC), and queueing.
パケットが推進コアによって扱われるとき、通常、IP Multicastパケット模写は行われます。(Cf。 図1), すなわち、マルチキャスト推進テーブルに従って、それが進められて、模写されるとき。 その結果、また、DiffServのできるノードがIPパケットのヘッダーへのDS分野[1]の内容をコピーするだろう、あらゆる、模写してください。 その結果、模写されたパケットは、まさにオリジナルのパケットと同じDS codepoint(DSCP)を手に入れて、したがって、このマルチキャストの入って来るパケットが分類されるので処理を進めながら、同じくらい経験します。 また、これは図1で例証されます。そこでは、それぞれの出口のインタフェースが(BA)分類、交通調節(TC)、および待ち行列のために機能を包括します。
Interface A IP Forwarding Interface B
+-----------+ +--------------+ +-----------+
MC-flow | | | replication | | egress |
---->| ingress |---->|------+-------|----->|(class.,TC,|---->
| | | | | | queueing) |
+-----------+ | | | +-----------+
| | |
| | | Interface C
| | | +-----------+
| | | | egress |
| +-------|----->|(class.,TC,|---->
| | | queueing) |
+--------------+ +-----------+
IP推進インタフェースB+を連結してください。-----------+ +--------------+ +-----------+ 流動M.C.| | | 模写| | 出口| ---->| イングレス|、-、-、--、>|、-、-、-、-、--+-------|、-、-、-、--、>|(クラス、TC、|、-、-、--、>| | | | | | 待ち行列、) | +-----------+ | | | +-----------+ | | | | | | インタフェースC| | | +-----------+ | | | | 出口| | +-------|、-、-、-、--、>|(クラス、TC、|、-、-、--、>| | | 待ち行列、) | +--------------+ +-----------+
Figure 1: Multicast packet replication in a DS node
図1: DSノードにおけるマルチキャストパケット模写
Bless & Wehrle Informational [Page 4] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[4ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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 Multicastグループに加わるとき、マルチキャストルーティングは議定書を作ります。(例えば、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.
マルチキャスト木の新しい部分によって消費される追加量のリソースがドメイン資源管理(Cfセクション1.1)によって考慮に入れられないと、他の受信機(正しい予約がある)の現在提供されたサービスの質は、悪く影響を受けるか、または違反さえされるでしょう。 あらゆる情勢のもとでNeglected予約Subtree Problemとして指定された以下(NRS Problem)の無視された資源予約による既存の交通契約へのこのマイナスの効果を避けなければなりません。 ドメイン境界の強い入場コントロール方針は、この問題を防ぐのを助けないでしょう、承認しがたくリソースを消費する新しい流れがドメインの中で起源を発するので。
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 Problemの2つの主要なケースを区別できます。 彼らは、異なった振舞いが分岐ポイントの位置によるのを示します。 それらの異なった効果を比較するために、帯域幅のシェアの安易な例は、図2で例証されて、以下の説明で使用されます。 特定のPHBタイプも彼らの割り当てられた帯域幅シェアも重要ではありません。 しかしながら、互いに関するそれらの相対的な優先権は重要です。
40% 40% 20%
+--------------------+---------------------+------------+
|Expedited Forwarding| Assured Forwarding | Best-Effort|
+--------------------+---------------------+------------+
---------------------------------------------------------->
output link bandwidth
40% 40% 20% +--------------------+---------------------+------------+ |完全優先転送| 相対的優先転送| ベストエフォート型| +--------------------+---------------------+------------+ ---------------------------------------------------------->出力リンク帯域幅
Figure 2: An example bandwidth share of different
behavior aggregates
図2: 異なった振舞い集合の例の帯域幅シェア
Bless & Wehrle Informational [Page 5] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[5ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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つの振舞い集合による)で考えられた出力リンクの帯域幅は共有されます: Forwarding、Assured Forwarding、および伝統的なBest-努力サービスを速めました。 この例では、私たちは、ルータが優先権の計画をする最も低いのが割り当てたAFの厳しい優先権待ち行列、EFがどこに最も高いのを持っているか、そして、中央、およびBest-努力を実行すると思います。 EF実現に義務的ではありませんが、厳しい非割込み型優先度スケジューラは.1セクション5.1RFC3247[15]で説明されるように1つの実現オプションです。 また、しかし、Weighted Fair Queueing(WFQ)が使用されることになっているなら、説明された効果は小異で本質的には起こるでしょうに。 以下のシナリオでは、等しいか下側の優先度(マルチキャスト流動のPHBとの比較における)のPHBsがNRS問題で影響を受けるのが例証されます。
The Neglected Reservation Subtree problem appears in two different cases:
Neglected予約Subtree問題は2つの異なった場合に現れます:
o Case 1: If the branching point of the new subtree (at first only a
branch) and the previous multicast tree is a (egress) boundary
node, as shown in Fig. 3, the additional multicast flow now
increases the total amount of used resources for the corresponding
behavior aggregate on the affected output link. The total amount
will be greater than the originally reserved amount.
Consequently, the policing component in the egress boundary node
drops packets until the traffic aggregate is in accordance with
the traffic contract. But while dropping packets, the router can
not identify the responsible flow (because of missing flow
classification functionality), and thus randomly discards packets,
whether they belong to a correctly behaving flow or not. As a
result, there will no longer be any service guarantee for the
flows with properly reserved resources.
o ケース1: 新しい下位木(最初に、唯一のブランチ)と前のマルチキャスト木の分岐ポイントが図3に示されるように(出口)境界ノードであるなら、追加マルチキャスト流動は今、影響を受ける出力リンクの上の対応する振舞い集合のための中古のリソースの総量を増加させます。 総量は元々予約された量よりさらにすばらしくなるでしょう。 その結果、交通集合が交通契約通りにあるまで、出口境界ノードの取り締まりコンポーネントはパケットを落とします。 しかし、ルータは、パケットを落としている間、原因となる流れ(なくなった流れ分類の機能性による)を特定できないで、その結果、手当たりしだいにパケットを捨てます、それらが正しく振る舞っている流れに属すか否かに関係なく。 その結果、もう、適切に予約されたリソースがある流れのためのどんなサービス保証もあるでしょう。
Bless & Wehrle Informational [Page 6] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[6ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ *) +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|###########|BN|####|IN|######|BN|####|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . \ .
. +--+ +--+ . \\ . \ .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A|
.+--+ +--+. +------+
|BN|........|BN|
+--+ +--+
||
送付者+---+ | S| DSドメイン+---+ / \ .||............... / \ ................ . || . <->…|| . . . . +---+ +--+ +--+ *) +--+ +--+ +--+ +------+ . |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: 受信機x FHN: 最初に、ノードBNを飛び越してください: 以下の境界ノード 内部のノード===: 予約された帯域幅###があるマルチキャストブランチ: 予約*のないマルチキャストブランチ) 出力リンクの上に集められたEFの帯域幅が実際の予約より高い、原因となる流れを考えないで、EF集合は帯域幅で制限されるでしょう。
Figure 3: The NRS Problem (case 1) occurs when Receiver
B joins
図3: Receiver Bが接合するとき、NRS Problem(ケース1)は起こります。
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に予約されて、対応する著しいパケットによって使用されます。 いつ、*で示されるリンクの上に彼らのパケットを受ける他のEFユーザに悪影響を与える受信機A、パケットが同じグループですが、新しい支店に沿って同じPHBがある2番目のドメインに向かって模写して、送って、BがこのPHBがEF、ことによると排気がEF PHBのためのリソースを割り当てた受信機A.Ifに関する新しいブランチであるので接合する受信機) 通常、BNは、次のドメインへの外向的な交通集合が同意された交通調節仕様に従っているのを確実にします。 したがって、出口BNはマルチキャスト流動に使用されるPHBタイプのパケットを落とすでしょう。
Bless & Wehrle Informational [Page 7] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[7ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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.
下側の、または、より高い優先度の他のPHBsはこの場合悪く影響を受けません。 図4の以下の例は2PHBsのためにこれを例証します。
+------------------+---------------------+--------------+------+ | 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! | | | +------------------+---------------------+--------------+------+
+------------------+---------------------+--------------+------+ | Forwを速めました。 | Forwを速めました。 | 確実なForw、|| | | | | | | 予約で| 余分な流れ| reservで。 | | | | 遠慮なく| | | +------------------+---------------------+--------------+------+ | 予約のあるなしにかかわらずEFは共有します。| 40 % | 20% | | 40%の予約されたEFは集めます。 | | | | -そして予約がある>EFパケット。| | | | 遠慮なく、あるでしょう。| | | | 捨てられる! | | | +------------------+---------------------+--------------+------+
(a) Excess flow has EF codepoint
(a)過剰流動には、EF codepointがあります。
+------------------+---------------------+--------------+------+ | Expedited Forw. | Assured Forwarding | Assured Forw.| BE | | | | | | | with reservation | excess flow | with reserv. | | | | without reservation | | | +------------------+---------------------+--------------+------+ | | AF with & without reservation share| 20 % | | | 40% of reserved EF aggregate. | | | 40% | -> EF packets with reservation and | | | | without reservation will be | | | | discarded! | | +------------------+---------------------+--------------+------+
+------------------+---------------------+--------------+------+ | Forwを速めました。 | 相対的優先転送| 確実なForw、|| | | | | | | 予約で| 余分な流れ| reservで。 | | | | 遠慮なく| | | +------------------+---------------------+--------------+------+ | | 予約と予約のないAFは共有します。| 20 % | | | 40%の予約されたEFは集めます。 | | | 40% | -そして予約がある>EFパケット。| | | | 遠慮なく、あるでしょう。| | | | 捨てられる! | | +------------------+---------------------+--------------+------+
(b) Excess flow has AF codepoint
(b)過剰流動には、AF codepointがあります。
Figure 4: Resulting share of bandwidth in a egress
boundary node with a neglected reservation of
(a) an Expedited Forwarding flow or (b) an
Assured Forwarding flow.
図4: 出口境界ノードにおける(a) Expedited Forwarding流動か(b) Assured Forwarding流動の無視された予約がある帯域幅の結果として起こるシェア。
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
図4は、(a)がいつForwardingがNRS Problemを引き起こす追加マルチキャストブランチによって使用されることが保証されたForwardingと(b)を速めたかを場合における帯域幅の結果として起こるシェアに示します。 追加交通がリンク帯域幅のもう30%を使用すると仮定して、図4(a)は、Expedited Forwarding(外向的なリンク帯域幅の70%)の結果として起こる集合が元々予約された40%まで阻止されるのを例証します。 この場合、低下しているEF帯域幅の量は余分な帯域幅の量と等しいです。 その結果オリジナルのExpedited Forwarding
Bless & Wehrle Informational [Page 8] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[8ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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.
また、集合(リンク帯域幅の40%を予約させた)はパケット損失で影響を受けます。 他のサービス(例えば、Assured ForwardingかBest-努力)は、不都合ではありません。
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)はAssured Forwardingのために同じ状況を示しています。 唯一の違いは現在Assured Forwardingが破棄で唯一影響を受けるということです、それでも、他のサービスが彼らの保証を得るとき。 どちらの場合ではも、パケット損失は、交通メーターによってふらちな事をしているサービスのクラスに制限されて、境界ノードでメカニズムを取り締まっています。 そのうえ、Differentiated Servicesドメインを出る交通が以下のイングレス境界ノードにすぎないことを確実にするのに彼らが原因となるので(ケース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に示されるように)、Neglected予約Subtree問題は起こることができます。 図5では、受信機AとBが既にマルチキャストグループに加わって、それに従って、リソースを予約したと思われます。 受信機Cが接合するとすぐに、2番目のドメインの内部のノードはマルチキャストパケットの模写を始めます。 ルータは機能を計量するか、または取り締まるのを備えていないので、それは、どんな量の余分な交通も認識しないで、新しいマルチキャスト流動を進めるでしょう。 後者がExpedited Forwardingなどの、より高い優先サービスに属すと、集合の帯域幅は、新しい支店では、集合の予約より高く、低優先度サービスから帯域幅を使用するでしょう。
Bless & Wehrle Informational [Page 9] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[9ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|===========|BN|====|IN|======|BN|===|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . # .
. +--+ +--+ . \\ . # *) .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A| #
.+--+ +--+. +------+ #
|BN|........|BN| +------+
+--+ +--+ |Recv.C|
|| +------+
送付者+---+ | S| DSドメイン+---+ / \ .||............... / \ ................ . || . <->…|| . . . . +---+ +--+ +--+ +--+ +--+ +--+ +------+ . |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
FHN: 最初に、ノード、BNを飛び越してください: 境界ノード、Recv.x: 受信機x S: 以下の送付者 内部のノード===: 予約された帯域幅###があるマルチキャストブランチ: 予約*のないマルチキャストブランチ) 出力リンクの上に集められたEFの帯域幅が実際の予約より高い、原因となる流れを考えないで、EF集合は帯域幅で制限されるでしょう。
Figure 5: Neglected Reservation Subtree problem case 2
after join of receiver C
図5: Subtree問題が2をケースに入れる無視された予約は受信機Cを接合します。
Bless & Wehrle Informational [Page 10] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[10ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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の追加量を進めます。 結果として起こる集合が出力リンク帯域幅ほど高くない限り、これはExpedited Forwardingのためのパケット損失を全くもたらしません。 より高い優先度のために、Expedited Forwardingは同じくらい必要で同じくらいそのままな同じくらい多くの帯域幅が利用可能です。 他のPHBsへの効果は図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.
+------------------+---------------------+--------------+------+ | Forwを速めました。 | Forwを速めました。 | 確実なForw、|| | | | | | | 予約で| 余分な流れ| reservで。 | | | | 遠慮なく| | | +------------------+---------------------+--------------+------+ | 40% | 30% | 30% | 0% | +------------------+---------------------+--------------+------予約のあるなしにかかわらずEFには最優先があるので、+ 予約があるEFと余分な流れはリンク帯域幅の70%を一緒に使用します。
(a) Excess flow has EF codepoint
(a)過剰流動には、EF codepointがあります。
+------------------+---------------------+--------------+------+
| Expedited Forw. | Assured Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| 40% | 60% | 0% |
| | (10% loss) | |
+------------------+---------------------+--------------+------+
AF with reservation and the excess flow use together 60%
of the link bandwidth because EF has the highest priority
(-> 40%). 10% of AF packets will be lost.
+------------------+---------------------+--------------+------+ | Forwを速めました。 | 確実なForw。 | 確実なForw、|| | | | | | | 予約で| 余分な流れ| reservで。 | | | | 遠慮なく| | | +------------------+---------------------+--------------+------+ | 40% | 60% | 0% | | | (10%の損失) | | +------------------+---------------------+--------------+------EFには最優先(->40%)があるので、+ 予約があるAFと余分な流れはリンク帯域幅の60%を一緒に使用します。 10%のAFパケットは失われるでしょう。
(b) Excess flow has AF codepoint
(b)過剰流動には、AF codepointがあります。
Figure 6: Resulting share of bandwidth in an interior
node with a neglected reservation of (a) an
Expedited Forwarding flow or (b) an Assured
Forwarding flow
図6: 内部のノードにおける(a) Expedited Forwarding流動か(b) Assured Forwarding流動の無視された予約がある帯域幅の結果として起こるシェア
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
ケース2の結果はExpedited Forwardingのための制限が全くないということですが、図6(a)が示すように、他のサービスは非予約されたリソースのこの使用で非常に不都合になるでしょう。 それらの帯域幅は新しい追加流れによって使用されます。 この場合30%の追加Expedited Forwarding交通がAssured Forwarding交通からリソースを先取りする、どれ、順番に、先取りするか。
Bless & Wehrle Informational [Page 11] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[11ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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.
ベストエフォート型交通、Assured Forwarding集合のための10%のパケット損失をもたらして、およびベストエフォート型交通の全損からのリソース。 図6(b)の例は、また、これがAssured Forwardingのような低優先度サービスで起こることができるのを示します。 低優先度があるサービス流動の予約が無視されるとき、それらの品質(この場合ベストエフォート型サービス)で他のサービス(低優先度があっても)を抑えることができます。 NRS問題を引き起こすのがそうすることができるのがそれ自体で例、サービスの集合で示されるように、パケット損失で影響を受けてください(Assured Forwarding集合の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をDifferentiated Servicesに適用すると、NRS Problemの一時的な発生はもたらされるでしょう。 受信機は送付者のPATHメッセージを受け取るためにIPマルチキャストグループに加わらなければなりません、リソース予約の要請(RESVメッセージ)を送ることができる前に。 このようにして、PATHメッセージがNRS Problemを引き起こす場合がある落手のためにリンクに関するメッセージを接合してください、この状況が特別な方法(例えば、マルチキャスト流動の他のすべてのデータ・パケットにすべてのPATHメッセージにcodepoint0を付けて、低下するか、または述べさせるのによる)で扱われないなら。
2.2. Heterogeneous Multicast Groups
2.2. 種々雑多なマルチキャストグループ
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台以上の受信機、送付者が提供するときどれが別のサービスかサービスの質を得たがっているか、そして、または部分集合が現在使用する他の受信機を含みます。 Differentiated Servicesによって支持されるはずである非常に重要な特性はまた、ベストエフォート型品質だけを要求する関係者がそうでなければより良いサービスのクラスを利用するグループコミュニケーションに参加できるべきであるということです。 異種性の次の、より良いサポートはグループの中で2つ以上の異なったサービスのクラスの同時発生の使用を提供します。 いろいろなことは、唯一の異なっていないサービスのクラスが、あるサービスのクラスの中の上質のパラメタのための必要な、しかし、異なったも値であるときに、さらに複雑になる傾向があります。
A further problem is to support heterogeneous groups with different service classes in a consistent way. It is possible that some services will not be comparable to each other so that one service cannot be replaced by the other, and both services have to be provided over the same link within this group.
さらなる問題は異なったサービスのクラスと共に種々雑多なグループを一貫した方法で支持することです。 互いにいくつかのサービスがならない匹敵しているのが可能であるので、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
異なったサービスを得る必需品がそうであることができる任意の新しい受信機が現在のマルチキャスト配送木の任意な点に接ぎ木されて、内部のノードさえ異なったサービスを利用することでパケットを模写しなければならないかもしれないので。 最初の一目、これはaであるように思えます。
Bless & Wehrle Informational [Page 12] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[12ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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.
内部のノードの簡単さに関する矛盾、変換さえしないので、利用可能なプロフィールを持って、現在、個々の受信機の品質のサービスを変換するべきです。 その結果、これを達成するために、内部のノードはパケット模写の間、codepoint値を変えなければなりません。
2.3. Dynamics of Any-Source Multicast
2.3. 力学、いくらか、-、ソース、マルチキャスト
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マルチキャストグループの中では、どんな関係者(実際に、それはこのマルチキャストグループのパケットを受けてさえいないどんなホストであるかもしれませんも)も送付者として務めることができます。 これはまた、最も良い努力以外の特定のサービスがグループの中で利用されるといけないので利用可能であるべき重要な特徴です。 微分されたServicesには、単方向のキャラクタが概念的にあります。 したがって、送付者によって暗示されたあらゆるマルチキャスト木に関して、同時の発信が、より良いサービスで可能であるなら、別々にリソースを予約しなければなりません。 共有されたマルチキャスト配送木が使用されているなら(例えば、PIM-SMかCore Based Treesと)、これは本当でさえあります。 十分そうでなければ、リソースはサービスのために1人以上の関係者の同時の発信を許しながら、マルチキャスト木の中で予約されて、NRS問題は再び起こるでしょう。 同じ議論は数人の送付者で予約されたリソースを共有する半二重の予約に適用されます、ネットワークが、ちょうど1人の送付者がパケットをグループに送るのを確実にすることができないので。 それに従って、Differentiated Servicesの中で対応するRSVP予約スタイル「ワイルドカードフィルタ」と「共有されて明白なフィルタ」[4]を支持できません。 Integrated Servicesアプローチは交通の半二重本質を確実にすることができます、あらゆるルータが順応がないかどうかインストールされた予約状態に各パケットについて問い合わせることができるので。
3. Solutions for Enabling IP-Multicast in Differentiated Services
Networks
3. 微分されたサービスネットワークでIP-マルチキャストを可能にするためのソリューション
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.
前項で説明された問題はDifferentiated Services構造の簡単さによって主に引き起こされます。 追加複雑さを導入しないソリューションは、DiffServアプローチのスケーラビリティを減少させないように導入される必要があります。 このドキュメントは問題の大部分の簡単な解決策を示します。
3.1. Solution for the NRS Problem
3.1. NRS問題のためのソリューション
The proposed solution consists conceptually of the following three steps that are described in more detail later.
提案された解決策はさらに詳細に後で説明される以下の3ステップから概念的に成ります。
Bless & Wehrle Informational [Page 13] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[13ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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であるなら、経営体は、要求されたサービスに対応するcodepointを設定するよう分岐ルータに命令します。
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のcodepointにcodepoint(そして、したがって、Per-ホップBehavior)を変換します。 より明確に、この特定のPHBはデフォルトPHBのベストエフォート型サービスよりさらに悪いサービスを提供できます。 対応するLower Effort Per-ドメインBehaviorのためのRFC3662[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
したがって、このマルチキャストグループからの述べているパケットはこの外向的な集合で他のパケットより積極的に捨てられるべきです。 それらのパケットに適切に構成されたPHB(そして、関連するDSCP)を使用することによって、これを達成できるでしょう。 それは、デフォルトPHBとこの種類のPHBを区別するために株式会社Effort(LE)PHBと呼ばれます。(適切に構成されたAF PHB[9]かClass Selector Compliant PHB[1])がこのドキュメント中で実感できる。 異状ノードで単により積極的にパケットを落とすのは十分ではありません、外向的な振舞いにおけるリソースが(BA)を集める十分があるかもしれないので
Bless & Wehrle Informational [Page 14] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[14ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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.
同じ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があるそのようなもの)の他のすべての節が通常通りのパケットを模写します。 また、分岐ノードがそうするかもしれないのでドメインの内部のノードになってください、とパケットの異状が概念的に必要とする、-、流れ分類。 これは1流れあたりの州を避けるコアのDiffServ哲学に反しているように思えますが、IPマルチキャスト流れはユニキャスト流れと異なっています: 伝統的なIPマルチキャスト推進とマルチキャストルーティングが、とにかくマルチキャストグループあたりの州をあらゆる出発しているリンクにインストールするのに必要です。 したがって、内部のノードにおける異状はIPマルチキャスト(Cfセクション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-クラシファイアとマーカーの組み合わせを使用することによって、異状を達成します。 クラシファイアは新しいcodepointを設定するマーカーにすべての模写されたパケットを向けるでしょう。 代替の実現はセクション7で説明されます。
The better service will only be provided if a reservation request was processed and approved by the resource management function. That means an admission control test must be performed before resources are actually used by the new branch. In case the admission test is successful, the re-marking node will be instructed by the resource management to stop re-marking and to use the original codepoint again (conceptually by removing the profile).
リソース管理機能で予約の要請を処理して、承認した場合にだけ、より良いサービスを提供するでしょう。 それは、リソースが実際に新しいブランチによって使用される前に入場対照試験を実行しなければならないことを意味します。 入学試験がうまくいくといけないので、述べるのを止めて、異状ノードがもう一度(概念的に、プロフィールを取り外す)オリジナルのcodepointを使用するよう資源管理によって命令されるでしょう。
In summary, only those receivers will obtain a better service within a DiffServ multicast group, which previously reserved the corresponding resources in the new branch with assistance of the resource management. Otherwise, they get a quality which might be even lower than best-effort.
概要では、それらの受信機だけがDiffServマルチキャストグループの中で、より良いサービスを得るでしょう。グループは以前に、資源管理の支援で新しいブランチで対応するリソースを予約しました。 さもなければ、彼らはベストエフォート型であるよりさらに低いかもしれない品質を得ます。
3.2. Solution for Supporting Heterogeneous Multicast Groups
3.2. 種々雑多なマルチキャストグループを支持するためのソリューション
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
セクション3.1からの提案された概念は異種性問題の限られた解決法を提供します。 受信機が予約なしで株式会社Effortサービスを得ることができて、そうが少なくともその2である、相違
Bless & Wehrle Informational [Page 15] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[15ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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).
マルチキャストグループの中のサービスのクラスは可能です。 したがって、どんな受信機もマルチキャストセッションのときにどんなサービスの質も得ないで関与するのは、可能です。 受信機が、マルチキャストグループの中身が十分おもしろいかどうかをただ見たいなら、これは役に立ちます、代価を払わなければならない(先の予約なしでグループをせんさくするように)より良いサービスを要求する前に。
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 Problemを引き起こしたでしょう。
Theoretically, the proposed approach in section 7 also supports more than two different services within one multicast group, because the additional field in the multicast routing table can store any DSCP value. However, this would work only if PHBs can be ordered, so that the "best" PHB among different required PHBs downstream is chosen to be forwarded on a specific link. This is mainly a management issue and is out of the scope of this document.
また、理論的に、セクション7での提案されたアプローチは1つのマルチキャストグループの中の2つ以上の異なったサービスを支持します、マルチキャスト経路指定テーブルの追加分野がどんなDSCP値も格納できるので。 しかしながら、PHBsを注文できる場合にだけ、これは働いているでしょう、異なった必要なPHBsの中の「最善」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値によった条件付きの異状を支持するかもしれません。 グループが異なったPHBs(例えば、異なったトランスポート・プロトコルポートへの流れのための)を使用するなら、これは役に立ちます、そして、その結果、異状はさらに、入って来るパケットのDSCP値に依存するべきです。
3.3. Solution for Any-Source Multicast
3.3. ソリューション、いくらか、-、ソース、マルチキャスト
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できる境界ノードはいつも送付者のアドレスとマルチキャストグループアドレスの両方に基づくマルチキャストパケットを分類するはずです。
4. Scalability Considerations
4. スケーラビリティ問題
Bless & Wehrle Informational [Page 16] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[16ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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に反しているのがそれ自体にアプローチします。 内部のルータの中でユニキャスト流れのパケットを述べさせるのに関係する既存の正当なスケーラビリティ関心とマルチキャストケースを区別するのは重要です。 そのうえ、いつ再マーク方針を変えるかに関する決定はルータによって実行されるのではなく、レベルを進めながらパケットでタイムスケールと異なったタイムスケールにおける何らかの経営体によって実行されます。
5. Deployment Considerations
5. 展開問題
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から提案された解決策を配備できないいくつかの専門化しているハードウェアプラットホームがあるかもしれません。 マルチキャストパケットがルータのバックプレーンに直接コピーされるとき、これはそうであるかもしれません、すべての外向的なインタフェースが平行なパケットを読むように。 その結果、これらの外向的なインタフェースの部分集合のためにcodepointを変えることができません、そして、直接分岐ポイントで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
2. 適切に割り当てられたリソースのない下位木のためのcodepointの変化は以下の川下のルータで起こることができました。 そこでは、考えられたマルチキャストグループのあらゆる入って来るパケットに関して、codepointが前のルータが設定するべきであった値に変わるでしょう。 LAN(例えば、高速切り換えLAN)を考えられた外向的なインタフェースに付けるなら、LANに関連づけられたあらゆるルータでは、考えられたグループのパケットを変えるべきです。
Bless & Wehrle Informational [Page 17] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[17ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
on the incoming interface by standard DiffServ mechanisms.
入来のときに、標準のDiffServメカニズムで、連結してください。
Future releases of router architectures may support the change of the codepoint directly in the replication process as proposed in section 7.
ルータ構造の今後のリリースはセクション7で提案されるように直接模写の過程における、codepointの変化を支持するかもしれません。
6. Security Considerations
6. セキュリティ問題
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]のセキュリティ問題は適用されます。 提案された解決策は新しいセキュリティ局面を含意しません。 aが任意のエンドシステムをマルチキャストに接合するなら、グループは望まれていなくて(その結果、ベストエフォート型品質より低くaを受けます)、通常、アプリケーションがこれらの関係者を除かなければならないということです。 認証、認可、またはアプリケーションレベルでテクニックを解きます--シナリオが伝統的な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.
そのうえ、対応する管理メカニズムのセキュリティを考えるのは重要です、それらがマルチキャスト流れの異状を動かすのに使用されるので。 一方では、マルチキャスト流れのパケットをマークするか、または述べさせるようルータに命令するための機能はサービス攻撃の窃盗を実行する魅力的な目標です。 他方では、それらのセキュリティはこの機能性がわかるのに使用されるルータ管理メカニズムによります。 一般に、したがって、また、それらの攻撃を防いで、ルータ管理は無断使用に対して保護されるべきです。
7. Implementation Model Example
7. 実現モデルの例
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
あらゆるマルチキャスト流動がマルチキャストルーティングの過程によって考えられなければならないので(このような関係においては、この概念はマルチキャストルート計算と維持部分、Cfではなく、マルチキャスト推進部分を意味します。 図1), それぞれのマルチキャスト経路指定テーブルエントリーにおける、DS分野を含んでいて、その結果出力リンク(. 仮想インターフェースをrespして、図8を参照します)(ほとんど別途費用がないのにおける結果)単位でDS codepoint値を含む余分なバイトの添加。 パケットがマルチキャスト推進工程で模写されるので、また、これは模写されたパケットの正しいDSCP値を設定するための適当な場所です。 しかし、それらのDSCP値は入って来るオリジナルのパケットからコピーされません。
Bless & Wehrle Informational [Page 18] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[18ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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.
対応のためのエントリーが出力したマルチキャスティング経路指定テーブルの追加DS分野から、リンクしてください(DSCP値だけをコピーしなければなりません、残っている2ビットは、無視されて、簡素化理由だけで存在していますが)。 この特定のグループのための入って来るパケットがデフォルトPHBのcodepointを運ばないなら、この分野は初めは、LE PHBのcodepointを含みます。
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を使用することで現在の一般的なマルチキャストグループの動きを保有するために同じcodepointを手に入れるべきです。 ルータ構成メッセージは、マルチキャスト経路指定テーブルで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) |
+--------------------------------+ +-------------------+
| ... | ... |
. . .
. . .
Addressの仮想のInter- DSのフィールズが連結するマルチキャストOther List Destinationは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
エイト環: DSCP値のための追加分野があるマルチキャスト経路指定テーブル
8. Proof of the Neglected Reservation Subtree Problem
8. 無視された予約下位木問題の証拠
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問題が実際に存在するのが示されて、ほんとうは起こります。 したがって、問題とその解決策は標準のリナックスKernel(v2.4.18)を使用することで調査されました、そして、リナックスは実現KIDS[11]を基礎づけました。
Furthermore, the proposed solution for the NRS problem has been implemented by enhancing the multicast routing table, as well as the
その上、NRS問題の提案されたソリューションは、また、マルチキャスト経路指定テーブルを機能アップすることによって、実現されました。
Bless & Wehrle Informational [Page 19] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[19ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
multicast routing behavior in the Linux kernel. In the following section, the modifications are briefly described.
リナックスカーネルにおけるマルチキャストルーティングの振舞い。 以下のセクションで、変更は簡潔に説明されます。
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]がある追加測定値はセクション9に提示されるでしょう。 彼らは、使用するか、または異状に株式会社Effort PHBを使用しないことでその他の詳細における、NRS問題の影響とBAsの動きも示しています。
8.1. Implementation of the Proposed Solution
8.1. 提案されたソリューションの実現
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 Problemを避ける提案された解決策は1バイトのあらゆるMulticastルータで、それぞれの経路指定テーブルエントリーの拡大です。 リナックスOSで、マルチキャスト経路指定テーブルは「マルチキャスト推進キャッシュ(MFC)」によって実行されます。 MFCは以下の3つのパラメタの各組み合わせのための「mfc-キャッシュ」エントリーから成るハッシュ表です: 送付者のIPアドレス、マルチキャストグループアドレス、および入来は連結します。
The routing information in a "mfc-cache"-entry is kept in an array of TTLs for each virtual interface. When the TTL is zero, a packet matching to this "mfc-cache"-entry will not be forwarded on this virtual interface. Otherwise, if the TTL is less than the packet's TTL, the latter will be forwarded on the interface with a decreased TTL.
「mfc-キャッシュ」エントリーにおけるルーティング情報はTTLsのアレイで各仮想インターフェースに保たれます。 TTLがゼロであるときに、この「mfc-キャッシュ」エントリーに合っているパケットはこの仮想インターフェースで進められないでしょう。 さもなければ、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.
出発しているリンクの上に帯域幅を割り当てるなら適切なcodepointを設定して、私たちは、特定の仮想インターフェースで使用されるべきであるcodepointを指定するためにTTLアレイと同様のバイトの2番目の勢ぞろいを加えました。 バイトの最初の6ビットは使用されるべきであるDSCPを含んでいて、7番目のビットは、パケットのオリジナルのcodepointを指定されたもの(=0)に変えなければならないか、または変わりのない(=1)に残さなければならないかを示します。 codepointバイトのデフォルトエントリーはゼロです。 それほど初めは、すべてのパケットがデフォルトDSCPに述べるでしょう。
Furthermore, we modified the multicast forwarding code for considering this information while replicating multicast packets. To change an "mfc-cache"-entry we implemented a daemon for exchanging the control information with a management entity (e.g., a bandwidth broker). Currently, the daemon uses a proprietary protocol, but migration to the COPS protocol (RFC 2748) is planned.
その上、私たちは、マルチキャストパケットを模写している間、この情報を考えるようにマルチキャスト推進コードを変更しました。 「mfc-キャッシュ」エントリーを変えるために、私たちは経営体(例えば、帯域幅ブローカー)と制御情報を交換するためにデーモンを実行しました。 現在、デーモンは固有のプロトコルを使用しますが、COPSプロトコル(RFC2748)への移動は計画されています。
Bless & Wehrle Informational [Page 20] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[20ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
8.2. Test Environment and Execution
8.2. 試験環境と実行
Sender
+---+ FHN: First Hop Node
| S | BN: Boundary Node
+---+
+#
+#
+#
+---+ +--+ +------+
|FHN|++++++++++++|BN|+++++++++++| host |
| |############| |***********| B |
+---+ +--+## +------+
+# #
+# #
+# #
+------+ +------+
|host A| |host C|
+------+ +------+
送付者+---+ FHN: 最初のホップノード| S| BN: 境界ノード+---+ +# +# +# +---+ +--+ +------+ |FHN|++++++++++++|BN|+++++++++++| ホスト| | |############| |***********| B| +---+ +--+## +------+ +# # +# # +# # +------+ +------+ |ホストA| |ホストC| +------+ +------+
+++ EF flow (group1) with reservation ### EF flow (group2) with reservation *** EF flow (group2) without reservation
+ + + 予約のない予約***EF流動(group2)に伴う予約###EF流動(group2)に伴うEF流動(group1)
Figure 8.1: Evaluation of NRS-Problem described in
Figure 3
エイト環.1: 図3で説明されたNRS-問題の評価
In order to prove case 1 of the NRS problem, as described in section 2.1, the testbed shown in Figure 8.1 was built. It is a reduced version of the network shown in Figure 5 and consists of two DS- capable nodes, an ingress boundary node and an egress boundary node. The absence of interior nodes does not have any effect on to the proof of the described problem.
セクション2.1で説明されるようにNRS問題に関するケース1を立証するために、図8.1で見せられたテストベッドは建設されました。 それは、図5で見せられたネットワークの減少しているバージョンであり、2つのDSのできるノード、イングレス境界ノード、および出口境界ノードから成ります。 内部のノードの欠如は説明された問題の証拠にどんな影響も与えません。
The testbed is comprised of two Personal Computers (Pentium III at 450 Mhz, 128 MB Ram, 3 network cards Intel eepro100) used as DiffServ nodes, as well as one sender and three receiver systems (also PCs). On the routers, KIDS has been installed and an mrouted (Multicast Routing Daemon) was used to perform multicast routing. The network was completely built of separate 10BaseT Ethernet segments in full- duplex mode. In [11], we evaluated the performance of the software routers and found out that even a PC at 200Mhz had no problem handling up to 10Mbps DS traffic on each link. Therefore, the presented measurements are not a result of performance bottlenecks caused by these software routers.
テストベッドはDiffServノードとして使用される2つのパーソナルコンピュータ(450MhzのPentium III、128MBの牡羊座、3はカードインテルeepro100をネットワークでつなぐ)から成ります、1人の送付者と3台の受信機システム(PCも)と同様に。 そして、ルータに、KIDSがインストールされた、mroutedされて、(マルチキャストルート設定Daemon)は、マルチキャストルーティングを実行するのに使用されました。 ネットワークは完全な重複のモードによる別々の10BaseTイーサネットセグメントで完全に造られました。 [11]では、私たちは、ソフトウェアルータの性能を評価して、200MhzのPCさえ各リンクの上に交通を10Mbps DSまで扱うことにおける問題を全く持っていなかったのを見つけました。 したがって、提示された測定値はこれらのソフトウェアルータによって引き起こされた性能のネックの結果ではありません。
Bless & Wehrle Informational [Page 21] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[21ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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バイトの一定のサイズのパケット)の2回の形成UDP交通の流れを発生させて、マルチキャストグループ1にそれらを送った、(233.1、.1、.1と)2、(233.2 .2 .2)。 両方の測定値では、受信機Aは経路に沿って各流れのための送付者に予約を持っていました、Bが流れ2のための流れ1、およびCのために予約した受信機。 したがって、2個の静的なプロフィールが各流れあたり10.000バイトの500kbps EF帯域幅と象徴バケツサイズでイングレス境界ノードにインストールされます。
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を接待するために出力リンクにインストールされました、そして、それらのC.Eachを接待するために出力リンクに関係づけられたのは500kbps Expedited Forwardingまで可能にしますが、出発しているリンクの上に運ばれたExpedited Forwarding交通の集合だけが考えられます。
In measurement 1, the hosts A and B joined to group 1, while A, B, and C joined to group 2. Those joins are using a reservation for the group towards the sender. Only the join of host B to group 2 has no admitted reservation. As described in section 2.1, this will cause the NRS problem (case 1). Metering and policing mechanisms in the egress boundary node throttle down the EF aggregate to the reserved 500kbps, and do not depend on whether or not individual flows have been reserved.
測定1では、ホストAとBはグループ1につなぎました、A、B、およびCはグループ2につなぎましたが。 ものは加わります。送付者に向かってグループの予約を使用しています。 分類するホストBに接合してください。唯一、2 認められた予約を全く持っていません。 セクション2.1で説明されるように、これはNRS問題(ケース1)を引き起こすでしょう。 出口境界ノードでメカニズムを計量して、取り締まるのは、予約された500kbpsにEF集合を抑えて、個々の流れを控えてあるかどうかによりません。
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 250kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 250kbps| |
+---------+--------+--------+--------+
+--------+--------+--------+ | ホストA| ホストB| ホストC| +---------+--------+--------+--------+ | グループ1| 500kbps| 250kbps| 500kbps| +---------+--------+--------+--------+ | グループ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.
エイト環.2: 測定1(提案された解決策のない)の結果: それぞれの流れの帯域幅を平均してください。 --ホストBへのリンクにおけるグループ1と2の>流れはグループ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.
エイト環.2は得られた結果を示しています。 ホストAとCは少しも干渉なしでそれらの流れを受けました。 しかし、ホストBが予約された帯域幅の唯一の半分でグループ1からデータを受け取ったので、パケットの半分が捨てられました。 また、エイト環.2は、受信機Bがすなわち、グループ1と2、ちょうど予約された500kbpsのために帯域幅の総量を得たのを示します。 流れ2は、実際にどんな帯域幅も控えていなくてExpedited Forwardingを手に入れて、さらに、そのリンクにおけるグループ1の保証に違反しました。
Bless & Wehrle Informational [Page 22] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[22ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
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において、以前に提示された解決策(Cfセクション3.1)は境界ノードにインストールされました。 現在、codepointがBest-努力(または、株式会社Effort)に変わらなければならないかどうか、さもなければ、ただそれをコピーできるかどうかがパケットをコピーしている間、チェックされます。 この測定では、それはHost Bへのリンクに関するグループ2のためにcodepointをBest-努力に変えました。
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 500kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 500kbps| |
+---------+--------+--------+--------+
+--------+--------+--------+ | ホストA| ホストB| ホストC| +---------+--------+--------+--------+ | グループ1| 500kbps| 500kbps| 500kbps| +---------+--------+--------+--------+ | グループ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.
エイト環.3: 測定1(提案された解決策がある)の結果: それぞれの流れの帯域幅を平均してください。 --ホストBへのリンクにおけるグループ1の>流動はグループ1の予約された帯域幅を得ます。 グループ2の流れはBest-努力に述べました。
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からのパケットが境界ノードで述べるので、それらはベストエフォート型交通として扱われました。 この場合、彼らはExpedited Forwarding流動と同じ帯域幅を得ました、そして、リンクプレゼントの上に他の十分な交通がなかったので、パケットを捨てる必要は全くありませんでした。
The above measurements confirm that the Neglected Reservation Subtree problem is to be taken seriously and that the presented solution will solve it.
上記の測定値は、Neglected予約Subtree問題が真剣に受け止められることであり、提示された解決策がそれを解決すると確認します。
9. Simulative Study of the NRS Problem and Limited Effort PHB
9. NRS問題と株式会社の努力PHBのまねた研究
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.
このセクションは提案された解決策の正当性と原因となる流れを述べさせるという効果を示しているまねた研究から株式会社Effortまでいくつかの結果を示しています。 また、セクション8と[13]でNRS問題の証拠を与えました。 このセクションは、株式会社EffortがいつBest Effortの代わりに異状に使用されるかをデフォルトBest Effort交通への利益に示します。 結果は強く株式会社Effortの使用を動機づけます。
Bless & Wehrle Informational [Page 23] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[23ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
9.1. Simulation Scenario
9.1. シミュレーションシナリオ
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.
以下のシナリオでは、境界ノードは10Mpbsのリンク速度を持っていました、そして、Interior Routersには、12Mbpsのリンク速度がありました。 境界ノードでは、EFにおける、集合の5Mbpsが予約されました。
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.
株式会社Effortが使用されたとき、LEは容量(0.5Mpbs)をオリジナルから10%に得ました。集合になってください、そして、90%がオリジナルの(4.5Mbps)であったなら集合容量になってください。 いてください。そして、LEの間の帯域幅、計画となっていながら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| +--+ +--+
+--+
+--+ +--+ +---+ +--+ |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.
以下のテーブルは、シミュレーション下痢では、4MbpsのレートがEFの予約を使用している状態で例えばEF0がSender S0からDestination 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)、異なった量をケースに入れるコネ、交通が異なった場合における、株式会社Effortの効果を示しているのに使用されたということになってください。 これらの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.
また、ソースが一定のレート交通を発生させたということになってください。(そこでは、BE0がUDPを使用して、BE1はトランスポート・プロトコルとしてTCPを使用しました)。
Bless & Wehrle Informational [Page 24] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[24ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
+----+--------+-------+----------+-----------+-----------+---------+ |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| +----+--------+-------+----------+-----------+-----------+---------+
+----+--------+-------+----------+-----------+-----------+---------+ |流れ| ソース| Dest。 | ケースI| ケースII| ケースIII| ケース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つのシミュレーション場合における流れの指示、量、およびCodepoint(IVへのケースI)
The four cases (I to IV) used in the simulation runs had the following characteristics:
シミュレーション下痢に使用される4つのケース(IVへの私)が以下の特性を持っていました:
Case I: In this scenario, the BE sources sent together exactly 5
Mbps, so there is no congestion in the BE queue.
ケースI: このシナリオでしたがって、中に混雑が全く一緒に送られたソースがちょうど5Mbpsであったなら、ない、待ち行列になってください。
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: 中で入手できているスペースが5Mbpsを送るのであるのである、述べている交通のための待ち行列になってください。 時が使用されるLEであったなら、BE0とBE1は4.5Mbpsを一緒に送って、まさにシェアはどれのものですか? それで、マルチキャストパケットがNRS問題のためにLEに述べるとき、LEは0.5Mbpsを手に入れて、4.5Mbpsであるべきです。(BE0とBE1には、そのMbpsはまだ十分です)。 LEが貪欲な振舞いを示すべきでなくて、リソースを使用するはずがない、いてください。
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: この場合、いてください、まさしくその安値はそうです。 BE0とBE1は1.5Mbpsだけを一緒に使用します。 そのように、LEが使用されている、いつから未使用の帯域幅リソースを使用できるべきであるか、いてください。
Case IV: BE0 and BE1 send together 7.5 Mbps so there is congestion
in the BE queue. In this case, LE should get 0.5 Mbps (not
more and not less).
ケースIV: BE0とBE1が中でしたがって、ある7.5Mbpsに混雑を一緒に送る、待ち行列になってください。 この場合、LEは0.5Mbpsを手に入れるはずです(以下ではなく、以上でない)。
In each scenario, loss rate and throughput of the considered flows and aggregates have been metered.
各シナリオでは、考えられた流れと集合に関する損失率とスループットは計量されました。
Bless & Wehrle Informational [Page 25] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[25ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
9.2. Simulation Results for Different Router Types
9.2. 異なったルータタイプのためのシミュレーションの結果
9.2.1. Interior Node
9.2.1. 内部のノード
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).
新たに加えられたマルチキャスト下位木の分岐ポイントが内部のノードに位置しているとき、NRS問題はセクション2.1(ケース2)で説明されるように起こることができます。
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.
4つの異なった場合におけるIR2とBR3とのリンクにおける流れの計量されたスループットは以下の4つの小区分で示されます。 新しい受信機が接合する前に状況は第2コラムに示されます。 後の状況、解決策がコラムthreeに示される提案なしで接合してください。 セクション3.1の提案された解答が使用されていて、原因となる流れがLEに述べるとき、第4コラムは結果を提示します。
9.2.1.1. Case I:
9.2.1.1. ケースI:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.007 Mbps | LE0: 0.504 Mbps |
|achieved| EF1: 2.001 Mbps | EF1: 2.003 Mbps | EF1: 2.000 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.009 Mbps | EF2: 5.000 Mbps |
|put | BE0: 1.000 Mbps | BE0: 0.601 Mbps | BE0: 1.000 Mbps |
| | BE1: 4.000 Mbps | BE1: 0.399 Mbps | BE1: 3.499 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.003 Mbps | EF: 11.019 Mbps | EF: 7.000 Mbps |
|through-| BE: 5.000 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 34.8 % | BE0: 0 % |
| | BE1: 0 % | BE1: 59.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
+--------+-----------------+-----------------+------------------+ | | 接合してくださいという前に| 接合してくださいという後に|後に接合してください。| | | | (異状でない) |(LEへの異状)| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 4.007 Mbps| LE0: 0.504 Mbps| |達成されます。| EF1: 2.001 Mbps| EF1: 2.003 Mbps| EF1: 2.000 Mbps| |突き抜ける| EF2: 5.002 Mbps| EF2: 5.009 Mbps| EF2: 5.000 Mbps| |置かれます。| 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| |突き抜ける| あります: 5.000 Mbps| あります: 1.000 Mbps| あります: 4.499 Mbps| |置かれます。| LE: --- | LE: --- | LE: 0.504 Mbps| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 0 % | LE0: 87.4 % | |パケット| EF1: 0 % | EF1: 0 % | EF1: 0 % | |損失| EF2: 0 % | EF2: 0 % | EF2: 0 % | |レート| BE0: 0 % | BE0: 34.8 % | BE0: 0 % | | | BE1: 0 % | BE1: 59.1 % | BE1: 0 % | +--------+-----------------+-----------------+------------------+(*)EF0はLEに述べて、LE0としてサインされます。
Bless & Wehrle Informational [Page 26] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[26ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
9.2.1.2. Case II:
9.2.1.2. ケースII:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.003 Mbps | LE0: 0.500 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.005 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.248 Mbps | BE0: 0.941 Mbps | BE0: 2.253 Mbps |
| | BE1: 2.252 Mbps | BE1: 0.069 Mbps | BE1: 2.247 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.002 Mbps | EF: 11.009 Mbps | EF: 7.003 Mbps. |
|through-| BE: 4.500 Mbps | BE: 1.010 Mbps | BE: 4.500 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 58.0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 57.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
+--------+-----------------+-----------------+------------------+ | | 接合してくださいという前に| 接合してくださいという後に|後に接合してください。| | | | (異状でない) |(LEへの異状)| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 4.003 Mbps| LE0: 0.500 Mbps| |達成されます。| EF1: 2.000 Mbps| EF1: 2.001 Mbps| EF1: 2.001 Mbps| |突き抜ける| EF2: 5.002 Mbps| EF2: 5.005 Mbps| EF2: 5.002 Mbps| |置かれます。| 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。 | |突き抜ける| あります: 4.500 Mbps| あります: 1.010 Mbps| あります: 4.500 Mbps| |置かれます。| LE: --- | LE: --- | LE: 0.500 Mbps| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 0 % | LE0: 87.4 % | |パケット| EF1: 0 % | EF1: 0 % | EF1: 0 % | |損失| EF2: 0 % | EF2: 0 % | EF2: 0 % | |レート| BE0: 0 % | BE0: 58.0 % | BE0: 0 % | | | BE1: 0 % | BE1: 57.1 % | BE1: 0 % | +--------+-----------------+-----------------+------------------+(*)EF0はLEに述べて、LE0としてサインされます。
9.2.1.3. Case III:
9.2.1.3. ケースIII:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 3.998 Mbps | LE0: 3.502 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.000 Mbps | EF2: 5.002 Mbps | EF2: 5.003 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.572 Mbps | BE0: 0.748 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.429 Mbps | BE1: 0.748 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.000 Mbps | EF: 11.001 Mbps | EF: 7.004 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.001 Mbps | BE: 1.496 Mbps |
|put | LE: --- | LE: --- | LE: 3.502 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 12.5 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 19.7 % | BE0: 0 % |
| | BE1: 0 % | BE1: 32.6 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0
+--------+-----------------+-----------------+------------------+ | | 接合してくださいという前に| 接合してくださいという後に|後に接合してください。| | | | (異状でない) |(LEへの異状)| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 3.998 Mbps| LE0: 3.502 Mbps| |達成されます。| EF1: 2.000 Mbps| EF1: 2.001 Mbps| EF1: 2.001 Mbps| |突き抜ける| EF2: 5.000 Mbps| EF2: 5.002 Mbps| EF2: 5.003 Mbps| |置かれます。| 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| |突き抜ける| あります: 1.498 Mbps| あります: 1.001 Mbps| あります: 1.496 Mbps| |置かれます。| LE: --- | LE: --- | LE: 3.502 Mbps| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 0 % | LE0: 12.5 % | |パケット| EF1: 0 % | EF1: 0 % | EF1: 0 % | |損失| EF2: 0 % | EF2: 0 % | EF2: 0 % | |レート| BE0: 0 % | BE0: 19.7 % | BE0: 0 % | | | BE1: 0 % | BE1: 32.6 % | BE1: 0 % | +--------+-----------------+-----------------+------------------+(*)EF0はLEに述べて、LE0としてサインされます。
Bless & Wehrle Informational [Page 27] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[27ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
9.2.1.4. Case IV:
9.2.1.4. ケースIV:
+--------+-----------------+-----------------+------------------+ | | before join | after join |after join, | | | | (no re-marking) |(re-marking to LE)| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 4.001 Mbps | LE0: 0.500 Mbps | |achieved| EF1: 2.018 Mbps | EF1: 2.000 Mbps | EF1: 2.003 Mbps | |through-| EF2: 5.005 Mbps | EF2: 5.001 Mbps | EF2: 5.007 Mbps | |put | BE0: 2.825 Mbps | BE0: 1.000 Mbps | BE0: 3.425 Mbps | | | BE1: 2.232 Mbps | BE1: --- | BE1: 1.074 Mbps | +--------+-----------------+-----------------+------------------+ |BA | EF: 7.023 Mbps | EF: 11.002 Mbps | EF: 7.010 Mbps | |through-| BE: 5.057 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps | |put | LE: --- | LE: --- | LE: 0.500 Mbps | +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 0 % | LE0: 75.0 % | |packet | EF1: 0 % | EF1: 0 % | EF1: 0 % | |loss | EF2: 0 % | EF2: 0 % | EF2: 0 % | |rate | BE0: 23.9 % | BE0: 73.3 % | BE0: 0 % | | | BE1: 41.5 % | BE1: --- | BE1: 0 % | +--------+-----------------+-----------------+------------------+ (*) EF0 is re-marked to LE and signed as LE0
+--------+-----------------+-----------------+------------------+ | | 接合してくださいという前に| 接合してくださいという後に|後に接合してください。| | | | (異状でない) |(LEへの異状)| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 4.001 Mbps| LE0: 0.500 Mbps| |達成されます。| EF1: 2.018 Mbps| EF1: 2.000 Mbps| EF1: 2.003 Mbps| |突き抜ける| EF2: 5.005 Mbps| EF2: 5.001 Mbps| EF2: 5.007 Mbps| |置かれます。| 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| |突き抜ける| あります: 5.057 Mbps| あります: 1.000 Mbps| あります: 4.499 Mbps| |置かれます。| LE: --- | LE: --- | LE: 0.500 Mbps| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: 0 % | LE0: 75.0 % | |パケット| EF1: 0 % | EF1: 0 % | EF1: 0 % | |損失| EF2: 0 % | EF2: 0 % | EF2: 0 % | |レート| BE0: 23.9 % | BE0: 73.3 % | BE0: 0 % | | | BE1: 41.5 % | BE1: --- | BE1: 0 % | +--------+-----------------+-----------------+------------------+(*)EF0はLEに述べて、LE0としてサインされます。
NOTE: BE1 has undefined throughput and loss in situation "after join (no re-marking)", because TCP is going into retransmission back-off timer phase and closes the connection after 512 seconds.
以下に注意してください。 BE1は、状況における未定義のスループットと損失が「後に、(異状でない)を接合すること」を持っています、TCPが「再-トランスミッション」下に後部タイマフェーズに入っていて、後の512秒の接続を終えるので。
9.2.2. Boundary Node
9.2.2. 境界ノード
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).
新たに加えられたマルチキャスト下位木の分岐ポイントが境界ノードに位置しているとき、NRS問題はセクション2.1(ケース1)で説明されるように起こることができます。
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.
4つの異なった場合におけるBR3とBR4とのリンクにおける流れの計量されたスループットは以下の4つの小区分で示されます。 新しい受信機が接合する前に状況は第2コラムに示されます。 後の状況、しかし、解決策がコラムthreeに示される提案なしで接合してください。 セクション3.1の提案された解答が使用されていて、原因となる流れがLEに述べるとき、第4コラムは結果を提示します。
Bless & Wehrle Informational [Page 28] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[28ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
9.2.2.1. Case I:
9.2.2.1. ケースI:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.489 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 3.512 Mbps | EF2: 5.002 Mbps |
|put | BE0: 1.000 Mbps | BE0: 1.000 Mbps | BE0: 1.004 Mbps |
| | BE1: 4.000 Mbps | BE1: 4.002 Mbps | BE1: 3.493 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.002 Mbps | EF: 5.001 Mbps | EF: 5.002 Mbps |
|through-| BE: 5.000 Mbps | BE: 5.002 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 25.6 % | LE1: 73.4 % |
|loss | EF2: 0 % | EF2: 29.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
+--------+-----------------+-----------------+------------------+ | | 接合してくださいという前に| 接合してくださいという後に|後に接合してください。| | | | (異状でない) |(LEへの異状)| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: --- | EF0: --- | |達成されます。| EF1: --- | EF1: 1.489 Mbps| LE1: 0.504 Mbps| |突き抜ける| EF2: 5.002 Mbps| EF2: 3.512 Mbps| EF2: 5.002 Mbps| |置かれます。| 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| |突き抜ける| あります: 5.000 Mbps| あります: 5.002 Mbps| あります: 4.497 Mbps| |置かれます。| LE: --- | LE: --- | LE: 0.504 Mbps| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: --- | EF0: --- | |パケット| EF1: --- | EF1: 25.6 % | LE1: 73.4 % | |損失| EF2: 0 % | EF2: 29.7 % | EF2: 0 % | |レート| BE0: 0 % | BE0: 0 % | BE0: 0 % | | | BE1: 0 % | BE1: 0 % | BE1: 0 % | +--------+-----------------+-----------------+------------------+(*)EF1はLEに述べて、LE1としてサインされます。
9.2.2.2. Case II:
9.2.2.2. ケースII:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.520 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.003 Mbps | EF2: 3.482 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.249 Mbps | BE0: 2.249 Mbps | BE0: 2.245 Mbps |
| | BE1: 2.252 Mbps | BE1: 2.252 Mbps | BE1: 2.252 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.003 Mbps | EF: 5.002 Mbps | EF: 5.002 Mbps |
|through-| BE: 4.501 Mbps | BE: 4.501 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 24.0 % | LE1: 74.8 % |
|loss | EF2: 0 % | EF2: 30.4 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
+--------+-----------------+-----------------+------------------+ | | 接合してくださいという前に| 接合してくださいという後に|後に接合してください。| | | | (異状でない) |(LEへの異状)| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: --- | EF0: --- | |達成されます。| EF1: --- | EF1: 1.520 Mbps| LE1: 0.504 Mbps| |突き抜ける| EF2: 5.003 Mbps| EF2: 3.482 Mbps| EF2: 5.002 Mbps| |置かれます。| 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| |突き抜ける| あります: 4.501 Mbps| あります: 4.501 Mbps| あります: 4.497 Mbps| |置かれます。| LE: --- | LE: --- | LE: 0.504 Mbps| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: --- | EF0: --- | |パケット| EF1: --- | EF1: 24.0 % | LE1: 74.8 % | |損失| EF2: 0 % | EF2: 30.4 % | EF2: 0 % | |レート| BE0: 0 % | BE0: 0 % | BE0: 0 % | | | BE1: 0 % | BE1: 0 % | BE1: 0 % | +--------+-----------------+-----------------+------------------+(*)EF1はLEに述べて、LE1としてサインされます。
Bless & Wehrle Informational [Page 29] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[29ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
9.2.2.3. Case III:
9.2.2.3. ケースIII:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.084 Mbps | LE1: 2.000 Mbps |
|through-| EF2: 5.001 Mbps | EF2: 3.919 Mbps | EF2: 5.000 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.752 Mbps | BE0: 0.750 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.748 Mbps | BE1: 0.750 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.001 Mbps | EF: 5.003 Mbps | EF: 5.000 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.500 Mbps | BE: 1.500 Mbps |
|put | LE: --- | LE: --- | LE: 2.000 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 45.7 % | LE1: 0 % |
|loss | EF2: 0 % | EF2: 21.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
+--------+-----------------+-----------------+------------------+ | | 接合してくださいという前に| 接合してくださいという後に|後に接合してください。| | | | (異状でない) |(LEへの異状)| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: --- | EF0: --- | |達成されます。| EF1: --- | EF1: 1.084 Mbps| LE1: 2.000 Mbps| |突き抜ける| EF2: 5.001 Mbps| EF2: 3.919 Mbps| EF2: 5.000 Mbps| |置かれます。| 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| |突き抜ける| あります: 1.498 Mbps| あります: 1.500 Mbps| あります: 1.500 Mbps| |置かれます。| LE: --- | LE: --- | LE: 2.000 Mbps| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: --- | EF0: --- | |パケット| EF1: --- | EF1: 45.7 % | LE1: 0 % | |損失| EF2: 0 % | EF2: 21.7 % | EF2: 0 % | |レート| BE0: 0 % | BE0: 0 % | BE0: 0 % | | | BE1: 0 % | BE1: 0 % | BE1: 0 % | +--------+-----------------+-----------------+------------------+(*)EF1はLEに述べて、LE1としてサインされます。
9.2.2.4. Case IV:
9.2.2.4. ケースIV:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.201 Mbps | LE1: 0.500 Mbps |
|through-| EF2: 5.048 Mbps | EF2: 3.803 Mbps | EF2: 5.004 Mbps |
|put | BE0: 2.638 Mbps | BE0: 2.535 Mbps | BE0: 3.473 Mbps |
| | BE1: 2.379 Mbps | BE1: 2.536 Mbps | BE1: 1.031 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.048 Mbps | EF: 5.004 Mbps | EF: 5.004 Mbps |
|through-| BE: 5.017 Mbps | BE: 5.071 Mbps | BE: 4.504 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 40.0 % | LE1: 68.6 % |
|loss | EF2: 0 % | EF2: 23.0 % | EF2: 0 % |
|rate | BE0: 30.3 % | BE0: 32.1 % | BE0: 0 % |
| | BE1: 33.3 % | BE1: 32.7 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE1
+--------+-----------------+-----------------+------------------+ | | 接合してくださいという前に| 接合してくださいという後に|後に接合してください。| | | | (異状でない) |(LEへの異状)| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: --- | EF0: --- | |達成されます。| EF1: --- | EF1: 1.201 Mbps| LE1: 0.500 Mbps| |突き抜ける| EF2: 5.048 Mbps| EF2: 3.803 Mbps| EF2: 5.004 Mbps| |置かれます。| 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| |突き抜ける| あります: 5.017 Mbps| あります: 5.071 Mbps| あります: 4.504 Mbps| |置かれます。| LE: --- | LE: --- | LE: 0.500 Mbps| +--------+-----------------+-----------------+------------------+ | | EF0: --- | EF0: --- | EF0: --- | |パケット| EF1: --- | EF1: 40.0 % | LE1: 68.6 % | |損失| EF2: 0 % | EF2: 23.0 % | EF2: 0 % | |レート| BE0: 30.3 % | BE0: 32.1 % | BE0: 0 % | | | BE1: 33.3 % | BE1: 32.7 % | BE1: 0 % | +--------+-----------------+-----------------+------------------+(*)EF1はLEに述べて、LE1としてサインされます。
Bless & Wehrle Informational [Page 30] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[30ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
10. Acknowledgements
10. 承認
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]に感謝申し上げます。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[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分野)の定義」RFC2474(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.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
11.2. Informative References
11.2. 有益な参照
[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.Carpenter、「彼らのSpecificationのためのDifferentiated Services Per Domain BehaviorsとRulesの定義」RFC3086(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インチ議定書の中で述べます、RFC2205、1997年9月。」
[5] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[5]Bernet、Y.、「RSVP DCLASS物の形式」、RFC2996、2000年11月。
[6] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector
Multicast Routing Protocol", RFC 1075, November 1988.
[6]WaitzmanとD.とヤマウズラとC.とS.デアリング、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」、RFC1075、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)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[8] Adams, A., Nicholas, J. and W. Siadak, "Protocol Independent
Multicast - Dense Mode (PIM-DM) Protocol Specification
(Revised)", Work in Progress.
[8] 「独立しているマルチキャストについて議定書の中で述べてください--濃いモード(PIM-DM)は仕様(改訂される)を議定書の中で述べる」というアダムス、A.、ニコラス、J.、およびW.Siadakは進行中で働いています。
[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、1999年6月の「相対的優先転送PHBは分類する」RFC2597。
Bless & Wehrle Informational [Page 31] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[31ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
[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ルータのためにモデル化します」、RFC3290、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.
R.が祝福する[11]、K.ウェールレ。 リナックスの下に実現を使用する微分されたサービスの評価、インターンの議事。 サービスの質(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.ウェールレ、J.リーバー対Kahmann コンファレンス(CNDS2001)、フェニックス(アリゾナ)2001年1月にServiceの振舞いの任意のQuality、Communication Networks And Distributed Systems Modeling And SimulationのProceedingsを統合する能力があるインターネット接続装置のためのシミュレーションスイート。
[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.
R.が祝福する[13]、K.ウェールレ。 微分されたサービスネットワークにおけるグループコミュニケーション、グローバルなコンピューティング2001(IQ2001)のためのインターネットQoS、クラスタコンピューティングにおけるIEEE国際シンポジウム、および格子、2001年5月に、ブリスベーン(オーストラリア)IEEEは押します。
[14] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec,
J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March
2002.
[14] デイビーとB.とシャルニーとA.とベネットとJ.C.R.とベンソンとK.とLe BoudecとJ.Y.とコートニーとW.とDavariとS.とFiroiuとV.と2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[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] シャルニーとA.、ベネットとJ.C.R.とベンソンとK.とLe BoudecとJ.Y.とチウとA.とコートニーとW.とDavariとS.とFiroiuとV.とKalmanekとC.とK.K.Ramakrishnan、「EF PHB(1ホップあたりの完全優先転送の振舞い)の新しい定義のための補足的情報」RFC3247(2002年3月)。
[16] Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort Per-Domain
Behavior (PDB) for Differentiated Services", RFC 3662, December
2003.
[16]が祝福する、R.、ニコルズ、K.、およびK.ウェールレ、「Aは微分されたサービスのための1ドメインあたりの努力の振舞い(PDB)を下ろします」、RFC3662、12月2003
Bless & Wehrle Informational [Page 32] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[32ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
12. Authors' Addresses
12. 作者のアドレス
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
ローランドはテレマティックスUniversitaetカールスルーエ(TH)ツィルケル研究所2 76128カールスルーエ(ドイツ)を祝福します。
Phone: +49 721 608 6413 EMail: bless@tm.uka.de URI: http://www.tm.uka.de/~bless
以下に電話をしてください。 +49 6413年の721 608メール: bless@tm.uka.de ユリ: 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
Tuebingen WSIのクラウスウェールレ大学--Tuebingen、コンピュータネットワークとインターネット/プロトコル工学と分散システムMorgenstelle 10c72076ドイツ
EMail: Klaus.Wehrle@uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/~wehrle/
メール: Klaus.Wehrle@uni-tuebingen.de ユリ: http://net.informatik.uni-tuebingen.de/~wehrle/
Bless & Wehrle Informational [Page 33] RFC 3754 IP Multicast in DS Networks April 2004
祝福、DSのウェールレ情報[33ページ]のRFC3754IP Multicastは2004年4月をネットワークでつなぎます。
13. Full Copyright Statement
13. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Bless & Wehrle Informational [Page 34]
祝福、ウェールレInformational[34ページ]
一覧
スポンサーリンク
