RFC1629 日本語訳
1629 Guidelines for OSI NSAP Allocation in the Internet. R. Colella,R. Callon, E. Gardner, Y. Rekhter. May 1994. (Format: TXT=131640 bytes) (Obsoletes RFC1237) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Colella
Request for Comments: 1629 NIST
Obsoletes: 1237 R. Callon
Category: Standards Track Wellfleet
E. Gardner
Mitre
Y. Rekhter
T.J. Watson Research Center, IBM Corp.
May 1994
Colellaがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1629NISTは以下を時代遅れにします。 1237年のR.Callonカテゴリ: 標準化過程Wellfleet E.ガードナー斜め継ぎY.Rekhter T.J.ワトソン研究所、IBM社の1994年5月
Guidelines for OSI NSAP Allocation in the Internet
インターネットのオウシNSAP Allocationのためのガイドライン
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
CLNP is currently being deployed in the Internet. This is useful to support OSI and DECnet(tm) traffic. In addition, CLNP has been proposed as a possible IPng candidate, to provide a long-term solution to IP address exhaustion. Required as part of the CLNP infrastructure are guidelines for network service access point (NSAP) address assignment. This paper provides guidelines for allocating NSAP addresses in the Internet.
CLNPは現在、インターネットで配備されています。 これは、OSIとDECnet(tm)交通を支持するために役に立ちます。 さらに、CLNPは、IPアドレス疲労困憊の長期的な解決法を提供するために可能なIPng候補として提案されました。 CLNPインフラストラクチャの一部として必要であるのは、ネットワークサービスアクセスポイント(NSAP)アドレス課題のためのガイドラインです。 この紙はインターネットにアドレスをNSAPに割り当てるためのガイドラインを提供します。
The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration.
この紙に提供されたガイドラインは、インターネットでのCLNPの初期の展開の基礎であり、CLNPルーティングのスケーリングへの援助、およびアドレス管理に非常に貴重であると判明しました。
Colella, Callon, Gardner & Rekhter [Page 1] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[1ページ]RFC1629NSAPガイドライン1994年5月
Table of Contents
目次
Section 1. Introduction ............................... 4
Section 2. Scope ...................................... 5
Section 3. Background ................................. 7
Section 3.1 OSI Routing Standards ..................... 7
Section 3.2 Overview of IS-IS (ISO/IEC 10589) ......... 8
Section 3.3 Overview of IDRP (ISO/IEC 10747) .......... 12
Section 3.3.1 Scaling Mechanisms in IDRP .............. 14
Section 3.4 Requirements of IS-IS and IDRP on NSAPs ... 15
Section 4. NSAPs and Routing .......................... 16
Section 4.1 Routing Data Abstraction .................. 16
Section 4.2 NSAP Administration and Efficiency ........ 19
Section 5. NSAP Administration and Routing in the In-
ternet ........................................... 21
Section 5.1 Administration at the Area ................ 23
Section 5.2 Administration at the Subscriber Routing
Domain ........................................... 24
Section 5.3 Administration at the Provider Routing
Domain ........................................... 24
Section 5.3.1 Direct Service Providers ................ 25
Section 5.3.2 Indirect Providers ...................... 26
Section 5.4 Multi-homed Routing Domains ............... 26
Section 5.5 Private Links ............................. 31
Section 5.6 Zero-Homed Routing Domains ................ 33
Section 5.7 Address Transition Issues ................. 33
Section 6. Recommendations ............................ 36
Section 6.1 Recommendations Specific to U.S. Parts of
the Internet ..................................... 37
Section 6.2 Recommendations Specific to European Parts
of the Internet .................................. 39
Section 6.2.1 General NSAP Structure .................. 40
Section 6.2.2 Structure of the Country Domain Part .... 40
Section 6.2.3 Structure of the Country Domain
Specific Part .................................... 41
Section 6.3 Recommendations Specific to Other Parts of
the Internet ..................................... 41
Section 6.4 Recommendations for Multi-Homed Routing
Domains .......................................... 41
Section 6.5 Recommendations for RDI and RDCI assign-
ment ............................................. 42
Section 7. Security Considerations .................... 42
Section 8. Authors' Addresses ......................... 43
Section 9. Acknowledgments ............................ 43
Section 10. References ................................ 44
Section A. Administration of NSAPs .................... 46
Section A.1 GOSIP Version 2 NSAPs .................... 47
Section A.1.1 Application for Administrative Authority
セクション1。 序論… 4 セクション2。 範囲… 5 セクション3。 バックグラウンド… 7 セクション3.1 OSIルート設定規格… 7が3.2概観を区分する、-、(ISO/IEC10589)… 8 セクション3.3 IDRP(ISO/IEC10747)の概観… 12 セクション3.3 .1 IDRPのスケーリングメカニズム… 14が3.4の要件を区分する、-、NSAPsの…上のIDRP 15 セクション4。 NSAPsとルート設定… 16 セクション4.1 ルート設定データ抽象化… 16 セクション4.2 NSAP政権と効率… 19 セクション5。 In- ternetのNSAP政権とルート設定… 21 セクション5.1 領域の政権… 23 セクション5.2 加入者経路ドメインの政権… 24 セクション5.3 プロバイダー経路ドメインの政権… 24 セクション5.3 .1 サービスプロバイダーを指示してください… 25 セクション5.3.2の間接的なプロバイダー… 26部5.4、マルチ、家へ帰り、経路ドメイン… 26 セクション5.5 個人的なリンク… 31部5.6、無、家へ帰り、経路ドメイン… 33 セクション5.7は変遷問題を記述します… 33 セクション6。 推薦… 36 セクション6.1 インターネットの米国の地域に特定の推薦… 37 セクション6.2 インターネットのヨーロッパの地域に特定の推薦… 39 セクション6.2 .1 一般NSAP構造… 40 セクション6.2 .2 国のドメイン部分の構造… 40 セクション6.2 .3 国のドメインの特定の部分の構造… 41 セクション6.3 インターネットの他の地域に特定の推薦… 41が6.4の推薦を区分する、マルチ、家へ帰り、経路ドメイン… 41 セクション6.5 RDIとRDCIのためのRecommendationsはmentを割り当てます… 42 セクション7。 セキュリティ問題… 42 セクション8。 作者のアドレス… 43 セクション9。 承認… 43 セクション10。 参照… 44 NSAPsのセクションA.運営… 46 セクションA.1 GOSIPバージョン2NSAPs… 47 職務権限のセクションA.1.1アプリケーション
Colella, Callon, Gardner & Rekhter [Page 2] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[2ページ]RFC1629NSAPガイドライン1994年5月
Identifiers ...................................... 48
Section A.1.2 Guidelines for NSAP Assignment ......... 50
Section A.2 Data Country Code NSAPs .................. 50
Section A.2.1 Application for Numeric Organization
Name ............................................. 51
Section A.3 Summary of Administrative Requirements .. 52
識別子… 48 NSAP課題のためのセクションA.1.2ガイドライン… 50 セクションA.2データ国名略号NSAPs… 50 数値組織名のセクションA.2.1アプリケーション… 管理要件の51セクションA.3概要。 52
Colella, Callon, Gardner & Rekhter [Page 3] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[3ページ]RFC1629NSAPガイドライン1994年5月
1. Introduction
1. 序論
The Internet is moving towards a multi-protocol environment that includes CLNP. To support CLNP in the Internet, an OSI lower layers infrastructure is required. This infrastructure comprises the connectionless network protocol (CLNP) [9] and supporting routing protocols. Also required as part of this infrastructure are guidelines for network service access point (NSAP) address assignment. This paper provides guidelines for allocating NSAP addresses in the Internet (the terms NSAP and NSAP address are used interchangeably throughout this paper in referring to NSAP addresses).
インターネットはCLNPを含んでいるマルチプロトコル環境に近づいています。 インターネットでCLNPを支持するために、OSI下層インフラストラクチャが必要です。 このインフラストラクチャは、コネクションレスなネットワーク・プロトコル(CLNP)[9]とルーティング・プロトコルをサポートするのを包括します。 また、このインフラストラクチャの一部として必要であるのは、ネットワークサービスアクセスポイント(NSAP)アドレス課題のためのガイドラインです。 この紙はインターネットにアドレスをNSAPに割り当てるためのガイドラインを提供します(アドレスという用語のNSAPとNSAPはこの紙中でNSAPアドレスを参照する際に互換性を持って使用されます)。
The guidelines presented in this document are quite similar to the guidelines that are proposed in the Internet for IP address allocation with CIDR (RFC 1519 [19]). The major difference between the two is the size of the addresses (4 octets for CIDR vs 20 octets for CLNP). The larger NSAP addresses allows considerably greater flexibility and scalability.
本書では提示されたガイドラインはCIDRとのIPアドレス配分のためにインターネットで提案されるガイドラインと全く同様です。(RFC1519[19])。 2の主要な違いはアドレス(CIDRのための4つの八重奏対CLNPのための20の八重奏)のサイズです。 より大きいNSAPアドレスはかなり大きい柔軟性とスケーラビリティを許容します。
The remainder of this paper is organized into five major sections and an appendix. Section 2 defines the boundaries of the problem addressed in this paper and Section 3 provides background information on OSI routing and the implications for NSAP addresses.
この紙の残りは5つの主要なセクションと付録に組織化されます。 セクション2はこの紙に記述された問題の限界を定義します、そして、セクション3はOSIルーティングと含意に関する基礎的な情報をNSAPアドレスに提供します。
Section 4 addresses the specific relationship between NSAP addresses and routing, especially with regard to hierarchical routing and data abstraction. This is followed in Section 5 with an application of these concepts to the Internet environment. Section 6 provides recommended guidelines for NSAP address allocation in the Internet. This includes recommendations for the U.S. and European parts of the Internet, as well as more general recommendations for any part of the Internet.
セクション4は特に階層型ルーティングとデータ抽象化に関してNSAPアドレスとルーティングとの特定の関係を記述します。 これはセクション5でこれらの概念のアプリケーションでインターネット環境に続かれています。 セクション6はインターネットでのNSAPアドレス配分のための勧告事項を提供します。 これはインターネットの米国の、そして、ヨーロッパの地域のための推薦を含んでいます、インターネットのどんな地域のための、より一般的な推薦と同様に。
The Appendix contains a compendium of useful information concerning NSAP structure and allocation authorities. The GOSIP Version 2 NSAP structure is discussed in detail and the structure for U.S.-based DCC (Data Country Code) NSAPs is described. Contact information for the registration authorities for GOSIP and DCC-based NSAPs in the U.S., the General Services Administration (GSA) and the American National Standards Institute (ANSI), respectively, is provided.
AppendixはNSAP構造と配分当局に関して役に立つ情報に関する概要を含んでいます。 詳細にGOSIPバージョン2NSAP構造について議論します、そして、米国ベースのDCC(データCountry Code)NSAPsのための構造は説明されます。 それぞれGOSIPのための登録局、米国のDCCベースのNSAPs、共通役務庁(GSA)、およびAmerican National Standards Institut(ANSI)のための問い合わせ先を提供します。
This document obsoletes RFC 1237. The changes from RFC 1237 are minor, and primarily editorial in nature. The descriptions of OSI routing standards contained in Section 3 have been updated to reflect the current status of the relevant standards, and a description of the OSI Interdomain Routing Protocol (IDRP) has been added. Recommendations specific to the European part of the Internet have
このドキュメントはRFC1237を時代遅れにします。 RFC1237からの変化は、小さい方であって、主として現実に編集です。 関連規格の現在の状態を反映するためにセクション3に含まれるOSIルーティング規格の記述をアップデートして、OSI Interdomainルート設定プロトコル(IDRP)の記述を加えました。 インターネットのヨーロッパの地域に特定の推薦はそうしました。
Colella, Callon, Gardner & Rekhter [Page 4] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[4ページ]RFC1629NSAPガイドライン1994年5月
been added in Section 6, along with recommendations for Routing Domain Identifiers and Routing Domain Confederation Identifiers needed for operation of IDRP.
セクション6では、ルート設定Domain Identifiersとルート設定Domain Confederation Identifiersのための推薦と共にIDRPの操作に必要であることで、加えられます。
2. Scope
2. 範囲
Control over the collection of hosts and the transmission and switching facilities that compose the networking resources of the global Internet is not homogeneous, but is distributed among multiple administrative authorities. For the purposes of this paper, the term network service provider (or just provider) is defined to be an organization that is in the business of providing datagram switching services to customers. Organizations that are *only* customers (i.e., that do not provide datagram services to other organizations) are called network service subscribers (or simply subscribers).
世界的なインターネットに関するネットワークリソースを構成するホストの収集、トランスミッション、および切り換え施設のコントロールは、均質ではありませんが、複数の職務権限の中に広げられます。 この紙の目的において、用語ネットワークサービスプロバイダー(または、まさしくプロバイダー)は、顧客に対するサービスをデータグラムの切り換えに提供するビジネスにはある組織になるように定義されます。 唯一の**顧客(すなわち、それは他の組織へのデータグラムサービスを提供しません)である組織はネットワーク・サービス加入者(または、単に加入者)と呼ばれます。
In the current Internet, subscribers (e.g., campus and corporate site networks) attach to providers (e.g., regionals, commercial providers, and government backbones) in only one or a small number of carefully controlled access points. For discussion of OSI NSAP allocation in this paper, providers are treated as composing a mesh having no fixed hierarchy. Addressing solutions which require substantial changes or constraints on the current topology are not considered in this paper.
現在のインターネットでは、加入者(例えば、キャンパスと法人のサイトネットワーク)は1だけのプロバイダー(例えば、地方版、商業プロバイダー、および政府背骨)か慎重に制御されたアクセスポイントの少ない数に付きます。 この紙におけるOSI NSAP配分の議論において、プロバイダーは固定階層構造を全く持っていないメッシュを構成するとして扱われます。 現在のトポロジーで大きな変化か規制を必要とするアドレシング解決がこの紙で考えられません。
There are two aspects of interest when discussing OSI NSAP allocation within the Internet. The first is the set of administrative requirements for obtaining and allocating NSAP addresses; the second is the technical aspect of such assignments, having largely to do with routing, both within a routing domain (intra-domain routing) and between routing domains (inter-domain routing). This paper focuses on the technical issues.
インターネットの中でOSI NSAP配分について議論するとき、興味がある2つの局面があります。 1番目は入手とアドレスをNSAPに割り当てるための管理要件のセットです。 2番目はそのような課題の技術的側面です、ルーティングと主に関係があるので、経路ドメイン(イントラドメインルーティング)と経路ドメイン(相互ドメインルーティング)の間の両方。 この紙は専門的な問題に焦点を合わせます。
The technical issues in NSAP allocation are mainly related to routing. This paper assumes that CLNP will be widely deployed in the Internet, and that the routing of CLNP traffic will normally be based on the OSI end-system to intermediate system routing protocol (ES-IS) [10], intra-domain IS-IS protocol [14], and inter-domain routing protocol (IDRP) [16]. It is expected that in the future the OSI routing architecture will be enhanced to include support for multicast, resource reservation, and other advanced services. The requirements for addressing for these future services is outside of the scope of this document.
NSAP配分における専門的な問題はルーティングに主に関連します。 この紙がCLNPがインターネットで広く配備されて、通常、CLNP交通のルーティングが中間システムルーティング・プロトコルへのOSIエンドシステムに基づくと仮定する、(ES存在、)、[10]、イントラドメイン、-、[14]、および相互ドメインルーティング・プロトコル(IDRP)[16]について議定書の中で述べてください。 将来OSIルーティング構造がマルチキャストのサポート、資源予約、および他の高度なサービスを含むように高められると予想されます。 これらの今後のサービスのためのアドレシングのための要件がこのドキュメントの範囲の外にあります。
The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and to address administration.
この紙に提供されたガイドラインは、インターネットでのCLNPの初期の展開の基礎であり、CLNPルーティングのスケーリングへの援助と、アドレス管理に非常に貴重であると判明しました。
Colella, Callon, Gardner & Rekhter [Page 5] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[5ページ]RFC1629NSAPガイドライン1994年5月
The guidelines in this paper are oriented primarily toward the large-scale division of NSAP address allocation in the Internet. Topics covered include:
この紙のガイドラインはインターネットで主としてNSAPアドレス配分の大規模な分割に向かって向けられます。 カバーされた話題は:
* Arrangement of parts of the NSAP for efficient operation of
the IS-IS routing protocol;
* 効率的な操作のためのNSAPの部分のアレンジメント、-、ルーティング・プロトコル。
* Benefits of some topological information in NSAPs to reduce
routing protocol overhead, and specifically the overhead on
inter-domain routing (IDRP);
* ルーティングを減少させるNSAPsの何らかの位相的な情報の利益は相互ドメインルーティング(IDRP)でオーバーヘッド、および明確にオーバーヘッドについて議定書の中で述べます。
* The anticipated need for additional levels of hierarchy in
Internet addressing to support network growth and use of
the Routing Domain Confederation mechanism of IDRP to provide
support for additional levels of hierarchy;
* インターネットアドレシングによる追加レベルの階層構造が追加レベルの階層構造のサポートを提供するためにIDRPのルート設定Domain Confederationメカニズムのネットワークの成長と使用を支持する予期された必要性。
* The recommended mapping between Internet topological entities
(i.e., service providers and service subscribers) and OSI
addressing and routing components, such as areas, domains and
confederations;
* インターネットの位相的な実体(すなわち、サービスプロバイダーとサービス加入者)とOSIアドレシングの間のお勧めのマッピングと領域や、ドメインや同盟者などのルーティングコンポーネント。
* The recommended division of NSAP address assignment authority
among service providers and service subscribers;
* NSAPのお勧めの分割はサービスプロバイダーの中の課題権威とサービス加入者に演説します。
* Background information on administrative procedures for
registration of administrative authorities immediately
below the national level (GOSIP administrative authorities
and ANSI organization identifiers); and,
* 全国レベル(GOSIP職務権限とANSI組織識別子)のすぐ下における職務権限の登録のための行政手続に関する基礎的な情報。 そして
* Choice of the high-order portion of the NSAP in subscriber
routing domains that are connected to more than one service
provider.
* 1つ以上のサービスプロバイダーにつなげられる加入者経路ドメインでのNSAPの高位一部の選択。
It is noted that there are other aspects of NSAP allocation, both technical and administrative, that are not covered in this paper. Topics not covered or mentioned only superficially include:
この紙でカバーされていない技術的で管理の両方のNSAP配分の他の局面があることに注意されます。 表面的にカバーされなかったか、または言及されなかった話題は:だけ
* Identification of specific administrative domains in the
Internet;
* インターネットでの特定の管理ドメインの識別。
* Policy or mechanisms for making registered information known
to third parties (such as the entity to which a specific NSAP
or a portion of the NSAP address space has been allocated);
* 第三者(特定のNSAPかNSAPアドレス空間の部分が割り当てられた実体などの)に登録された情報を明らかにするための方針かメカニズム。
Colella, Callon, Gardner & Rekhter [Page 6] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[6ページ]RFC1629NSAPガイドライン1994年5月
* How a routing domain (especially a site) should organize its
internal topology of areas or allocate portions of its NSAP
address space; the relationship between topology and addresses
is discussed, but the method of deciding on a particular topology
or internal addressing plan is not; and,
* 経路ドメイン(特にサイト)は、領域の内部のトポロジーを組織化するべきであるか、またはどうNSAPアドレス空間の部分を割り当てるべきであるか。 トポロジーとアドレスとの関係について議論しますが、特定のトポロジーか内部のアドレシングプランを決める方法は議論するというわけではありません。 そして
* Procedures for assigning the System Identifier (ID) portion of
the NSAP. A method for assignment of System IDs is presented
in [18].
* NSAPのSystem Identifier(ID)部分を割り当てるための手順。 System IDの課題のための方法は[18]に提示されます。
3. Background
3. バックグラウンド
Some background information is provided in this section that is helpful in understanding the issues involved in NSAP allocation. A brief discussion of OSI routing is provided, followed by a review of the intra-domain and inter-domain protocols in sufficient detail to understand the issues involved in NSAP allocation. Finally, the specific constraints that the routing protocols place on NSAPs are listed.
このNSAP配分にかかわる問題を理解する際に役立っているセクションに何らかの基礎的な情報を提供します。 OSIルーティングの簡潔な議論を提供します、NSAP配分にかかわる問題は理解できるくらいの詳細における、イントラドメインと相互ドメインプロトコルのレビューがあとに続いていて。 NSAPsの上のルーティング・プロトコル場所が記載されているという最終的に特定の規制。
3.1. OSI Routing Standards
3.1. OSIルート設定規格
OSI partitions the routing problem into three parts:
OSIはルーティング問題を3つの部品に仕切ります:
* routing exchanges between hosts (a.k.a., end systems or ESs) and
routers (a.k.a., intermediate systems or ISs) (ES-IS);
* ルーティングがホスト(通称、システムかESsを終わらせてください)とルータの間で(通称中間システムかISs)を交換する、(ES存在、)、。
* routing exchanges between routers in the same routing domain
(intra-domain IS-IS); and,
* ルーティングが同じ経路ドメインのルータの間で交換する、(イントラドメイン、-、)、。 そして
* routing among routing domains (inter-domain IS-IS).
* 経路ドメインの中のルーティング、(相互ドメイン、-、)
ES-IS (international standard ISO 9542) advanced to international standard (IS) status within ISO in 1987. Intra-domain IS-IS advanced to IS status within ISO in 1992. Inter-Domain Routing Protocol (IDRP) advanced to IS status within ISO in October 1993. CLNP, ES- IS, and IS-IS are all widely available in vendor products, and have been deployed in the Internet for several years. IDRP is currently being implemented in vendor products.
ES存在、(国際的な標準のISO9542)は1987年にISOの中で世界規格(ある)状態に達しました。 イントラドメイン、-、達せられているのは、1992年のISOの中の状態です。 達せられる相互Domainルート設定プロトコル(IDRP)は1993年10月のISOの中の状態です。 そして、CLNP、ESがそうである、-、メーカー製品の中で広くすべて利用可能であり、数年間インターネットで配備されています。 IDRPは現在、メーカー製品の中で実行されています。
This paper examines the technical implications of NSAP assignment under the assumption that ES-IS, intra-domain IS-IS, and IDRP routing are deployed to support CLNP.
この論文が仮定でNSAP課題の技術的な含意を調べる、それ、ES存在、イントラドメイン、-、IDRPルーティングは、CLNPを支持するために配備されます。
Colella, Callon, Gardner & Rekhter [Page 7] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[7ページ]RFC1629NSAPガイドライン1994年5月
3.2. Overview of ISIS (ISO/IEC 10589)
3.2. イシスの概観(ISO/IEC10589)
The IS-IS intra-domain routing protocol, ISO/IEC 10589, provides routing for OSI environments. In particular, IS-IS is designed to work in conjunction with CLNP, ES-IS, and IDRP. This section briefly describes the manner in which IS-IS operates.
-、イントラドメインルーティング・プロトコル(ISO/IEC10589)はOSI環境にルーティングを提供します。 特に、-、CLNPに関連して働くように設計されている、ES存在、そして、IDRP。 このセクションが簡潔に方法を説明する、どれ、-、作動するか。
In IS-IS, the internetwork is partitioned into routing domains. A routing domain is a collection of ESs and ISs that operate common routing protocols and are under the control of a single administration (throughout this paper, "domain" and "routing domain" are used interchangeably). Typically, a routing domain may consist of a corporate network, a university campus network, a regional network, a backbone, or a similar contiguous network under control of a single administrative organization. The boundaries of routing domains are defined by network management by setting some links to be exterior, or inter-domain, links. If a link is marked as exterior, no intra-domain IS-IS routing messages are sent on that link.
中、-、インターネットワークは経路ドメインに仕切られます。 経路ドメインは一般的なルーティング・プロトコルを操作して、ただ一つの管理のコントロールの下にあるESsとISsの収集(この紙中では、「ドメイン」と「経路ドメイン」は互換性を持って使用される)です。 通常、経路ドメインはただ一つの管理編成で制御された企業ネットワーク、大学構内ネットワーク、地域ネットワーク、背骨、または同様の隣接のネットワークから成るかもしれません。 経路ドメインの境界はいくつかのリンクに外であるように設定するのによるネットワークマネージメント、または相互ドメイン、リンクによって定義されます。 リンクが外部、どんなイントラドメインとしても示されない、-、そのリンクにルーティング・メッセージを送ります。
IS-IS routing makes use of two-level hierarchical routing. A routing domain is subdivided into areas (also known as level 1 subdomains). Level 1 routers know the topology in their area, including all routers and hosts. However, level 1 routers do not know the identity of routers or destinations outside of their area. Level 1 routers forward all traffic for destinations outside of their area to a level 2 router within their area.
-、ルーティングは2レベルの階層型ルーティングを利用します。 経路ドメインは領域(また、レベル1 サブドメインとして、知られている)に分筆されます。 レベル1 ルータはすべてのルータとホストを含むそれらの領域でトポロジーを知っています。 しかしながら、レベル1 ルータはそれらの領域の外でルータか目的地のアイデンティティを知りません。 レベル1 ルータはそれらの領域の中の平らな2ルータへのそれらの領域の外に目的地のためのすべての交通を送ります。
Similarly, level 2 routers know the level 2 topology and know which addresses are reachable via each level 2 router. The set of all level 2 routers in a routing domain are known as the level 2 subdomain, which can be thought of as a backbone for interconnecting the areas. Level 2 routers do not need to know the topology within any level 1 area, except to the extent that a level 2 router may also be a level 1 router within a single area. Only level 2 routers can exchange data packets or routing information directly with routers located outside of their routing domain.
同様に、レベル2 ルータは、レベル2トポロジーを知っていて、どのアドレスにそれぞれの平らな2ルータで届いているかを知っています。 平らな2サブドメインとして経路ドメインにおける、レベル2 ルータのセットを知っています。(領域とインタコネクトするための背骨としてそれを考えることができます)。 レベル2 ルータは平らなどんな1つの領域の中でもトポロジーを知る必要はありません、また、平らな2ルータがただ一つの領域の中の平らな1つのルータであるかもしれないという範囲を除いて。 唯一のレベル2 ルータは直接それらの経路ドメインの外に位置したルータとデータ・パケットかルーティング情報を交換できます。
NSAP addresses provide a flexible, variable length addressing format, which allows for multi-level hierarchical address assignment. These addresses provide the flexibility needed to solve two critical problems simultaneously: (i) How to administer a worldwide address space; and (ii) How to assign addresses in a manner which makes routing scale well in a worldwide Internet.
NSAPアドレスはフレキシブルで、可変な長さのアドレス指定形式を提供します。(それは、マルチレベルの階層的なアドレス課題を考慮します)。 これらのアドレスは同時に2つの重大問題を解決するのに必要である柔軟性を提供します: (i) どう世界的なアドレス空間を管理するか。 そして、ルーティングが上手に世界的なインターネットを計量する方法でアドレスを割り当てる(ii)方法。
As illustrated in Figure 1, ISO addresses are subdivided into the Initial Domain Part (IDP) and the Domain Specific Part (DSP). The IDP is the part which is standardized by ISO, and specifies the format and authority responsible for assigning the rest of the
図1で例証されるように、ISOアドレスはInitial Domain Part(IDP)とDomain Specific Part(DSP)に細分されます。 IDPはISOによって標準化される部分であり、残りを割り当てるのに原因となる形式と権威を指定します。
Colella, Callon, Gardner & Rekhter [Page 8] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[8ページ]RFC1629NSAPガイドライン1994年5月
address. The DSP is assigned by whatever addressing authority is specified by the IDP (see Appendix A for more discussion on the top level NSAP addressing authorities). It is expected that the authority specified by the IDP may further sub-divide the DSP, and may assign sub-authorities responsible for parts of the DSP.
アドレス。 DSPはIDP(先端についての、より多くの議論のためのAppendix Aが当局に演説するNSAPを平らにするのを見る)によって指定されるどんなアドレシング権威によっても割り当てられます。 IDPによって指定された権威がさらにDSPを細分して、DSPの部分に責任があるサブ当局を選任するかもしれないと予想されます。
For routing purposes, ISO addresses are subdivided by IS-IS into the area address, the system identifier (ID), and the NSAP selector (SEL). The area address identifies both the routing domain and the area within the routing domain. Generally, the area address corresponds to the IDP plus a high-order part of the DSP (HO-DSP).
ルーティング目的、アドレスが細分されるISO、-、領域アドレス、システム識別子(ID)、およびNSAPセレクタ(SEL)に。 領域アドレスは経路ドメインの中で経路ドメインと領域の両方を特定します。 一般に、領域アドレスはIDPとDSP(HO-DSP)の高位部分に一致しています。
<----IDP---> <----------------------DSP---------------------------->
<-----------HO-DSP------------>
+-----+-----+-------------------------------+--------------+-------+
| AFI | IDI |Contents assigned by authority identified in IDI field|
+-----+-----+-------------------------------+--------------+-------+
<----------------Area Address--------------> <-----ID-----> <-SEL->
<。----IDP---><。----------------------DSP----------------------------><。-----------おーい、-、DSP------------>+-----+-----+-------------------------------+--------------+-------+ | AFI| イディ|IDI分野で特定された権威によって割り当てられたコンテンツ| +-----+-----+-------------------------------+--------------+-------+ <。----------------領域アドレス--------------><。-----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 Hierarchical Address Structure.
図1: OSIの階層的なアドレス構造。
The ID field may be from one to eight octets in length, but must have a single known length in any particular routing domain. Each router is configured to know what length is used in its domain. The SEL field is always one octet in length. Each router is therefore able to identify the ID and SEL fields as a known number of trailing octets of the NSAP address. The area address can be identified as the remainder of the address (after truncation of the ID and SEL fields). It is therefore not necessary for the area address to have any particular length -- the length of the area address could vary between different area addresses in a given routing domain.
ID分野は、長さにおける1〜8つの八重奏まであるかもしれませんが、どんな特定の経路ドメインにもただ一つの知られている長さを持たなければなりません。 各ルータは、どんな長さがドメインで使用されるかを知るために構成されます。 いつもSEL分野は長さが1つの八重奏です。 したがって、それぞれのルータは、IDとSEL分野がNSAPアドレスの引きずっている八重奏の既知数であると認識できます。 アドレス(IDとSEL分野のトランケーションの後の)の残りとして領域アドレスを特定できます。 したがって、領域アドレスにはどんな特定の長さもあるのは必要ではありません--領域アドレスの長さが与えられた経路ドメインの異なった領域アドレスの間で異なることができました。
Usually, all nodes in an area have the same area address. However, sometimes an area might have multiple addresses. Motivations for allowing this are several:
通常、領域のすべてのノードには、同じ領域アドレスがあります。 しかしながら、領域には、時々、複数のアドレスがあるかもしれません。 これを許容することに関する動機は数個です:
Colella, Callon, Gardner & Rekhter [Page 9] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[9ページ]RFC1629NSAPガイドライン1994年5月
* It might be desirable to change the address of an area. The most
graceful way of changing an area address from A to B is to first
allow it to have both addresses A and B, and then after all nodes
in the area have been modified to recognize both addresses, one by
one the nodes can be modified to forget address A.
* 領域のアドレスを変えるのは望ましいかもしれません。 領域アドレスをAからBに変える最も優雅な方法が最初にそれにはアドレスAとBの両方があるのを許容することであり、そして、その領域のすべてのノードが両方のアドレスを認識するように変更された後にひとつずつ、アドレスAを忘れるようにノードは変更できます。
* It might be desirable to merge areas A and B into one area. The
method for accomplishing this is to, one by one, add knowledge of
address B into the A partition, and similarly add knowledge of
address A into the B partition.
* 領域AとBを1つの領域に合併するのは望ましいかもしれません。 これを達成するための方法は、アドレスBに関する知識をAパーティションにひとつずつ加えて、同様にアドレスAに関する知識をBパーティションに加えることです。
* It might be desirable to partition an area C into two areas, A and
B (where A might equal C, in which case this example becomes one
of removing a portion of an area). This would be accomplished by
first introducing knowledge of address A into the appropriate
nodes (those destined to become area A), and knowledge of address
B into the appropriate nodes, and then one by one removing
knowledge of address C.
* AとB、領域Cを2つの領域に仕切るのは望ましいかもしれません(AがCと等しいかもしれなくその場合そこでこの例は領域の部分を取り除く1つになります)。 これは、適切なノード(領域Aになるように運命づけられたもの)へのアドレスA、およびアドレスBに関する知識について最初に知識を紹介することによって適切なノードに達成されて、次に、アドレスCに関する知識をひとつずつ取り除いているでしょう。
Since the addressing explicitly identifies the area, it is very easy for level 1 routers to identify packets going to destinations outside of their area, which need to be forwarded to level 2 routers. Thus, in IS-IS routers perform as follows:
アドレシングが明らかに領域を特定するので、レベル1 ルータがそれらの領域の外に目的地に行くパケットを特定するのは、非常に簡単です。(パケットはレベル2 ルータに送られる必要があります)。 その結果、中、-、ルータは以下の通り働きます:
* Level 1 intermediate systems route within an area based on the ID
portion of the ISO address. Level 1 routers recognize, based on the
destination address in a packet, whether the destination is within
the area. If so, they route towards the destination. If not, they
route to the nearest level 2 router.
* レベル1 領域の中の中間システムルートはISOアドレスのID部分を基礎づけました。 領域の中に目的地があるか否かに関係なく、ルータがパケットの送付先アドレスに基づいて認識する1を平らにしてください。 そうだとすれば、彼らは目的地に向かって発送します。 そうでなければ、彼らは2ルータを最も近いレベルに発送します。
* Level 2 intermediate systems route based on address prefixes,
preferring the longest matching prefix, and preferring internal
routes over external routes. They route towards areas, without
regard to the internal structure of an area; or towards level 2
routers on the routing domain boundary that have advertised external
address prefixes into the level 2 subdomain. A level 2 router may
also be operating as a level 1 router in one area.
* レベル2 中間システムはアドレスに基づいて接頭語を発送します、最も長い合っている接頭語を好んで、外部経路より内部のルートを好んで。 それら、領域の内部の構造への尊敬のない領域に向かったルート。 または、レベル2に向かって、ルーティングドメイン境界の外部であることの形で広告を出したルータは平らな2サブドメインへの接頭語を記述します。 また、A級試験2ルータはレベルとして1つの領域の1つのルータを操作しているかもしれません。
A level 1 router will have the area portion of its address manually configured. It will refuse to become a neighbor with a router whose area addresses do not overlap its own area addresses. However, if a level 1 router has area addresses A, B, and C, and a neighbor has area addresses B and D, then the level 1 IS will accept the other IS as a level 1 neighbor.
A級試験1ルータで、手動でアドレスの領域の部分を構成するでしょう。 それは、領域アドレスがそれ自身の領域アドレスを重ね合わせないルータで隣人になるのを拒否するでしょう。 B、C、および隣人には平らな1つのルータに領域アドレスAがあるなら領域アドレスBとDがあり、次に、レベル1がどのように受け入れるということであっても、平らな1人の隣人としてもう片方があります。
A level 2 router will accept another level 2 router as a neighbor, regardless of area address. However, if the area addresses do not overlap, the link would be considered by both routers to be level 2
A級試験2ルータは領域アドレスにかかわらず隣人として別の平らな2ルータを認めるでしょう。 しかしながら、領域アドレスが重ならないなら、リンクは両方のルータによってレベル2であると考えられるでしょう。
Colella, Callon, Gardner & Rekhter [Page 10] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[10ページ]RFC1629NSAPガイドライン1994年5月
only, and only level 2 routing packets would flow on the link. External links (i.e., to other routing domains) must be between level 2 routers in different routing domains.
唯一、および唯一のレベル2 ルーティングパケットはリンクの上に流れるでしょう。 レベル2 異なった経路ドメインのルータの間には、外部のリンク(すなわち、他の経路ドメインへの)があるに違いありません。
IS-IS provides an optional partition repair function. If a level 1 area becomes partitioned, this function, if implemented, allows the partition to be repaired via use of level 2 routes.
-、任意のパーティション修理機能を提供します。 平らな1つの領域が仕切られるようになるなら、実行されるなら、この機能は、パーティションがレベル2 ルートの使用で修理されるのを許容します。
IS-IS requires that the set of level 2 routers be connected. Should the level 2 backbone become partitioned, there is no provision for use of level 1 links to repair a level 2 partition.
-、レベル2 ルータのセットが接続されるのが必要です。 平らな2背骨が仕切られるようになるなら、レベル1 レベル2が仕切る修理へのリンクの使用への支給が全くありません。
Occasionally a single level 2 router may lose connectivity to the level 2 backbone. In this case the level 2 router will indicate in its level 1 routing packets that it is not "attached", thereby allowing level 1 routers in the area to route traffic for outside of the area to a different level 2 router. Level 1 routers therefore route traffic to destinations outside of their area only to level 2 routers which indicate in their level 1 routing packets that they are "attached".
時折、ただ一つの平らな2ルータは平らな2背骨に接続性を失うかもしれません。 この場合、平らな2ルータは、レベル1でそれがパケットですが、掘るのが「付いたこと」を示すでしょう、その結果、レベル1 その領域のルータが異なった平らな2ルータに領域の外部のための交通を発送するのを許容します。 レベル1 したがって、ルータはそれらの領域の外で交通を目的地に発送しますが、それらがパケットですが、それらのレベル1でルーティングを示す「付けている」2つのルータを平らにします。
A host may autoconfigure the area portion of its address by extracting the area portion of a neighboring router's address. If this is the case, then a host will always accept a router as a neighbor. Since the standard does not specify that the host *must* autoconfigure its area address, a host may be pre-configured with an area address.
ホストは、隣接しているルータのアドレスの領域の部分を抽出することによって、アドレスの領域の部分を自動構成するかもしれません。 これがそうであるなら、ホストは隣人としていつもルータを認めるでしょう。 *規格が、ホスト*がそうしなければならないと指定しないので、領域アドレス、ホストが領域アドレスであらかじめ設定されるかもしれないのを自動構成してください。
Special treatment is necessary for broadcast subnetworks, such as LANs. This solves two sets of issues: (i) In the absence of special treatment, each router on the subnetwork would announce a link to every other router on the subnetwork, resulting in O(n-squared) links reported; (ii) Again, in the absence of special treatment, each router on the LAN would report the same identical list of end systems on the LAN, resulting in substantial duplication.
特別な処理がLANなどの放送サブネットワークに必要です。 これは2セットの問題を解決します: (i) 特別な処理がないとき、サブネットワークの上の各ルータはサブネットワークの上で他のあらゆるルータへのリンクを発表するでしょう、とO(nで二乗される)のリンクへの結果になるのは報告しました。 (ii) 一方、特別な処理がないときLANに関する各ルータはLANに関してエンドシステムの同じ同じリストを報告するでしょう、かなりの複製をもたらして。
These problems are avoided by use of a "pseudonode", which represents the LAN. Each router on the LAN reports that it has a link to the pseudonode (rather than reporting a link to every other router on the LAN). One of the routers on the LAN is elected "designated router". The designated router then sends out a Link State Packet (LSP) on behalf of the pseudonode, reporting links to all of the routers on the LAN. This reduces the potential n-squared links to n links. In addition, only the pseudonode LSP includes the list of end systems on the LAN, thereby eliminating the potential duplication.
これらの問題はLANを表す"pseudonode"の使用で避けられます。 LANに関する各ルータは、pseudonode(LANに関して他のあらゆるルータにリンクを報告するよりむしろ)にリンクを持っていると報告します。 LANのルータの1つは「代表ルータ」に選出されます。 代表ルータは次に、pseudonodeを代表してLink州Packet(LSP)を出します、LANに関してルータのすべてへのリンクを報告して。 これはnリンクへの潜在的nで二乗されたリンクを減少させます。 さらに、pseudonode LSPだけがLANのエンドシステムのリストを含んで、その結果、潜在的複製を排除します。
Colella, Callon, Gardner & Rekhter [Page 11] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[11ページ]RFC1629NSAPガイドライン1994年5月
The IS-IS provides for optional Quality of Service (QOS) routing, based on throughput (the default metric), delay, expense, or residual error probability.
-、スループットに基づいてService(QOS)ルーティングの任意のQualityに備える、(メートル法でデフォルトとしてください、)、遅れ、費用、または見逃し誤り確率。
IS-IS has a provision for authentication information to be carried in all IS-IS PDUs. Currently the only form of authentication which is defined is a simple password. A password may be associated with each link, each area, and with the level 2 subdomain. A router not in possession of the appropriate password(s) is prohibited from participating in the corresponding function (i.e., may not initialize a link, be a member of the area, or a member of the level 2 subdomain, respectively).
-、認証情報がすべてで運ばれる支給を持っている、-、PDUs。 現在の、定義される唯一の形式の認証は簡単なパスワードです。 パスワードは各リンク、各領域と平らな2サブドメインに関連しているかもしれません。 ルータは適切なパスワードの所有物で対応する機能(すなわち、それぞれリンクを初期化しないか、領域のメンバー、または平らな2サブドメインのメンバーであるかもしれない)に参加するのが禁止されていません。
Procedures are provided to allow graceful migration of passwords without disrupting operation of the routing protocol. The authentication functions are extensible so that a stronger, cryptographically-based security scheme may be added in an upwardly compatible fashion at a future date.
ルーティング・プロトコルの操作を中断しないでパスワードの優雅な移動を許すために手順を提供します。 認証機能が広げることができるそう、そのa、 より強い、暗号で、ベース、セキュリティ体系は上向きにコンパチブルファッションで後日に加えられるかもしれません。
3.3. Overview of IDRP (ISO/IEC 10747)
3.3. IDRPの概観(ISO/IEC10747)
The Inter-Domain Routing Protocol (IDRP, ISO/IEC 10747), developed in ISO, provides routing for OSI environments. In particular, IDRP is designed to work in conjuction with CLNP, ES-IS, and IS-IS. This section briefly describes the manner in which IDRP operates.
ISOで開発されたInter-ドメインルート設定プロトコル(IDRP、ISO/IEC10747)はOSI環境にルーティングを提供します。 特に、IDRPがCLNPと共にconjuctionで働くように設計されている、ES存在、- このセクションは簡潔に、IDRPが作動する方法を説明します。
Consistent with the OSI Routing Framework [13], in IDRP the internetwork is partitioned into routing domains. IDRP places no restrictions on the inter-domain topology. A router that participates in IDRP is called a Boundary Intermediate System (BIS). Routing domains that participate in IDRP are not allowed to overlap - a BIS may belong to only one domain.
OSIルート設定Framework[13]と一致していて、IDRPでは、インターネットワークは経路ドメインに仕切られます。 IDRPは相互ドメイントポロジーに関して制限を全く課しません。 IDRPに参加するルータはBoundary Intermediate System(BIS)と呼ばれます。 IDRPに参加する経路ドメインは重なることができません--BISは1つのドメインだけに属すかもしれません。
A pair of BISs are called external neighbors if these BISs belong to different domains but share a common subnetwork (i.e., a BIS can reach its external neighbor in a single network layer hop). Two domains are said to be adjacent if they have BISs that are external neighbors of each other. A pair of BISs are called internal neighbors if these BISs belong to the same domain. In contrast with external neighbors, internal neighbors don't have to share a common subnetwork -- IDRP assumes that a BIS should be able to exchange Network Protocol Date Units (NPDUs) with any of its internal neighbors by relying solely on intra-domain routing procedures.
これらのBISsが異なったドメインに属すなら、1組のBISsは外部の隣人と呼ばれますが、一般的なサブネットワークを共有してください(すなわち、BISは単一のネットワーク層ホップで外部の隣人に届くことができます)。 互いの外部の隣接物であるBISsを持っているなら、2つのドメインが隣接していると言われます。 これらのBISsが同じドメインに属すなら、1組のBISsは内部の隣人と呼ばれます。 外部の隣人と比べて、内部の隣人は一般的なサブネットワークを共有する必要はありません--IDRPは、BISが唯一イントラドメインルーティング手順を当てにすることによってNetworkプロトコルDate Units(NPDUs)を内部の隣人のどれかと交換できるべきであると仮定します。
IDRP governs the exchange of routing information between a pair of neighbors, either external or internal. IDRP is self-contained with respect to the exchange of information between external neighbors. Exchange of information between internal neighbors relies on
IDRPは1組の外部の、または、内部の隣人の間のルーティング情報の交換を治めます。 IDRPは外部の隣人の間の情報交換に関して自己充足的です。 内部の間の隣人が当てにする情報交換
Colella, Callon, Gardner & Rekhter [Page 12] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[12ページ]RFC1629NSAPガイドライン1994年5月
additional support provided by intra-domain routing (unless internal neighbors share a common subnetwork).
イントラドメインルーティング(内部の隣人が一般的なサブネットワークを共有しないなら)で提供された追加的支援。
To facilitate routing information aggregation/abstraction, IDRP allows grouping of a set of connected domains into a Routing Domain Confederation (RDC). A given domain may belong to more than one RDC. There are no restrictions on how many RDCs a given domain may simultaneously belong to, and no preconditions on how RDCs should be formed -- RDCs may be either nested, or disjoint, or may overlap. One RDC is nested within another RDC if all members (RDs) of the former are also members of the latter, but not vice versa. Two RDCs overlap if they have members in common and also each has members that are not in the other. Two RDCs are disjoint if they have no members in common.
情報集合/抽象化を発送するのを容易にするために、IDRPは1セットの接続ドメインをルート設定Domain Confederation(RDC)に分類させます。 与えられたドメインは1RDCに属すかもしれません。 制限が全く与えられたドメインが同時に属すかもしれない何RDCsにもかかわらず、RDCsがどう形成されるべきであるかに関するどんな前提条件にもありません--RDCsは入れ子にされるか、ばらばらになるか、または重なるかもしれません。 1RDCがまた、前者のすべてのメンバー(RDs)が後者のメンバーであるなら別のRDCの中で入れ子にされますが、逆もまた同様に入れ子にされるというわけではありません。 彼らがメンバーが共通であるなら、2RDCsが重なります、そして、また、それぞれには、もう片方にいないメンバーがいます。 2RDCsがそうです。彼らがメンバーが全く共通でないなら、ばらばらになってください。
Each domain participating in IDRP is assigned a unique Routing Domain Identifier (RDI). Syntactically an RDI is represented as an OSI network layer address. Each RDC is assigned a unique Routing Domain Confederation Identifier (RDCI). RDCIs are assigned out of the address space allocated for RDIs -- RDCIs and RDIs are syntactically indistinguishable. Procedures for assigning and managing RDIs and RDCIs are outside the scope of the protocol. However, since RDIs are syntactically nothing more than network layer addresses, and RDCIs are syntactically nothing more than RDIs, it is expected that RDI and RDCI assignment and management would be part of the network layer assignment and management procedures. Recommendations for RDI and RDCI assignment are provided in Section 6.5.
ユニークなルート設定Domain Identifier(RDI)はIDRPに参加する各ドメインに割り当てられます。 シンタクス上、RDIはOSIネットワーク層アドレスとして表されます。 ユニークなルート設定Domain Confederation Identifier(RDCI)は各RDCに割り当てられます。 RDCIsはRDIsのために割り当てられたアドレス空間から割り当てられます--RDCIsとRDIsはシンタクス上区別がつきません。 プロトコルの範囲の外にRDIsとRDCIsを割り当てて、管理するための手順があります。 しかしながらただネットワーク層アドレス、およびRDCIsはRDIsがシンタクス上そうであるからシンタクス上です。ただRDIs、RDI、RDCI課題、および管理がネットワーク層課題と管理手順の一部であると予想されます。 RDIのための推薦とRDCI課題をセクション6.5に提供します。
IDRP requires a BIS to be preconfigured with the RDI of the domain to which the BIS belongs. If a BIS belongs to a domain that is a member of one or more RDCs, then the BIS has to be preconfigured with RDCIs of all the RDCs the domain is in, and the information about relations between the RDCs - nested or overlapped.
IDRPは、BISがBISが属するドメインのRDIと共にあらかじめ設定されるのを必要とします。 BISが1RDCsのメンバーであるドメインに属すなら、RDCsの間には、ドメインがあるすべてのRDCsのRDCIsと関係の情報がある状態で、BISはあらかじめ設定されなければなりません--入れ子にされるか、または重ね合わせられます。
IDRP doesn't assume or require any particular internal structure for the addresses. The protocol provides correct routing as long as the following guidelines are met:
IDRPはアドレスのための少しの特定の内部の構造も仮定もしませんし、必要ともしません。 以下のガイドラインが満たされる限り、プロトコルは正しいルーティングを提供します:
* End systems and intermediate systems may use any NSAP address or
Network Entity Title (NET -- i.e., an NSAP address without the
selector) that has been assigned under ISO 8348 [11] guidelines;
* エンドシステムと中間システムはISO8348[11]ガイドラインの下で割り当てられたどんなNSAPアドレスやNetwork Entity Title(NET--すなわち、セレクタのないNSAPアドレス)も使用するかもしれません。
* An NSAP prefix carried in the Network Layer Reachability
Information (NLRI) field for a route originated by a BIS in a
given routing domain should be associated with only that
routing domain; that is, no system identified by the prefix
should reside in a different routing domain; ambiguous routing
may result if several routing domains originate routes whose
* Network Layer Reachability情報(NLRI)分野で与えられた経路ドメインでBISによって溯源されたルートまで運ばれたNSAP接頭語はその経路ドメインだけに関連しているべきです。 すなわち、接頭語によって特定されなかったシステムは全く異なった経路ドメインにあるはずです。 ドメインが溯源する数個のルーティングがだれのものを発送するなら、あいまいなルーティングは結果として生じるかもしれません。
Colella, Callon, Gardner & Rekhter [Page 13] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[13ページ]RFC1629NSAPガイドライン1994年5月
NLRI field contain identical NSAP address prefixes, since this
would imply that the same system(s) is simultaneously located
in several routing domains;
NLRI分野は同じNSAPアドレス接頭語を含んでいます、これが、同じシステムが同時にいくつかの経路ドメインに位置しているのを含意するでしょう、したがって。
* Several different NSAP prefixes may be associated with a single
routing domain which contains a mix of systems which use NSAP
addresses assigned by several different addressing authorities.
* いくつかの異なったNSAP接頭語がいくつかの異なったアドレシング当局によって割り当てられたNSAPアドレスを使用するシステムのミックスを含むただ一つの経路ドメインに関連しているかもしれません。
IDRP assumes that the above guidelines have been satisfied, but it contains no means to verify that this is so. Therefore, such verification is assumed to be the responsibility of the administrators of routing domains.
IDRPは、上記のガイドラインを満たしてあると仮定しますが、それはこれがそうであることを確かめる手段を全く含んでいません。 したがって、そのような検証は経路ドメインの管理者の責任であると思われます。
IDRP provides mandatory support for data integrity and optional support for data origin authentication for all of its messages. Each message carries a 16-octet digital signature that is computed by applying the MD-4 algorithm (RFC 1320) to the context of the message itself. This signature provides support for data integrity. To support data origin authentication a BIS, when computing a digital signature of a message, may prepend and append additional information to the message. This information is not passed as part of the message but is known to the receiver.
IDRPはメッセージのすべてのためのデータ保全の義務的なサポートとデータ起源認証の任意のサポートを提供します。 各メッセージはMD-4アルゴリズム(RFC1320)をメッセージ自体の文脈に適用することによって計算される16八重奏のデジタル署名を運びます。 この署名はデータ保全のサポートを提供します。 メッセージのデジタル署名を計算するとき、BISは、データ起源認証を支持するために、追加情報をメッセージにprependして、追加するかもしれません。 この情報は、メッセージの一部として通過されませんが、受信機に知られています。
3.3.1. Scaling Mechanisms in IDRP
3.3.1. IDRPのスケーリングメカニズム
The ability to group domains in RDCs provides a simple, yet powerful mechanism for routing information aggregation and abstraction. It allows reduction of topological information by replacing a sequence of RDIs carried by the RD_PATH attribute with a single RDCI. It also allows reduction of the amount of information related to transit policies, since the policies can be expressed in terms of aggregates (RDCs), rather than individual components (RDs). It also allows simplification of route selection policies, since these policies can be expressed in terms of aggregates (RDCs) rather than individual components (RDs).
RDCsのドメインを分類する能力は簡単で、しかし、強力なメカニズムをルーティング情報集合と抽象化に提供します。 それは、独身のRDCIと共にRD_PATH属性によって運ばれたRDIsの系列を置き換えることによって、位相的な情報の減少を許します。 また、それは運送保険証券に関連する情報量の減少を許します、個々のコンポーネント(RDs)よりむしろ集合(RDCs)で方針を言い表すことができるので。 また、それはルート選択方針の簡素化を許します、個々のコンポーネント(RDs)よりむしろ集合(RDCs)でこれらの方針を言い表すことができるので。
Aggregation and abstraction of Network Layer Reachability Information (NLRI) is supported by the "route aggregation" mechanism of IDRP. This mechanism is complementary to the Routing Domain Confederations mechanism. Both mechanisms are intended to provide scalable routing via information reduction/abstraction. However, the two mechanisms are used for different purposes: route aggregation for aggregation and abstraction of routes (i.e., Network Layer Reachability Information), Routing Domain Confederations for aggregation and abstraction of topology and/or policy information. To provide maximum benefits, both mechanisms can be used together. This implies that address assignment that will facilitate route aggregation does not conflict with the ability to form RDCs, and vice versa; formation
Network Layer Reachability情報(NLRI)の集合と抽象化はIDRPの「ルート集合」メカニズムで後押しされています。 このメカニズムはルート設定Domain Confederationsメカニズムを補足しています。 両方のメカニズムが情報減少/抽象化でスケーラブルなルーティングを提供することを意図します。 しかしながら、2つのメカニズムが異なる役割に使用されます: ルート(すなわち、Network Layer Reachability情報)の集合と抽象化のための集合、トポロジーの集合と抽象化のためのルート設定Domain Confederations、そして/または、方針情報を発送してください。 最大限の利益を提供するために、両方のメカニズムを一緒に使用できます。 これはルート集合を容易にするそのアドレス課題がRDCsを形成する能力と衝突しないで、逆もまた同様ですを含意します。 構成
Colella, Callon, Gardner & Rekhter [Page 14] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[14ページ]RFC1629NSAPガイドライン1994年5月
of RDCs should be done in a manner consistent with the address assignment needed for route aggregation.
RDCsにおいて、アドレス課題と一致した方法がルート集合に必要としたされたコネはそうであるべきですか?
3.4. Requirements of IS-IS and IDRP on NSAPs
3.4. 要件、-、NSAPsの上のIDRP
The preferred NSAP format for IS-IS is shown in Figure 1. A number of points should be noted from IS-IS:
NSAP形式を好む、-、図1では、示されます。 多くのポイントが注意されるべきである、-、:
* The IDP is as specified in ISO 8348, the OSI network layer service
specification [11];
* IDPがISO8348、OSIネットワーク層サービス仕様[11]で指定されるようにあります。
* The high-order portion of the DSP (HO-DSP) is that portion of the
DSP whose assignment, structure, and meaning are not constrained by
IS-IS;
* DSP(HO-DSP)の高位一部が課題、構造、および意味が抑制されないDSPのその一部である、-、。
* The area address (i.e., the concatenation of the IDP and the
HO-DSP) must be globally unique. If the area address of an NSAP
matches one of the area addresses of a router, it is in the
router's area and is routed to by level 1 routing;
* 領域アドレス(すなわち、IDPとHO-DSPの連結)はグローバルにユニークでなければなりません。 NSAPの領域アドレスがルータの領域アドレスの1つに合っているなら、それにルータの領域にあって、レベル1 ルーティングで掘られます。
* Level 2 routing acts on address prefixes, using the longest address
prefix that matches the destination address;
* レベル2 送付先アドレスに合っている最も長いアドレス接頭語を使用して、ルーティングはアドレス接頭語に影響します。
* Level 1 routing acts on the ID field. 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. The ID field is assumed to be
flat. The method presented in RFC 1526 [18] may optionally be
used to assure globally unique IDs;
* レベル1 ルーティングはID分野に影響します。 ID分野は、領域の中でESsとレベル1ISsにユニークであって、レベル2ISsに、経路ドメインの中でユニークであるに違いありません。 ID分野が平坦であると思われます。 RFC1526[18]に提示された方法は固有のIDをグローバルに保証するのに任意に使用されるかもしれません。
* The one-octet NSAP Selector, SEL, determines the entity to receive
the CLNP packet within the system identified by the rest of the
NSAP (i.e., a transport entity) and is always the last octet of the
NSAP; and,
* 1八重奏のNSAP Selector(SEL)は実体がNSAP(すなわち、輸送実体)の残りで特定されたシステムの中でCLNPパケットを受けることを決定して、いつもNSAPの最後の八重奏です。 そして
* A system shall be able to generate and forward data packets
containing addresses in any of the formats specified by
ISO 8348. However, within a routing domain that conforms to IS-IS,
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 IS-IS
routing. End systems with addresses which do not conform may
require additional manual configuration and be subject to inferior
routing performance.
* システムは、ISO8348によって指定された形式のいずれにもアドレスを含むデータ・パケットを、発生して、進めることができるでしょう。 しかしながら、それが従う経路ドメイン、-、NSAPの下層階級八重奏が最大限に利用する図1に示されたIDとSEL分野として構造化されるべきである、-、ルーティング。 従わないアドレスがあるエンドシステムは、追加手動の構成を必要として、劣ったルーティング性能を受けることがあるかもしれません。
For purposes of efficient operation of the IS-IS routing protocol, several observations may be made. First, although the IS-IS protocol specifies an algorithm for routing within a single routing domain, the routing algorithm must efficiently route both: (i) Packets whose final destination is in the domain (these must, of course, be routed
効率的な操作の目的、-、ルーティング・プロトコル、いくつかの観測をするかもしれません。 最初に、-、プロトコルはただ一つの経路ドメインの中のルーティングにアルゴリズムを指定して、ルーティング・アルゴリズムは効率的に両方を発送しなければなりません: (i) だれの最終的な目的地がそのドメインにあるか。パケット、(これらがそうしなければならない、もちろん、発送されてください。
Colella, Callon, Gardner & Rekhter [Page 15] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[15ページ]RFC1629NSAPガイドライン1994年5月
to the correct destination end system in the domain); and (ii) Packets whose final destination is outside of the domain (these must be routed to an appropriate "border" router, from which they will exit the domain).
そのドメインの正しい目的地エンドシステム)、。 そして、(ii) 最終的な目的地がドメイン(それらがドメインを出る適切な「境界」ルータにこれらを発送しなければならない)の外にあるパケット。
For those destinations which are in the domain, level 2 routing treats the entire area address (i.e., all of the NSAP address except the ID and SEL fields) as if it were a flat field. Thus, the efficiency of level 2 routing to destinations within the domain is affected only by the number of areas in the domain, and the number of area addresses assigned to each area.
そのドメインにあるそれらの目的地に関しては、レベル2 ルーティングはまるでそれが平らな野原であるかのように全体の領域アドレス(すなわち、IDとSEL分野以外のNSAPアドレスのすべて)を扱います。 したがって、ドメインの中の目的地に掘られるレベル2の効率はそのドメインの領域の数、および各領域に割り当てられた領域アドレスの数だけで影響を受けます。
For those destinations which are outside of the domain, level 2 routing routes according to address prefixes. In this case, there is considerable potential advantage (in terms of reducing the amount of routing information that is required) if the number of address prefixes required to describe any particular set of external destinations can be minimized. Efficient routing with IDRP similarly also requires minimization of the number of address prefixes needed to describe specific destinations. In other words, addresses need to be assigned with topological significance. This requirement is described in more detail in the following sections.
ドメインの外にあるそれらの目的地に関しては、アドレスに応じて、レベル2 ルーティングは接頭語を発送します。 この場合、接頭語がどんな特定のセットの外部の目的地についても説明するのを必要としたアドレスの数を最小にすることができるなら、かなりの潜在的利点(必要であるルーティング情報の量を減少させることに関する)があります。 また、IDRPがある効率的なルーティングは同様に特定の目的地について説明するのに必要であるアドレス接頭語の数の最小化を必要とします。 言い換えれば、アドレスは、位相的な意味で割り当てられる必要があります。 この要件はさらに詳細に以下のセクションで説明されます。
4. NSAPs and Routing
4. NSAPsとルート設定
4.1. Routing Data Abstraction
4.1. ルート設定データ抽象化
When determining an administrative policy for NSAP assignment, it is important to understand the technical consequences. The objective behind the use of hierarchical routing is to achieve some level of routing data abstraction, or summarization, to reduce the processing time, memory requirements, and transmission bandwidth consumed in support of routing. This implies that address assignment must serve the needs of routing, in order for routing to scale to very large networks.
NSAP課題のための施政方針を決定するとき、技術的な結果を理解しているのは重要です。 階層型ルーティングの使用の後ろの目的はルーティングを支持して費やされた処理時間、メモリ要件、およびトランスミッション帯域幅を減らすために何らかのレベルのルーティングデータ抽象化、または総括を達成することです。 これは、アドレス課題がルーティングの必要性に役立たなければならないのを含意します、ルーティングが非常に大きいネットワークにスケーリングするように。
While the notion of routing data abstraction may be applied to various types of routing information, this and the following sections primarily emphasize one particular type, namely reachability information. Reachability information describes the set of reachable destinations.
ルーティングデータ抽象化の概念が様々なタイプのルーティング情報に適用されているかもしれない間、これと以下のセクションは主として1つの特定のタイプ、すなわち、可到達性情報を強調します。 可到達性情報は届いている目的地のセットについて説明します。
Abstraction of reachability information dictates that NSAPs be assigned according to topological routing structures. However, administrative assignment falls along organizational or political boundaries. These may not be congruent to topological boundaries, and therefore the requirements of the two may collide. A balance between these two needs is necessary.
可到達性情報の抽象化は、位相的なルーティング構造に従ってNSAPsが割り当てられると決めます。 しかしながら、管理課題は組織的であるか政治上の境界に沿って下がります。 これらは位相的な境界に一致していないかもしれません、そして、したがって、2つのものの要件は衝突するかもしれません。 これらの2つの必要性の間のバランスが必要です。
Colella, Callon, Gardner & Rekhter [Page 16] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[16ページ]RFC1629NSAPガイドライン1994年5月
Routing data abstraction occurs at the boundary between hierarchically arranged topological routing structures. An element lower in the hierarchy reports summary routing information to its parent(s). Within the current OSI routing framework [13] and routing protocols, the lowest boundary at which this can occur is the boundary between an area and the level 2 subdomain within a IS-IS routing domain. Data abstraction is designed into IS-IS at this boundary, since level 1 ISs are constrained to reporting only area addresses.
データ抽象化が階層的に境界に起こるルート設定は位相的なルーティング構造をアレンジしました。 要素は階層構造レポート概要ルーティング情報で親に下げられます。 これが起こることができる最も低い境界が中の領域と平らな2サブドメインの間の現在のOSIルーティング枠組み[13]とルーティング・プロトコルの中では、境界である、-、経路ドメイン データ抽象化が設計されている、-、この境界では、レベル1以来、ISsは領域アドレスだけを報告するのに抑制されます。
Level 2 routing is based upon address prefixes. Level 2 routers (ISs) distribute, throughout the level 2 subdomain, the area addresses of the level 1 areas to which they are attached (and any manually configured reachable address prefixes). Level 2 routers compute next-hop forwarding information to all advertised address prefixes. Level 2 routing is determined by the longest advertised address prefix that matches the destination address.
レベル2 ルーティングはアドレス接頭語に基づいています。 レベル2 ルータ(ISs)は平らな2サブドメイン、レベル1の領域アドレス中でそれらが付けている領域(そして、どんな手動で構成された届いているアドレス接頭語も)を分配します。 レベル2 ルータはすべての広告を出しているアドレス接頭語に次のホップ推進情報を計算します。 レベル2 ルーティングは送付先アドレスに合っている最も長い広告を出しているアドレス接頭語で決定します。
At routing domain boundaries, address prefix information is exchanged with other routing domains via IDRP. If area addresses within a routing domain are all drawn from distinct NSAP assignment authorities (allowing no abstraction), then the boundary prefix information consists of an enumerated list of all area addresses.
ルーティングドメイン境界では、IDRPを通して他の経路ドメインでアドレス接頭語情報を交換します。 異なったNSAP課題当局から経路ドメインの中の領域アドレスをすべて得るなら(抽象化を全く許さないで)、境界接頭語情報はすべての領域アドレスの列挙されたリストから成ります。
Alternatively, should the routing domain "own" an address prefix and assign area addresses based upon it, boundary routing information can be summarized into the single prefix. This can allow substantial data reduction and, therefore, will allow much better scaling (as compared to the uncoordinated area addresses discussed in the previous paragraph).
あるいはまた境界ルーティング情報を経路ドメインがアドレス接頭語を「所有し」て、それに基づく領域アドレスを割り当てるならただ一つの接頭語へまとめることができます。 これは、かなりのデータ整理を許容できて、したがって、比例するほうがよいのを許容するでしょう(前のパラグラフで議論した非調整された領域アドレスと比べて)。
If routing domains are interconnected in a more-or-less random (non- hierarchical) scheme, it is quite likely that no further abstraction of routing data can occur. Since routing domains would have no defined hierarchical relationship, administrators would not be able to assign area addresses out of some common prefix for the purpose of data abstraction. The result would be flat inter-domain routing; all routing domains would need explicit knowledge of all other routing domains that they route to. This can work well in small- and medium- sized internets, up to a size somewhat larger than the current IP Internet. However, this does not scale to very large internets. For example, we expect growth in the future to an international Internet which has tens or hundreds of thousands of routing domains in the U.S. alone. Even larger numbers of routing domains are possible when each home, or each small company, becomes its own routing domain. This requires a greater degree of data abstraction beyond that which can be achieved at the "routing domain" level.
経路ドメインが多少無作為(非階層的な)の計画でインタコネクトされるなら、ルーティングデータのさらなる抽象化は全くかなり起こりそうであることができません。 経路ドメインには、定義された上下関係が全くないでしょう、したがって、管理者がデータ抽象化の目的のために何らかの一般的な接頭語から領域アドレスを割り当てることができないでしょう。 結果は平坦な相互ドメインルーティングでしょう。 ドメインがそれらが発送する他のすべての経路ドメインの形式知を必要とするすべてのルーティング。 これは小さくて中型の大きさで分けられたインターネットでうまくいくことができます、現在のIPインターネットよりいくらか大きいサイズまで。 しかしながら、これは非常に大きいインターネットに比例しません。 例えば、私たちは将来、10か米国の何十万もの経路ドメインを単独にする国際的なインターネットに成長を予測します。 各家、または各小会社がそれ自身の経路ドメインになるとき、より多くのさえ経路ドメインが可能です。 これは「経路ドメイン」レベルで達成できるそれを超えて、より大きい度のデータ抽象化を必要とします。
Colella, Callon, Gardner & Rekhter [Page 17] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[17ページ]RFC1629NSAPガイドライン1994年5月
In the Internet, however, it should be possible to exploit the existing hierarchical routing structure interconnections, as discussed in Section 5. Thus, there is the opportunity for a group of subscribers each to be assigned an address prefix from a shorter prefix assigned to their provider. Each subscriber now "owns" its (somewhat longer) prefix, from which it assigns its area addresses.
しかしながら、インターネットでは、既存の階層型ルーティング構造インタコネクトを利用するのは可能であるべきです、セクション5で議論するように。 したがって、アドレス接頭語が彼らのプロバイダーに割り当てられたより短い接頭語から加入者のグループにそれぞれ配属される機会があります。 各加入者は現在、(いくらか長い)の接頭語を「所有しています」。(それはそれから領域アドレスを割り当てます)。
The most straightforward case of this occurs when there is a set of subscribers whose routing domains are all attached only to a single service provider, and which use that provider for all external (inter-domain) traffic. A short address prefix may be assigned to the provider, which then assigns slightly longer prefixes (based on the provider's prefix) to each of the subscribers. This allows the provider, when informing other providers of the addresses that it can reach, to abbreviate the reachability information for a large number of routing domains as a single prefix. This approach therefore can allow a great deal of hierarchical abbreviation of routing information, and thereby can greatly improve the scalability of inter-domain routing.
経路ドメインがすべての外部(相互ドメイン)の交通にそのプロバイダーを使用するただ一つのサービスプロバイダーだけに付けられたすべてである加入者のセットがあるとき、この最も簡単なケースは現れます。 短いアドレス接頭語はプロバイダーに割り当てられるかもしれません。(次に、それは、わずかに長い接頭語(プロバイダーの接頭語に基づいている)を加入者各人に割り当てます)。 それにただ一つの接頭語を多くの経路ドメインのための可到達性情報を簡略化するために達することができることをアドレスの他のプロバイダーに知らせるとき、これはプロバイダーを許容します。 このアプローチは、したがって、多くのルーティング情報の階層的な略語を許容できて、その結果、相互ドメインルーティングのスケーラビリティを大いに改良できます。
Clearly, this approach is recursive and can be carried through several iterations. Routing domains at any "level" in the hierarchy may use their prefix as the basis for subsequent suballocations, assuming that the NSAP addresses remain within the overall length and structure constraints. The flexibility of NSAP addresses facilitates this form of hierarchical address assignment and routing. As one example of how NSAPs may be used, the GOSIP Version 2 NSAP structure is discussed later in this section.
明確に、このアプローチは、再帰的であり、いくつかの繰り返しで運ぶことができます。 階層構造のどんな「レベル」でも経路ドメインはその後の細分割当ての基礎としてそれらの接頭語を使用するかもしれません、NSAPアドレスが全長と構造規制に残っていると仮定して。 NSAPアドレスの柔軟性はこのフォームの階層的なアドレス課題とルーティングを容易にします。 NSAPsがどう使用されるかもしれないかに関する1つの例として、GOSIPバージョン2NSAP構造は後でこのセクションで議論されます。
At this point, we observe that the number of nodes at each lower level of a hierarchy tends to grow exponentially. Thus the greatest gains in data abstraction occur at the leaves and the gains drop significantly at each higher level. Therefore, the law of diminishing returns suggests that at some point data abstraction ceases to produce significant benefits. Determination of the point at which data abstraction ceases to be of benefit requires a careful consideration of the number of routing domains that are expected to occur at each level of the hierarchy (over a given period of time), compared to the number of routing domains and address prefixes that can conveniently and efficiently be handled via dynamic inter-domain routing protocols. As the Internet grows, further levels of hierarchy may become necessary. Again, this requires considerable flexibility in the addressing scheme, such as is provided by NSAP addresses.
ここに、私たちは、階層構造の各下のレベルにおけるノードの数が、指数関数的に成長する傾向があるのを観測します。 したがって、データ抽象化における最大級の利得は葉に起こります、そして、利得はそれぞれのより高いレベルで著しく低下します。 したがって、収穫逓減の法則は、何らかのポイントデータ抽象化におけるそれが、重要な利益を生産するのをやめるのを示します。 データ抽象化が有益であることをやめるポイントの決断は階層構造(与えられた期間の間の)の各レベルで起こると予想される経路ドメインの数の熟慮を必要とします、ダイナミックな相互ドメインルーティング・プロトコルで便利に効率的に扱うことができる経路ドメインとアドレス接頭語の数と比べて。 インターネットが発展するのに従って、さらなるレベルの階層構造は必要になるかもしれません。 一方、これはNSAPアドレスで提供するようなアドレシング計画におけるかなりの柔軟性を必要とします。
Colella, Callon, Gardner & Rekhter [Page 18] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[18ページ]RFC1629NSAPガイドライン1994年5月
4.2. NSAP Administration and Efficiency
4.2. NSAP政権と効率
There is a balance that must be sought between the requirements on NSAPs for efficient routing and the need for decentralized NSAP administration. The NSAP structure from Version 2 of GOSIP (Figure 2) offers one example of how these two needs might be met. The AFI, IDI, DSP Format Identifier (DFI), and Administrative Authority (AA) fields provide for administrative decentralization. The AFI/IDI pair of values 47.0005 identify the U.S. Government as the authority responsible for defining the DSP structure and allocating values within it (see the Appendix for more information on NSAP structure).
分散NSAP管理の効率的なルーティングと必要性のためにNSAPsに関する要件の間で求めなければならないバランスがあります。 GOSIP(図2)のバージョン2からのNSAP構造はこれらの2つの需要がどう満たされるかもしれないかに関する1つの例を提供します。 AFI、IDI、DSP Format Identifier(DFI)、およびAdministrative Authority(AA)分野は行政の地方分権に備えます。 値47.0005のAFI/IDI組は、米国政府がDSP構造を定義して、それの中に値を割り当てるのに原因となる権威であると認識します(NSAP構造の詳しい情報に関してAppendixを見てください)。
<----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| rd| 領域| 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
AA Administrative Authority
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
IDPの初期のドメイン部分AFI権威と初期の形式IDの特定の部分DFI DSP形式ID AA IDIドメイン識別子DSPドメイン職務権限Rsvdは経路ドメイン識別子領域領域識別子IDシステム識別子SEL NSAP第セレクタを予約しました。
Figure 2: GOSIP Version 2 NSAP structure.
図2: GOSIPバージョン2NSAP構造。
[Note: We are using U.S. GOSIP version 2 addresses only as an example. It is not necessary that NSAPs be allocated from the GOSIP Version 2 authority under 47.0005. The ANSI format under the Data Country Code for the U.S. (DCC=840) and formats assigned to other countries and ISO members or liaison organizations are also being used, and work equally well. For parts of the Internet outside of the U.S. there may in some cases be strong reasons to prefer a country- or area-specific format rather than the U.S. GOSIP format. However, GOSIP addresses are used in most cases in the examples in this paper because:
注意します; 私たちは単に例としてU.S. GOSIPバージョン2アドレスを使用しています。47.0005 米国へのData Country Codeの下のANSI形式(DCC=840)と形式の下における権威が割り当てたGOSIPバージョン2から他国までNSAPsを割り当てるのは必要でなく、ISOメンバーか連絡組織が、また、使用されていて、等しくうまくいきます; インターネットの地域に関しては、いくつかの場合、そこの米国の外部は、国を好む強い理由かU.S. GOSIP形式よりむしろ領域特有の形式であるかもしれません。しかしながら、多くの場合、GOSIPアドレスがこの紙の例で使用される、:
* The DSP format has been defined and allows hierarchical allocation;
and,
* DSP形式は、定義されて、階層的な配分を許します。 そして
Colella, Callon, Gardner & Rekhter [Page 19] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[19ページ]RFC1629NSAPガイドライン1994年5月
* An operational registration authority for suballocation of AA
values under the GOSIP address space has already been established at
GSA.]
* GOSIPアドレス空間の下におけるAA値の細分割当てのための操作上の登録局はGSAに既に設立されました。]
GOSIP Version 2 defines the DSP structure as shown (under DFI=80h) and provides for the allocation of AA values to administrations. Thus, the fields from the AFI to the AA, inclusive, represent a unique address prefix assigned to an administration.
GOSIPバージョン2は、示される(DFI=80hの下の)とDSP構造を定義して、AA値の配分に政権に備えます。 したがって、包括的なAFIからAAまでの分野は管理に配属されたユニークなアドレス接頭語を表します。
American National Standard X3.216-1992 [1] specifies the structure of the DSP for NSAP addresses that use an Authority and Format Identifier (AFI) value of (decimal) 39, which identifies the "ISO- DCC" (data country code) format, in which the value of the Initial Domain Identifier (IDI) is (decimal) 840, which identifies the U.S. National Body (ANSI). This DSP structure is identical to the structure that is specified by GOSIP Version 2. The AA field is called "org" for organization identifier in the ANSI standard, and the ID field is called "system". The ANSI format, therefore, differs from the GOSIP format illustrated above only in that the AFI and IDI specify the "ISO-DCC" format rather than the "ISO 6523-ICD" format used by GOSIP, and the "AA" field is administered by an ANSI registration authority rather than by the GSA. Organization identifiers may be obtained from ANSI. The technical considerations applicable to NSAP administration are independent of whether a GOSIP Version 2 or an ANSI value is used for the NSAP assignment.
米国標準規格X3.216-1992[1]は米国国家体(ANSI)を特定する(10進)の39のAuthorityとFormat Identifier(AFI)値を使用するNSAPアドレスにDSPの構造を指定します。値は"ISO- DCC"(データ国名略号)形式を特定します。(初期のドメイン識別子(イディ)の値はそれで(10進)の840です)。 このDSP構造はGOSIPバージョン2によって指定される構造と同じです。 AA分野はANSI規格における組織識別子のために"org"と呼ばれます、そして、ID分野は「システム」と呼ばれます。 したがって、ANSI形式はAFIとIDIが単にGOSIPによって使用された"ISO 6523-ICD"形式よりむしろ"ISO-DCC"形式を指定するという点において上で例証されたGOSIP形式と異なっています、そして、"AA"分野はGSAでというよりむしろANSI登録局によって管理されます。 ANSIから組織識別子を得るかもしれません。 GOSIPバージョン2かANSI値がNSAP課題に使用されるかどうかからNSAP管理に適切な技術的な問題は独立しています。
Similarly, although other countries make use of different NSAP formats, the principles of NSAP assignment and use are the same. The NSAP formats recommended by RARE WG4 for use in Europe are discussed in Section 6.2.
同様に、他国は異なったNSAP形式を利用しますが、NSAP課題と使用の原則は同じです。 セクション6.2でヨーロッパでの使用のためにRARE WG4によって推薦されたNSAP書式について議論します。
In the low-order part of the GOSIP Version 2 NSAP format, two fields are defined in addition to those required by IS-IS. These fields, RD and Area, are defined to allow allocation of NSAPs along topological boundaries in support of increased data abstraction. Administrations assign RD identifiers underneath their unique address prefix (the reserved field is left to accommodate future growth and to provide additional flexibility for inter-domain routing). Routing domains allocate Area identifiers from their unique prefix. The result is:
2NSAPがフォーマットするGOSIPバージョンの下位の部分では、2つの分野がそれらに加えて必要な状態で定義される、- これらの分野(RDとArea)は、位相的な境界に沿って増加するデータ抽象化を支持してNSAPsの配分を許すために定義されます。 政権はそれらのユニークなアドレス接頭語の下で識別子をRDに割り当てます(今後の成長に対応して、予約された野原が相互ドメインルーティングに追加柔軟性を提供するのが残されます)。 経路ドメインは識別子をそれらのユニークな接頭語からAreaに割り当てます。 結果は以下の通りです。
* AFI+IDI+DFI+AA = administration prefix,
* AFI+IDI+DFI+AAは管理接頭語と等しいです。
* administration prefix(+Rsvd)+RD = routing domain prefix, and,
* そして、ドメイン接頭語を+ 管理接頭語(+ Rsvd)RD=発送すること。
* routing domain prefix+Area = area address.
* 経路ドメインの接頭語+地域は領域アドレスと等しいです。
Colella, Callon, Gardner & Rekhter [Page 20] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[20ページ]RFC1629NSAPガイドライン1994年5月
This provides for summarization of all area addresses within a routing domain into one prefix. If the AA identifier is accorded topological significance (in addition to administrative significance), an additional level of data abstraction can be obtained, as is discussed in the next section.
これは1つの接頭語への経路ドメインの中のすべての領域アドレスの総括に備えます。 位相的な意味(管理意味に加えた)をAA識別子に与えるなら、そのままで次のセクションで議論していた状態で追加レベルのデータ抽象化を得ることができます。
5. NSAP Administration and Routing in the Internet
5. インターネットのNSAP政権とルート設定
Basic Internet routing components are service providers and service subscribers. A natural mapping from these components to OSI routing components is that each provider and subscriber operates as a routing domain.
基本的なインターネット・ルーティングコンポーネントは、サービスプロバイダーとサービス加入者です。 自然なこれらのコンポーネントからOSIルーティングの部品までのマッピングは各プロバイダーと加入者が経路ドメインとして働いているということです。
Alternatively, a subscriber may choose to operate as a part of a provider domain; that is, as an area within the provider's routing domain. However, in such a case the discussion in Section 5.1 applies.
あるいはまた、加入者は、プロバイダードメインの一部として作動するのを選ぶかもしれません。 すなわち、プロバイダーの経路ドメインの中の領域として。 しかしながら、このような場合にはセクション5.1における議論は適用されます。
We assume that most subscribers will prefer to operate a routing domain separate from their provider's. Such subscribers can exchange routing information with their provider via interior routing protocol route leaking or via IDRP; for the purposes of this discussion, the choice is not significant. The subscriber is still allocated a prefix from the provider's address space, and the provider advertises its own prefix into inter-domain routing.
私たちは、ほとんどの加入者が、彼らのプロバイダーのものから別々の経路ドメインを操作するのを好むと思います。 そのような加入者は内部のルーティング・プロトコルルート漏出を通して、または、IDRPを通して彼らのプロバイダーとルーティング情報を交換できます。 この議論の目的のために、選択は重要ではありません。 接頭語をプロバイダーのアドレス空間から加入者にまだ割り当てています、そして、プロバイダーは相互ドメインルーティングにそれ自身の接頭語の広告を出します。
Given such a mapping, where should address administration and allocation be performed to satisfy both administrative decentralization and data abstraction? Three possibilities are considered:
そのようなマッピングを考えて、アドレス管理と配分は、行政の地方分権とデータ抽象化の両方を満たすためにどこで実行されるべきですか? 3つの可能性が考えられます:
1. at the area,
1.、領域で
2. at the subscriber routing domain, and,
2. そしてドメインを発送する加入者で
3. at the provider routing domain.
3.、プロバイダー経路ドメインで。
Subscriber routing domains correspond to end-user sites, where the primary purpose is to provide intra-domain routing services. Provider routing domains are deployed to carry transit (i.e., inter-domain) traffic.
加入者経路ドメインはエンドユーザサイトに対応しています。そこでは、第一の目的はイントラドメインルーティングサービスを提供することです。 プロバイダー経路ドメインは、トランジット(すなわち、相互ドメイン)交通を運ぶために配備されます。
The greatest burden in transmitting and operating on routing information is at the top of the routing hierarchy, where routing information tends to accumulate. In the Internet, for example, each provider must manage the set of network numbers for all networks reachable through the provider.
ルーティング情報が伝わって、作動するのにおいて最も大きい負担がルーティング階層構造の最上部にあります。(そこでは、ルーティング情報が蓄積する傾向があります)。 インターネットでは、例えば、各プロバイダーはプロバイダーを通して届いているすべてのネットワークのネットワーク・ナンバーのセットを経営しなければなりません。
Colella, Callon, Gardner & Rekhter [Page 21] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[21ページ]RFC1629NSAPガイドライン1994年5月
For traffic destined for other networks, the provider will route based on inter-domain routing information obtained from other providers or, in some cases, to a default provider.
他のネットワークのために運命づけられた交通に、プロバイダーは相互ドメインルーティングに基づいて他のプロバイダーかいくつかの場合、デフォルトプロバイダーに得られた情報を発送するでしょう。
In general, higher levels of the routing hierarchy will benefit the most from the abstraction of routing information at a lower level of the routing hierarchy. There is relatively little direct benefit to the administration that performs the abstraction, since it must maintain routing information individually on each attached topological routing structure.
一般に、ルーティング階層構造の、より高いレベルは最も多くルーティング階層構造の下のレベルでルーティング情報の抽象化の利益を得るでしょう。 抽象化を実行する管理への比較的少ない直接利益があります、それぞれの付属位相的なルーティング構造の上で個別にルーティング情報を保守しなければならないので。
For example, suppose that a given subscriber is trying to decide whether to obtain an NSAP address prefix based on an AA value from GSA (implying that the first four octets of the address would be those assigned out of the GOSIP space), or based on an RD value from its provider (implying that the first seven octets of the address are those obtained by that provider). If considering only their own self-interest, the subscriber and its local provider have little reason to choose one approach or the other. The subscriber must use one prefix or another; the source of the prefix has little effect on routing efficiency within the subscriber's routing domain. The provider must maintain information about each attached subscriber in order to route, regardless of any commonality in the prefixes of its subscribers.
例えば、与えられた加入者が、プロバイダーからGSA(アドレスの最初の4つの八重奏がGOSIPスペースから割り当てられたものであることを含意する)からのAA値に基づいているか、またはRD値に基づくNSAPアドレス接頭語を得るかどうか決めようとしていると仮定してください(アドレスの最初の7つの八重奏がそのプロバイダーによって得られたものであることを含意して)。 それら自身の私利だけを考えるなら、加入者とそのローカルのプロバイダーには、1つのアプローチかもう片方を選ぶ理由がほとんどありません。 加入者は何らかの接頭語を使用しなければなりません。 接頭語の源は加入者の経路ドメインの中でほとんどルーティング効率に影響を与えません。 プロバイダーは、いずれもにかかわらず加入者の接頭語の共通点を発送するためにそれぞれの付属加入者の情報を保守しなければなりません。
However, there is a difference when the local provider distributes routing information to other providers. In the first case, the provider cannot aggregate the subscriber's address into its own prefix; the address must be explicitly listed in routing exchanges, resulting in an additional burden to other providers which must exchange and maintain this information.
しかしながら、ローカルのプロバイダーが他のプロバイダーにルーティング情報を分配するとき、違いがあります。 前者の場合、プロバイダーはそれ自身の接頭語への加入者のアドレスに集められることができません。 ルーティング交換で明らかにアドレスを記載しなければなりません、この情報を交換して、保守しなければならない他のプロバイダーへの追加負担をもたらして。
In the second case, each other provider sees a single address prefix for the local provider which encompasses the new subscriber. This avoids the exchange of additional routing information to identify the new subscriber's address prefix. Thus, the advantages primarily benefit other providers which maintain routing information about this provider (and its subscribers).
2番目の場合で互いである、プロバイダーは新しい加入者を取り囲むローカルのプロバイダーに関してただ一つのアドレス接頭語を見ます。 これは、新しい加入者のアドレス接頭語を特定するために追加ルーティング情報の交換を避けます。 したがって、利点は主としてこのプロバイダー(そして、加入者)のルーティング情報を保守する他のプロバイダーのためになります。
Clearly, a symmetric application of these principles is in the interest of all providers, enabling them to more efficiently support CLNP routing to their customers. The guidelines discussed below describe reasonable ways of managing the OSI address space that benefit the entire community.
明確に、これらの原則の左右対称の利用はすべてのプロバイダーのためにあります、より効率的に彼らの顧客にCLNPルーティングを支持するのを可能にして。 以下で議論したガイドラインは全体の共同体のためになるOSIアドレス空間を管理する合理的な方法を述べます。
Colella, Callon, Gardner & Rekhter [Page 22] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[22ページ]RFC1629NSAPガイドライン1994年5月
5.1. Administration at the Area
5.1. 領域の政権
If areas take their area addresses from a myriad of unrelated NSAP allocation authorities, there will be effectively no data abstraction beyond what is built into IS-IS. For example, assume that within a routing domain three areas take their area addresses, respectively, out of:
領域が関係ないNSAP配分当局の無数からそれらの領域アドレスを取ると、データ抽象化が全く有効に築き上げられることを超えていない、- 例えば、経路ドメインの中では、3つの領域が以下からそれらの領域アドレスをそれぞれ取ると仮定してください。
* the GOSIP Version 2 authority assigned to the Department
of Commerce, with an AA of nnn:
* nnnのAAと共に商務省に配属されたGOSIPバージョン2権威:
AFI=47, IDI=0005, DFI=80h, AA=nnn, ... ;
AFI=47、IDI=0005、DFI=80h、AA=nnn… ;
* the GOSIP Version 2 authority assigned to the Department
of the Interior, with an AA of mmm:
* GOSIPバージョン2権威がAAがある内務省に配属した、えー:
AFI=47, IDI=0005, DFI=80h, AA=mmm, ... ; and,
えー、AFI=47、IDI=0005、DFI=80h、AA=… ; そして
* the ANSI authority under the U.S. Data Country Code (DCC)
* 米国Data Country Codeの下のANSI権威(DCC)
(Section A.2) for organization XYZ with ORG identifier = xxx:
ORG識別子がある組織XYZのための(セクションA.2)はxxxと等しいです:
AFI=39, IDI=840, DFI=dd, ORG=xxx, ....
AFI=39、IDI=840、DFI=dd、ORG=xxx…
As described in Section 3.3, from the point of view of any particular routing domain, there is no harm in having the different areas in the routing domain use addresses obtained from a wide variety of administrations. For routing within the domain, the area addresses are treated as a flat field.
セクション3.3でどんな特定の経路ドメインの観点からも説明されるように、経路ドメインの異なった領域にさまざまな政権から得られたアドレスを使用させるのにおいて害が全くありません。 ドメインの中のルーティングにおいて、領域アドレスは平らな野原として扱われます。
However, this does have a negative effect on inter-domain routing, particularly on those other domains which need to maintain routes to this domain. There is no common prefix that can be used to represent these NSAPs and therefore no summarization can take place at the routing domain boundary. When addresses are advertised by this routing domain to other routing domains, an enumerated list must be used consisting of the three area addresses.
しかしながら、これは相互ドメインルーティングでマイナスの影響があります、特にこのドメインにルートを維持する必要があるそれらの他のドメインで。 これらのNSAPsを表すのに使用できるどんな一般的な接頭語もありません、そして、したがって、総括は全くルーティングドメイン境界で行われることができません。 アドレスがこの経路ドメインによって他の経路ドメインに広告に掲載されるとき、3つの領域アドレスから成りながら、列挙されたリストを使用しなければなりません。
This situation is roughly analogous to the dissemination of routing information in the TCP/IP Internet prior to the introduction of CIDR. Areas correspond roughly to networks and area addresses to network numbers. The result of allowing areas within a routing domain to take their NSAPs from unrelated authorities is flat routing at the area address level. The number of address prefixes that subscriber routing domains would advertise is on the order of the number of attached areas; the number of prefixes a provider routing domain would advertise is approximately the number of areas attached to all
この状況はCIDRの導入の前にTCP/IPインターネットでルーティング情報の普及におよそ類似しています。領域はおよそネットワーク・ナンバーへのネットワークと領域アドレスに対応しています。 経路ドメインの中の領域が関係ない当局からそれらのNSAPsを取るのを許容するという結果は領域アドレスレベルにおいて平坦なルーティングです。 付属領域の数の注文には加入者経路ドメインが広告を出すアドレス接頭語の数があります。 プロバイダー経路ドメインが広告を出す接頭語の数はすべてに付けられた領域のおよそ数です。
Colella, Callon, Gardner & Rekhter [Page 23] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[23ページ]RFC1629NSAPガイドライン1994年5月
its subscriber routing domains. For "default-less" providers (i.e., those that don't use default routes) the size of the routing tables would be on the order of the number of area addresses globally. As the CLNP internet grows this would quickly become intractable. A greater degree of hierarchical information reduction is necessary to allow greater growth.
その加入者経路ドメイン。 「デフォルトなし」のプロバイダー(すなわち、デフォルトルートを使用しないもの)のために、領域アドレスの数の注文には経路指定テーブルのサイズがグローバルにあるでしょう。 CLNPインターネットが成長するのに従って、これは急速に手に負えなくなるでしょう。 より大きい度の階層的な情報減少が、よりすばらしい成長を許容するのに必要です。
5.2. Administration at the Subscriber Routing Domain
5.2. 加入者経路ドメインの政権
As mentioned previously, the greatest degree of data abstraction comes at the lowest levels of the hierarchy. Providing each subscriber routing domain (that is, site) with a unique prefix results in the biggest single increase in abstraction, with each subscriber domain assigning area addresses from its prefix. From outside the subscriber routing domain, the set of all addresses reachable in the domain can then be represented by a single prefix.
既述のとおり、最大級の度のデータ抽象化は階層構造の最も低いレベルで来ます。 それぞれの加入者経路ドメイン(すなわち、サイト)をユニークな接頭語に提供すると、抽象化の最も大きいただ一つの増加はもたらされます、それぞれの加入者ドメインが接頭語からの領域アドレスを割り当てていて。 そして、加入者経路ドメインの外から、ただ一つの接頭語はそのドメインで届いているすべてのアドレスのセットを表すことができます。
As an example, assume a government agency has been assigned the AA value of zzz under ICD=0005. The agency then assigns a routing domain identifier to a routing domain under its administrative authority identifier, rrr. The resulting prefix for the routing domain is:
例として、グーグーグーのAA値がICD=0005の下で政府機関に配属されたと仮定してください。 そして、政府機関は職務権限識別子、rrrの下の経路ドメインに経路ドメイン識別子を割り当てます。 経路ドメインへの結果として起こる接頭語は以下の通りです。
AFI=47, IDI=0005, DFI=80h, AA=zzz, (Rsvd=0), RD=rrr.
AFI=47、IDI=0005、DFI=80h、AA=グーグーグー、(Rsvd=0)、=第rrr。
All areas within this routing domain would have area addresses comprising this prefix followed by an Area identifier. The prefix represents the summary of reachable addresses within the routing domain.
この経路ドメインの中のすべての領域には、Area識別子があとに続いたこの接頭語を包括する領域アドレスがあるでしょう。 接頭語は経路ドメインの中に届いているアドレスの概要を表します。
There is a close relationship between areas and routing domains implicit in the fact that they operate a common routing protocol and are under the control of a single administration. The routing domain administration subdivides the domain into areas and structures a level 2 subdomain (i.e., a level 2 backbone) which provides connectivity among the areas. The routing domain represents the only path between an area and the rest of the internetwork. It is reasonable that this relationship also extend to include a common NSAP addressing authority. Thus, the areas within the subscriber RD should take their NSAPs from the prefix assigned to the subscriber RD.
それらは一般的なルーティング・プロトコルを操作して、ただ一つの管理のコントロールの下にあるという事実の暗黙の領域と経路ドメインの間には、密接な関係があります。 経路ドメイン管理は、領域にドメインを分筆して、接続性を領域に提供する平らな2サブドメイン(すなわち、平らな2背骨)を構造化します。 経路ドメインは領域とインターネットワークの残りの間の唯一の経路を表します。 また、この関係が権威を記述する一般的なNSAPを含むように広がるのは、妥当です。 したがって、加入者RDの中の領域は加入者RDに割り当てられた接頭語からそれらのNSAPsを取るべきです。
5.3. Administration at the Provider Routing Domain
5.3. プロバイダー経路ドメインの政権
Two kinds of provider routing domains are considered, direct providers and indirect providers. Most of the subscribers of a direct provider are domains that act solely as service subscribers (i.e., they carry no transit traffic). Most of the "subscribers" of
2種類のプロバイダー経路ドメインは、考えられて、ダイレクトなプロバイダーと間接的なプロバイダーです。 ダイレクトプロバイダーの加入者の大部分は唯一サービス加入者として機能するドメイン(すなわち、彼らはトランジット交通を全く運ばない)です。 「加入者」の大部分
Colella, Callon, Gardner & Rekhter [Page 24] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[24ページ]RFC1629NSAPガイドライン1994年5月
an indirect provider are, themselves, service providers. In present terminology a backbone is an indirect provider, while a regional is a direct provider. Each case is discussed separately below.
間接的なプロバイダーがそうである、自分たち、サービスプロバイダー。 中では、現在の用語a背骨は間接的なプロバイダーですが、地方版はダイレクトプロバイダーです。 別々に以下で各ケースについて議論します。
5.3.1. Direct Service Providers
5.3.1. 直航プロバイダー
It is interesting to consider whether direct service providers' routing domains should be the common authority for assigning NSAPs from a unique prefix to the subscriber routing domains that they serve. In the long term the number of routing domains in the Internet will grow to the point that it will be infeasible to route on the basis of a flat field of routing domains. It will therefore be essential to provide a greater degree of information abstraction.
ユニークな接頭語からそれらが役立つ加入者経路ドメインまでNSAPsを割り当てるために直航プロバイダーの経路ドメインが一般的な権威であるべきであるかどうか考えるのはおもしろいです。 長期でインターネットの経路ドメインの数は経路ドメインの平らな野原に基づいて発送するのにおいて実行不可能になるというポイントに成長するでしょう。 したがって、より大きい度の情報抽象化を提供するのは不可欠でしょう。
Direct providers may assign prefixes to subscriber domains, based on a single (shorter length) address prefix assigned to the provider. For example, given the GOSIP Version 2 address structure, an AA value may be assigned to each direct provider, and routing domain values may be assigned by the provider to each attached subscriber routing domain. A similar hierarchical address assignment based on a prefix assigned to each provider may be used for other NSAP formats. This results in direct providers advertising to other providers (both direct and indirect) a small fraction of the number of address prefixes that would be necessary if they enumerated the individual prefixes of the subscriber routing domains. This represents a significant savings given the expected scale of global internetworking.
ダイレクトプロバイダーはプロバイダーに割り当てられたただ一つ(より短い長さ)のアドレス接頭語に基づいて加入者ドメインに接頭語を割り当てるかもしれません。 例えば、GOSIPバージョン2アドレス構造を考えて、AA値はそれぞれのダイレクトプロバイダーに割り当てられるかもしれません、そして、経路ドメイン値はプロバイダーによってそれぞれの付属加入者経路ドメインに割り当てられるかもしれません。 各プロバイダーに割り当てられた接頭語に基づく同様の階層的なアドレス課題は他のNSAP形式に使用されるかもしれません。 これはアドレスの数のわずかな部分が前に置く他の加入者経路ドメインの個々の接頭語を列挙するなら必要なプロバイダー(ダイレクトものと同様に間接的な)へのダイレクトプロバイダー広告をもたらします。 グローバルなインターネットワーキングの予想されたスケールを考えて、これは重要な貯蓄を表します。
Are subscriber routing domains willing to accept prefixes derived from the direct providers? In the supplier/consumer model, the direct provider is offering connectivity as the service, priced according to its costs of operation. This includes the "price" of obtaining service from one or more indirect providers and exchanging routing information with other direct providers. In general, providers will want to handle as few address prefixes as possible to keep costs low. In the Internet environment, subscriber routing domains must be sensitive to the resource constraints of the providers (both direct and indirect). The efficiencies gained in routing clearly warrant the adoption of NSAP administration by the direct providers.
ダイレクトプロバイダーから接頭語を受け入れても構わないと思っている加入者経路ドメインを得ますか? 供給者/消費者モデルでは、ダイレクトプロバイダーは操作のコストに従って値を付けられたサービスとして接続性を提供しています。 これは1つ以上の間接的なプロバイダーからサービスを得て、他のダイレクトプロバイダーとルーティング情報を交換する「価格」を含んでいます。 一般に、プロバイダーはコストを低く保つのにおいてできるだけわずかなアドレス接頭語しか扱いたくならないでしょう。 インターネット環境で、加入者経路ドメインはプロバイダーのリソース規制に敏感であるに違いありません(ダイレクトものと同様に間接的な)。 ルーティングで明確に獲得された効率はダイレクトプロバイダーでNSAP管理の採用を保証します。
The mechanics of this scenario are straightforward. Each direct provider is assigned a unique prefix, from which it allocates slightly longer routing domain prefixes for its attached subscriber routing domains. For GOSIP NSAPs, this means that a direct provider would be assigned an AA identifier. Attached subscriber routing domains would be assigned RD identifiers under the direct provider's unique prefix. For example, assume that NIST is a subscriber routing domain whose sole inter-domain link is via SURANet. If SURANet is
このシナリオの整備士は正直です。 ユニークな接頭語はそれぞれのダイレクトプロバイダーに割り当てられます。(それは付属加入者経路ドメインのために接頭語をそれから、より長い経路ドメインにわずかに割り当てます)。 GOSIP NSAPsに関しては、これは、AA識別子がダイレクトプロバイダーに割り当てられることを意味します。 RD識別子はダイレクトプロバイダーのユニークな接頭語の下で付属加入者経路ドメインに割り当てられるでしょう。 例えば、NISTがSURANetを通して唯一の相互ドメインリンクがある加入者経路ドメインであると仮定してください。 SURANetがそうなら
Colella, Callon, Gardner & Rekhter [Page 25] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[25ページ]RFC1629NSAPガイドライン1994年5月
assigned an AA identifier kkk, NIST could be assigned an RD of jjj, resulting in a unique prefix for SURANet of:
AA識別子kkkが割り当てられる場合、jjjのRDはNISTに割り当てられるかもしれません、以下のSURANetに、ユニークな接頭語をもたらして
AFI=47, IDI=0005, DFI=80h, AA=kkk
AFI=47、IDI=0005、DFI=80h、AA=kkk
and a unique prefix for NIST of
NISTに、ユニークな接頭語
AFI=47, IDI=0005, DFI=80h, AA=kkk, (Rsvd=0), RD=jjj.
AFI=47、IDI=0005、DFI=80h、AA=kkk、(Rsvd=0)、=第jjj。
A similar scheme can be established using NSAPs allocated under DCC=840. In this case, a direct provider applies for an ORG identifier from ANSI, which serves the same purpose as the AA identifier in GOSIP.
DCC=840の下に割り当てられたNSAPsを使用することで同様の計画を確立できます。 この場合、ダイレクトプロバイダーはANSIからORG識別子に申し込みます。(ANSIはGOSIPのAA識別子と同じ目的に役立ちます)。
5.3.2. Indirect Providers
5.3.2. 間接的なプロバイダー
There does not appear to be a strong case for direct service providers to take their address spaces from the NSAP space of an indirect provider (e.g. backbone in today's terms). The benefit in routing data abstraction is relatively small. The number of direct providers today is in the tens and an order of magnitude increase would not cause an undue burden on the indirect providers. Also, it may be expected that as time goes by there will be increased direct inter-connection of the direct providers, subscriber routing domains directly attached to the "indirect" providers, and international links directly attached to the providers. Under these circumstances, the distinction between direct and indirect providers would become blurred.
直航プロバイダーが間接的なプロバイダー(例えば、今日の用語による背骨)のNSAPスペースからそれらのアドレス空間を取る強いケースはあるように見えません。 ルーティングデータ抽象化による利益は比較的わずかです。 今日、10にはダイレクトプロバイダーの数があります、そして、桁の増加は間接的なプロバイダーの不当な負担を引き起こさないでしょう。 また、時間がそこに過ぎるとき、それはダイレクトプロバイダーの増加するダイレクト相互接続になるでしょう、直接「間接的な」プロバイダーに付けられた加入者経路ドメインと予想されたかもしれなくて、国際的な関係は直接プロバイダーに付きました。 こういう事情ですから、ダイレクトで間接的なプロバイダーの区別はぼけるようになるでしょう。
An additional factor that discourages allocation of NSAPs from an indirect provider's prefix is that the indirect providers and their attached direct providers are perceived as being independent. Direct providers may take their indirect provider service from one or more providers, or may switch indirect providers should a more cost- effective service be available elsewhere (essentially, indirect providers can be thought of the same way as long-distance telephone carriers). Having NSAPs derived from the indirect providers is inconsistent with the nature of the relationship.
間接的なプロバイダーの接頭語からのNSAPsの配分に水をさしている追加要素は間接的なプロバイダーとそれらの付属ダイレクトプロバイダーが独立しているとして知覚されるということです。 ダイレクトプロバイダーは、1つ以上のプロバイダーから彼らの間接的なプロバイダーサービスを取るか、または、より多くの費用有効なサービスがほかの場所で入手できるなら、間接的なプロバイダーを切り換えるかもしれません(本質的には、長距離電話キャリヤーとして同じように間接的なプロバイダーを考えることができます)。 間接的なプロバイダーからNSAPsを得させるのは関係の本質に矛盾しています。
5.4. Multi-homed Routing Domains
5.4. マルチ、家へ帰り、経路ドメイン
The discussions in Section 5.3 suggest methods for allocating NSAP addresses based on service provider connectivity. This allows a great deal of information reduction to be achieved for those routing domains which are attached to a single provider. In particular, such routing domains may select their NSAP addresses from a space allocated to them by their direct service provider. This allows the provider, when announcing the addresses that it can reach to other
セクション5.3における議論はサービスプロバイダーの接続性に基づくアドレスをNSAPに割り当てるための方法を示します。 これは、大きな情報減少がただ一つのプロバイダーに付けられているそれらの経路ドメインに達成されるのを許容します。 特に、そのような経路ドメインはそれらの直航プロバイダーによってそれらに割り当てられたスペースからのそれらのNSAPアドレスを選択するかもしれません。 それが他に達することができるアドレスを発表するとき、これはプロバイダーを許容します。
Colella, Callon, Gardner & Rekhter [Page 26] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[26ページ]RFC1629NSAPガイドライン1994年5月
providers, to use a single address prefix to describe a large number of NSAP addresses corresponding to multiple routing domains.
プロバイダーであり、多くのNSAPについて説明するのにただ一つのアドレス接頭語を使用するのは複数の経路ドメインとの対応を記述します。
However, there are additional considerations for routing domains which are attached to multiple providers. Such "multi-homed" routing domains may, for example, consist of single-site campuses and companies which are attached to multiple providers, large organizations which are attached to different providers at different locations in the same country, or multi-national organizations which are attached to providers in a variety of countries worldwide. There are a number of possible ways to deal with these multi-homed routing domains.
しかしながら、複数のプロバイダーに付けられている経路ドメインへの追加問題があります。 そのようなもの、「マルチ、家へ帰り、」 例えば、経路ドメインはただ一つのサイトキャンパスと複数のプロバイダーに付けられている会社か、同じ国で別の場所の異なったプロバイダーに付けられている大きな組織か、世界中のさまざまな国のプロバイダーに付けられている多国籍の組織から成るかもしれません。 これらに対処する多くの可能な方法がある、マルチ、家へ帰り、経路ドメイン。
One possible solution is to assign addresses to each multi-homed organization independently from the providers to which it is attached. This allows each multi-homed organization to base its NSAP assignments on a single prefix, and to thereby summarize the set of all NSAPs reachable within that organization via a single prefix. The disadvantage of this approach is that since the NSAP address for that organization has no relationship to the addresses of any particular provider, the providers to which this organization is attached will need to advertise the prefix for this organization to other providers. Other providers (potentially worldwide) will need to maintain an explicit entry for that organization in their routing tables. If other providers do not maintain a separate route for this organization, then packets destined to this organization will be lost.
1つの可能な解決策がアドレスをそれぞれに割り当てることである、マルチ、家へ帰り、独自にプロバイダーからそれがどれであるかに付けられた組織。 これがそれぞれを許容する、マルチ、家へ帰り、NSAP課題をただ一つの接頭語に基礎づけて、その結果ただ一つの接頭語を通してその組織の中で届いているすべてのNSAPsのセットをまとめる組織。 このアプローチの不都合はその組織のためのNSAPアドレスにはどんな特定のプロバイダーのアドレスとの関係も全くないのでこの組織が付けているプロバイダーが、この組織のために他のプロバイダーに接頭語の広告を出す必要があるということです。 他のプロバイダー(潜在的に世界的な)は、その組織のためにそれらの経路指定テーブルで明白なエントリーを維持する必要があるでしょう。 他のプロバイダーがこの組織のための別々のルートを維持しないと、この組織に運命づけられたパケットは失われるでしょう。
For example, suppose that a very large U.S.-wide company "Mega Big International Incorporated" (MBII) has a fully interconnected internal network and is assigned a single AA value under the U.S. GOSIP Version 2 address space. It is likely that outside of the U.S., a single entry may be maintained in routing tables for all U.S. GOSIP addresses. However, within the U.S., every "default-less" provider will need to maintain a separate address entry for MBII. If MBII is in fact an international corporation, then it may be necessary for every "default-less" provider worldwide to maintain a separate entry for MBII (including providers to which MBII is not attached). Clearly this may be acceptable if there are a small number of such multihomed routing domains, but would place an unacceptable load on routers within providers if all organizations were to choose such address assignments. This solution may not scale to internets where there are many hundreds of thousands of multi- homed organizations.
例えば、そのaが非常に大きい米国全体の会社であると仮定してください、「メガ、大きさ、国際、取り入れられて、」 (MBII)は完全にインタコネクトされた内部のネットワークを持って、U.S. GOSIPバージョン2アドレス空間の下でただ一つのAA値を割り当てられます。 米国の外では、単一のエントリーがすべてのU.S. GOSIPアドレスのために経路指定テーブルで維持されそうです。 しかしながら、米国の中では、あらゆる「デフォルトなし」のプロバイダーが、MBIIのために別々のアドレスエントリーを維持する必要があるでしょう。 事実上、MBIIが国際会社であるなら、世界中のあらゆる「デフォルトなし」のプロバイダーがMBIIのために別々のエントリーを維持するのが必要であるかもしれません(どのMBIIにプロバイダーを含めるかは付属していません)。 明確に、これは、そのような少ない数の「マルチ-家へ帰」っている経路ドメインがあれば許容できるかもしれませんが、すべての組織がそのようなアドレス課題を選ぶなら、プロバイダーの中に容認できない負荷をルータに置くでしょうに。 この解決策がインターネットに多くの何十万があるところに比例しないかもしれない、マルチ、家へ帰り、組織。
A second possible approach would be for multi-homed organizations to be assigned a separate NSAP space for each connection to a provider, and to assign a single address prefix to each area within its routing
2番目の可能なアプローチがあるだろう、マルチ、家へ帰り、別々のNSAPスペースが各接続のためにプロバイダーに割り当てられて、ルーティングの中でただ一つのアドレス接頭語を各領域に割り当てる組織
Colella, Callon, Gardner & Rekhter [Page 27] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[27ページ]RFC1629NSAPガイドライン1994年5月
domain(s) based on the closest interconnection point. For example, if MBII had connections to two providers in the U.S. (one east coast, and one west coast), as well as three connections to national providers in Europe, and one in the far east, then MBII may make use of six different address prefixes. Each area within MBII would be assigned a single address prefix based on the nearest connection.
最も近いインタコネクトに基づくドメインは指します。 例えば、そして、MBIIに接続が米国(1つの東海岸、および1つの西海岸)に2つのプロバイダーまであったなら、ヨーロッパの国家のプロバイダー、および遠い東の1つの3つの接続対接続と同様に、MBIIは6つの異なったアドレス接頭語を利用するかもしれません。 最も近い接続に基づくただ一つのアドレス接頭語はMBIIの中の各領域に割り当てられるでしょう。
For purposes of external routing of traffic from outside MBII to a destination inside of MBII, this approach works similarly to treating MBII as six separate organizations. For purposes of internal routing, or for routing traffic from inside of MBII to a destination outside of MBII, this approach works the same as the first solution.
MBIIからMBIIの目的地内部までの交通の外部のルーティングの目的に、このアプローチは同様に6つの独立した組織団体としてMBIIを扱うのに効き目があります。 内部のルーティングの目的、またはMBIIの内部から目的地までMBIIの外に交通を発送するのに、このアプローチは最初の解決策として同じように効き目があります。
If we assume that incoming traffic (coming from outside of MBII, with a destination within MBII) is always to enter via the nearest point to the destination, then each provider which has a connection to MBII needs to announce to other providers the ability to reach only those parts of MBII whose address is taken from its own address space. This implies that no additional routing information needs to be exchanged between providers, resulting in a smaller load on the inter-domain routing tables maintained by providers when compared to the first solution. This solution therefore scales better to extremely large internets containing very large numbers of multi- homed organizations.
私たちが、入って来る交通(MBIIの外部から、MBIIの中に目的地がある状態で、来る)が目的地への最も近いポイントでいつも入ることであると思うなら、MBIIには接続がある各プロバイダーは、アドレスがそれ自身のアドレス空間から取られるMBIIのそれらの部分だけに達する能力を他のプロバイダーに発表する必要があります。 これは、どんな追加ルーティング情報も、プロバイダーの間で交換される必要でないのを含意します、最初の解決策と比べるとプロバイダーによって維持された相互ドメイン経路指定テーブルで、よりわずかな負荷をもたらして。 したがって、この解決策が非常に大きい数を含む非常に大きいインターネットによりよく比例する、マルチ、家へ帰り、組織。
One problem with the second solution is that backup routes to multi- homed organizations are not automatically maintained. With the first solution, each provider, in announcing the ability to reach MBII, specifies that it is able to reach all of the NSAPs within MBII. With the second solution, each provider announces that it can reach all of the NSAPs based on its own address prefix, which only includes some of the NSAPs within MBII. If the connection between MBII and one particular provider were severed, then the NSAPs within MBII with addresses based on that provider would become unreachable via inter- domain routing. The impact of this problem can be reduced somewhat by maintenance of additional information within routing tables, but this reduces the scaling advantage of the second approach.
2番目の解決策に関する、ある問題がそのバックアップルートである、マルチ、家へ帰り、組織は自動的に維持されません。 最初の解決策で、MBIIに達する能力を発表する際に、各プロバイダーは、MBIIの中でNSAPsのすべてに達することができると指定します。 2番目の解決策で、各プロバイダーは、MBIIの中にいくつかのNSAPsを含んでいるだけであるそれ自身のアドレス接頭語に基づくNSAPsのすべてに達することができると発表します。 MBIIと1つの特定のプロバイダーとの関係が断ち切られるなら、そのプロバイダーに基づくアドレスがあるMBIIの中のNSAPsは相互ドメインルーティングで手が届かなくなるでしょうに。 この問題の影響は経路指定テーブルの中でいくらか追加情報の維持で減少できますが、これは2番目のアプローチのスケーリング利点を減少させます。
The second solution also requires that when external connectivity changes, internal addresses also change.
また、2番目の解決策は、また、外部の接続性が変化するとき内部のアドレスが変化するのを必要とします。
Also note that this and the previous approach will tend to cause packets to take different routes. With the first approach, packets from outside of MBII destined for within MBII will tend to enter via the point which is closest to the source (which will therefore tend to maximize the load on the networks internal to MBII). With the second solution, packets from outside destined for within MBII will tend to enter via the point which is closest to the destination
また、これと前のアプローチが、パケットが異なったルートを取ることを引き起こす傾向があることに注意してください。 最初のアプローチで、MBIIの中で運命づけられたMBIIの外部からのパケットは、ソース(したがって、MBIIへの内部のネットワークで負荷を最大にする傾向がある)の最も近くにあるポイントで入る傾向があるでしょう。 2番目の解決策で、MBIIの中で運命づけられた外部からのパケットは、目的地の最も近くにあるポイントで入る傾向があるでしょう。
Colella, Callon, Gardner & Rekhter [Page 28] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[28ページ]RFC1629NSAPガイドライン1994年5月
(which will tend to minimize the load on the networks within MBII, and maximize the load on the providers).
(MBIIの中のネットワークで負荷を最小にして、プロバイダーで負荷を最大にする傾向があるでしょう。)
These solutions also have different effects on policies. For example, suppose that country "X" has a law that traffic from a source within country X to a destination within country X must at all times stay entirely within the country. With the first solution, it is not possible to determine from the destination address whether or not the destination is within the country. With the second solution, a separate address may be assigned to those NSAPs which are within country X, thereby allowing routing policies to be followed. Similarly, suppose that "Little Small Company" (LSC) has a policy that its packets may never be sent to a destination that is within MBII. With either solution, the routers within LSC may be configured to discard any traffic that has a destination within MBII's address space. However, with the first solution this requires one entry; with the second it requires many entries and may be impossible as a practical matter.
また、これらの解決策は異なった影響を方針に与えます。 例えば、国「X」には国Xの中のソースから国Xの中の目的地までの交通がいつも完全に国内で残らなければならないという法があると仮定してください。 最初の解決策では、送付先アドレスから国の中に目的地があるかどうか決定するのは可能ではありません。 2番目の解決策で、別々のアドレスは国Xの中にあるそれらのNSAPsに割り当てられるかもしれません、その結果、ルーティング方針が従われるのを許容します。 同様に、その「小さい小会社」(LSC)にパケットが決して送られないかもしれない方針があるなら、MBIIの中に目的地には、それがいます。 解決策で、LSCの中のルータは、MBIIのアドレス空間の中に目的地を持っているどんな交通も捨てるために構成されるかもしれません。 しかしながら、最初の解決策で、これは1つのエントリーを必要とします。 2番目では、それは、多くのエントリーを必要として、実際問題として不可能であるかもしれません。
There are other possible solutions as well. A third approach is to assign each multi-homed organization a single address prefix, based on one of its connections to a provider. Other providers to which the multi-homed organization are attached maintain a routing table entry for the organization, but are extremely selective in terms of which indirect providers are told of this route. This approach will produce a single "default" routing entry which all providers will know how to reach the organization (since presumably all providers will maintain routes to each other), while providing more direct routing in those cases where providers agree to maintain additional routing information.
また、他の可能な解決策があります。 3番目のアプローチがそれぞれを割り当てることである、マルチ、家へ帰り、プロバイダーとの接続のひとりに基づいた組織のaただ一つのアドレス接頭語。 他のプロバイダー、どれ、マルチ、家へ帰り、付けられた組織は、組織のためにa経路指定テーブルエントリーを維持しますが、どの間接的なプロバイダーがこのルートについて言われるかに非常に選択しているか。 このアプローチはすべてのプロバイダーが、プロバイダーが同意するそれらのケースの中によりダイレクトなルーティングを供給している間、どう、組織(おそらくすべてのプロバイダーが互いにルートを維持するので)に達するかが、追加ルーティング情報であることを支持するのを知っている単一の「デフォルト」ルーティングエントリーを起こすでしょう。
There is at least one situation in which this third approach is particularly appropriate. Suppose that a special interest group of organizations have deployed their own backbone. For example, lets suppose that the U.S. National Widget Manufacturers and Researchers have set up a U.S.-wide backbone, which is used by corporations who manufacture widgets, and certain universities which are known for their widget research efforts. We can expect that the various organizations which are in the widget group will run their internal networks as separate routing domains, and most of them will also be attached to other providers (since most of the organizations involved in widget manufacture and research will also be involved in other activities). We can therefore expect that many or most of the organizations in the widget group are dual-homed, with one attachment for widget-associated communications and the other attachment for other types of communications. Let's also assume that the total number of organizations involved in the widget group is small enough that it is reasonable to maintain a routing table containing one
この3番目のアプローチが特に適切である少なくとも1つの状況があります。 組織の特殊利益集団がそれら自身の背骨を配備したと仮定してください。 例えば、米国National Widget ManufacturersとResearchersが米国全体の背骨と彼らのウィジェット研究の努力で知られているある大学を設立したと思わせます。背骨はウィジェットを製造している会社によって使用されます。 経路ドメインを切り離してください。そうすれば、また、それらの大部分が他のプロバイダーに付けられるとき(また、ウィジェット製造と研究にかかわる組織の大部分が他の活動にかかわるので)、私たちは、ウィジェットグループにはある様々な組織がそれらの内部のネットワークを経営していると予想できます。 したがって、私たちが、多くかウィジェットグループにおける組織の大部分がそうであると予想できる、二元的である、-、家へ帰り、ウィジェットで関連しているコミュニケーションに関する1つの付属と他のタイプのコミュニケーションに関するもう片方の付属をもって。 また、ウィジェットグループにかかわる組織の総数が1つを含む経路指定テーブルを維持するのが妥当であるほどわずかであると仮定しましょう。
Colella, Callon, Gardner & Rekhter [Page 29] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[29ページ]RFC1629NSAPガイドライン1994年5月
entry per organization, but that they are distributed throughout a larger internet with many millions of (mostly not widget-associated) routing domains.
1組織あたりのエントリーそれらが、より大きいインターネット中で何百万もの(ウィジェットでほとんど関連しない)の経路ドメインで分配されていなかったなら。
With the third approach, each multi-homed organization in the widget group would make use of an address assignment based on its other attachment(s) to providers (the attachments not associated with the widget group). The widget backbone would need to maintain routes to the routing domains associated with the various member organizations. Similarly, all members of the widget group would need to maintain a table of routes to the other members via the widget backbone. However, since the widget backbone does not inform other general world-wide providers of what addresses it can reach (since the backbone is not intended for use by other outside organizations), the relatively large set of routing prefixes needs to be maintained only in a limited number of places. The addresses assigned to the various organizations which are members of the widget group would provide a "default route" via each members other attachments to providers, while allowing communications within the widget group to use the preferred path.
3番目はアプローチします、それぞれ、マルチ、家へ帰り、ウィジェットグループにおける組織がプロバイダー(ウィジェットグループに関連づけられなかった付属)への他の付属に基づくアドレス課題を利用するでしょう。 ウィジェット背骨は、様々な会員会社に関連している経路ドメインにルートを維持する必要があるでしょう。 同様に、ウィジェットグループのすべてのメンバーが、ウィジェット背骨で他のメンバーにルートのテーブルを維持する必要があるでしょう。 しかしながら、ウィジェット背骨が、それにどんなアドレスに達することができるかを(背骨が使用のために他の外の組織によって意図されないので)他の一般的な世界的なプロバイダーに知らせないので、比較的大きいセットのルーティング接頭語は、限られた数の場所だけで維持される必要があります。 ウィジェットグループの中のコミュニケーションが都合のよい経路を使用するのを許容している間、ウィジェットグループのメンバーである様々な組織に配属されたアドレスはそれぞれを通した「デフォルトルート」メンバーにプロバイダーへの他の付属を提供するでしょう。
A fourth solution involves assignment of a particular address prefix for routing domains which are attached to two or more specific cooperative public service providers. For example, suppose that there are two providers "SouthNorthNet" and "NorthSouthNet" which have a very large number of customers in common (i.e., there are a large number of routing domains which are attached to both). Rather than getting two address prefixes (such as two AA values assigned under the GOSIP address space) these organizations could obtain three prefixes. Those routing domains which are attached to NorthSouthNet but not attached to SouthNorthNet obtain an address assignment based on one of the prefixes. Those routing domains which are attached to SouthNorthNet but not to NorthSouthNet would obtain an address based on the second prefix. Finally, those routing domains which are multi-homed to both of these networks would obtain an address based on the third prefix. Each of these two providers would then advertise two prefixes to other providers, one prefix for subscriber routing domains attached to it only, and one prefix for subscriber routing domains attached to both.
4番目の解決策は2つ以上の特定の協力的な社会奉仕プロバイダーに付けられている経路ドメインに特定のアドレス接頭語の課題にかかわります。 例えば、非常に多くの顧客が共通である2つのプロバイダー"SouthNorthNet"と"NorthSouthNet"があると仮定してください(すなわち、両方に付けられている多くの経路ドメインがあります)。 2つのアドレス接頭語(GOSIPアドレス空間の下で割り当てられた2つのAA値などの)を得るよりむしろ、これらの組織は3つの接頭語を得ることができました。 NorthSouthNetに付けられていますが、SouthNorthNetに付けられていないそれらの経路ドメインは接頭語の1つに基づくアドレス課題を得ます。 SouthNorthNetに付けられていますが、NorthSouthNetに付けられるというわけではないそれらの経路ドメインは2番目の接頭語に基づくアドレスを得るでしょう。 最終的にそうするそれらの経路ドメイン、マルチ、家へ帰り、3番目の接頭語に基づくアドレスをこれらのネットワークの両方に得るでしょう。 次に、それぞれのこれらの2つのプロバイダーが他のプロバイダーに2つの接頭語の広告を出すでしょう、そして、加入者経路ドメインへの1つの接頭語がそれだけに付きました、そして、加入者経路ドメインへの1つの接頭語が両方に付きました。
This fourth solution could become important when use of public data networks becomes more common. In particular, it is likely that at some point in the future a substantial percentage of all routing domains will be attached to public data networks. In this case, nearly all government-sponsored networks (such as some regional networks which receive funding from NSF, as well as government sponsored backbones) may have a set of customers which overlaps substantially with the public networks.
公衆データネットワークの使用が、より一般的になると、この4番目の解決策は重要になるかもしれません。 未来の何らかのポイントでは、特に、すべての経路ドメインのかなりの割合が公衆データネットワークに付けられそうでしょう。 この場合、ほとんどすべての政府によって後援されたネットワーク(NSFからの基金を受けるいくつかの地域ネットワークや、政府の後援された背骨などの)には、実質的に公衆通信回線に重なる顧客のセットがあるかもしれません。
Colella, Callon, Gardner & Rekhter [Page 30] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[30ページ]RFC1629NSAPガイドライン1994年5月
There are therefore a number of possible solutions to the problem of assigning NSAP addresses to multi-homed routing domains. Each of these solutions has very different advantages and disadvantages. Each solution places a different real (i.e., financial) cost on the multi-homed organizations, and on the providers (including those to which the multi-homed organizations are not attached).
したがって、アドレスをNSAPに割り当てるという問題の多くの可能な解決がある、マルチ、家へ帰り、経路ドメイン。 それぞれのこれらの解決策には、非常に異なった利点と損失があります。 各解決策が異なった本当(すなわち、財政的な)の費用を置く、マルチ、家へ帰り、組織、プロバイダー、(それらを含んでいる、どれ、マルチ、家へ帰り、付けられなかった組織)
In addition, most of the solutions described also highlight the need for each provider to develop policy on whether and under what conditions to accept customers with addresses that are not based on its own address prefix, and how such non-local addresses will be treated. For example, a somewhat conservative policy might be that an attached subscriber RD may use any NSAP address prefix, but that addresses which are not based on the providers own prefix might not be advertised to other providers. In a less conservative policy, a provider might accept customers using such non-local prefixes and agree to exchange them in routing information with a defined set of other providers (this set could be an a priori group of providers that have something in common such as geographical location, or the result of an agreement specific to the requesting subscriber). Various policies involve real costs to providers, which may be reflected in those policies.
また、さらに、説明された解決策の大部分は各プロバイダーが扱われて自分自身のがアドレスをもっている基づいていない顧客がオンであると受け入れるどんな条件のもとで接頭語を記述するか、そして、そのような非ローカルのアドレスがどのように扱われるかに関する方針を開発する必要性を強調します。 例えば、いくらか保守的な方針は付属加入者RDがどんなNSAPアドレス接頭語も使用するかもしれないということであるかもしれませんが、プロバイダーに基づいていないアドレスが接頭語を所有しているのは他のプロバイダーに広告を出さないかもしれません。 それほど保守的でない方針で、プロバイダーは、そのような非ローカルの接頭語を使用することで顧客を受け入れて、ルーティング情報で定義されたセットの他のプロバイダーでそれらを交換するのに同意するかもしれません(このセットは地理的な位置、または要求している加入者にとって、特定の協定の結果などのように一脈相通じるものがあるプロバイダーの先験的なグループであるかもしれません)。 様々な方針は本当のコストをプロバイダーに伴います。(プロバイダーはそれらの方針に反映されるかもしれません)。
5.5. Private Links
5.5. 個人的なリンク
The discussion up to this point concentrates on the relationship between NSAP addresses and routing between various routing domains over transit routing domains, where each transit routing domain interconnects a large number of routing domains and offers a more- or-less public service.
議論がこの時点までにそれぞれのトランジット経路ドメインが多くの経路ドメインとインタコネクトして、aをさらに提供するトランジット経路ドメインの上の様々な経路ドメインの間のNSAPアドレスとルーティングとの関係に集中する、なし、社会奉仕。
However, there may also exist a large number of private point-to- point links which interconnect two private routing domains. In many cases such private point-to-point links may be limited to forwarding packets directly between the two private routing domains.
しかしながら、また、個人的なポイントからポイントへの2つの個人的な経路ドメインとインタコネクトする多くのリンクが存在するかもしれません。 多くの場合、そのような個人的なポイントツーポイント接続は2つの個人的な経路ドメインの直接間にパケットを送るのに制限されるかもしれません。
For example, let's suppose that the XYZ corporation does a lot of business with MBII. In this case, XYZ and MBII may contract with a carrier to provide a private link between the two corporations, where this link may only be used for packets whose source is within one of the two corporations, and whose destination is within the other of the two corporations. Finally, suppose that the point-to-point link is connected between a single router (router X) within XYZ corporation and a single router (router M) within MBII. It is therefore necessary to configure router X to know which addresses can be reached over this link (specifically, all addresses reachable in MBII). Similarly, it is necessary to configure router M to know which addresses can be reached over this link (specifically, all
例えば、XYZ会社がMBIIと多くビジネスをすると思いましょう。 この場合、XYZとMBIIは、キャリヤーで2つの会社の間の個人的なリンクを提供するのを契約するかもしれません。そこでは、このリンクが2つの会社の1つの中にソースがあって、2つの会社のもう片方の中に目的地があるパケットに使用されるだけであるかもしれません。 最終的に、ポイントツーポイント接続がXYZ会社の中のただ一つのルータ(ルータX)とMBIIの中のただ一つのルータ(ルータM)の間で接続されると仮定してください。 したがって、どのアドレスにこのリンク(明確にMBIIで届いているすべてのアドレス)の上に達することができるかを知るためにルータXを構成するのが必要です。 同様に、どのアドレスにこのリンクの上に達することができるかを知るためにルータMを構成するのが必要である、(明確にすべて
Colella, Callon, Gardner & Rekhter [Page 31] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[31ページ]RFC1629NSAPガイドライン1994年5月
addresses reachable in XYZ Corporation).
XYZ社で届いているアドレス)
The important observation to be made here is that such private links may be ignored for the purpose of NSAP allocation, and do not pose a problem for routing. This is because the routing information associated with private links is not propagated throughout the internet, and therefore does not need to be collapsed into a provider's prefix.
ここでされる重要な観測はそのような個人的なリンクがNSAP配分の目的のために無視されるかもしれなくて、ルーティングのために問題を設定しないということです。 これは個人的なリンクに関連しているルーティング情報によってインターネット中で伝播されないで、したがって、プロバイダーの接頭語まで潰される必要はないからです。
In our example, lets suppose that the XYZ corporation has a single connection to a service provider, and has therefore received an address allocation from the space administered by that provider. Similarly, let's suppose that MBII, as an international corporation with connections to six different providers, has chosen the second solution from Section 5.4, and therefore has obtained six different address allocations. In this case, all addresses reachable in the XYZ Corporation can be described by a single address prefix (implying that router M only needs to be configured with a single address prefix to represent the addresses reachable over this point-to-point link). All addresses reachable in MBII can be described by six address prefixes (implying that router X needs to be configured with six address prefixes to represent the addresses reachable over the point-to-point link).
私たちの例でさせる、そのプロバイダーによって管理されたスペースからXYZ会社がサービスプロバイダーに単独結合を持って、したがって、アドレス配分を受けたと思わせます。 同様に、MBIIが6つの異なったプロバイダーとの接続がある国際会社としてセクション5.4から2番目の解決策を選んで、したがって、6つの異なったアドレス配分を得たと思いましょう。 この場合、ただ一つのアドレス接頭語(ルータMがただ一つのアドレス接頭語によって構成されて、このポイントツーポイント接続の上で届いているアドレスを表す必要であるだけであるのを含意する)でXYZ社で届いているすべてのアドレスについて説明できます。 6つのアドレス接頭語(ルータXが6つのアドレス接頭語によって構成されて、ポイントツーポイント接続の上で届いているアドレスを表す必要であるのを含意する)でMBIIで届いているすべてのアドレスについて説明できます。
In some cases, such private point-to-point links may be permitted to forward traffic for a small number of other routing domains, such as closely affiliated organizations. This will increase the configuration requirements slightly. However, provided that the number of organizations using the link is relatively small, then this still does not represent a significant problem.
いくつかの場合、そのような個人的なポイントツーポイント接続が他の少ない数の経路ドメインのための交通を進めることが許可されるかもしれません、密接に合併された組織などのように。 これは構成必要条件をわずかに増加させるでしょう。 しかしながら、リンクを使用する組織の数が比較的少なければ、これはまだ重大な問題を表していません。
Note that the relationship between routing and NSAP addressing described in other sections of this paper is concerned with problems in scaling caused by large, essentially public transit routing domains which interconnect a large number of routing domains. However, for the purpose of NSAP allocation, private point-to-point links which interconnect only a small number of private routing domains do not pose a problem, and may be ignored. For example, this implies that a single subscriber routing domain which has a single connection to a "public" provider, plus a number of private point- to-point links to other subscriber routing domains, can be treated as if it were single-homed to the provider for the purpose of NSAP address allocation.
この紙の他のセクションで説明されたルーティングとNSAPアドレシングとの関係は多くの経路ドメインとインタコネクトする大きくて、本質的には公共のトランジット経路ドメインによって引き起こされたスケーリングで問題に関係があることに注意してください。 しかしながら、少ない数の個人的な経路ドメインだけとインタコネクトする個人的なポイントツーポイント接続は、NSAP配分の目的のために、問題を設定しないで、無視されるかもしれません。 例えば、これは、まるでそれがNSAPアドレス配分を目的のためのプロバイダーとシングル家へ帰らせるかのように「公共」のプロバイダーに単独結合を持っているただ一つの加入者経路ドメイン、および他の加入者経路ドメインへの多くの個人的なポイントポイントのリンクを扱うことができるのを含意します。
Colella, Callon, Gardner & Rekhter [Page 32] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[32ページ]RFC1629NSAPガイドライン1994年5月
5.6. Zero-Homed Routing Domains
5.6. 無、家へ帰り、経路ドメイン
Currently, a very large number of organizations have internal communications networks which are not connected to any external network. Such organizations may, however, have a number of private point-to-point links that they use for communications with other organizations. Such organizations do not participate in global routing, but are satisfied with reachability to those organizations with which they have established private links. These are referred to as zero-homed routing domains.
現在、非常に多くの組織には、どんな外部のネットワークにも接続されない内部の通信網があります。 しかしながら、そのような組織は多くのそれらが他の組織とのコミュニケーションに使用する個人的なポイントツーポイント接続を持っているかもしれません。 そのような組織は、グローバルなルーティングに参加しませんが、それらと個人的なリンクを設立したそれらの組織への可到達性に満たされています。 これらが呼ばれる、無、家へ帰り、経路ドメイン。
Zero-homed routing domains can be considered as the degenerate case of routing domains with private links, as discussed in the previous section, and do not pose a problem for inter-domain routing. As above, the routing information exchanged across the private links sees very limited distribution, usually only to the RD at the other end of the link. Thus, there are no address abstraction requirements beyond those inherent in the address prefixes exchanged across the private link.
無、家へ帰り、経路ドメインは、前項で議論するように個人的なリンクがある経路ドメインの堕落したケースであるとみなすことができて、相互ドメインルーティングのために問題を設定しません。 同じくらい上では、個人的なリンクの向こう側に交換されたルーティング情報が非常に限られた分配を見ます、通常リンクのもう一方の端のRDだけに。 したがって、アドレス抽象化要件は全く個人的なリンクの向こう側に交換されたアドレス接頭語に固有のそれらを超えていません。
However, it is important that zero-homed routing domains use valid globally unique NSAP addresses. Suppose that the zero-homed routing domain is connected through a private link to an RD. Further, this RD participates in an internet that subscribes to the global OSI addressing plan (i.e., ISO 8348). This RD must be able to distinguish between the zero-homed routing domain's NSAPs and any other NSAPs that it may need to route to. The only way this can be guaranteed is if the zero-homed routing domain uses globally unique NSAPs.
しかしながら、それが重要である、それ、無、家へ帰り、経路ドメインは有効なグローバルにユニークなNSAPアドレスを使用します。 それを仮定してください、無、家へ帰り、経路ドメインはRDへの個人的なリンクを通してつなげられます。 さらに、このRDはグローバルなOSIアドレシングプラン(すなわち、ISO8348)に加入するインターネットに参加します。 このRDが見分けることができなければならない、無、家へ帰り、ドメインのNSAPsとそれが発送する必要があるかもしれないいかなる他のNSAPsも発送します。 これを保証できる唯一の方法がそうである、無、家へ帰り、経路ドメインはグローバルにユニークなNSAPsを使用します。
5.7. Address Transition Issues
5.7. アドレス変遷問題
Allocation of NSAP addresses based on connectivity to providers is important to allow scaling of inter-domain routing to an internet containing millions of routing domains. However, such address allocation based on topology also implies that a change in topology may result in a change of address.
プロバイダーへの接続性に基づくNSAPアドレスの配分は、インターネットに掘られる相互ドメイン含有のスケーリングに何百万もの経路ドメインを許容するために重要です。 しかしながら、また、トポロジーに基づくそのようなアドレス配分は、トポロジーの変化が住所の変更をもたらすかもしれないのを含意します。
This need to allow for change in addresses is a natural, inevitable consequence of any method for routing data abstraction. The basic notion of routing data abstraction is that there is some correspondence between the address and where a system (i.e., a routing domain, area, or end system) is located. Thus if the system moves, in some cases the address will have to change. If it were possible to change the connectivity between routing domains without changing the addresses, then it would clearly be necessary to keep track of the location of that routing domain on an individual basis.
アドレスにおける変化を考慮するこの必要性はルーティングデータ抽象化のためのどんな方法の自然で、必然の結果です。 ルーティングデータ抽象化の基本的な概念はアドレスの間と、そして、システム(すなわち、経路ドメイン、領域、またはエンドシステム)が位置しているところに何らかの通信があるということです。 したがって、システムが動くと、いくつかの場合、アドレスは変化しなければならないでしょう。 それが経路ドメインの間でアドレスを変えないで接続性を変えるのにおいて可能であるなら、個別的にその経路ドメインの位置の動向をおさえるのが明確に必要でしょうに。
Colella, Callon, Gardner & Rekhter [Page 33] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[33ページ]RFC1629NSAPガイドライン1994年5月
Because of the rapid growth and increased commercialization of the Internet, it is possible that the topology may be relatively volatile. This implies that planning for address transition is very important. Fortunately, there are a number of steps which can be taken to help ease the effort required for address transition. A complete description of address transition issues is outside of the scope of this paper. However, a very brief outline of some transition issues is contained in this section.
急速な成長と増加するインターネットの商用化のために、トポロジーが比較的不安定であることは、可能です。 これは、アドレス変遷の計画を立てるのが非常に重要であることを含意します。 幸い、努力がアドレス変遷のために必要とした容易さを助けるために取ることができる多くの方法があります。 アドレス変遷問題の完全な記述がこの紙の範囲の外にあります。 しかしながら、いくつかの変遷問題の非常に簡潔なアウトラインはこのセクションに含まれています。
Also note that the possible requirement to transition addresses based on changes in topology imply that it is valuable to anticipate the future topology changes before finalizing a plan for address allocation. For example, in the case of a routing domain which is initially single-homed, but which is expecting to become multi-homed in the future, it may be advantageous to assign NSAP addresses based on the anticipated future topology.
また、トポロジーの変化に基づく変遷アドレスへの可能な要件が、アドレス配分のために計画を仕上げる前に将来のトポロジー変化を予期するのが貴重であることを含意することに注意してください。 例えば、経路ドメインの場合では、初めはどれがそうかがシングル家へ帰りましたが、どれがなるようにおめでたの予定であるか、マルチ、家へ帰り、将来、予期された将来のトポロジーに基づくアドレスをNSAPに割り当てるのは有利であるかもしれません。
In general, it will not be practical to transition the NSAP addresses assigned to a routing domain in an instantaneous "change the address at midnight" manner. Instead, a gradual transition is required in which both the old and the new addresses will remain valid for a limited period of time. During the transition period, both the old and new addresses are accepted by the end systems in the routing domain, and both old and new addresses must result in correct routing of packets to the destination.
一般に、それはNSAPアドレスが「真夜中にアドレスを変えてください」という瞬時に起こっている方法で経路ドメインに割り当てた変遷に実用的にならないでしょう。 代わりに、時間の限定期間の間老人と新しいアドレスの両方が有効なままで残っているゆるやかな変遷が必要です。 過渡期の間、経路ドメインのエンドシステムで両方の古くて新しいアドレスを受け入れます、そして、古いものと同様に新しいアドレスは目的地へのパケットの正しいルーティングをもたらさなければなりません。
Provision for transition has already been built into IS-IS. As described in Section 3, IS-IS allows multiple addresses to be assigned to each area specifically for the purpose of easing transition.
既に変遷への支給を組み込んである、- セクション3で説明されるように-、複数のアドレスが特に変遷を緩和する目的のために各領域に割り当てられるのを許容します。
Similarly, there are provisions in OSI for the autoconfiguration of area addresses. This allows OSI end systems to find out their area addresses automatically, either by passively observing the ES-IS IS- Hello packets transmitted by routers, or by actively querying the routers for their NSAP address. If the ID portion of the address is assigned in a manner which allows for globally unique IDs [18], then an end system can reconfigure its entire NSAP address automatically without the need for manual intervention. However, routers will still require manual address reconfiguration.
同様に、条項が領域アドレスの自動構成のためのOSIにあります。 OSIエンドシステムはこれで自動的にそれらの領域アドレスを突き止めることができます、どちらか受け身に見ることによってES存在、存在、こんにちは、パケットが、ルータ、またはそれらのNSAPアドレスのために活発にルータについて質問することによって、伝わりました。 アドレスのID部分が固有のID[18]をグローバルに考慮する方法で割り当てられるなら、エンドシステムは手動の介入の必要性なしで全体のNSAPアドレスを自動的に再構成できます。 しかしながら、それでも、ルータは手動のアドレス再構成を必要とするでしょう。
During the transition period, it is important that packets using the old address be forwarded correctly, even when the topology has changed. This is facilitated by the use of "best match" inter-domain routing.
過渡期の間、正しく旧住所を使用するパケットを進めるのは重要です、トポロジーが変化さえしたとき。 これは「最も良いマッチ」相互ドメインルーティングの使用で容易にされます。
For example, suppose that the XYZ Corporation was previously connected only to the NorthSouthNet provider. The XYZ Corporation
例えば、XYZ社が以前にNorthSouthNetプロバイダーだけに接続されたと仮定してください。 XYZ社
Colella, Callon, Gardner & Rekhter [Page 34] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[34ページ]RFC1629NSAPガイドライン1994年5月
therefore went off to the NorthSouthNet administration and got a routing domain assignment based on the AA value obtained by the NorthSouthNet under the GOSIP address space. However, for a variety of reasons, the XYZ Corporation decided to terminate its association with the North-SouthNet, and instead connect directly to the NewCommercialNet public data network. Thus the XYZ Corporation now has a new address assignment under the ANSI address assigned to the NewCommercialNet. The old address for the XYZ Corporation would seem to imply that traffic for the XYZ Corporation should be routed to the NorthSouthNet, which no longer has any direct connection with XYZ Corporation.
GOSIPアドレス空間の下でしたがって、NorthSouthNet管理へ去って、NorthSouthNetにAA値に基づいた経路ドメイン課題を得させました。 しかしながら、さまざまな理由で、XYZ社は、北部-SouthNetと共に協会を終えて、代わりに直接NewCommercialNet公衆データネットワークに接続すると決めました。 したがって、XYZ社は現在、NewCommercialNetに割り当てられたANSIアドレスの下で新しいアドレス課題を持っています。 XYZ社のための旧住所はXYZ社のための交通がXYZ社との少しのダイレクト接続ももうないNorthSouthNetに発送されるべきであるのを含意するように思えるでしょう。
If the old provider (NorthSouthNet) and the new provider (NewCommercialNet) are adjacent and cooperative, then this transition is easy to accomplish. In this case, packets routed to the XYZ Corporation using the old address assignment could be routed to the NorthSouthNet, which would directly forward them to the NewCommercialNet, which would in turn forward them to XYZ Corporation. In this case only NorthSouthNet and NewCommercialNet need be aware of the fact that the old address refers to a destination which is no longer directly attached to NorthSouthNet.
古いプロバイダー(NorthSouthNet)と新しいプロバイダー(NewCommercialNet)が隣接していて協力的であるなら、この変遷は達成しやすいです。 この場合、旧住所課題を使用することでXYZ社に発送されたパケットはNorthSouthNetに発送できました。(直接、NorthSouthNetはそれらをNewCommercialNetに送るでしょう)。(順番に、NewCommercialNetはXYZ社にそれらを送るでしょう)。 この場合、NorthSouthNetとNewCommercialNetだけが旧住所がもう直接NorthSouthNetに付けられていない目的地について言及するという事実を知っていなければなりません。
If the old provider and the new provider are not adjacent, then the situation is a bit more complex, but there are still several possible ways to forward traffic correctly.
古いプロバイダーと新しいプロバイダーが隣接していないなら、状況はもう少し複雑ですが、正しく交通を進めるいくつかの可能な方法がまだあります。
If the old provider and the new provider are themselves connected by other cooperative providers, then these intermediate domains may agree to forward traffic for XYZ correctly. For example, suppose that NorthSouthNet and NewCommercialNet are not directly connected, but that they are both directly connected to the NSFNET backbone. In this case, all three of NorthSouthNet, NewCommercialNet, and the NSFNET backbone would need to maintain a special entry for XYZ corporation so that traffic to XYZ using the old address allocation would be forwarded via NewCommercialNet. However, other routing domains would not need to be aware of the new location for XYZ Corporation.
古いプロバイダーと新しいプロバイダーが他の協力的なプロバイダーによって接続されるなら、これらの中間的ドメインは、XYZのために正しく交通を進めるのに同意するかもしれません。 例えば、NorthSouthNetとNewCommercialNetが直接接続されませんが、それらがともに直接NSFNET背骨に接続されると仮定してください。 この場合、NorthSouthNet、NewCommercialNet、およびすべての3つのNSFNET背骨が、NewCommercialNetを通して旧住所配分を使用するXYZへの交通を進めて、XYZ会社のために特別なエントリーを維持する必要があるでしょう。 しかしながら、他の経路ドメインはXYZ社において新しい位置を意識している必要はないでしょう。
Suppose that the old provider and the new provider are separated by a non-cooperative routing domain, or by a long path of routing domains. In this case, the old provider could encapsulate traffic to XYZ Corporation in order to deliver such packets to the correct backbone.
古いプロバイダーと新しいプロバイダーが非協力的な経路ドメイン、または経路ドメインの長い経路によって切り離されると仮定してください。 この場合、古いプロバイダーは、そのようなパケットを正しい背骨に届けるためにXYZ社に交通を要約するかもしれません。
Also, those locations which do a significant amount of business with XYZ Corporation could have a specific entry in their routing tables added to ensure optimal routing of packets to XYZ. For example, suppose that another commercial backbone "OldCommercialNet" has a large number of customers which exchange traffic with XYZ
また、XYZ社と共に重要な取引高をするそれらの位置はパケットの最適ルーティングをXYZに確実にするために加えられたそれらの経路指定テーブルに特定のエントリーを持っているかもしれません。 例えば、別の商業背骨"OldCommercialNet"にはXYZと交通を交換する顧客の多くがあると仮定してください。
Colella, Callon, Gardner & Rekhter [Page 35] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[35ページ]RFC1629NSAPガイドライン1994年5月
Corporation, and that this third provider is directly connected to both NorthSouthNet and NewCommercialNet. In this case OldCommercialNet will continue to have a single entry in its routing tables for other traffic destined for NorthSouthNet, but may choose to add one additional (more specific) entry to ensure that packets sent to XYZ Corporation's old address are routed correctly.
社、そして、この3番目のプロバイダーは直接NorthSouthNetとNewCommercialNetの両方に接続されます。 この場合、OldCommercialNetは、NorthSouthNetのために運命づけられた他の交通のための経路指定テーブルに単一のエントリーを持ち続けますが、XYZ社の旧住所に送られたパケットが正しく発送されるのを保証するために1つの追加している(より特定の)エントリーを加えるのを選ぶかもしれません。
Whichever method is used to ease address transition, the goal is that knowledge relating XYZ to its old address that is held throughout the global internet would eventually be replaced with the new information. It is reasonable to expect this to take weeks or months and will be accomplished through the distributed directory system. Discussion of the directory, along with other address transition techniques such as automatically informing the source of a changed address, are outside the scope of this paper.
アドレス変遷を緩和するのに使用される方法、目標は結局グローバルなインターネット中に保持される旧住所にXYZに関連する知識を新情報に取り替えるだろうということです。 それは、これが何週間も何カ月もかかると予想するのが妥当であり、分配されたディレクトリシステムを通して熟達するでしょう。 この紙の範囲の外にディレクトリの議論が変えられたアドレスについて自動的にソースに知らせなどなどの他のアドレス変遷のテクニックと共にあります。
6. Recommendations
6. 推薦
We anticipate that the current exponential growth of the Internet will continue or accelerate for the foreseeable future. In addition, we anticipate a continuation of the rapid internationalization of the Internet. The ability of routing to scale is dependent upon the use of data abstraction based on hierarchical NSAP addresses. As CLNP use increases in the Internet, it is therefore essential to assign NSAP addresses with great care.
私たちは、インターネットの現在の急激な増加が予見できる未来に続くか、または加速すると予期します。 さらに、私たちはインターネットの急速な国際化の継続を予期します。 ルーティングが比例する能力は階層的なNSAPアドレスに基づくデータ抽象化の使用に依存しています。 したがって、CLNP使用がインターネットを増やすのに従って、アドレスをNSAPに細心の注意を払って割り当てるのは不可欠です。
It is in the best interests of the internetworking community that the cost of operations be kept to a minimum where possible. In the case of NSAP allocation, this again means that routing data abstraction must be encouraged.
インターネットワーキング共同体の利益のためでは、操作の費用が可能であるところで最小限に保たれるのは、そうです。 NSAP配分の場合では、これは、再びルーティングデータ抽象化を奨励しなければならないことを意味します。
In order for data abstraction to be possible, the assignment of NSAP addresses must be accomplished in a manner which is consistent with the actual physical topology of the Internet. For example, in those cases where organizational and administrative boundaries are not related to actual network topology, address assignment based on such organization boundaries is not recommended.
データ抽象化が可能であるように、インターネットの実際の物理的なトポロジーと一致した方法でNSAPアドレスの課題を実行しなければなりません。 例えば、組織的で管理の境界が実際のネットワーク形態に関連しないそれらの場合では、そのような組織境界に基づくアドレス課題は推薦されません。
The intra-domain IS-IS routing protocol allows for information abstraction to be maintained at two levels: systems are grouped into areas, and areas are interconnected to form a routing domain. The inter-domain IDRP routing protocol allows for information abstraction to be maintained at multiple levels by grouping routing domains into Routing Domain Confederations and using route aggregation capabilities.
イントラドメイン、-、ルーティング・プロトコルは、情報抽象化が2つのレベルで維持されるのを許容します: システムは領域に分類されます、そして、領域は、経路ドメインを形成するためにインタコネクトされます。 相互ドメインIDRPルーティング・プロトコルは、情報抽象化が複数のレベルで経路ドメインをルート設定Domain Confederationsに分類して、ルート集合能力を使用することによって維持されるのを許容します。
For zero-homed and single-homed routing domains (which are expected to remain zero-homed or single-homed), we recommend that the NSAP
無、家へ帰り、ドメインを発送しながらシングル家へ帰る、(残っていると予想される、無、家へ帰り、シングル家へ帰る、)、私たちがそれを推薦する、NSAP
Colella, Callon, Gardner & Rekhter [Page 36] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[36ページ]RFC1629NSAPガイドライン1994年5月
addresses assigned for OSI use within a single routing domain use a single address prefix assigned to that domain. Specifically, this allows the set of all NSAP addresses reachable within a single domain to be fully described via a single prefix. We recommend that single-homed routing domains use an address prefix based on its connectivity to a public service provider. We recommend that zero- homed routing domains use globally unique addresses.
アドレスはOSIのためにただ一つのアドレス接頭語がそのドメインに割り当てたただ一つの経路ドメイン使用の中で使用を割り当てました。 明確に、これは、単一領域の中で届いているすべてのNSAPアドレスのセットがただ一つの接頭語で完全に説明されるのを許容します。 私たちは、それがアドレス接頭語が接続性に基礎づけたドメイン使用を社会奉仕プロバイダーに発送しながらシングル家へ帰ったことを勧めます。 私たちがそれを推薦する、無、家へ帰り、経路ドメインはグローバルにユニークなアドレスを使用します。
We anticipate that the total number of routing domains existing on a worldwide OSI Internet to be great enough that additional levels of hierarchical data abstraction beyond the routing domain level will be necessary. To provide the needed data abstraction we recommend to use Routing Domain Confederations and route aggregation capabilities of IDRP.
私たちは、経路ドメインを超えた階層データ抽象化の追加レベルが平らにする十分すばらしくなるように世界的なOSIインターネットに存在する経路ドメインの総数が必要になると予期します。 私たちがIDRPのルート設定Domain Confederationsとルート集合能力を使用することを勧める必要なデータ抽象化を提供するために。
The general technical requirements for NSAP address guidelines do not vary from country to country. However, details of address administration may vary between countries. Also, in most cases, network topology will have a close relationship with national boundaries. For example, the degree of network connectivity will often be greater within a single country than between countries. It is therefore appropriate to make specific recommendations based on national boundaries, with the understanding that there may be specific situations where these general recommendations need to be modified. Moreover, that suggests that national boundaries may be used to group domains into Routing Domain Confederations.
NSAPアドレスガイドラインのための一般的な技術的要求事項は国によって違いません。 しかしながら、アドレス管理の細部は国の間で異なるかもしれません。 また、多くの場合、ネットワーク形態には、国境との密接な関係があるでしょう。 例えば、ネットワークの接続性の度合いは国より単一の国の中でしばしばさらに大きくなるでしょう。 したがって、国境に基づく特定の推薦状をするのは適切です、特定の状況がこれらの一般的な推薦が変更される必要があるところにあるかもしれないという条件で。 そのうえ、それは、国境がドメインをルート設定Domain Confederationsに分類するのに使用されるかもしれないのを示します。
Each of the country-specific or continent-specific recommendations presented below are consistent with the technical requirements for scaling of addressing and routing presented in this RFC.
以下に提示されたそれぞれの国の特有の、または、大陸特有の推薦はこのRFCに提示されたアドレシングとルーティングのスケーリングのための技術的要求事項と一致しています。
6.1. Recommendations Specific to U.S. Parts of the Internet
6.1. インターネットの米国の地域に特定の推薦
NSAP addresses for use within the U.S. portion of the Internet are expected to be based primarily on two address prefixes: the ICD=0005 format used by The U.S. Government, and the DCC=840 format defined by ANSI.
インターネットの米国の部分の中の使用のためのNSAPアドレスによって主として2つのアドレス接頭語に基礎づけられると予想されます: 形式が米国政府で使用したICD=0005、および形式がANSIで定義したDCC=840。
We anticipate that, in the U.S., public interconnectivity between private routing domains will be provided by a diverse set of providers, including (but not necessarily limited to) regional providers and commercial Public Data Networks.
間の米国の、そして、公共の相互接続性では、個人的な経路ドメインに私たちはそれを予期しますが、さまざまのセットのプロバイダーによって提供されて、含むのと(必ず有限であるというわけではない。)でしょう。地方のプロバイダーと商業Public Data Networks。
These networks are not expected to be interconnected in a strictly hierarchical manner. For example, the regional providers may be directly connected rather than rely on an indirect provider, and all three of these types of networks may have direct international connections.
厳密に階層的な方法でこれらのネットワークがインタコネクトされないと予想されます。 例えば、地方のプロバイダーは間接的なプロバイダーを当てにするより直接むしろ接続されるかもしれません、そして、ネットワークのこれらのタイプ3人には皆、ダイレクト国際的な接続があるかもしれません。
Colella, Callon, Gardner & Rekhter [Page 37] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[37ページ]RFC1629NSAPガイドライン1994年5月
However, the total number of such providers is expected to remain (for the foreseeable future) small enough to allow addressing of this set of providers via a flat address space. These providers will be used to interconnect a wide variety of routing domains, each of which may comprise a single corporation, part of a corporation, a university campus, a government agency, or other organizational unit.
しかしながら、そのようなプロバイダーの総数がフラットアドレス空間を通して記述するのをこのセットのプロバイダーを許容できるくらい小さいままで残っている(予見できる未来に)と予想されます。 これらのプロバイダーは、さまざまな経路ドメインとインタコネクトするのに使用されるでしょう。それはそれぞれ単一の会社、会社の一部、大学構内、政府機関、または他の組織的なユニットを包括するかもしれません。
In addition, some private corporations may be expected to make use of dedicated private providers for communication within their own corporations.
さらに、いくつかの私法人がコミュニケーションにそれら自身の会社の中でひたむきな個人的なプロバイダーを利用すると予想されるかもしれません。
We anticipate that the great majority of routing domains will be attached to only one of the providers. This will permit hierarchical address abbreviation based on provider. We therefore strongly recommend that addresses be assigned hierarchically, based on address prefixes assigned to individual providers.
私たちは、経路ドメインの大多数がプロバイダーの1つだけに付けられると予期します。 これはプロバイダーに基づく階層的なアドレス略語を可能にするでしょう。 したがって、私たちは、アドレスが個々のプロバイダーに割り当てられたアドレス接頭語に基づいて階層的に割り当てられることを強く勧めます。
For the GOSIP address format, this implies that Administrative Authority (AA) identifiers should be obtained by all providers (explicitly including the NSFNET backbone, the NSFNET regionals, and other major government backbones). For those subscriber routing domains which are connected to a single provider, they should be assigned a Routing Domain (RD) value from the space assigned to that provider.
GOSIPアドレス形式のために、これは、すべてのプロバイダー(明らかに、NSFNET背骨、NSFNET地方版、および他の主要な政府背骨を含んでいる)によってAdministrative Authority(AA)識別子が得られるべきであるのを含意します。 ただ一つのプロバイダーにつなげられるそれらの加入者経路ドメインにおいて、ルート設定Domain(RD)値はそのプロバイダーに割り当てられたスペースからそれらに割り当てられるべきです。
To provide routing information aggregation/abstraction we recommend that each provider together with all of its subscriber domains form a Routing Domain Confederation. That, combined with hierarchical address assignment, would provide significant reduction in the volume of routing information that needs to be handled by IDRP. Note that the presence of multihomed subscriber domains would imply that such Confederations will overlap, which is explicitly supported by IDRP.
ルーティング情報集合/抽象化を提供するために、私たちは、加入者ドメインのすべてに伴う各プロバイダーがルート設定Domain Confederationを形成することを勧めます。 階層的なアドレス課題に結合したそれはIDRPによって扱われる必要があるルーティング情報のボリュームのかなりの減少を供給するでしょう。 「マルチ-家へ帰」っている加入者ドメインの存在が、そのようなConfederations(IDRPによって明らかに支持される)が重なるのを含意することに注意してください。
We recommend that all providers explicitly be involved in the task of address administration for those subscriber routing domains which are single-homed to them. This offers a valuable service to their customers, and also greatly reduces the resources (including human and network resources) necessary for that provider to take part in inter-domain routing.
私たちは、すべてのプロバイダーが明らかにそれらの加入者経路ドメインのためにアドレス管理に関するタスクにかかわって、どれがあるかがそれらとシングル家へ帰ったということであることを推薦します。 これは、彼らの顧客に対する貴重なサービスを提供して、また、そのプロバイダーが相互ドメインルーティングに参加するのに必要なリソース(人間とネットワーク資源を含んでいる)を大いに減らします。
Each provider should develop policy on whether and under what conditions to accept customers using addresses that are not based on the provider's own address prefix, and how such non-local addresses will be treated. Policies should reflect the issue of cost associated with implementing such policies.
各プロバイダーは扱われて基づいていないアドレスを使用している顧客がプロバイダーのところで受け入れるどんな条件のもとでアドレス接頭語を所有するか、そして、そのような非ローカルのアドレスがどのように扱われるかに関する方針を開発するべきです。 方針はそのような政策を実施すると関連しているコストの問題を反映するべきです。
We recommend that a similar hierarchical model be used for NSAP addresses using the DCC-based address format. The structure for
私たちは、同様の階層的なモデルがNSAPアドレスにDCCベースのアドレス形式を使用することで使用されることを勧めます。 構造
Colella, Callon, Gardner & Rekhter [Page 38] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[38ページ]RFC1629NSAPガイドライン1994年5月
DCC=840-based NSAPs is provided in Section A.2.
DCC=840ベースのNSAPsをセクションA.2に提供します。
For routing domains which are not attached to any publically- available provider, no urgent need for hierarchical address abbreviation exists. We do not, therefore, make any additional recommendations for such "isolated" routing domains, except to note that there is no technical reason to preclude assignment of GOSIP AA identifier values or ANSI organization identifiers to such domains. Where such domains are connected to other domains by private point- to-point links, and where such links are used solely for routing between the two domains that they interconnect, no additional technical problems relating to address abbreviation is caused by such a link, and no specific additional recommendations are necessary.
どんなpublicallyに利用可能なプロバイダーにも付けられていない経路ドメインに、階層的なアドレス略語のどんな緊急の必要性も存在していません。 私たちはしたがって、そのような「孤立している」経路ドメインのための少しの追加推薦状もしません、GOSIP AA識別子値かANSI組織識別子の課題をそのようなドメインに排除するどんな技術的な理由もないことに注意するのを除いて。 そのようなドメインがどこでポイントへの個人的なポイントリンクによって他のドメインにつなげられるか、そして、唯一2つのドメインの間のそれらがインタコネクトするルーティング、アドレス略語に関連するのがそのようなリンクによって引き起こされる追加技術的問題がなく、およびどんな特定の追加推薦においても、そのようなリンクがどこで使用されているかはどんな必要ではありません。
6.2. Recommendations Specific to European Parts of the Internet
6.2. インターネットのヨーロッパの地域に特定の推薦
This section contains additional RARE recommendations for allocating NSAP addresses within each national domain, administered by a National Standardization Organization (NSO) and national research network organizations.
このセクションはNational Standardization Organization(NSO)によって管理されたそれぞれの国家のドメインの中にアドレスをNSAPに割り当てるための追加RARE推薦と国家の研究ネットワーク組織を含みます。
NSAP addresses are expected to be based on the ISO DCC scheme. Organizations which are not associated with a particular country and which have reasons not to use a national prefix based on ISO DCC should follow the recommendations covered in chapters 6.3 and 6.4.
NSAPアドレスによってISO DCC計画に基礎づけられると予想されます。 特定の国に関連づけられないで、ISO DCCに基づく国家の接頭語を使用しない理由を持っている組織は第6.3章と第6.4章でカバーされた推薦に続くべきです。
ISO DCC addresses are not associated with any specific subnetwork type and service provider and are thus independent of the type or ownership of the underlying technology.
ISO DCCアドレスは、どんな特定のサブネットワークタイプとサービスプロバイダーにも関連づけられないで、その結果、基本的な技術のタイプか所有権から独立しています。
Colella, Callon, Gardner & Rekhter [Page 39] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[39ページ]RFC1629NSAPガイドライン1994年5月
6.2.1. General NSAP Structure
6.2.1. 一般NSAP構造
The general structure of a Network Address defined in ISO 8348 is further divided into:
ISO8348で定義されたNetwork Addressの一般構造体はさらに以下に分割されます。
+-----------+-----------------------------------------+
| IDP | DSP |
+-----+-----+-----------+-----------------------------+
| AFI | IDI | CDP | CDSP |
+-----+-----+-----+-----+----------------+------+-----+
| AFI | IDI | CFI | CDI | RDAA | ID | SEL |
+-----+-----+-----+-----+----------------+------+-----+
octets | 1 | 2 | 2..4 | 0..13 | 1..8 | 1 |
+-----+-----+-----------+----------------+------+-----+
+-----------+-----------------------------------------+ | IDP| DSP| +-----+-----+-----------+-----------------------------+ | AFI| イディ| CDP| CDSP| +-----+-----+-----+-----+----------------+------+-----+ | AFI| イディ| CFI| CDI| RDAA| ID| SEL| +-----+-----+-----+-----+----------------+------+-----+ 八重奏| 1 | 2 | 2..4 | 0..13 | 1..8 | 1 | +-----+-----+-----------+----------------+------+-----+
IDP Initial Domain Part
AFI Authority and Format Identifier, two-decimal-digit,
38 for decimal abstract syntax of the DSP or
39 for binary abstract syntax of the DSP
IDI Initial Domain Identifier, a three-decimal-digit
country code, as defined in ISO 3166
DSP Domain Specific Part
CDP Country Domain Part, 2..4 octets
CFI Country Format Identifier, one digit
CDI Country Domain Identifier, 3 to 7 digits, fills
CDP to an octet boundary
CDSP Country Domain Specific Part
RDAA Routing Domain and Area Address
ID System Identifier (1..8 octet)
SEL NSAP Selector
ISO3166DSP Domain Specific Part CDP Country Domain Part、2の定義されるとしてのIDP Initial Domain Part AFI AuthorityとFormat Identifierか2 10進数字かDSPの10進抽象構文のための38かDSP IDI Initial Domain Identifierの2進の抽象構文、3 10進数字の国名略号のための39。4 八重奏CFI Country Format Identifier、1ケタのCDI Country Domain Identifier(3〜7ケタ)は八重奏CDSP Country Domain Specific Part RDAAルート設定DomainとArea Address ID System Identifier(1 .8八重奏)SEL NSAP Selector境界にCDPをいっぱいにしています。
The total length of an NSAP can vary from 7 to 20 octets.
NSAPの全長は7〜20の八重奏を変えることができます。
6.2.2. Structure of the Country Domain Part
6.2.2. 国のドメイン部分の構造
The CDP identifies an organization within a country and the CDSP is then available to that organization for further internal structuring as it wishes. Non-ambiguity of addresses is ensured by there being the NSO a single national body that allocates the CDPs.
CDPは国の中で組織を特定します、そして、次に、CDSPは願っているように一層の内部の構造のためのその組織に利用可能です。 そこによるCDPsを割り当てるNSOのa単一の国家体であることはアドレスの非のあいまいさに確実にされます。
The CDP is further divided into CFI and CDI, where the CFI identifies the format of the CDI. The importance of this is that it enables several types of CDI to be assigned in parallel, corresponding to organizations with different requirements and giving different amounts of the total address space to them, and that it conveniently enables a substantial amount of address space to be reserved for future allocation.
CDPはさらにCFIとCDIに分割されます。そこでは、CFIがCDIの形式を特定します。 この重要性はCDIのいくつかのタイプが異なった要件で組織に対応する総アドレス空間の異なった量をそれらに与えている類似で選任されるのを可能にして、かなりの量のアドレス空間が今後の配分のために予約されるのを便利に可能にするということです。
Colella, Callon, Gardner & Rekhter [Page 40] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[40ページ]RFC1629NSAPガイドライン1994年5月
The possible structures of the CDP are as follows:
CDPの可能な構造は以下の通りです:
CFI = /0 reserved
CFI = /1 CDI = /aaa very large organizations or
trade associations
CFI = /2 CDI = /aaaaa organizations of intermediate size
CFI = /3 CDI = /aaaaaaa small organizations and single users
CFI = /4../F reserved
CFI=/0は中間的サイズのCFI=/3のCDI=/aaaaaaaの小さい組織とシングルユーザーCFI=/4のCFI=/1CDI=/aaa非常に大きい組織か産業団体CFI=/2CDI=/aaaaa組織を控えました。Fが予約した/
Note: this uses the hexadecimal reference publication format defined in ISO 8348 of a solidus "/" followed by a string of hexadecimal digits. Each "a" represents a hexadecimal digit.
以下に注意してください。 「16進参照公表がフォーマットするこの用途は8348ISOソリドゥスで」 /を定義したこと」が一連の16進数字で続きました。 各“a"は16進数字を表します。
Organizations are classified into large, medium and small for the purpose of address allocation, and one CFI is made available for each category of organization.
組織は、アドレス配分の目的のために大きく分類されて、中型であって、小さいです、そして、1CFIを組織の各カテゴリに利用可能にします。
This recommendation for CDP leaves space for the U.S. GOSIP Version 2 NSAP model (Appendix A.1) by the reserved CFI /8, nevertheless it is not recommended for use in the European Internet.
CDPのためのこの推薦はU.S. GOSIPバージョン2NSAPモデル(付録A.1)のために予約されたCFI /8で間隔を取ります、それにもかかわらず、それがヨーロッパのインターネットでの使用のために推薦されません。
6.2.3. Structure of the Country Domain Specific Part
6.2.3. 国のドメインの特定の部分の構造
The CDSP must have a structure (within the decimal digit or binary octet syntax selected by the AFI value 38 or 39) satisfying both the routing requirements (IS-IS) and the logical requirements of the organization identified (CFI + CDI).
CDSPには構造(AFI値38か39によって選択された10進数字か2進の八重奏構文の中の)が両方のルーティング要件を満たしながらなければならない、(-、)、そして、特定された組織(CFI+CDI)の論理的な要件。
6.3. Recommendations Specific to Other Parts of the Internet
6.3. インターネットの他の地域に特定の推薦
For the part of the Internet which is outside of the U.S. and Europe, it is recommended that the DSP format be structured hierarchically similarly to that specified within the U.S. and Europe no matter whether the addresses are based on DCC or ICD format.
米国とヨーロッパの外にあるインターネットの地域において、アドレスがDCCかICD形式に基づいて、DSP形式が階層的で同様に米国とヨーロッパの中で指定されたそれに構造化されるのは、お勧めです。
Further, in order to allow aggregation of NSAPs at national boundaries into as few prefixes as possible, we further recommend that NSAPs allocated to routing domains should be assigned based on each routing domain's connectivity to a national Internet backbone.
さらに、国境にできるだけわずかしかNSAPsの集合を接頭語に許容しないように、私たちは、経路ドメインに割り当てられたNSAPsが国家のインターネットの基幹への各経路ドメインの接続性に基づいて割り当てられるべきであることをさらに勧めます。
6.4. Recommendations for Multi-Homed Routing Domains
6.4. 推薦、マルチ、家へ帰り、経路ドメイン
Some routing domains will be attached to multiple providers within the same country, or to providers within multiple countries. We refer to these as "multi-homed" routing domains. Clearly the strict hierarchical model discussed above does not neatly handle such routing domains.
いくつかの経路ドメインが同じ国の中の複数のプロバイダー、または、複数の国の中のプロバイダーに付けられるでしょう。 私たちがこれらを参照する、「マルチ、家へ帰り、」 ドメインを発送します。 明確に、上で議論した厳しい階層的なモデルはそのような経路ドメインをきちんと扱いません。
Colella, Callon, Gardner & Rekhter [Page 41] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[41ページ]RFC1629NSAPガイドライン1994年5月
There are several possible ways that these multi-homed routing domains may be handled. Each of these methods vary with respect to the amount of information that must be maintained for inter-domain routing and also with respect to the inter-domain routes. In addition, the organization that will bear the brunt of this cost varies with the possible solutions. For example, the solutions vary with respect to:
いくつかの可能な道がある、それ、これら、マルチ、家へ帰り、経路ドメインは扱われるかもしれません。 それぞれのこれらの方法は相互ドメインルーティングと相互ドメインルートに関しても維持しなければならない情報量に関して異なります。 さらに、この費用のほこさきに堪える組織は可能な解決策で異なります。 例えば、解決策は以下に関して異なります。
* resources used within routers within the providers;
* プロバイダーの中のルータの中の運用資金。
* administrative cost on provider personnel; and,
* プロバイダー人員の管理費。 そして
* difficulty of configuration of policy-based inter-domain
routing information within subscriber routing domains.
* 加入者経路ドメインの中の方針ベースの相互ドメインルーティング情報の構成の困難。
Also, the solution used may affect the actual routes which packets follow, and may effect the availability of backup routes when the primary route fails.
また、使用される解決策は、パケットが従う実際のルートに影響して、幹線道路が失敗すると、バックアップルートの有用性に作用するかもしれません。
For these reasons it is not possible to mandate a single solution for all situations. Rather, economic considerations will require a variety of solutions for different subscriber routing domains and providers.
これらの理由で、すべての状況のただ一つの解決策を強制するのは可能ではありません。 むしろ、経済上の考慮は異なった加入者経路ドメインとプロバイダーのさまざまな解決を必要とするでしょう。
6.5. Recommendations for RDI and RDCI assignment
6.5. RDIのための推薦とRDCI課題
While RDIs and RDCIs need not be related to the set of addresses within the domains (confederations) they depict, for the sake of simplicity we recommend that RDIs and RDCIs be assigned based on the NSAP prefixes assigned to domains and confederations.
RDIsとRDCIsが彼らが表現するドメイン(同盟者)の中のアドレスのセットに関連する必要はない間、簡単にするために私たちは、RDIsとRDCIsがドメインと同盟者に割り当てられたNSAP接頭語に基づいて割り当てられることを勧めます。
A subscriber RD should use the NSAP prefix assigned to it as its RDI. A multihomed RD should use one of the NSAP prefixes assigned to it as its RDI. If a service provider forms a Routing Domain Confederation with some of its subscribers and the subscribers take their addresses out of the provider, then the NSAP prefix assigned to the provider should be used as the RDCI of the confederation. In this case the provider may use a longer NSAP prefix for its own RDIs. In all other cases a provider should use the address prefix that it uses for assigning addresses to systems within the provider as its RDI.
加入者RDはRDIとしてそれに割り当てられたNSAP接頭語を使用するはずです。 multihomed RDはRDIとしてそれに割り当てられたNSAP接頭語の1つを使用するはずです。 サービスプロバイダーが何人かの加入者と共にルート設定Domain Confederationを形成して、加入者がプロバイダーから彼らのアドレスを取り出すなら、プロバイダーに割り当てられたNSAP接頭語は同盟者のRDCIとして使用されるべきです。 この場合、プロバイダーはそれ自身のRDIsにより長いNSAP接頭語を使用するかもしれません。 他のすべての場合では、プロバイダーはそれがRDIとしてプロバイダーの中でアドレスをシステムに割り当てるのに使用するアドレス接頭語を使用するべきです。
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo (except for the discussion of IS-IS authentication in Section 3.2).
中、このメモで安全保障問題について議論しない、(議論、-、認証、セクション3.2)
Colella, Callon, Gardner & Rekhter [Page 42] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[42ページ]RFC1629NSAPガイドライン1994年5月
8. Authors' Addresses
8. 作者のアドレス
Richard P. Colella National Institute of Standards & Technology Building 225/Room B217 Gaithersburg, MD 20899
規格のリチャードP.Colella国家の研究所とB217ゲイザースバーグ、技術Building225/余地MD 20899
Phone: (301) 975-3627 EMail: colella@nist.gov
以下に電話をしてください。 (301) 975-3627 メールしてください: colella@nist.gov
Ross Callon c/o Wellfleet Communications, Inc 2 Federal Street Billerica, MA 01821
Wellfleetコミュニケーション、ビルリカ、ロスCallon気付のInc2の連邦政府の通りMA 01821
Phone: (508) 436-3936 EMail: callon@wellfleet.com
以下に電話をしてください。 (508) 436-3936 メールしてください: callon@wellfleet.com
Ella P. Gardner The MITRE Corporation 7525 Colshire Drive McLean, VA 22102-3481
エラ・P.ガードナー・斜め継ぎ社7525のColshire Driveマクリーン、ヴァージニア22102-3481
Phone: (703) 883-5826 EMail: epg@gateway.mitre.org
以下に電話をしてください。 (703) 883-5826 メールしてください: epg@gateway.mitre.org
Yakov Rekhter T.J. Watson Research Center, IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598
ニューヨーク ヤコフRekhter T.J.ワトソン研究所、IBM社の私書箱218ヨークタウンの高さ、10598
Phone: (914) 945-3896 EMail: yakov@watson.ibm.com
以下に電話をしてください。 (914) 945-3896 メールしてください: yakov@watson.ibm.com
9. Acknowledgments
9. 承認
The authors would like to thank the members of the IETF OSI-NSAP Working Group and of RARE WG4 for the helpful suggestions made during the writing of this paper. We would also like to thank Radia Perlman of Novell, Marcel Wiget of SWITCH, and Cathy Wittbrodt of BARRnet for their ideas and help.
作者はこの紙の書くことの間にされた役立つ提案についてIETF OSI-NSAP作業部会とRARE WG4のメンバーに感謝したがっています。 彼らの考えについてノベルのRadiaパールマン、SWITCHのマルセルWiget、およびBARRnetのキャシーWittbrodtに感謝します、そして、また、助けたいと思います。
Colella, Callon, Gardner & Rekhter [Page 43] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[43ページ]RFC1629NSAPガイドライン1994年5月
10. References
10. 参照
[1] ANSI, "American National Standard for the Structure and Semantics
of the Domain-Specific Part (DSP) of the OSI Network Service
Access Point (NSAP) Address", American National Standard X3.216-
1992.
[1] ANSI、「OSIネットワークサービスアクセスポイント(NSAP)アドレスのドメイン特有の部分(DSP)の構造と意味論のための米国標準規格」米国標準規格X3.216 1992。
[2] Boland, T., "Government Open Systems Interconnection Profile
Users' Guide Version 2 [DRAFT]", NIST Special Publication,
National Institute of Standards and Technology, Computer Systems
Laboratory, Gaithersburg, MD, June 1991.
[2] ボーランド、T.、「政府オープンシステムインタコネクトはユーザのガイドバージョン2[草稿]の輪郭を描きます」、NISTの特別な公表、米国商務省標準技術局、コンピュータシステム研究所、ゲイザースバーグ(MD)1991年6月。
[3] GOSIP Advanced Requirements Group, "Government Open Systems
Interconnection Profile (GOSIP) Version 2", Federal Information
Processing Standard 146-1, U.S. Department of Commerce, National
Institute of Standards and Technology, Gaithersburg, MD, April
1991.
[3] GOSIPの高度な要件グループ、「政府オープンシステムインタコネクトはバージョン2インチ、連邦情報処理基準146-1、(GOSIP)米国商務省の輪郭を描きます、米国商務省標準技術局、ゲイザースバーグ(MD)1991年4月。」
[4] Hemrick, C., "The OSI Network Layer Addressing Scheme, Its
Implications, and Considerations for Implementation", NTIA Report
85186, U.S. Department of Commerce, National Telecommunications
and Information Administration, 1985.
[4] Hemrick、C.、「OSIネットワーク層は実現のために計画、含意、および問題を記述し」て、NTIAは85186、米国の商務省、電気通信情報局、1985を報告します。
[5] ISO, "Addendum to the Network Service Definition Covering Network
Layer Addressing," RFC 941, ISO, April 1985.
[5] ISO、「ネットワーク・サービス定義へのネットワーク層アドレシングをカバーする付加物」、RFC941、ISO、1985年4月。
[6] ISO/IEC, "Codes for the Representation of Names of Countries",
International Standard 3166, ISO/IEC JTC 1, Switzerland, 1984.
[6] ISO/IEC、「国の名前の表現のためのコード」、国際規格3166、ISO/IEC JTC1、スイス1984。
[7] ISO/IEC, "Data Interchange - Structures for the Identification of
Organization", International Standard 6523, ISO/IEC JTC 1,
Switzerland, 1984.
[7] ISO/IEC、「データは交換されます--組織の識別のための構造」、国際規格6523、JTC1、ISO/IECスイス1984
[8] ISO/IEC, "Information Processing Systems - Open Systems
Interconnection -- Basic Reference Model", International Standard
7498, ISO/IEC JTC 1, Switzerland, 1984.
[8] ISO/IEC、「情報処理システム--オープン・システム・インターコネクション--基本参照モデル」、国際規格7498、ISO/IEC JTC1、スイス1984。
[9] ISO/IEC, "Protocol for Providing the Connectionless-mode Network
Service", International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
[9] ISO/IEC、「コネクションレスなモードネットワーク・サービスを提供するためのプロトコル」、国際規格8473、ISO/IEC JTC1、スイス1986。
[10] ISO/IEC, "End System to Intermediate System Routing Exchange
Protocol for use in Conjunction with the Protocol for the
Provision of the Connectionless-mode Network Service",
International Standard 9542, ISO/IEC JTC 1, Switzerland, 1987.
[10]ISO/IEC、「プロトコルがあるConjunctionにおける、Connectionless-モードNetwork ServiceのProvisionの使用のためのIntermediate Systemルート設定Exchangeプロトコルへの終わりのSystem」、国際Standard9542、IEC JTC1、ISO/スイス1987。
Colella, Callon, Gardner & Rekhter [Page 44] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[44ページ]RFC1629NSAPガイドライン1994年5月
[11] ISO/IEC, "Information Processing Systems -- Data Communications
-- Network Service Definition", International Standard 8348,
1992.
[11]ISO/IEC、「情報処理システム--データ通信--ネットワーク・サービス定義」、国際規格8348、1992。
[12] ISO/IEC, "Information Processing Systems - OSI Reference Model -
Part3: Naming and Addressing", Draft International Standard
7498-3, ISO/IEC JTC 1, Switzerland, March 1989.
[12] ISO/IEC、「情報処理システム--OSI規範モデル--Part3:、」 「命名とアドレシング」は7498-3と、1989年のISO/IECのJTC1、スイスの行進のときに国際規格を作成します。
[13] ISO/IEC, "Information Technology - Telecommunications and
Information Exchange Between Systems - OSI Routeing Framework",
Technical Report 9575, ISO/IEC JTC 1, Switzerland, 1989.
[13]ISO/IEC、「情報技術--システムの間のテレコミュニケーションと情報交換--OSI Routeing枠組み」、技術報告書9575、ISO/IEC JTC1、スイス1989。
[14] ISO/IEC, "Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-Mode Network Service
(ISO 8473)", International Standard ISO/IEC 10589, 1992.
[14]ISO/IEC、「プロトコルがあるConjunctionにおける、Providing Connectionless-モードNetwork Service(ISO8473)の使用のためのIntermediate System Intra-ドメインRouteing Exchangeプロトコルへの中間的System」国際規格ISO/IEC10589、1992。
[15] Loughheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3)" RFC 1267, cisco Systems, T.J. Watson Research Center,
IBM Corp., October 1991.
[15] K.、およびY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP-3)」RFC1267、Loughheedされました、コクチマスSystems、T.J.ワトソン研究所、IBM社、1991年10月。
[16] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing
Information among Intermediate Systems to support Forwarding of
ISO 8473 PDUs", International Standard 10747, ISO/IEC JTC 1,
Switzerland 1993.
[16]ISO/IEC、「議定書を作って、Intermediate Systemsの中のInter-ドメインRouteing情報のExchangeはISO8473PDUsのForwardingを支持してください」、インターナショナルであるというStandard10747、IEC JTC1、ISO/スイス1993。
[17] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
Proposal for Internet Addressing and Routing", RFC 1347, DEC,
June 1992.
[17] Callon、R.、「より大きいのがあるTCPとUDPは(tuba)、インターネットアドレシングとルート設定のための簡単な提案を記述します」、RFC1347、1992年12月、6月。
[18] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP
Hosts", RFC 1526, Bellcore, September 1993.
[18]Piscitello、D.、「チューバ/CLNPホストへのシステム識別子の課題」、RFC1526、Bellcore、1993年9月。
[19] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, BARRNet, cisco, OARnet, September 1993.
[19] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「Address AssignmentとAggregation Strategy」、RFC1519、BARRNet、コクチマス、OARnet、9月1993日
[20] ISO/IEC JTC1/SC6, "Addendum to ISO 9542 Covering Address
Administration", N6273, March 1991.
[20]ISO/IEC JTC1/SC6、「ISO9542へのアドレス管理をカバーする付加物」、N6273、1991年3月。
Colella, Callon, Gardner & Rekhter [Page 45] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[45ページ]RFC1629NSAPガイドライン1994年5月
A. Administration of NSAPs
A。 NSAPsの政権
NSAPs represent the endpoints of communication through the Network Layer and must be globally unique [4]. ISO 8348 defines the semantics of the NSAP and the abstract syntaxes in which the semantics of the Network address can be expressed [11].
NSAPsはNetwork Layerを通してコミュニケーションの終点を表して、グローバルにユニークな[4]であるに違いありません。 ISO8348はNetworkアドレスの意味論を言い表すことができるNSAPの意味論と抽象構文を定義します。[11]。
The NSAP consists of the initial domain part (IDP) and the domain specific part (DSP). The initial domain part of the NSAP consists of an authority and format identifier (AFI) and an initial domain identifier (IDI). The AFI specifies the format of the IDI, the network addressing authority responsible for allocating values of the IDI, and the abstract syntax of the DSP. The IDI specifies the addressing subdomain from which values of the DSP are allocated and the network addressing authority responsible for allocating values of the DSP from that domain. The structure and semantics of the DSP are determined by the authority identified by the IDI. Figure 3 shows the NSAP address structure.
NSAPは初期のドメイン部分(IDP)とドメインの特定の部分(DSP)から成ります。 NSAPの初期のドメイン部分は権威、形式ID(AFI)、および初期のドメイン識別子(IDI)から成ります。 AFIはIDI(IDIの値、およびDSPの抽象構文を割り当てるのに原因となるネットワークアドレシング権威)の形式を指定します。 IDIはDSPの値が割り当てられるアドレシングサブドメインとそのドメインからDSPの値を割り当てるのに原因となるネットワークアドレシング権威を指定します。 DSPの構造と意味論はIDIによって特定された権威で決定します。 図3はNSAPアドレス構造を示しています。
+-----------+
| IDP |
+-----+-----+-------------------------------------------------+
| AFI | IDI |<--------------------DSP------------------------>|
+-----+-----+-------------------------------------------------+
+-----------+ | IDP| +-----+-----+-------------------------------------------------+ | AFI| イディ| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--DSP------------------------>| +-----+-----+-------------------------------------------------+
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
IDPの初期のドメイン部分AFI権威と初期の形式IDのドメイン識別子DSPドメイン特定のIDI一部
Figure 3: NSAP address structure.
図3: NSAPは構造を記述します。
The global network addressing domain consists of all the NSAP addresses in the OSI environment. Within that environment, seven second-level addressing domains and corresponding IDI formats are described in ISO 8348:
世界的なネットワークアドレス指定領域はOSI環境におけるすべてのNSAPアドレスから成ります。 その環境の中では、7つの第2レベルアドレス指定領域と対応するIDI形式がISO8348で説明されます:
* X.121 for public data networks
* 公衆データネットワークのためのX.121
* F.69 for telex
* テレックスのためのF.69
* E.163 for the public switched telephone network numbers
* 公衆電話交換網番号のためのE.163
* E.164 for ISDN numbers
* ISDN番号のためのE.164
* ISO Data Country Code (DCC), allocated according to ISO 3166 [6]
* ISO3166に応じて割り当てられたISO Data Country Code(DCC)[6]
Colella, Callon, Gardner & Rekhter [Page 46] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[46ページ]RFC1629NSAPガイドライン1994年5月
* ISO International Code Designator (ICD), allocated according to
ISO 6523 [7]
* ISO6523に応じて割り当てられたISO国際旗信号Designator(ICD)[7]
* Local to accommodate the coexistence of OSI and non-OSI network
addressing schemes.
* OSIと非OSIネットワークアドレシング計画の共存を収容するために、地方です。
For OSI networks in the U.S., portions of the ICD subdomain are available for use through the U.S. Government, and the DCC subdomain is available for use through The American National Standards Institute (ANSI). The British Standards Institute is the registration authority for the ICD subdomain, and has registered four IDIs for the U.S. Government: those used for GOSIP, DoD, OSINET, and the OSI Implementors Workshop. ANSI, as the U.S. ISO Member Body, is the registration authority for the DCC domain in the United States.
米国政府のを通した使用について、米国のOSIネットワークにおいて、ICDサブドメインの部分があります、そして、American National Standards Institut(ANSI)のを通した使用について、DCCサブドメインがあります。 イギリスのStandards InstituteはICDサブドメインのための登録局であり、米国政府のために4IDIsを登録しました: GOSIP、DoD、OSINET、およびOSI Implementors Workshopに使用されるもの。 U.S. ISOメンバーBodyとして、ANSIは合衆国のDCCドメインへの登録局です。
A.1 GOSIP Version 2 NSAPs
A.1 GOSIPバージョン2NSAPs
GOSIP Version 2 makes available for government use an NSAP addressing subdomain with a corresponding address format as illustrated in Figure 2 in Section 4.2. The "47" signifies that it is based on the ICD format and uses a binary syntax for the DSP. The 0005 is an IDI value which has been assigned to the U.S. Government. Although GOSIP Version 2 NSAPs are intended primarily for U.S. Government use, requests from non-government and non-U.S. organizations will be considered on a case-by-case basis.
GOSIPバージョン2で、NSAPアドレシングサブドメインはセクション4.2の図2で例証されるように対応するアドレス形式で政府使用に利用可能になります。 「47インチは、それがICD形式に基づいているのを意味して、DSPに2進の構文を使用します。」 0005は米国政府に配属されたIDI値です。 GOSIPバージョン2NSAPsは主として米国政府使用のために意図しますが、非政府とnon-U.S.組織からの要求はケースバイケースで考えられるでしょう。
The format for the DSP under ICD=0005 has been established by the National Institute of Standards and Technology (NIST), the authority for the ICD=0005 domain, in GOSIP Version 2 [3] (see Figure 2, Section 4.2). NIST has delegated the authority to register AA identifiers for GOSIP Version 2 NSAPs to the General Services Administration (GSA).
ICD=0005の下のDSPのための形式は米国商務省標準技術局(NIST)によって確立されました、ICD=0005ドメインへの権威、GOSIPバージョン2[3]で(図2を見てください、セクション4.2)。 NISTはGOSIPバージョン2NSAPsのためのAA識別子を共通役務庁(GSA)に登録する権威を代表として派遣しました。
ISO 8348 allows a maximum length of 20 octets for the NSAP address. The AFI of 47 occupies one octet, and the IDI of 0005 occupies two octets. The DSP is encoded as binary as indicated by the AFI of 47. One octet is allocated for a DSP Format Identifier, three octets for an Administrative Authority identifier, two octets for Routing Domain, two octets for Area, six octets for the System Identifier, and one octet for the NSAP selector. Note that two octets have been reserved to accommodate future growth and to provide additional flexibility for inter-domain routing. The last seven octets of the GOSIP NSAP format are structured in accordance with IS-IS [14], the intra-domain IS-IS routing protocol. The DSP Format Identifier (DFI) identifies the format of the remaining DSP structure and may be used in the future to identify additional DSP formats; the value 80h in the DFI identifies the GOSIP Version 2 NSAP structure.
ISO8348はNSAPアドレスのための20の八重奏の最大の長さを許容します。 47のAFIは1つの八重奏を占領します、そして、0005年のIDIは2つの八重奏を占領します。 DSPは47のAFIによって示されるのと同じくらい2進でコード化されます。 DSP Format Identifier、Administrative Authority識別子のための3つの八重奏、ルート設定Domainのための2つの八重奏、Areaのための2つの八重奏、System Identifierのための6つの八重奏、およびNSAPセレクタのための1つの八重奏のために1つの八重奏を割り当てます。 今後の成長に対応して、相互ドメインルーティングに追加柔軟性を提供するために2つの八重奏を控えてあることに注意してください。 GOSIP NSAP形式の最後の7つの八重奏が構造化される、-、[14]、イントラドメイン、-、ルーティング・プロトコル。 DSP Format Identifier(DFI)は残っているDSP構造の形式を特定して、将来、追加DSP形式を特定するのに使用されるかもしれません。 DFIの値の80hはGOSIPバージョン2NSAP構造を特定します。
Colella, Callon, Gardner & Rekhter [Page 47] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[47ページ]RFC1629NSAPガイドライン1994年5月
The Administrative Authority identifier names the administrative authority which is responsible for registration within its domain. The administrative authority may delegate the responsibilityfor registering areas to the routing domains, and the routing domains may delegate the authority to register System Identifiers to the areas. The main responsibility of a registration authority at any level of the addressing hierarchy is to assure that names of entities are unambiguous, i.e., no two entities have the same name. The registration authority is also responsible for advertising the names.
Administrative Authority識別子はドメインの中の登録に原因となる職務権限を命名します。 職務権限は領域を登録するresponsibilityforを経路ドメインへ代表として派遣するかもしれません、そして、経路ドメインはその領域にSystem Identifiersを登録する権威を代表として派遣するかもしれません。 いいえtwo、実体には、アドレシング階層構造のどんなレベルでも登録局の主な責任が実体の名前が明白であることを保証することであり、すなわち、同じ名前があります。 また、登録局も名前の広告を出すのに責任があります。
A routing domain is a set of end systems and intermediate systems which operate according to the same routing procedures and is wholly contained within a single administrative domain. An area uniquely identifies a subdomain of the routing domain. The system identifier names a unique system within an area. The value of the system field may be a physical address (SNPA) or a logical value. Address resolution between the NSAP and the SNPA may be accomplished by an ES-IS protocol [10], locally administered tables, or mapping functions. The NSAP selector field identifies the end user of the network layer service, i.e., a transport layer entity.
経路ドメインは、同じルーティング手順によると、作動する1セットのエンドシステムと中間システムであり、ただ一つの管理ドメインの中に完全に保管されています。 領域は唯一経路ドメインに関するサブドメインを特定します。 システム識別子は領域の中で独自のシステムを命名します。 システム分野の値は、物理アドレス(SNPA)か論理的な値であるかもしれません。 NSAPとSNPAの間のアドレス解決が実行されるかもしれない、ES存在、[10]、局所的に管理されたテーブル、またはマッピング機能について議定書の中で述べてください。 NSAPセレクタ分野はすなわち、ネットワーク層サービス、トランスポート層実体のエンドユーザを特定します。
A.1.1 Application for Administrative Authority Identifiers
職務権限識別子のA.1.1アプリケーション
The steps required for an agency to acquire an NSAP Administrative Authority identifier under ICD=0005 from GSA will be provided in the updated GOSIP users' guide for Version 2 [2] and are given below. Requests from non-government and non-U.S. organizations should originate from a senior official, such as a vice-president or chief operating officer.
GSAからNSAP Administrative Authority識別子をICD=0005の下に取得する政府機関をアップデートされたユーザのGOSIPものに提供するので、必要であるステップを、バージョンのために2[2]を誘導して、以下に与えます。 非政府とnon-U.S.組織からの要求は副社長か最高執行責任者などの高官から発するべきです。
* Identify all end systems, intermediate systems, subnetworks, and
their topological and administrative relationships.
* すべての終わりにシステム、中間システム、サブネットワーク、およびそれらの位相的で管理の関係を特定してください。
* Designate one individual (usually the agency head) within an
agency to authorize all registration requests from that agency
(NOTE: All agency requests must pass through this individual).
* 政府機関の中で(通常政府機関ヘッド)に1人の個人を任命して(注意: すべての政府機関要求がこの個人を通り抜けなければなりません)、その政府機関からのすべての登録要求を認可してください。
* Send a letter on agency letterhead and signed by the agency head
to GSA:
* 政府機関レターヘッドで手紙を出してください、そして、政府機関によってサインされて、GSAに向かってください:
Colella, Callon, Gardner & Rekhter [Page 48] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[48ページ]RFC1629NSAPガイドライン1994年5月
Telecommunications Customer Requirements Office
U.S. General Services Administration
Information Resource Management Service
Office of Telecommunications Services
18th and F Streets, N.W.
Washington, DC 20405
Fax +1 202 208-5555
18番目とF通り、ワシントン、北西DC 20405がファックスで+1 202 208-5555に送るテレコミュニケーション顧客要件オフィス米国共通役務庁の情報資源管理サービス電気通信事務所サービス
The letter should contain the following information:
手紙は以下の情報を含むはずです:
- Requestor's Name and Title,
- 要請者の名前と肩書
- Organization,
- 組織
- Postal Address,
- 郵便の宛先
- Telephone and Fax Numbers,
- 数に電話をして、ファックスで送ってください。
- Electronic Mail Address(es), and,
- そして電子メールAddress(es)。
- Reason Needed (one or two paragraphs explaining the intended
use).
- 理由は(意図している使用がわかる1か2つのパラグラフ)を必要としました。
* If accepted, GSA will send a return letter to the agency head
indicating the NSAP Administrative Authority identifier as-
signed,effective date of registration, and any other pertinent
information.
* 受け入れるなら、GSAがNSAP Administrative Authority識別子を示す政府機関ヘッドにリターン手紙を送る、-、登録のサインされて、発効している日、およびいかなる他の適切な情報。
* If rejected, GSA will send a letter to the agency head
explaining the reason for rejection.
* 拒絶されると、GSAは不合格理由について説明する政府機関ヘッドに手紙を送るでしょう。
* Each Authority will administer its own subaddress space in
accordance with the procedures set forth by the GSA in Section
A.1.2.
* セクションA.1.2にGSAによって詳しく説明された手順によると、各Authorityはそれ自身の「副-アドレス」のスペースを管理するでしょう。
* The GSA will maintain, publicize, and disseminate the assigned
values of Administrative Authority identifiers unless
specifically requested by an agency not to do so.
* 政府機関によってそうしないよう明確に要求されないと、GSAはAdministrative Authority識別子の割り当てられた値を維持して、ピーアールして、広めるでしょう。
Colella, Callon, Gardner & Rekhter [Page 49] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[49ページ]RFC1629NSAPガイドライン1994年5月
A.1.2 Guidelines for NSAP Assignment
NSAP課題のためのA.1.2ガイドライン
Recommendations which should be followed by an administrative authority in making NSAP assignments are given below.
作成NSAP課題における職務権限があとに続くべきである推薦を以下に与えます。
* The authority should determine the degree of structure of the
DSP under its control. Further delegation of address assignment
authority (resulting in additional levels of hierarchy in the
NSAP) may be desired.
* 権威はコントロールの下でDSPの構造の度合いを決定するべきです。 アドレス課題権威(NSAPの追加レベルの階層構造をもたらす)の一層の代表団は望まれるかもしれません。
* The authority should make sure that portions of NSAPs that it
specifies are unique, current, and accurate.
* 権威はそれが指定するNSAPsの部分が確実にユニークで、現在で、正確になるようにするべきです。
* The authority should ensure that procedures exist for
disseminating NSAPs to routing domains and to areas within
each routing domain.
* 権威は、手順が各経路ドメインの中で経路ドメインと、そして、領域にNSAPsを広めるために存在するのを確実にするべきです。
* The systems administrator must determine whether a logical or a
physical address should be used in the System Identifier field
(Figure 2, Section 4.2). An example of a physical address is a
48-bit MAC address; a logical address is merely a number that
meets the uniqueness requirements for the System Identifier
field, but bears no relationship to an address on a physical
subnetwork. We recommend that IDs should be assigned to be
globally unique, as made possible by the method described in
[18].
* 上級システムアドミニストレータは、論理的であるかa物理アドレスがSystem Identifier分野(図2、セクション4.2)で使用されるべきであるかどうかと決心しなければなりません。 物理アドレスに関する例は48ビットのMACアドレスです。 論理アドレスは単にSystem Identifier分野をユニークさの必要条件を満たしますが、物理的なサブネットワークに関するアドレスに関係に全く堪えない数です。 私たちは、[18]で説明された方法で可能にするようにIDがグローバルに特有になるように割り当てられるべきであることを勧めます。
* The network address itself contains information that may be
used to aid routing, but does not contain a source route [12].
Information that enables next-hop determination based on NSAPs
is gathered and maintained by each intermediate system through
routing protocol exchanges.
* ネットワーク・アドレス自体は、ルーティングを支援するのに使用されるかもしれない情報を含んでいますが、送信元経路[12]は含んでいません。 NSAPsに基づく次のホップ決断を可能にする情報が、ルーティング・プロトコル交換を通して各中間システムによって集められて、保守されます。
* GOSIP end systems and intermediate systems in federal agencies
must be capable of routing information correctly to and from any
subdomain defined by ISO 8348.
* 連邦機関におけるGOSIPエンドシステムと中間システムはどんなサブドメインからもサブドメインと、そして、ISO8348によって定義されたルーティング情報が正しくできなければなりません。
* An agency may request the assignment of more than one
Administrative Authority identifier. The particular use of each
should be specified.
* 政府機関は1つ以上のAdministrative Authority識別子の課題を要求するかもしれません。 それぞれの特定の使用は指定されるべきです。
A.2 Data Country Code NSAPs
A.2データ国名略号NSAPs
NSAPs from the Data Country Code (DCC) subdomain will also be common in the international Internet. ANS X3.216-1992 specifies the DSP structure under DCC=840 [1]. In the ANS, the DSP structure is identical to that specified in GOSIP Version 2, with the
また、Data Country Code(DCC)サブドメインからのNSAPsは国際的なインターネットで一般的になるでしょう。 ANS X3.216-1992はDCC=840[1]の下でDSP構造を指定します。 ANSでは、DSP構造はGOSIPバージョン2で指定されたそれと同じです。
Colella, Callon, Gardner & Rekhter [Page 50] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[50ページ]RFC1629NSAPガイドライン1994年5月
Administrative Authority identifier replaced by the numeric form of the ANSI-registered organization name, as shown in Figure 4.
図4に示されるようにANSIによって登録された組織名の数値フォームに取り替えられた管理Authority識別子。
Referring to Figure 4, when the value of the AFI is 39, the IDI denotes an ISO DCC and the abstract syntax of the DSP is binary octets. The value of the IDI for the U.S. is 840, the three-digit numeric code for the United States under ISO 3166 [6]. The numeric form of organization name is analogous to the Administrative Authority identifier in the GOSIP Version 2 NSAP.
AFIの値が39であるときに、図4を参照して、IDIはISO DCCを指示します、そして、DSPの抽象構文は2進の八重奏です。 米国へのIDIの値は840です、ISO3166[6]の下の合衆国への3ケタの数字コード。 数値組織形態名はGOSIPバージョン2NSAPのAdministrative Authority識別子に類似しています。
<----IDP--->
+-----+-----+----------------------------------------+
| AFI | IDI |<----------------------DSP------------->|
+-----+-----+----------------------------------------+
| 39 | 840 | DFI |ORG | Rsvd | RD | Area | ID | SEL |
+-----+-----+----------------------------------------+
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
+-----+-----+----------------------------------------+
<。----IDP--->+-----+-----+----------------------------------------+ | AFI| イディ| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--DSP------------->| +-----+-----+----------------------------------------+ | 39 | 840 | DFI|ORG| Rsvd| rd| 領域| 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 4: NSAP format for DCC=840 as proposed in ANSI X3S3.3.
図4: ANSI X3S3.3で提案されるDCC=840であることのNSAP形式。
A.2.1 Application for Numeric Organization Name
数値組織名のA.2.1アプリケーション
The procedures for registration of numeric organization names in the U.S. have been defined and are operational. To register a numeric organization name, the applicant must submit a request for registration and the $1,000 (U.S.) fee to the registration authority, the American National Standards Institute (ANSI). ANSI will register a numeric value, along with the information supplied for registration, in the registration database. The registration information will be sent to the applicant within ten working days. The values for numeric organization names are assigned beginning at 113527.
米国での数値組織名の登録のための手順は、定義されて、操作上です。 数値組織名を登録するために、応募者は登録を求める要求と1,000ドル(米国)の料金を登録局(American National Standards Institut(ANSI))に提出しなければなりません。 ANSIは登録データベースにおける登録に提供された情報に伴う数値を示すでしょう。 10営業日以内にレジスト情報を応募者に送るでしょう。 数値組織名のための値は、113527で始まりながら、割り当てられます。
Colella, Callon, Gardner & Rekhter [Page 51] RFC 1629 NSAP Guidelines May 1994
Colella、Callon、ガードナー、およびRekhter[51ページ]RFC1629NSAPガイドライン1994年5月
The application form for registering a numeric organization name may be obtained from the ANSI Registration Coordinator at the following address:
以下のアドレスのANSI Registration Coordinatorから数値組織名を登録するための申込み書を入手するかもしれません:
Registration Coordinator
American National Standards Institute
11 West 42nd Street
New York, NY 10036
+1 212 642 4884 (tel)
+1 212 398 0023 (fax)
RFC822: mmaas@attmail.com
X.400: G=michelle; S=maas; A=attmail; C=us
登録コーディネータAmerican National Standards Institut11の西四十二番街ニューヨーク、ニューヨーク10036+1 212 642 4884(tel)+1 212 398 0023(ファックス)RFC822: mmaas@attmail.com X.400: G=michelle。 S=maas。 A=attmail。 Cは私たちと等しいです。
Once an organization has registered with ANSI, it becomes a registration authority itself. In turn, it may delegate registration authority to routing domains, and these may make further delegations, for instance, from routing domains to areas. Again, the responsibilities of each Registration Authority are to assure that NSAPs within the domain are unambiguous and to advertise them as applicable.
組織がいったんANSIとともに記名すると、それは登録局自体になります。 順番に、登録局を経路ドメインへ代表として派遣するかもしれません、そして、例えば、これらは経路ドメインから領域まで一層の代表団を作るかもしれません。 一方、それぞれのRegistration Authorityの責任は、ドメインの中のNSAPsが明白であることを保証して、適切であるとして彼らの広告を出すことです。
A.3 Summary of Administrative Requirements
管理要件のA.3概要
NSAPs must be globally unique, and an organization may assure this uniqueness for OSI addresses in two ways. The organization may apply to GSA for an Administrative Authority identifier. Although registration of Administrative Authority identifiers by GSA primarily serves U.S. Government agencies, requests for non-government and non-U.S. organizations will be considered on a case-by-case basis. Alternatively, the organization may apply to ANSI for a numeric organization name. In either case, the organization becomes the registration authority for its domain and can register NSAPs or delegate the authority to do so.
NSAPsはグローバルにユニークでなければなりません、そして、組織はOSIアドレスのために2つの方法でこのユニークさを保証するかもしれません。 組織はAdministrative Authority識別子のためにGSAに申し込まれるかもしれません。 GSAによるAdministrative Authority識別子の登録は主として米国政府機関に役立ちますが、非政府とnon-U.S.組織を求める要求はケースバイケースで考えられるでしょう。 あるいはまた、組織は数値組織名のためにANSIに申し込まれるかもしれません。 どちらの場合ではも、組織は、ドメインへの登録局になって、NSAPsを登録するか、またはそうする権威を代表として派遣することができます。
In the case of GOSIP Version 2 NSAPs, the complete DSP structure is given in GOSIP Version 2. For ANSI DCC-based NSAPs, the DSP structure is specified in ANS X3.216-1992. The DSP structure is identical to that specified in GOSIP Version 2.
GOSIPバージョン2NSAPsの場合では、GOSIPバージョン2で完全なDSP構造を与えます。 ANSI DCCベースのNSAPsとして、DSP構造はANS X3.216-1992で指定されます。 DSP構造はGOSIPバージョン2で指定されたそれと同じです。
Colella, Callon, Gardner & Rekhter [Page 52]
Colella、Callon、ガードナー、およびRekhter[52ページ]
一覧
スポンサーリンク
