RFC1469 日本語訳
1469 IP Multicast over Token-Ring Local Area Networks. T. Pusateri. June 1993. (Format: TXT=8189 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Pusateri Request for Comments: 1469 Consultant June 1993
Pusateriがコメントのために要求するワーキンググループT.をネットワークでつないでください: 1469 コンサルタント1993年6月
IP Multicast over Token-Ring Local Area Networks
トークンリングの上のIPマルチキャストローカル・エリア・ネットワーク
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. Although an interim solution has emerged and is currently being used, it is the intention of this document to specify a more efficient means of transmission using an assigned Token-Ring functional address.
このドキュメントはToken-リングローカル・エリア・ネットワークの上でIPマルチキャストデータグラムのトランスミッションのためのメソッドを指定します。 当座のソリューションは、現れて、現在使用されていますが、それはこのドキュメントがトランスミッションが割り当てられたToken-リング機能アドレスを使用するより効率的な手段を指定するという意志です。
Introduction
序論
IP multicasting provides a means of transmitting IP datagrams to a group of hosts. A group IP address is used as the destination address in the IP datagram as documented in STD 5, RFC 1112 [1]. These group addresses, also referred to as Class D addresses, fall in the range from 224.0.0.0 to 239.255.255.255. A standard method of mapping IP multicast addresses to media types such as ethernet and fddi exist in [1] and RFC 1188 [2]. This document attempts to define the mapping for an IP multicast address to the corresponding Token- Ring MAC address.
IPマルチキャスティングはIPデータグラムをホストのグループに送る手段を提供します。 グループIPアドレスは送付先アドレスとしてSTD5に記録されるIPデータグラムで使用されます、RFC1112[1]。 また、Class Dアドレスと呼ばれたこれらのグループアドレスが範囲で224.0から落下する、.0、.0、239.255 .255 .255。 イーサネットとfddiが[1]とRFC1188[2]に存在するとき、IPマルチキャストアドレスをメディアに写像する標準方法はそのようなものをタイプします。 このドキュメントは、対応するTokenリングMACアドレスとIPマルチキャストアドレスのためのマッピングを定義するのを試みます。
Background
バックグラウンド
The Token-Ring Network Architecture Reference [3] provides several types of addressing mechanisms. These include both individual (unicast) and group addresses (multicast). A special subtype of group addresses are called functional addresses and are indicated by a bit in the destination MAC address. They were designed for widely used functions such as ring monitoring, NETBIOS, Bridge, and Lan Manager frames. There are a limited number of functional addresses, 31 in all, and therefore several unrelated functions must share the same functional address.
Token-リングNetwork Architecture Reference[3]はメカニズムこれらのインクルードが個人(ユニキャスト)とグループアドレス(マルチキャスト)の両方であると扱ういくつかのタイプを提供します。 グループアドレスの特別な「副-タイプ」は、送付先MACアドレスで機能アドレスと呼ばれて、少し示されます。 それらはリングモニターや、NETBIOSや、Bridgeや、ランマネージャフレームなどの広く使用された機能のために設計されました。 限られた数の機能アドレス、全部で31があります、そして、したがって、いくつかの関係ない機能が同じ機能アドレスを共有しなければなりません。
Pusateri [Page 1] RFC 1469 IP Multicast over Token-Ring LANs June 1993
トークンリングの上のPusateri[1ページ]RFC1469IPマルチキャストLAN1993年6月
It would be most desirable if Token-Ring could use the same mapping as ethernet and fddi for IP multicast to hardware multicast addressing. However, current implementations of Token-Ring controller chips cannot support this. To see why, we must first examine the Destination MAC address format.
Token-リングがIPマルチキャストにイーサネットとfddiと同じマッピングをハードウェアマルチキャストアドレシングに使用できるなら、最も望ましいでしょうに。 しかしながら、Token-リングコントローラチップの現在の実装はこれをサポートすることができません。 理由を見るために、私たちは最初に、Destination MACアドレス形式を調べなければなりません。
Destination Address Format
目的地アドレス形式
The destination MAC address consists of six octets. In the following diagram of a MAC address, the order of transmission of the octets is from top to bottom (octet 0 to octet 5), and the order of transmission of the bits within each octet is from right to left (bit 0 to bit 7). This is the so-called "canonical" bit order for IEEE 802.2 addresses. Addresses supplied to or received from token ring interfaces are usually laid out in memory with the bits of each octet in the opposite order from that illustrated, i.e., with bit 0 in the high-order (leftmost) position within the octet.
送付先MACアドレスは6つの八重奏から成ります。 MACアドレスの以下のダイヤグラムで、八重奏の送信の注文は上から下まで(八重奏0から八重奏5)です、そして、各八重奏の中のビットのトランスミッションの注文は左(ビット0からビット7)への権利から来ています。 これはIEEE802.2の注文が扱ういわゆる「正準な」ビットです。 通常、それからの反対のオーダーにおける、それぞれの八重奏のビットが例証されている状態で、供給されたかトークンから容認されたリングが連結するアドレスはメモリで広げられます、すなわち、ビット0が八重奏の中の高位(一番左)位置にある状態で。
7 6 5 4 3 2 1 0
7 6 5 4 3 2 1 0
--------------------------------- | | | | | | |U/L|I/G| octet 0 --------------------------------- | | | | | | | | | octet 1 --------------------------------- | | | | | | | |FAI| octet 2 --------------------------------- | | | | | | | | | octet 3 --------------------------------- | | | | | | | | | octet 4 --------------------------------- | | | | | | | | | octet 5 ---------------------------------
--------------------------------- | | | | | | |U/L|I/G| 八重奏0--------------------------------- | | | | | | | | | 八重奏1--------------------------------- | | | | | | | |FAI| 八重奏2--------------------------------- | | | | | | | | | 八重奏3--------------------------------- | | | | | | | | | 八重奏4--------------------------------- | | | | | | | | | 八重奏5---------------------------------
The low order bit of the high order octet is called the I/G bit. It signifies whether the address is an individual address (0) or a group address (1). This is comparable to the multicast bit in the DIX Ethernet addressing format.
高位八重奏の下位のビットはI/Gビットと呼ばれます。 それはアドレスが個々のアドレス(0)かグループアドレス(1)であることにかかわらず意味します。 これはDIXイーサネットアドレス指定形式でマルチキャストビットに匹敵しています。
Bit position 1 of the high order octet, called the U/L bit, specifies whether the address is universally administered (0) or locally administered (1). Universally administered addresses are those specified by a standards organization such as the IEEE.
または、U/Lビットと呼ばれる高位八重奏のビット位置1が、アドレスが一般に管理されるかどうか指定する、(0)、局所的に、(1)を管理しました。 一般に管理されたアドレスはIEEEなどの規格組織によって指定されたものです。
If the I/G bit is set to 1 and the U/L bit is 0, the address must be a universally administered group address. If the I/G bit is 1 and the U/L bit is a 1, the address may be either a local administered group address or a functional address. This distinction is determined by
I/Gビットが1に設定されて、U/Lビットが0であるなら、アドレスは一般に管理されたグループアドレスであるに違いありません。 I/Gビットが1であり、U/Lビットがa1であるなら、アドレスは、ローカルの管理されたグループアドレスか機能アドレスのどちらかであるかもしれません。 この区別は決定しています。
Pusateri [Page 2] RFC 1469 IP Multicast over Token-Ring LANs June 1993
トークンリングの上のPusateri[2ページ]RFC1469IPマルチキャストLAN1993年6月
the Functional Address Indicator (FAI) bit located in bit position 0 of octet 2. If the FAI bit is 0, the address is considered a functional address. And if the FAI bit is 1, this indicates a locally administered group address.
Functional Address Indicator(FAI)ビットはビット位置で0つの八重奏2の場所を見つけました。 FAIビットが0であるなら、アドレスは機能アドレスであると考えられます。 そして、FAIビットが1であるなら、これは局所的に管理されたグループアドレスを示します。
Different functional addresses are made by setting one of the remaining 31 bits in the address field. These bits include the 7 remaining bits in octet 2 as well as the 8 bits in octets 3, 4, and 5. It is not possible to create more functional addresses by setting more than one of these bits at a time.
異なった機能アドレスは、残りのものをアドレス・フィールドに31ビットはめ込むことによって、作られています。 これらのビットは八重奏3、4、および5に残っている7ビットを八重奏2と8ビット含んでいます。 一度にこれらのビットの1つ以上を設定することによって、より機能的なアドレスを作成するのは可能ではありません。
Three methods exist for mapping between an IP multicast address and a hardware address. These include:
3つのメソッドがマッピングのためにIPマルチキャストアドレスとハードウェア・アドレスの間に存在しています。 これらは:
1. The all rings broadcast address
1. すべてのリングがアドレスを放送します。
2. The assigned functional address
2. 割り当てられた機能アドレス
3. The existing IEEE assigned IP Multicast group addresses
3. 既存のIP Multicastグループアドレスが割り当てられたIEEE
In order to insure interoperability, all systems supporting IP multicasting on each physical ring must agree on the hardware address to be used. Therefore, the method used should be configurable on a given interface. Bridges may provide a means to translate between different methods for each physical ring that is being bridged. Method (3) is recommended but due to hardware limitations of Token- Ring controller chips, may not be possible. In this case, Method (2) is preferred over Method (1). For backward compatibility, systems that support (2) MUST also support (1). And systems that support (3) MUST also support (2) and therefore (1). In the absence of configuration information, the default should be to use the assigned functional address (2).
相互運用性を保障して、それぞれの物理的なリングの上にIPマルチキャスティングをサポートするすべてのシステムが、使用されるためにハードウェア・アドレスに同意しなければなりません。 したがって、使用されるメソッドは与えられたインタフェースで構成可能であるべきです。 ブリッジはブリッジされているそれぞれの物理的なリングのために異なったメソッドの間で翻訳する手段を提供するかもしれません。 メソッド(3)はお勧めですが、Tokenリングコントローラチップのハードウェア限界のために、可能でないかもしれません。 この場合、Method(2)はMethod(1)より好まれます。 また、後方の互換性のために、(2)をサポートするシステムは(1)をサポートしなければなりません。 そして、(3)をサポートするシステムは、(2)をサポートして、また、その結果(1)をサポートしなければなりません。 設定情報がないとき、デフォルトは割り当てられた機能アドレス(2)を使用することであるべきです。
IP Multicast Functional Address
IPマルチキャスト機能アドレス
Because there is a shortage of Token-Ring functional addresses, all IP multicast addresses have been mapped to a single Token-Ring functional address. In canonical form, this address is 03-00-00-20- 00-00. In non-canonical form, it is C0-00-00-04-00-00. It should be noted that since there are only 31 possible functional addresses, there may be other protocols that are assigned this functional address as well. Therefore, just because a frame is sent to the functional address 03-00-00-20-00-00 does not mean that it is an IP multicast frame.
Token-リング機能アドレスの不足があるので、すべてのIPマルチキャストアドレスがただ一つのToken-リング機能アドレスに写像されました。 標準形では、このアドレスは03-00-00-20- 00-00です。 正典外のフォームでは、それはC0-00-00-04-00-00です。 31の可能な機能アドレスしかないのでまた、この機能アドレスが割り当てられる他のプロトコルがあるかもしれないことに注意されるべきです。 したがって、ただフレームを機能的に送るので、アドレス03-00-00-20-00-00は、それがIPマルチキャストフレームであることを意味しません。
Pusateri [Page 3] RFC 1469 IP Multicast over Token-Ring LANs June 1993
トークンリングの上のPusateri[3ページ]RFC1469IPマルチキャストLAN1993年6月
Acknowledgments
承認
The author would like to thank John Moy, Fred Baker, Steve Deering, and Rob Enns for their review and constructive comments.
作者は彼らのレビューと建設的なコメントについてジョンMoy、フレッド・ベイカー、スティーブ・デアリング、およびロブ・エンスに感謝したがっています。
References
参照
[1] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.
[1] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1989年8月。
[2] Katz, D., "A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET, October 1990.
[2] キャッツ、D.、「FDDIネットワークの上のIPデータグラムの送信の提案された標準」、RFC1188、長所/NSFNET、1990年10月。
[3] IBM Token-Ring Network, Architecture Reference, Publication SC30- 3374-02, Third Edition, (September, 1989).
[3] IBMトークンリングネットワーク、アーキテクチャ参照、公表SC30 3374-02、第3版(1989年9月)。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Thomas J. Pusateri Consultant 11820 Edgewater Ct. Raleigh, NC 27614
トーマスJ.Pusateri11820コンサルタントEdgewater ct。 ローリー、NC 27614
EMail: pusateri@cs.duke.edu
メール: pusateri@cs.duke.edu
Pusateri [Page 4]
Pusateri[4ページ]
一覧
スポンサーリンク