RFC1585 日本語訳
1585 MOSPF: Analysis and Experience. J. Moy. March 1994. (Format: TXT=29754 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Moy Request for Comments: 1585 Proteon, Inc. Category: Informational March 1994
Moyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1585年のProteon Inc.カテゴリ: 情報の1994年3月
MOSPF: Analysis and Experience
MOSPF: 分析と経験
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering Task Force internet routing protocol standardization criteria" ([RFC 1264]).
このメモはMOSPFプロトコルがどう「インターネット・エンジニアリング・タスク・フォースインターネットルーティング・プロトコル標準化評価基準」([RFC1264])によってインターネットルーティング・プロトコルに課された要件を満たすかを記録します。
Please send comments to mospf@gated.cornell.edu.
コメントを mospf@gated.cornell.edu に送ってください。
1. Summary of MOSPF features and algorithms
1. MOSPFの特徴とアルゴリズムの概要
MOSPF is an enhancement of OSPF V2, enabling the routing of IP multicast datagrams. OSPF is a link-state (unicast) routing protocol, providing a database describing the Autonomous System's topology. IP multicast is an extension of LAN multicasting to a TCP/IP Internet. IP Multicast permits an IP host to send a single datagram (called an IP multicast datagram) that will be delivered to multiple destinations. IP multicast datagrams are identified as those packets whose destinations are class D IP addresses (i.e., addresses whose first byte lies in the range 224-239 inclusive). Each class D address defines a multicast group.
MOSPFはOSPF V2の増進です、IPマルチキャストデータグラムのルーティングを可能にして。OSPFはリンク州の(ユニキャスト)ルーティング・プロトコルです、Autonomous Systemのトポロジーについて説明するデータベースを提供して。 IPマルチキャストはTCP/IPインターネットへのLANマルチキャスティングの拡大です。 IP Multicastは、IPホストが複数の送付先に届けられる単一のデータグラム(IPマルチキャストデータグラムと呼ばれる)を送るのを可能にします。 IPマルチキャストデータグラムは目的地がクラスD IPアドレス(すなわち、最初のバイトが範囲に224-239 包括的にあるアドレス)であるそれらのパケットとして特定されます。 それぞれのクラスDアドレスはマルチキャストグループを定義します。
The extensions required of an IP host to participate in IP multicasting are specified in "Host extensions for IP multicasting" ([RFC 1112]). That document defines a protocol, the Internet Group Management Protocol (IGMP), that enables hosts to dynamically join and leave multicast groups.
IPマルチキャスティングに参加するのにIPホストに必要である拡大は「IPマルチキャスティングのためのホスト拡大」([RFC1112])で指定されます。 そのドキュメントはプロトコル、ホストがダイナミックにマルチキャストグループに加わって、出るのを可能にするインターネットGroup Managementプロトコル(IGMP)を定義します。
MOSPF routers use the IGMP protocol to monitor multicast group membership on local LANs through the sending of IGMP Host Membership Queries and the reception of IGMP Host Membership Reports. A MOSPF router then distributes this group location information throughout the routing domain by flooding a new type of OSPF link state advertisement, the group-membership-LSA (type 6). This in turn enables the MOSPF routers to most efficiently forward a multicast
MOSPFルータは、地方のLANでIGMP Host Membership Queriesの発信とIGMP Host Membership Reportsのレセプションでマルチキャストグループ会員資格をモニターするのにIGMPプロトコルを使用します。 そして、新しいタイプのOSPFリンク州の広告、会員資格LSAを分類しているのがあふれさせることによって、MOSPFルータはこのグループ位置情報を経路ドメインに分配します(6をタイプしてください)。 これは、MOSPFルータが最も効率的にマルチキャストを進めるのを順番に可能にします。
Moy [Page 1] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[1ページ]RFC1585MOSPF: 1994年の分析と経験行進
datagram to its multiple destinations: each router calculates the path of the multicast datagram as a shortest-path tree whose root is the datagram source, and whose terminal branches are LANs containing group members.
複数の目的地へのデータグラム: 各ルータは根がデータグラムソースであり、終枝がグループのメンバーを含むLANである最短パス木としてマルチキャストデータグラムの経路について計算します。
A separate tree is built for each [source network, multicast destination] combination. To ease the computational demand on the routers, these trees are built "on demand", i.e., the first time a datagram having a particular combination of source network and multicast destination is received. The results of these "on demand" tree calculations are then cached for later use by subsequent matching datagrams.
別々の木はそれぞれの[ソースネットワーク、マルチキャストの目的地]組み合わせのために建てられます。 ルータでコンピュータの要求を緩和するために、「要求」(すなわち、1ソースネットワークとマルチキャストの目的地の特定の組み合わせがあるデータグラムが受け取られている回目)はこれらの木に建てられます。 そして、これらの「オンデマンド」の木の計算の結果は後の使用のためにその後の合っているデータグラムによってキャッシュされます。
MOSPF is meant to be used internal to a single Autonomous System. When supporting IP multicast over the entire Internet, MOSPF would have to be used in concert with an inter-AS multicast routing protocol (something like DVMRP would work).
MOSPFは独身のAutonomous Systemに内部で使用されることになっています。 全体のインターネットにわたってIPマルチキャストを支持するとき、MOSPFは相互ASマルチキャストルーティング・プロトコルと協力して使用されなければならないでしょう(DVMRPが働いているように)。
The MOSPF protocol is based on the work of Steve Deering in [Deering]. The MOSPF specification is documented in [MOSPF].
MOSPFプロトコルは[デアリング]でのスティーブ・デアリングの仕事に基づいています。 MOSPF仕様は[MOSPF]に記録されます。
1.1. Characteristics of the multicast datagram's path
1.1. マルチキャストデータグラムの経路の特性
As a multicast datagram is forwarded along its shortest-path tree, the datagram is delivered to each member of the destination multicast group. In MOSPF, the forwarding of the multicast datagram has the following properties:
最短パス木に沿ってマルチキャストデータグラムを進めるとき、目的地マルチキャストグループの各メンバーにデータグラムを届けます。 MOSPFでは、マルチキャストデータグラムの推進は以下の特性を持っています:
o The path taken by a multicast datagram depends both on the
datagram's source and its multicast destination. Called
source/destination routing, this is in contrast to most unicast
datagram forwarding algorithms (like OSPF) that route
based solely on destination.
o マルチキャストデータグラムによって取られた経路はデータグラムのソースとそのマルチキャストの目的地に頼っています。 呼ばれたソース/目的地ルーティング、これはルートが唯一目的地に基礎づけたほとんどのユニキャストデータグラム推進アルゴリズム(OSPFのような)と対照的になっています。
o The path taken between the datagram's source and any particular
destination group member is the least cost path available. Cost
is expressed in terms of the OSPF link-state metric.
o データグラムのソースとどんな特定の目的地グループのメンバーの間にも取られた経路は利用可能な最小費用経路です。 費用はOSPFリンク状態でメートル法で言い表されます。
o MOSPF takes advantage of any commonality of least cost paths
to destination group members. However, when members of the
multicast group are spread out over multiple networks, the
multicast datagram must at times be replicated. This replication
is performed as few times as possible (at the tree branches),
taking maximum advantage of common path segments.
o MOSPFは最小費用経路のどんな共通点も目的地グループのメンバーに利用します。 しかしながら、マルチキャストグループのメンバーが時には複数のネットワークの上に広げられるとき、マルチキャストデータグラムを模写しなければなりません。 共通路セグメントの最大の利点を活用して、この模写は可能な同じくらい数回(木の枝の)として実行されます。
o For a given multicast datagram, all routers calculate an
identical shortest-path tree. This is possible since the
shortest-path tree is rooted at the datagram source, instead
o 与えられたマルチキャストデータグラムに関しては、すべてのルータが同じ最短パス木について計算します。 最短パス木が根づいているので、これは代わりにデータグラムソースで可能です。
Moy [Page 2] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[2ページ]RFC1585MOSPF: 1994年の分析と経験行進
of being rooted at the calculating router (as is done in the
unicast case). Tie-breakers have been defined to ensure
that, when several equal-cost paths exist, all routers agree
on which single path to use. As a result, there is a single
path between the datagram's source and any particular
destination group member. This means that, unlike OSPF's
treatment of regular (unicast) IP data traffic, there is no
provision for equal-cost multipath.
計算のルータ(ユニキャスト場合でするように)に根づくのについて。 タイブレークは、いくつかの等しい費用経路が存在しているとすべてのルータが、どのただ一つの経路を使用したらよいかに同意するのを保証するために定義されました。 その結果、データグラムのソースとどんな特定の目的地グループのメンバーの間にはも、ただ一つの経路があります。 これは、等価コストマルチパスへの支給が全くOSPFの定期的な(ユニキャスト)IPデータ通信量の処理と異なっていないことを意味します。
o While MOSPF optimizes the path to any given group member, it
does not necessarily optimize the use of the internetwork as
a whole. To do so, instead of calculating source-based
shortest-path trees, something similar to a minimal spanning
tree (containing only the group members) would need to be
calculated. This type of minimal spanning tree is called a
Steiner tree in the literature. For a comparison of
shortest-path tree routing to routing using Steiner trees,
see [Deering2] and [Bharath-Kumar].
o MOSPFがどんな与えられたグループのメンバーにも経路を最適化している間、それは必ず全体でインターネットワークの使用を最適化するというわけではありません。 計算のソースベースの最短パス木の代わりにそう最小スパニング樹(グループのメンバーだけを含む)と何か同様のことをするのは、計算される必要があるでしょう。 このタイプの最小スパニング樹は文学にスタイナー木と呼ばれます。 スタイナー木を使用するルーティングへの最短パス木のルーティングの比較に関しては、[Deering2]と[Bharath-クマー]を見てください。
o When forwarding a multicast datagram, MOSPF conforms to the
link-layer encapsulation standards for IP multicast
datagrams as specified in "Host extensions for IP multicasting"
([RFC 1112]), "Transmission of IP datagrams over the
SMDS Service" ([RFC 1209]) and "Transmission of IP and ARP
over FDDI Networks" ([RFC 1390]). In particular, for ethernet
and FDDI the explicit mapping between IP multicast
addresses and data-link multicast addresses is used.
o マルチキャストデータグラムを進めて、MOSPFが「IPマルチキャスティングのためのホスト拡大」([RFC1112])で指定されるようにIPマルチキャストデータグラムのリンクレイヤカプセル化規格に従うとき、「SMDS Serviceの上のIPデータグラムのトランスミッション」([RFC1209])と「FDDIネットワークの上のIPとARPのトランスミッション。」です([RFC1390])。 イーサネットとFDDIに関して、IPマルチキャストアドレスとデータ・リンクマルチキャストアドレスの間の明白なマッピングは特に、使用されています。
1.2. Miscellaneous features
1.2. 種々雑多な特徴
This section lists, in no particular order, the other miscellaneous features that the MOSPF protocol supports:
このセクションはどんな特定のオーダーにもMOSPFプロトコルが支持する他の種々雑多な特徴をリストアップしません:
o MOSPF routers can be mixed within an Autonomous System (and
even within a single OSPF area) with non-multicast OSPF
routers. When this is done, all routers will interoperate in
the routing of unicasts. Unicast routing will not be
affected by this mixing; all unicast paths will be the same
as before the introduction of multicast. This mixing of
multicast and non-multicast routers enables phased
introduction of a multicast capability into an internetwork.
However, it should be noted that some configurations of MOSPF
and non-MOSPF routers may produce unexpected failures in
multicast routing (see Section 6.1 of [MOSPF]).
o MOSPFルータは、非マルチキャストOSPFルータにAutonomous Systemの中で混ぜられるのと(ただ一つのOSPF領域の中で同等。)であることができます。 これが完了していると、すべてのルータがユニキャストのルーティングで共同利用するでしょう。 ユニキャストルーティングはこの混合で影響を受けないでしょう。 すべてのユニキャスト経路がマルチキャストの導入の前と同じになるでしょう。 マルチキャストと非マルチキャストルータのこの混合はマルチキャスト能力の段階的な導入をインターネットワークに可能にします。 しかしながら、MOSPFと非MOSPFルータのいくつかの構成がマルチキャストルーティングで予期していなかった失敗を生産するかもしれないことに([MOSPF]のセクション6.1を見てください)注意されるべきです。
o MOSPF does not include the ability to tunnel multicast
datagrams through non-multicast routers. A tunneling capability
has proved valuable when used by the DVMRP protocol in the
o MOSPFは非マルチキャストルータを通してトンネルマルチキャストデータグラムに能力を含めません。 トンネリング能力はDVMRPプロトコルによって使用されると貴重であると判明しました。
Moy [Page 3] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[3ページ]RFC1585MOSPF: 1994年の分析と経験行進
MBONE. However, it is assumed that, since MOSPF is an intra-AS
protocol, multicast can be turned on in enough of the Autonomous
System's routers to achieve the required connectivity without
resorting to tunneling. The more centralized control that exists
in most Autonomous Systems, when compared to the Internet as a
whole, should make this possible.
MBONE。 しかしながら、MOSPFがイントラ-ASプロトコルであるのでAutonomous Systemのルータがトンネリングに訴えないで必要な接続性を実現する十分でマルチキャストをつけることができると思われます。 全体でインターネットと比べるとほとんどのAutonomous Systemsに存在するより多くの集中制御で、これは可能になるべきです。
o In addition to calculating a separate datagram path for each
[source network, multicast destination] combination, MOSPF
can also vary the path based on IP Type of Service (TOS). As
with OSPF unicast routing, TOS-based multicast routing is
optional, and routers supporting it can be freely mixed with
those that don't.
o また、それぞれの[ソースネットワーク、マルチキャストの目的地]組み合わせのために別々のデータグラム経路について計算することに加えて、MOSPFはService(TOS)のIP Typeに基づく経路を変えることができます。 OSPFユニキャストルーティングのように、TOSベースのマルチキャストルーティングは任意です、そして、自由にそれを支持するルータをそうしないそれらに混ぜることができます。
o MOSPF supports all network types that are supported by the base
OSPF protocol: broadcast networks, point-to-points networks and
non-broadcast multi-access (NBMA) networks. Note however that
IGMP is not defined on NBMA networks, so while these networks
can support the forwarding of multicast datagrams, they cannot
support directly connected group members.
o MOSPFはベースOSPFプロトコルによって支持されるすべてのネットワークタイプを支持します: ネットワーク、ポイントツーポイントネットワーク、および非放送マルチアクセス(NBMA)ネットワークを放送してください。 しかしながら、これらのネットワークがマルチキャストデータグラムの推進を支持できる間、直接接続されたグループのメンバーを支持できないようにIGMPがNBMAネットワークで定義されないことに注意してください。
o MOSPF supports all Autonomous System configurations that are
supported by the base OSPF protocol. In particular, an algorithm
for forwarding multicast datagrams between OSPF areas
is included. Also, areas with configured virtual links can
be used for transit multicast traffic.
o MOSPFはベースOSPFプロトコルによって支持されるすべてのAutonomous System構成を支持します。 OSPF領域の間にマルチキャストデータグラムを送るためのアルゴリズムは特に、含まれています。 また、トランジットマルチキャスト交通に構成された仮想のリンクがある領域を使用できます。
o A way of forwarding multicast datagrams across Autonomous
System boundaries has been defined. This means that a multicast
datagram having an external source can still be forwarded
throughout the Autonomous System. Facilities also exist for
forwarding locally generated datagrams to Autonomous System exit
points, from which they can be further distributed. The
effectiveness of this support will depend upon the nature of the
inter-AS multicast routing protocol. The one assumption that
has been made is that the inter-AS multicast routing protocol
will operate in an reverse path forwarding (RPF) fashion:
namely, that multicast datagrams originating from an external
source will enter the Autonomous System at the same place that
unicast datagrams destined for that source will exit.
o Autonomous System境界の向こう側にマルチキャストデータグラムを送る方法は定義されました。 これは、Autonomous System中でまだ外部電源がいるマルチキャストデータグラムを進めることができることを意味します。 また、施設は、局所的に発生したデータグラムをAutonomous Systemエキジットポイントに送るために存在しています。(エキジットポイントからそれらをさらに分配できます)。 このサポートの有効性は相互ASマルチキャストルーティング・プロトコルの本質に依存するでしょう。 された1つの仮定は相互ASマルチキャストルーティング・プロトコルが(RPF)にファッションを送りながら逆の経路で作動するということです: すなわち、外部電源から発するマルチキャストデータグラムがユニキャストデータグラムがそのソースに運命づけたのと同じ場所でAutonomous Systemに入るのは出るでしょう。
o To deal with the fact that the external unicast and multicast
topologies will be different for some time to come, a
way to indicate that a route is available for multicast but
not unicast (or vice versa) has been defined. This for example
would allow a MOSPF system to use DVMRP as its inter-AS
multicast routing protocol, while using BGP as its inter-AS
unicast routing protocol.
o 外部のユニキャストとマルチキャストtopologiesがここしばらく異なるという事実に対処するために、ルートがユニキャストではなく、マルチキャスト(逆もまた同様である)に利用可能であることを示す方法は定義されました。 これで、例えば、MOSPFシステムは相互ASユニキャストルーティング・プロトコルとしてBGPを使用している間、相互ASマルチキャストルーティング・プロトコルとしてDVMRPを使用できるでしょう。
Moy [Page 4] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[4ページ]RFC1585MOSPF: 1994年の分析と経験行進
o For those physical networks that have been assigned multiple
IP network/subnet numbers, multicast routing can be disabled
on all but one OSPF interface to the physical network. This
avoids unwanted replication of multicast datagrams.
o 複数のIPネットワーク/サブネット番号が配属されたそれらの物理ネットワークにおいて、1つのOSPFインタフェース以外のすべてでマルチキャストルーティングを物理ネットワークに無効にすることができます。 これはマルチキャストデータグラムの求められていない模写を避けます。
o For those networks residing on Autonomous System boundaries,
which may be running multiple multicast routing protocols
(or multiple copies of the same multicast routing protocol),
MOSPF can be configured to encapsulate multicast datagrams
with unicast (rather than multicast) link-level destinations.
This also avoids unwanted replication of multicast datagrams.
o Autonomous System境界にあるそれらのネットワークにおいてユニキャスト(マルチキャストよりむしろ)リンク・レベルの目的地があるマルチキャストデータグラムを要約するためにMOSPFを構成できます。境界は、複数のマルチキャストルーティング・プロトコル(または、複本の同じマルチキャストルーティング・プロトコル)を走らせているかもしれません。 また、これはマルチキャストデータグラムの求められていない模写を避けます。
o MOSPF provides an optimization for IP multicast's "expanding
ring search" (sometimes called "TTL scoping") procedure. In
an expanding ring search, an application finds the nearest
server by sending out successive multicasts, each with a
larger TTL. The first responding server will then be the
closest (in terms of hops, but not necessarily in terms of
the OSPF metric). MOSPF minimizes the network bandwidth
consumed by an expanding ring search by refusing to forward
multicast datagrams whose TTL is too small to ever reach a
group member.
o MOSPFはIPマルチキャストの「拡張リング検索」(時々「TTLの見ること」と呼ばれる)手順に最適化を提供します。 拡張リング検索では、アプリケーションは連続したマルチキャストを出すことによって、最も近いサーバを見つけます、それぞれより大きいTTLと共に。 最初の応じるサーバがその時、最も近く(ホップにもかかわらず、必ずOSPFにおけるメートル法であるというわけではないのに関して)にあるでしょう。 MOSPFはTTLがグループのメンバーに届くことができないくらい小さいマルチキャストデータグラムを進めるのを拒否することによって拡張リング検索で消費されたネットワーク回線容量を最小にします。
2. Security architecture
2. セキュリティー体系
All MOSPF protocol packet exchanges (excluding IGMP) are specified by the base OSPF protocol, and as such are authenticated. For a discussion of OSPF's authentication mechanism, see Appendix D of [OSPF].
すべてのMOSPFプロトコルパケット交換(IGMPを除いた)が、ベースOSPFプロトコルによって指定されて、そういうものとして認証されます。 OSPFの認証機構の議論に関しては、[OSPF]のAppendix Dを見てください。
3. MIB support
3. MIBサポート
Management support for MOSPF has been added to the base OSPF V2 MIB [OSPF MIB]. These additions consist of the ability to read and write the configuration parameters specified in Section B of [MOSPF], together with the ability to dump the new group-membership-LSAs.
MOSPFの管理サポートはベースOSPF V2 MIB[OSPF MIB]に加えられます。 これらの追加は[MOSPF]のセクションBで指定された設定パラメータを読み書きする能力から成ります、会員資格LSAsを分類していた状態で新しさをどさっと落とす能力と共に。
4. Implementations
4. 実現
There is currently one MOSPF implementation, written by Proteon, Inc. It was released for general use in April 1992. It is a full MOSPF implementation, with the exception of TOS-based multicast routing. It also does not contain an inter-AS multicast routing protocol.
現在、Proteon Inc.によって書かれた1つのMOSPF実現があります。Itは1992年4月の一般的使用のためにリリースされました。 それはTOSベースのマルチキャストルーティング以外の完全なMOSPF実現です。 また、それは相互ASマルチキャストルーティング・プロトコルを含んでいません。
The multicast applications included with the Proteon MOSPF implementation include: a multicast pinger, console commands so that the router itself can join and leave multicast groups (and so respond to multicast pings), and the ability to send SNMP traps to a
Proteon MOSPF実現で含まれていたマルチキャストアプリケーションは: マルチキャストピンガ、コンソールはそのようにルータ自体がマルチキャストグループに加わって、出ることができると命令します、そして、(そして、マルチキャストピングにそう応じます)SNMPを送る能力はaとして捕らえられます。
Moy [Page 5] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[5ページ]RFC1585MOSPF: 1994年の分析と経験行進
multicast address. Proteon is also using IP multicast to support the tunneling of other protocols over IP. For example, source route bridging is tunneled over a MOSPF domain, using one IP multicast address for explorer frames and mapping the segment/bridge found in a specifically-routed frame's RIF field to other IP multicast addresses. This last application has proved popular, since it provides a lightweight transport that is resistant to reordering.
マルチキャストアドレス。 また、Proteonは、IPの上で他のプロトコルのトンネリングを支持するのにIPマルチキャストを使用しています。 例えば、送信元経路の橋を架けることはMOSPFドメインの上でトンネルを堀られます、他のIPマルチキャストアドレスに探検家フレームに1つのIPマルチキャストアドレスを使用して、明確に発送されたフレームのRIF野原で発見されるセグメント/橋を写像して。 再命令に抵抗力がある軽量の輸送を提供するので、この最後のアプリケーションはポピュラーであると判明しました。
The Proteon MOSPF implementation is currently running in approximately a dozen sites, each site consisting of 10-20 routers.
Proteon MOSPF実現は現在、およそ1ダースのサイト、10-20 ルータから成る各サイトへ駆け込んでいます。
Table 1 gives a comparison between the code size of Proteon's base OSPF implementation and its MOSPF implementation. Two dimensions of
テーブル1はProteonのベースOSPF実現のコードサイズとそのMOSPF実現の間に比較を与えます。 二次元
lines of C bytes of 68020 object code
___________________________________________________
OSPF base 11,693 63,160
MOSPF 15,247 81,956
Cバイトの68020オブジェクトコードの線___________________________________________________ OSPFベース11,693 63,160MOSPF15,247 81,956
Table 1: Comparison of OSPF and MOSPF code sizes
テーブル1: OSPFとMOSPFコードサイズの比較
size are indicated: lines of C (comments and blanks included), and bytes of 68020 object code. In both cases, the multicast extensions to OSPF have engendered a 30% size increase.
サイズは示されます: C(コメントと空白を含んでいる)の線、およびバイトの68020オブジェクトコード。 どちらの場合も、OSPFへのマルチキャスト拡大は30%のサイズ増加を生み出しました。
Note that in these sizes, the code used to configure and monitor the implementation has been included. Also, in the MOSPF code size figure, the IGMP implementation has been included.
これらのサイズでは、実現を構成して、モニターするのに使用されるコードが含まれていることに注意してください。 また、MOSPFコードサイズ数値では、IGMP実現は含まれています。
5. Testing
5. テスト
Figure 1 shows the topology that was used for the initial debugging of Proteon's MOSPF implementation. It consists of seven MOSPF routers, interconnected by ethernets, token rings, FDDIs and serial lines. The applications used to test the routing were multicast ping and the sending of traps to a multicast address (the box labeled "NAZ" was a network analyzer that was occasionally sending IGMP Host Membership Reports and then continuously receiving multicast SNMP traps). The "vat" application was also used on workstations (without running the DVMRP "mrouted" daemon; see "Distance Vector Multicast Routing Protocol", [RFC 1075]) which were multicasting packet voice across the MOSPF domain.
図1はProteonのMOSPF実現の初期のデバッグに使用されたトポロジーを示しています。 それはイーサネット、トークンリング、FDDIs、およびシリアル・ラインによってインタコネクトされた7つのMOSPFルータから成ります。 ルーティングをテストするのに使用されるアプリケーションは、マルチキャストアドレスへのマルチキャストピングと罠の送付("NAZ"とラベルされた箱は時折ホスト会員資格レポートをIGMPに送って、次に絶え間なくマルチキャストSNMP罠を受けていたネットワークアナライザであった)でした。 また、「大タンク」アプリケーションはMOSPFドメイン中のマルチキャスティングパケット声であったワークステーション(走らないで、DVMRPはデーモンを「mroutedした」; 「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」を見てください、[RFC1075])の上で使用されました。
Moy [Page 6] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[6ページ]RFC1585MOSPF: 1994年の分析と経験行進
The MOSPF features tested in this setup were:
このセットアップでテストされたMOSPFの特徴は以下の通りでした。
o Re-routing in response to topology changes.
o トポロジーに対応してコースを変更するのは変化します。
o Path verification after altering costs.
o コストを変更した後の経路検証。
o Routing multicast datagrams between areas.
o マルチキャストデータグラムを領域の間に発送します。
o Routing multicast datagrams to and from external addresses.
o 外部アドレスと外部アドレスからマルチキャストデータグラムを発送します。
o The various tiebreakers employed when constructing datagram
shortest-path trees.
o データグラム最短パス木を組み立てるとき使われた様々なタイブレーク。
o MOSPF over non-broadcast multi-access networks.
o 非放送マルチアクセスネットワークの上のMOSPF。
o Interoperability of MOSPF and non-multicast OSPF routers.
o MOSPFと非マルチキャストOSPFルータの相互運用性。
+---+
+-------------------------------|RT1|
| +---+
| +---------+ |
| | |
| +---+ +---+ +---+ |
| |RT5|---------|RT2| |NAZ| |
| +---+ +----+---+ +---+ |
| | | | |
| | +------------------------+
| | | +
| | | |
| | | | +---+
| +------------+ + | |--|RT7|
| | | | | +---+
| +---+ | +---+ |
| |RT4|--------|-----------|RT3|----|
| +---+ | +---+ |
| | |
| + + |
| | +---+ |
+---------------|-----------|RT6|------------|
| +---+ |
+ +
+---+ +-------------------------------|RT1| | +---+ | +---------+ | | | | | +---+ +---+ +---+ | | |RT5|---------|RT2| |NAZ| | | +---+ +----+---+ +---+ | | | | | | | | +------------------------+ | | | + | | | | | | | | +---+ | +------------+ + | |--|RT7| | | | | | +---+ | +---+ | +---+ | | |RT4|--------|-----------|RT3|----| | +---+ | +---+ | | | | | + + | | | +---+ | +---------------|-----------|RT6|------------| | +---+ | + +
Figure 1: Initial MOSPF test setup
図1: 初期のMOSPFテストセットアップ
Moy [Page 7] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[7ページ]RFC1585MOSPF: 1994年の分析と経験行進
Due to the commercial tunneling applications developed by Proteon that use IP multicast, MOSPF has been deployed in a number of operational but non-Internet-connected sites. MOSPF has been also deployed in some Internet-connected sites (e.g., OARnet) for testing purposes. The desire of these sites is to use MOSPF to attach to the "mbone". However, an implementation of both MOSPF and DVMRP in the same box is needed; without this one way communication has been achieved (sort of like lecture mode in vat) by configuring multicast static routes in the MOSPF implementation. The problem is that there is no current way to inject the MOSPF source information into DVMRP.
IPマルチキャストを使用するProteonによって開発された市販のトンネリングアプリケーションのため、MOSPFは多くの操作上の、しかし、非インターネットが接続しているサイトで配備されました。 また、MOSPFはテスト目的のためにいくつかのインターネットで接続されたサイト(例えば、OARnet)で配備されました。 これらのサイトの願望は"mbone"に付くのにMOSPFを使用することです。 しかしながら、MOSPFとDVMRPの両方の実現が同じ状態で必要です。 一方通行であることのこれがなければ、コミュニケーションは、MOSPF実現でマルチキャストスタティックルートを構成することによって、達成されました(ちょっと大タンクの中の講演モードのように)。 問題はMOSPFソース情報をDVMRPに注ぐどんな現在の方法もないということです。
The MOSPF features that have not yet been tested are:
まだテストされていないMOSPFの特徴は以下の通りです。
o The interaction between MOSPF and virtual links.
o MOSPFと仮想のリンクとの相互作用。
o Interaction between MOSPF and other multicast routing protocols
(e.g., DVMRP).
o MOSPFと他のマルチキャストルーティング・プロトコル(例えば、DVMRP)との相互作用。
o TOS-based routing in MOSPF.
o MOSPFでのTOSベースのルーティング。
6. A brief analysis of MOSPF scaling
6. MOSPFスケーリングの簡潔な分析
MOSPF uses the Dijkstra algorithm to calculate the path of a multicast datagram through any given OSPF area. This calculation encompasses all the transit nodes (routers and networks) in the area; its cost scales as O(N*log(N)) where N is the number of transit nodes (same as the cost of the OSPF unicast intra-area routing calculation). This is the cost of a single path calculation; however, MOSPF calculates a separate path for each [source network, multicast destination, TOS] tuple. This is potentially a lot of Dijkstra calculations.
OSPF領域を考えて、MOSPFは、いずれもを通してマルチキャストデータグラムの経路について計算するのにダイクストラアルゴリズムを使用します。 この計算はその領域がすべてのトランジットノード(ルータとネットワーク)を包含します。 それはOとしてスケールかかりました。(Nがトランジットノード(OSPFユニキャストイントラ領域ルーティング計算の費用と同じ)の数であるN*ログ(N))。 これはただ一つの経路計算の費用です。 しかしながら、MOSPFはそれぞれの[ソースネットワーク、マルチキャストの目的地、TOS]tupleのために別々の経路について計算します。 これは潜在的に多くのダイクストラの計算です。
MOSPF proposes to deal with this calculation burden by calculating datagram paths in an "on demand" fashion. That is, the path is calculated only when receiving the first datagram in a stream. After the calculation, the results are cached for use by later matching datagrams. This on demand calculation alleviates the cost of the routing calculations in two ways: 1) It spreads the routing calculations out over time and 2) the router does fewer calculations, since it does not even calculate the paths of datagrams whose path will not even touch the router.
MOSPFは、「オンデマンド」のファッションで計算のデータグラム経路のそばでこの計算負担に対処するよう提案します。 絶え間なく最初のデータグラムを受けるときだけ、すなわち、経路は計算されます。 計算の後に、結果は、使用のために後でデータグラムを合わせることによって、キャッシュされます。このオンデマンドの計算は2つの方法でルーティング計算の費用を軽減します: 1) それは時間がたつにつれてルーティング計算を広げます、そして、ルータがそれ以来の、より少ない計算をする2は)経路がルータに触れてさえいないデータグラムの経路について計算さえしません。
Cache entries need never be timed out, although they are removed on topological changes. If an implementation chooses to limit the amount of memory consumed by the cache, probably by removing selected entries, care must be taken to ensure that cache thrashing does not occur.
位相的な変化の上でそれらを取り除きますが、外でキャッシュエントリーを決して調節してはいけません。 実現が、キャッシュと、たぶん選択されたエントリーを取り除くことによって消費されたメモリー容量を制限するのを選ぶなら、キャッシュの打つことが起こらないのを保証するために注意しなければなりません。
Moy [Page 8] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[8ページ]RFC1585MOSPF: 1994年の分析と経験行進
The effectiveness of this "on demand" calculation will need to be proven over time, as multicast usage and traffic patterns become more evident.
この「オンデマンド」の計算の有効性は、時間がたつにつれて立証される必要があるでしょう、マルチキャスト用法とトラフィック・パターンが、より明白になるとき。
As a simple example, suppose an OSPF area consists of 200 routers. Suppose each router represents a site, and each site is participating simultaneously with three other local sites (inside the area) in a video conference. This gives 200/4 = 50 groups, and 200 separate datagram trees. Assuming each datagram tree goes through every router (which probably won't be true), each router will be doing 200 Dijkstras initially (and on internal topology changes). The time to run a 200 node Dijkstra on a 10 mips processor was estimated to be 15 milliseconds in "OSPF protocol analysis" ([RFC 1245]). So if all 200 Dijkstras need to be done at once, it will take 3 seconds total on a 10 mips processor. In contrast, assuming each video stream is 64Kb/sec, the routers will constantly forward 12Mb/sec of application data (the cost of this soon dwarfing the cost of the Dijkstras).
簡単な例として、OSPF領域が200のルータから成ると仮定してください。 各ルータがサイトを表して、各サイトが同時に他の3つのローカル・サイト(領域の中の)でテレビ会議システムに参加するなら。 これは200/4 = 50のグループ、および200本の別々のデータグラム木を与えます。 それぞれのデータグラム木があらゆるルータ(たぶん本当にならない)に直面していると仮定すると、各ルータは初めは(そして内部のトポロジー変化の上で)、200Dijkstrasをするでしょう。 10mipsプロセッサの上のダイクストラが200ノードを走らせるためには、そうであった時代に、概算しているのは、「OSPFプロトコル分析」([RFC1245])で15ミリセカンドです。 それで、すべての200Dijkstrasが、すぐにする必要があると、それは10mipsプロセッサの総3秒取るでしょう。 対照的に、それぞれのビデオストリームが64KB/秒であると仮定すると、ルータは絶えず12Mb/秒のアプリケーションデータ(すぐDijkstrasの費用を小さくするこの費用)を転送するでしょう。
In this example there are also 200 group-membership-LSAs in the area; since each group membership-LSA is around 64 bytes, this adds 64*200 = 12K bytes to the OSPF link state database.
この例には、200もその領域で会員資格LSAsを分類していた状態であります。 それぞれのグループ会員資格-LSAがおよそ64バイトであるので、これは64*200 = 12KバイトをOSPFリンク州のデータベースに追加します。
Other things to keep in mind when evaluating the cost of MOSPF's routing calculation are:
MOSPFのルーティング計算の費用を評価するとき覚えておく他のことは以下の通りです。
o Assuming that the guidelines of "OSPF protocol analysis" ([RFC
1245]) are followed and areas are limited to 200 nodes, the cost
of the Dijkstra will not grow unbounded, but will instead be
capped at the Dijkstra for 200 nodes. One need then worry about
the number of Dijkstras, which is determined by the number of
[datagram source, multicast destination] combinations.
o 「OSPFプロトコル分析」([RFC1245])のガイドラインが従われていて、領域が200のノードに制限されると仮定すると、ダイクストラの費用は、限りなくなりませんが、200のノードのために代わりにダイクストラでふたをされるでしょう。 人は次に、Dijkstrasの数を心配しなければなりません、[データグラムソース、マルチキャストの目的地]組み合わせの数に従って断固としたどれ。
o A datagram whose destination has no group members in the domain
can still be forwarded through the MOSPF system. However, the
Dijkstra calculation here depends only on the [datagram source,
TOS], since the datagram will be forwarded along to "wild-card
receivers" only. Since the number of group members in a 200
router area is probably also bounded, the possibility of
unbounded calculation growth lies in the number of possible
datagram sources. (However, it should be noted that some future
multicast applications, such as distributed computing, may generate
a large number of short-lived multicast groups).
o MOSPFシステムを通してまだ、目的地にはグループのメンバーが全くそのドメインにいないデータグラムを進めることができます。 しかしながら、ここでのダイクストラの計算がよる、オンなだけ、[データグラムソース、TOS]、データグラムが送るので、ずっと「ワイルドカード受信機」だけ、に送ってください。 また、200ルータ領域のグループのメンバーの数もたぶん境界があるので、可能なデータグラムソースの数には限りない計算の成長の可能性があります。 (しかしながら、分散コンピューティングなどのいくつかの将来のマルチキャストアプリケーションが多くの短命なマルチキャストグループを作るかもしれないことに注意されるべきです。)
o By collapsing routing information before importing it into the
area/AS, the number of sources can be reduced dramatically. In
particular, if the AS relies on a default external route, most
external sources will be covered by a single Dijkstra calculation
(the one using 0.0.0.0 as the source).
o 領域/ASにそれを輸入する前にルーティング情報を潰すことによって、ソースの数は劇的に減少できます。 ASが外部経路、ほとんどの外部電源が当てにするデフォルトを当てにするなら特に、ただ一つのダイクストラの計算で覆われてください、(ものが使用される、0.0、.0、.0、ソース)
Moy [Page 9] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[9ページ]RFC1585MOSPF: 1994年の分析と経験行進
One other factor to be considered in MOSPF scaling is how often cache entries need to be recalculated, as a result of a network topology change. The rules for MOSPF cache maintenance are explained in Section 13 of [MOSPF]. Note that the further away the topology change happens from the calculating router, the fewer cache entries need to be recalculated. For example, if an external route changes, many fewer cache entries need to be purged as compared to a change in a MOSPF domain's internal link. For scaling purposes, this is exactly the desired behavior. Note that "OSPF protocol analysis" ([RFC 1245]) bears this out when it shows that changes in external routes (on the order of once a minute for the networks surveyed) are much more frequent than internal changes (between 15 and 50 minutes for the networks surveyed).
MOSPFスケーリングで考えられる他の1つの要素はキャッシュエントリーが、どれくらいの頻度で再計算される必要があるかということです、ネットワーク形態変化の結果、。 MOSPFキャッシュメンテナンスのための規則は[MOSPF]のセクション13で説明されます。 遠くでは、トポロジー変化が、より遠いというメモは計算のルータから起こって、より少ないキャッシュエントリーが、再計算される必要があります。 例えば、外部経路が変化するなら、多くの、より少ないキャッシュエントリーが、MOSPFドメインの内部のリンクの変化と比べて、掃除される必要があります。 スケーリング目的のために、これはまさに望まれた行動です。 外部経路(調査されたネットワークのための1分あたりの一度の注文での)の変化が内的変化(調査されたネットワークのための15〜50分)よりはるかに頻繁であることを示すと「OSPFプロトコル分析」([RFC1245])がこれを支持することに注意してください。
7. Known difficulties
7. 知られている困難
The following are known difficulties with the MOSPF protocol:
↓これはMOSPFプロトコルで知られている困難です:
o When a MOSPF router itself contains multicast applications, the
choice of its application datagrams' source addresses should be
made with care. Due to OSPF's representation of serial lines,
using a serial line interface address as source can lead to
excess data traffic on the serial line. In fact, using any
interface address as source can lead to excess traffic, owing to
MOSPF's decision to always multicast the packet onto the source
network as part of the forwarding process (see Section 11.3 of
[MOSPF]). However, optimal behavior can be achieved by assigning
the router an interface-independent address, and using this as
the datagram source.
o MOSPFルータ自体がマルチキャストアプリケーションを含むとき、慎重にアプリケーションデータグラムのソースアドレスの選択をするべきです。 OSPFのシリアル・ラインの表現のため、ソースとしてシリアル・ラインインターフェース・アドレスを使用するのはシリアル・ラインにおける余分なデータ通信量に通じることができます。 事実上、どんなインタフェースも使用して、推進プロセスの一部としてソースが余分なトラフィックにつながることができるMOSPFの決定によるいつもマルチキャストへのパケットをソースネットワークに扱ってください([MOSPF]のセクション11.3を見てください)。 しかしながら、インタフェースから独立しているアドレスをルータに割り当てて、データグラムソースとしてこれを使用することによって、最適の振舞いを達成できます。
This concern does not apply to regular IP hosts (i.e., those
that are not MOSPF routers).
この関心はレギュラーのIPホスト(すなわち、MOSPFルータでないそれら)に適用されません。
o It is necessary to ensure, when mixing MOSPF and non-multicast
routers on a LAN, that a MOSPF router becomes Designated Router.
Otherwise multicast datagrams will not be forwarded on the LAN,
nor will group membership be monitored on the LAN, nor will the
group-membership-LSAs be flooded over the LAN. This can be an
operational nuisance, since OSPF's Designated Router election
algorithm is designed to discourage Designated Router transitions,
rather than to guarantee that certain routers become
Designated Router. However, assigning a DR Priority of 0 to all
non-multicast routers will always guarantee that a MOSPF router
is selected as Designated Router.
o MOSPFと非マルチキャストルータをLANに混ぜるときMOSPFルータがDesignated Routerになるのを保証するのが必要です。 さもなければ、マルチキャストデータグラムはLANで進められないでしょう、そして、グループ会員資格はLANでモニターされるでしょう、または、会員資格LSAsを分類しているのがLANの上で水につからないでしょう。 これは操作上の迷惑であるかもしれません、あるルータがDesignated Routerになるのを保証するよりOSPFのDesignated Router選挙アルゴリズムがむしろDesignated Router変遷に水をさしているように設計されているので。 しかしながら、すべての非マルチキャストルータに0のDR Priorityを割り当てるのは、いつもMOSPFルータがDesignated Routerとして選定されるのを保証するでしょう。
Moy [Page 10] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[10ページ]RFC1585MOSPF: 1994年の分析と経験行進
8. Future work
8. 今後の活動
In the future, it is expected that the following work will be done on the MOSPF protocol:
将来、MOSPFプロトコルで以下の仕事をすると予想されます:
o More analysis of multicast traffic patterns needs to be done, in
order to see whether the MOSPF routing calculations will pose an
undue processing burden on multicast routers. If necessary,
further ways to ease this burden may need to be defined. One
suggestion that has been made is to revert to reverse path
forwarding when the router is unable to calculate the detailed
MOSPF forwarding cache entries.
o マルチキャストトラフィック・パターンの、より多くの分析が、する必要があります、MOSPFルーティング計算がマルチキャストルータでの過度の処理負担を引き起こすかどうか確認するために。 必要なら、この負担をゆるめるさらなる方法は、定義される必要があるかもしれません。 された1つの提案はルータが詳細なMOSPFについて計算できないとき、キャッシュエントリーを進めながら経路推進を逆にするために戻ることです。
o Experience needs to be gained with the interactions between multiple
multicast routing algorithms (e.g., MOSPF and DVMRP).
o 経験は、複数のマルチキャストルーティング・アルゴリズム(例えば、MOSPFとDVMRP)の間には、相互作用がある状態で獲得される必要があります。
o Additional MIB support for the retrieval of forwarding cache
entries, along the lines of the "IP forwarding table MIB" ([RFC
1354]), would be useful.
o 推進キャッシュエントリーの検索の追加MIBサポートは「IP推進テーブルMIB」([RFC1354])の系列に沿って役に立つでしょう。
Moy [Page 11] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[11ページ]RFC1585MOSPF: 1994年の分析と経験行進
9. References
9. 参照
[Bharath-Kumar] Bharath-Kumar, K., and J. Jaffe, "Routing to
multiple destinations in Computer Networks", IEEE
Transactions on Communications, COM-31[3], March
1983.
Communications、COM-31[3]、1983年3月の[Bharath-クマー]Bharath-クマー、K.、およびJ.ジャフィー、「コンピュータNetworksの複数の目的地へのルート設定」、IEEE Transactions。
[Deering] Deering, S., "Multicast Routing in Internetworks
and Extended LANs", SIGCOMM Summer 1988
Proceedings, August 1988.
[デアリング] デアリング、S.、「インターネットワークと拡張LANにおけるマルチキャストルート設定」、SIGCOMM1988年夏の議事、1988年8月。
[Deering2] Deering, S., "Multicast Routing in a Datagram
Internetwork", Stanford Technical Report
STAN-CS-92-1415, Department of Computer Science,
Stanford University, December 1991.
[Deering2] デアリング、S.、「データグラムインターネットワークにおけるマルチキャストルート設定」、スタンフォード技術報告書スタンCs92-1415、コンピュータサイエンス学部、スタンフォード大学(1991年12月)。
[OSPF] Moy, J., "OSPF Version 2", RFC 1583, Proteon,
Inc., March 1994.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、RFC1583、Proteon Inc.、1994インチ年3月。
[OSPF MIB] Baker F., and R. Coltun, "OSPF Version 2 Management
Information Base", RFC 1253, ACC, Computer Science
Center, August 1991.
[OSPF MIB] ベイカーF.、およびR.Coltun、「OSPFバージョン2管理情報ベース」、RFC1253(ACC、Computerサイエンス・センター1991年8月)。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
Proteon, Inc., March 1994.
[MOSPF] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、Proteon Inc.、1994年3月。
[RFC 1075] Waitzman, D., Partridge, C. and S. Deering,
"Distance Vector Multicast Routing Protocol", RFC
1075, BBN STC, Stanford University, November 1988.
[RFC1075] Waitzman、D.、ヤマウズラ、C.、およびS.デアリングは「ベクトルマルチキャストルーティング・プロトコルを遠ざけます」、RFC1075、BBN STC、スタンフォード大学、1988年11月。
[RFC 1112] Deering, S., "Host Extensions for IP Multicasting",
Stanford University, RFC 1112, May 1988.
[RFC1112] デアリング(S.、「IPマルチキャスティングのためのホスト拡大」、スタンフォード大学、RFC1112)は1988がそうするかもしれません。
[RFC 1209] Piscitello, D., and J. Lawrence, "Transmission of IP
Datagrams over the SMDS Service", RFC 1209, Bell
Communications Research, March 1991.
[RFC1209] Piscitello、D.、およびJ.ローレンス、「SMDSサービスの上のIPデータグラムの送信」、RFC1209、ベルコミュニケーションズ・リサーチ(1991年3月)。
[RFC 1245] Moy, J., Editor, "OSPF Protocol Analysis", RFC
1245, Proteon, Inc., July 1991.
[RFC1245] Moy、J.、エディタ、「OSPFプロトコル分析」、RFC1245、Proteon Inc.、1991年7月。
[RFC 1246] Moy, J., Editor, "Experience with the OSPF
Protocol", RFC 1245, Proteon, Inc., July 1991.
Moy(J.、エディタ)が「OSPFプロトコルで経験する」[RFC1246]、RFC1245、Proteon Inc.、1991年7月。
[RFC 1264] Hinden, R., "Internet Routing Protocol
Standardization Criteria", RFC 1264, BBN, October
1991.
[RFC1264] Hinden、R.、「インターネットルーティング・プロトコル標準化評価基準」、RFC1264、BBN、1991年10月。
Moy [Page 12] RFC 1585 MOSPF: Analysis and Experience March 1994
Moy[12ページ]RFC1585MOSPF: 1994年の分析と経験行進
[RFC 1390] Katz, D., "Transmission of IP and ARP over FDDI
Networks", RFC 1390, cisco Systems, Inc., January
1993.
[RFC1390] キャッツ、D.、「FDDIネットワークの上のIPとARPのトランスミッション」、RFC1390、コクチマスSystems Inc.、1993年1月。
[RFC 1354] Baker, F., "IP Forwarding Table MIB", RFC 1354,
ACC, July 1992.
[RFC1354] ベイカー、F.、「IP推進テーブルMIB」、RFC1354、ACC、1992年7月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo, tho see Section 2.
このメモで安全保障問題について議論しないで、thoはセクション2を見ます。
Author's Address
作者のアドレス
John Moy Proteon, Inc. 9 Technology Drive Westborough, MA 01581
Driveウェストボーラフ、ジョンMoy Proteon Inc.9Technology MA 01581
Phone: (508) 898-2800 EMail: jmoy@proteon.com
以下に電話をしてください。 (508) 898-2800 メールしてください: jmoy@proteon.com
Moy [Page 13]
Moy[13ページ]
一覧
スポンサーリンク
