RFC1237 日本語訳
1237 Guidelines for OSI NSAP Allocation in the Internet. R. Colella,E. Gardner, R. Callon. July 1991. (Format: TXT=116989, PS=160478, PDF=171423 bytes) (Obsoleted by RFC1629) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Richard Colella (NIST)
Request for Comments: 1237 Ella Gardner (Mitre)
Ross Callon (DEC)
July 1991
ネットワークワーキンググループリチャードColella(NIST)はコメントのために以下を要求します。 1237エラ・ガードナー(斜め継ぎ)ロスCallon(12月)1991年7月
Guidelines for OSI NSAP Allocation in the Internet
インターネットのオウシNSAP Allocationのためのガイドライン
Status of This Memo
このメモの状態
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the ``IAB Official Protocol
Standards'' for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Internet is moving towards a multi-protocol environment that
includes OSI. To support OSI in the Internet, an OSI lower layers
infrastructure is required. This infrastructure comprises the
connectionless network protocol (CLNP) 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 NSAPs in the Internet.
インターネットはOSIを含んでいるマルチプロトコル環境に近づいています。 インターネットでOSIを支持するために、OSI下層インフラストラクチャが必要です。 このインフラストラクチャは、コネクションレスなネットワーク・プロトコル(CLNP)とルーティング・プロトコルをサポートするのを包括します。 また、このインフラストラクチャの一部として必要であるのは、ネットワークサービスアクセスポイント(NSAP)アドレス課題のためのガイドラインです。 この紙はインターネットにNSAPsを割り当てるためのガイドラインを提供します。
This document provides our current best judgment for the allocation
of NSAP addresses in the Internet. This is intended to guide initial
deployment of OSI 8473 (Connectionless Network Layer Protocol) in
the Internet, as well as to solicit comments. It is expected that
these guidelines may be further refined and this document updated as a
result of experience gained during this initial deployment.
このドキュメントはインターネットでのNSAPアドレスの配分のための私たちの現在の最も良い判断を提供します。 これは、インターネットでのOSI8473(コネクションレスなNetwork Layerプロトコル)の初期の展開を誘導して、コメントに請求することを意図します。 これらのガイドラインがさらに洗練されるかもしれないと予想されて、経験の結果、アップデートされたこのドキュメントはこの初期の展開の間、獲得されました。
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
Contents
コンテンツ
1 Introduction 4
1 序論4
2 Scope 4
2 範囲4
3 Background 6
3 バックグラウンド6
3.1 OSI Routing Standards . . . . . . . . . . . . 7
3.1 OSIルート設定規格. . . . . . . . . . . . 7
3.2 Overview of DIS10589 . . . . . . . . . . . . 8
3.2 DIS10589. . . . . . . . . . . . 8の概観
3.3 Requirements of DIS10589 on NSAPs . . . . . . . . 11
3.3 NSAPs. . . . . . . . 11の上のDIS10589の要件
4 NSAP and Routing 13
4 NSAPとルート設定13
5 NSAP Administration and Routing in the Internet 17
5 インターネット17のNSAP政権とルート設定
5.1 Administration at the Area . . . . . . . . . . 19
5.1 領域. . . . . . . . . . 19の政権
5.2 Administration at the Leaf Routing Domain . . . . . 21
5.2 葉の経路ドメイン. . . . . 21の政権
5.3 Administration at the Transit Routing Domain . . . . 21
5.3 トランジット経路ドメイン. . . . 21の政権
5.3.1 Regionals . . . . . . . . . . . . . . 22
5.3.1 地方版. . . . . . . . . . . . . . 22
5.3.2 Backbones . . . . . . . . . . . . . . 23
5.3.2 背骨. . . . . . . . . . . . . . 23
5.4 Multi-homed Routing Domains . . . . . . . . . . 24
5.4、マルチ、家へ帰り、経路ドメイン. . . . . . . . . . 24
5.5 Private Links . . . . . . . . . . . . . . . 29
5.5 個人的なリンク. . . . . . . . . . . . . . . 29
5.6 Zero-Homed Routing Domains . . . . . . . . . . 30
5.6、無、家へ帰り、経路ドメイン. . . . . . . . . . 30
5.7 Transition Issues . . . . . . . . . . . . . 31
5.7 変遷問題. . . . . . . . . . . . . 31
6 Recommendations 34
6つの推薦34
6.1 Recommendations Specific to U.S. Parts of the Internet . 35
6.1 インターネット. 35の米国の地域に特定の推薦
Colella, Gardner, & Callon [Page 2]
Colella、ガードナー、およびCallon[2ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
6.2 Recommendations Specific to Non-U.S. Parts of the Internet 37
6.2 インターネット37の非米国の地域に特定の推薦
6.3 Recommendations for Multi-Homed Routing Domains . . . 37
6.3の推薦、マルチ、家へ帰り、経路ドメイン. . . 37
7 Security Considerations 38
7 セキュリティ問題38
8 Authors' Addresses 39
8人の作者のアドレス39
9 Acknowledgments 39
9つの承認39
A Administration of NSAPs 40
NSAPs40の政権
A.1 GOSIP Version 2 NSAPs . . . . . . . . . . . . 41
A.1 GOSIPバージョン2NSAPs. . . . . . . . . . . . 41
A.1.1 Application for Administrative Authority Identifiers 42
職務権限識別子42のA.1.1アプリケーション
A.1.2 Guidelines for NSAP Assignment . . . . . . . 44
NSAP課題. . . . . . . 44のためのA.1.2ガイドライン
A.2 Data Country Code NSAPs . . . . . . . . . . . 45
A.2データ国名略号NSAPs. . . . . . . . . . . 45
A.2.1 Application for Numeric Organization Name . . . 46
数値組織名. . . 46のA.2.1アプリケーション
A.3 Summary of Administrative Requirements . . . . . . 46
管理要件. . . . . . 46のA.3概要
Colella, Gardner, & Callon [Page 3]
Colella、ガードナー、およびCallon[3ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
1 Introduction
1つの序論
The Internet is moving towards a multi-protocol environment that
includes OSI. To support OSI in the Internet, an OSI lower layers
infrastructure is required. This infrastructure comprises the
connectionless network protocol (CLNP) [12] (see also RFC 994 [8])
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
NSAPs in the Internet (NSAP and NSAP address are used interchangeably
throughout this paper in referring to NSAP addresses).
インターネットはOSIを含んでいるマルチプロトコル環境に近づいています。 インターネットでOSIを支持するために、OSI下層インフラストラクチャが必要です。 このインフラストラクチャはコネクションレスなネットワーク・プロトコル(CLNP)[12]を包括します。(また、RFC994[8])を見て、ルーティング・プロトコルをサポートします。 また、このインフラストラクチャの一部として必要であるのは、ネットワークサービスアクセスポイント(NSAP)アドレス課題のためのガイドラインです。 この紙はインターネットにNSAPsを割り当てるためのガイドラインを提供します(NSAPとNSAPアドレスはこの紙中で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 NSAPs.
この紙の残りは5つの主要なセクションと付録に組織化されます。 セクション2はこの紙に記述された問題の限界を定義します、そして、セクション3はOSIルーティングと含意に関する基礎的な情報をNSAPsに供給します。
Section 4 addresses the specific relationship between NSAPs 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 allocation in the Internet.
セクション4は特に階層型ルーティングとデータ抽象化に関してNSAPsとルーティングとの特定の関係を記述します。 これはセクション5でこれらの概念のアプリケーションでインターネット環境に続かれています。 セクション6はインターネットでのNSAP配分のための勧告事項を提供します。
Appendix A 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.
付録AはNSAP構造と配分当局に関して役に立つ情報に関する概要を含んでいます。 詳細にGOSIPバージョン2NSAP構造について議論します、そして、米国ベースのDCC(データCountry Code)NSAPsのための構造は説明されます。 それぞれGOSIPのための登録局、米国のDCCベースのNSAPs、共通役務庁(GSA)、およびAmerican National Standards Institut(ANSI)のための問い合わせ先を提供します。
2 Scope
2 範囲
There are two aspects of interest when discussing OSI NSAP allocation
within the Internet. The first is the set of administrative require-
ments for obtaining and allocating NSAPs; 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
インターネットの中でOSI NSAP配分について議論するとき、興味がある2つの局面があります。 1番目は入手のためにmentsを必要として、NSAPsを割り当てる管理のセットです。 2番目はそのような課題の技術的側面です、ルーティングと主に関係があるので、経路ドメイン(イントラドメインルーティング)とルーティングの間の両方
Colella, Gardner, & Callon [Page 4]
Colella、ガードナー、およびCallon[4ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
domains (inter-domain routing). This paper focuses on the technical
issues.
ドメイン(相互ドメインルーティング)。 この紙は専門的な問題に焦点を合わせます。
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
ES-IS (end-system to intermediate system) routing protocol applicable
for point-to-point links and LANs [13] (see also RFC 995 [7]) and
the emerging intra-domain IS-IS protocol [17]. Also expected is the
deployment of an inter-domain routing protocol similar to Border
Gateway Protocol (BGP) [18].
NSAP配分における専門的な問題はルーティングに主に関連します。 この紙がインターネットで配備されて、CLNPが広くそうであり、それが通常、交通が基づくCLNPのルーティングであると仮定する、OSI ES存在、ポイントツーポイント接続とLAN[13]に、適切な(中間システムへのエンドシステム)ルーティング・プロトコル、(また、RFC995[7])と現れているイントラドメインを見てください、-、[17]について議定書の中で述べてください。 また、予想されているのは、ボーダ・ゲイトウェイ・プロトコル(BGP)[18]と同様の相互ドメインルーティング・プロトコルの展開です。
The guidelines provided in this paper are intended for immediate
deployment as CLNP is made available in the Internet. This paper
specifically does not address long-term research issues, such as
complex policy-based routing requirements.
インターネットでCLNPを利用可能にするとき、即座の展開のためにこの紙に提供されたガイドラインを意図します。 この論文は明確に複雑な方針ベースのルーティング要件などの長期の研究課題を記述しません。
In the current Internet many routing domains (such as corporate and
campus networks) attach to transit networks (such as NSFNET regionals)
in only one or a small number of carefully controlled access points.
Addressing solutions which require substantial changes or constraints
on the current topology are not considered.
現在のインターネットでは、多くの経路ドメイン(法人とキャンパスネットワークなどの)が1だけの輸送網(NSFNET地方版などの)か慎重に制御されたアクセスポイントの少ない数に付きます。 現在のトポロジーで大きな変化か規制を必要とするアドレシング解決が考えられません。
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
DIS10589IS-IS routing protocol;
* 効率的な操作のためのNSAPの部分のアレンジメント、DIS10589IS存在、ルーティング・プロトコル。
* Benefits of some topological information in NSAPs to reduce
routing protocol overhead;
* ルーティングを減少させるNSAPsの何らかの位相的な情報の利益はオーバーヘッドについて議定書の中で述べます。
* The anticipated need for additional levels of hierarchy in
Internet addressing to support network growth;
* インターネットアドレシングによる追加レベルの階層構造がネットワークの成長を支持する予期された必要性。
* The recommended mapping between Internet topological entities
(i.e., backbone networks, regional networks, and site networks)
and OSI addressing and routing components;
* インターネットの位相的な実体(すなわち、背骨ネットワーク、地域ネットワーク、およびサイトネットワーク)と、OSIアドレシングとルーティングコンポーネントの間のお勧めのマッピング。
* The recommended division of NSAP address assignment authority
among backbones, regionals (also called mid-levels), and sites;
* NSAPのお勧めの分割は背骨、地方版(また、中間のレベルと呼ばれる)、およびサイトの中に課題権威を記述します。
Colella, Gardner, & Callon [Page 5]
Colella、ガードナー、およびCallon[5ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
* Background information on administrative procedures for registra-
tion of administrative authorities immediately below the national
level (GOSIP administrative authorities and ANSI organization
identifiers); and,
* 全国レベル(GOSIP職務権限とANSI組織識別子)のすぐ下における職務権限のregistra- tionのための行政手続に関する基礎的な情報。 そして
* Choice of the high-order portion of the NSAP in leaf routing
domains that are connected to more than one regional or backbone.
* 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
potion of the NSAP address space has been allocated);
* 第三者(特定のNSAPかNSAPアドレス空間の一服が割り当てられた実体などの)に登録された情報を明らかにするための方針かメカニズム。
* 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.
* NSAPのSystem Identifier(ID)部分を割り当てるための手順。
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 protocol in sufficient detail to understand the
issues involved in NSAP allocation. Finally, the specific constraints
that the intra-domain protocol places on NSAPs are listed.
このNSAP配分にかかわる問題を理解する際に役立っているセクションに何らかの基礎的な情報を提供します。 OSIルーティングの簡潔な議論を提供します、NSAP配分にかかわる問題は理解できるくらいの詳細における、イントラドメインプロトコルのレビューがあとに続いていて。 最終的に、イントラドメインがNSAPsの上の場所について議定書の中で述べるという特定の規制は記載されています。
Colella, Gardner, & Callon [Page 6]
Colella、ガードナー、およびCallon[6ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
3.1 OSI Routing Standards
3.1 OSIルート設定規格
OSI partitions the routing problem into three parts:
OSIはルーティング問題を3つの部品に仕切ります:
* routing exchanges between end systems and intermediate systems
(ES-IS),
* ルーティングがエンドシステムと中間システムの間で交換する、(ES存在、)
* routing exchanges between ISs in the same routing domain (intra-
domain IS-IS), and,
* ルーティングが同じ経路ドメインのISsの間で交換する、(イントラドメイン、-、)
* routing among routing domains (inter-domain IS-IS).
* 経路ドメインの中のルーティング、(相互ドメイン、-、)
ES-IS, international standard ISO9542 [13] approved in 1987, is
available in vendor products and is planned for the next release of
Berkeley UNIX (UNIX is a trademark of AT&T). It is also cited in GOSIP
Version 2 [4], which became effective in April 1991 for all applicable
federal procurements, and mandatory beginning eighteen months later in
1992.
ES存在、世界規格ISO9542[13]は1987年に承認して、メーカー製品の中で利用可能であり、バークレーUNIXの次のリリースのために計画されています(UNIXはAT&Tの商標です)。 また、それは1992年に1991年4月にすべての適切な連邦の調達に有効になった2[4]と18カ月後の義務的な始めのGOSIPバージョンで引用されます。
Intra-domain IS-IS advanced to draft international standard (DIS)
status within ISO in November, 1990 as DIS10589 [17]. It is reasonable
to expect that final text for the intra-domain IS-IS standard will be
available by mid-1991.
イントラドメイン、-、1990年11月にDIS10589[17]としてISOの中でドラフト世界規格(DIS)状態に達しました。 イントラドメインにその最終版の教科書を予想するのが妥当である、-、規格は1991年中頃までに利用可能になるでしょう。
There are two candidate proposals which address OSI inter-domain
routing, ECMA TR/50 [3] and Border Router Protocol (BRP) [19], a
direct derivative of the IETF Border Gateway Protocol [18]. ECMA TR/50
has been proposed as base text in the ISO/IEC JTC1 SC6/WG2 committee,
which is responsible for the Network layer of the ISO Reference Model
[11 ].X3S3.3, the ANSI counterpart to WG2, has incorporated features
of TR/50 into BRP and submitted this as alternate base text at the
WG2 meeting in October, 1990. Currently, it is out for ISO Member
Body comment. The proposed protocol is referred to as the Inter-domain
Routing Protocol (IDRP) [20].
OSI相互ドメインルーティング、ECMA TR/50[3]、およびBorder Routerプロトコル(BRP)[19](IETFボーダ・ゲイトウェイ・プロトコル[18]のダイレクト派生物)を記述する2つの候補提案があります。 ISO Reference Model[11 ].X3S3.3のNetwork層(WG2へのANSI対応者)が1990年10月にTR/50の特徴をBRPに組み入れて、交互のベーステキストとしてWG2ミーティングでこれを提出したので、ECMA TR/50はベーステキストとしてISO/IEC JTC1 SC6/WG2委員会で提案されました。(委員会は責任があります)。 現在、それはISOメンバーBodyコメントのためのものです。 提案されたプロトコルはInter-ドメインルート設定プロトコル(IDRP)[20]と呼ばれます。
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, Gardner, & Callon [Page 7]
Colella、ガードナー、およびCallon[7ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
3.2 Overview of DIS10589
3.2 DIS10589の概観
The IS-IS intra-domain routing protocol, DIS10589, developed in ISO,
provides routing for OSI environments. In particular, DIS10589 is
designed to work in conjunction with CLNP and ES-IS. This section
briefly describes the manner in which DIS10589 operates.
-、イントラドメインルーティング・プロトコル(ISOで開発されたDIS10589)はOSI環境にルーティングを提供します。 特に、DIS10589がCLNPに関連して働くように設計されている、ES存在 このセクションは簡潔に、DIS10589が作動する方法を説明します。
In DIS10589, 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 administra-
tion. Typically, a routing domain may consist of a corporate network,
a university campus network, a regional network, or a similar contigu-
ous 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 DIS10589 routing messages are sent on that
link.
DIS10589では、インターネットワークは経路ドメインに仕切られます。 経路ドメインは一般的なルーティング・プロトコルを操作して、単一のadministra- tionのコントロールの下にあるESsとISsの収集です。 通常、経路ドメインはただ一つの管理編成のコントロールの下で企業ネットワーク、大学構内ネットワーク、地域ネットワーク、または同様のcontigu- ousネットワークから成るかもしれません。 経路ドメインの境界はいくつかのリンクに外であるように設定するのによるネットワークマネージメント、または相互ドメイン、リンクによって定義されます。 外であることをリンクを示すなら、DIS10589ルーティング・メッセージを全くそのリンクに送りません。
Currently, ISO does not have a standard for inter-domain routing
(i.e., for routing between separate autonomous routing domains). In
the interim, DIS10589 uses manual configuration. An inter-domain link
is statically configured with the set of address prefixes reachable
via that link, and with the method by which they can be reached (such
as the DTE address to be dialed to reach that address, or the fact
that the DTE address should be extracted from the OSI NSAP address).
現在、ISOには、相互ドメインルーティング(すなわち、別々の自治の経路ドメインの間のルーティングのための)の規格がありません。 その間、DIS10589は手動の構成を使用します。 そのリンクを通して届いているアドレス接頭語のセット、およびそれらに達することができる方法(そのアドレスに達するようにダイヤルされるべきDTEアドレス、またはDTEアドレスがOSI NSAPアドレスから抜粋されるべきであるという事実などの)によって相互ドメインリンクは静的に構成されます。
DIS10589 routing makes use of two-level hierarchical routing. A
routing domain is subdivided into areas (also known as level 1
subdomains). Level 1 ISs know the topology in their area, including
all ISs and ESs in their area. However, level 1 ISs do not know the
identity of ISs or destinations outside of their area. Level 1 ISs
forward all traffic for destinations outside of their area to a level
2 IS within their area.
DIS10589ルーティングは2レベルの階層型ルーティングを利用します。 経路ドメインは領域(また、レベル1 サブドメインとして、知られている)に分筆されます。 レベル1 ISsは彼らの領域にすべてのISsとESsを含む彼らの領域でトポロジーを知っています。 しかしながら、レベル1ISsはそれらの領域の外でISsか目的地のアイデンティティを知りません。 それらの領域の中にISsが目的地のための外のすべての交通を送るレベル2へのそれらの領域のレベル1があります。
Similarly, level 2 ISs know the level 2 topology and know which
addresses are reachable via each level 2 IS. The set of all level 2
ISs 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
ISs do not need to know the topology within any level 1 area, except
to the extent that a level 2 IS may also be a level 1 IS within a
single area. Only level 2 ISs can exchange data packets or routing
information directly with external ISs located outside of their
同様に、レベル2ISsは、レベル2トポロジーを知っていて、どのアドレスが各レベル2で届いているかがあるのを知っています。 平らな2サブドメインとして経路ドメインのレベル2ISsのセットを知っています。(領域とインタコネクトするための背骨としてそれを考えることができます)。 また、レベル2が範囲以外の領域ですが、ISsがどんなレベル1の中でもトポロジーを知るために必要としないレベル2はただ一つの領域の中にレベル1があるということであるかもしれません。 レベル2だけISsが直接外部のISsがある情報が外部の場所を見つけたデータ・パケットかルーティングを交換できる、彼ら
Colella, Gardner, & Callon [Page 8]
Colella、ガードナー、およびCallon[8ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
routing domain.
ドメインを発送します。
As illustrated in Figure 1, ISO addresses are subdivided into the
Initial Domain Part (IDP) and the Domain Specific Part (DSP), as spec-
ified in ISO8348/Addendum 2, the OSI network layer addressing standard
[14 ](also RFC 941 [6]). The IDP is the part which is standardized by
ISO, and specifies the format and authority responsible for assigning
the rest of the 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). The DSP is further
subdivided, by DIS10589, into a High Order Part of DSP (HO-DSP), a
system identifier (ID), and an NSAP selector (SEL). The HO-DSP may
use any format desired by the authority which is identified by the
IDP. Together, the combination of [IDP,HO-DSP] identify an area within
a routing domain and, implicitly, the routing domain containing the
area. The combination of [IDP,HO-DSP] is therefore referred to as the
area address.
ISOアドレスは図1で例証されるようにInitial Domain Part(IDP)とDomain Specific Part(DSP)に細分されます、仕様がISO8348/付加物2でifiedされたとき、OSIネットワーク層アドレシング規格[14 ]。(RFC941[6])も。 IDPはISOによって標準化されて、アドレスの残りを割り当てるのに原因となる形式と権威を指定する部分です。 DSPはIDP(先端についての、より多くの議論のためのAppendix Aが当局に演説するNSAPを平らにするのを見る)によって指定されるどんなアドレシング権威によっても割り当てられます。 DSPはさらに細分されます、DIS10589、DSPのHigh Order Part(HO-DSP)、システム識別子(ID)、およびNSAPセレクタ(SEL)に。 HO-DSPはIDPによって特定される権威によって望まれていたどんな形式も使用するかもしれません。 一緒にいる、組み合わせ、領域を含んでいて、[IDP、HO-DSP]は経路ドメインとそれとなく経路ドメインの中で領域を特定します。 したがって、[IDP、HO-DSP]の組み合わせはそうです。領域アドレスと呼ばれます。
_______________________________________________
!____IDP_____!_______________DSP______________!
!__AFI_!_IDI_!_____HO-DSP______!___ID___!_SEL_!
_______________________________________________ !____IDP_____!_______________DSP______________! __AFI_!_イディ_!_____おーい、-、DSP______!___ID____SEL_!
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
HO-DSP High-order DSP
ID System Identifier
SEL NSAP Selector
IDPの初期のドメイン部分AFI権威と形式ID IDIがドメインの識別子のDSPのドメインの特定の部分に頭文字をつける、おーい、-、DSP、高位DSP IDシステム識別子SEL NSAPセレクタ
Figure 1: OSI 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).
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, Gardner, & Callon [Page 9]
Colella、ガードナー、およびCallon[9ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
* It might be desirable to change the address of an area. The most
graceful way of changing an area from having address A to having
address 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 ESs can be modified to forget
address A.
* 領域のアドレスを変えるのは望ましいかもしれません。 アドレスBを持っていることによって領域を変える最も優雅な方法が最初にそれにはアドレスAとBの両方があるのを許容することであり、そして、その領域のすべてのノードが両方のアドレスを認識するように変更された後にひとつずつ、アドレスAを忘れるようにESsは変更できます。
* 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 ESs
(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つになります)。 これは、適切なESs(領域Aになるように運命づけられたもの)へのアドレスA、およびアドレスBに関する知識について最初に知識を紹介することによって適切なノードに達成されて、次に、アドレスCに関する知識をひとつずつ取り除いているでしょう。
Since the addressing explicitly identifies the area, it is very easy
for level 1 ISs to identify packets going to destinations outside
of their area, which need to be forwarded to level 2 ISs. Thus, in
DIS10589 the two types of ISs route as follows:
アドレシングが明らかに領域を特定するので、レベル1ISsがそれらの領域の外に目的地に行くパケットを特定するのは、非常に簡単です。(パケットはレベル2ISsに送られる必要があります)。 したがって、DIS10589では、ISsの2つのタイプが以下の通り以下を発送します。
* Level 1 intermediate systems -- these nodes route based on the ID
portion of the ISO address. They route within an area. Level 1 ISs
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 IS.
* レベル1 中間システム--ルートがISOアドレスのID部分に基礎づけたこれらのノード。 彼らは領域を中に発送します。 ISsがパケットの送付先アドレスに基づいて領域の中に目的地があるか否かに関係なく、認識するレベル1。 そうだとすれば、彼らは目的地に向かって発送します。 そうでなければ、彼らはレベル2を最も近く発送します。あります。
* Level 2 intermediate systems -- these nodes 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 ISs on the routing domain boundary that have advertised
external address prefixes into the level 2 subdomain. A level 2 IS
may also be operating as a level 1 IS in one area.
* レベル2 中間システム--これらのノードはアドレスに基づいて接頭語を発送します、最も長い合っている接頭語を好んで、外部経路より内部のルートを好んで。 それら、領域の内部の構造への尊敬のない領域に向かったルート。 または、ルーティングドメイン境界の外部であることの形で広告を出したレベル2ISsに向かって、平らな2サブドメインへの接頭語を記述してください。 また、レベル1が1つの領域にあるとき、A級試験2は作動しているかもしれません。
A level 1 IS will have the area portion of its address manually
configured. It will refuse to become a neighbor with an IS whose area
addresses do not overlap its own area addresses. However, if a level 1
IS has area addresses A, B, and C, and a neighbor has area addresses
A級試験1はアドレスの領域の部分を手動で構成させるということです。 隣人になる、それが、拒否するそれ自身の領域が記述するオーバラップではなく、アドレスがそうする領域がそうです。 しかしながら、1がレベルであるならそう、領域アドレスA、Bを持っていて、領域アドレスを持っていますC、およびaが、近所付き合いさせる。
Colella, Gardner, & Callon [Page 10]
Colella、ガードナー、およびCallon[10ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
B and D, then the level 1 IS will accept the other IS as a level 1
neighbor.
BとD、次に、レベル1は受け入れるということです。もう片方がレベル1隣人としてそうです。
A level 2 IS will accept another level 2 IS as a neighbor, regardless
of area address. However, if the area addresses do not overlap, the
link would be considered by both ISs to be level 2 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 ISs in different
routing domains.
A級試験2は別のレベル2を受け入れるということです。隣人として、領域アドレスにかかわらず、あります。 しかしながら、領域アドレスが重ならないなら、リンクはレベル2専用であると両方のISsによって考えられるでしょう、そして、レベル2 ルーティングパケットだけがリンクの上に流れるでしょう。 異なった経路ドメインのレベル2ISsの間には、外部のリンク(すなわち、他の経路ドメインへの)があるに違いありません。
DIS10589 provides an optional partition repair function. In the
unlikely case that a level 1 area becomes partitioned, this function,
if implemented, allows the partition to be repaired via use of level 2
routes.
DIS10589は任意のパーティション修理機能を提供します。 仕切られて、平らな1つの領域がなるありそうもない場合では、実行されるなら、この機能は、パーティションがレベル2 ルートの使用で修理されるのを許容します。
DIS10589 requires that the set of level 2 ISs 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.
DIS10589は、レベル2ISsのセットが接続されるのを必要とします。 平らな2背骨が仕切られるようになるなら、レベル1 レベル2が仕切る修理へのリンクの使用への支給が全くありません。
In unusual cases, a single level 2 IS may lose connectivity to the
level 2 backbone. In this case the level 2 IS will indicate in its
level 1 routing packets that it is not attached, thereby allowing
level 1 ISs in the area to route traffic for outside of the area
to a different level 2 IS. Level 1 ISs therefore route traffic to
destinations outside of their area only to level 2 ISs which indicate
in their level 1 routing packets that they are attached.
珍しい場合では、ただ一つのレベル2は平らな2背骨に接続性を失うかもしれないということです。 この場合、レベル2はレベル1でパケットを発送して、付けられていなくて、その結果、その領域のレベル1ISsが領域の外部のための交通を異なったレベル2に発送するのを許容するのが、そうであることを示すということです。 レベル1 したがって、ISsは彼らの平らな1ルーティングパケットでそれらが付属しているのを示すレベル2ISsだけへのそれらの領域の外で交通を目的地に発送します。
An ES may autoconfigure the area portion of its address by extracting
the area portion of a neighboring IS's address. If this is the case,
then an ES will always accept an IS as a neighbor. Since the standard
does not specify that the end system must autoconfigure its area
address, an end system may be pre-configured with an area address. In
this case the end system would ignore IS neighbors with non-matching
area addresses.
ESが、近所付き合いの領域の部分を抽出するのによるアドレスの領域の部分がそうであることを自動構成するかもしれない、アドレス。 ESがこれがそうであるならいつも受け入れる、隣人として、あります。 規格が、エンドシステムが領域アドレスを自動構成しなければならないと指定しないので、エンドシステムは領域アドレスであらかじめ設定されるかもしれません。 この場合、終わりは非合っている領域アドレスをもっているシステムが、無視するだろう隣人です。
3.3 Requirements of DIS10589 on NSAPs
3.3 NSAPsの上のDIS10589の要件
The preferred NSAP format for DIS10589 is shown in Figure 1. A number
of points should be noted from DIS10589:
DIS10589に、都合のよいNSAP書式は図1に示されます。 多くのポイントがDIS10589から注意されるべきです:
Colella, Gardner, & Callon [Page 11]
Colella、ガードナー、およびCallon[11ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
* The IDP is as specified in ISO 8348/Addendum 2, the OSI network
layer addressing standard [14];
* OSIネットワーク層が規格[14]を記述して、IDPがISO8348/付加物2で指定されるようにあります。
* The high-order portion of the DSP (HO-DSP) is that portion of the
DSP whose assignment, structure, and meaning are not constrained
by DIS10589;
* DSP(HO-DSP)の高位一部が課題、構造、および意味がDIS10589によって抑制されないDSPのその一部です。
* The concatenation of the IDP and the HO-DSP, the area address,
must be globally unique (if the area address of an NSAP matches
one of the area addresses of a system, it is in the system'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;
* レベル1 ルーティングはID分野に影響します。 ID分野は、領域の中でESsとレベル1ISsにユニークであって、レベル2ISsに、経路ドメインの中でユニークであるに違いありません。 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/Addendum 2. However, within a routing domain that conforms to
DIS10589, 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 DIS10589 routing. End systems with addresses which do not
conform may require additional manual configuration and be subject
to inferior routing performance.
* システムは、ISO8348/付加物2時までに指定された形式のいずれにもアドレスを含むデータ・パケットを、発生して、進めることができるでしょう。 しかしながら、DIS10589に従う経路ドメインの中では、NSAPの下層階級八重奏はDIS10589ルーティングを最大限に利用するために図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 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 a
correct ``border'' router, from which they will exit the domain).
効率的な操作の目的、-、ルーティング・プロトコル、いくつかの観測をするかもしれません。 最初に、-、プロトコルはただ一つの経路ドメインの中のルーティングにアルゴリズムを指定して、ルーティング・アルゴリズムは効率的に両方を発送しなければなりません: (i) 最終的な目的地がドメイン(もちろんそのドメインの正しい目的地エンドシステムにこれらを発送しなければならない)にあるパケット。 そして、最終的な目的地がドメイン(それらがドメインを出る正しい「境界」ルータにこれらを発送しなければならない)の外にある(ii)パケット。
Colella, Gardner, & Callon [Page 12]
Colella、ガードナー、およびCallon[12ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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 (which can range from one up to a maximum of
three).
そのドメインにあるそれらの目的地に関しては、レベル2 ルーティングはまるでそれが平らな野原であるかのように全体の領域アドレス(すなわち、IDとSEL分野以外のNSAPアドレスのすべて)を扱います。 したがって、そのドメインの領域の数、および各領域に割り当てられた領域アドレスの数(ある上から最大3まで及ぶことができる)だけでドメインの中の目的地に掘られるレベル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 destinations can
be minimized.
ドメインの外にあるそれらの目的地に関しては、アドレスに応じて、レベル2 ルーティングは接頭語を発送します。 この場合、接頭語がどんな特定のセットの目的地についても説明するのを必要としたアドレスの数を最小にすることができるなら、かなりの潜在的利点(必要であるルーティング情報の量を減少させることに関する)があります。
4 NSAPs and Routing
4NSAPsとルート設定
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 cpu,
memory, and transmission bandwidth consumed in support of routing.
This 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. It is necessary to find a balance between these two needs.
NSAP課題のための施政方針を決定するとき、技術的な結果を理解しているのは重要です。 階層型ルーティングの使用の後ろの目的は帯域幅がルーティングを支持して消費したcpu、メモリ、およびトランスミッションを減らすために何らかのレベルのルーティングデータ抽象化、または総括を達成することです。 これは、位相的なルーティング構造に従ってNSAPsが割り当てられると決めます。 しかしながら、管理課題は組織的であるか政治上の境界に沿って下がります。 これらは位相的な境界に一致していないかもしれません、そして、したがって、2つのものの要件は衝突するかもしれません。 これらの2の間のバランスに必要性を見つけるのが必要です。
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 [16] and routing protocols, the
lowest boundary at which this can occur is the boundary between an
area and the level 2 subdomain within a DIS10589 routing domain. Data
abstraction is designed into DIS10589 at this boundary, since level 1
ISs are constrained to reporting only area addresses, and a maximum
number of three area addresses are allowed in one area (This is an
architectural constant in DIS10589. See [17], Clause 7.2.11 and Table
2 of Clause 7.5.1).
データ抽象化が階層的に境界に起こるルート設定は位相的なルーティング構造をアレンジしました。 要素は階層構造レポート概要ルーティング情報で親に下げられます。 現在のOSIルーティング枠組み[16]とルーティング・プロトコルの中では、これが起こることができる最も低い境界はDIS10589経路ドメインの中の領域と平らな2サブドメインの間の境界です。 データ抽象化はこの境界でDIS10589に設計されています、レベル1ISsが領域アドレスだけを報告するのに抑制されて、最大数の3つの領域アドレスが1つの領域に許容されているので。(これがDIS10589の建築定数である、Clauseの[17]、Clause7.2.11、およびTable2を見てください、7.5、.1、)
Colella, Gardner, & Callon [Page 13]
Colella、ガードナー、およびCallon[13ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
Level 2 routing is based upon address prefixes. Level 2 ISs dis-
tribute, 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 ISs 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 ISsはすべての広告を出しているアドレス接頭語に次のホップ推進情報を計算します。 レベル2 ルーティングは送付先アドレスに合っている最も長い広告を出しているアドレス接頭語で決定します。
At routing domain boundaries, address prefix information is exchanged
(statically or dynamically) with other routing domains. 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.
ルーティングドメイン境界では、他の経路ドメインでアドレス接頭語情報を交換します(静的かダイナミックに)。 異なった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. This requires a greater degree of data abstraction beyond that
which can be achieved at the ``routing domain'' level.
経路ドメインが多少無作為(非階層的な)の計画でインタコネクトされるなら、ルーティングデータのさらなる抽象化は全くかなり起こりそうであることができません。 経路ドメインには、定義された上下関係が全くないでしょう、したがって、管理者がデータ抽象化の目的のために何らかの一般的な接頭語から領域アドレスを割り当てることができないでしょう。 結果は平坦な相互ドメインルーティングでしょう。 ドメインがそれらが発送する他のすべての経路ドメインの形式知を必要とするすべてのルーティング。 これは小さくて中型の大きさで分けられたインターネットでうまくいくことができます、現在のIPインターネットよりいくらか大きいサイズまで。 しかしながら、これは非常に大きいインターネットに比例しません。 例えば、私たちは将来、10か米国の何十万もの経路ドメインを単独にする国際的なインターネットに成長を予測します。 これは「経路ドメイン」レベルで達成できるそれを超えて、より大きい度のデータ抽象化を必要とします。
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 routing
domains each to be assigned an address prefix from a shorter prefix
assigned to another routing domain whose function is to interconnect
the group of routing domains. Each member of the group of routing
しかしながら、インターネットでは、既存の階層型ルーティング構造インタコネクトを利用するのは可能であるべきです、セクション5で議論するように。 したがって、アドレス接頭語が経路ドメインのグループとインタコネクトする機能がことである別の経路ドメインに割り当てられたより短い接頭語から経路ドメインのグループにそれぞれ配属される機会があります。 ルーティングのグループの各メンバー
Colella, Gardner, & Callon [Page 14]
Colella、ガードナー、およびCallon[14ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
domains now ``owns'' its (somewhat longer) prefix, from which it
assigns its area addresses.
ドメインは現在、(いくらか長い)の接頭語を「所有しています」。(それはそれから領域アドレスを割り当てます)。
The most straightforward case of this occurs when there is a set
of routing domains which are all attached only to a single regional
(or backbone) domain, and which use that regional for all external
(inter-domain) traffic. A small address prefix may be assigned to
the regional, which then assigns slightly longer prefixes (based
on the regional's prefix) to each of the routing domains that it
interconnects. This allows the regional, when informing other
routing domains 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.
ただ一つの地方(または、背骨)のドメインだけにすべて付けられていて、すべての外部(相互ドメイン)の交通において地方でそれを使用する1セットの経路ドメインがあるとき、この最も簡単なケースは現れます。 小さいアドレス接頭語は地方に割り当てられるかもしれません。(次に、それは、わずかに長い接頭語(地方版の接頭語に基づいている)をそれがインタコネクトするそれぞれの経路ドメインに割り当てます)。 それにただ一つの接頭語を多くの経路ドメインのための可到達性情報を簡略化するために達することができることをアドレスの他の経路ドメインに知らせるとき、これは地方を許容します。 このアプローチは、したがって、多くのルーティング情報の階層的な略語を許容できて、その結果、相互ドメインルーティングのスケーラビリティを大いに改良できます。
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 GOSIP Version 2 NSAP structure, discussed later in
this section, allows for multiple levels of routing hierarchy.
明確に、このアプローチは、再帰的であり、いくつかの繰り返しで運ぶことができます。 階層構造のどんな「レベル」でも経路ドメインはその後の細分割当ての基礎としてそれらの接頭語を使用するかもしれません、NSAPアドレスが全長と構造規制に残っていると仮定して。 2NSAPが構造化する後でこのセクションで議論されたGOSIPバージョンは複数のレベルのルーティング階層構造を考慮します。
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.
ここに、私たちは、階層構造の各下のレベルにおけるノードの数が、指数関数的に成長する傾向があるのを観測します。 したがって、データ抽象化における最大級の利得は葉に起こります、そして、利得はそれぞれのより高いレベルで著しく低下します。 したがって、収穫逓減の法則は、何らかのポイントデータ抽象化におけるそれが、重要な利益を生産するのをやめるのを示します。 データ抽象化が有益であることをやめるポイントの決断は階層構造(与えられた期間の間の)の各レベルで起こると予想される経路ドメインの数の熟慮を必要とします、ダイナミックな相互ドメインルーティング・プロトコルで便利に効率的に扱うことができる経路ドメインとアドレス接頭語の数と比べて。
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 an example of how these two needs might be met. The AFI,
IDI, DFI, and 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 Appendix A for more information on
NSAP structure).
分散NSAP管理の効率的なルーティングと必要性のためにNSAPsに関する要件の間で求めなければならないバランスがあります。 GOSIP(図2)のバージョン2からのNSAP構造はこれらの2つの需要がどう満たされるかもしれないかに関する例を提供します。 AFI、IDI、DFI、およびAA分野は行政の地方分権に備えます。 値47/0005のAFI/IDI組は、米国政府がDSP構造を定義して、それの中に値を割り当てるのに原因となる権威であると認識します(NSAP構造の詳しい情報に関してAppendix Aを見てください)。
Colella, Gardner, & Callon [Page 15]
Colella、ガードナー、およびCallon[15ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
[Note: It is not important 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 expected to be used, and will work
equally well. For parts of the Internet outside of the U.S.
there may in some cases be strong reasons to prefer a local
format rather than the GOSIP format. However, GOSIP addresses
are used in most cases in the examples in this paper because:
注意します; 47/0005 米国へのData Country Codeの下のANSI形式(DCC=840)と形式の下における権威が割り当てたGOSIPバージョン2から他国までNSAPsを割り当てるのが重要でなく、ISOメンバーか連絡組織が、また、使用されると予想されて、等しくうまくいくでしょう; いくつかの場合、インターネットの地域において、そこの米国の外部はGOSIP形式よりむしろ地方の形式を好む強い理由であるかもしれません。しかしながら、多くの場合、GOSIPアドレスがこの紙の例で使用される、:
* The DSP format has been defined and allows hierarchical
allocation; and,
* DSP形式は、定義されて、階層的な配分を許します。 そして
* 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までの分野は管理に配属されたユニークなアドレス接頭語を表します。
_______________
!<--__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_-->。____________! _DFI_!AA_!Rsvd_!_RD_!Area_!ID_!Sel_!八重奏!__0005__!_47_!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構造。
Currently, a proposal is being progressed in ANSI for an American
National Standard (ANS) for the DSP of the NSAP address space
現在、提案はNSAPアドレス空間のDSPのための米国標準規格(ANS)のためにANSIで進行されています。
Colella, Gardner, & Callon [Page 16]
Colella、ガードナー、およびCallon[16ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
administered by ANSI. This will provide an identical DSP structure
to that provided by GOSIP Version 2. The ANSI format, therefore,
differs from that illustrated above only in that the IDP is based
on an ISO DCC assignment, and in that the AA will be administered
by a different organization (ANSI secretariat instead of GSA).
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.
ANSIによって管理されます。 これはGOSIPバージョン2によって提供されたそれに同じDSP構造を提供するでしょう。 したがって、ANSI形式はIDPが単にISO DCC課題に基づいていて、AAが異なった組織(GSAの代わりにANSI事務局)によって管理されるので上で例証されたそれと異なっています。 GOSIPバージョン2かANSI値がNSAP課題に使用されるかどうかからNSAP管理に適切な技術的な問題は独立しています。
Similarly, although other countries may make use of slightly different
NSAP formats, the principles of NSAP assignment and use are the same.
同様に、他国はわずかに異なったNSAP形式を利用するかもしれませんが、NSAP課題と使用の原則は同じです。
In the low-order part of the GOSIP Version 2 NSAP format, two
fields are defined in addition to those required by DIS10589. 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つの分野がDIS10589によって必要とされたものに加えて定義されます。 これらの分野(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.
* 経路ドメインの接頭語+地域は領域アドレスと等しいです。
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政権とルート設定
Internet routing components---backbones, regionals, and sites
or campuses---are arranged hierarchically for the most part. A
natural mapping from these components to OSI routing components
is that backbones, regionals, and sites act as routing domains.
インターネット・ルーティングコンポーネント---背骨か、地方版と、サイトかキャンパス---階層的では、だいたい配置されます。 自然なこれらのコンポーネントからOSIルーティングの部品までのマッピングは背骨、地方版、およびサイトがドメインを発送するとして機能するということです。
Colella, Gardner, & Callon [Page 17]
Colella、ガードナー、およびCallon[17ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
(Alternatively, a site may choose to operate as an area within a
regional. However, in such a case the area is part of the regional's
routing domain and the discussion in Section 5.1 applies. We assume
that some, if not most, sites will prefer to operate as routing
domains. By operating as a routing domain, a site operates a level 2
subdomain as well as one or more level 1 areas.)
(あるいはまた、サイトは、領域として地方版の中で作動するのを選ぶかもしれません。 しかしながら、このような場合には領域は地方版の経路ドメインの一部です、そして、セクション5.1における議論は適用されます。 私たちは、いくつか、または大部分、サイトが、ドメインを発送するとして作動するのを好むと思います。 経路ドメインとして作動することによって、サイトは1つ以上のレベル1の領域と同様に平らな2サブドメインを操作します。)
Given such a mapping, where should address administration and alloca-
tion be performed to satisfy both administrative decentralization and
data abstraction? Three possibilities are considered:
そのようなマッピングを考えて、アドレス管理とalloca- tionは、行政の地方分権とデータ抽象化の両方を満たすためにどこで実行されるべきですか? 3つの可能性が考えられます:
1. at the area,
1.、領域で
2. at the leaf routing domain, and,
2. そしてドメインを発送する葉で
3. at the transit routing domain (TRD).
3.、トランジット経路ドメイン(TRD)で。
Leaf routing domains correspond to sites, where the primary purpose is
to provide intra-domain routing services. Transit routing domains are
deployed to carry transit (i.e., inter-domain) traffic; backbones and
regionals are TRDs.
葉の経路ドメインはサイトに対応しています。そこでは、第一の目的はイントラドメインルーティングサービスを提供することです。 トランジット経路ドメインはトランジット(すなわち、相互ドメイン)交通を運ぶために配備されます。 背骨と地方版はTRDsです。
The greatest burden in transmitting and operating on routing informa-
tion is at the top of the routing hierarchy, where routing information
tends to accumulate. In the Internet, for example, regionals must man-
age the set of network numbers for all networks reachable through the
regional. Traffic destined for other networks is generally routed to
the backbone. The backbones, however, must be cognizant of the network
numbers for all attached regionals and their associated networks.
ルーティングinforma- tionが伝わって、作動するのにおいて最も大きい負担がルーティング階層構造の最上部にあります。(そこでは、ルーティング情報が蓄積する傾向があります)。 例えば、地方版がそうしなければならないインターネットでは、男性は地方を通って届いているすべてのネットワークのネットワーク・ナンバーのセットに年をとらせます。 一般に、他のネットワークのために運命づけられた交通は背骨に発送されます。 しかしながら、背骨はすべての付属地方版とそれらの関連ネットワークのネットワーク・ナンバーを認識していなければなりません。
In general, the advantage of abstracting routing information at a
given level of the routing hierarchy is greater at the higher levels
of the 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 site 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
regional (implying that the first seven octets of the address are
those assigned to that regional). If considering only their own
例えば、当然のことのサイトが、地方版からGSA(アドレスの最初の4つの八重奏がGOSIPスペースから割り当てられたものであることを含意する)からのAA値に基づいているか、またはRD値に基づくNSAPアドレス接頭語を得るかどうか決めようとしていると仮定してください(アドレスの最初の7つの八重奏がそれに地方で割り当てられたものであることを含意して)。 それら自身のだけを考えます。
Colella, Gardner, & Callon [Page 18]
Colella、ガードナー、およびCallon[18ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
self-interest, the site itself, and the attached regional, have
little reason to choose one approach or the other. The site must use
one prefix or another; the source of the prefix has little effect
on routing efficiency within the site. The regional must maintain
information about each attached site in order to route, regardless of
any commonality in the prefixes of the sites.
私利、サイト自体、および付属地方版には、あるアプローチかもう片方を選ぶ理由がほとんどありません。 サイトは何らかの接頭語を使用しなければなりません。 接頭語の源はサイトの中でほとんどルーティング効率に影響を与えません。 地方は、いずれもにかかわらずサイトの接頭語の共通点を発送するためにそれぞれの添付のサイトの情報を保守しなければなりません。
However, there is a difference when the regional distributes routing
information to backbones and other regionals. In the first case, the
regional cannot aggregate the site's address into its own prefix;
the address must be explicitly listed in routing exchanges, resulting
in an additional burden to backbones and other regionals which must
exchange and maintain this information.
しかしながら、地方が背骨と他の地方版にルーティング情報を分配する違いがあります。 前者の場合、地方はそれ自身の接頭語へのサイトのアドレスに集められることができません。 ルーティング交換で明らかにアドレスを記載しなければなりません、この情報を交換して、保守しなければならない背骨と他の地方版への追加負担をもたらして。
In the second case, each other regional and backbone sees a single
address prefix for the regional, which encompasses the new site. This
avoids the exchange of additional routing information to identify the
new site's address prefix. Thus, the advantages primarily accrue to
other regionals and backbones which maintain routing information about
this site and regional.
2番目の場合で地方版と背骨が、ただ一つのアドレスが地方版(新しいサイトを包含するもの)のために前に置くのを見る互い これは、新しいサイトのアドレス接頭語を特定するために追加ルーティング情報の交換を避けます。 したがって、利点は主としてこれのルーティング情報をサイトで地方に保守する他の地方版と背骨に生じます。
One might apply a supplier/consumer model to this problem: the higher
level (e.g., a backbone) is a supplier of routing services, while
the lower level (e.g., an attached regional) is the consumer of these
services. The price charged for services is based upon the cost of
providing them. The overhead of managing a large table of addresses
for routing to an attached topological entity contributes to this
cost.
1つは供給者/消費者モデルをこの問題に適用するかもしれません: より高いレベル(例えば、背骨)はルーティングサービスの供給者です、下のレベル(例えば、付属地方版)はこれらのサービスの消費者ですが。 サービスに課される価格はそれらを提供する費用に基づいています。 ルーティングのためのアドレスの大きいテーブルを付属位相的な実体に管理するオーバーヘッドはこの費用に貢献します。
The Internet, however, is not a market economy. Rather, efficient
operation is based on cooperation. The guidelines discussed below
describe reasonable ways of managing the OSI address space that
benefit the entire community.
しかしながら、インターネットは市場経済ではありません。 むしろ、効率的な操作は協力に基づいています。 以下で議論したガイドラインは全体の共同体のためになるOSIアドレス空間を管理する合理的な方法を述べます。
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 DIS10589. For example, assume that within a
routing domain three areas take their area addresses, respectively,
out of:
領域が関係ないNSAP配分当局の無数からそれらの領域アドレスを取ると、データ抽象化は全く有効にDIS10589が組み込まれることを超えていないでしょう。 例えば、経路ドメインの中では、3つの領域が以下からそれらの領域アドレスをそれぞれ取ると仮定してください。
Colella, Gardner, & Callon [Page 19]
Colella、ガードナー、およびCallon[19ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
* 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) (Section
A.2) for organization XYZ with ORG identifier = xxx:
* ORG識別子がある組織XYZのための米国Data Country Code(DCC)(セクションA.2)の下のANSI権威は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. 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 leaf routing domains would advertise is on
the order of the number of attached areas; the number of prefixes a
regional routing domain would advertise is approximately the number of
areas attached to the client leaf routing domains; and for a backbone
this would be summed across all attached regionals. Although this
situation is just barely acceptable in the current Internet, as the
Internet grows this will quickly become intractable. A greater degree
of hierarchical information reduction is necessary to allow continued
growth in the Internet.
この状況はTCP/IPインターネットでルーティング情報の普及におよそ類似しています。 領域はおよそネットワーク・ナンバーへのネットワークと領域アドレスに対応しています。 経路ドメインの中の領域が関係ない当局からそれらのNSAPsを取るのを許容するという結果は領域アドレスレベルにおいて平坦なルーティングです。 付属領域の数の注文には葉の経路ドメインが広告を出すアドレス接頭語の数があります。 地方の経路ドメインが広告を出す接頭語の数はクライアント葉の経路ドメインに付けられた領域のおよそ数です。 そして、背骨において、これはすべての付属地方版の向こう側にまとめられるでしょう。 この状況は現在のインターネットでちょうどほとんど許容できませんが、インターネットが発展するのに従って、これは急速に手に負えなくなるでしょう。 より大きい度の階層的な情報減少が、インターネットの継続成長を許容するのに必要です。
Colella, Gardner, & Callon [Page 20]
Colella、ガードナー、およびCallon[20ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
5.2 Administration at the Leaf Routing Domain
5.2 葉の経路ドメインの政権
As mentioned previously, the greatest degree of data abstraction comes
at the lowest levels of the hierarchy. Providing each leaf routing
domain (that is, site) with a unique prefix results in the biggest
single increase in abstraction, with each leaf domain assigning area
addresses from its prefix. From outside the leaf routing domain, the
set of all addresses reachable in the domain can then be represented
by a single prefix.
既述のとおり、最大級の度のデータ抽象化は階層構造の最も低いレベルで来ます。 それぞれの葉の経路ドメイン(すなわち、サイト)をユニークな接頭語に提供すると、抽象化の最も大きいただ一つの増加はもたらされます、それぞれの葉のドメインが接頭語からの領域アドレスを割り当てていて。 そして、葉の経路ドメインの外から、ただ一つの接頭語はそのドメインで届いているすべてのアドレスのセットを表すことができます。
As an example, assume NSF has been assigned the AA value of zzz
under ICD=0005. NSF then assigns a routing domain identifier to a
routing domain under its administrative authority identifier, rrr. The
resulting prefix for the routing domain is:
例として、ICD=0005の下でグーグーグーのAA値をNSFに割り当ててあると仮定してください。 そして、NSFは職務権限識別子、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 attached to 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 leaf RD should take their NSAPs
from the prefix assigned to the leaf RD.
それらは一般的なルーティング・プロトコルを操作して、ただ一つの管理のコントロールの下にあるという事実の暗黙の領域と経路ドメインの間には、密接な関係があります。 経路ドメイン管理は、領域にドメインを分筆して、接続性を領域に提供する平らな2サブドメイン(すなわち、平らな2背骨)を構造化します。 経路ドメインは領域とインターネットワークの残りの間の唯一の経路を表します。 また、この関係が権威を記述する一般的なNSAPを含むように広がるのは、妥当です。 したがって、葉のRDの中の領域は葉のRDに割り当てられた接頭語からそれらのNSAPsを取るべきです。
5.3 Administration at the Transit Routing Domain
5.3 トランジット経路ドメインの政権
Two kinds of transit routing domains are considered, backbones and
regionals. Each is discussed separately below.
2種類のトランジット経路ドメインが考えられる、背骨と地方版。 別々に以下でそれぞれについて議論します。
Colella, Gardner, & Callon [Page 21]
Colella、ガードナー、およびCallon[21ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
5.3.1 Regionals
5.3.1 地方版
It is interesting to consider whether regional routing domains should
be the common authority for assigning NSAPs from a unique prefix to
the leaf routing domains that they serve. The benefits derived from
data abstraction are less than in the case of leaf routing domains,
and the additional degree of data abstraction provided by this is
not necessary in the short term. However, 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を割り当てるために地方の経路ドメインが一般的な権威であるべきであるかどうか考えるのはおもしろいです。 データ抽象化から得られた利益は葉の経路ドメインに関するケースより少ないです、そして、これによって提供された追加度のデータ抽象化は短期で必要ではありません。 しかしながら、長期でインターネットの経路ドメインの数は経路ドメインの平らな野原に基づいて発送するのにおいて実行不可能になるというポイントに成長するでしょう。 したがって、より大きい度の情報抽象化を提供するのは不可欠でしょう。
Regionals may assign prefixes to leaf domains, based on a single
(shorter length) address prefix assigned to the regional. For example,
given the GOSIP Version 2 address structure, an AA value may be
assigned to each regional, and routing domain values may be assigned
by the regional to each attached leaf routing domain. A similar
hierarchical address assignment based on a prefix assigned to each
regional may be used for other NSAP formats. This results in regionals
advertising to backbones a small fraction of the number of address
prefixes that would be necessary if they enumerated the individual
prefixes of the leaf routing domains. This represents a significant
savings given the expected scale of global internetworking.
地方版は地方に割り当てられたただ一つ(より短い長さ)のアドレス接頭語に基づいて葉のドメインに接頭語を割り当てるかもしれません。 例えば、GOSIPバージョン2アドレス構造を考えて、AA値はそれぞれに地方で割り当てられるかもしれません、そして、経路ドメイン値はそれぞれの付属葉の経路ドメインへの地方によって割り当てられるかもしれません。 それぞれに地方で割り当てられた接頭語に基づく同様の階層的なアドレス課題は他のNSAP形式に使用されるかもしれません。 これはアドレスの数のわずかな部分が前に置く葉の経路ドメインの個々の接頭語を列挙するなら必要な背骨への地方版広告をもたらします。 グローバルなインターネットワーキングの予想されたスケールを考えて、これは重要な貯蓄を表します。
Are leaf routing domains willing to accept prefixes derived from
the regional's? In the supplier/consumer model, the regional is
offering connectivity as the service, priced according to its costs
of operation. This includes the ``price'' of obtaining service from
one or more backbones. In general, backbones will want to handle as
few address prefixes as possible to keep costs low. In the Internet
environment, which does not operate as a typical marketplace, leaf
routing domains must be sensitive to the resource constraints of the
regionals and backbones. The efficiencies gained in routing clearly
warrant the adoption of NSAP administration by the regionals.
地方版のものから接頭語を受け入れても構わないと思っている葉の経路ドメインを得ますか? 供給者/消費者モデルでは、地方は操作のコストに従って値を付けられたサービスとして接続性を提供しています。 これは1つ以上の背骨からサービスを得る「価格」を含んでいます。 一般に、背骨はコストを低く保つのにおいてできるだけわずかなアドレス接頭語しか扱いたくならないでしょう。 インターネット環境で、葉の経路ドメインは地方版と背骨のリソース規制に敏感であるに違いありません。(それは、典型的な市場として作動しません)。 ルーティングで明確に獲得された効率は地方版でNSAP管理の採用を保証します。
The mechanics of this scenario are straightforward. Each regional
is assigned a unique prefix, from which it allocates slightly longer
routing domain prefixes for its attached leaf routing domains.
For GOSIP NSAPs, this means that a regional would be assigned an
AA identifier. Attached leaf routing domains would be assigned RD
identifiers under the regional's unique prefix. For example, assume
このシナリオの整備士は正直です。 ユニークな接頭語は各地方版に割り当てられます。(それは付属葉の経路ドメインのために接頭語をそれから、より長い経路ドメインにわずかに割り当てます)。 GOSIP NSAPsに関しては、これは、AA識別子が地方版に割り当てられることを意味します。 RD識別子は地方版のユニークな接頭語の下で付属葉の経路ドメインに割り当てられるでしょう。 例えば、仮定
Colella, Gardner, & Callon [Page 22]
Colella、ガードナー、およびCallon[22ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
NIST is a leaf routing domain whose sole inter-domain link is via
SURANet. If SURANet is assigned an AA identifier kkk, NIST could be
assigned an RD of jjj, resulting in a unique prefix for SURANet of:
NISTはSURANetを通して唯一の相互ドメインリンクがある葉の経路ドメインです。 AA識別子kkkがSURANetに割り当てられるなら、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 regional applies for an ORG identifier from
ANSI, which serves the same purpose as the AA identifier in GOSIP.
The current direction in ANSI is to standardize on an NSAP structure
identical to GOSIP Version 2 (see Section A.2).
DCC=840の下に割り当てられたNSAPsを使用することで同様の計画を確立できます。 この場合、地方版はANSIからORG識別子に申し込みます。(ANSIはGOSIPのAA識別子と同じ目的に役立ちます)。 ANSIの現在の指示はGOSIPと同じNSAP構造の上でバージョン2を標準化する(セクションA.2を見てください)ことです。
5.3.2 Backbones
5.3.2 背骨
There does not appear to be a strong case for regionals to take their
address spaces from the the NSAP space of a backbone. The benefit in
routing data abstraction is relatively small. The number of regionals
today is in the tens and an order of magnitude increase would not
cause an undue burden on the backbones. Also, it may be expected that
as time goes by there will be increased direct interconnection of the
regionals, leaf routing domains directly attached to the backbones,
and international links directly attached to the regionals. Under
these circumstances, the distinction between regionals and backbones
may become blurred.
地方版が背骨のNSAPスペースからそれらのアドレス空間を取る強いケースはあるように見えません。 ルーティングデータ抽象化による利益は比較的わずかです。 今日、10には地方版の数があります、そして、桁の増加は背骨の不当な負担を引き起こさないでしょう。 また、時間がそこに過ぎるとき、それは地方版の増加するダイレクトインタコネクトになるでしょう、直接背骨に付けられた葉の経路ドメインと予想されたかもしれなくて、国際的な関係は直接地方版に付きました。 こういう事情ですから、地方版と背骨の区別はぼけるようになるかもしれません。
An additional factor that discourages allocation of NSAPs from a
backbone prefix is that the backbones and their attached regionals are
perceived as being independent. Regionals may take their long-haul
service from one or more backbones, or may switch backbones should
a more cost-effective service be provided elsewhere (essentially,
backbones can be thought of the same way as long-distance telephone
carriers). Having NSAPs derived from the backbone is inconsistent with
the nature of the relationship.
背骨接頭語からのNSAPsの配分に水をさしている追加要素は背骨とそれらの付属地方版が独立しているとして知覚されるということです。 地方版は、1つ以上の背骨から彼らの長期サービスを取るか、または、より費用対効果に優れたサービスをほかの場所に提供するなら、背骨を切り換えるかもしれません(本質的には、長距離電話キャリヤーとして同じように背骨を考えることができます)。 背骨からNSAPsを得させるのは関係の本質に矛盾しています。
Colella, Gardner, & Callon [Page 23]
Colella、ガードナー、およびCallon[23ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
5.4 Multi-homed Routing Domains
5.4、マルチ、家へ帰り、経路ドメイン
The discussions in Section 5.3 suggest methods for allocating NSAP
addresses based on regional or backbone connectivity. This allows a
great deal of information reduction to be achieved for those routing
domains which are attached to a single TRD. In particular, such
routing domains may select their NSAP addresses from a space allocated
to them by the regional. This allows the regional, when announcing the
addresses that it can reach to other regionals and backbones, to use
a single address prefix to describe a large number of NSAP addresses
corresponding to multiple routing domains.
セクション5.3における議論は地方に基づいてアドレスをNSAPに割り当てるための方法か背骨の接続性を示します。 これは、大きな情報減少が独身のTRDに付けられているそれらの経路ドメインに達成されるのを許容します。 特に、そのような経路ドメインは地方によってそれらに割り当てられたスペースからのそれらのNSAPアドレスを選択するかもしれません。 複数の経路ドメインに対応する多くのNSAPアドレスについて説明するのにただ一つのアドレス接頭語を使用するために、それが他の地方版と背骨に達することができるアドレスを発表するとき、これは地方を許容します。
However, there are additional considerations for routing domains
which are attached to multiple regionals and backbones. Such ``multi-
homed'' routing domains may, for example, consist of single-site
campuses and companies which are attached to multiple backbones, large
organizations which are attached to different regionals at different
locations in the same country, or multi-national organizations which
are attached to backbones 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 regionals and backbones 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 TRD, the TRDs to which this organization is attached will
need to advertise the prefix for this organization to other regionals
and backbones. Other regionals and backbones (potentially worldwide)
will need to maintain an explicit entry for that organization in their
routing tables.
1つの可能な解決策がアドレスをそれぞれに割り当てることである、マルチ、家へ帰り、独自に地方版と背骨からそれがどれであるかに付けられた組織。 これがそれぞれを許容する、マルチ、家へ帰り、NSAP課題をただ一つの接頭語に基礎づけて、その結果ただ一つの接頭語を通してその組織の中で届いているすべてのNSAPsのセットをまとめる組織。 このアプローチの不都合はその組織のためのNSAPアドレスにはどんな特定のTRDのアドレスとの関係も全くないのでこの組織が付けているTRDsが、この組織のために他の地方版と背骨に接頭語の広告を出す必要があるということです。 他の地方版と背骨(潜在的に世界的な)は、その組織のためにそれらの経路指定テーブルで明白なエントリーを維持する必要があるでしょう。
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 backbone and regional
will need to maintain a separate address entry for MBII. If MBII
例えば、そのaが非常に大きい米国全体の会社であると仮定してください、「メガ、大きさ、国際、取り入れられて、」 (MBII)は完全にインタコネクトされた内部のネットワークを持って、U.S. GOSIPバージョン2アドレス空間の下でただ一つのAA値を割り当てられます。 米国の外では、単一のエントリーがすべてのU.S. GOSIPアドレスのために経路指定テーブルで維持されそうです。 しかしながら、中では、米国、あらゆる背骨、および地方が、MBIIのために別々のアドレスエントリーを維持する必要があるでしょう。 MBIIです。
Colella, Gardner, & Callon [Page 24]
Colella、ガードナー、およびCallon[24ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
is in fact an international corporation, then it may be necessary
for every backbone worldwide to maintain a separate entry for MBII
(including backbones to which MBII is not attached). Clearly this
may be acceptable if there are a small number of such multi-homed
routing domains, but would place an unacceptable load on routers
within backbones 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.
事実上、国際会社、その時は世界中のあらゆる背骨が維持するのが必要であるかもしれないMBIIのための別々のエントリー(どのMBIIに背骨を含めるかは付属していない)ですか? 少ない数のそのようなものがあれば明確に、これが許容できるかもしれない、マルチ、家へ帰り、すべての組織がそのようなアドレス課題を選ぶなら背骨の中に容認できない負荷をルータに置くのを除いた経路ドメイン。 この解決策がインターネットに多くの何十万があるところに比例しないかもしれない、マルチ、家へ帰り、組織。
A second possible approach would be for multi-homed organizations to
be assigned a separate NSAP space for each connection to a TRD, and
to assign a single address prefix to each area within its routing
domain(s) based on the closest interconnection point. For example, if
MBII had connections to two regionals in the U.S. (one east coast, and
one west coast), as well as three connections to national backbones
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.
2番目の可能なアプローチがあるだろう、マルチ、家へ帰り、別々のNSAPスペースが各接続のためにTRDに割り当てられて、経路ドメインの中の各領域にただ一つのアドレス接頭語を割り当てる組織は最も近いインタコネクトポイントを基礎づけました。 例えば、そして、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 TRD which has a connection to MBII needs
to announce to other TRDs 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
TRDs, resulting in a smaller load on the inter-domain routing tables
maintained by TRDs 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には接続がある各TRDは、アドレスがそれ自身のアドレス空間から取られるMBIIのそれらの部分だけに達する能力を他のTRDsに発表する必要があります。 これは、どんな追加ルーティング情報も、TRDsの間で交換される必要でないのを含意します、最初の解決策と比べるとTRDsによって維持された相互ドメイン経路指定テーブルで、よりわずかな負荷をもたらして。 したがって、この解決策が非常に大きい数を含む非常に大きいインターネットによりよく比例する、マルチ、家へ帰り、組織。
One problem with the second solution is that backup routes to multi-
homed organizations are not automatically maintained. With the first
solution, each TRD, 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 TRD 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 TRD
2番目の解決策に関する、ある問題がそのバックアップルートである、マルチ、家へ帰り、組織は自動的に維持されません。 最初の解決策で、MBIIに達する能力を発表する際に、各TRDは、MBIIの中でNSAPsのすべてに達することができると指定します。 2番目の解決策で、各TRDは、MBIIの中にいくつかのNSAPsを含んでいるだけであるそれ自身のアドレス接頭語に基づくNSAPsのすべてに達することができると発表します。 MBIIと1特定のTRDとの接続です。
Colella, Gardner, & Callon [Page 25]
Colella、ガードナー、およびCallon[25ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
were severed, then the NSAPs within MBII with addresses based on that
TRD 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.
断ち切られて、そして、そのTRDに基づくアドレスがある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 (which will
tend to minimize the load on the networks within MBII, and maximize
the load on the TRDs).
また、これと前のアプローチが、パケットが異なったルートを取ることを引き起こす傾向があることに注意してください。 最初のアプローチで、MBIIの中で運命づけられたMBIIの外部からのパケットは、ソース(したがって、MBIIへの内部のネットワークで負荷を最大にする傾向がある)の最も近くにあるポイントで入る傾向があるでしょう。 2番目の解決策で、MBIIの中で運命づけられた外部からのパケットは、目的地(MBIIの中のネットワークで負荷を最小にして、TRDsで負荷を最大にする傾向がある)の最も近くにあるポイントで入る傾向があるでしょう。
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 TRD. Other TRDs to which the multi-homed
organization are attached maintain a routing table entry for the
organization, but are extremely selective in terms of which other
TRDs are told of this route. This approach will produce a single
``default'' routing entry which all TRDs will know how to reach
また、他の可能な解決策があります。 3番目のアプローチがそれぞれを割り当てることである、マルチ、家へ帰り、TRDとの接続のひとりに基づいた組織のaただ一つのアドレス接頭語。 他のTRDs、どれ、マルチ、家へ帰り、付けられた組織は、組織のためにa経路指定テーブルエントリーを維持しますが、どの他のTRDsがこのルートについて言われるかに非常に選択しているか。 このアプローチはすべてのTRDsが、どのようにが達するかを知っている単一の「デフォルト」ルーティングエントリーを起こすでしょう。
Colella, Gardner, & Callon [Page 26]
Colella、ガードナー、およびCallon[26ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
(since presumably all TRDs will maintain routes to each other), while
providing more direct routing in some cases.
(おそらくすべてのTRDsが互いにルートを維持するので)、いくつかの場合、さらに提供している間、ルーティングを指示してください。
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 TRDs (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 entry
per organization, but that they are distributed throughout a larger
internet with many millions of (mostly not widget-associated) routing
domains.
この3番目のアプローチが特に適切である少なくとも1つの状況があります。 組織の特殊利益集団がそれら自身の背骨を配備したと仮定してください。 例えば、米国National Widget ManufacturersとResearchersが米国全体の背骨と彼らのウィジェット研究の努力で知られているある大学を設立したと思わせます。背骨はウィジェットを製造している会社によって使用されます。 経路ドメインを切り離してください。そうすれば、また、それらの大部分が他のTRDsに付けられるとき(また、ウィジェット製造と研究にかかわる組織の大部分が他の活動にかかわるので)、私たちは、ウィジェットグループにはある様々な組織がそれらの内部のネットワークを経営していると予想できます。 したがって、私たちが、多くかウィジェットグループにおける組織の大部分がそうであると予想できる、二元的である、-、家へ帰り、ウィジェットで関連しているコミュニケーションに関する1つの付属と他のタイプのコミュニケーションに関するもう片方の付属をもって。 また、ウィジェットグループにかかわる組織の総数が1組織あたり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 TRDs (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 worldwide TRDs
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 TRDs, while allowing communications
within the widget group to use the preferred path.
3番目はアプローチします、それぞれ、マルチ、家へ帰り、ウィジェットグループにおける組織がTRDs(ウィジェットグループに関連づけられなかった付属)への他の付属に基づくアドレス課題を利用するでしょう。 ウィジェット背骨は、様々な会員会社に関連している経路ドメインにルートを維持する必要があるでしょう。 同様に、ウィジェットグループのすべてのメンバーが、ウィジェット背骨で他のメンバーにルートのテーブルを維持する必要があるでしょう。 しかしながら、ウィジェット背骨が、それにどんなアドレスに達することができるかを(背骨が使用のために他の外の組織によって意図されないので)他の一般的な世界的なTRDsに知らせないので、比較的大きいセットのルーティング接頭語は、限られた数の場所だけで維持される必要があります。 ウィジェットグループの中のコミュニケーションが都合のよい経路を使用するのを許容している間、ウィジェットグループのメンバーである様々な組織に配属されたアドレスはそれぞれを通した「デフォルトルート」メンバーにTRDsへの他の付属を提供するでしょう。
A fourth solution involves assignment of a particular address prefix
for routing domains which are attached to precisely two (or more)
specific routing domains. For example, suppose that there are two
regionals ``SouthNorthNet'' and ``NorthSouthNet'' which have a very
4番目の解決策は正確に2つ(さらに)の特定の経路ドメインに付けられている経路ドメインに特定のアドレス接頭語の課題にかかわります。 例えば、aをまさしくそのであるする2つの地方版"SouthNorthNet"と"NorthSouthNet"があると仮定してください。
Colella, Gardner, & Callon [Page 27]
Colella、ガードナー、およびCallon[27ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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 TRDs would then advertise two prefixes to other
TRDs, one prefix for leaf routing domains attached to it only, and one
prefix for leaf routing domains attached to both.
一般的(すなわち、両方に付けられている多くの経路ドメインがある)の多くの顧客。 2つのアドレス接頭語(GOSIPアドレス空間の下で割り当てられた2つのAA値などの)を得るよりむしろ、これらの組織は3つの接頭語を得ることができました。 NorthSouthNetに付けられていますが、SouthNorthNetに付けられていないそれらの経路ドメインは接頭語の1つに基づくアドレス課題を得ます。 SouthNorthNetに付けられていますが、NorthSouthNetに付けられるというわけではないそれらの経路ドメインは2番目の接頭語に基づくアドレスを得るでしょう。 最終的にそうするそれらの経路ドメイン、マルチ、家へ帰り、3番目の接頭語に基づくアドレスをこれらのネットワークの両方に得るでしょう。 次に、それぞれのこれらの2TRDsが他のTRDsに2つの接頭語の広告を出すでしょう、そして、葉の経路ドメインへの1つの接頭語がそれだけに付きました、そして、葉の経路ドメインへの1つの接頭語が両方に付きました。
This fourth solution is likely to be 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 current NSFNET regionals)
may have a set of customers which overlaps substantially with the
public networks.
この4番目の解決策は公衆データネットワークの使用が、より一般的になるとき、重要である傾向があります。 未来の何らかのポイントでは、特に、すべての経路ドメインのかなりの割合が公衆データネットワークに付けられそうでしょう。 この場合、ほとんどすべての政府によって後援されたネットワーク(いくつかの現在のNSFNET地方版などの)には、実質的に公衆通信回線に重なる顧客のセットがあるかもしれません。
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 TRDs (including those to which
the multi-homed organizations are not attached).
したがって、アドレスをNSAPに割り当てるという問題の多くの可能な解決がある、マルチ、家へ帰り、経路ドメイン。 それぞれのこれらの解決策には、非常に異なった利点と損失があります。 各解決策が異なった本当(すなわち、財政的な)の費用を置く、マルチ、家へ帰り、組織、TRDs、(それらを含んでいる、どれ、マルチ、家へ帰り、付けられなかった組織)
In addition, most of the solutions described also highlight the need
for each TRD to develop policy on whether and under what conditions
to accept 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 non-local NSAP prefixes will be
accepted from any attached leaf RD, but not advertised to other TRDs.
In a less conservative policy, a TRD might accept such non-local
prefixes and agree to exchange them with a defined set of other TRDs
(this set could be an a priori group of TRDs that have something in
common such as geographical location, or the result of an agreement
specific to the requesting leaf RD). Various policies involve real
costs to TRDs, which may be reflected in those policies.
また、さらに、説明された解決策の大部分は各TRDが扱われて自分自身のが基づいていないアドレスがオンであると受け入れるどんな条件のもとで接頭語を記述するか、そして、そのような非ローカルのアドレスがどのように扱われるかに関する方針を開発する必要性を強調します。 例えば、いくらか保守的な方針は非ローカルのNSAP接頭語がどんな付属葉のRDからも受け入れますが、他のTRDsに広告を出さないということであるかもしれません。 それほど保守的でない方針で、TRDは、そのような非ローカルの接頭語を受け入れて、他のTRDsの定義されたセットとそれらを交換するのに同意するかもしれません(このセットは地理的な位置、または要求葉のRDに特定の協定の結果などのように一脈相通じるものがあるTRDsの先験的なグループであるかもしれません)。 様々な方針は本当のコストをTRDsに伴います。(TRDsはそれらの方針に反映されるかもしれません)。
Colella, Gardner, & Callon [Page 28]
Colella、ガードナー、およびCallon[28ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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 addresses reachable in XYZ
Corporation).
例えば、XYZ会社がMBIIと多くビジネスをすると思いましょう。 この場合、XYZとMBIIは、キャリヤーで2つの会社の間の個人的なリンクを提供するのを契約するかもしれません。そこでは、このリンクが2つの会社の1つの中にソースがあって、2つの会社のもう片方の中に目的地があるパケットに使用されるだけであるかもしれません。 最終的に、ポイントツーポイント接続がXYZ会社の中のただ一つのルータ(ルータX)とMBIIの中のただ一つのルータ(ルータM)の間で接続されると仮定してください。 したがって、どのアドレスにこのリンク(明確にMBIIで届いているすべてのアドレス)の上に達することができるかを知るためにルータXを構成するのが必要です。 同様に、どのアドレスにこのリンク(明確にXYZ社で届いているすべてのアドレス)の上に達することができるかを知るためにルータMを構成するのが必要です。
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 TRD's
prefix.
ここでされる重要な観測はそのような個人的なリンクがNSAP配分の目的のために無視されるかもしれなくて、ルーティングのために問題を設定しないということです。 これは個人的なリンクに関連しているルーティング情報によってインターネット中で伝播されないで、したがって、TRDの接頭語まで潰される必要はないからです。
In our example, lets suppose that the XYZ corporation has a single
connection to an NSFNET regional, and has therefore received an
address allocation from the space administered by that regional.
Similarly, let's suppose that MBII, as an international corporation
with connections to six different backbones or regionals, 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
私たちの例でさせる、XYZ会社が単独結合をNSFNETに地方にして、したがって、それによって地方で管理されたスペースからアドレス配分を受けたと思わせます。 同様に、MBIIが6つの異なった背骨か地方版との接続がある国際会社としてセクション5.4から2番目の解決策を選んで、したがって、6つの異なったアドレス配分を得たと思いましょう。 この場合、ただ一つのアドレス接頭語はXYZ社で届いているすべてのアドレスについて説明できます。
Colella, Gardner, & Callon [Page 29]
Colella、ガードナー、およびCallon[29ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
(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).
(ルータMがただ一つのアドレス接頭語によって構成されて、ポイントへのこのポイントリンクの上に届いているアドレスを表す必要であるだけであるのを含意します。) 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 leaf routing domain which has a single connection to a
``public'' backbone (e.g., the NSFNET), plus a number of private
point-to-point links to other leaf routing domains, can be treated
as if it were single-homed to the backbone for the purpose of NSAP
address allocation.
この紙の他のセクションで説明されたルーティングとNSAPアドレシングとの関係は多くの経路ドメインとインタコネクトする大きくて、本質的には公共のトランジット経路ドメインによって引き起こされたスケーリングで問題に関係があることに注意してください。 しかしながら、少ない数の個人的な経路ドメインだけとインタコネクトする個人的なポイントツーポイント接続は、NSAP配分の目的のために、問題を設定しないで、無視されるかもしれません。 例えば、これは、まるでそれがNSAPアドレス配分を目的のための背骨とシングル家へ帰らせるかのように「公共」の背骨(例えば、NSFNET)への単独結合、および多くの個人的なポイントツーポイント接続を他の葉の経路ドメインに持っている単葉経路ドメインは扱うことができるのを含意します。
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,
無、家へ帰り、経路ドメインは、前項で議論するように個人的なリンクがある経路ドメインの堕落したケースであるとみなすことができて、相互ドメインルーティングのために問題を設定しません。 同じくらい上
Colella, Gardner, & Callon [Page 30]
Colella、ガードナー、およびCallon[30ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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., Addendum 2 to ISO8348). 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へのAddendum2)に加入するインターネットに参加します。 このRDが見分けることができなければならない、無、家へ帰り、ドメインのNSAPsとそれが発送する必要があるかもしれないいかなる他のNSAPsも発送します。 これを保証できる唯一の方法がそうである、無、家へ帰り、経路ドメインはグローバルにユニークなNSAPsを使用します。
5.7 Transition Issues
5.7 変遷問題
Allocation of NSAP addresses based on connectivity to TRDs 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.
TRDsへの接続性に基づくNSAPアドレスの配分は、インターネットに掘られる相互ドメイン含有のスケーリングに何百万もの経路ドメインを許容するために重要です。 しかしながら、また、トポロジーに基づくそのようなアドレス配分は、トポロジーの変化が住所の変更をもたらすかもしれないのを含意します。
This need to allow for change in addresses is a natural, inevitable
consequence of 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.
アドレスにおける変化を考慮するこの必要性はルーティングデータ抽象化の自然で、必然の結果です。 ルーティングデータ抽象化の基本的な概念はアドレスの間と、そして、システム(すなわち、経路ドメイン、領域、またはエンドシステム)が位置しているところに何らかの通信があるということです。 したがって、システムが動くと、いくつかの場合、アドレスは変化しなければならないでしょう。 それが経路ドメインの間でアドレスを変えないで接続性を変えるのにおいて可能であるなら、個別的にその経路ドメインの位置の動向をおさえるのが明確に必要でしょうに。
In the short term, due to the rapid growth and increased commer-
cialization 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.
短期で、インターネットの急速な成長と増加するcommer- cializationのために、トポロジーが比較的不安定であることは、可能です。 これは、アドレス変遷の計画を立てるのが非常に重要であることを含意します。 幸い、努力がアドレス変遷のために必要とした容易さを助けるために取ることができる多くの方法があります。 アドレス変遷問題の完全な記述がこの紙の範囲の外にあります。 しかしながら、いくつかの変遷問題の非常に簡潔なアウトラインはこのセクションに含まれています。
Colella, Gardner, & Callon [Page 31]
Colella、ガードナー、およびCallon[31ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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 DIS10589.
As described in Section 3, DIS10589 allows multiple addresses to
be assigned to each area specifically for the purpose of easing
transition.
DIS10589は既に変遷への支給に組み込まれました。 セクション3で説明されるように、DIS10589は、複数のアドレスが特に変遷を緩和する目的のために各領域に割り当てられるのを許容します。
Similarly, there are provisions in OSI for the autoconfiguration of
area addresses. This allows OSI end systems to find out their area
addresses automatically by observing the ISO9542 IS-Hello packets
transmitted by routers. If the ID portion of the address is assigned
by using IEEE style ``stamped in PROM at birth'' identifiers, then
an end system can reconfigure its entire NSAP address automatically
without the need for manual intervention. However, routers will still
need manual address reconfiguration.
同様に、条項が領域アドレスの自動構成のためのOSIにあります。 OSIエンドシステムがこれで見ることによって自動的にそれらの領域アドレスを突き止めることができる、ISO9542 IS、-、こんにちは、パケットはルータで伝わりました。 アドレスのID部分がIEEEスタイルを使用するのが「PROMでは、出生によって、押し込まれた」という識別子によって割り当てられるなら、エンドシステムは手動の介入の必要性なしで全体の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 NSFNET regional. The XYZ Corporation
therefore went off to the NorthSouthNet administration and got a
routing domain assignment based on the AA value assigned to the
NorthSouthNet regional under the GOSIP address space. However, for
a variety of reasons, the XYZ Corporation decided to terminate its
association with the NorthSouthNet, and instead connect directly to
例えば、XYZ社が以前にNorthSouthNet NSFNETだけに地方で接続されたと仮定してください。 XYZ社は、したがって、NorthSouthNet管理へ去って、経路ドメイン課題をGOSIPアドレス空間の下における地方のNorthSouthNetに割り当てられたAA値に基づかせていました。 しかしながら、さまざまな理由で、XYZ社は、NorthSouthNetとの協会を終えて、代わりに直接接続すると決めました。
Colella, Gardner, & Callon [Page 32]
Colella、ガードナー、およびCallon[32ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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.
NewCommercialNet公衆データネットワーク。 したがって、XYZ社は現在、NewCommercialNetに割り当てられたANSIアドレスの下で新しいアドレス課題を持っています。 XYZ社のための旧住所はXYZ社のための交通がXYZ社との少しのダイレクト接続ももうないNorthSouthNetに発送されるべきであるのを含意するように思えるでしょう。
If the old TRD (NorthSouthNet) and the new TRD (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.
古いTRD(NorthSouthNet)と新しいTRD(NewCommercialNet)が隣接していて協力的であるなら、この変遷は達成しやすいです。 この場合、旧住所課題を使用することでXYZ社に発送されたパケットはNorthSouthNetに発送できました。(直接、NorthSouthNetはそれらをNewCommercialNetに送るでしょう)。(順番に、NewCommercialNetはXYZ社にそれらを送るでしょう)。 この場合、NorthSouthNetとNewCommercialNetだけが旧住所がもう直接NorthSouthNetに付けられていない目的地について言及するという事実を知っていなければなりません。
If the old TRD and the new TRD are not adjacent, then the situation
is a bit more complex, but there are still several possible ways to
forward traffic correctly.
古いTRDと新しいTRDが隣接していないなら、状況はもう少し複雑ですが、正しく交通を進めるいくつかの可能な方法がまだあります。
If the old TRD and the new TRD are themselves connected by other
cooperative transit routing domains, 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.
古いTRDと新しいTRDが他の協力的なトランジット経路ドメインによって接続されるなら、これらの中間的ドメインは、XYZのために正しく交通を進めるのに同意するかもしれません。 例えば、NorthSouthNetとNewCommercialNetが直接接続されませんが、それらがともに直接NSFNET背骨に接続されると仮定してください。 この場合、NorthSouthNet、NewCommercialNet、およびすべての3つのNSFNET背骨が、NewCommercialNetを通して旧住所配分を使用するXYZへの交通を進めて、XYZ会社のために特別なエントリーを維持する必要があるでしょう。 しかしながら、他の経路ドメインはXYZ社において新しい位置を意識している必要はないでしょう。
Suppose that the old TRD and the new TRD are separated by a non-
cooperative routing domain, or by a long path of routing domains. In
this case, the old TRD could encapsulate traffic to XYZ Corporation in
order to deliver such packets to the correct backbone.
古いTRDと新しいTRDが非協力的な経路ドメイン、または経路ドメインの長い経路によって切り離されると仮定してください。 この場合、古いTRDは、そのようなパケットを正しい背骨に届けるために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 Corporation,
また、XYZ社と共に重要な取引高をするそれらの位置はパケットの最適ルーティングをXYZに確実にするために加えられたそれらの経路指定テーブルに特定のエントリーを持っているかもしれません。 例えば、別の商業背骨"OldCommercialNet"にはXYZ社と交通を交換する顧客の多くがあると仮定してください。
Colella, Gardner, & Callon [Page 33]
Colella、ガードナー、およびCallon[33ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
and that this third TRD 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.
そして、この第3TRDは直接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 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 OSI is introduced in the
Internet, it is therefore essential to choose a hierarchical structure
for NSAP addresses with great care.
私たちは、インターネットの現在の急激な増加が予見できる未来に続くか、または加速すると予期します。 さらに、私たちはインターネットの急速な国際化を予期します。 ルーティングが比例する能力は階層的なNSAPアドレスに基づくデータ抽象化の使用に依存しています。 したがって、インターネットでOSIを導入するとき、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
イントラドメイン、-、ルーティング・プロトコルは、情報抽象化が2つのレベルで維持されるのを許容します: システムは分類されます。
Colella, Gardner, & Callon [Page 34]
Colella、ガードナー、およびCallon[34ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
into areas, and areas are interconnected to form a routing domain.
For zero-homed and single-homed routing domains (which are expected
to remain zero-homed or single-homed), we recommend that the NSAP
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.
領域、および領域はそうです。経路ドメインを形成するために、インタコネクトされます。 無、家へ帰り、ドメインを発送しながらシングル家へ帰る、(残っていると予想される、無、家へ帰り、シングル家へ帰る、)、私たちは、NSAPアドレスが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.
私たちは、経路ドメインを超えた階層データ抽象化の追加レベルが平らにする十分すばらしくなるように世界的なOSIインターネットに存在する経路ドメインの総数が必要になると予期します。
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.
多くの場合、ネットワーク形態には、国境との密接な関係があるでしょう。 例えば、ネットワークの接続性の度合いは国より単一の国の中でしばしばさらに大きくなるでしょう。 したがって、国境に基づく特定の推薦状をするのは適切です、特定の状況がこれらの一般的な推薦が変更される必要があるところにあるかもしれないという条件で。
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 IDP format
used by NIST for GOSIP Version 2, and the DCC=840 format defined by
ANSI.
インターネットの米国の部分の中の使用のためのNSAPアドレスによって主として2つのアドレス接頭語に基礎づけられると予想されます: IDP形式はGOSIPにNISTで形式がANSIで定義したバージョン2、およびDCC=840を使用しました。
We anticipate that, in the U.S., public interconnectivity between
private routing domains will be provided by a diverse set of TRDs,
including (but not necessarily limited to):
私たちはそれを予期しますが、間の米国の、そして、公共の相互接続性では、個人的な経路ドメインにTRDsのさまざまのセットによって提供されて、含むのと(必ず有限であるというわけではない)でしょう:
* the NSFNET backbone;
* NSFNET背骨。
* a number of NSFNET regional networks; and,
* 多くのNSFNET地域ネットワーク。 そして
* a number of commercial Public Data Networks.
* 多くの商業Public Data Networks。
It is also expected that these networks will not be interconnected
in a strictly hierarchical manner (for example, there is expected
to be direct connectivity between NSFNET regionals, and all three of
these types of networks may have direct international connections).
また、これらのネットワークが厳密に階層的な方法でインタコネクトされない(例えば、NSFNET地方版の間でダイレクト接続性があると予想されます、そして、ネットワークのこれらのタイプ3人には皆、ダイレクト国際的な接続があるかもしれない)と予想されます。
Colella, Gardner, & Callon [Page 35]
Colella、ガードナー、およびCallon[35ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
However, the total number of such TRDs is expected to remain (for the
foreseeable future) small enough to allow addressing of this set of
TRDs via a flat address space. These TRDs 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.
しかしながら、そのようなTRDsの総数がフラットアドレス空間を通して記述するのをTRDsのこのセットを許容できるくらい小さいままで残っている(予見できる未来に)と予想されます。 これらのTRDsは、さまざまな経路ドメインとインタコネクトするのに使用されるでしょう。それはそれぞれ単一の会社、会社の一部、大学構内、政府機関、または他の組織的なユニットを包括するかもしれません。
In addition, some private corporations may be expected to make use of
dedicated private TRDs for communication within their own corporation.
さらに、いくつかの私法人がコミュニケーションにそれら自身の会社の中で専用個人的なTRDsを利用すると予想されるかもしれません。
We anticipate that the great majority of routing domains will be
attached to only one of the TRDs. This will permit hierarchical
address abbreviation based on TRD. We therefore strongly recommend
that addresses be assigned hierarchically, based on address prefixes
assigned to individual TRDs.
私たちは、経路ドメインの大多数がTRDsの1つだけに付けられると予期します。 これはTRDに基づく階層的なアドレス略語を可能にするでしょう。 したがって、私たちは、アドレスが個々のTRDsに割り当てられたアドレス接頭語に基づいて階層的に割り当てられることを強く勧めます。
For the GOSIP address format, this implies that Administrative
Authority (AA) identifiers should be assigned to all TRDs (explicitly
including the NSFNET backbone, the NSFNET regionals, and other major
government backbones). For those leaf routing domains which are
connected to a single TRD, they should be assigned a Routing Domain
(RD) value from the space assigned to that TRD.
GOSIPアドレス形式のために、これは、Administrative Authority(AA)識別子がすべてのTRDs(明らかに、NSFNET背骨、NSFNET地方版、および他の主要な政府背骨を含んでいる)に割り当てられるべきであるのを含意します。 独身のTRDにつなげられるそれらの葉の経路ドメインにおいて、ルート設定Domain(RD)値はそのTRDに割り当てられたスペースからそれらに割り当てられるべきです。
We recommend that all TRDs explicitly be involved in the task of
address administration for those leaf routing domains which are
single-homed to them. This will offer a valuable service to their
customers, and will also greatly reduce the resources (including
human and network resources) necessary for that TRD to take part in
inter-domain routing.
私たちは、そうするそれらの葉の経路ドメインがそれらとシングル家へ帰ったのですべてのTRDsが明らかにアドレス管理に関するタスクにかかわることを勧めます。 これは、彼らの顧客に対する貴重なサービスを提供して、また、そのTRDが相互ドメインルーティングに参加するのに必要なリソース(人間とネットワーク資源を含んでいる)を大いに減らすでしょう。
Each TRD should develop policy on whether and under what conditions to
accept addresses that are not based on its own address prefix, and how
such non-local addresses will be treated. Policies should reflect the
issue of cost associated with implementing such policies.
各TRDは扱われて自分自身のが基づいていないアドレスがオンであると受け入れるどんな条件のもとで接頭語を記述するか、そして、そのような非ローカルのアドレスがどのように扱われるかに関する方針を開発するはずです。 方針はそのような政策を実施すると関連しているコストの問題を反映するべきです。
We recommend that a similar hierarchical model be used for NSAP
addresses using the DCC-based address format. The structure for
DCC=840-based NSAPs is provided in Section A.2.
私たちは、同様の階層的なモデルがNSAPアドレスにDCCベースのアドレス形式を使用することで使用されることを勧めます。 DCC=840ベースのNSAPsのための構造をセクションA.2に提供します。
For routing domains which are not attached to any publically-
available TRD, there is not the same urgent need for hierarchical
address abbreviation. We do not, therefore, make any additional
recommendations for such ``isolated'' routing domains, except to
どんなpublicallyに利用可能なTRDにも付けられていない経路ドメインには、階層的なアドレス略語の同じ緊急の必要がありません。 私たちはしたがって、そのような「孤立している」経路ドメインのための少しの追加推薦状もしないで、除いてください。
Colella, Gardner, & Callon [Page 36]
Colella、ガードナー、およびCallon[36ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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, again no additional
technical problems relating to address abbreviation is caused by such
a link, and no specific additional recommendations are necessary.
GOSIP AA識別子値かANSI組織識別子の課題をそのようなドメインに排除するどんな技術的な理由もないことに注意してください。 そのようなドメインがどこで個人的なポイントツーポイント接続によって他のドメインにつなげられるか、そして、唯一再びそれらがインタコネクトする2つのドメインと、アドレス略語に関連するのがそのようなリンクによって引き起こされる追加技術的問題がなくて、特定の追加推薦の間のルーティングにおいて、そのようなリンクがどこで使用されているかが必要です。
6.2 Recommendations Specific to Non-U.S. Parts of the Internet
6.2 インターネットの非米国の地域に特定の推薦
For the part of the Internet which is outside of the U.S., it is
recommended that the DSP format be structured similarly to that
specified within GOSIP Version 2 no matter whether the addresses are
based on DCC or ICD format.
米国の外にあるインターネットの地域において、アドレスがDCCかICD形式に基づいて、DSP形式が同様にGOSIPバージョン2の中で指定されたそれに構造化されるのは、お勧めです。
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.3 Recommendations for Multi-Homed Routing Domains
6.3の推薦、マルチ、家へ帰り、経路ドメイン
Some routing domains will be attached to multiple TRDs within the
same country, or to TRDs within multiple different countries. We
refer to these as ``multi-homed'' routing domains. Clearly the strict
hierarchical model discussed above does not neatly handle such routing
domains.
いくつかの経路ドメインが同じ国の中の複数のTRDs、または、複数の異なった国の中のTRDsに付けられるでしょう。 私たちがこれらを参照する、「マルチ、家へ帰り、」 ドメインを発送します。 明確に、上で議論した厳しい階層的なモデルはそのような経路ドメインをきちんと扱いません。
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 TRDs;
* TRDsの中のルータの中の運用資金。
* administrative cost on TRD personnel; and,
* TRD人員の管理費。 そして
Colella, Gardner, & Callon [Page 37]
Colella、ガードナー、およびCallon[37ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
* difficulty of configuration of policy-based inter-domain routing
information within leaf 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 routing domains, regionals, and backbones.
これらの理由で、すべての状況のただ一つの解決策を強制するのは可能ではありません。 むしろ、経済上の考慮は異なった経路ドメイン、地方版、および背骨のさまざまな解決策を必要とするでしょう。
7 Security Considerations
7 セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Colella, Gardner, & Callon [Page 38]
Colella、ガードナー、およびCallon[38ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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@osi3.ncsl.nist.gov
以下に電話をしてください。 (301) 975-3627 メールしてください: colella@osi3.ncsl.nist.gov
EllaP. Gardner
The MITRE Corporation
7525 Colshire Drive
McLean, VA 22102
EllaP。 ガードナー・斜め継ぎ社7525のColshire Driveマクリーン、ヴァージニア 22102
Phone: (703) 883-5826
EMail: epg@gateway.mitre.org
以下に電話をしてください。 (703) 883-5826 メールしてください: epg@gateway.mitre.org
Ross Callon
c/o Digital Equipment Corporation, 1-2/A19
550 King Street
Littleton, MA 01460-1289
ロスCallon気付ディジタルイクイップメント社、リトルトン、1-2/A19 550キング・ストリートMA01460-1289
Phone: (508) 486-5009
Email: Callon@bigfut.enet.dec.com
以下に電話をしてください。 (508) 486-5009 メールしてください: Callon@bigfut.enet.dec.com
9 Acknowledgments
9つの承認
The authors would like to thank the members of the IETF OSI-NSAP
Working Group for the helpful suggestions made during the writing of
this paper.
作者はこの紙の書くことの間にされた役立つ提案についてIETF OSI-NSAP作業部会のメンバーに感謝したがっています。
Colella, Gardner, & Callon [Page 39]
Colella、ガードナー、およびCallon[39ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
A Administration of NSAPs
NSAPsの政権
NSAPs represent the endpoints of communication through the Network
Layer and must be globally unique [5]. Addendum 2 to ISO8348 defines
the semantics of the NSAP and the abstract syntaxes in which the
semantics of the Network address can be expressed [14].
NSAPsはNetwork Layerを通してコミュニケーションの終点を表して、グローバルにユニークな[5]であるに違いありません。 ISO8348への付加物2はNetworkアドレスの意味論を言い表すことができるNSAPの意味論と抽象構文を定義します。[14]。
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.
_______________
!_____IDP_____!________________________________
!__AFI_!_IDI__!______________DSP______________!
NSAPは初期のドメイン部分(IDP)とドメインの特定の部分(DSP)から成ります。 NSAPの初期のドメイン部分は権威、形式ID(AFI)、および初期のドメイン識別子(IDI)から成ります。 AFIはIDI(IDIの値、およびDSPの抽象構文を割り当てるのに原因となるネットワークアドレシング権威)の形式を指定します。 IDIはDSPの値が割り当てられるアドレシングサブドメインとそのドメインからDSPの値を割り当てるのに原因となるネットワークアドレシング権威を指定します。 DSPの構造と意味論はIDIによって特定された権威で決定します。 図3はNSAPアドレス構造を示しています。 _______________ !_____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 ISO8348/Addendum 2:
世界的なネットワークアドレス指定領域はOSI環境におけるすべてのNSAPアドレスから成ります。 その環境の中では、7つの第2レベルアドレス指定領域と対応するIDI形式がISO8348/付加物2で説明されます:
* 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 ISO3166 [9]
* ISO3166に応じて割り当てられたISO Data Country Code(DCC)[9]
Colella, Gardner, & Callon [Page 40]
Colella、ガードナー、およびCallon[40ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
* ISO International Code Designator (ICD), allocated according to
ISO6523 [10]
* ISO6523に応じて割り当てられたISO国際旗信号Designator(ICD)[10]
* 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 subdo-
main 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. (The
U.S. Government is registered as an organization by ANSI under the
DCC, and in turn, will register object identifiers and X.400 names
under this authority.)
米国政府のを通した使用について、米国のOSIネットワークにおいて、ICDサブドメインの部分があります、そして、American National Standards Institut(ANSI)のを通した使用について、DCC subdoメインがあります。 イギリスのStandards InstituteはICDサブドメインのための登録局であり、米国政府のために4IDIsを登録しました: GOSIP、DoD、OSINET、およびOSI Implementors Workshopに使用されるもの。 U.S. ISOメンバーBodyとして、ANSIは合衆国のDCCドメインへの登録局です。 (米国政府は組織としてDCCの下のANSIによって登録されて、順番に、この権限の下で物の識別子とX.400名を登録するでしょう。)
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 on page 16. 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アドレシングサブドメインは16ページの図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 [4] (see Figure 2,
page 16). 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[4]で(図2を見てください、16ページ)。 NISTはGOSIPバージョン2NSAPsのためのAA識別子を共通役務庁(GSA)に登録する権威を代表として派遣しました。
Addendum 2 to ISO8348 allows a maximum length of 20 octets for the
NSAP. 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
ISO8348への付加物2はNSAPのための20の八重奏の最大の長さを許容します。 47のAFIは1つの八重奏を占領します、そして、0005年のIDIは2つの八重奏を占領します。 DSPは47のAFIによって示されるのと同じくらい2進でコード化されます。 DSP Format Identifier、Administrative Authority識別子のための3つの八重奏、ルート設定のための2つの八重奏のために1つの八重奏を割り当てます。
Colella, Gardner, & Callon [Page 41]
Colella、ガードナー、およびCallon[41ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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 DIS10589 [17], 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.
ドメイン、Areaのための2つの八重奏、System Identifierのための6つの八重奏、およびNSAPセレクタのための1つの八重奏。 今後の成長に対応して、相互ドメインルーティングに追加柔軟性を提供するために2つの八重奏を控えてあることに注意してください。 DIS10589[17]によると、GOSIP NSAP形式の最後の7つの八重奏が構造化されます、イントラドメイン、-、ルーティング・プロトコル。 DSP Format Identifier(DFI)は残っているDSP構造の形式を特定して、将来、追加DSP形式を特定するのに使用されるかもしれません。 DFIの値の80hはGOSIPバージョン2NSAP構造を特定します。
The Administrative Authority identifier names the administrative
authority which is responsible for registration within its domain.
The administrative authority may delegate the responsibility for
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識別子はドメインの中の登録に原因となる職務権限を命名します。 職務権限は経路ドメインに領域を登録することへの責任を代表として派遣するかもしれません、そして、経路ドメインはその領域に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 [13], 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の間のアドレス解決は、プロトコル[13]、局所的に管理されたテーブルであるか機能を写像しながら、ESによって実行されるかもしれません。 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.組織からの要求は副社長か最高執行責任者などの高官から発するべきです。
Colella, Gardner, & Callon [Page 42]
Colella、ガードナー、およびCallon[42ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
* 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に向かってください:
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
F通り、ワシントン、北西DC オフィスU.S.共通役務庁の情報資源管理サービス電気通信事務所が18番目に修理するテレコミュニケーション顧客の要求と20405
Fax 202 208-5555
ファックス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はそれ自身の「副-アドレス」のスペースを管理するでしょう。
Colella, Gardner, & Callon [Page 43]
Colella、ガードナー、およびCallon[43ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
* 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識別子の割り当てられた値を維持して、ピーアールして、広めるでしょう。
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 dissemi-
nating NSAPs to routing domains and to areas within each routing
domain.
* 権威は、手順がdissemi- nating NSAPsのために各経路ドメインの中に経路ドメインと、そして、領域に存在するのを確実にするべきです。
* The systems administrator must determine whether a logical or a
physical address should be used in the System Identifier field
(Figure2, page 16). 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.
* 上級システムアドミニストレータは、論理的であるかa物理アドレスがSystem Identifier分野(Figure2、16ページ)で使用されるべきであるかどうかと決心しなければなりません。 物理アドレスに関する例は48ビットのMACアドレスです。 論理アドレスは単にSystem Identifier分野をユニークさの必要条件を満たしますが、物理的なサブネットワークに関するアドレスに関係に全く堪えない数です。
* The network address itself contains no routing information [15].
Information that enables next-hop determination based on NSAPs
is gathered and maintained by each intermediate system through
routing protocol exchanges.
* ネットワーク・アドレス自体はルーティング情報[15]を全く含んでいません。 NSAPsに基づく次のホップ決断を可能にする情報が、ルーティング・プロトコル交換を通して各中間システムによって集められて、保守されます。
* GOSIP end systems and intermediate systems in federal agencies
must be capable of routing information correctly to and from any
subdomain defined by ISO8348/Addendum 2.
* 連邦機関におけるGOSIPエンドシステムと中間システムはどんなサブドメインからもサブドメインと、そして、ISO8348/付加物2によって定義されたルーティング情報が正しくできなければなりません。
* An agency may request the assignment of more than one Administra-
tive Authority identifier. The particular use of each should be
specified.
* 政府機関は1つ以上のAdministra- tive Authority識別子の課題を要求するかもしれません。 それぞれの特定の使用は指定されるべきです。
Colella, Gardner, & Callon [Page 44]
Colella、ガードナー、およびCallon[44ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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. Currently, there is a draft proposed
American National Standard (dpANS) in the U.S. for the DSP structure
under DCC=840 [1]. Subsequent to an upcoming ANSI X3 Committee ballot,
the dpANS will be distributed for public comment.
また、Data Country Code(DCC)サブドメインからのNSAPsは国際的なインターネットで一般的になるでしょう。 現在、DCC=840[1]の下にDSP構造には草稿の提案された米国標準規格(dpANS)が米国にあります。 今度のANSI X3 Committee投票にその後であり、dpANSはパブリックコメントのために分配されるでしょう。
In the dpANS, the DSP structure is identical to that specified in
GOSIP Version 2, with the Administrative Authority identifier replaced
by the numeric form of the ANSI-registered organization name, as shown
in Figure 4.
dpANSでは、DSP構造はGOSIPバージョン2で指定されたそれと同じです、Administrative Authority識別子をANSIによって登録された組織名の数値フォームに取り替えていて、図4に示されるように。
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 ISO3166 [9]. 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[9]の下の合衆国への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_-->。_____________! _DFI_!_ORG_!Rsvd_!RD_!Area_!_ID_!Sel_!八重奏!__840__!_39_!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形式。
Colella, Gardner, & Callon [Page 45]
Colella、ガードナー、およびCallon[45ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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で始まりながら、割り当てられます。
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 4976 (tel)
+1 212 398 0023 (fax)
登録コーディネータAmerican National Standards Institut11の西四十二番街ニューヨーク、ニューヨーク10036+1 212 642 4976(tel)+1 212 398 0023(ファックス)
Once an organization has registered with ANSI, it becomes a registra-
tion authority itself. In turn, it may delegate registration authority
to routing domains, and these may make further delegations, for in-
stance, 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とともに記名すると、それはregistra- tion権威自体になります。 順番に、登録局を経路ドメインへ代表として派遣するかもしれません、そして、これらは一層の代表団を作るかもしれません、コネ姿勢に、経路ドメインから領域まで。 一方、それぞれの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
NSAPsはグローバルにユニークでなければなりません、そして、組織はOSIアドレスのために2つの方法でこのユニークさを保証するかもしれません。 組織はAdministrative Authority識別子のためにGSAに申し込まれるかもしれません。 GSAによるAdministrative Authority識別子の登録は主として米国政府機関に役立ちますが、非政府とnon-U.S.組織を求める要求はケースバイケースで考えられるでしょう。 あるいはまた、組織は数値のためにANSIに申し込まれるかもしれません。
Colella, Gardner, & Callon [Page 46]
Colella、ガードナー、およびCallon[46ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
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を登録するか、またはそうする権威を代表として派遣することができます。
In the case of GOSIP Version 2 NSAPs, the complete DSP structure is
given in GOSIP Version 2. For ANSI DCC-based NSAPs, there is a draft
proposed American National Standard that specifies the DSP structure
under DCC=840. The dpANS specifies a DSP structure that is identical
to that specified in GOSIP Version 2.
GOSIPバージョン2NSAPsの場合では、GOSIPバージョン2で完全なDSP構造を与えます。 ANSI DCCベースのNSAPsのために、DCC=840の下でDSP構造を指定する草稿の提案されたアメリカのNational Standardがあります。 dpANSはGOSIPバージョン2で指定されたそれと同じDSP構造を指定します。
References
参照
[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. Draft Proposed American National
Standard, 1991 (pending final approval by ANSI).
[1] ANSI。 OSIネットワークサービスアクセスポイント(NSAP)アドレスのドメインの特定の部分(DSP)の構造と意味論のための米国標準規格。 ProposedのアメリカのNational Standard、1991(ANSIによる未定の最終承認)を作成してください。
[2] Tim Boland. 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] ティム・ボーランド。 政府オープンシステムインタコネクトはユーザのガイドバージョン2[草稿]の輪郭を描きます。 NISTの特別な公表、米国商務省標準技術局、コンピュータシステム研究所、ゲイザースバーグ(MD)1991年6月。
[3] ECMA. Inter-Domain Routeing. Technical Report 50, ISO/IEC JTC 1,
Switzerland, 1989.
[3] ECMA。 相互ドメインRouteing。 技術報告書50、ISO/IEC JTC1、スイス1989。
[4] 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.
[4] GOSIPの高度な要件は分類されます。 政府オープンシステムインタコネクトは(GOSIP)バージョン2の輪郭を描きます。 連邦情報処理基準146-1、米国商務省、米国商務省標準技術局、ゲイザースバーグ(MD)1991年4月。
[5] Christine Hemrick. The OSI Network Layer Addressing Scheme, Its
Implications, and Considerations for Implementation. NTIA Report
85-186, U.S. Department of Commerce, National Telecommunications
and Information Administration, 1985.
[5] クリスティンHemrick。 実現のためのOSIネットワーク層アドレシング計画、含意、および問題。 NTIAは85-186、米国商務省、電気通信情報局、1985を報告します。
[6] ISO. Addendum to the Network Service Definition Covering Network
Layer Addressing. RFC 941,Network Working Group, April 1985.
[6] ISO。 ネットワーク層アドレシングをカバーするネットワーク・サービス定義への付加物。 RFC941、作業部会、1985年4月をネットワークでつないでください。
Colella, Gardner, & Callon [Page 47]
Colella、ガードナー、およびCallon[47ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
[7] ISO. End System to Intermediate System Routing Exchange Protocol
for use in conjunction with ISO 8473. RFC 995, Network Working
Group, April 1986.
[7] ISO。 ISO8473に関連して使用のためのIntermediate Systemルート設定ExchangeプロトコルへのSystemを終わらせてください。 RFC995、作業部会、1986年4月をネットワークでつないでください。
[8] ISO. Final Text of DIS 8473, Protocol for Providing the
Connectionless-mode Network Service. RFC 994, Network Working
Group, March 1986.
[8] ISO。 不-8473年の最終版の教科書、コネクションレスなモードネットワーク・サービスを提供するためのプロトコル。 RFC994、作業部会、1986年3月をネットワークでつないでください。
[9] ISO/IEC. Codes for the Representation of Names of Countries.
International Standard 3166, ISO/IEC JTC 1, Switzerland, 1984.
[9] ISO/IEC。 国の名前の表現のためのコード。 国際規格3166、ISO/IEC JTC1、スイス1984。
[10] ISO/IEC. Data Interchange - Structures for the Identification
of Organization. International Standard 6523, ISO/IEC JTC 1,
Switzerland, 1984.
[10] ISO/IEC。 データは交換されます--組織の識別のための構造。 国際規格6523、ISO/IEC JTC1、スイス1984。
[11] ISO/IEC. Information Processing Systems - Open Systems Intercon-
nection- Basic Reference Model. International Standard 7498,
ISO/IEC JTC 1, Switzerland, 1984.
[11] ISO/IEC。 情報Processing Systems--Systems Intercon- nectionの基本的なReference Modelを開いてください。 国際規格7498、ISO/IEC JTC1、スイス1984。
[12] ISO/IEC. Protocol for Providing the Connectionless-mode Network
Service. International Standard 8473, ISO/IEC JTC 1, Switzerland,
1986.
[12] ISO/IEC。 コネクションレスなモードネットワーク・サービスを提供するには、議定書を作ってください。 国際規格8473、ISO/IEC JTC1、スイス1986。
[13] ISO/IEC. End System to Intermediate System Routing Exchange
Protocol for use in Conjunction with the Protocol for the Provi-
sion of the Connectionless-mode Network Service. International
Standard 9542, ISO/IEC JTC 1, Switzerland, 1987.
[13] ISO/IEC。 プロトコルがあるConjunctionにおける、Connectionless-モードNetwork ServiceのProvi- sionの使用のためのIntermediate Systemルート設定ExchangeプロトコルへのSystemを終わらせてください。 国際規格9542、ISO/IEC JTC1、スイス1987。
[14] ISO/IEC. Information Processing Systems -- Data Communications
-- Network Service Definition Addendum 2: Network Layer Address-
ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
Switzerland, 1988.
[14] ISO/IEC。 情報処理システム(データ通信)はサービス定義付加物2をネットワークでつなぎます: Layer Address- ingをネットワークでつないでください。 国際規格8348/付加物2、ISO/IEC JTC1、スイス1988。
[15] ISO/IEC. Information Processing Systems - OSI Reference Model
- Part3: Naming and Addressing. Draft International Standard
7498-3, ISO/IEC JTC 1, Switzerland, March 1989.
[15] ISO/IEC。 情報処理システム--OSI規範モデル--Part3: 命名して、記述します。 7498-3と、1989年のISO/IECのJTC1、スイスの行進のときに国際規格を作成してください。
[16] ISO/IEC. Information Technology - Telecommunications and
Information Exchange Between Systems - OSI Routeing Framework.
Technical Report 9575, ISO/IEC JTC 1, Switzerland, 1989.
[16] ISO/IEC。 情報技術--システムの間のテレコミュニケーションと情報交換--OSI Routeing枠組み。 技術報告書9575、ISO/IEC JTC1、スイス1989。
[17] ISO/IEC. Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the
[17] ISO/IEC。 Conjunctionにおける使用のためのIntermediate System Intra-ドメインRouteing Exchangeプロトコルへの中間的System
Colella, Gardner, & Callon [Page 48]
Colella、ガードナー、およびCallon[48ページ]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
インターネット1991年7月のオウシNSAP AllocationのためのRFC1237ガイドライン
Protocol for Providing the Connectionless-mode Network Service
(ISO 8473). Draft International Standard 10589, ISO/IEC JTC 1,
Switzerland, November 1990.
コネクションレスなモードネットワーク・サービス(ISO8473)を提供するには、議定書を作ってください。 JTC1、スイス1990年11月に国際規格10589、ISO/IECを作成してください。
[18] K. Loughheed and Y. Rekhter. A Border Gateway Protocol (BGP).
RFC 1105, Network Working Group, 1989.
K.がLoughheedした[18]とY.Rekhter。 ボーダ・ゲイトウェイ・プロトコル(BGP)。 RFC1105、作業部会、1989をネットワークでつないでください。
[19] K. Loughheed and Y. Rekhter. A Border Router Protocol(BRP).
Draft, Network Working Group, February 1990.
K.がLoughheedした[19]とY.Rekhter。 境界ルータプロトコル(BRP)。 草稿、ネットワーク作業部会、1990年2月。
[20] ASC X3S3.3. Intermediate System to Intermediate System Inter-
Domain Routeing Exchange Protocol. Working Document 90-216, ANSI,
New York, July 1990.
[20] ASC X3S3.3。 中間システム相互ドメインRouteing交換プロトコルへの中間システム。 1990年7月にドキュメント90-216、ANSI、ニューヨークを扱います。
Colella, Gardner, & Callon [Page 49]
Colella、ガードナー、およびCallon[49ページ]
一覧
スポンサーリンク
