RFC2490 日本語訳
2490 A Simulation Model for IP Multicast with RSVP. M. Pullen, R.Malghan, L. Lavu, G. Duan, J. Ma, H. Nah. January 1999. (Format: TXT=74936, PS=1956365, PDF=135368 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループM.ピューレンの要求をネットワークでつないでください: 2490年のジョージメイスン大学Category: 情報のR.のH.Nahジョージメイスン大学Malghan日立データシステムズL.LavuベイネットワークスG.DuanオラクルJ.マNewBridge1999年1月
A Simulation Model for IP Multicast with RSVP
RSVPがあるIPマルチキャストのためのシミュレーションモデル
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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
1. バックグラウンド2 2。 OPNETシミュレーション環境3 3。 IP Multicast Model3 3.1Address Format3 3.2Network Layer4 3.3Nodeは5 4を層にします。 RSVPモデル13 4.1RSVPアプリケーション13
Pullen, et. al. Informational [Page 1] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[1ページ]のRFC2490IPマルチキャスト
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
4.2 ルータ14 4.3RSVPでの存在RSVPは5に17を接待します。 マルチキャストルート設定Model Interface、19、5.1Creation、マルチキャストルーティングプロセッサノード19 5.2のInterfacingプロセッサノード19 5.3Interrupt Generation、21、5.4Modifications、プロセス・モデルのモジュール、22、6 OSPFとMOSPFが23の6.1のイニット23 6.2の使用されていない23 6.3BCOspfLsa23 6.4BCMospfLsa23 6.5Arr23 6.6に_こんにちは、pks24 6.7Mospfspfcalc24 6.8Ospfspfcalc25 6.9UpstrNode25 6.10DABRAをモデル化する、25、7 DVMRPモデル26 7.1に、イニット26 7.2に、7.3徹底的調査_が州26 7.4レポート_を送る活動していない26が7.5プルーンの_が7.6汚職_が27 7.7Arr_Pkt27 7.8ルート_電卓28 7.9タイマを送る26を送る26を送る、28、8 シミュレーション性能28 9。 今後の活動29 10。 セキュリティ問題29 11。 参照29作者のアドレス30の完全な著作権宣言文31
1. Background
1. バックグラウンド
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
IPマルチキャスティング[1]のうまくいっている展開とMboneのその有用性は、リアルタイムのマルチメディアインターネットアプリケーションの増加を続けているのに通じました。 インターネットがベストエフォート型サービスの質だけを伝統的にサポートしたので、適切なリソースがネットワークで予約されるのをインターネット・プロトコル群を使用することで許容するメカニズムを作成するために、相当な興味があります、指定されたレベルでビデオや、声や、分配されたシミュレーションなどのリアルタイムのトラフィックの品質を支えることができるように。 RSVPプロトコル[2]は、このために開発されて、進行中の実装取り組みの対象です。 RSVPの開発者が彼らのデザイン過程でシミュレーションを使用した、いいえが
Pullen, et. al. Informational [Page 2] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[2ページ]のRFC2490IPマルチキャスト
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.
一般に、RSVPとのIPmcのシミュレーションは性能の分析とこれらのプロトコルの振舞いの予測に利用可能です。 ここで説明されたシミュレーションモデルは、この不足をいっぱいにするために開発されて、IETF共同体に利用可能に作られていることを明らかに意図します。
2. The OPNET Simulation Environment
2. OPNETシミュレーション環境
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.
Optimized Network Engineering Tools(OPNET)はアーリントン(ヴァージニア)のMIL3会社の商業シミュレーション製品です。 それはかなり大きいネットワークにおける多くの密接に区切られたイベントが正確に効率的に表されるのを許容するDiscrete Event Simulationアプローチを使います。 ネットワークが自由自在に下げることができる完全なリンクによってインタコネクトされたコンポーネントで造られるところでOPNETはモデル化法を使用します。 各コンポーネントの振舞いは状態遷移ダイヤグラムとしてモデル化されます。 各状態で行われるプロセスはC言語におけるプログラムで説明されます。 私たちは、これが、OPNETベースのモデルを他のモデル環境に移植するのを比較的簡単にすると信じています。 モデルのこのファミリーはOPNET3.5と互換性があります。 以下のセクションは、私たちが創造したIPmcとRSVPモデルのためにOPNETを使用することで状態遷移モデルとプロセスコードについて説明します。 OPNET層は、よく定義されたインタフェースがある非常にモジュールのソフトウェア要素に必ずネットワークスタックの層に同等であるというわけではありませんが、スタック層と特性を共有します。
3. IP Multicast Model
3. IPマルチキャストモデル
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ネットワーク層かノード層の助けかプロセス層でシミュレートできるホストとルータで詳細に層について説明します、物理的な層から始めて。
3.1 Address format
3.1 アドレス形式
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が長さ24ビットであり、Yが長さ8ビットであるところで「X.Y」で1つのタイプのアドレシングだけを指示させます、IPv4クラスCネットワークに対応しています。 Xは目的地かソースネットワーク・ナンバーを示します、そして、Yは目的地かソースノード番号を示します。 私たちのモデルXでは、=500はマルチキャストトラフィックのために予約されます。 マルチキャストトラフィックのために、Yの値はパケットが属するグループを示します。
Pullen, et. al. Informational [Page 3] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[3ページ]のRFC2490IPマルチキャスト
3.2 Network Layer
3.2 ネットワーク層
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、およびsixサブネットF1、F6を通して。 OPNETに全二重リンクモデルが全くないとき、2シンプレクスが可能な双方向のトラフィックをリンクするとき、各結合リンクはモデル化されます。
[Figure 1: Network Layer of Debug Model]
[図1: デバッグモデルのネットワーク層]
3.2.1 Attributes
3.2.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. それぞれのルータ(ネットワーク_id.node_イド)2のそれぞれのアクティブなインタフェースのIPアドレス。 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の伝播遅延。 シンプレクスをシミュレートするのに使用されるべきプロセス・モデルはリンクします(これは、アニメーションが含まれているかどうかを意味します)。
3.2.2 LAN Subnets
3.2.2 LANサブネット
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リングに関連づけられて、また、通常、別のインタフェースで境界ルータに関連づけられます(境界ルータは1つ以上のバックボーンルータに関連づけられるかもしれません)。 イーサネットでは、すべてのホストがバスに接続されます、ホストは図2で例証されるようにリングでFDDIでインタコネクトされますが。
[Figure 2: FDDI Ring Subnet Layer]
[図2: FDDIリングサブネット層]
Pullen, et. al. Informational [Page 4] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[4ページ]のRFC2490IPマルチキャスト
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は100Mb/秒の通信速度でステーションがリングトポロジーで構成した多くの交信に汎用のネットワークを提供します。 リング帯域幅の使用は調節されたトークン回転プロトコルを通して制御されます。ステーションは、トークンを受けて、フレームを伝える前に、プロトコルで1セットのタイミングと優先権評価基準にあわなければなりません。 応答時間が重要であるネットワーク応用を収容するために、同期転送サービスを定義することによって、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)技術です。 IEEE802.3規格に続いて、メディアアクセス・プロトコル(MAC)によってLANの操作は管理されます、衝突検出型搬送波検知多重アクセス(CSMA/CD)をLANチャンネルに供給して。
3.3 Node layer
3.3 ノード層
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のNodeエディタを使用することで組み込まれるノードレベルイラストの助けにホストとルータの内部の構造について論じます。
3.3.1 Basic OPNET elements
3.3.1 基本的な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。 送信機とReceiverノード: 送信機はパケット伝送のリンク振舞い効果をシミュレートします、そして、Receiversはパケットレセプションの受信効果をシミュレートします。 通信速度は送信機の属性です、そして、レートを受け取るのは、受信機の属性です。一緒にこれらの値はパケットのトランスミッション遅れについて決めます。
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。 統計値ストリーム: 統計値ストリームは異なったノードの間で情報を伝達するのに使用されます: プロセッサ、Queue、Transmitters、およびReceiversノード、それぞれ。
Pullen, et. al. Informational [Page 5] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[5ページ]のRFC2490IPマルチキャスト
3.3.2 Host description
3.3.2 ホスト記述
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層(ネットワーク、Node、およびProcessは層にする)と異なります、プロトコル・スタック要素は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層に対するサービスを供給します。 リング帯域幅の使用は調節されたトークン回転プロトコルを通して制御されます。ホストは、トークンを受けて、フレームを伝える前に、プロトコルで1セットのタイミングと優先権評価基準にあわなければなりません。 フレームがMACノードに届くとき、ノードは以下の動作の1つを実行します:
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層は、フレーム、decapsulatesのコピーをフレームにして、descapsulatedフレーム(パケット)をIP層に送ります。 3 フレームの所有者がホストであるならいかなる他のもFDDIリングでの次期ホストにオリジナルのフレームを伝えます、そして、このホストのためにフレームを運命づけません、そして、隣接しているホストにフレームを送ります。
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_移-プロセッサノードです。 この層は、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
c。 IP待ち行列ノード: 階層構造におけるネットワークルーティング/推進はここで実装されます。 IP層は、MAC層で提供されたサービスを利用することによって、異なったより高い平らなプロトコルである上の層のためのサービスを提供します。 MACから到着するパケットが層にされて、IP decapsulates層が上側の層のプロトコルへの情報がIPヘッダーのプロトコルIDの値に基礎づけたパケットとフォワードであるので。 上側の層のプロトコルから到着するパケットに関しては、IP層は、送付先アドレスを得て、計算します。
Pullen, et. al. Informational [Page 6] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[6ページ]のRFC2490IPマルチキャスト
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.
次のノードアドレス、次のノード情報と共にテーブルを発送して、IPヘッダーと共にそれをカプセル化して、addr_移-ノードにパケットを送ります。
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層に到着するパケットは、ファーストインファーストアウト(先入れ先出し法)規律で列に並ばせられて、作動します。 待ち行列サイズ、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_ホスト(ルータマルチキャストモデル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_ホストノード(図4)はプロセスノードです。 パケットはこの層の中に列に並ばせられません。 IGMP_ホストはIP層で提供されたサービスを利用するマルチキャストアプリケーションのためのユニークなグループ経営指導を提供します。 IGMP_ホストはIGMP層を超えてアプリケーションのグループ会員資格情報から成る単一のテーブルを維持します。 IGMP_ホスト層によって実行された機能は受け取られたパケットのタイプとパケットの源に頼っています。
[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_ホスト層は応用層とネットワークからあるタイプのパケットを予想します:
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
1. 受け入れてください。応用層(1つ以上のアプリケーションであるかもしれない)からのグループ要求に参加してください: IGMP_ホストは各グループのための会員資格情報から成るテーブルを維持します。 アプリケーションがaを送るときには要求に参加してください、そして、それは、特定のグループN.に加わるために、会員資格情報をアップデートするよう要求します。 この新しいグループ会員資格情報は最も近いルーターと、そして、MAC層に伝えられなければなりません。 IGMP_ホストが既にメンバーofthisグループ(すなわち、IGMP_ホストの上の別のアプリケーションがグループNのメンバーであるなら)であるなら、IGMP_ホストは、メッセージをルータに送る必要はありませんし、また層にするようにMACに示す必要はありません。 IGMP_ホストが現在IGMP_ホストがaを生成するメンバーがグループNを求める要求に参加するという(これはRFC1112に「応答」と呼ばれます)ことでなく、それをIPに送るなら層にして、最も近いルーターに送ってください。 また、さらに、IGMP_ホストはそのようにIGMP_ホストからMAC層まで接続されたOPNET「統計値ワイヤ」を通して物理的な層に連結するMAC層にこの会員資格情報を伝えます。
Pullen, et. al. Informational [Page 7] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[7ページ]のRFC2490IPマルチキャスト
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.
MAC層がすぐに、会員資格情報を知って、フレームを受け入れ始めるのはグループN.のために運命づけられました。(OPNET統計値ワイヤはOPNETモデルの間に情報を送る仮想の経路です。) 2. 最も近いルーターから到着する質問を受け入れてください、そして、IGMP_ホスト層のマルチキャストテーブルの会員資格情報に基づく応答を送ってください: 質問はグループ会員資格情報に関してルータのインタフェースの各ホストについて問い合わせるルータからのメッセージです。 IGMP_ホストが質問を受けるとき、それは、ホストのアプリケーションのどれかが何かグループのために登録されるかどうか決定するためにマルチキャストグループ会員資格テーブルを見上げます。 何か登録が存在しているなら、IGMP_ホストは、イベントがそれぞれの活動的なグループに対応する無作為の時間の後に応答を生成する計画をします。 図5のイーサネットの例と以下のセクションの記述はシナリオについて説明します。
---------------------------------------
| | | |
| | | |
+---+ +---+ +---+ +---+
| H1| | H2| | H3| | R |
+---+ +---+ +---+ +---+
--------------------------------------- | | | | | | | | +---+ +---+ +---+ +---+ | 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_ホストは、イベントがホストH1を示すt1(t1>はt0と等しい)がグループN1のメンバーである手当たりしだいに発生している時代に応答を生成する計画をします。 同様に、H2は、イベントがグループN3で会員資格を示すためにt3(t3>はt0と等しい)のグループN2とH3で会員資格を示すためにt2(t2>はt0と等しい)で応答を生成する計画をするでしょう。 応答が発生しているとき、マルチキャストグループアドレスに設定された送付先アドレスと共に応答を送ります。 したがって、グループのすべてのメンバーホストがサブネットにおける同じグループのメンバーである他のホストによって送られた応答を受けるでしょう。
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
上記の例では、H3が生成する前にH1のIGMP_ホストはt1<t3であるなら、グループN1で会員資格をアップデートするために応答を生成するでしょう、そして、また、H3はルータに加えたこの応答を受けるでしょう。 H3のIGMP_ホストがH1によって送られた応答を受けるとき、H3のIGMP_ホストは時間t3のときに予定されていたイベントを取り消します、そのグループのための応答をルータに送ったので。 この仕事、イベントを作るために
Pullen, et. al. Informational [Page 8] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[8ページ]のRFC2490IPマルチキャスト
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.
質問への応答を生成するのは手当たりしだいに予定されています、そして、上の説明されたイベントの計画をするのがどのルータに間隔より少ないかが強制されるので、間隔は質問を送ります。 3. 何か応用層がパケットが運命づけられているグループのメンバーであるならサブネットにおける他のホストによって送られた応答を受け入れてください。 4. 受け入れてください。Application層からのグループ要求を終えてください。 アプリケーションが、グループを出ると決めると、これらの要求は応用層によって生成されます。 IGMP_ホストは、グループ情報テーブルをアップデートして、次に、このグループに対応する少しの応答も送らないでしょう(別のアプリケーションがこのグループのメンバーでないなら)。 ルータがグループのために特定のインタフェースで、ある時間で少しの応答も受けないとき、そのインタフェースの会員資格はそのグループで取り消されます。
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ノード目的は、どれが基本的なIPだけによって提供されたサービスを利用するかをQoSの特定のレベルとベストエフォート型トラフィックを達成するためにRSVPによって提供されたサービスを利用することで1つのタイプの適用を持っているネットワークで観測しました。
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ノードは、FTPなどのアプリケーションからネットワークで競争しているトラフィックをモデル化するために手当たりしだいに発生しているIPアドレスにトラフィックを生成します。 経路指定テーブルの情報に基づくパケットを発送する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. セッションInterArrival時間(IAT): 変数は、イベント開会する計画をするのに使用されますか? UBEノードは、意地悪なSession IATと共に指数関数的に分配された確率変数を生成して、その時、データがトラフィックであると生成し始めます。 2. データIAT: UBEが、データがトラフィックであると生成するとき、データ・パケットの間のinterarrival回はData IATです。 Data IATの値の減少はネットワークにおける、混雑の厳しさを増強します。 3. セッション-分とセッション最大: UBEノードが、そのセッションのときにデータがトラフィックであると生成し始めるとき、無作為の期間、どれが一様にSession-分とSession-最大の間に分配されるかは残っています。
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:
f。 マルチキャストApplicationプロセッサノード: 応用層はプロセスノードである1つ以上のアプリケーションノードから成ります。 これらのノードは下位層プロトコルIGMP、RSVP、およびIPによって提供されたサービスを利用します。 要求とトラフィックがApplication層のプログラム応用層の属性で生成したApplication階層モデルは以下の通りです。
Pullen, et. al. Informational [Page 9] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[9ページ]のRFC2490IPマルチキャスト
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].
1. セッションIAT: 変数は、出来事開会する計画をするのに使用されますか? Applicationノードは、意地悪なSession IATと共に指数関数的に分配された確率変数を発生させて、その時、特定のグループのための情報を発生させて、また、そのグループのものパケットを受け入れ始めます。 2. データIAT: Applicationノードがデータ通信量を発生させると、パケットの間の間の到着時間は議論としてData IAT変数を使用します。 分配はOPNETでの利用可能な分配機能のいずれであることができますも。 3. セッション-分とセッション最大: アプリケーションがアプリケーションがそのセッションのときに残っている持続時間はSession-分までに境界があるセッションとSession-最大に参加するとき。 Session-分とSession-最大の間の一様に分配された確率変数はこのために発生します。 その時々で各ノードには、データのゼロか1回の流れがあるでしょう。 4. NGRPS: 使用されるこの変数はアプリケーション発生マルチキャストでアプリケーションが接合するためにIGMPを要求するグループの値をバウンドに取引します。 グループは範囲[0、NGRPS-1]から無作為に選択されます。
[Figure 6: Node Level of Gateway]
[図6: ゲートウェイのノードレベル]
3.3.3 Router description
3.3.3 ルータ記述
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。 ルータで実行された待ち行列のテクニックは入出力待ち行列の組み合わせです。 rx10へのノードrx1は入って来るリンクに接続された受信機です。 図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
1つの主要な違いがホストにサブネットルータにおけるMACノードとそれの間にあります。 サブネットルータにおけるMACノードはホストのグループのためにどれについてマルチキャストパケットだけを受け入れるMACと異なったすべて到着しているマルチキャストパケットを受け入れます。
Pullen, et. al. Informational [Page 10] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[10ページ]のRFC2490IPマルチキャスト
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).
ホストはメンバーです。 この理由で、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_、移-、: ルータ階層構造のリンクレイヤはIPアドレスを物理アドレスに翻訳するサービスを備えるaddr_移-プロセッサノードです。 addr_移-ノードは上でホストモデルの下で説明されました。
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. ユニキャスト経路指定テーブル: このテーブルは一次元のただ一つの勢ぞろいです。(それは、ホストのUDP過程ノードで発生するパケットを発送するのに使用されます)。 ルートが全く特定のIPアドレスに知られていないなら、対応するエントリーはデフォルトルートに設定されます。 2. マルチキャスト経路指定テーブル: このテーブルはNがモデルのマルチキャストグループの最大数であるIアレイのそばのNです、そして、Iはルータで、インタフェースの数です。 このテーブルは、マルチキャストパケットを発送するのに使用されます。 ルータにおける経路指定テーブルは上側の層のルーティング・プロトコルによって設定されます(下のセクション4を見てください)。 セッション_イドが対応していた状態でIP層がMOSFPを利用しているセッションまでマルチキャストパケットを受けるとき、それは、次のホップを得るためにマルチキャスト経路指定テーブルを見上げます。 3. 会員資格テーブルを分類してください: このテーブルは、ルータのすべてのインタフェースのグループ会員資格情報を保守するのに使用されます。 またIアレイのNであるこのテーブルはIGMP層のプロトコルによって用意をされます。 ルーティング・プロトコルは、計算するグループ会員資格テーブルのこの情報を使用して、Multicast経路指定テーブルにルートをはめ込みます。
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ノードに到着するとき、パケットはそれらの交通カテゴリの優先権に基づく適切なサブ待ち行列に挿入されます: コントロール交通、リソースは交通、またはベストエフォート型交通を控えました。 非割込み型優先はパケットを調整する際に使用されます。 整備点検の後に、出力キューかMACの1つにパケットを送ります。 送信機が利用可能になるまで、これらを通したパケット進歩は列を作ります。
Pullen, et. al. Informational [Page 11] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[11ページ]のRFC2490IPマルチキャスト
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. 各インタフェース(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ノード: また、ルータでモデル化されているのは、特定のQoSセットアップを提供するためにマルチキャスティング、ルーティング・プロトコル、およびRSVPを実行するためのIGMPです。
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ノードはRFC1112で定義されるようにIGMPプロトコルを実行します。 ルータ(図7)における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が受信するとき、質問への応答は発信しました、IPノードのマルチキャストGroup会員資格テーブルとMOSPF LSAの上の引き金がアップデートするIGMPアップデート。 3. 毎回、IGMPは質問を送ります、また、どんな応答のときにもどんなインタフェースに関するグループのためにも受け取っていないなら、IPノードでマルチキャストグループ会員資格テーブルをアップデートします、インタフェースがもうそのグループのメンバーでないことを示して。 単にルータが最後の質問のための応答を受けていないインタフェースに関するグループに、アクティブな会員資格が発信したのを示すエントリーのときにこのアップデートをします。 4. ルーティング・プロトコル(以下のection4を見る)は、ルートを計算して、マルチキャスト経路指定テーブルをアップデートするのにグループ会員資格テーブルの情報を使用します。 5. それぞれグループでは、それがメンバーであるので、いつでIGMPが質問を受けて(ルータにおけるIGMPは直接接続された隣接しているルータから質問を受けることができます)、IGMPノードがa応答を作成するか、質問が受けられたもの以外のすべてのインタフェースで。 6. 背骨ルータのIGMPノードは障害があります、ルータにホストがサブネットにいるとIGMPが使用されるだけであるので。
Pullen, et. al. Informational [Page 12] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[12ページ]のRFC2490IPマルチキャスト
[Figure 7: IGMP process on routers]
[図7: ルータのIGMPの過程]
4. RSVP model
4. RSVPモデル
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]でよく見られます。
4.1 RSVP APPLICATION
4.1 RSVPアプリケーション
4.1.1 Init
4.1.1 イニット
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.
Multicast Group ID、Data、セッションの終了のためにすべての変数を初期化して、分配機能をロードします。 すべての初期化処理を終了した後のIdle状態へのトランジット。
4.1.2 Idle
4.1.2 怠けてください。
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.
この州は2つの州、Join、およびData_Sendに変遷を持っています。 aセッションに参加する予定であるか、またはアプリケーションが現在のセッションを終える予定であるのが当時Join状態に通過します、アプリケーションがデータを送るだろうというときのData_Send状態へのトランジット。
4.1.3 Join
4.1.3 接合してください。
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.
Applicationは地方のRSVPデーモンにセッション呼び出しを送るでしょう。 応答では、それはLocalデーモンからセッション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.
アプリケーションがそれがそれによってつないで、aを受信されたいというマルチキャストグループのためのセッションディレクトリの送付者情報がないかどうかチェックする受信機として機能しているなら、地方の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デーモンへのリリース呼び出しをどれであったかに送るだろうか、そして、aが終えるセッションを終えるのを選ぶなら、IGMPデーモンに呼びかけてください。 これらの機能を完成した後に、それは活動していない状態に戻るでしょう。
[Figure 8: RSVP process on routers]
[エイト環: ルータのRSVPの過程]
Pullen, et. al. Informational [Page 13] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[13ページ]のRFC2490IPマルチキャスト
4.1.4 Data_Send
4.1.4 データ_は発信します。
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.
それが選択するマルチキャストの目的地にデータ・パケットを作成して、それを送ります。 それは、それが送ったいくつのパケットの動向をおさえるかためにカウンタをアップデートします。 デフォルトのこの状態はIdle状態に戻ります。
4.2 RSVP on Routers
4.2 ルータのRSVP
Figure 8 shows the process model of RSVP on routers.
エイト環はルータでRSVPのプロセス・モデルを見せています。
4.2.1 Init
4.2.1 イニット
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状態まで続くでしょう。
4.2.2 Idle
4.2.2 怠けてください。
Idle state transit to Arr state upon receiving a packet.
パケットを受けるとき、Arr状態に州のトランジットを空費してください。
4.2.3 Arr
4.2.3 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州によって呼び出されました。 それが呼ばれる前に、Path Messageを進めるための最新の経路指定テーブルを手に入れるために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
1. 最初に、Path州のブロックがないかどうかどれに合っている送付先アドレスがあるかをチェックして、送付者ポート、送付者アドレスまたは仕向港がPath州のブロックのSession物の値に合っていないなら、それは、経路エラーメッセージを送って、戻ります。 (現在のところアプリケーションはどんなエラーメッセージも送らないで、私たちはコンソールに関するこのエラーメッセージを印刷します。) 2. 経路メッセージのものとのマッチがSession ObjectとSender Template Objectを受けたPSBが見つけられるなら、現在のPSBは推進PSBになります。 3. 対応が経路メッセージでセッションと送付者テンプレートマッチを反対させて、入って来るインタフェースがIncInterfaceに合っているPSBを捜し求めてください。 そして、そのようなPSBが見つけられる、Previous Hop Address、Next Hop Address、およびSenderTspec Objectが経路メッセージのものに合っていないなら、経路メッセージの値は必要な旗が回される経路州のブロックとPath Refreshにコピーされます。 前のホップアドレスであるなら、次に、跳んでください。
Pullen, et. al. Informational [Page 14] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[14ページ]のRFC2490IPマルチキャスト
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.
PSBのアドレスは経路メッセージと異なっていて、次に、また、必要な旗が回されて、Current PSBがされるResv RefreshはこれとPSBと等しいです。 4. そして、そして、合っているPSBが見つけられないなら新しいPSBが作成される、必要なFlagが回されて、Current PSBがされるPath RefreshはこれとPSBと等しいです。 5. Path Refreshであるなら、必要なFlagはオンです、そして、Current PSBは推進PSBにコピーされます、そして、Path Refresh Sequenceは実行されます。 PathRefreshと呼ばれるこの機能を実行するのは使用されています。 外向的なインタフェースに記載することである推進経路州のブロックのあらゆるインタフェースに経路Refreshを送ります。 6. 推進PSBのSender Template Objectとのフィルタ仕様物のマッチと推進PSBの外向的なインタフェースのエントリーのOutgoing Interfaceマッチ1が記載する予約州Blockを捜し求めてください。 見つけられるなら、a Resv Refreshは推進PSBにおけるPrevious Hop Addressへ通信して、Update Traffic Control系列を実行します。
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から呼ばれます。 それはPathMsgProによって指定される外向的なインタフェースを通してメッセージがメッセージを送るPathを作成します。
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. 外向的なインタフェースを決定してください、そして、PSBがないかどうかだれのSource AddressとSession ObjectsがResvメッセージのものに合っているかチェックしてください。 2. そのようなPSBが見つけられないなら、ResvErrメッセージにどんなPath情報も利用可能でないと言わせてください。 (私たちはこのメッセージを実行していなくて、コンソールに関するエラーメッセージを印刷するだけです。) 3. 両立しないスタイルと過程がないかどうか流れ記述子リストをチェックして、予約をしてください、送付者情報がないかどうかPSBリストをチェックして。 どんな送付者情報もPSBリストを通して利用可能でないなら、ErrorメッセージにそのいいえSender情報を言わせてください。 PSBsが見つけたすべてのマッチングには、Refresh PHOPリストにPSBのPrevious Hop Addressがないなら、Refresh PHOPリストにPrevious Hop Addressを追加してください。 4. 合っている予約州Block(RSB)がないかどうかだれのSessionとFilter Spec ObjectがResvメッセージのものに合っているかチェックしてください。 どれかそのようなRSBが見つけられないなら、Resv Messageから新しいRSBを作成してください、そして、NeworMod旗のOnを設定してください。 activeRSBとしてこのRSBに電話をしてください。 Resvにおける回転は必要な旗をリフレッシュします。 5. 合っているRSBが見つけられるなら、物をactiveRSBとこのRSBのFlowSpecとScope物がResv MessageコピーのResvメッセージFlowspecとScopeのものと異なっているかどうかとしてのこれにActiveRSBに電話をしてください、そして、NeworMod旗のOnを設定してください。
Pullen, et. al. Informational [Page 15] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[15ページ]のRFC2490IPマルチキャスト
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. アップデートトラフィックコントロール系列に電話をしてください。 機能をUpdateTrafficControl7と呼ぶことによって、これをします。 Resv Refreshであるなら、必要なFlagはOnであり、次に、Refresh PHOP Listの各Previous HopへのResvRefreshメッセージを送ってください。 Refresh PHOP ListのあらゆるPrevious Hopのために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とPrevious Hopと共に入力されるようにPathMsgProとResvMsgProの両方によって呼ばれます。 機能は、RSBからResv Messageを組み立てて、メッセージをPrevious Hopに送ります。
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. Session ObjectとSender Template Objectが到着したPathTearメッセージのものに合っているPSBを捜し求めてください。 2. そのようなPSBが見つけられないなら、無とリターンをしてください。 3. 合っているPSBを見つけるなら、PSBのOutgoing Interfaceリストに記載されているすべての外向的なインタフェースにPathTearメッセージを送ります。 4. Filter Spec ObjectがPSBのSender Template Objectに合っているすべてのRSBを捜し求めてください、そして、このRSBのOutgoing InterfaceがPSBのOutgoingインタフェースリストに記載されるなら、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. RSBがないかどうかSession Object、ResvTearメッセージと何かそのようなRSBがないかどうか戻るFilter Spec Objectマッチをチェックしてください。 4. RSBが見つけられるそのようなものとResv Refreshであるなら、必要なFlagによるRefresh PHOP ListにあるすべてのPreviousホップスへの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州によって呼び出されます。 受信されたResvConfメッセージのResv Confirm ObjectにあったIPアドレスにResv Confirmを送ります。
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リストはSession Object、およびFilter Spec Objectを入力RSBに合わせる合っているRSBを捜されます。 2. 有効なKernel TC_FlowspecはRSBのこれらのすべてのもののために計算されます。
Pullen, et. al. Informational [Page 16] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[16ページ]のRFC2490IPマルチキャスト
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のFilter Spec ObjectがTC Filter Spec ListでFilter Spec Objectの1つに合っていないなら、TC Filter Spec ListにFilter Spec Objectを加えてください。 4. 入力RSBのFlowSpec ObjectがTC_Flowspecより大きいなら、Is_Biggest旗をつけてください。 5. Session Object、Outgoing Interface、およびFilter Spec ObjectがInput RSBのものに合わせる合っているTraffic Control州Block(TCSB)を捜し求めてください。 6. そのようなTCSBが見つけられないなら、新しいTCSBを作成してください。 7. 合っているTCSBが見つけられるなら、予約を変更してください。 8. 回転にBiggestが旗を揚げさせるIs_があるなら、必要なFlagがほかに旗を揚げさせるResv Refreshでは、入力RSBのResvConfirm ObjectのIPアドレスにResvConf Messageを送ってください。
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が上で説明したファンクションコールでこの州によって行われる機能をします。
4.3 RSVP on Hosts
4.3 ホストの上のRSVP
Figure 9 shows the process of RSVP on hosts.
図9はホストの上にRSVPの過程を示しています。
4.3.1 Init
4.3.1 イニット
Initializes all the variables. Default transition to idle state.
すべての変数を初期化します。 状態を空費するデフォルト変遷。
[Figure 9: RSVP process on hosts]
[図9: ホストのRSVPの過程]
4.3.2 idle
4.3.2 怠けてください。
This state transit to the Arr state on packet arrival.
パケット到着のArr状態へのこの州のトランジット。
4.3.3 Arr
4.3.3 Arr
This state calls the appropriate functions depending on the type of message received. Default transition to idle state.
この州は、適切な機能を受け取られたメッセージのタイプに頼ると呼びます。 状態を空費するデフォルト変遷。
Pullen, et. al. Informational [Page 17] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[17ページ]のRFC2490IPマルチキャスト
a. MakeSessionCall: This function is called from the Arr state whenever a Session call is received from the local application.
a。 MakeSessionCall: 局所塗布からSession呼び出しを受けるときはいつも、この機能は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. 1つが見つけられるなら、対応するSessionアイダホ州を返してください。 3. セッション情報が見つけられないなら、対応するセッションまで新しいセッションIdからセッションを割り当ててください。 4. UpCallをこのSessionアイダホ州との局所塗布にしてください。
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. Session 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状態から呼ばれます。 局所塗布が局所塗布が受信機であるなら送付者であるかResvTearメッセージを発生させると、この機能はPathTearメッセージを発生させるでしょう。
4.3.4 Session This state's function is performed by the MakeSessionCall function.
4.3.4 セッションThis状態の機能はMakeSessionCall機能によって実行されます。
4.3.5 Sender
4.3.5 送付者
This state's function is han by the MakeSenderCall function.
この状態の機能はMakeSenderCall機能によるhanです。
4.3.6 Reserve
This state's function
is performed by the MakeReserveCall function.
4.3.6 蓄えのThis状態の機能はMakeReserveCall機能によって実行されます。
4.3.7 Release
4.3.7 リリース
This state's function is performed by the MakeReleaseCall function.
この状態の機能はMakeReleaseCall機能によって実行されます。
Pullen, et. al. Informational [Page 18] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[18ページ]のRFC2490IPマルチキャスト
5. Multicast Routing Model Interface
5. マルチキャストルート設定モデルインタフェース
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の利用可能な実現があります。(私たちは以下でOSPFについて説明するつもりです)。 これらのモデルを呼び出すための指示はモデルのための別々のUserのガイドに含まれています。
5.1 Creation of multicast routing processor node
5.1 マルチキャストルーティングプロセッサノードの創造
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 Simulationパッケージを使用することでマルチキャストルーティング・プロトコルを連結するのはパケットの流れでノードエディタとそれをリンクすることにおける、新しいルーティングプロセッサノードの創造を必要とします。パケットの流れはプロセッサノード、待ち行列ノード、送信機、および受信機ノードとインタコネクトするのに使用される単方向のリンクです。 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つの暗いノードで、表される)を選択することによって、発生します、リンクの源を指定するためにマウスボタンの上に左クリックして、リンクの目的地を示すためにマウスボタンの上に右クリックして。
5.2 Interfacing processor nodes
5.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
マルチキャストルーティングプロセッサノードは重複の接続と共にIPプロセッサノードとそれぞれIGMPプロセッサノードにリンクされます。 2つのノードの間の重複の接続は情報か中断の双方向の流れを供給しながらそれらとインタコネクトする2個のuniの方向のリンクによって代理をされます、図6に示されるように。 IPプロセッサノード(サブネットルータにおける)はマルチキャストルーティングプロセッサノードに連結します、ユニキャストルーティングプロセッサノード、Resource予約プロセッサノード(RSVP)、ARPプロセッサノード、(オンだけ
Pullen, et. al. Informational [Page 19] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[19ページ]のRFC2490IPマルチキャスト
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.
サブネットルータとホスト)、IGMPプロセッサノード、および最終的にそれぞれARPのための例外とMACノードとの重複の関係とのMACプロセッサノード(サブネットルータとホストだけの)。
5.2.1 Interfacing ARP and MAC processor nodes
5.2.1 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ノードへの単一のuni方向のリンクでIPプロセッサノードに接続します。
5.2.2 Interfacing IGMP, IP, and multicast routing processor nodes
5.2.2 IGMP、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ノードにリンクされるので、その結果、それはIPノードの中でグループ会員資格テーブル(このモデルで、マルチキャスト経路指定テーブルデータ構造の局所界面(インタフェース0)によってグループ会員資格テーブルは表される)をアップデートできます。 このアップデートはそれがIPノードの中でマルチキャスト経路指定テーブルを再評価するIGMPノードからマルチキャストルーティングプロセッサノードに信号の引き金となります。 グループ会員資格テーブルにおける変化がマルチキャスト経路指定テーブルの変更を保証するなら、マルチキャストルーティングプロセッサノードは、IGMPによってアップデートされた新しいグループ会員資格情報によると、現在のマルチキャスト経路指定テーブルを変更するためにIPノードと対話します。
5.2.2.1 Modification of group membership table
5.2.2.1 グループ会員資格テーブルの変更
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
いなくなるか、または特定のマルチキャストグループに加わるという決定がホストにある状態で、グループ会員資格における変化は起こります。 ゲートウェイのIGMPの過程はどのホストが現在特定のグループからパケットを受けているかを決定する試みにおけるサブネットの中で定期的にホストのIGMPの過程に質問を出します。 グループに特定の未定のIGMPホスト質問のための応答を受けないのは、特定のグループに属すどんなホストもサブネットで存在しないのをゲートウェイIGMPに示します。 サブネットにおけるマルチキャストグループの最後の残っているメンバーがいなくなるとき、これは起こります。 この場合、IGMPプロセッサノードは、マルチキャストルーティングプロセッサノードを警告することによって、できた状態でグループ会員資格をアップデートして、マルチキャスト経路指定テーブルの変更の引き金となります。 グループに特定のプルーンのメッセージは、現在のサブネットに通じるインタフェースにプルーンの状態を設置しながら、上向きに開始されて、伝播されます、事実上、グループ特有のマルチキャストスパニングツリーからこのサブネットを取り除いて
Pullen, et. al. Informational [Page 20] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[20ページ]のRFC2490IPマルチキャスト
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工程で管理されます。
5.2.2.2 Dependency on unicast routing protocol
5.2.2.2 ユニキャストルーティング・プロトコルに関する依存
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プロセッサノードでテーブルの上に置くrecalculateにそれを使用します。
5.3 Interrupt Generation
5.3中断世代
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ツールを使用して、マルチキャストルーティングプロセッサノードへの中断はいくつかの方法で発生します。 パケットがMACノードによって受け取られて、IPヘッダー決断が捨てるときにどの上側の層のプロトコルに関してパケットを送るのがされるIPノードに伝播されるとき、1つはパケットの流れ(マルチキャストルーティングプロセッサノードの)に沿ったマルチキャストパケットの到着です。 2番目のタイプの中断世代はグループ会員資格テーブルのアップデートのマルチキャストルーティングの過程を警告するIGMPの過程からのリモート中断で起こります。 IPノードに受け取られたマルチキャストパケットのための特定のソース/グループ(S、G)エントリーが現在のマルチキャスト経路指定テーブルに存在していなくて、新しいエントリーが、作成される必要があると、3分の1は起こります。 IPノードは新しいソース/グループエントリーをマルチキャスト経路指定テーブルに作成するためにそれを知らせるマルチキャストルーティングプロセッサノードに中断を発生させます。
5.3.1 Types of interrupts
5.3.1 中断のタイプ
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
中断コード、整数の表すことを使用することで中断のタイプと中断のための状態を指定することによって、OPNETモデルの中で発生したプロセス割込み機構は扱うことができます。
Pullen, et. al. Informational [Page 21] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[21ページ]のRFC2490IPマルチキャスト
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.
特定の中断のための状態。 中断のための状態は、中断から生じながら、状態を発生させる中断をリンクする中断の流れと州で指定されます。 自己中断(同じ過程の中で州の中で発生する中断)において、タイプ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言語に書かれている)の中で中断コードを提供します。 中断のための状態が本当になるとき、変遷を中断の流れで指定された結果の状態にします。
5.3.2 Conditions for interrupts
5.3.2 中断のための状態
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 Simulation ModelでIGMPプロセッサノード、IPプロセッサノード、およびマルチキャストルーティングプロセッサノードを互いに連結するように存在しています。 また、ユニキャストルーティングとのIPプロセッサノードインタフェースはIGMPプロセッサノードとのどのインタフェースについて議定書の中で述べるか。 マルチキャストパケットがIPプロセッサノードからマルチキャストルーティングプロセッサノードまでのパケットの流れで到着するとき、OPC_INTRPT_STRM中断は発生します。 グループのメンバーが特定のグループから会員資格を放棄するとき、タイプのリモート中断(OPC_INTRPT_REMOTE)がIGMPの過程からIPの過程まで発生するか、または新しいメンバーはグループに追加されます。 IPノードにまた、マルチキャストルーティング・プロトコルの過程にリモート中断を発生させるIGMP工程で位置するグループ会員資格テーブルでこの新しい会員資格をアップデートします、IPモジュールでマルチキャスト経路指定テーブルの再計算を引き起こして。
5.4 Modifications of modules in the process model
過程における、モジュールの5.4の変更がモデル化されます。
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 Simulationツールを使用することで透明にルーティング・プロトコルモジュール(事実上、プロセス・モデルのモジュールのすべて)の変更をします。 どんなサブネットでも、ルーティングモジュールの添加か変更がすべてのサブネットをよく考えるでしょう。
Pullen, et. al. Informational [Page 22] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[22ページ]のRFC2490IPマルチキャスト
6. OSPF and MOSPF Models
6. OSPFとMOSPFモデル
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.
14の州を含んでいて、OSPFとMOSPFモデル[5]はOSPFモデルで実行されます。 それらはルータに存在するだけです。 図10はプロセス・モデルを示しています。 以下の処理は示されたモジュールで行われます。
6.1 init
6.1 イニット
This state initializes all the router variables. Default transition to idle state.
この州はすべてのルータ変数を初期化します。 状態を空費するデフォルト変遷。
6.2 idle
6.2は怠けます。
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に通過して、_こんにちは、pksは状態です。 また、これから、バージョン、来るリンクまたは下にが変遷を引き起こすでしょう。
6.3 BCOspfLsa
6.3 BCOspfLsa
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.
活動していない状態からのこの状態への変遷は_状態が発信するときはいつも、実行されて、ospf_lsaが本当であり、(ネットワークが初期化されているとき、起こります)ospf_lsa_がリフレッシュするとき_timoutが現れるということです。 この州は、Router、Network、Summary Link州Advertisementsを作成して、Link州Updateパケットに彼らに皆、詰め込むでしょう。 AllSPFRoutersの送付先アドレスがあるIP層にLink州Update Packetを送ります。
[Figure 10: OSPF and MOSPF process model on routers]
[ルータの図10: OSPFとMOSPFプロセス・モデル]
6.4 BCMospfLsa
6.4 BCMospfLsa
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.
活動していない状態からのこの状態への変遷は_状態が発信するときはいつも、実行されて、mospf_lsaが本当であるということです。 この州は、Group Membership Link州Advertisementを作成して、Mospf Link州Update Packetにそれらに詰め込むでしょう。 AllSPFRoutersの送付先アドレスがあるIP層にこのMospf Link州Update Packetを送ります。
6.5 arr
6.5 arr
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パケットのタイプに頼るのは以下が機能するという機能要求を受けました。
Pullen, et. al. Informational [Page 23] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[23ページ]のRFC2490IPマルチキャスト
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_プロ: この機能が呼ばれる、いつ、こんにちは、パケットは受け取られているか。 この機能はルータの隣人情報をアップデートします。(それは、後で異なったLSAsを送る間、使用されます)。 2. OspfLsUpdatePk_プロ: OSPF LSAアップデートパケットが受け取られているとき(ルータLSA、ネットワークLSA、または概要LSA)、この機能は呼ばれます。 RouterがArea Border RouterであるかLSAがArea IdがRouters Area IdであるAreaに属すなら、それは、このLSAがLink州データベースに既に存在するかどうか決定するために捜されます。 存在していて、既存のLSAのLS Sequence Numberが容認されたLSAのLS Sequence Number以下であるなら、既存のLSAを容認されたものに取り替えました。 機能はそれが代表ルータかArea Border Routerである場合にだけNetwork LSAを処理します。 それはルータがArea Border Routerである場合にだけSummary LSAを処理します。 また、機能はarr状態からospfspfcalcまでの変遷のための状態である引き金のospfspfcalcをつけます。 3. MospfLsUpdatePk_プロ: MOSPF LSAアップデートパケットが受け取られているとき、この機能は呼ばれます。 それはルータに関するグループ会員資格リンク州のデータベースをアップデートします。
6.6 hello_pks
6.6 _こんにちは、pks
Hello packets are created and sent with destination address of AllSPFRouters. Default transition to idle state.
こんにちは、パケットはそうです。AllSPFRoutersの送付先アドレスと共に作成して、送ります。 状態を空費するデフォルト変遷。
6.7 mospfspfcalc
6.7 mospfspfcalc
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_ノードへのこの州のトランジット。
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の最も低いPath木の情報を使用することで計算されます。
Pullen, et. al. Informational [Page 24] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[24ページ]のRFC2490IPマルチキャスト
6.8 ospfspfcalc
6.8 ospfspfcalc
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: この機能は、Routerのリンク州の広告を調べることによって、候補リストを初期化します。 この広告における各リンクに関しては、リンクのもう一方の端がルータかトランジットネットワークであり、それが最短パス木に既にないなら、これらの頭頂の間の距離について計算してください。 このリンクのもう一方の端が候補リストに既にないか、または計算された距離がこの他の終わりの弁護に出廷する値より少ないなら、候補リストへのリンクのもう一方の端を加えてください。
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: ルータが概要がリンクするArea Border Routerであるなら、受信したのは調べられます。 この概要LSAの広告を出すArea境界ルータへのルートは経路指定テーブルで調べられます。 1つを見つけるなら、概要LSAで指定されたネットワークにルートを追加することによって、経路指定テーブルアップデートをします、そして、このルートへの費用はその境界ルータからこのネットワークに達するようにこれと費用の広告を出す領域境界ルータへの費用の合計です。
e. RoutingTableCalc: This function updates the routing table by examining the shortest path tree data structure.
e。 RoutingTableCalc: この機能は、最短パスツリーデータ構造を調べることによって、経路指定テーブルをアップデートします。
6.9 upstr_node
6.9upstr_ノード
This state does not do anything in the present model. It transitions to DABRA state.
この州は現在のモデルの何もしません。 それはDABRA状態に移行します。
6.10 DABRA
6.10 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.
ルータがArea Border Routerであり、地域がソース部門であるなら、DABRAメッセージは構成されます、そして、すべての川下の領域に発信してください。 状態を空費するデフォルト変遷。
Pullen, et. al. Informational [Page 25] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[25ページ]のRFC2490IPマルチキャスト
7. DVMRP Model
7. DVMRPモデル
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の過程はRoutersに存在するだけです。 図11はDVMRPの過程の州を示しています。
7.1 Init
7.1 イニット
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.
変数、経路指定テーブル、および推進がテーブルの上に置くすべてを初期化してください、そして、シミュレーション・パラメータをロードしてください。 それはすべての初期化処理を終了した後のIdle状態へのトランジットがそうするでしょう。
7.2 Idle
7.2は怠けます。
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.
シミュレーションはそれに従って、Idle州とトランジットにおける次の予定されている出来事か離れて呼び出された出来事を状態に待っています。 DVMRPモデルでは、Idle州はProbe_Send、Report_Send、Prune_Send、Graft_Send、Arr_Pkt、Route_Calc、およびTimer州に変遷を持っています。
[Figure 11. DVMRP process on routers]
[ルータの図11DVMRPの過程]
7.3 Probe_Send State
7.3徹底的調査_は状態を送ります。
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ルータに知らせるために定期的にメッセージをProbeに送ります。 DVMRPルータは、Probeメッセージにすべての知られている隣人のアドレスを記載して、All- DVMRP-ルータアドレスにそれを送ります。 ルータは未知の隣人から来るどんなメッセージも処理しないでしょう。
7.4 Report_Send
7.4レポート_は発信します。
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ルータのためにReportを送るのを避けるために、2つのReportメッセージの間隔は平均した60秒で一様に分配されます。 ルータは、ソースルータのアドレス、すべてのソースにおけるReportメッセージへのルータのアドレスの、そして、メートル法の上流を記載して、All-DVMRP-ルータアドレスにそれを送ります。
7.5 Prune_Send
7.5プルーンの_は発信します。
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,
すなわち、まだグループに何かグループのメンバーがいれば、ルータは、IGMPからグループ番号を得て、見つけるためにIP Multicast会員資格テーブルをチェックします。 ルータが、最後のホストが辞職したことを決定するなら、それは、そのグループのためのすべてのソースの場所を見つけるように全体の推進テーブルを通ります。 ルータはPruneメッセージを送ります。
Pullen, et. al. Informational [Page 26] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[26ページ]のRFC2490IPマルチキャスト
containing source address, group address and prune lifetime, separately for each (source, group) pair and records the row as pruned in the forwarding table.
ソースアドレスを含んでいて、グループは、それぞれの(ソースは分類してください)組のために別々に生涯を記述して、剪定して、推進テーブルで剪定されるように列を記録します。
7.6 Graft_Send
7.6 汚職_は発信します。
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メッセージを送るでしょう。 ルータ、また、各Graftのためのセットアップaタイマは、承認を待ちながら、通信します。
7.7 Arr_Pkt
7.7 Arr_Pkt
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。 メッセージを調べてください: ルータはProbeメッセージ、アップデートで隣人のリストをチェックします。それは隣人の有用性を示すそれらの状態です。
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。 メッセージを報告してください: レポートメッセージを交換することに基づいて、ルータは各ソースに根づいているMulticast配送木を建てることができます。 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。 メッセージを剪定してください: ルータがソースアドレスを抜粋して、グループは、生涯を記述して、剪定して、マークは(ソースは分類してください)組の依存する川下のリストで剪定される入って来るインタフェースです。 すべての川下のインタフェースが剪定されたなら、ルータはプルーンのメッセージを上流に送るでしょう。
Pullen, et. al. Informational [Page 27] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[27ページ]のRFC2490IPマルチキャスト
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。 Acknowledgeメッセージを接ぎ木してください: ルータはソースとグループアドレスを抜粋して、推進テーブルで(ソースは分類してください)組の汚職メッセージタイマをきれいにしてください。
7.8 Route_Calc
7.8ルート_電卓
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がいったんパケットを受けると、それは、リモート中断をDVMRPに発火させて、パケットのために外向的なインタフェースを用意するようにDVMRPに頼むでしょう。 DVMRPの過程は、グループのメンバーがMulticast配送木の上にいるブランチについて決めるためにIPからパケットのソースアドレスとグループアドレスを得て、推進テーブルで(ソースは分類してください)組をチェックします。 この知識に基づいてIPのGroup Membership Tableをアップデートするでしょう。
7.9 Timer
7.9 タイマ
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.
この状態は毎秒に一度動かされます。 それは推進テーブルをチェックします、Graftメッセージ承認タイマが満期であるならルータはGraftメッセージを上流に再送するでしょう。 プルーンの州の生涯タイマが満期であるなら、ルータは、川下のルータが再びパケットをグループに受けることができるように、このインタフェースを接ぎ木するでしょう。 また、ルータは、(ソースは分類してください)組が上流のルータによって剪定されるかどうかチェックします、そうだとすれば、それは汚職メッセージを上流のインタフェースに送るでしょう。
8. Simulation performance
8. シミュレーション性能
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ネットワークのシミュレーションはプロトコルの良いScalabilityを示しました。 私たちが使用した走行プラットホームは、512MBの主記憶装置があるSGI Octane駅とMIPS R10000 CPU(Rev2.7)です。 ここに、私たちは多量栄養素に伴うそれぞれのモデルの本当の実行時間とホストで発生する流れのためのパケット相互到着時間を記載します。
Pullen, et. al. Informational [Page 28] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[28ページ]のRFC2490IPマルチキャスト
Simulated Debug Model Intermediate Model Large Model
time 11 Routers 42 routers 86 routers
12 Hosts 48 hosts 96 hosts
11Routers42のシミュレートされたDebug Model Intermediate Model Large Model時間ルータ86ルータ12Hosts48は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.01s0.02 0.02のベストエフォート型データベストエフォート型データベストエフォート型データ0.01s0.025 0.025
100 s 3 hours 14 hours 30 hours 200 s 7 hours 30 hours - - -
100秒間3時間14時間30時間200秒間7時間30時間--、--、-
9. Future work
9. 今後の活動
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できるシステムの働きを予測するために有益な手段になると信じています。
10. Security Considerations
10. セキュリティ問題
This RFC raises no security considerations.
このRFCはセキュリティ問題を全く提起しません。
11. References
11. 参照
[1] Deering, S., "Host Requirements for IP Multicasting", STD 5,
RFC 1112, August 1989.
[1] デアリング、S.、「IPマルチキャスティングのためのホスト要件」、STD5、RFC1112、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] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[3] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
[3]Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[4] MIL3 Inc., "OPNET Modeler Tutorial Version 3", Washington, DC,
1997
[4] MIL3Inc.、「OPNETモデラー家庭教師のバージョン3インチ、ワシントン(DC)1997」
[5] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[5]Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
[6] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work
in Progress.
[6] T.、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」というPusateriは進行中で働いています。
Pullen, et. al. Informational [Page 29] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[29ページ]のRFC2490IPマルチキャスト
Authors' Addresses
作者のアドレス
J. Mark Pullen C3I Center/Computer Science Mail Stop 4A5 George Mason University Fairfax, VA 22032
J.マークピューレンC3Iセンター/コンピュータサイエンスMail Stop4A5ジョージ・メイスン・大学のフェアファクス、ヴァージニア 22032
EMail: mpullen@gmu.edu
メール: mpullen@gmu.edu
Ravi Malghan 3141 Fairview Park Drive, Suite 700 Falls Church VA 22042
ラービーMalghan3141Fairviewはドライブを駐車して、スイート700の滝がヴァージニア 22042人を教会に案内します。
EMail: rmalghan@bacon.gmu.edu
メール: rmalghan@bacon.gmu.edu
Lava K. Lavu Bay Networks 600 Technology Park Dr. Billerica, MA 01821
ビルリカ博士、溶岩K.Lavuベイネットワークス600技術Park MA 01821
EMail: llavu@bacon.gmu.edu
メール: llavu@bacon.gmu.edu
Gang Duan Oracle Co. Redwood Shores, CA 94065
ギャングDuanオラクル社のアカスギ岸、カリフォルニア 94065
EMail: gduan@us.oracle.com
メール: gduan@us.oracle.com
Jiemei Ma Newbridge Networks Inc. 593 Herndon Parkway Herndon, VA 20170
JiemeiマニューブリッジネットワークスInc.593ハーンドンParkwayハーンドン、ヴァージニア 20170
EMail: jma@newbridge.com
メール: jma@newbridge.com
Hoon Nah C3I Center Mail Stop 4B5 George Mason University Fairfax, VA 22030
Hoon Nah C3IセンターのMail Stop4B5ジョージ・メイスン・大学のフェアファクス、ヴァージニア 22030
EMail: hnah@bacon.gmu.edu
メール: hnah@bacon.gmu.edu
Pullen, et. al. Informational [Page 30] RFC 2490 IP Multicast with RSVP January 1999
etピューレン、アル。 RSVP1999年1月がある情報[30ページ]のRFC2490IPマルチキャスト
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Pullen, et. al. Informational [Page 31]
etピューレン、アル。 情報[31ページ]
一覧
スポンサーリンク
