RFC1526 日本語訳
1526 Assignment of System Identifiers for TUBA/CLNP Hosts. D.Piscitello. September 1993. (Format: TXT=16848 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Piscitello Request for Comments: 1526 Bellcore Category: Informational September 1993
Piscitelloがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1526年のBellcoreカテゴリ: 情報の1993年9月
Assignment of System Identifiers for TUBA/CLNP Hosts
チューバ/CLNPホストへのシステム識別子の課題
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. The mechanism is extensible and can provide a basis for assigning system identifiers in a globally unique fashion.
このドキュメントはユニークさがTUBA/CLNPインターネットにおける自動構成の目的のために経路ドメインの中でRFC1237スタイルNSAPアドレスのシステム識別子部分に保証されるかもしれないコンベンションについて説明します。 メカニズムは、広げることができて、グローバルにユニークなファッションによるシステム識別子を割り当てる基礎を提供できます。
Introduction
序論
This memo specifies methods for assigning a 6 octet system identifier portion of the OSI NSAP address formats described in "Guidelines for OSI NSAP Allocation in the Internet" [1], in a fashion that ensures that the ID is unique within a routing domain. It also recommends methods for assigning system identifiers having lengths other than 6 octets. The 6 octet system identifiers recommended in this RFC are assigned from 2 globally administered spaces (IEEE 802 or "Ethernet", and IP numbers, administered by the Internet Assigned Numbers Authority, IANA).
このメモは「インターネットでのOSI NSAP配分のためのガイドライン」[1]で説明されたOSI NSAPアドレス形式の6八重奏システム識別子部分を割り当てるためのメソッドを指定します、IDが確実に経路ドメインの中でユニークになるようにするファッションで。 また、それは6つの八重奏以外の長さを持っているシステム識別子を割り当てるためのメソッドを推薦します。 このRFCのお勧めの6つの八重奏システム識別子が2つのグローバルに管理された空間(インターネットAssigned民数記Authority、IANAによって管理されたIEEE802か「イーサネット」と、IP番号)から割り当てられます。
At this time, the primary purpose for assuring uniqueness of system identifiers is to aid in autoconfiguration of NSAP addresses in TUBA/CLNP internets [2]. The guidelines in this paper also establish an initial framework within which globally unique system identifiers, also called endpoint identifiers, may be assigned.
このとき、システム識別子をユニークさに保証するためのプライマリ目的はTUBA/CLNPインターネット[2]における、NSAPアドレスの自動構成で支援することです。 また、この紙のガイドラインはまた、終点識別子と呼ばれたグローバルにユニークなシステム識別子が割り当てられるかもしれない初期のフレームワークを確立します。
Acknowledgments
承認
Many thanks to Radia Perlman, Allison Mankin, and Ross Callon of for their insights and assistance. Thanks also to the Ethernet connector to my MAC, which conveniently and quite inobtrusively fell out, enabling me to get an entire day's worth of work done without email interruptions.
彼らの洞察と支援のためにRadiaパールマン、アリソン・マンキン、およびロスCallonをありがとうございます。 また、便利に全く「不-おしつけがまし」に落ちた私のMACへのイーサネットコネクタをありがとうございます、私がメール中断なしで全体の日の仕事の価値をさせるのを可能にして。
Piscitello [Page 1] RFC 1526 System Identifiers for TUBA September 1993
チューバ1993年9月のためのPiscitello[1ページ]RFC1526システム識別子
1. Background
1. バックグラウンド
The general format of OSI network service access point (NSAP) addresses is illustrated in Figure 1.
OSIネットワークサービスアクセスポイント(NSAP)アドレスの一般形式は図1で例証されます。
_______________________________________________
|____IDP_____|_______________DSP______________|
|__AFI_|_IDI_|_____HO-DSP______|___ID___|_SEL_|
_______________________________________________ |____IDP_____|_______________DSP______________| |__AFI_|_イディ_|_____おーい、-、DSP______|___ID___|_SEL_|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
HO-DSP High-order DSP
ID System Identifier
SEL NSAP Selector
IDPの初期のドメイン部分AFI権威と形式ID IDIがドメインの識別子のDSPのドメインの特定の部分に頭文字をつける、おーい、-、DSP、高位DSP IDシステム識別子SEL NSAPセレクタ
Figure 1: OSI NSAP Address Structure.
図1: オウシNSAPは構造を扱います。
The recommended encoding and allocation of NSAP addresses in the Internet is specified in RFC 1237. RFC 1237 makes the following statements regarding the system identifier (ID) field of the NSAPA:
インターネットでのNSAPアドレスのお勧めのコード化と配分はRFC1237で指定されます。 RFC1237はNSAPAのシステム識別子(ID)分野に関する以下の声明を出します:
1. the ID field may be from one to eight octets in length
1. 長さにおける1〜8つの八重奏までID分野があるかもしれません。
2. the ID must have a single known length in any particular
routing domain
2. IDはどんな特定の経路ドメインにもただ一つの知られている長さを持たなければなりません。
3. the ID field must be unique within an area for ESs and
level 1 ISs, and unique within the routing domain for level
2 ISs.
3. ID分野は、領域の中でESsとレベル1ISsにユニークであって、レベル2ISsに、経路ドメインの中でユニークであるに違いありません。
4. the ID field is assumed to be flat
4. ID分野が平坦であると思われます。
RFC 1237 further indicates that, within a routing domain that conforms to the OSI intradomain routing protocol [3] the lower-order octets of the NSAP should be structured as the ID and SEL fields shown in Figure 1 to take full advantage of intradomain IS-IS routing. (End systems with addresses which do not conform may require additional manual configuration and be subject to inferior routing performance.)
RFC1237がさらにそれを示して、OSI intradomainルーティング・プロトコル[3]に従う経路ドメインの中では、NSAPの下層階級八重奏が最大限に利用する図1に示されたIDとSEL分野として構造化されるべきである、intradomain、-、ルーティング (従わないアドレスがあるエンドシステムは、追加手動の構成を必要として、劣ったルーティング性能を受けることがあるかもしれません。)
Both GOSIP Version 2 (under DFI-80h, see Figure 2a) and ANSI DCC NSAP addressing (Figure 2b) define a common DSP structure in which the system identifier is assumed to be a fixed length of 6 octets.
両方、GOSIPバージョン、2 (DFI-80hの下では、図2a)を見てください。そうすれば、(図2b)を扱うANSI DCC NSAPがシステム識別子が6つの八重奏の固定長であると思われる一般的なDSP構造を定義します。
Piscitello [Page 2] RFC 1526 System Identifiers for TUBA September 1993
チューバ1993年9月のためのPiscitello[2ページ]RFC1526システム識別子
_______________
|<--__IDP_-->_|___________________________________
|AFI_|__IDI___|___________<--_DSP_-->____________|
|_47_|__0005__|DFI_|AA_|Rsvd_|_RD_|Area_|ID_|Sel_|
octets |_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__|
_______________ | <--__IDP_-->_|___________________________________ |AFI_|__イディ___|___________<--_DSP_-->。____________| |_47_|__0005__|DFI_|AA_|Rsvd_|_第_|領域_|ID_|Sel_| 八重奏|_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__|
Figure 2 (a): GOSIP Version 2 NSAP structure.
______________
|<--_IDP_-->_|_____________________________________
|AFI_|__IDI__|____________<--_DSP_-->_____________|
|_39_|__840__|DFI_|_ORG_|Rsvd_|RD_|Area_|_ID_|Sel_|
octets |_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__|
図2(a): GOSIPバージョン2NSAP構造。 ______________ | <--_IDP_-->_|_____________________________________ |AFI_|__イディ__|____________<--_DSP_-->。_____________| |_39_|__840__|DFI_|_ORG_|Rsvd_|第_|領域_|_ID_|Sel_| 八重奏|_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
ORG Organization Name (numeric form)
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
IDP Initial Domain Part AFI AuthorityとFormat Identifier IDI Initial Domain Identifier DSP Domain Specific Part DFI DSP Format Identifier ORG Organization Name(数値フォーム)Rsvd Reserved RDルート設定Domain Identifier Area Area Identifier ID System Identifier SEL NSAP Selector
Figure 2(b): ANSI NSAP address format for DCC=840
図2(b): DCC=840であることのANSI NSAPアドレス形式
2. Autoconfiguration
2. 自動構成
There are provisions in OSI for the autoconfiguration of area addresses. OSI end systems may learn their area addresses automatically by observing area address identified in the IS-Hello packets transmitted by routers using the ISO 9542 End System to Intermediate System Routing Protocol, and may then insert their own system identifier. (In particular, RFC 1237 explains that when the ID portion of the address is assigned using IEEE style 48-bit identifiers, an end system can reconfigure its entire NSAP address automatically without the need for manual intervention.) End systems that have not been pre-configured with an NSAPA may also request an address from an intermediate system their area using [5].
条項が領域アドレスの自動構成のためのOSIにあります。 OSIエンドシステムが中で特定された領域アドレスを観測することによって自動的にそれらの領域アドレスを学ぶかもしれない、-、こんにちは、パケットはIntermediate Systemルート設定プロトコルにISO9542End Systemを使用するルータで伝わって、次に、それら自身のシステム識別子を挿入するかもしれません。 (特に、RFC1237は、アドレスのID部分がIEEEのスタイルの48ビットの識別子を使用することで割り当てられるとき、エンドシステムが手動の介入の必要性なしで全体のNSAPアドレスを自動的に再構成できると説明します。) NSAPAと共にあらかじめ設定されていないエンドシステムはそうするかもしれません、また、中間システムからアドレスを要求してください。それらの領域使用[5]。
2.1 Autoconfiguration and 48-bit addresses
2.1 自動構成と48ビットのアドレス
There is a general misassumption that the 6-octet system identifier must be a 48-bit IEEE assigned (ethernet) address. Generally speaking, autoconfiguration does not rely on the use of a 48-bit ethernet style address; any system identifier that is globally
6八重奏のシステム識別子が48ビットの(イーサネット)が割り当てられたIEEEがアドレスであったならそうしなければならない一般的なmisassumptionがあります。 概して、自動構成は48ビットのイーサネットスタイルアドレスの使用に依存しません。 グローバルにそうであるどんなシステム識別子
Piscitello [Page 3] RFC 1526 System Identifiers for TUBA September 1993
チューバ1993年9月のためのPiscitello[3ページ]RFC1526システム識別子
administered and is unique will do. The use of 48-bit/6 octet system identifiers is "convenient...because it is the same length as an 802 address", but more importantly, choice of a single, uniform ID length allows for "efficient packet forwarding", since routers won't have to make on the fly decisions about ID length (see [6], pages 156-157). Still, it is not a requirement that system identifiers be 6 octets to operate the the IS-IS protocol, and IS-IS allows for the use of IDs with lengths from 1 to 8 octets.
管理されて、ユニークな意志がするということです。 48ビットの/6八重奏システム識別子の使用は「便利です」…「それが802アドレスと同じ長さであるので」より重要に、単一の、そして、一定のIDの長さの選択は「効率的なパケット推進」を考慮します、ルータがIDに関する飛行中の決定を長さにする必要はないので([6]を見てください、156-157ページ)。 それでも、それがシステム識別子が操作する6つの八重奏であるという要件でない、-、プロトコル、-、長さがあるIDの使用のために、1〜8つの八重奏を許容します。
3. System Identifiers for TUBA/CLNP
3. チューバ/CLNPのためのシステム識別子
Autoconfiguration is a desirable feature for TUBA/CLNP, and is viewed by some as "essential if a network is to scale to a truly large size" [6].
自動構成は、TUBA/CLNPに、望ましい特徴であり、「不可欠ネットワークがaであるなら本当に大きいサイズに比例することになっているのを」[6]としていくつかによって見なされます。
For this purpose, and to accommodate communities who do not wish to use ethernet style addresses, a generalized format that satisfies the following criteria is desired:
この目的、イーサネットスタイルアドレスを使用したがっていない共同体を収容するために、以下の評価基準を満たす一般化された形式は望まれています:
o the format is compatible with installed end systems
complying to RFC 1237
o 形式はRFC1237に応じるインストールされたエンドシステムと互換性があります。
o the format accommodates 6 octet, globally unique system
identifiers that do not come from the ethernet address space
o 形式は6八重奏、イーサネットアドレス空間から来ないグローバルにユニークなシステム識別子に対応します。
o the format accommodates globally unique system identifiers
having lengths other than 6 octets
o 形式は6つの八重奏以外の長さを持っている独自のシステム識別子にグローバルに対応します。
The format and encoding of a globally unique system identifier that meets these requirements is illustrated in Figure 3:
これらの必要条件を満たすグローバルにユニークなシステム識別子の形式とコード化は図3で例証されます:
Octet 1 Octet 2 Octet 3 ... Octet LLL-1 Octet LLLL
+-----------+-----------+-----------+- ...-+-----------+-----------+
| xxxx TTGM | xxxx xxxx | xxxx xxxx | | xxxx xxxx | xxxx xxxx |
+-----------+-----------+-----------+- ...-+-----------+-----------+
八重奏1八重奏2八重奏3… 八重奏LLL-1八重奏LLLL+-----------+-----------+-----------+- ...-+-----------+-----------+ | xxxx TTGM| xxxx xxxx| xxxx xxxx| | xxxx xxxx| xxxx xxxx| +-----------+-----------+-----------+- ...-+-----------+-----------+
Figure 3. General format of the system identifier
図3。 システム識別子の一般形式
3.1 IEEE 802 Form of System Identifier
3.1 システム識別子のIEEE802フォーム
The format is compatible with globally assigned IEEE 802 addresses, since it carefully preserves the semantics of the global/local and group/individual bits. Octet 1 identifies 2 qualifier bits, G and M, and a subtype (TT) field whose semantics are associated with the qualifier bits. When a globally assigned IEEE 802 address is used as a system identifier, the qualifier bit M, representing the multicast/unicast bit, must always be set to zero to denote a unicast address. The qualifier bit G may be either 0 or 1, depending on
形式はグローバルに割り当てられたIEEE802アドレスと互換性があります、慎重にグローバルな/地方の、そして、グループ/個々のビットの意味論を保存するので。 八重奏1は2資格を与える人ビット、G、M、および意味論が資格を与える人ビットに関連している「副-タイプ」(TT)分野を特定します。 グローバルに割り当てられたIEEE802アドレスがシステム識別子として使用されるとき、マルチキャスト/ユニキャストビットを表して、資格を与える人ビットMをユニキャストアドレスを指示するようにゼロにいつも設定しなければなりません。 0か1、依存のどちらかがオンであったなら、資格を与える人ビットGはそうするかもしれません。
Piscitello [Page 4] RFC 1526 System Identifiers for TUBA September 1993
チューバ1993年9月のためのPiscitello[4ページ]RFC1526システム識別子
whether the individual address is globally or locally assigned. In these circumstances, the subtype bits are "don't care", and the system identifier shall be interpreted as a 48-bit, globally unique identifier assigned from the IEEE 802 committee (an ethernet address). The remaining bits in octet 1, together with octets 2 and 3 are the vendor code or OUI (organizationally unique identifier), as illustrated in Figure 4. The ID is encoded in IEEE 802 canonical form (low order bit of low order hex digit of leftmost octet is the first bit transmitted).
個々のアドレスはグローバルか局所的に割り当てられるのであるかどうか こういう事情ですから、「副-タイプ」ビットは「気にかけないでください」ということです、そして、48ビットの、そして、グローバルにユニークな識別子がIEEE802委員会から(イーサネットアドレス)を割り当てたので、システム識別子は解釈されるものとします。 八重奏1における残っているビットであり、八重奏と共に、2と3はベンダーコードであるかOUIが(組織的でユニークな識別子)です、図4で例証されるように。 IDはIEEE802標準形でコード化されます(一番左八重奏の下位の十六進法ケタの下位のビットは伝えられた最初のビットです)。
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 +-----------+-----------+-----------+-----------+-----------+-----------+ | VVVV VV00 | VVVV VVVV | VVVV VVVV | SSSS SSSS | SSSS SSSS | SSSS SSSS | +-----------+-----------+-----------+-----------+-----------+-----------+
八重奏1八重奏2八重奏3八重奏4八重奏5八重奏6+-----------+-----------+-----------+-----------+-----------+-----------+ | VVVV VV00| VVVV VVVV| VVVV VVVV| SSSS SSSS| SSSS SSSS| SSSS SSSS| +-----------+-----------+-----------+-----------+-----------+-----------+
|------------vendor code -----------|--------station code---------------|
|------------ベンダーコード-----------|--------ステーションコード---------------|
Figure 4. IEEE 802 form of system identifier
図4。 システム識別子のIEEE802フォーム
4. Embedded IP Address as System Identifier
4. システム識別子としての埋め込まれたIPアドレス
To distinguish 48-bit IEEE 802 addresses used as system identifiers from other forms of globally admininistered system identifiers, the qualifer bit M shall be set to 1. The correct interpretation of the M bit set to 1 should be, "this can't be an IEEE 802 multicast address, since use of multicast addresses is by convention illegal, so it must be some other form of system identifier". The subtype (TT) bits illustrated in Figure 3 thus become relevant.
他のフォームのグローバルにadmininisteredされたシステム識別子からのシステム識別子として使用される48ビットのIEEE802アドレスを区別するために、qualiferビットMは1に設定されるものとします。 1に設定されて、噛み付かれたMの正しい解釈は「これがIEEE802マルチキャストアドレスであるはずがありません、それがある他のフォームに関するシステム識別子であるに違いなくマルチキャストアドレスの使用がコンベンションの不法入国者であるので」ことであるべきです。 図3でこのようにして例証された「副-タイプ」(TT)ビットは関連するようになります。
When the subtype bits (TT) are set to a value of 0, the system identifier contains an embedded IP address. The remainder of the 48- bit system identifier is encoded as follows. The remaining nibble in octet 1 shall be set to zero. Octet 2 is reserved and shall be set to a pre-assigned value (see Figure 5). Octets 3 through 6 shall contain a valid IP address, assigned by IANA. Each octet of the IP address is encoded in binary, in internet canonical form, i.e., the leftmost bit of the network number first.
「副-タイプ」ビット(TT)が0の値に設定されるとき、システム識別子は埋め込まれたIPアドレスを含んでいます。 48の噛み付いているシステム識別子の残りは以下の通りコード化されます。 八重奏1における残っている少量がゼロに設定されるものとします。 八重奏2は、予約されていて、プレ割り当てられた値に設定されるものとします(図5を見てください)。 八重奏3〜6はIANAによって割り当てられた有効なIPアドレスを含むものとします。 IPアドレスの各八重奏は最初に、すなわち、バイナリー、インターネット標準形、ネットワーク・ナンバーの一番左ビットでコード化されます。
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 +-----------+-----------+-----------+-----------+-----------+-----------+ | 0000 0001 | 1010 1010 | aaaa aaaa | bbbb bbbb | cccc cccc | dddd dddd | +-----------+-----------+-----------+-----------+-----------+-----------+
八重奏1八重奏2八重奏3八重奏4八重奏5八重奏6+-----------+-----------+-----------+-----------+-----------+-----------+ | 0000 0001 | 1010 1010 | aaaa aaaa| bbbb bbbb| cccc cccc| dddd dddd| +-----------+-----------+-----------+-----------+-----------+-----------+
|-len&Type--|--reserved-|---------IP address----------------------------|
|-lenとタイプ--|--予約されます。|---------IPアドレス----------------------------|
Figure 5. Embedded IP address as system identifier
図5。 システム識別子としての埋め込まれたIPアドレス
Piscitello [Page 5] RFC 1526 System Identifiers for TUBA September 1993
チューバ1993年9月のためのPiscitello[5ページ]RFC1526システム識別子
As an example, the host "eve.bellcore.com = 128.96.90.55" could retain its IP address as a system identifier in a TUBA/CLNP network. The encoded ID is illustrated in Figure 6.
例、ホスト、「eve.bellcore.comが等しい、128.96、.90、0.55インチ、システム識別子としてTUBA/CLNPネットワークでIPアドレスを保有できた、」 コード化されたIDは図6で例証されます。
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 +-----------+-----------+-----------+-----------+-----------+-----------+ | 0000 0001 | 1010 1010 | 1000 0000 | 0110 0000 | 0101 1010 | 0011 0111 | +-----------+-----------+-----------+-----------+-----------+-----------+
八重奏1八重奏2八重奏3八重奏4八重奏5八重奏6+-----------+-----------+-----------+-----------+-----------+-----------+ | 0000 0001 | 1010 1010 | 1000 0000 | 0110 0000 | 0101 1010 | 0011 0111 | +-----------+-----------+-----------+-----------+-----------+-----------+
|-len&Type--|--reserved-|---------IP address----------------------------|
|-lenとタイプ--|--予約されます。|---------IPアドレス----------------------------|
Figure 6. Example of IP address encoded as ID
図6。 IDとしてコード化されたIPアドレスに関する例
H 2 "Other forms of System Identifiers"
H2「他の形式のSystem Identifiers」
To allow for the future definition of additional 6-octet system identifiers, the remaining subtype values are reserved.
追加6八重奏のシステム識別子の今後の定義を考慮するために、残っている「副-タイプ」値は予約されています。
It is also possible to identify system identifiers with lengths other than 6 octets. Communities who wish to use 8 octet identifiers (for example, embedded E.164 international numbers for the ISDN ERA) must use a GOSIP/ANSI DSP format that allows for the specification of 2 additional octets in the ID field, perhaps at the expense of the "Rsvd" fields; this document recommends that a separate Domain Format Indicator value be assigned for such purposes; i.e., a DFI value that is interpreted as saying, among other things, "the system identifier encoded in this DSP is 64-bits/8 octets. The resulting ANSI/GOSIP DSP formats under such circumstances are illustrated in Figure 7:
また、6つの八重奏以外の長さとシステム識別子を同一視するのも可能です。 8つの八重奏識別子(例えば、ISDN ERAの埋め込まれたE.164国際的な番号)を使用したがっている共同体はID分野で2つの追加八重奏の仕様を考慮するGOSIP/ANSI DSP形式を使用しなければなりません、恐らく"Rsvd"分野を犠牲にして。 このドキュメントは、別々のDomain Format Indicator値がそのような目的のために割り当てられることを勧めます。 すなわち、「このDSPでコード化されたシステム識別子は64ビットの/8八重奏です」と特に言いながら解釈されるDFI値。 結果として起こるANSI/GOSIP DSP形式は図7でこれでは例証されます:
Piscitello [Page 6] RFC 1526 System Identifiers for TUBA September 1993
チューバ1993年9月のためのPiscitello[6ページ]RFC1526システム識別子
______________
|<--_IDP_-->_|______________________________
|AFI_|__IDI__|____________<--_DSP_-->_______|
|_39_|__840__|DFI_|_ORG_|RD_|Area_|_ID_|Sel_|
octets |_1__|___2___|_1__|__3__|_2_|__2__|_8__|_1__|
______________ | <--_IDP_-->_|______________________________ |AFI_|__イディ__|____________<--_DSP_-->。_______| |_39_|__840__|DFI_|_ORG_|第_|領域_|_ID_|Sel_| 八重奏|_1__|___2___|_1__|__3__|_2_|__2__|_8__|_1__|
Figure 7a: ANSI NSAP address format for DCC=840, DFI=foo
図7a: DCC=840、DFI=fooであることのANSI NSAPアドレス形式
_______________
|<--__IDP_-->_|___________________________________
|AFI_|__IDI___|___________<--_DSP_-->____________|
|_47_|__0005__|DFI_|AA_|_RD_|Area_|ID_|Sel_|
octets |_1__|___2____|_1__|_3_|_2__|_2___|_8_|_1__|
_______________ | <--__IDP_-->_|___________________________________ |AFI_|__イディ___|___________<--_DSP_-->。____________| |_47_|__0005__|DFI_|AA_|_第_|領域_|ID_|Sel_| 八重奏|_1__|___2____|_1__|_3_|_2__|_2___|_8_|_1__|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administrative Authority
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
IDPの初期のドメイン部分AFI権威と初期の特定の形式IDの識別子IDシステム識別子SEL NSAP IDIドメイン識別子DSPドメイン部分DFI DSP形式ID AA職務権限経路ドメイン識別子領域領域第セレクタ
Figure 7b: GOSIP Version 2 NSAP structure, DFI=bar
図7b: GOSIPバージョン2NSAP構造、DFI=バー
Similar address engineering can be applied for those communities who wish to have shorter system identifiers; have another DFI assigned, and expand the reserved field.
より短いシステム識別子を持ちたがっている共同体に同様のアドレス工学を適用できます。 別のDFIを割り当てさせてください、そして、予約された分野を広げてください。
5. Conclusions
5. 結論
This proposal should debunk the "if it's 48-bits, it's gotta be an ethernet address" myth. It demonstrates how IP addresses may be encoded within the 48-bit system identifier field in a compatible fashion with IEEE 802 addresses, and offers guidelines for those who wish to use system identifiers other than those enumerated here.
この提案は「48ビットであるなら、イーサネットアドレスでなければなりません」という神話をすっぱぬかせるべきです。 それは、IPアドレスが48ビットのシステム識別子分野の中でIEEE802アドレスでコンパチブルファッションでどうコード化されるかもしれないかを示して、ここに列挙されたもの以外のシステム識別子を使用したがっている人のためにガイドラインを提供します。
Piscitello [Page 7] RFC 1526 System Identifiers for TUBA September 1993
チューバ1993年9月のためのPiscitello[7ページ]RFC1526システム識別子
6. References
6. 参照
[1] Callon, R., Gardner, E., and R. Colella, "Guidelines for OSI NSAP
Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, June
1991.
[1]Callon、R.、ガードナー、E.、およびR.Colella、「インターネットのオウシNSAP Allocationのためのガイドライン」、RFC1237、NIST、斜め継ぎ、12月(1991年6月)。
[2] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
Proposal for Internet Addressing and Routing", RFC 1347, DEC,
June 1992.
[2] Callon、R.、「より大きいのがあるTCPとUDPは(tuba)、インターネットアドレシングとルート設定のための簡単な提案を扱います」、RFC1347、1992年12月、6月。
[3] ISO, "Intradomain routing protocol for use in conjunction with
ISO 8473, Protocol for providing the OSI connectionless network
service", ISO 10589.
[3] ISO、「ISO8473に関連した使用のためのIntradomainルーティング・プロトコル、OSIを提供するのに、コネクションレスなプロトコルはサービスをネットワークでつなぎます」、ISO10589。
[4] ISO, End-system and intermediate-system routing protocol for use
in conjunction with ISO 8473, Protocol for providing the OSI
connectionless network service, ISO 9542.
[4] ISO、End-システム、および中間システムルーティングは使用のためにISO8473に関連して議定書を作ります、コネクションレスなネットワーク・サービス(ISO9542)をOSIに供給するためのプロトコル。
[5] ISO, "End-system and intermediate-system routing protocol for use
in conjunction with ISO 8473, Protocol for providing the OSI
connectionless network service. Amendment 1: Dynamic Discovery
of OSI NSAP Addresses End Systems", ISO 9542/DAM1.
[5] ISO、「エンドシステムと中間システムルーティングは使用のためにISO8473に関連して議定書を作ります、OSIのコネクションレスなネットワーク・サービスを提供するためのプロトコル。」 修正1: 「オウシNSAPのダイナミックな発見はエンドシステムを扱う」ISO9542/DAM1。
[6] Perlman, R., "Interconnections: Bridges and Routers", Addison-
Wesley Publishers, Reading, MA. 1992.
[6] パールマン、R.、「インタコネクト:」 アディソンウエスリー出版社の、そして、閲読している「ブリッジとルータ」、MA。 1992.
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. Author's Address
8. 作者のアドレス
David M. Piscitello Bell Communications Research NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701
Piscitelloベルコミュニケーションズ・リサーチNVC 1C322 331ニューマン春の道路赤が盛り土するデヴィッドM.、ニュージャージー 07701
EMail: dave@mail.bellcore.com
メール: dave@mail.bellcore.com
Piscitello [Page 8]
Piscitello[8ページ]
一覧
スポンサーリンク
