[要約] RFC 2490は、IPマルチキャストとRSVPを使用したシミュレーションモデルに関するものであり、その目的は、ネットワーク環境でのマルチキャスト通信の効率とパフォーマンスを評価することです。
Network Working Group M. Pullen
Request for Comments: 2490 George Mason University
Category: Informational R. Malghan
Hitachi Data Systems
L. Lavu
Bay Networks
G. Duan
Oracle
J. Ma
NewBridge
H. Nah
George Mason University
January 1999
A Simulation Model for IP Multicast with RSVP
RSVPを使用したIPマルチキャストのシミュレーションモデル
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
Abstract
概要
This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package [4], with protocol procedures defined in the C language. The model was developed to allow investigation of performance constraints on routing but should have wide applicability in the Internet multicast/resource reservation community. We are making this model publicly available with the intention that it can be used to provide expanded studies of resource-reserved multicasting.
このドキュメントでは、OPNETシミュレーションパッケージ[4]を使用して開発された、RSVPを使用したIPv4マルチキャストの詳細なモデルについて説明します。プロトコル手順はC言語で定義されています。このモデルは、ルーティングのパフォーマンス制約の調査を可能にするために開発されましたが、インターネットマルチキャスト/リソース予約コミュニティに広く適用できるはずです。このモデルは、リソース予約マルチキャストの拡張された研究を提供するために使用できることを意図して、このモデルを公開しています。
Table of Contents
目次
1. Background 2 2. The OPNET Simulation Environment 3 3. IP Multicast Model 3 3.1 Address Format 3 3.2 Network Layer 4 3.3 Node layer 5 4. RSVP Model 13 4.1 RSVP Application 13 4.2 RSVP on Routers 14 4.3 RSVP on Hosts 17 5. Multicast Routing Model Interface 19 5.1 Creation of multicast routing processor node 19 5.2 Interfacing processor nodes 19 5.3 Interrupt Generation 21 5.4 Modifications of modules in the process model 22 6. OSPF and MOSPF Models 23 6.1 Init 23 6.2 Idle 23 6.3 BCOspfLsa 23 6.4 BCMospfLsa 23 6.5 Arr 23 6.6 Hello_pks 24 6.7 Mospfspfcalc 24 6.8 Ospfspfcalc 25 6.9 UpstrNode 25 6.10 DABRA 25 7. DVMRP Model 26 7.1 Init 26 7.2 Idle 26 7.3 Probe_Send State 26 7.4 Report_Send 26 7.5 Prune _Send 26 7.6 Graft_send 27 7.7 Arr_Pkt 27 7.8 Route_Calc 28 7.9 Timer 28 8. Simulation performance 28 9. Future Work 29 10. Security Considerations 29 11. References 29 Authors' Addresses 30 Full Copyright Statement 31
1.背景2 2. OPNETシミュレーション環境3 3. IPマルチキャストモデル3 3.1アドレス形式3 3.2ネットワークレイヤー4 3.3ノードレイヤー5 4. RSVPモデル13 4.1 RSVPアプリケーション13 4.2ルーター上のRSVP 14 4.3ホスト上のRSVP 17 5。マルチキャストルーティングモデルインターフェイス19 5.1マルチキャストルーティングプロセッサノードの作成19 5.2インターフェースプロセッサノード19 5.3割り込み生成21 5.4プロセスモデル内のモジュールの変更22 6. OSPFおよびMOSPFモデル23 6.1 Init 23 6.2 Idle 23 6.3 BCOspfLsa 23 6.4 BCMospfLsa 23 6.5 Arr 23 6.6 Hello_pks 24 6.7 Mospfspfcalc 24 6.8 Ospfspfcalc 25 6.9 UpstrNode 25 6.10 DABRA 25 7. DVMRPモデル26 7.1 Init 26 7.2 Idle 26 7.3 Probe_Send State 26 7.4 Report_Send 26 7.5 Prune _Send 26 7.6 Graft_send 27 7.7 Arr_Pkt 28 7.9 Routeタイマー28 8.シミュレーションのパフォーマンス28 9.今後の作業29 10.セキュリティに関する考慮事項29 11.参考資料29著者のアドレス30完全な著作権表記31
The successful deployment of IP multicasting [1] and its availability in the Mbone has led to continuing increase in real-time multimedia Internet applications. Because the Internet has traditionally supported only a best-effort quality of service, there is considerable interest to create mechanisms that will allow adequate resources to be reserved in networks using the Internet protocol suite, such that the quality of real-time traffic such as video, voice, and distributed simulation can be sustained at specified levels. The RSVP protocol [2] has been developed for this purpose and is the subject of ongoing implementation efforts. Although the developers of RSVP have used simulation in their design process, no simulation of IPmc with RSVP has been generally available for analysis of the performance and prediction of the behavior of these protocols. The simulation model described here was developed to fill this gap, and is explicitly intended to be made available to the IETF community.
IPマルチキャスト[1]の展開の成功とMboneでのその可用性により、リアルタイムマルチメディアインターネットアプリケーションの増加が続いています。インターネットは従来、ベストエフォート型のサービス品質のみをサポートしていたため、ビデオなどのリアルタイムトラフィックの品質が向上するように、インターネットプロトコルスイートを使用するネットワークで適切なリソースを予約できるメカニズムを作成することに大きな関心があります。 、音声、および分散シミュレーションは、指定されたレベルで維持できます。 RSVPプロトコル[2]はこの目的のために開発されたものであり、継続的な実装作業の対象となっています。 RSVPの開発者は設計プロセスでシミュレーションを使用しましたが、これらのプロトコルのパフォーマンスの分析と動作の予測にRSVPを使用したIPmcのシミュレーションは一般に利用できません。ここで説明するシミュレーションモデルは、このギャップを埋めるために開発されたものであり、IETFコミュニティが利用できるようにすることを明示的に意図しています。
The Optimized Network Engineering Tools (OPNET) is a commercial simulation product of the MIL3 company of Arlington, VA. It employs a Discrete Event Simulation approach that allows large numbers of closely-spaced events in a sizable network to be represented accurately and efficiently. OPNET uses a modeling approach where networks are built of components interconnected by perfect links that can be degraded at will. Each component's behavior is modeled as a state-transition diagram. The process that takes place in each state is described by a program in the C language. We believe this makes the OPNET-based models relatively easy to port to other modeling environments. This family of models is compatible with OPNET 3.5. The following sections describe the state-transition models and process code for the IPmc and RSVP models we have created using OPNET. Please note that an OPNET layer is not necessarily equivalent to a layer in a network stack, but shares with a stack layer the property that it is a highly modular software element with well defined interfaces.
最適化されたネットワークエンジニアリングツール（OPNET）は、バージニア州アーリントンにあるMIL3企業の商用シミュレーション製品です。離散イベントシミュレーションアプローチを採用しているため、かなり大きなネットワークで間隔の狭い多数のイベントを正確かつ効率的に表現できます。 OPNETは、モデリングアプローチを使用しており、ネットワークは、完全に低下する可能性のある完全なリンクによって相互接続されたコンポーネントで構築されています。各コンポーネントの動作は、状態遷移図としてモデル化されています。各状態で行われるプロセスは、C言語のプログラムによって記述されます。これにより、OPNETベースのモデルを他のモデリング環境に比較的簡単に移植できます。このモデルファミリーはOPNET 3.5と互換性があります。次のセクションでは、OPNETを使用して作成したIPmcモデルとRSVPモデルの状態遷移モデルとプロセスコードについて説明します。 OPNETレイヤーは必ずしもネットワークスタックのレイヤーと同等ではありませんが、明確に定義されたインターフェイスを持つ高度にモジュール化されたソフトウェア要素であることをスタックレイヤーと共有することに注意してください。
The following processing takes place in the indicated modules. Each subsection below describes in detail a layer in the host and the router that can be simulated with the help of the corresponding OPNET network layer or node layer or the process layer, starting from physical layer.
以下の処理は、示されたモジュールで行われます。以下の各サブセクションでは、物理層から始めて、対応するOPNETネットワーク層またはノード層またはプロセス層の助けを借りてシミュレートできるホストとルーターの層について詳しく説明します。
The OPNET IP model has only one type of addressing denoted by "X.Y" where X is 24 bits long and Y is 8 bits long, corresponding to an IPv4 Class C network. The X indicates the destination or the source network number and Y indicates the destination or the source node number. In our model X = 500 is reserved for multicast traffic. For multicast traffic the value of Y indicates the group to which the packet belongs.
OPNET IPモデルには、「X.Y」で示される1種類のアドレッシングしかありません。Xは24ビット長、Yは8ビット長で、IPv4クラスCネットワークに対応しています。 Xは宛先またはソースのネットワーク番号を示し、Yは宛先またはソースのノード番号を示します。このモデルでは、X = 500はマルチキャストトラフィック用に予約されています。マルチキャストトラフィックの場合、Yの値はパケットが属するグループを示します。
Figure 1 describes an example network topology built using the OPNET network editor. This network consists of two backbone routers BBR1, BBR2, three area border routers ABR1, ABR2, ABR3 and six subnets F1, through F6. As OPNET has no full duplex link model, each connecting link is modeled as two simplex links enabling bidirectional traffic.
図1は、OPNETネットワークエディターを使用して構築されたネットワークトポロジの例を示しています。このネットワークは、2つのバックボーンルーターBBR1、BBR2、3つのエリア境界ルーターABR1、ABR2、ABR3、および6つのサブネットF1からF6で構成されています。 OPNETには全二重リンクモデルがないため、各接続リンクは、双方向トラフィックを可能にする2つのシンプレックスリンクとしてモデル化されます。
[Figure 1: Network Layer of Debug Model]
[図1：デバッグモデルのネットワーク層]
The attributes of the elements of the network layer are:
ネットワーク層の要素の属性は次のとおりです。
a. Area Border Routers and Backbone Routers
a. エリアボーダールーターとバックボーンルーター
1. IP address of each active interface of each router (network_id.node_id) 2. Service rate of the IP layer (packets/sec) 3. Transmission speeds of each active interface (bits/sec)
1. 各ルーターの各アクティブインターフェイスのIPアドレス（network_id.node_id）2. IPレイヤーのサービスレート（パケット/秒）3.各アクティブインターフェイスの伝送速度（ビット/秒）
b. Subnets
b. サブネット
1. IP address of each active interface of the router in the subnet 2. IP address of the hosts in each of the subnet. 3. Service rate of the IP layer in the subnet router and the hosts.
1. サブネット2のルーターのアクティブな各インターフェイスのIPアドレス。各サブネットのホストのIPアドレス。 3.サブネットルーターとホストのIPレイヤーのサービスレート。
c. Simplex links
c. シンプレックスリンク
1. Propagation delay in the links 2. The process model to be used for simulating the simplex links (this means whether animation is included or not).
1. リンクの伝播遅延2.シンプレックスリンクのシミュレーションに使用するプロセスモデル（つまり、アニメーションが含まれているかどうか）。
Figure 2 shows the FDDI ring as used in a subnet. The subnet will have one router and one or more hosts. The router in the subnet is included to route the traffic between the FDDI ring or Ethernet in the corresponding subnet and the external network. The subnet router is connected on one end to Ethernet or FDDI ring and normally also is connected to an area border router on another interface (the area border routers may be connected to more than one backbone router). In the Ethernet all the hosts are connected to the bus, while in FDDI the hosts are interconnected in a ring as illustrated in Figure 2.
図2は、サブネットで使用されるFDDIリングを示しています。サブネットには1つのルーターと1つ以上のホストがあります。サブネット内のルーターは、対応するサブネット内のFDDIリングまたはイーサネットと外部ネットワーク間のトラフィックをルーティングするために含まれています。サブネットルーターは、一端がイーサネットまたはFDDIリングに接続され、通常は別のインターフェイスのエリアボーダールーターにも接続されています（エリアボーダールーターは複数のバックボーンルーターに接続されている場合があります）。イーサネットでは、すべてのホストがバスに接続されますが、FDDIでは、ホストは図2に示すようにリングで相互接続されます。
[Figure 2: FDDI Ring Subnet Layer]
[図2：FDDIリングサブネットレイヤー]
FDDI provides general purpose networking at 100 Mb/sec transmission rates for large numbers of communicating stations configured in a ring topology. Use of ring bandwidth is controlled through a timed token rotation protocol, wherein stations must receive a token and meet with a set of timing and priority criteria before transmitting frames. In order to accommodate network applications in which response times are critical, FDDI provides for deterministic availability of ring bandwidth by defining a synchronous transmission service. Asynchronous frame transmission requests dynamically share the remaining ring bandwidth.
FDDIは、リングトポロジで構成された多数の通信ステーションに対して、100 Mb /秒の伝送速度で汎用ネットワーキングを提供します。リング帯域幅の使用は、タイムドトークンローテーションプロトコルによって制御されます。ステーションはトークンを受信し、フレームを送信する前に一連のタイミングと優先度の基準を満たす必要があります。応答時間が重要なネットワークアプリケーションに対応するために、FDDIは同期送信サービスを定義することにより、リング帯域幅の確定的な可用性を提供します。非同期フレーム送信要求は、残りのリング帯域幅を動的に共有します。
Ethernet is a bus-based local area network (LAN) technology. The operation of the LAN is managed by a media access protocol (MAC) following the IEEE 802.3 standard, providing Carrier Sense Multiple Access with Collision Detection (CSMA/CD) for the LAN channel.
イーサネットは、バスベースのローカルエリアネットワーク（LAN）テクノロジです。 LANの動作は、IEEE 802.3標準に準拠したメディアアクセスプロトコル（MAC）によって管理され、LANチャネルに衝突検出（CSMA / CD）を備えたキャリア検知多重アクセスを提供します。
This section discusses the internal structure of hosts and routers with the help of node level illustrations built using the Node editor of OPNET.
このセクションでは、OPNETのノードエディターを使用して作成されたノードレベルの図を使用して、ホストとルーターの内部構造について説明します。
The basic elements of a node level illustration are
ノードレベルの図の基本的な要素は次のとおりです。
a. Processor nodes: Processor nodes are used for processing incoming packets and generating packets with a specified packet format.
a. プロセッサノード：プロセッサノードは、着信パケットを処理し、指定されたパケット形式でパケットを生成するために使用されます。
b. Queue node: Queue nodes are a superset of processor nodes. In addition to the capabilities of processor nodes, queue nodes also have capability to store packets in one or more queues.
b. キューノード：キューノードは、プロセッサノードのスーパーセットです。プロセッサノードの機能に加えて、キューノードには1つ以上のキューにパケットを格納する機能もあります。
c. Transmitter and Receiver nodes: Transmitters simulate the link behavior effect of packet transmission and Receivers simulate the receiving effects of packet reception. The transmission rate is an attribute of the transmitter and receiving rate is an attribute of the receiver. These values together decide the transmission delay of a packet.
c. 送信機ノードと受信機ノード：送信機はパケット送信のリンク動作効果をシミュレートし、受信機はパケット受信の受信効果をシミュレートします。送信レートは送信機の属性であり、受信レートは受信機の属性です。これらの値により、パケットの伝送遅延が決まります。
d. Packet streams: Packet streams are used to interconnect the above described nodes.
d. パケットストリーム：パケットストリームは、上記のノードを相互接続するために使用されます。
e. Statistic streams: Statistic streams are used to convey information between the different nodes: Processor, Queue, Transmitters and Receivers nodes respectively.
e. 統計ストリーム：統計ストリームは、さまざまなノード間で情報を伝達するために使用されます。それぞれ、プロセッサー、キュー、トランスミッター、レシーバーノードです。
The host model built using OPNET has a layered structure. Different from the OPNET layers (Network, Node and Process layer) that describe the network at different levels, protocol stack elements are implemented at OPNET nodes. Figure 3 shows the node level structure of a FDDI host.
OPNETを使用して構築されたホストモデルは、階層構造になっています。異なるレベルでネットワークを記述するOPNETレイヤー（ネットワーク、ノード、プロセスレイヤー）とは異なり、プロトコルスタック要素はOPNETノードに実装されます。図3は、FDDIホストのノードレベルの構造を示しています。
[Figure 3: Node Level of Host]
[図3：ホストのノードレベル]
a. MAC queue node: The MAC interfaces on one side to the physical layer through the transmitter (phy_tx) and receiver (phy_rx) and also provides services to the IP layer. Use of ring bandwidth is controlled through a timed token rotation protocol, wherein hosts must receive a token and meet with a set of timing and priority criteria before transmitting frames. When a frame arrives at the MAC node, the node performs one of the following actions:
a. MACキューノード：MACは、トランスミッター（phy_tx）とレシーバー（phy_rx）を介して物理層に接続し、IP層にサービスを提供します。リング帯域幅の使用は、時限トークンローテーションプロトコルによって制御されます。この場合、ホストはトークンを受信し、フレームを送信する前に一連のタイミングと優先度の基準を満たす必要があります。フレームがMACノードに到着すると、ノードは次のいずれかのアクションを実行します。
1. If the owner of the frame is this MAC, the MAC layer destroys the frame since the frame has finished circulating through the FDDI ring. 2. if the frame is destined for this host, the MAC layer makes a copy of the frame, decapsulates the frame and sends the descapsulated frame (packet) to the IP layer. The original frame is transmitted to the next host in the FDDI ring 3. if the owner of the frame is any other host and the frame is not destined for this host, the frame is forwarded to the adjacent host.
1. フレームの所有者がこのMACである場合、フレームがFDDIリングの循環を終了したため、MAC層はフレームを破棄します。 2.フレームの宛先がこのホストの場合、MAC層はフレームのコピーを作成し、フレームをカプセル化解除して、カプセル化解除されたフレーム（パケット）をIP層に送信します。元のフレームはFDDIリング3の次のホストに送信されます。フレームの所有者が他のホストであり、フレームがこのホスト宛てでない場合、フレームは隣接ホストに転送されます。
b. ADDR_TRANS processor node: The next layer above the MAC layer is the addr_trans processor node. This layer provides service to the IP layer by carrying out the function of translating the IP address to physical interface address. This layer accepts packets from the IP layer with the next node information, maps the next node information to a physical address and forwards the packet for transmission. This service is required only in one direction from the IP layer to the MAC layer. Since queuing is not done at this level, a processor node is used to accomplish the address translation function, from IP to MAC address (ARP).
b. ADDR_TRANSプロセッサノード：MAC層の上の次の層はaddr_transプロセッサノードです。この層は、IPアドレスを物理インターフェイスアドレスに変換する機能を実行することにより、IP層にサービスを提供します。この層は、次のノード情報を持つIP層からのパケットを受け入れ、次のノード情報を物理アドレスにマップし、パケットを転送して転送します。このサービスは、IP層からMAC層への一方向でのみ必要です。このレベルではキューイングは行われないため、IPからMACアドレス（ARP）へのアドレス変換機能を実行するためにプロセッサノードが使用されます。
c. IP queue node: Network routing/forwarding in the hierarchy is implemented here. IP layer provides service for the layers above which are the different higher level protocols by utilizing the services provided by the MAC layer. For packets arriving from the MAC layer, the IP layer decapsulates the packet and forwards the information to an upper layer protocol based upon the value of the protocol ID in the IP header. For packets arriving from upper layer protocols, the IP layer obtains the destination address, calculates the next node address from the routing table, encapsulates it with a IP header and forwards the packet to the addr_trans node with the next node information.
c。 IPキューノード：階層内のネットワークルーティング/転送がここに実装されます。 IP層は、MAC層によって提供されるサービスを利用することにより、上位層の異なるプロトコルにサービスを提供します。 MAC層から到着するパケットの場合、IP層はパケットのカプセル化を解除し、IPヘッダーのプロトコルIDの値に基づいて情報を上位層プロトコルに転送します。上位層プロトコルから到着するパケットの場合、IP層は宛先アドレスを取得し、ルーティングテーブルから次のノードアドレスを計算し、それをIPヘッダーでカプセル化して、次のノード情報とともにパケットをaddr_transノードに転送します。
The IP node is a queue node. It is in this layer that packets incur delay which simulates the processing capability of a host and queueing for use of the outgoing link. A packet arrival to the IP layer will be queued and experience delay when it finds another packet already being transmitted, plus possibly other packets queued for transmission. The packets arriving at the IP layer are queued and operate with a first-in first-out (FIFO) discipline. The queue size, service rate of the IP layer are both promoted attributes, specified at the simulation run level by the environment file.
IPノードはキューノードです。ホストの処理能力と発信リンクの使用のためのキューイングをシミュレートするパケットで遅延が発生するのはこの層です。 IP層へのパケットの到着はキューに入れられ、すでに送信されている別のパケットと、場合によっては送信のためにキューに入れられている他のパケットを検出すると、遅延が発生します。 IP層に到着したパケットはキューに入れられ、先入れ先出し（FIFO）規則で動作します。キューサイズ、IPレイヤーのサービスレートは両方とも昇格された属性であり、シミュレーション実行レベルで環境ファイルによって指定されます。
d. IGMP processor node: The models described above are standard components available in OPNET libraries. We have added to these the host multicast protocol model IGMP_host, the router multicast model IGMP_gwy, and the unicast best-effort protocol model UBE.
d. IGMPプロセッサノード：上記のモデルは、OPNETライブラリで利用可能な標準コンポーネントです。これらに、ホストマルチキャストプロトコルモデルIGMP_host、ルーターマルチキャストモデルIGMP_gwy、およびユニキャストベストエフォートプロトコルモデルUBEを追加しました。
The IGMP_host node (Figure 4) is a process node. Packets are not queued in this layer. IGMP_host provides unique group management services for the multicast applications utilizing the services provided by the IP layer. IGMP_host maintains a single table which consists of group membership information of the application above the IGMP layer. The function performed by the IGMP_host layer depends upon the type of the packet received and the source of the packet.
IGMP_hostノード（図4）はプロセスノードです。パケットはこの層のキューには入れられません。 IGMP_hostは、IPレイヤーによって提供されるサービスを利用するマルチキャストアプリケーションに固有のグループ管理サービスを提供します。 IGMP_hostは、IGMPレイヤーの上のアプリケーションのグループメンバーシップ情報で構成される単一のテーブルを維持します。 IGMP_hostレイヤーによって実行される機能は、受信したパケットのタイプとパケットのソースによって異なります。
[Figure 4: IGMP process on hosts]
[図4：ホストのIGMPプロセス]
The IGMP_host layer expects certain type of packets from the application layer and from the network:
IGMP_hostレイヤーは、アプリケーションレイヤーおよびネットワークからの特定のタイプのパケットを予期します。
1. Accept join group requests from the application layer (which can be one or more applications): IGMP_host maintains a table which consists of the membership information for each group. When a application sends a join request, it requests to join a specific group N. The membership information is updated. This new group membership information has to be conveyed to the nearest router and to the MAC layer. If the IGMP_host is already a member ofthis group (i.e. if another application above the IGMP_host is a member of the group N), the IGMP_host does not have to send a message to the router or indicate to the MAC layer. If the IGMP_host is not a member currently, the IGMP_host generates a join request for the group N (this is called a "response" in RFC 1112) and forwards it to the IP layer to be sent to the nearest router. In addition the IGMP_host also conveys this membership information to the MAC layer interfacing to the physical layer through the OPNET "statistic wire" connected from the IGMP_host to the MAC layer, so that the MAC layer knows the membership information immediately and begins to accept the frames destined for the group N. (An OPNET statistic wire is a virtual path to send information between OPNET models.) 2. Accept queries arriving from the nearest router and send responses based on the membership information in the multicast table at the IGMP_host layer: A query is a message from a router inquiring each host on the router's interface about group membership information. When the IGMP_host receives a query, it looks up the multicast group membership table, to determine if any of the host's applications are registered for any group. If any registration exists, the IGMP_host schedules an event to generate a response after a random amount of time corresponding to each active group. The Ethernet example in Figure 5 and the description in the following section describes the scenario.
1.アプリケーション層（1つ以上のアプリケーション）からのグループ参加要求を受け入れる：IGMP_hostは、各グループのメンバーシップ情報で構成されるテーブルを維持します。アプリケーションが参加要求を送信すると、特定のグループNへの参加を要求します。メンバーシップ情報が更新されます。この新しいグループメンバーシップ情報は、最も近いルーターとMAC層に伝達する必要があります。 IGMP_hostがすでにこのグループのメンバーである場合（つまり、IGMP_hostの上の別のアプリケーションがグループNのメンバーである場合）、IGMP_hostはメッセージをルーターに送信したり、MACレイヤーに示したりする必要はありません。 IGMP_hostが現在メンバーではない場合、IGMP_hostはグループNの参加要求（これはRFC 1112では「応答」と呼ばれます）を生成し、IP層に転送して最も近いルーターに送信します。さらに、IGMP_hostは、このメンバーシップ情報をMACレイヤーに伝え、IGMP_hostからMACレイヤーに接続されたOPNETの「統計ワイヤー」を介して物理レイヤーに接続します。これにより、MACレイヤーはメンバーシップ情報を即座に認識し、フレームの受け入れを開始します。グループN宛てです。（OPNET統計ワイヤは、OPNETモデル間で情報を送信するための仮想パスです。）2.最寄りのルーターから到着するクエリを受け入れ、IGMP_hostレイヤーのマルチキャストテーブルのメンバーシップ情報に基づいて応答を送信します。クエリは、グループメンバーシップ情報についてルーターのインターフェイス上の各ホストに問い合わせるルーターからのメッセージです。 IGMP_hostはクエリを受信すると、マルチキャストグループメンバーシップテーブルを検索して、ホストのアプリケーションがグループに登録されているかどうかを判断します。登録が存在する場合、IGMP_hostは、各アクティブグループに対応するランダムな時間の後に応答を生成するようにイベントをスケジュールします。図5のイーサネットの例と次のセクションの説明では、シナリオについて説明しています。
---------------------------------------
| | | |
| | | |
+---+ +---+ +---+ +---+
| H1| | H2| | H3| | R |
+---+ +---+ +---+ +---+
Figure 5: An Ethernet example of IGMP response schedule
図5：IGMP応答スケジュールのイーサネットの例
The router R interfaces with the subnet on one interface I1 and to reach the hosts. To illustrate this let us assume that hosts H1 and H3 are members of group N1 and H2 is a member of group N2. When the router sends a query, all the hosts receive the query at the same time t0. IGMP_host in H1 schedules an event to generate a response at a randomly generated time t1 (t1 >= t0) which will indicate the host H1 is a member of group N1. Similarly H2 will schedule an event to generate a response at t2 (t2 >= t0)to indicate membership in group N2 and H3 at t3 (t3 >= t0) to indicate membership in group N3. When the responses are generated, the responses are sent with destination address set to the multicast group address. Thus all member hosts of a group will receive the responses sent by the other hosts in the subnet who are members of the same group.
ルータRは、1つのインターフェイスI1上のサブネットとインターフェイスして、ホストに到達します。これを説明するために、ホストH1とH3がグループN1のメンバーであり、H2がグループN2のメンバーであると仮定します。ルータがクエリを送信すると、すべてのホストが同じ時間t0にクエリを受信します。 H1のIGMP_hostは、ランダムに生成された時間t1（t1> = t0）で応答を生成するようにイベントをスケジュールします。これは、ホストH1がグループN1のメンバーであることを示します。同様に、H2はイベントをスケジュールして、グループN2のメンバーシップを示すt2（t2> = t0）で応答を生成し、グループN3のメンバーシップを示すt3（t3> = t0）でH3を生成します。応答が生成されると、宛先グループアドレスがマルチキャストグループアドレスに設定されて応答が送信されます。したがって、グループのすべてのメンバーホストは、同じグループのメンバーであるサブネット内の他のホストから送信された応答を受信します。
In the above example if t1 < t3, IGMP_host in H1 will generate a response to update the membership in group N1 before H3 does and H3 will also receive this response in addition to the router. When IGMP_host in H3 receives the response sent by H1, IGMP_host in H3 cancels the event scheduled at time t3, since a response for that group has been sent to the router. To make this work, the events to generate response to queries are scheduled randomly, and the interval for scheduling the above described event is forced to be less than the interval at which router sends the queries. 3. Accept responses sent by the other hosts in the subnet if any application layer is a member of the group to which the packet is destined. 4. Accept terminate group requests from the Application layer. These requests are generated by application layer when a application decides to leave a group. The IGMP_host updates the group information table and subsequently will not send any response corresponding to this group (unless another application is a member of this group). When a router does not receive any response for a group in certain amount of time on a specific interface, membership of that interface is canceled in that group.
上記の例では、t1 <t3の場合、H1のIGMP_hostは、H3が行う前にグループN1のメンバーシップを更新する応答を生成し、H3はルーターに加えてこの応答も受信します。 H3のIGMP_hostがH1によって送信された応答を受信すると、H3のIGMP_hostは、そのグループの応答がルーターに送信されているため、時刻t3にスケジュールされたイベントをキャンセルします。これを機能させるために、クエリへの応答を生成するイベントはランダムにスケジュールされ、上記のイベントをスケジュールする間隔は、ルーターがクエリを送信する間隔よりも短くなるように強制されます。 3.いずれかのアプリケーション層がパケットの宛先であるグループのメンバーである場合、サブネット内の他のホストによって送信された応答を受け入れます。 4.アプリケーション層からのグループ終了要求を受け入れます。これらの要求は、アプリケーションがグループを脱退することを決定したときに、アプリケーション層によって生成されます。 IGMP_hostはグループ情報テーブルを更新し、その後、このグループに対応する応答を送信しません（別のアプリケーションがこのグループのメンバーでない限り）。ルーターが特定のインターフェースで一定時間内にグループの応答を受信しない場合、そのインターフェースのメンバーシップはそのグループでキャンセルされます。
e. Unicast best-effort (UBE) processor node: This node is used to generate a best effort traffic in the Internet based on the User Datagram Protocol (UDP). The objective of this node is to model the background traffic in a network. This traffic does not use the services provided by RSVP. UBE node aims to create the behaviors observed in a network which has one type of application using the services provided by RSVP to achieve specific levels of QoS and the best effort traffic which uses the services provided by only the underlying IP.
e. ユニキャストベストエフォート（UBE）プロセッサノード：このノードは、ユーザーデータグラムプロトコル（UDP）に基づいてインターネットでベストエフォートトラフィックを生成するために使用されます。このノードの目的は、ネットワークのバックグラウンドトラフィックをモデル化することです。このトラフィックは、RSVPによって提供されるサービスを使用しません。 UBEノードは、RSVPによって提供されるサービスを使用する1つのタイプのアプリケーションを備えたネットワークで観察される動作を作成し、QoSの特定のレベルと、基礎となるIPのみによって提供されるサービスを使用するベストエフォートトラフィックを実現することを目的としています。
The UBE node generates traffic to a randomly generated IP address so as to model competing traffic in the network from applications such as FTP. The packets generated are sent to the IP layer which routes the packet based upon the information in the routing table. The attributes of the UBE node are:
UBEノードは、ランダムに生成されたIPアドレスへのトラフィックを生成して、FTPなどのアプリケーションからのネットワーク内の競合するトラフィックをモデル化します。生成されたパケットは、ルーティングテーブルの情報に基づいてパケットをルーティングするIP層に送信されます。 UBEノードの属性は次のとおりです。
1. Session InterArrival Time (IAT): is the variable used to schedule an event to begin a session. The UBE node generates an exponentially distributed random variable with mean Session IAT and begins to generate data traffic at that time. 2. Data IAT: When the UBE generates data traffic, the interarrival times between data packets is Data IAT. A decrease in the value of Data IAT increases the severity of congestion in the network. 3. Session-min and Session-max: When the UBE node starts generating data traffic it remains in that session for a random period which is uniformly distributed between Session-min and Session-max.
1. セッション到着間時間（IAT）：セッションを開始するイベントをスケジュールするために使用される変数です。 UBEノードは、平均セッションIATで指数分布するランダム変数を生成し、その時点でデータトラフィックの生成を開始します。 2.データIAT：UBEがデータトラフィックを生成するとき、データパケット間の到着時間はデータIATです。データIATの値が減少すると、ネットワークの輻輳の深刻度が増加します。 3.セッション最小とセッション最大：UBEノードがデータトラフィックの生成を開始すると、セッション最小とセッション最大の間で均一に分散されるランダムな期間、そのセッションにとどまります。
f. Multicast Application processor node: The application layer consists of one or more application nodes which are process nodes. These nodes use the services provided by lower layer protocols IGMP, RSVP and IP. The Application layer models the requests and traffic generated by Application layer programs. Attributes of the application layer are: 1. Session IAT: is the variable used to schedule an event to begin a session. The Application node generates an exponentially distributed random variable with mean Session IAT and begins to generate information for a specific group at that time and also accept packets belonging to that group. 2. Data IAT: When Application node generates data traffic, the inter arrival time between the packets uses Data IAT variable as the argument. The distribution can be any of the available distribution functions in OPNET. 3. Session-min and Session-max: When an application joins a session the duration for which the application stays in that session is bounded by Session-min and Session-max. A uniformly distributed random variable between Session-min and Session-max is generated for this purpose. At any given time each node will have zero or one flow(s) of data. 4. NGRPS: This variable is used by the application generating multicast traffic to bound the value of the group to which an application requests the IGMP to join. The group is selected at random from the range [0,NGRPS-1].
f。マルチキャストアプリケーションプロセッサノード：アプリケーション層は、プロセスノードである1つ以上のアプリケーションノードで構成されます。これらのノードは、下位層プロトコルIGMP、RSVP、およびIPによって提供されるサービスを使用します。アプリケーション層は、アプリケーション層プログラムによって生成された要求とトラフィックをモデル化します。アプリケーション層の属性は次のとおりです。1.セッションIAT：イベントをスケジュールしてセッションを開始するために使用される変数です。アプリケーションノードは、平均セッションIATで指数分布するランダム変数を生成し、その時点で特定のグループの情報を生成し始め、そのグループに属するパケットも受け入れます。 2.データIAT：アプリケーションノードがデータトラフィックを生成するとき、パケット間の到着時間は引数としてデータIAT変数を使用します。配布は、OPNETで使用可能な任意の配布関数にすることができます。 3. Session-minとSession-max：アプリケーションがセッションに参加するとき、アプリケーションがそのセッションに留まる期間は、Session-minとSession-maxによって制限されます。この目的のために、Session-minとSession-maxの間で一様に分布するランダム変数が生成されます。常に、各ノードにはゼロまたは1つのデータフローがあります。 4. NGRPS：この変数は、アプリケーションがIGMPの参加を要求するグループの値をバインドするために、マルチキャストトラフィックを生成するアプリケーションによって使用されます。グループは[0、NGRPS-1]の範囲からランダムに選択されます。
[Figure 6: Node Level of Gateway]
[図6：ゲートウェイのノードレベル]
There are two types of routers in the model, a router serving a subnet and a backbone router. A subnet router has all the functions of a backbone router and in addition also has a interface to the underlying subnet which can be either a FDDI network or a Ethernet subnet. In the following section the subnet router will be discussed in detail.
モデルには2種類のルーターがあり、サブネットにサービスを提供するルーターとバックボーンルーターです。サブネットルーターは、バックボーンルーターのすべての機能を備えており、さらにFDDIネットワークまたはイーサネットサブネットのいずれかである可能性のある基礎となるサブネットへのインターフェイスも備えています。次のセクションでは、サブネットルーターについて詳しく説明します。
Figure 6 shows the node level model of a subnet router.
図6は、サブネットルーターのノードレベルモデルを示しています。
a. The queueing technique implemented in the router is a combination of input and output queueing. The nodes rx1 to rx10 are the receivers connected to incoming links. The router in Figure 6 has a physical interface to the FDDI ring or Ethernet, which consists of the queue node MAC, transmitter phy_tx, and the receiver phy_rx. The backbone routers will not have a MAC layer. The services provided and the functions of the MAC layer are the same as the MAC layer in the host discussed above.
a. ルータに実装されているキューイング技術は、入力キューイングと出力キューイングを組み合わせたものです。ノードrx1からrx10は、着信リンクに接続されたレシーバーです。図6のルーターには、FDDIリングまたはイーサネットへの物理インターフェースがあり、キューノードMAC、トランスミッターphy_tx、レシーバーphy_rxで構成されています。バックボーンルーターにはMACレイヤーはありません。提供されるサービスとMAC層の機能は、前述のホストのMAC層と同じです。
There is one major difference between the MAC node in a subnet router and that in a host. The MAC node in a subnet router accepts all arriving multicast packets unlike the MAC in a host which accepts only the multicast packets for groups of which the host is a member. For this reason the statistic wire from the IGMP to MAC layer does not exist in a router (also because a subnet router does not have an application layer).
サブネットルーターのMACノードとホストのMACノードには大きな違いが1つあります。ホストがメンバーであるグループのマルチキャストパケットのみを受け入れるホストのMACとは異なり、サブネットルーターのMACノードは、到着するすべてのマルチキャストパケットを受け入れます。このため、IGMPからMAC層への統計ワイヤはルーターには存在しません（サブネットルーターにアプリケーション層がないため）。
b. Addr_trans: The link layer in the router hierarchy is the addr_trans processor node which provides the service of translating the IP address to a physical address. The addr_trans node was described above under the host model.
b. Addr_trans：ルータ階層のリンク層は、IPアドレスを物理アドレスに変換するサービスを提供するaddr_transプロセッサノードです。 addr_transノードについては、ホストモデルで説明しています。
c. IP layer: The router IP layer which provides services to the upper layer transport protocols and also performs routing based upon the information in the routing table. The IP layer maintains two routing tables and one group membership table.
c. IP層：上位層のトランスポートプロトコルにサービスを提供し、ルーティングテーブルの情報に基づいてルーティングを実行するルーターIP層。 IP層は、2つのルーティングテーブルと1つのグループメンバーシップテーブルを保持します。
The tables used by the router model are:
ルーターモデルで使用されるテーブルは次のとおりです。
1. Unicast routing table: This table is an single array of one dimension, which is used to route packets generated by the UDP process node in the hosts. If no route is known to a particular IP address, the corresponding entry is set to a default route. 2. Multicast routing table: This table is a N by I array where N is the maximum number of multicast groups in the model and I is the number of interfaces in the router. This table is used to route multicast packets. The routing table in a router is set by an upper layer routing protocol (see section 4 below). When the IP layer receives a multicast packet with a session_id corresponding to a session which is utilizing the MOSFP, it looks up the multicast routing table to obtain the next hop. 3. Group membership table: This table is used to maintain group membership information of all the interfaces of the router. This table which is also an N by I array is set by the IGMP layer protocol. The routing protocols use this information in the group membership table to calculate and set the routes in the Multicast routing table.
1.ユニキャストルーティングテーブル：このテーブルは、1次元の単一配列であり、ホストのUDPプロセスノードによって生成されたパケットをルーティングするために使用されます。特定のIPアドレスへのルートがわからない場合、対応するエントリはデフォルトルートに設定されます。 2.マルチキャストルーティングテーブル：このテーブルはN x Iの配列です。Nはモデル内のマルチキャストグループの最大数であり、Iはルーター内のインターフェイスの数です。このテーブルは、マルチキャストパケットのルーティングに使用されます。ルーターのルーティングテーブルは、上位層のルーティングプロトコルによって設定されます（以下のセクション4を参照）。 IP層は、MOSFPを利用しているセッションに対応するsession_idを持つマルチキャストパケットを受信すると、マルチキャストルーティングテーブルを検索して次のホップを取得します。 3.グループメンバーシップテーブル：このテーブルは、ルーターのすべてのインターフェイスのグループメンバーシップ情報を維持するために使用されます。 N x Iアレイでもあるこのテーブルは、IGMP層プロトコルによって設定されます。ルーティングプロトコルは、グループメンバーシップテーブルのこの情報を使用して、マルチキャストルーティングテーブルのルートを計算および設定します。
Sub-queues: The IP node has three subqueues, which implement queuing based upon the priority of arriving packets from the neighboring routers or the underlying subnet. The queue with index 0 has the highest priority. When a packet arrives at the IP node, the packets are inserted into the appropriate sub-queue based on the priority of their traffic category: control traffic, resource- reserved traffic, or best effort traffic. A non-preemptive priority is used in servicing the packets. After the servicing, packets are sent to the one of the output queues or the MAC. The packets progress through these queues until the transmitter becomes available.
サブキュー：IPノードには3つのサブキューがあり、隣接するルーターまたは基になるサブネットから到着するパケットの優先度に基づいてキューイングを実装します。インデックス0のキューが最も優先されます。パケットがIPノードに到着すると、パケットは、そのトラフィックカテゴリの優先度（制御トラフィック、リソース予約トラフィック、またはベストエフォートトラフィック）に基づいて、適切なサブキューに挿入されます。パケットの処理では、非プリエンプティブな優先度が使用されます。サービス後、パケットは出力キューの1つまたはMACに送信されます。トランスミッタが使用可能になるまで、パケットはこれらのキューを通過します。
Attributes of the IP node are:
IPノードの属性は次のとおりです。
1. Unique IP address for each interface (a set of transmitter and receiver constitute an interface). 2. Service rate: the rate with which packets are serviced at the router. 3. Queue size: size of each of the sub queues used to store incoming packets based on the priority can be specified individually
1. 各インターフェースに固有のIPアドレス（送信機と受信機のセットがインターフェースを構成します）。 2.サービスレート：パケットがルーターで処理されるレート。 3.キューサイズ：優先度に基づいて着信パケットを格納するために使用される各サブキューのサイズを個別に指定できます。
d. Output queues: The output queues perform the function of queueing the packets received by the IP layer when the transmitter is busy. A significant amount of queuing takes place in the output queues only if the throughput of the IP node approaches the transmission capacity of the links. The only attribute of the queue node is:
d. 出力キュー：出力キューは、トランスミッタがビジー状態のときにIPレイヤーが受信したパケットをキューに入れる機能を実行します。 IPノードのスループットがリンクの伝送容量に近づいた場合にのみ、出力キューで大量のキューイングが行われます。キューノードの唯一の属性は次のとおりです。
Queue size: size of the queue in each queue node. If the queue is full when a packet is received, that packet is dropped.
キューサイズ：各キューノードのキューのサイズ。パケットを受信したときにキューがいっぱいの場合、そのパケットはドロップされます。
e. IGMP Node: Also modeled in the router is the IGMP for implementing multicasting, the routing protocol, and RSVP for providing specific QoS setup.
e. IGMPノード：ルータでは、マルチキャストを実装するためのIGMP、ルーティングプロトコル、および特定のQoS設定を提供するためのRSVPもモデル化されています。
The IGMP node implements the IGMP protocol as defined in RFC 1112. The IGMP node at a router (Figure 7) is different from the one at a host. The functions of the IGMP node at a router are:
IGMPノードは、RFC 1112で定義されているIGMPプロトコルを実装します。ルーター（図7）のIGMPノードは、ホストのIGMPノードとは異なります。ルータのIGMPノードの機能は次のとおりです。
1. IGMP node at a router sends queries at regular intervals on all its interfaces. 2. When IGMP receives a response to the queries sent, IGMP updates the multicast Group membership table in the IP node and triggers on MOSPF LSA update. 3. Every time the IGMP sends a query, it also updates the multicast group membership table in the IP node if no response has been received on for the group on any interface, indicating that a interface is no longer a member of that group. This update is done only on entries which indicate an active membership for a group on a interface where the router has not received a response for the last query sent. 4. The routing protocol (see ection 4 below) uses the information in the group membership table to calculate the routes and update the multicast routing table. 5. When the IGMP receives a query (an IGMP at router can receive a query from a directly connected neighboring router), the IGMP node creates a response for each of the groups it is a member of on all the interfaces except the one through which the query was received. 6. The IGMP node on a backbone router is disabled, because IGMP is only used when a router has hosts on its subnet.
1. ルーターのIGMPノードは、そのすべてのインターフェイスで定期的にクエリを送信します。 2.送信されたクエリに対する応答をIGMPが受信すると、IGMPはIPノードのマルチキャストグループメンバーシップテーブルを更新し、MOSPF LSA更新でトリガーします。 3. IGMPがクエリを送信するたびに、インターフェイス上のグループに対する応答が受信されなかった場合、IPノードのマルチキャストグループメンバーシップテーブルも更新されます。これは、インターフェイスがそのグループのメンバーではなくなったことを示します。この更新は、ルーターが最後に送信されたクエリに対する応答を受信していないインターフェイス上のグループのアクティブなメンバーシップを示すエントリに対してのみ行われます。 4.ルーティングプロトコル（以下のセクション4を参照）は、グループメンバーシップテーブルの情報を使用してルートを計算し、マルチキャストルーティングテーブルを更新します。 5. IGMPがクエリを受信すると（ルーターのIGMPは直接接続された隣接ルーターからクエリを受信できます）、IGMPノードは、それがメンバーとなっている各グループに対して応答を作成します。クエリを受け取りました。 6. IGMPは、ルーターがサブネット上にホストを持っている場合にのみ使用されるため、バックボーンルーターのIGMPノードは無効になっています。
[Figure 7: IGMP process on routers]
[図7：ルーターのIGMPプロセス]
The current version of the RSVP model supports only fixed-filter reservation style. The following processing takes place in the indicated modules. The model is current with [2].
RSVPモデルの現在のバージョンは、固定フィルター予約スタイルのみをサポートしています。以下の処理は、示されたモジュールで行われます。モデルは[2]の最新バージョンです。
Initializes all variables and loads the distribution functions for Multicast Group IDs, Data, termination of the session. Transit to Idle state after completing all the initializations.
すべての変数を初期化し、マルチキャストグループID、データ、セッションの終了の配信機能をロードします。すべての初期化が完了したら、アイドル状態に遷移します。
This state has transitions to two states, Join and Data_Send. It transit to Join state at the time that the application is scheduled to join a session or terminate the current session, transit to Data_Send state when the application is going to send data.
この状態には、JoinとData_Sendの2つの状態への遷移があります。アプリケーションがセッションに参加するか、現在のセッションを終了するようにスケジュールされているときにJoin状態に遷移し、アプリケーションがデータを送信するときにData_Send状態に遷移します。
The Application will send a session call to local RSVP daemon. In response it receives the session Id from the Local daemon. This makes a sender or receiver call. The multicast group id is selected randomly from a uniform distribution. While doing a sender call the application will write all its sender information in a global session directory.
アプリケーションは、ローカルRSVPデーモンにセッションコールを送信します。それに応じて、ローカルデーモンからセッションIDを受け取ります。これにより、送信者または受信者が呼び出されます。マルチキャストグループIDは、一様分布からランダムに選択されます。送信者呼び出しを行っている間、アプリケーションはそのすべての送信者情報をグローバルセッションディレクトリに書き込みます。
If the application is acting as a receiver it will check for the sender information in the session directory for the multicast group that it wants to join to and make a receive call to the local RSVP daemon. Along with the session and receive calls, it makes an IGMP join call.
アプリケーションがレシーバーとして機能している場合、アプリケーションは、参加したいマルチキャストグループのセッションディレクトリ内のセンダー情報を確認し、ローカルRSVPデーモンに受信呼び出しを行います。セッションと受信呼び出しとともに、IGMP参加呼び出しを行います。
If the application chooses to terminate the session to which it was registered, it will send a release call to the local RSVP daemon and a terminate call to IGMP daemon. After completing these functions it will return to the idle state.
アプリケーションが登録されたセッションを終了することを選択した場合、アプリケーションはローカルRSVPデーモンにリリースコールを送信し、IGMPデーモンに終了コールを送信します。これらの機能を完了すると、アイドル状態に戻ります。
[Figure 8: RSVP process on routers]
[図8：ルーターのRSVPプロセス]
Creates a data packet and sends it to a multicast destination that it selects. It update a counter to keep track of how many packets that it has sent. This state on default returns to Idle state.
データパケットを作成し、選択したマルチキャスト宛先に送信します。送信したパケットの数を追跡するためにカウンターを更新します。デフォルトのこの状態は、アイドル状態に戻ります。
Figure 8 shows the process model of RSVP on routers.
図8は、ルーター上のRSVPのプロセスモデルを示しています。
This state calls a function called RouterInitialize which will initialize all the router variables. This state will go to Idle state after completing these functions.
この状態は、すべてのルーター変数を初期化するRouterInitializeと呼ばれる関数を呼び出します。これらの機能が完了すると、この状態はアイドル状態になります。
Idle state transit to Arr state upon receiving a packet.
パケットを受信すると、アイドル状態はArr状態に遷移します。
This state checks for the type of the packet arrived and calls the appropriate function depending on the type of message received.
この状態は、到着したパケットのタイプをチェックし、受信したメッセージのタイプに応じて適切な関数を呼び出します。
a. PathMsgPro: This function was invoked by the Arr state when a path message is received. Before it was called, OSPF routing had been recomputed to get the latest routing table for forwarding the Path Message.
a. PathMsgPro：この関数は、パスメッセージが受信されたときにArr状態によって呼び出されました。それが呼び出される前に、OSPFルーティングは、パスメッセージを転送するための最新のルーティングテーブルを取得するために再計算されていました。
1. It first checks for a Path state block which has a matching destination address and if the sender port or sender address or destination port does not match the values of the Session object of the Path state block, it sends an path error message and returns. (At present the application does not send any error messages, we print this error message on the console.) 2. If a PSB is found whose Session Object and Sender Template Object matches with that of the path message received, the current PSB becomes the forwarding PSB. 3. Search for the PSB whose session and sender template matches the corresponding objects in the path message and whose incoming interface matches the IncInterface. If such a PSB is found and the if the Previous Hop Address, Next Hop Address, and SenderTspec Object doesn't match that of path message then the values of path message is copied into the path state block and Path Refresh Needed flag is turned on. If the Previous Hop Address, Next Hop Address of PSB differs from the path message then the Resv Refresh Needed flag is also turned on, and the Current PSB is made equal to this PSB. 4. If a matching PSB is not found then a new PSB is created and and Path Refresh Needed Flag is turned on, and the Current PSB is made equal to this PSB. 5. If Path Refresh Needed Flag is on, Current PSB is copied into forwarding PSB and Path Refresh Sequence is executed. To execute this function called PathRefresh is used. Path Refresh is sent to every interface that is in the outgoing interfaces list of forwarding path state block. 6. Search for a Reservation State Block whose filter spec object matches with the Sender Template Object of the forwarding PSB and whose Outgoing Interface matches one of the entry in the forwarding PSB's outgoing interface list. If found then a Resv Refresh message to the Previous Hop Address in the forwarding PSB and execute the Update Traffic Control sequence.
1.まず、一致する宛先アドレスを持つパス状態ブロックをチェックし、送信側ポートまたは送信側アドレスまたは宛先ポートがパス状態ブロックのセッションオブジェクトの値と一致しない場合、パスエラーメッセージを送信して返します。 。 （現在、アプリケーションはエラーメッセージを送信しません。コンソールにこのエラーメッセージを出力します。）2.セッションオブジェクトと送信者テンプレートオブジェクトが受信したパスメッセージのそれと一致するPSBが見つかった場合、現在のPSBがPSBの転送。 3.セッションおよび送信側テンプレートがパスメッセージ内の対応するオブジェクトと一致し、着信インターフェイスがIncInterfaceと一致するPSBを検索します。そのようなPSBが見つかり、前のホップアドレス、次のホップアドレス、およびSenderTspecオブジェクトがパスメッセージのそれと一致しない場合、パスメッセージの値がパス状態ブロックにコピーされ、[パスの更新が必要]フラグがオンになります。 。 PSBの前のホップアドレス、次のホップアドレスがパスメッセージと異なる場合、Resv Refresh Neededフラグもオンになり、現在のPSBはこのPSBと等しくなります。 4.一致するPSBが見つからない場合は、新しいPSBが作成され、パス更新必要フラグがオンになり、現在のPSBがこのPSBと等しくなります。 5.パスリフレッシュが必要なフラグがオンの場合、現在のPSBが転送PSBにコピーされ、パスリフレッシュシーケンスが実行されます。この機能を実行するには、PathRefreshを使用します。パスリフレッシュは、転送パスステートブロックの発信インターフェイスリストにあるすべてのインターフェイスに送信されます。 6.フィルター仕様オブジェクトが転送PSBの送信者テンプレートオブジェクトと一致し、送信インターフェイスが転送PSBの送信インターフェイスリストのエントリの1つと一致する予約状態ブロックを検索します。見つかった場合は、転送PSBの前のホップアドレスへのResvリフレッシュメッセージを送信し、トラフィック制御更新シーケンスを実行します。
b. PathRefresh: This function is called from PathMsgPro. It creates the Path message sends the message through the outgoing interface that is specified by the PathMsgPro.
b. PathRefresh：この関数はPathMsgProから呼び出されます。 Pathメッセージを作成し、PathMsgProで指定された発信インターフェイスを介してメッセージを送信します。
c. ResvMsgPro: This function was invoked by the Arr state when a Resv message is received.
c. ResvMsgPro：この関数は、Resvメッセージの受信時にArr状態によって呼び出されました。
1. Determine the outgoing interface and check for the PSB whose Source Address and Session Objects match the ones in the Resv message. 2. If such a PSB is not found then send a ResvErr message saying that No Path Information is available. (We have not implemented this message, we only print an error message on the console.) 3. Check for incompatible styles and process the flow descriptor list to make reservations, checking the PSB list for the sender information. If no sender information is available through the PSB list then send an Error message saying that No Sender information. For all the matching PSBs found, if the Refresh PHOP list doesn't have the Previous Hop Address of the PSB then add the Previous Hop Address to the Refresh PHOP list. 4. Check for matching Reservation State Block (RSB) whose Session and Filter Spec Object matches that of Resv message. If no such RSB is found then create a new RSB from the Resv Message and set the NeworMod flag On. Call this RSB as activeRSB. Turn on the Resv Refresh Needed Flag. 5. If a matching RSB is found, call this as activeRSB and if the FlowSpec and Scope objects of this RSB differ from that of Resv Message copy the Resv message Flowspec and Scope objects to the ActiveRSB and set the NeworMod flag On.
1. 発信インターフェイスを決定し、ソースアドレスとセッションオブジェクトがResvメッセージ内のものと一致するPSBを確認します。 2.そのようなPSBが見つからない場合は、利用可能なパス情報がないことを示すResvErrメッセージを送信します。 （このメッセージは実装していません。コンソールにエラーメッセージを出力するだけです。）3.互換性のないスタイルを確認し、フロー記述子リストを処理して予約し、PSBリストで送信者情報を確認します。 PSBリストから送信者情報を取得できない場合は、送信者情報がないことを示すエラーメッセージを送信します。見つかったすべての一致するPSBについて、更新PHOPリストにPSBの前のホップアドレスがない場合は、更新PHOPリストに前のホップアドレスを追加します。 4.セッションとフィルターの仕様オブジェクトがResvメッセージのオブジェクトと一致する、予約状態ブロック（RSB）の一致を確認します。そのようなRSBが見つからない場合は、Resvメッセージから新しいRSBを作成し、NeworModフラグをオンに設定します。このRSBをactiveRSBとして呼び出します。 Resv更新が必要なフラグをオンにします。 5.一致するRSBが見つかった場合、これをactiveRSBとして呼び出し、このRSBのFlowSpecおよびScopeオブジェクトがResv MessageのFlowSpecおよびScopeオブジェクトと異なる場合は、ResvメッセージのFlowspecおよびScopeオブジェクトをActiveRSBにコピーし、NeworModフラグをオンに設定します。
6. Call the Update Traffic Control Sequence. This is done by calling the function UpdateTrafficControl 7. If Resv Refresh Needed Flag is On then send a ResvRefresh message for each Previous Hop in the Refresh PHOP List. This is done by calling the ResvRefresh function for every Previous Hop in the Refresh PHOP List.
6. トラフィック制御シーケンスの更新を呼び出します。これは、UpdateTrafficControl 7関数を呼び出すことによって行われます。ResvRefresh Needed FlagがOnの場合、Refresh PHOP Listの前のホップごとにResvRefreshメッセージを送信します。これは、更新PHOPリスト内のすべての前のホップに対してResvRefresh関数を呼び出すことによって行われます。
d. ResvRefresh: this function is called by both PathMsgPro and ResvMsgPro with RSB and Previous Hop as input. The function constructs the Resv Message from the RSB and sends the message to the Previous Hop.
d. ResvRefresh：この関数は、RSBと前のホップを入力として、PathMsgProとResvMsgProの両方から呼び出されます。この関数は、RSBからResvメッセージを作成し、メッセージを前のホップに送信します。
e. PathTearPro: This function is invoked by the Arr state when a PathTear message is received.
e. PathTearPro：この関数は、PathTearメッセージを受信したときにArr状態によって呼び出されます。
1. Search for PSB whose Session Object and Sender Template Object matches that of the arrived PathTear message. 2. If such a PSB is not found do nothing and return. 3. If a matching PSB is found, a PathTear message is sent to all the outgoing interfaces that are listed in the Outgoing Interface list of the PSB. 4. Search for all the RSB whose Filter Spec Object matches the Sender Template Object of the PSB and if the Outgoing Interface of this RSB is listed in the PSB's Outgoing interface list delete the RSB. 5. Delete the PSB and return.
1. 到着したPathTearメッセージのセッションオブジェクトおよび送信者テンプレートオブジェクトと一致するPSBを検索します。 2.そのようなPSBが見つからない場合は、何もせずに戻ります。 3.一致するPSBが見つかった場合、PathTearメッセージは、PSBの送信インターフェースリストにリストされているすべての送信インターフェースに送信されます。 4.フィルター仕様オブジェクトがPSBの送信側テンプレートオブジェクトと一致するすべてのRSBを検索し、このRSBの送信インターフェイスがPSBの送信インターフェイスリストにリストされている場合は、RSBを削除します。 5. PSBを削除して戻ります。
f. ResvTearPro: This function is invoked by the Arr state when a ResvTear message is received. 1. Determine the Outgoing Interface. 2. Process the flow descriptor list of the arrived ResvTear message. 3. Check for the RSB whose Session Object, Filter Spec Object matches that of ResvTear message and if there is no such RSB return. 4. If such an RSB is found and Resv Refresh Needed Flag is on send ResvTear message to all the Previous Hops that are in Refresh PHOP List. 5. Finally delete the RSB.
f. ResvTearPro：この関数は、ResvTearメッセージを受信したときにArr状態によって呼び出されます。 1.発信インターフェイスを決定します。 2.到着したResvTearメッセージのフロー記述子リストを処理します。 3.セッションオブジェクト、フィルター仕様オブジェクトがResvTearメッセージのRSBと一致するRSBを確認し、そのようなRSBリターンがないかどうかを確認します。 4.そのようなRSBが見つかり、Resv更新が必要なフラグがオンの場合、Resh PHOPリストにあるすべての前のホップにResvTearメッセージを送信します。 5.最後にRSBを削除します。
g. ResvConfPro: This function is invoked by the Arr state when a ResvConf message is received. The Resv Confirm is forwarded to the IP address that was in the Resv Confirm Object of the received ResvConf message.
g. ResvConfPro：この関数は、ResvConfメッセージを受信したときにArr状態によって呼び出されます。 Resv Confirmは、受信したResvConfメッセージのResv Confirmオブジェクトに含まれていたIPアドレスに転送されます。
h. UpdateTrafficControl: This function is called by PathMsgPro and ResvMsgPro and input to this function is RSB.
h. UpdateTrafficControl：この関数はPathMsgProおよびResvMsgProによって呼び出され、この関数への入力はRSBです。
1. The RSB list is searched for a matching RSB that matches the Session Object, and Filter Spec Object with the input RSB. 2. Effective Kernel TC_Flowspec are computed for all these RSB's.
1. RSBリストは、セッションオブジェクトと一致するRSBと、入力RSBを持つフィルター仕様オブジェクトを検索します。 2.有効なカーネルTC_Flowspecは、これらすべてのRSBに対して計算されます。
3. If the Filter Spec Object of the RSB doesn't match the one of the Filter Spec Object in the TC Filter Spec List then add the Filter Spec Object to the TC Filter Spec List. 4. If the FlowSpec Object of the input RSB is greater than the TC_Flowspec then turn on the Is_Biggest flag. 5. Search for the matching Traffic Control State Block(TCSB) whose Session Object, Outgoing Interface, and Filter Spec Object matches with those of the Input RSB. 6. If such a TCSB is not found create a new TCSB. 7. If matching TCSB is found modify the reservations. 8. If Is_Biggest flag is on turn on the Resv Refresh Needed Flag flag, else send a ResvConf Message to the IP address in the ResvConfirm Object of the input RSB.
3. RSBのフィルター仕様オブジェクトがTCフィルター仕様リスト内のフィルター仕様オブジェクトのいずれとも一致しない場合は、フィルター仕様オブジェクトをTCフィルター仕様リストに追加します。 4.入力RSBのFlowSpecオブジェクトがTC_Flowspecより大きい場合は、Is_Biggestフラグをオンにします。 5.セッションオブジェクト、送信インターフェイス、およびフィルター仕様オブジェクトが入力RSBのオブジェクトと一致する一致するトラフィック制御状態ブロック（TCSB）を検索します。 6.そのようなTCSBが見つからない場合は、新しいTCSBを作成します。 7.一致するTCSBが見つかった場合は、予約を変更します。 8. Is_Biggestフラグがオンの場合、Resv Refresh Needed Flagフラグをオンにし、それ以外の場合は、ResvConfメッセージを入力RSBのResvConfirmオブジェクトのIPアドレスに送信します。
4.2.4 pathmsg: The functions to be done by this state are done through the function call PathMsgPro described above.
4.2.4 pathmsg：この状態で実行される機能は、上記のPathMsgPro関数呼び出しによって実行されます。
4.2.5 resvmsg: The functions that would be done by this state are done through the function call ResvMsgPro described above.
4.2.5 resvmsg：この状態で実行される機能は、上記のResvMsgPro関数呼び出しによって実行されます。
4.2.6 ptearmsg: The functions that would be done by this state are done through the function call PathTearPro described above.
4.2.6 ptearmsg：この状態で実行される機能は、上記のPathTearPro関数呼び出しによって実行されます。
4.2.7 rtearmsg: The functions that would be done by this state are done through the function call ResvTearPro described above.
4.2.7 rtearmsg：この状態で実行される機能は、上記のResvTearPro関数呼び出しによって実行されます。
4.2.8 rconfmsg: The functions that would be done by this state are done through the function call ResvConfPro described above.
4.2.8 rconfmsg：この状態で実行される機能は、上記のResvConfPro関数呼び出しを介して実行されます。
Figure 9 shows the process of RSVP on hosts.
図9は、ホストでのRSVPのプロセスを示しています。
Initializes all the variables. Default transition to idle state.
すべての変数を初期化します。アイドル状態へのデフォルト遷移。
[Figure 9: RSVP process on hosts]
[図9：ホストでのRSVPプロセス]
This state transit to the Arr state on packet arrival.
この状態は、パケットの到着時にArr状態に遷移します。
This state calls the appropriate functions depending on the type of message received. Default transition to idle state.
この状態は、受信したメッセージのタイプに応じて適切な関数を呼び出します。アイドル状態へのデフォルト遷移。
a. MakeSessionCall: This function is called from the Arr state whenever a Session call is received from the local application.
a. MakeSessionCall：この関数は、ローカルアプリケーションからセッション呼び出しが受信されるたびに、Arr状態から呼び出されます。
1. Search for the Session Information. 2. If one is found return the corresponding Session Id. 3. If the session information is not found assign a new session Id to the session to the corresponding session. 4. Make an UpCall to the local application with this Session Id.
1. セッション情報を検索します。 2.見つかった場合は、対応するセッションIDを返します。 3.セッション情報が見つからない場合は、セッションに新しいセッションIDを対応するセッションに割り当てます。 4.このセッションIDでローカルアプリケーションにUpCallを実行します。
b. MakeSenderCall: This function is called from the Arr state whenever a Sender call is received from the local application.
b. MakeSenderCall：この関数は、Sender呼び出しがローカルアプリケーションから受信されるたびに、Arr状態から呼び出されます。
1. Get the information corresponding to the Session Id and create a Path message corresponding to this session. 2. A copy of the packet is buffered and used by the host to send the PATH message periodically. 3. This packet is sent to the IP layer.
1. セッションIDに対応する情報を取得し、このセッションに対応するPathメッセージを作成します。 2.パケットのコピーがバッファされ、ホストが定期的にPATHメッセージを送信するために使用します。 3.このパケットはIP層に送信されます。
c. MakeReserveCall: This function is called from the Arr state whenever a Reserve call is received from the local application. This function will create and send a Resv message. Also, the packet is buffered for later use.
c. MakeReserveCall：この関数は、ローカルアプリケーションからReserve呼び出しを受信するたびにArr状態から呼び出されます。この関数は、Resvメッセージを作成して送信します。また、パケットは後で使用するためにバッファリングされます。
d. MakeReleaseCall: This function is called from the Arr state whenever a Release call is received from the local application. This function will generate a PathTear message if the local application is sender or generates a ResvTear message if the local application is receiver.
d. MakeReleaseCall：この関数は、ローカルアプリケーションからRelease呼び出しを受信するたびに、Arr状態から呼び出されます。この関数は、ローカルアプリケーションが送信側の場合はPathTearメッセージを生成し、ローカルアプリケーションが受信側の場合はResvTearメッセージを生成します。
4.3.4 Session This state's function is performed by the MakeSessionCall function.
4.3.4 セッションこの状態の機能は、MakeSessionCall関数によって実行されます。
This state's function is han by the MakeSenderCall function.
この状態の関数は、MakeSenderCall関数によって処理されます。
4.3.6 Reserve This state's function is performed by the MakeReserveCall function.
4.3.6 Reserveこの状態の機能は、MakeReserveCall関数によって実行されます。
This state's function is performed by the MakeReleaseCall function.
この状態の機能は、MakeReleaseCall関数によって実行されます。
Because this set of models was intended particularly to enable evaluation by simulation of various multicast routing protocols, we give particular attention in this section to the steps necessary to interface a routing protocol model to the other models. We have available implementations of DVMRP and OSPF, which we will describe below. Instructions for invoking these models are contained in a separate User's Guide for the models.
この一連のモデルは、さまざまなマルチキャストルーティングプロトコルのシミュレーションによる評価を可能にすることを特に目的としていたため、このセクションでは、ルーティングプロトコルモデルを他のモデルにインターフェースするために必要な手順に特に注意を払います。 DVMRPとOSPFの利用可能な実装があります。これについては以下で説明します。これらのモデルを呼び出す手順は、モデルの別のユーザーズガイドに含まれています。
Interfacing a multicast routing protocol using the OPNET Simulation package requires the creation of a new routing processor node in the node editor and linking it via packet streams. Packet streams are unidirectional links used to interconnect processor nodes, queue nodes, transmitters and receiver nodes. A duplex connection between two nodes is represented by using two unidirectional links to connect the two nodes to and from each other.
OPNETシミュレーションパッケージを使用してマルチキャストルーティングプロトコルをインターフェースするには、ノードエディターで新しいルーティングプロセッサノードを作成し、パケットストリームを介してリンクする必要があります。パケットストリームは、プロセッサノード、キューノード、送信機および受信機ノードを相互接続するために使用される単方向リンクです。 2つのノード間の二重接続は、2つの単方向リンクを使用して2つのノードを相互に接続することによって表されます。
A multicast routing processor node is created in the node editor and links are created to and from the processors(duplex connection) that interact with this module, the IGMP processor node and the IP processor node. Within the node editor, a new processor node can be created by selecting the button for processor creation (plain gray node on the node editor control panel) and by clicking on the desired location in the node editor to place the node. Upon creation of the processor node, the name of the processor can be specified by right clicking on the mouse button and entering the name value on the attribute box presented. Links to and from this node are generated by selecting the packet stream button (represented by two gray nodes connected with a solid green arrow on the node editor control panel), left clicking on the mouse button to specify the source of the link and right clicking on the mouse button to mark the destination of the link.
マルチキャストルーティングプロセッサノードがノードエディタで作成され、このモジュール、IGMPプロセッサノード、およびIPプロセッサノードとやり取りするプロセッサ（二重接続）との間のリンクが作成されます。ノードエディタ内で、プロセッサ作成用のボタン（ノードエディタのコントロールパネルのプレーングレーノード）を選択し、ノードエディタの目的の場所をクリックしてノードを配置することにより、新しいプロセッサノードを作成できます。プロセッサノードの作成時に、マウスボタンを右クリックして表示される属性ボックスに名前の値を入力すると、プロセッサの名前を指定できます。このノードとの間のリンクは、パケットストリームボタン（ノードエディターコントロールパネルの緑の実線矢印で接続された2つの灰色のノードで表される）を選択し、マウスボタンを左クリックしてリンクのソースを指定し、右クリックして生成されます。リンク先をマークするためにマウスボタン上で。
The multicast routing processor node is linked to the IP processor node and the IGMP processor node each with a duplex connection. A duplex connection between two nodes is represented by two uni-directional links interconnecting them providing a bidirectional flow of information or interrupts, as shown in Figure 6. The IP processor node (in the subnet router) interfaces with the multicast routing processor node, the unicast routing processor node, the Resource Reservation processor node(RSVP), the ARP processor node( only on subnet routers and hosts), the IGMP processor node, and finally the MAC processor node (only on subnet routers and hosts) each with a duplex connection with exceptions for ARP and MAC nodes.
マルチキャストルーティングプロセッサノードは、それぞれ二重接続でIPプロセッサノードとIGMPプロセッサノードにリンクされています。図6に示すように、2つのノード間の二重接続は、相互接続する2つの単方向リンクで表され、情報または割り込みの双方向フローを提供します。IPプロセッサノード（サブネットルーター内）は、マルチキャストルーティングプロセッサノードとインターフェイスします。ユニキャストルーティングプロセッサノード、リソース予約プロセッサノード（RSVP）、ARPプロセッサノード（サブネットルーターとホストのみ）、IGMPプロセッサノード、最後にMACプロセッサノード（サブネットルーターとホストのみ）、それぞれ二重ARPおよびMACノードの例外を伴う接続。
The service of the ARP node is required only in the direction from the IP layer to the MAC layer(requiring only a unidirectional link from IP processor node to ARP processor node). The MAC processor node on the subnet router receives multicast packets destined for all multicast groups in the subnet, in contrast to the MAC node on subnet hosts which only receives multicast packets destined specifically for its multicast group. The MAC node connects to the IP processor node with a single uni-directional link from it to the IP node.
ARPノードのサービスは、IP層からMAC層への方向でのみ必要です（IPプロセッサノードからARPプロセッサノードへの単方向リンクのみが必要です）。サブネットグループのマルチキャストパケットのみを受信するサブネットホストのMACノードとは対照的に、サブネットルータのMACプロセッサノードは、サブネット内のすべてのマルチキャストグループ宛のマルチキャストパケットを受信します。 MACノードは、それからIPノードへの単一の単方向リンクでIPプロセッサノードに接続します。
The IGMP processor node interacts with the multicast routing processor node, unicast routing processor node, and the IP processor node. Because the IGMP node is linked to the IP node, it is thus able to update the group membership table(in this model, the group membership table is represented by the local interface(interface 0) of the multicast routing table data structure) within the IP node. This update triggers a signal to the multicast routing processor node from the IGMP node causing it to reassess the multicast routing table within the IP node. If the change in the group membership table warrants a modification of the multicast routing table, the multicast routing processor node interacts with the IP node to modify the current multicast routing table according to the new group membership information updated by IGMP.
IGMPプロセッサノードは、マルチキャストルーティングプロセッサノード、ユニキャストルーティングプロセッサノード、およびIPプロセッサノードと対話します。 IGMPノードはIPノードにリンクされているため、グループメンバーシップテーブルを更新できます（このモデルでは、グループメンバーシップテーブルは、マルチキャストルーティングテーブルデータ構造のローカルインターフェイス（インターフェイス0）によって表されます）。 IPノード。この更新により、IGMPノードからマルチキャストルーティングプロセッサノードへの信号がトリガーされ、IPノード内のマルチキャストルーティングテーブルが再評価されます。グループメンバーシップテーブルの変更がマルチキャストルーティングテーブルの変更を保証する場合、マルチキャストルーティングプロセッサノードはIPノードと対話して、IGMPによって更新された新しいグループメンバーシップ情報に従って現在のマルチキャストルーティングテーブルを変更します。
The change in the group membership occurs with the decision at a host to leave or join a particular multicast group. The IGMP process on the gateway periodically sends out queries to the IGMP processes on hosts within the subnet in an attempt to determine which hosts currently are receiving packets from particular groups. Not receiving a response for a pending IGMP host query specific to a group indicates to the gateway IGMP that no host belonging to the particular group exists in the subnet. This occurs when the last remaining member of a multicast group in the subnet leaves. In this case the IGMP processor node updates the group membership able and triggers a modification of the multicast routing table by alerting the multicast routing processor node. A prune message specific to the group is initiated and propagated upward establishing a prune state for the interface leading to the present subnet, effectively removing this subnet from the group-specific multicast spanning tree and potentially leading to additional pruning of spanning tree edges as the prune message travels higher up the tree. Joining a multicast group is also managed by the IGMP process which updates the group membership table leading to a possible modification of the multicast routing table.
グループメンバーシップの変更は、特定のマルチキャストグループを脱退または参加するホストでの決定によって発生します。ゲートウェイ上のIGMPプロセスは、サブネット内のホスト上のIGMPプロセスに定期的にクエリを送信して、特定のグループからパケットを現在受信しているホストを特定しようとします。グループに固有の保留中のIGMPホストクエリに対する応答を受信しないことは、特定のグループに属するホストがサブネットに存在しないことをゲートウェイIGMPに示します。これは、サブネット内のマルチキャストグループの最後に残っているメンバーが去ったときに発生します。この場合、IGMPプロセッサノードはグループメンバーシップを更新し、マルチキャストルーティングプロセッサノードに警告することにより、マルチキャストルーティングテーブルの変更をトリガーします。グループに固有のプルーンメッセージが開始され、上方向に伝搬して、現在のサブネットにつながるインターフェースのプルーン状態を確立し、このサブネットをグループ固有のマルチキャストスパニングツリーから効果的に削除し、潜在的に、プルーンとしてスパニングツリーエッジの追加のプルーニングにつながりますメッセージはツリーの上位に移動します。マルチキャストグループへの参加は、グループメンバーシップテーブルを更新するIGMPプロセスによっても管理され、マルチキャストルーティングテーブルが変更される可能性があります。
The multicast routing protocol is dependent on a unicast routing protocol (RIP or OSPF) to handle multicast routing. The next hop interface to the source of the packet received, or the upstream interface, is determined using the unicast routing protocol to trace the reverse path back to the source of the packet. If the packet received arrived on this upstream interface, then the packet can be propagated downstream through its downstream interfaces (excluding the interface in which the packet was received). Otherwise, the packet is deemed to be a duplicate and dropped, halting the propagation of the packet downstream. This repeated reverse path checking and broadcasting eventually generates the spanning tree for multicast routing of packets. To determine the reverse path forward interface of a received multicast packet propagated up from the IP layer, the multicast routing processor node retrieves a copy of the unicast routing table from the IP processor node and uses it to recalculate the multicast routing table in the IP processor node.
マルチキャストルーティングプロトコルは、マルチキャストルーティングを処理するためにユニキャストルーティングプロトコル（RIPまたはOSPF）に依存しています。受信したパケットの送信元へのネクストホップインターフェイス、またはアップストリームインターフェイスは、ユニキャストルーティングプロトコルを使用して、パケットの送信元へのリバースパスを追跡することによって決定されます。受信したパケットがこのアップストリームインターフェイスに到着した場合、パケットはダウンストリームインターフェイスを介してダウンストリームに伝搬できます（パケットが受信されたインターフェイスを除く）。そうでない場合、パケットは重複していると見なされてドロップされ、ダウンストリームのパケットの伝搬が停止します。この繰り返しのリバースパスチェックとブロードキャストにより、最終的にパケットのマルチキャストルーティング用のスパニングツリーが生成されます。マルチキャストルーティングプロセッサノードは、IP層から伝達された受信マルチキャストパケットのリバースパス転送インターフェイスを特定するために、IPプロセッサノードからユニキャストルーティングテーブルのコピーを取得し、それを使用してIPプロセッサのマルチキャストルーティングテーブルを再計算します。ノード。
Using the OPNET tools, interrupts to the multicast routing processor node are generated in several ways. One is the arrival of a multicast packet along a packet stream (at the multicast routing processor node) when the packet is received by the MAC node and propagated up the IP node where upon discarding the IP header determination is made as to which upper layer protocol to send the packet. A second type of interrupt generation occurs by remote interrupts from the IGMP process alerting the multicast routing process of an update in the group membership table. A third occurs when the specific source/group (S,G) entry for a multicast packet received at the IP node does not exist in the current multicast routing table and a new entry needs to be created. The IP node generates an interrupt to the multicast routing processor node informing it to create a new source/group entry on the multicast routing table.
OPNETツールを使用すると、マルチキャストルーティングプロセッサノードへの割り込みがいくつかの方法で生成されます。 1つは、パケットがMACノードによって受信され、IPノードに伝搬されたときに、パケットストリームに沿って（マルチキャストルーティングプロセッサノードで）マルチキャストパケットが到着することです。IPヘッダーを破棄すると、どの上位層プロトコルが決定されます。パケットを送信します。 2番目のタイプの割り込み生成は、IGMPプロセスからのリモート割り込みによって発生し、マルチキャストルーティングプロセスにグループメンバーシップテーブルの更新を警告します。 3つ目は、IPノードで受信したマルチキャストパケットの特定のソース/グループ（S、G）エントリが現在のマルチキャストルーティングテーブルに存在せず、新しいエントリを作成する必要がある場合です。 IPノードは、マルチキャストルーティングプロセッサノードへの割り込みを生成して、マルチキャストルーティングテーブルに新しいソース/グループエントリを作成するよう通知します。
The process interrupts generated within the OPNET model can be handled by specifying the types of interrupts and the conditions for the interrupts using the interrupt code, integer number representing the condition for a specific interrupt. The conditions for interrupts are specified on the interrupt stream linking the interrupt generating state and the state resulting from the interrupt. For self-interrupts (interrupts occurring among states within the same process), interrupts of type OPC_INTRPT_SELF are used. For remote interrupts (interprocess interrupts), the conditions for specific interrupts are specified from the idle state to the state resulting from the interrupt within the remote process.
OPNETモデル内で生成されたプロセス割り込みは、割り込みコードを使用して割り込みのタイプと割り込みの条件を指定することによって処理できます。整数は、特定の割り込みの条件を表します。割り込みの条件は、割り込み発生状態と割り込みの結果の状態をリンクする割り込みストリームで指定されます。自己割り込み（同じプロセス内の状態間で発生する割り込み）では、OPC_INTRPT_SELFタイプの割り込みが使用されます。リモート割り込み（プロセス間割り込み）の場合、特定の割り込みの条件は、アイドル状態からリモートプロセス内の割り込みの結果の状態まで指定されます。
The remote interrupts are of type, OPC_INTRPT_REMOTE. A third type of interrupt is the OPC_INTRPT_STRM, which is triggered when packets arrive via a packet stream, indicating its arrival. The condition of this interrupt is also specified from the idle state to the resultant state by the interrupt condition stream defined by a unique interrupt code. For all of these interrupts, the interrupt code is provided within the header block (written in C language) of the interrupted process. When the condition for the interrupt becomes true, a transition is made to the resultant state specified by the interrupt stream.
リモート割り込みは、OPC_INTRPT_REMOTEタイプです。 3番目のタイプの割り込みはOPC_INTRPT_STRMで、パケットストリームを介してパケットが到着したときにトリガーされ、その到着を示します。この割り込みの条件も、一意の割り込みコードによって定義された割り込み条件ストリームによって、アイドル状態から結果の状態まで指定されます。これらすべての割り込みについて、割り込みコードは、割り込みされたプロセスのヘッダーブロック（C言語で記述）内に提供されます。割り込みの条件がtrueになると、割り込みストリームで指定された結果の状態に遷移します。
Several interrupt connections exist to interface the IGMP processor node, IP processor node , and the multicast routing processor node with each other in the present OPNET Simulation Model. Also, the IP processor node interfaces with the unicast routing protocol which interfaces with the IGMP processor node. An OPC_INTRPT_STRM interrupt is generated when a multicast packet arrives via a packet stream from the IP processor node to the multicast routing processor node. A remote interrupt of type, OPC_INTRPT_REMOTE, is generated from the IGMP process to the IP process when a member of a group relinquishes membership from a particular group or a new member is added to a group. This new membership is updated in the group membership table located in the IP node by the IGMP process which also generates a remote interrupt to the multicast routing protocol process, causing a recalculation of the multicast routing table in the IP module.
現在のOPNETシミュレーションモデルでは、IGMPプロセッサノード、IPプロセッサノード、およびマルチキャストルーティングプロセッサノードを相互に接続するために、いくつかの割り込み接続が存在します。また、IPプロセッサノードは、IGMPプロセッサノードとインターフェイスするユニキャストルーティングプロトコルとインターフェイスします。 OPC_INTRPT_STRM割り込みは、IPプロセッサノードからマルチキャストルーティングプロセッサノードへのパケットストリームを介してマルチキャストパケットが到着したときに生成されます。グループのメンバーが特定のグループからメンバーシップを放棄するか、新しいメンバーがグループに追加されると、タイプOPC_INTRPT_REMOTEのリモート割り込みがIGMPプロセスからIPプロセスに生成されます。この新しいメンバーシップは、IGMPプロセスによってIPノードにあるグループメンバーシップテーブルで更新されます。IGMPプロセスは、マルチキャストルーティングプロトコルプロセスへのリモート割り込みも生成し、IPモジュールのマルチキャストルーティングテーブルを再計算します。
Modifications of routing protocol modules (in fact all of the modules in the process model) are made transparently throughout the network using the OPNET Simulation tools. An addition or modification of a routing module in any subnet will reflect on all the subnets.
ルーティングプロトコルモジュール（実際にはプロセスモデルのすべてのモジュール）の変更は、OPNETシミュレーションツールを使用してネットワーク全体で透過的に行われます。サブネット内のルーティングモジュールの追加または変更は、すべてのサブネットに反映されます。
OSPF and MOSPF models [5] are implemented in the OSPF model containing fourteen states. They only exist on routers. Figure 10 shows the process model. The following processing takes place in the indicated modules.
OSPFおよびMOSPFモデル[5]は、14の状態を含むOSPFモデルに実装されています。これらはルーターにのみ存在します。図10にプロセスモデルを示します。以下の処理は、示されたモジュールで行われます。
This state initializes all the router variables. Default transition to idle state.
この状態では、すべてのルーター変数が初期化されます。アイドル状態へのデフォルト遷移。
This state has several transitions. If a packet arrives it transits to arr state. Depending on interrupts received it will transit to BCOspfLsa, BCMospfLsa, hello_pks state. In future versions, links coming up or down will also cause a transition.
この状態にはいくつかの遷移があります。パケットが到着すると、arr状態に遷移します。受信した割り込みに応じて、BCOspfLsa、BCMOspfLsa、hello_pks状態に遷移します。将来のバージョンでは、リンクがアップまたはダウンすると、遷移も発生します。
Transition to this state from idle state is executed whenever the condition send_ospf_lsa is true, which happens when the network is being initialized, and when ospf_lsa_refresh_timout occurs. This state will create Router, Network, Summary Link State Advertisements and pack all of them into an Link State Update packet. The Link State Update Packet is sent to the IP layer with a destination address of AllSPFRouters.
アイドル状態からこの状態への遷移は、send_ospf_lsaがtrueの場合に実行されます。これは、ネットワークが初期化されているとき、およびospf_lsa_refresh_timoutが発生したときに発生します。この状態は、ルーター、ネットワーク、サマリーリンク状態アドバタイズメントを作成し、それらすべてをリンク状態更新パケットにパックします。リンク状態更新パケットは、AllSPFRoutersの宛先アドレスと共にIPレイヤーに送信されます。
[Figure 10: OSPF and MOSPF process model on routers]
[図10：ルーターのOSPFおよびMOSPFプロセスモデル]
Transition to this state from idle state is executed whenever the condition send_mospf_lsa is true. This state will create Group Membership Link State Advertisement and pack them into Mospf Link State Update Packet. This Mospf Link State Update Packet is sent to IP layer with a destination address of AllSPFRouters.
アイドル状態からこの状態への遷移は、send_mospf_lsaの条件が真のときに実行されます。この状態は、グループメンバーシップリンク状態アドバタイズを作成し、Mospfリンク状態更新パケットにパックします。このMospfリンク状態更新パケットは、宛先アドレスがAllSPFRoutersのIP層に送信されます。
The arr state checks the type of packet that is received upon a packet arrival. It calls the following functions depending on the protocol Id of the packet received.
arr状態は、パケットの到着時に受信されるパケットのタイプをチェックします。受信したパケットのプロトコルIDに応じて以下の関数を呼び出します。
a. OspfPkPro: Depending on the type of OSPF/MOSPF packet received the function calls the following functions.
a. OspfPkPro：受信したOSPF / MOSPFパケットのタイプに応じて、この関数は次の関数を呼び出します。
1. HelloPk_pro: This function is called whenever a hello packet is received. This function updates the router's neighbor information, which is later used while sending the different LSAs. 2. OspfLsUpdatePk_pro: This function is called when an OSPF LSA update packet is received (router LSA, network LSA, or summary LSA). If the Router is an Area Border Router or if the LSA belongs to the Area whose Area Id is the Routers Area Id, then it is searched to determine whether this LSA already exists in the Link State database. If it exists and if the existing LSA's LS Sequence Number is less than the received LSA's LS Sequence Number the existing LSA was replaced with the received one. The function processes the Network LSA only if it is a designated router or Area Border Router. It processes the Summary LSA only if the router is a Area Border Router. The function also turns on the trigger ospfspfcalc which is the condition for the transition from arr state to ospfspfcalc. 3. MospfLsUpdatePk_pro: This function is called when a MOSPF LSA update packet is received. It updates the group membership link state database of the router.
1. HelloPk_pro：この関数は、helloパケットが受信されるたびに呼び出されます。この関数は、ルーターのネイバー情報を更新します。これは、後でさまざまなLSAを送信するときに使用されます。 2. OspfLsUpdatePk_pro：この関数は、OSPF LSA更新パケットを受信したときに呼び出されます（ルーターLSA、ネットワークLSA、またはサマリーLSA）。ルーターがエリアボーダールーターである場合、またはLSAがエリアIDがルーターエリアIDであるエリアに属している場合は、このLSAがリンク状態データベースに既に存在するかどうかを確認するために検索されます。それが存在し、既存のLSAのLSシーケンス番号が受信したLSAのLSシーケンス番号より小さい場合、既存のLSAは受信したLSAに置き換えられました。この機能は、指定ルーターまたはエリア境界ルーターである場合にのみ、ネットワークLSAを処理します。ルーターがエリアボーダールーターである場合にのみ、サマリーLSAを処理します。この関数は、arr状態からospfspfcalcへの遷移の条件であるトリガーospfspfcalcもオンにします。 3. MospfLsUpdatePk_pro：この関数は、MOSPF LSA更新パケットを受信したときに呼び出されます。ルータのグループメンバーシップリンク状態データベースを更新します。
Hello packets are created and sent with destination address of AllSPFRouters. Default transition to idle state.
Helloパケットが作成され、AllSPFRoutersの宛先アドレスで送信されます。アイドル状態へのデフォルト遷移。
The following functions are used to calculate the shortest path tree and routing table. This state transit to upstr_node upon detupstrnode condition.
次の関数は、最短パスツリーとルーティングテーブルを計算するために使用されます。この状態は、detupstrnode状態になるとupstr_nodeに遷移します。
a. CandListInit: Depending upon the SourceNet of the datagram, the candidate lists are initialized.
a. CandListInit：データグラムのSourceNetに応じて、候補リストが初期化されます。
b. MospfCandAddPro: The vertex link is examined and if the other end of the link is not a stub network and is not already in the candidate list it is added to the candidate list after calculating the cost to that vertex. If this other end of the link is already on the shortest path tree and the calculated cost is less than the one that shows in the shortest path tree entry update the shortest path tree to show the calculated cost.
b. MospfCandAddPro：頂点リンクが検査され、リンクのもう一方の端がスタブネットワークではなく、候補リストにない場合、その頂点へのコストを計算した後に候補リストに追加されます。リンクのもう一方の端がすでに最短パスツリー上にあり、計算されたコストが最短パスツリーエントリに表示されるコストよりも小さい場合は、最短パスツリーを更新して、計算されたコストを表示します。
c. MospfSPFTreeCalc: The vertex that is closest to the root that is in the candidate list is added to the shortest path tree and its link is considered for possible inclusions in the candidate list.
c. MospfSPFTreeCalc：候補リストにあるルートに最も近い頂点が最短パスツリーに追加され、そのリンクが候補リストに含まれる可能性があると見なされます。
d. MCRoutetableCalc: Multicast routing table is calculated using the information of the MOSPF shortest Path tree.
d. MCRoutetableCalc：マルチキャストルーティングテーブルは、MOSPF最短パスツリーの情報を使用して計算されます。
The following functions are used in this state to calculate the shortest path tree and using this information the routing table. Transition to ospfspfcalc state on ospfcalc condition. This is set to one after processing all functions in the state.
この状態で次の関数を使用して、最短パスツリーを計算し、この情報を使用してルーティングテーブルを作成します。 ospfcalc条件でのospfspfcalc状態への遷移。状態のすべての関数を処理した後、これは1に設定されます。
a. OspfCandidateAddPro: This function initializes the candidate list by examining the link state advertisement of the Router. For each link in this advertisement, if the other end of the link is a router or transit network and if it is not already in the shortest-path tree then calculate the distance between these vertices. If the other end of this link is not already on the candidate list or if the distance calculated is less than the value that appears for this other end add the other end of the link to candidate list.
a. OspfCandidateAddPro：この関数は、ルーターのリンク状態アドバタイズを調べることによって候補リストを初期化します。このアドバタイズメントの各リンクについて、リンクのもう一方の端がルーターまたはトランジットネットワークであり、最短パスツリーにまだない場合は、これらの頂点間の距離を計算します。このリンクのもう一方の端が候補リストにない場合、または計算された距離がこのもう一方の端に表示される値よりも小さい場合は、リンクのもう一方の端を候補リストに追加します。
b. OspfSPTreeBuild: This function pulls each vertex from the candidate list that is closest to the root and adds it to the shortest path tree. In doing so it deletes the vertex from the candidate list. This function continues to do this until the candidate list is empty.
b. OspfSPTreeBuild：この関数は、ルートに最も近い候補リストから各頂点を引き出し、最短パスツリーに追加します。これにより、候補リストから頂点が削除されます。この関数は、候補リストが空になるまでこれを続けます。
c. OspfStubLinkPro: In this procedure the stub networks are added to shortest path tree.
c. OspfStubLinkPro：この手順では、スタブネットワークが最短パスツリーに追加されます。
d. OspfSummaryLinkPro: If the router is an Area Border Router the summary links that it has received is examined. The route to the Area border router advertising this summary LSA is examined in the routing table. If one is found a routing table update is done by adding the route to the network specified in the summary LSA and the cost to this route is sum of the cost to area border router advertising this and the cost to reach this network from that area border router.
d. OspfSummaryLinkPro：ルーターがエリアボーダールーターの場合、受信したサマリーリンクが調べられます。このサマリーLSAをアドバタイズするエリア境界ルーターへのルートは、ルーティングテーブルで調べられます。発見された場合、サマリーLSAで指定されたネットワークへのルートを追加することによってルーティングテーブルの更新が行われ、このルートへのコストは、これをアドバタイズするエリアボーダールーターへのコストと、そのエリアボーダーからこのネットワークに到達するためのコストの合計です。ルーター。
e. RoutingTableCalc: This function updates the routing table by examining the shortest path tree data structure.
e. RoutingTableCalc：この関数は、最短パスツリーのデータ構造を調べて、ルーティングテーブルを更新します。
This state does not do anything in the present model. It transitions to DABRA state.
この状態は、現在のモデルでは何もしません。 DABRA状態に遷移します。
If the router is an Area Border Router and the area is the source area then a DABRA message is constructed and send to all the downstream areas. Default transition to idle state.
ルーターがエリアボーダールーターで、エリアがソースエリアである場合、DABRAメッセージが作成され、すべてのダウンストリームエリアに送信されます。アイドル状態へのデフォルト遷移。
The DVMRP model is implemented based on reference [6], DVMRP version 3. There are nine states. The DVMRP process only exists on Routers. Figure 11 shows the states of the DVMRP process.
DVMRPモデルはリファレンス[6]、DVMRPバージョン3に基づいて実装されています。9つの状態があります。 DVMRPプロセスはルーター上にのみ存在します。図11は、DVMRPプロセスの状態を示しています。
Initialize all variables, routing table and forwarding table and load the simulation parameters. It will transit to the Idle state after completing all the initializations.
すべての変数、ルーティングテーブル、転送テーブルを初期化し、シミュレーションパラメーターを読み込みます。すべての初期化が完了すると、アイドル状態に移行します。
The simulation waits for the next scheduled event or remotely invoked event in the Idle State and transit to the state accordingly. In the DVMRP model, Idle State has transitions to Probe_Send, Report_Send, Prune_Send, Graft_Send, Arr_Pkt, Route_Calc and Timer states.
シミュレーションは、アイドル状態で次にスケジュールされているイベントまたはリモートで呼び出されたイベントを待機し、それに応じて状態に遷移します。 DVMRPモデルでは、アイドル状態には、Probe_Send、Report_Send、Prune_Send、Graft_Send、Arr_Pkt、Route_Calc、およびTimer状態への遷移があります。
[Figure 11. DVMRP process on routers]
[図11.ルーターのDVMRPプロセス]
A DVMRP router sends Probe messages periodically to inform other DVMRP routers that it is operational. A DVMRP router lists all its known neighbors' addresses in the Probe message and sends it to All-DVMRP-Routers address. The routers will not process any message that comes from an unknown neighbor.
DVMRPルーターはプローブメッセージを定期的に送信して、他のDVMRPルーターが動作していることを通知します。 DVMRPルーターは、既知のネイバーのアドレスをすべてプローブメッセージにリストし、それをAll-DVMRP-Routersアドレスに送信します。ルーターは、不明なネイバーからのメッセージを処理しません。
To avoid sending Report at the same time for all DVMRP routers, the interval between two Report messages is uniformly distributed with average 60 seconds. The router lists source router's address, upstream router's address and metric of all sources into the Report message and sends it to All-DVMRP-Routers address.
すべてのDVMRPルーターで同時にレポートを送信しないようにするため、2つのレポートメッセージの間隔は平均60秒で均一に分散されます。ルーターは、ソースルーターのアドレス、アップストリームルーターのアドレス、およびすべてのソースのメトリックをレポートメッセージにリストし、それをAll-DVMRP-Routersアドレスに送信します。
The transition to this state is triggered by the local IGMP process. When a host on the subnetwork drops from a group, the IGMP process asks DVMRP to see if the branch should be pruned.
この状態への移行は、ローカルIGMPプロセスによってトリガーされます。サブネットワーク上のホストがグループから削除されると、IGMPプロセスはDVMRPにブランチをプルーニングする必要があるかどうかを確認するように要求します。
The router obtains the group number from IGMP and checks the IP Multicast membership table to find out if there is any group member that is still in the group. If the router determines that the last host has resigned, it goes through the entire forwarding table to locate all sources for that group. The router sends Prune message, containing source address, group address and prune lifetime, separately for each (source, group) pair and records the row as pruned in the forwarding table.
ルータはIGMPからグループ番号を取得し、IPマルチキャストメンバーシップテーブルをチェックして、グループ内にまだグループメンバーが存在するかどうかを確認します。最後のホストが辞任したとルーターが判断した場合、ルーターは転送テーブル全体を調べて、そのグループのすべてのソースを見つけます。ルータは、送信元アドレス、グループアドレス、プルーニングライフタイムを含むプルーンメッセージを（送信元、グループ）ペアごとに個別に送信し、転送テーブルにプルーニングされた行を記録します。
The transition to this state is triggered by the local IGMP process. Once a multicast delivery has been pruned, Graft messages are necessary when a host in the local subnetwork joins into the group. A Graft message sent to the upstream router should be acknowledged hop by hop to the root of the tree guaranteeing end-to-end delivery.
この状態への移行は、ローカルIGMPプロセスによってトリガーされます。マルチキャスト配信がプルーニングされると、ローカルサブネットワークのホストがグループに参加するときに、Graftメッセージが必要になります。上流のルーターに送信されたGraftメッセージは、ツリーのルートまでホップごとに確認応答して、エンドツーエンドの配信を保証する必要があります。
The router obtains the group number from IGMP and go through the forwarding table to locate all traffic sources for that group. A Graft message will be sent to the upstream router with the source address and group address for each (source, group) pair. The router also setups a timer for each Graft message waiting for an acknowledgement.
ルータはIGMPからグループ番号を取得し、転送テーブルを通過して、そのグループのすべてのトラフィックソースを見つけます。グラフトメッセージは、各（送信元、グループ）ペアの送信元アドレスとグループアドレスとともに上流のルーターに送信されます。ルータはまた、確認応答を待機する各Graftメッセージのタイマーを設定します。
All DVMRP control messages will be sent up to DVMRP layer by IP. The function performed by the DVMRP layer depends upon the type of the message received.
すべてのDVMRP制御メッセージは、IPによってDVMRPレイヤーまで送信されます。 DVMRPレイヤーによって実行される機能は、受信したメッセージのタイプによって異なります。
a. Probe message: The router checks the neighbors' list in Probe message, update its their status to indicate the availability of its neighbors.
a. プローブメッセージ：ルーターはプローブメッセージ内のネイバーのリストをチェックし、そのステータスを更新してネイバーの可用性を示します。
b. Report message: Based on exchanging report messages, the routers can build the Multicast delivery tree rooted at each source. A function called ReportPkPro will be called to handle all possible situations when receiving a report message. If the message is a poison reverse report and not coming from one of the dependent downstreams, the incoming interface should be added to the router's downstream list. If the message is not a poison reverse report but it came from one of the downstreams, this interface should be deleted from the downstreams list. And then, the router compared the metric got from the message with the metric of the current upstream, if the new metric is less than the older one, the router's upstream interface should be updated.
b. レポートメッセージ：レポートメッセージの交換に基づいて、ルーターは各ソースをルートとするマルチキャスト配信ツリーを構築できます。 ReportPkProと呼ばれる関数が呼び出され、レポートメッセージを受信するときに起こり得るすべての状況を処理します。メッセージがポイズンリバースレポートであり、依存するダウンストリームの1つから送信されていない場合、着信インターフェイスをルーターのダウンストリームリストに追加する必要があります。メッセージがポイズンリバースレポートではないが、ダウンストリームの1つから送信された場合、このインターフェイスをダウンストリームリストから削除する必要があります。次に、ルータはメッセージから取得したメトリックを現在のアップストリームのメトリックと比較しました。新しいメトリックが古いメトリックよりも小さい場合、ルータのアップストリームインターフェイスを更新する必要があります。
c. Prune message: The router extracts the source address, group address and prune lifetime, marks the incoming interface as pruned in the dependent downstream list of the (source, group) pair. If all downstream interfaces have been pruned, the router will send a prune message to its upstream.
c. プルーンメッセージ：ルーターはソースアドレス、グループアドレス、プルーニングライフタイムを抽出し、（ソース、グループ）ペアの依存するダウンストリームリストで着信インターフェイスをプルーニング済みとしてマークします。すべてのダウンストリームインターフェイスがプルーニングされている場合、ルータはプルーニングメッセージをアップストリームに送信します。
d. Graft message: The router extracts the source and group address, active the incoming interface in the dependent downstream list of the (source, group) pair. If the (source, group) pair has been pruned, the router will reconnect the branch by sending a graft message to its upstream interface.
d. グラフメッセージ：ルーターはソースとグループのアドレスを抽出し、（ソース、グループ）ペアの従属ダウンストリームリストの着信インターフェイスをアクティブにします。 （ソース、グループ）ペアがプルーニングされている場合、ルーターは、上流のインターフェースにグラフトメッセージを送信することでブランチを再接続します。
e. Graft Acknowledge message: The router extracts the source and group address, clear the graft message timer of the (source, group) pair in the forwarding table.
e. 移植確認メッセージ：ルーターは送信元とグループのアドレスを抽出し、転送テーブルの（送信元、グループ）ペアの移植メッセージタイマーをクリアします。
The transition to this state is triggered by the local IP process. Once the IP receives a packet, it will fire a remote interrupt to the DVMRP and ask the DVMRP to prepare the outgoing interfaces for the packet. The DVMRP process obtains the packet's source address and group address from the IP and checks the (source, group) pairs in the forwarding table to decide the branches that have the group members on the Multicast delivery tree. The Group Membership Table on IP will be updated based on this knowledge.
この状態への移行は、ローカルIPプロセスによってトリガーされます。 IPがパケットを受信すると、DVMRPへのリモート割り込みを起動し、DVMRPにパケットの発信インターフェイスを準備するように要求します。 DVMRPプロセスはIPからパケットの送信元アドレスとグループアドレスを取得し、転送テーブルの（送信元、グループ）ペアをチェックして、マルチキャスト配信ツリーにグループメンバーを持つブランチを決定します。この知識に基づいて、IPのグループメンバーシップテーブルが更新されます。
This state is activated once every second. It checks the forwarding table, if the Graft message acknowledgment timer is expired, The router will retransmit the Graft message to the upstream. If the prune state lifetime timer is expired, the router will graft this interface so that the downstream router can receive the packets to the group again. The router also checks if the (source, group) pair is pruned by the upstream router, if so, it will send a graft message to the upstream interface.
この状態は、1秒に1回アクティブになります。転送テーブルをチェックし、Graftメッセージ確認タイマーの期限が切れた場合、ルーターはGraftメッセージをアップストリームに再送信します。プルーニングステートライフタイムタイマーが期限切れになると、ルータはこのインターフェイスを移植して、ダウンストリームルータがグループへのパケットを再度受信できるようにします。また、ルーターは、（ソース、グループ）ペアがアップストリームルーターによってプルーニングされているかどうかをチェックし、プルーニングされている場合は、グラフトメッセージをアップストリームインターフェイスに送信します。
Our simulations of three network models with MOSPF routing have showed good Scalability of the protocol. The running platform we used is a SGI Octane Station with 512 MB main memory and MIPS R10000 CPU, Rev 2.7. Here we list the real running time of each model along with its major elements and the packet inter-arrival times for the streams generated in the hosts.
MOSPFルーティングを使用した3つのネットワークモデルのシミュレーションでは、プロトコルの優れたスケーラビリティが示されています。使用した実行プラットフォームは、512 MBのメインメモリとMIPS R10000 CPU、Rev 2.7を搭載したSGI Octaneステーションです。ここでは、各モデルの実際の実行時間と、その主要な要素、およびホストで生成されたストリームのパケットの到着時間を示します。
Simulated Debug Model Intermediate Model Large Model time 11 Routers 42 routers 86 routers 12 Hosts 48 hosts 96 hosts
シミュレートされたデバッグモデル中間モデル大規模モデル時間11ルーター42ルーター86ルーター12ホスト48ホスト96ホスト
Reserve Data Reserve Data Reserve Data 0.01s 0.02s 0.02s Best-effort Data Best-effort Data Best-effort Data 0.01s 0.025s 0.025s
予約データ予約データ予約データ0.01s 0.02s 0.02sベストエフォートデータベストエフォートデータベストエフォートデータ0.01s 0.025s 0.025s
100 s 3 hours 14 hours 30 hours 200 s 7 hours 30 hours - - -
100秒3時間14時間30時間200秒7時間30時間---
We hope to receive assistance from the IPmc/RSVP development community within the IETF in validating and refining this model. We believe it will be a useful tool for predicting the behavior of RSVP-capable systems.
このモデルの検証と改良において、IETF内のIPmc / RSVP開発コミュニティからの支援を期待しています。 RSVP対応システムの動作を予測するための便利なツールになると考えています。
This RFC raises no security considerations.
このRFCでは、セキュリティに関する考慮事項はありません。
[1] Deering, S., "Host Requirements for IP Multicasting", STD 5, RFC 1112, August 1989.
[1] Deering、S。、「IPマルチキャストのホスト要件」、STD 5、RFC 1112、1989年8月。
[2] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[2] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource Reservation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
[3] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[3] Wroclawski、J。、「The Use of RSVP with IETF Integrated Services」、RFC 2210、1997年9月。
[4] MIL3 Inc., "OPNET Modeler Tutorial Version 3", Washington, DC, 1997
[4] MIL3 Inc。、「OPNET Modeler Tutorial Version 3」、ワシントンDC、1997
[5] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[5] Moy、J。、「OSPFへのマルチキャスト拡張」、RFC 1584、1994年3月。
[6] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress.
[6] Pusateri、T。、「Distance Vector Multicast Routing Protocol」、Work in Progress。
Authors' Addresses
著者のアドレス
J. Mark Pullen C3I Center/Computer Science Mail Stop 4A5 George Mason University Fairfax, VA 22032
J.マークプレンC3Iセンター/コンピュータサイエンスメールストップ4A5ジョージメイソン大学フェアファックス、バージニア州22032
EMail: mpullen@gmu.edu
Ravi Malghan 3141 Fairview Park Drive, Suite 700 Falls Church VA 22042
Ravi Malghan 3141 Fairview Park Drive、Suite 700 Falls Church VA 22042
EMail: rmalghan@bacon.gmu.edu
Lava K. Lavu Bay Networks 600 Technology Park Dr. Billerica, MA 01821
溶岩。 2つのネットワークに200のテクノロジーパークレートをもたらします。ビレリケ、0171
EMail: llavu@bacon.gmu.edu
Gang Duan Oracle Co. Redwood Shores, CA 94065
Gang Duan Oracle Co. Redwood Shores、CA 94065
EMail: gduan@us.oracle.com
Jiemei Ma Newbridge Networks Inc. 593 Herndon Parkway Herndon, VA 20170
Jiemei Ma Newbridge Networks Inc. 593 Herndon Parkway Herndon、VA 20170
EMail: jma@newbridge.com
Hoon Nah C3I Center Mail Stop 4B5 George Mason University Fairfax, VA 22030
Hoon Nah C3Iセンターメールストップ4B5ジョージメイソン大学フェアファックス、バージニア州22030
EMail: hnah@bacon.gmu.edu
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。