RFC1586 日本語訳
1586 Guidelines for Running OSPF Over Frame Relay Networks. O.deSouza, M. Rodrigues. March 1994. (Format: TXT=14968 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group O. deSouza Request for Comments: 1586 M. Rodrigues Category: Informational AT&T Bell Laboratories March 1994
deSouzaがコメントのために要求するワーキンググループO.をネットワークでつないでください: 1586年のM.ロドリーグカテゴリ: 1994年の情報のAT&Tベル研究所の行進
Guidelines for Running OSPF Over Frame Relay Networks
フレームリレーネットワークの上にOSPFを実行するためのガイドライン
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 specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. We show how to configure frame relay interfaces in a way that obviates the "full-mesh" connectivity required by current OSPF implementations. This allows for simpler, more economic network designs. These guidelines do not require any protocol changes; they only provide recommendations for how OSPF should be implemented and configured to use frame relay networks efficiently.
オープンShortest Path First(OSPF)ルーティング・プロトコルの作成者とユーザがプロトコルがどうフレームリレーネットワークをひくかの改良を引き起こすように、このメモはガイドラインを指定します。 私たちは、「完全なメッシュ」の接続性を取り除く方法でフレームリレーインタフェースが現在のOSPF実装が必要であることをどのように構成するかを示します。 これは、より簡単で、より経済のネットワークデザインを考慮します。 これらのガイドラインは少しのプロトコル変化も必要としません。 彼らはOSPFが効率的にフレームリレーネットワークを使用するためにどう実装されて、構成されるべきであるか推薦を提供するだけです。
Acknowledgements
承認
This memo is the result of work done in the OSPF Working Group of the IETF. Comments and contributions from several sources, especially Fred Baker of ACC, John Moy of Proteon, and Bala Rajagopalan of AT&T Bell Laboratories are included in this work.
このメモはIETFのOSPF作業部会で行われた仕事の結果です。 いくつかのソース、特にACCのフレッド・ベイカー、ProteonのジョンMoy、およびAT&Tベル研究所のBala Rajagopalanからのコメントと貢献はこの仕事に含まれています。
1. Introduction
1. 序論
A frame relay (FR) network provides virtual circuits (VCs) to interconnect attached devices. Each VC is uniquely identified at each FR interface by a Data Link Connection Identifier (DLCI). RFC 1294 specifies the encapsulation of multiprotocol traffic over FR [1]. The devices on a FR network may either be fully interconnected with a "mesh" of VCs, or partially interconnected. OSPF characterizes FR networks as non-broadcast multiple access (NBMA) because they can support more than two attached routers, but do not have a broadcast capability [2]. Under the NBMA model, the physical FR interface on a router corresponds to a single OSPF interface through which the router is connected to one or more neighbors on the FR network; all the neighboring routers must also be directly connected to each other
フレームリレー(FR)ネットワークは、付属デバイスとインタコネクトするために、仮想の回路(VCs)を提供します。 各VCはそれぞれのFRインタフェースでData Link Connection Identifier(DLCI)によって唯一特定されます。 RFC1294はFR[1]の上で「マルチ-プロトコル」トラフィックのカプセル化を指定します。 FRネットワークのデバイスは、VCsの「メッシュ」で完全にインタコネクトされるか、または部分的にインタコネクトされるかもしれません。 2以上をサポートすることができるので複数の非放送アクセス(NBMA)がルータを付けたので、OSPFはFRネットワークを特徴付けますが、放送能力[2]を持たないでください。 NBMAモデルの下では、ルータの物理的なFRインタフェースはルータがFRネットワークの1人以上の隣人に接される単一のOSPFインタフェースに対応しています。 また、直接すべての隣接しているルータに互いに接しなければなりません。
deSouza & Rodrigues [Page 1] RFC 1586 OSPF over Frame Relay March 1994
フレームリレー1994年3月の上のdeSouzaとロドリーグ[1ページ]RFC1586OSPF
over the FR network. Hence OSPF implementations that use the NBMA model for FR do not work when the routers are partially interconnected. Further, the topological representation of a multiple access network has each attached router bi-directionally connected to the network vertex with a single link metric assigned to the edge directed into the vertex.
FRネットワークの上で。 ルータが部分的にインタコネクトされているとき、したがって、FRにNBMAモデルを使用するOSPF実装が働いていません。 さらに、複数のアクセスネットワークの位相的な代理には、ネットワーク頂点に接続された単一のメートル法であるリンクで両性愛者の方向が頂点に向けられた縁に割り当てたそれぞれの付属ルータがあります。
We see that the NBMA model becomes more restrictive as the number of routers connected to the network increases. First, the number of VCs required for full-mesh connectivity increases quadratically with the number of routers. Public FR services typically offer performance guarantees for each VC provisioned by the service. This means that real physical resources in the FR network are devoted to each VC, and for this the customer eventually pays. The expense for full-mesh connectivity thus grows quadratically with the number of interconnected routers. We need to build OSPF implementations that allow for partial connectivity over FR. Second, using a single link metric (per TOS) for the FR interface does not allow OSPF to weigh some VCs more heavily than others according to the performance characteristics of each connection. To make efficient use of the FR network resources, it should be possible to assign different link metrics to different VCs.
私たちは、ネットワークに関連づけられたルータの数が増加するのに従ってNBMAモデルが、より制限するようになるのがわかります。 まず最初に、ルータの数に従って、完全なメッシュの接続性に必要であるVCsの数は二次関数的に増加します。 公共のFRサービスはサービスで食糧を供給された各VCのために契約履行保証を通常提供します。 これは、FRネットワークにおける本当の物理資源が各VCと、そして、顧客が結局支払うこれように注がれることを意味します。 その結果、インタコネクトされたルータの数に従って、完全なメッシュの接続性のための費用は二次関数的に伸びます。 私たちは、FRの上で部分的な接続性を考慮する実装をOSPFに築き上げる必要があります。 2番目に、単一のリンクを使用して、それぞれの接続の性能の特性に従って、OSPFはFRにおけるメートル法(1TOSあたりの)のインタフェースでいくつかのVCsの他のものより大いに重さを計ることができません。 FRネットワーク資源の効率的な使用をするように、異なったリンク測定基準を異なったVCsに割り当てるのは可能であるべきです。
These limitations of the current OSPF model for FR become more severe as the network size increases, and render FR technology less cost effective than it could be for large networks. We propose solutions to these problems that do not increase complexity by much and do not require any changes to the OSPF protocol.
FRの現在のOSPFモデルのこれらの限界は、ネットワークの規模が増加するのに従って、より厳しくなって、それであることができたほど大きいネットワークには費用効率がよくなくFR技術を表します。 私たちは複雑さをあまり増強しないで、またOSPFプロトコルへの少しの変化も必要としないこれらの問題にソリューションを提案します。
2. Summary of Recommendations
2. 推薦の概要
We propose expanding the general view of an OSPF interface to account for its functional type (point-to-point, broadcast, NBMA) rather than its physical type. In most instances, the physical network can only serve one function and can only be defined as one type of OSPF interface. For multiplexed interfaces such as FR however, logical connections between routers can serve different functions. Hence one VC on a FR interface can be viewed distintly from other VCs on the same physical interface. The solution requires that OSPF be able to support logical interfaces (networks) as well as physical interfaces. Each logical network can be either point-to-point, that is, a single VC, or NBMA, that is, a collection of VCs. It is not necessary to define new interface types for logical networks, since the operation of the protocol over logical point-to-point networks and logical NBMA networks remains the same as for the corresponding physical networks. For instance, logical point-to-point links could be numbered or unnumbered. It is only necessary for implementations to provide the hooks that give users the ability to configure an individual VC as a
私たちは、物理的なタイプよりむしろ職能型(ポイントツーポイント、放送、NBMA)の原因になるようにOSPFインタフェースの概観を広げるよう提案します。 たいていの場合、物理ネットワークは、1つの機能しか果たすことができないで、1つのタイプのOSPFインタフェースと定義できるだけです。 しかしながら、FRなどの多重送信されたインタフェースに関しては、ルータの間の論理的な関係は異なった機能を果たすことができます。 したがって、同じ物理インターフェースの他のVCsからFRインタフェースの1VCを色をつけて見ることができます。 ソリューションは、OSPFが、論理的なインタフェースが物理インターフェースと同様に(ネットワーク)であるとサポートすることができるのを必要とします。 それぞれの論理的なネットワークはすなわち、ポイントツーポイント、独身のVCかNBMAのどちらか、すなわち、VCsの収集であるかもしれません。 論理的なネットワークのための新しいインターフェース型を定義するのは必要ではありません、論理的な二地点間ネットワークと論理的なNBMAネットワークの上のプロトコルの操作が対応する物理ネットワークのように同じままで残っているので。 例えば、論理的なポイントツーポイント接続は、番号付である、または無数であるかもしれません。 実装が単にaとして個々のVCを構成する能力をユーザに与えるフックを提供するのが必要です。
deSouza & Rodrigues [Page 2] RFC 1586 OSPF over Frame Relay March 1994
フレームリレー1994年3月の上のdeSouzaとロドリーグ[2ページ]RFC1586OSPF
logical point-to-point network or a collection of VCs as a logical NBMA network.
論理的なNBMAネットワークとしてのVCsの論理的な二地点間ネットワークか収集。
The NBMA model does provide some economy in OSPF protocol processing and overhead and is the recommended mode of operation for small homogeneous networks. Other than the Designated Router (DR) and the backup Designated Router (BDR), each router maintains only two adjacencies, one each with the DR and BDR, regardless of the size of the NBMA network. When FR VCs are configured as point-to-point links, a router would have many more adjacencies to maintain, resulting in increased protocol overhead. If all VCs were to have comparable performance characteristics as well, there may not be compelling reasons to assign a different link metric to each VC.
NBMAモデルは、OSPFプロトコル処理とオーバーヘッドに何らかの経済を提供して、小さい同次のネットワークのための操作のお勧めのモードです。 Designated Router(DR)とバックアップDesignated Router(BDR)を除いて、各ルータは2つの隣接番組とそれぞれDRがある1とNBMAネットワークのサイズにかかわらずBDRだけを維持します。 ポイントツーポイントがリンクされるときFR VCsが構成されるとき、ルータには、維持するずっと多くの隣接番組があるでしょう、増強されたプロトコルオーバーヘッドをもたらして。 すべてのVCsにまた、匹敵する性能の特性があるつもりであったなら、各VCへのメートル法の異なったリンクを割り当てるやむにやまれない理由がないかもしれません。
3. Implementing OSPF over FR
3. FRの上でOSPFを実装します。
We recommend that OSPF router implementations be built so that administrators can configure network layer interfaces that consist of one or more FR VCs within a single physical interface. Each logical network interface could then be configured as the appropriate type of OSPF interface, that is, point-to-point for a single VC, or NBMA for a collection of VCs. This capability would allow a router to belong to one or more distinct IP subnets on a single physical FR interface. Thus, it is necessary that the router be able to support multiple IP addresses on a single physical FR interface. As with physical NBMA networks, logical NBMA networks must be full-mesh connected. While logical point-to-point links can be either numbered or unnumbered, we show that it is easier to implement routers to handle numbered logical point-to-point links.
私たちは、管理者が単一の物理インターフェースの中の1FR VCsから成るネットワーク層インタフェースを構成できるようにOSPFルータ実装が築き上げられることを勧めます。 そして、適切なタイプのOSPFインタフェース、すなわち、独身のVCのためのポイントツーポイント、またはVCsの収集のためのNBMAとしてそれぞれの論理的なネットワーク・インターフェースを構成できました。 この能力で、ルータは単一の物理的なFRインタフェースの1か、より異なったIPサブネットに属すことができるでしょう。 したがって、ルータが単一の物理的なFRインタフェースに関する複数のIPアドレスをサポートできるのが必要です。 物理的なNBMAネットワークなら、論理的なNBMAネットワークは接続された完全なメッシュであるに違いありません。 論理的なポイントツーポイント接続が付番されているか、または無数である場合がある間、私たちは、番号付の論理的なポイントツーポイント接続を扱うためにルータを実装するのが、より簡単であることを示します。
3.1 Numbered Logical Interfaces
3.1 番号付の論理的なインタフェース
The router administrator should be able to configure numbered logical interfaces over FR as follows:
ルータ管理者は以下のFRの上で番号付の論理的なインタフェースを構成できるべきです:
STEP 1: Configure the physical interface specifying relevant parameters such as the slot, connector, and port numbers, physical frame format, encoding, and clock mode. In its internal interface MIB [3], the router should create a new ifEntry in the ifTable, assign the physical interface an ifIndex, and increment the ifNumber by one.
ステップ1: スロットや、コネクタや、ポートナンバーや、物理的なフレーム形式や、コード化や、時計モードなどの関連パラメタを指定する物理インターフェースを構成してください。 内部のインタフェースMIB[3]では、ルータは、ifTableで新しいifEntryを作成して、ifIndexを物理インターフェースに割り当てて、ifNumberを1つ増加するべきです。
STEP 2: Configure the data-link layer over the interface, specifying frame relay as the encapsulation method. Parameters such as the DLCI encoding type and length, maximum frame size, management interface (Annex D, LMI), and address resolution procedure (manual, inverse ARP). If a management interface is not supported, FR VCs must be
ステップ2: カプセル化メソッドとしてフレームリレーを指定して、インタフェースの上でデータ・リンク層を構成してください。 タイプと長さをコード化するDLCIなどのパラメタ、最大のフレーム・サイズ、経営者側は解決手順が(手動の、そして、逆さのARP)であると連結して(LMI、Dを付加してください)、扱います。 管理インタフェースがサポートされないなら、FR VCsはサポートされるに違いありません。
deSouza & Rodrigues [Page 3] RFC 1586 OSPF over Frame Relay March 1994
フレームリレー1994年3月の上のdeSouzaとロドリーグ[3ページ]RFC1586OSPF
configured manually.
手動で構成されます。
STEP 3: Configure the IP network layer for the interface by specifying the number of logical interfaces and the IP address and subnet mask for each numbered logical interface. Specify the VCs (by DLCI) associated with each logical network interface if there is more than one. If an address resolution protocol such as Inverse ARP [4] is being used, it should suffice to specify a list of IP addresses for the FR interface and have Inverse ARP create the DLCI-IP address binding.
ステップ3: 論理的なインタフェースの数、IPアドレス、およびサブネットマスクをそれぞれの番号付の論理的なインタフェースに指定することによって、IPネットワーク層をインタフェースに構成してください。 1つ以上があれば、それぞれの論理的なネットワーク・インターフェースに関連しているVCs(DLCIによる)を指定してください。 Inverse ARP[4]などのアドレス解決プロトコルが使用されているなら、FRインタフェースへのIPアドレスのリストを指定して、Inverse ARPにDLCI-IPアドレス結合を作成させるように、それは十分であるべきです。
STEP 4: Configure OSPF to run over each logical interface as appropriate, specifying the necessary interface parameters such as area ID, link metric, protocol timers and intervals, DR priority, and list of neighbors (for the DR). OSPF interfaces consisting of one VC can be treated as point-to-point links while multi-VC OSPF interfaces are treated as NBMA subnets. In its internal OSPF MIB [5], the router should create additional entries in the ospfIfTable each with the appropriate ospfIfType (nbma or pointTopoint).
ステップ4: OSPFを構成して、適宜それぞれの論理的なインタフェースをひいてください、領域IDなどの必要なインタフェース・パラメータを指定して隣人(DRのための)のメートル法のプロトコルタイマ、間隔、DR優先権、およびリストをリンクしてください。 マルチVC OSPFインタフェースがNBMAサブネットとして扱われている間、1VCから成るOSPFインタフェースはポイントツーポイント接続として扱うことができます。 内部のOSPF MIB[5]では、ルータは適切なospfIfType(nbmaかpointTopoint)と共にそれぞれospfIfTableで追加エントリーを作成するべきです。
3.2 Unnumbered Point-to-Point Logical Interfaces
3.2 無数の二地点間論理的なインタフェース
OSPF uses the IP address to instance each numbered interface. However, since an unnumbered point-to-point link does not have an IP address, the ifIndex from the interface MIB is used instead [5]. This is straightforward for a physical point-to-point network, since the ifIndex is assigned when the interface is configured. Logical interfaces over FR however, do not have distinct and unique values for ifIndex. To allow OSPF to instance unnumbered logical point-to- point links, it is necessary to assign each such link a unique ifIndex in STEP 3 above. This could lead to some confusion in the interfaces table since a new ifTable entry would have to be created for each logical point-to-point link. This type of departure from the standard practice of creating interface table entries only for physical interfaces could be viewed as an unnecessary complication.
インスタンスへのIPアドレスがそれぞれ付番したOSPF用途は連結します。 無数のポイントツーポイント接続にはIPアドレスがないので、しかしながら、インタフェースMIBからのifIndexは代わりに使用されます。[5]。 インタフェースが構成されるとき、ifIndexが割り当てられるので、物理的な二地点間ネットワークに、これは簡単です。 論理的である、しかしながら、FRの上で連結して、ifIndexのために異なってユニークな値を持っていません。 インスタンスの無数の論理的なポイントからポイントへのリンクにOSPFを許容するために、上のSTEP3でそのような各リンクにユニークなifIndexを割り当てるのが必要です。 これは新しいifTableエントリー以来のテーブルがそれぞれの論理的なポイントツーポイント接続に作成されるために持っているインタフェースでの何らかの混乱に通じるかもしれません。 不要な複雑さとして物理インターフェースのためだけのインタフェーステーブルエントリーを作成する標準的技法からのこのタイプの出発を見なすことができました。
Alternatively, it is possible to build a private MIB that contains data structures to instance unnumbered logical links. However, making recommendations for the structure and use of such a private MIB is beyond the scope of this work. Even if unnumbered point-to-point logical links were implemented in this manner, it would still be necessary to allow a FR interface to be configured with multiple IP addresses when a router is connected to multiple NBMA subnets through a single physical interface. Hence, while it is possible to define unnumbered logical point-to-point links in OSPF, we find this
あるいはまた、インスタンスの無数の論理的なリンクにデータ構造を含む個人的なMIBを造るのは可能です。 しかしながら、そのような個人的なMIBの構造と使用のための推薦状をするのはこの仕事の範囲を超えています。 ルータが単一の物理インターフェースを通して複数のNBMAサブネットに関連づけられるとき、無数の二地点間論理的なリンクがこの様に実装されたとしても、FRインタフェースが複数のIPアドレスによって構成されるのを許容するのがまだ必要でしょうに。 したがって、OSPFで無数の論理的なポイントツーポイント接続を定義するのが可能である間、私たちはこれを見つけます。
deSouza & Rodrigues [Page 4] RFC 1586 OSPF over Frame Relay March 1994
フレームリレー1994年3月の上のdeSouzaとロドリーグ[4ページ]RFC1586OSPF
alternative less attractive than using numbered logical point-to- point links.
番号付の論理的なポイントからポイントを使用するほど魅力的でない代替手段はリンクされます。
4. Using OSPF over FR
4. FRの上でOSPFを使用します。
The ability to configure distinct logical interfaces over FR gives users a great deal of flexibility in designing FR networks for use with OSPF. Because routers can be partially interconnected over FR, it is possible to design networks more cost-effectively than before. The issues to consider are the price/cost structure for VCs (fixed, distance-sensitive, banded) and ports, performance guarantees provided, traffic distribution (local, long-haul), and protocol efficiency. We have mentioned that the NBMA model provides some economy in OSPF protocol processing and overhead and is recommended for small homogeneous networks. In general, users should configure their networks to contain several small "NBMA clusters," which are in turn interconnected by long-haul VCs. The best choices for the number of routers in each cluster and the size of the long-haul logical point-to-point links depends on the factors mentioned above. If it is necessary to architect a more "flat" network, the ability to assign different link metrics to different (groups of) VCs allows for greater efficiency in using FR resources since VCs with better performance characteristics (throughput, delay) could be assigned lower link metrics.
FRの上で異なった論理的なインタフェースを構成する能力はOSPFとの使用のためにFRネットワークを設計する際に多くの柔軟性をユーザに与えます。 FRの上でルータが部分的にインタコネクトされることができるので、ネットワークを以前より費用効率よく設計するのは可能です。 考える問題は、VCs(修理されて、距離敏感で、組になっている)とポートへの価格/原価構造と、保証が提供した性能と、トラヒック分配(地方の長期)と、プロトコル効率です。 私たちは小さい同次のネットワークに、NBMAモデルが何らかの経済的にOSPFプロトコル処理とオーバーヘッドに提供して、お勧めであると言及しました。 一般に、ユーザは、長期VCsによって順番にインタコネクトされる数個の小さい「NBMAクラスタ」を含むように彼らのネットワークを構成するべきです。 各クラスタのルータの数のための最も良い選択と長期の論理的なポイントツーポイント接続のサイズは前記のように要素に依存します。 それが建築家のaより「平坦な」ネットワーク、異なったリンク測定基準を異なるのに割り当てる能力に必要であるかどうか、(分類する、)、VCsは、より良い性能の特性(スループット、遅れ)があるVCsに低いリンク測定基準を割り当てることができたのでFRリソースを使用する際に、より大きい効率を考慮します。
5. Conclusion
5. 結論
We have specified guidelines for OSPF implementors and users to bring about improvements in how the protocol runs over frame relay networks. These recommendations do not require any protocol changes and allow for simpler, more efficient and cost-effective network designs. We recommend that OSPF implementations be able to support logical interfaces, each consisting of one or more virtual circuits and used as numbered logical point-to-point links (one VC) or logical NBMA networks (more than one VC). The current NBMA model for frame relay should continue to be used for small homogeneous networks consisting of a few routers.
OSPF作成者とユーザがプロトコルがどうフレームリレーネットワークをひくかの改良を引き起こすように、私たちはガイドラインを指定しました。 これらの推薦は、プロトコル変化を必要として、よりより簡単で、効率的で費用対効果に優れたネットワークデザインを考慮しません。 私たちは、OSPF実装が論理的なインタフェースをサポートすることができることを勧めます、番号付の論理的なポイントツーポイントが(1VC)か論理的なNBMAネットワーク(1VC)をリンクするので、1個以上の仮想の回路から成って、使用されるそれぞれ。 フレームリレーのための現在のNBMAモデルは、いくつかのルータから成る小さい同次のネットワークに使用され続けるべきです。
deSouza & Rodrigues [Page 5] RFC 1586 OSPF over Frame Relay March 1994
フレームリレー1994年3月の上のdeSouzaとロドリーグ[5ページ]RFC1586OSPF
6. References
6. 参照
[1] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1294, Wellfleet Communications, Inc., BBN Communications, January 1992.
[1]ブラッドリーとT.とブラウン、C.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」RFC1294、WellfleetコミュニケーションInc.、BBNコミュニケーション(1992年1月)。
[2] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
[2]Moy、J.、「OSPF、バージョン2インチ、RFC1583、Proteon Inc.、1994インチ年3月。
[3] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based Internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Inc., Performance Systems International, March 1991.
[3] McCloghrie、K.とM.ローズ、エディターズ、「TCP/IPベースのインターネットのネットワークマネージメントのための管理情報ベース:」 「MIB-II」、STD17、RFC1213、ヒューズLANシステムInc.、国際言語運用機構、1991年3月。
[4] Bradley, T., and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, Wellfleet Communications, Inc., January 1992.
[4] ブラッドリー、T.とC.ブラウン、「逆さのアドレス解決プロトコル」、RFC1293、WellfleetコミュニケーションInc.、1992年1月。
[5] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1253, ACC, Computer Science Center, August 1991.
[5] ベイカー、F.とR.Coltun、「OSPFバージョン2管理情報ベース」、RFC1253、ACC、Computerサイエンス・センター1991年8月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
7. Authors' Addresses
7. 作者のアドレス
Osmund S. deSouza AT&T Bell Laboratories Room 1K-606 101 Crawfords Corner Road Holmdel, NJ 07733
1K-606 101のゼンマイS.deSouza AT&Tベル研究所部屋Crawfordsコーナー道路Holmdel、ニュージャージー 07733
Phone: (908) 949-1393 EMail: osmund.desouza@att.com
以下に電話をしてください。 (908) 949-1393 メールしてください: osmund.desouza@att.com
Manoel A. Rodrigues Room 1K-608 AT&T Bell Laboratories 101 Crawfords Corner Road Holmdel, NJ 07733
Crawfordsコーナー道路Holmdel、Manoel A.ロドリーグ余地の1K大西洋標準時608とTベル研究所101ニュージャージー 07733
Phone: (908) 949-4655 EMail: manoel.rodrigues@att.com
以下に電話をしてください。 (908) 949-4655 メールしてください: manoel.rodrigues@att.com
deSouza & Rodrigues [Page 6]
deSouzaとロドリーグ[6ページ]
一覧
スポンサーリンク