RFC1277 日本語訳
1277 Encoding Network Addresses to Support Operation over Non-OSILower Layers. S.E. Hardcastle-Kille. November 1991. (Format: TXT=22254, PS=176169 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S.E. Hardcastle-Kille
Requests for Comments 1277 University College London
November 1991
ネットワークワーキンググループ東南Hardcastle-Killeは1991年11月にコメント1277のためにユニバーシティ・カレッジロンドンを要求します。
Encoding Network Addresses
to support operation over non-OSI lower layers
非OSIの低級層の上の操作をサポートするためにNetwork Addressesをコード化します。
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.
Abstract
このMemo This RFCの状態は、IAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。 要約
The OSI Directory specifies an encoding of Presentation Address,
which utilises OSI Network Addresses as defined in the OSI
Network Layer standards [CCI88] [ISO87a]. The OSI Directory, and
any OSI application utilising the OSI Directory must be able use
these Network Addresses to identify end systems. Currently, OSI
applications are often run over lower layers other than the OSI
Network Service. It is neither reasonable nor desirable for
groups wishing to investigate and use OSI Applications in
conjunction with the OSI Directory to be dependent on a global
OSI Network Service. This document defines a new network address
format, and rules for using some existing network address
formats. The scope of this document is:
OSIディレクトリはPresentation Addressのコード化を指定します。(Presentation AddressはOSI Network Layer規格[CCI88][ISO87a]で定義されるようにOSI Network Addressesを利用します)。 しばしばOSIディレクトリ、およびできる使用がシステム現在の終わりのOSIのときにアプリケーションを特定するこれらのNetwork Addressesであったに違いないならOSIディレクトリを利用するどんなOSIアプリケーションもそうです。OSI Network Service以外の下層をひいてください。 OSIディレクトリに関連してOSI Applicationsを調査して、使用したがっているグループには、グローバルなOSI Network Serviceに依存しているのは、妥当でなくて、また望ましくはありません。 このドキュメントは新しいネットワークアドレス形式、およびいくつかの既存のネットワークアドレス形式を使用するための規則を定義します。 このドキュメントの範囲は以下の通りです。
1. Any TCP/IP network supporting COTS using RFC 1006.
1. RFC1006を使用することでCOTSをサポートするどんなTCP/IPネットワーク。
2. Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is
not used to provide CONS (i.e., only DTE and not Network address
is carried).
2. X.25へのCOTSに関するどんなマッピング、も(通常X.25(80))。(そこでは、X.25が、コンズを提供するのに使用されません(Networkアドレスではなく、すなわち、DTEだけが運ばれます))。
The approach could also be extended to use with other means of
providing COTS (or CLTS). It is not appropriate for use where
CONS or CLNS is used to provide COTS (or CLTS).
また、提供する他の手段でCOTSを使用するために進入路を広げることができました(または、CLTS)。 使用には、それはコンズかCLNSがCOTS(または、CLTS)を提供するのに使用されるところで適切ではありません。
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
1 Introduction
1つの序論
The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSI Network Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI application utilising the OSI Directory must be able use these Network Addresses to identify end systems. Currently, OSI applications are often run over lower layers other than the OSI Network Service. It is neither reasonable nor desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to be dependent on a global OSI Network Service. This RFCdefines mechanisms to encode addressing information within Network Addresses, in order to support this type of working. In particular, support is defined for RFC 1006 mapping of COTS onto TCP/IP and COTS mapped onto X.25(1980) [RC87, CCI80].
OSIディレクトリはPresentation Addressのコード化を指定します。(Presentation AddressはOSI Network Layer規格[CCI88][ISO87a]で定義されるようにOSI Network Addressesを利用します)。 しばしばOSIディレクトリ、およびできる使用がシステム現在の終わりのOSIのときにアプリケーションを特定するこれらのNetwork Addressesであったに違いないならOSIディレクトリを利用するどんなOSIアプリケーションもそうです。OSI Network Service以外の下層をひいてください。 OSIディレクトリに関連してOSI Applicationsを調査して、使用したがっているグループには、グローバルなOSI Network Serviceに依存しているのは、妥当でなくて、また望ましくはありません。 このタイプの働きをサポートするためにNetwork Addressesの中で情報を扱うコード化するこのRFCdefinesメカニズム。 特に、サポートはCOTSに関するRFC1006マッピングのためにX.25(1980)[RC87、CCI80]に写像されたTCP/IPとCOTSと定義されます。
Where an OSI application is run over CLNS on the internet, the NSAP Guidelines of RFC 1237 should be followed [CGC91]. This document must be read in the context of ISO 8348 Addendum 2 [ISO87b]. It will not be meaningful on its own.
OSIアプリケーションがCLNSに実行されるところに、インターネットでは、RFC1237のNSAP Guidelinesは続かれるべきです[CGC91]。 ISO8348Addendum2[ISO87b]の文脈でこのドキュメントを読まなければなりません。 それはそれ自身のところで重要にならないでしょう。
1.1 Historical Note
1.1 歴史的な注意
This document was originally published as UCL Research Note RN/89/13 and as a project THORN internal document [Kil89]. It was devised in response to two projects which faced this requirement, and was agreed as a common approach. The projects were:
このドキュメントは元々、UCL Research Note RN/89/13としてプロジェクトTHORN内部文書[Kil89]として発表されました。 それはこの要件に直面していた2つのプロジェクトに対応して工夫されて、一般的なアプローチとして同意されました。 プロジェクトは以下の通りでした。
o The THORN project, which is an Esprit Project building an OSI
Directory [SA88].
o THORN(OSIディレクトリ[SA88]を築き上げるEsprit Projectである)は突出しています。
o The ISODE project [Ros90], and in particular the QUIPU directory
being developed at UCL [Kil88].
o ISODEは[Ros90]、および特にUCL[Kil88]で開発されるQUIPUディレクトリを映し出します。
The proposal has been implemented, and the viability of the solution demonstrated.
提案は実装されました、そして、ソリューションの生存力は示されました。
Hardcastle-Kille Page 1
Hardcastle-Kille1ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
2 Problem Statement
2 問題声明
When utilising the OSI Directory, the OSI location of an End System will be determined by a Network Address, which is taken from a Presentation Address, looked up in the OSI Directory. OSI applications are currently operated over the following lower layers.
OSIディレクトリを利用するとき、End SystemのOSI位置はNetwork Addressによって決定されるでしょう。(Network AddressはOSIディレクトリで調べられたPresentation Addressから取られます)。 OSIアプリケーションは現在、以下の下層の上で操作されます。
o An international X.25 network, which routes on the basis of X.121
addresses. By and large this is X.25(80), but some parts are now
X.25(84) and will carry Network Addresses as user data. OSI
Transport is mapped onto the variant of X.25 which is available.
o 国際的なX.25ネットワーク。(そのネットワークはX.121に基づいてアドレスを発送します)。 概して、これがX.25(80)ですが、いくつかの部品が、現在X.25(84)であり、利用者データとしてNetwork Addressesを運ぶでしょう。 OSI Transportは利用可能なX.25の異形に写像されます。
o Large private X.25 networks, which do not have DNICs, but are
otherwise similar to the previous (in particular Janet).
o 大きい私設のX.25ネットワーク(特にジャネット)。(DNICsを持っていませんが、そうでなければ、そのネットワークは前と同様です)。
o Isolated networks running Connection Oriented Network Service
(e.g., Pink Book Ethernets).
o Connection Oriented Network Service(例えば、Pink Book Ethernets)を実行する孤立しているネットワーク。
o Isolated networks running Connectionless Network Service (e.g.,
MAP LANs).
o Connectionless Network Service(例えば、MAP LAN)を実行する孤立しているネットワーク。
o The Connectionless Network Service Protocol (CLNP) pilot,
currently taking place in the NSFNet and NORDUNet communities.
o 現在NSFNetとNORDUNet共同体で行われて、(CLNP)が操縦するConnectionless Network Serviceプロトコル。
o Isolated TCP/IP LANs, utilising RFC 1006 to support the OSI
Transport Service[RC87].
o OSI Transport Service[RC87]をサポートするのにRFC1006を利用して、TCP/IP LANを隔離しました。
o The DARPA/NSF Internet, using RFC 1006.
o RFC1006を使用するDARPA/NSFインターネット。
In general, these systems need to be interconnected by the use of transport bridging or application relaying. Operation of transport bridges causes a number of problems which it is desirable to avoid. Only some applications can support relaying, and this is not always satisfactory.
一般に、これらのシステムは、輸送のブリッジするかアプリケーションリレーの使用でインタコネクトされる必要があります。 輸送ブリッジの操作は避けるのが望ましい多くの問題を引き起こします。 いくつかだけのアプリケーションがリレーをサポートすることができます、そして、これはいつも満足できるというわけではありません。
2.1 The ``Right Solution''
2.1 「正しい解決」
It is worth noting briefly what the intended (OSI) solution is. There is a single global network service. Network Addresses are globally allocated, and do not imply anything about routing or location. An
意図している(OSI)ソリューションが何であるかに簡潔に注意する価値があります。 ただ一つの世界的なネットワークサービスがあります。 ネットワークAddressesはグローバルに割り当てられて、ルーティングか位置に関して何も含意しません。 1
Hardcastle-Kille Page 2
Hardcastle-Kille2ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
End System is attached to one or more subnetworks at Subnetwork Points of Attachment (SNPAs). Intermediate Systems join subnetworks, again being attached at SNPAs. Routing is achieved by repeated binding of Network Address to SNPA (initially at the Originating End System, and then at each Intermediate System). This binding is achieved by network level routing mechanisms. This can only work in a pure OSI environment with a single ubiquitous network service (either connectionless or connection-oriented), and so is not sufficient for the problem being addressed by this note.
終わりのSystemはAttachment(SNPAs)のSubnetwork Pointsの1つ以上のサブネットワークに取り付けられます。 再びSNPAsに付けられていて、中間的Systemsはサブネットワークを接合します。 Originating End Systemにおいてルート設定がNetwork Addressの繰り返された結合でSNPAに達成される、(初めは、そして、各Intermediate System、) この結合はメカニズムを発送するネットワークレベルによって達成されます。ただ一つのユビキタスネットワークサービスが(コネクションレスであるか接続指向)で純粋なOSI環境で働くことができるだけであるので、これは、この注意によって扱われることにおける問題に十分ではありません。
2.2 General Approach
2.2 一般的方法
This section describes the use of network addresses, and gives a functional overview of the problem being takceled. The means of connecting to a remote Application Entity is broadly as follows.
このセクションは、ネットワーク・アドレスの使用について説明して、takceledされることにおける問題の機能概要を与えます。 リモートApplication Entityに接続する手段は広く以下の通りです。
1. Look up the Application Entity in the OSI Directory to obtain the
Presentation Address 1.
1. OSIディレクトリでApplication Entityを見上げて、Presentation Address1を入手してください。
2. Extract each Network Address from the Presentation Address, and
determine if it can be used (and how).
2. Presentation Addressから各Network Addressを抽出してください、そして、それを使用できるかどうか(そして、どのように)決定してください。
3. Determine an order of preference for the Network Addresses.
3. Network Addressesのためのよく使われる順を決定してください。
4. Attempt to connect to one or more of the Network Addresses.
4. Network Addressesの1つ以上に接続するのを試みてください。
This note is concerned with the second step, and will probably have implications on the third. There is currently no directory service to provide step 2, and so this (interim) approach must be algorithmic. All addressing information required for the network must be extracted from the network address. This note describes the use of Network Addresses for networks which do not provide the OSI Network Service (CLNS or CONS), and places constraints on the use of X.121 form network addresses when used for an OSI Network Service. The following types of Network Address are discussed in this note:
この注意は、第2ステップに関係があって、3日にたぶん意味を持つでしょう。 現在、ステップ2を提供するためにディレクトリサービスが全くないので、この(当座)のアプローチはアルゴリズムであるに違いありません。 ネットワーク・アドレスからネットワークに必要であるすべてのアドレス指定情報を抜粋しなければなりません。 この注意はOSI Network Serviceに使用されるとX.121の使用の規制がネットワーク・アドレスを形成するNetwork AddressesのOSI Network Service(CLNSかコンズ)を提供しないネットワークの使用、および場所について説明します。 この注意でNetwork Addressの以下のタイプについて議論します:
----------------------------
1. Strictly an Application Entity should have only one
Presentation Address. In practice it may have several, and the
network addresses of each Presentation Address should be considered.
---------------------------- 1. 厳密に、Application Entityには、1Presentation Addressしかあるはずがありません。 数個に開くかもしれなくて、ネットワークが扱うそれぞれのPresentation Addressの習慣では、考えられるべきであってください。
Hardcastle-Kille Page 3
Hardcastle-Kille3ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
o Use of X.121 form Network Addresses.
o X.121フォームNetwork Addressesの使用。
o A special encoding of Telex form Network Addresses.
o TelexフォームNetwork Addressesをコード化する特別番組。
3 Network addresses with X.121 AFI
3 X.121 AFIとのネットワークアドレス
This note defines an approach for use of network addresses with the X.121 AFI. The IDP of network addresses is used to allow worldwide administration of the NSAP address space. As such, not all values of the IDP will in practice have topological significance (which implies that in some cases the IDP will not be sufficient for network layer routing). However, it is recommended that any End System using the Connection Oriented Network Service and with access to the international X.25 service uses the X.121 form of NSAP address relative to its access point. This allows routing across the worldwide X.25 based public data networks to be based on the X.121 addresses. Allocation of DSP (Domain Specific Part) within this form of address is a private issue.
この注意はX.121 AFIとのネットワーク・アドレスの使用のためのアプローチを定義します。 ネットワーク・アドレスのIDPは、NSAPアドレス空間の世界的な管理を許容するのに使用されます。 そういうものとして、すべてではなく、IDPの値には、位相的な意味(十分であることをいくつかの場合、IDPがネットワーク層ルーティングでならない含意する)が実際にはあるでしょう。 しかしながら、Connection Oriented Network Serviceと国際的なX.25サービスへのアクセスによるどんなEnd System使用もアクセスポイントに比例してNSAPアドレスのX.121フォームを使用するのは、お勧めです。 これで、世界的なX.25ベースの公衆データネットワークの向こう側のルーティングはX.121アドレスに基づきます。 この敬称の中のDSP(ドメインSpecific Part)の配分は個人的な問題です。
The IDP is primarily an allocation mechanism, and the user (end system) cannot in principle assume any implied routing. However, due to the lack of a network directory service, it is recommended that any End System with Connection Oriented Network Service and access to the international X.25 service uses X.121 form relative to its access point. Allocation of DSP (Domain Specific Part) is a private issue. Conversely it is recommended that if an X.121 IDP (Initial Domain Part) form Network Address is interpreted, then the X.121 address will provide a route (by defining an SNPA on the international X.25 network). There may be additional and perhaps preferable routes which can be determined by private means. If the DSP is absent, the form should be interpreted as implying a mapping of Transport onto X.25(80).
IDPは主として配分メカニズムです、そして、ユーザ(エンドシステム)は原則として少しの暗示しているルーティングも仮定できません。 しかしながら、ネットワークディレクトリサービスの不足のために、Connection Oriented Network ServiceとどんなEnd Systemと国際的なX.25サービスへのアクセスもアクセスポイントに比例してX.121フォームを使用するのは、お勧めです。 DSP(ドメインSpecific Part)の配分は個人的な問題です。 逆に、X.121 IDP(初期のDomain Part)フォームNetwork Addressが解釈されるとX.121アドレスがルート(国際的なX.25ネットワークでSNPAを定義するのによる)を提供するのは、お勧めです。 個人的な手段で決定できる追加していて恐らく望ましいルートがあるかもしれません。 DSPが欠けるなら、フォームは、Transportに関するマッピングをX.25(80)に含意しながら、解釈されるべきです。
4 New Network Address Format
4 新しいネットワーク・アドレス形式
This section defines a new network address format. The scope of this format is currently:
このセクションは新しいネットワークアドレス形式を定義します。 現在、この形式の範囲は以下の通りです。
1. Any TCP/IP network supporting COTS using RFC 1006.
1. RFC1006を使用することでCOTSをサポートするどんなTCP/IPネットワーク。
Hardcastle-Kille Page 4
Hardcastle-Kille4ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
2. Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is
not used to provide CONS (i.e., only DTE and not Network address
is carried), except where the international X.25 service is used
and no PID or CUDF is required.
These exceptions are the cases which are handled by use of X.121
AFI (Section 3). The intention is to use the X.121 AFI wherever
possible, and the formats defined in this section are for the
remaining cases.
2. X.25へのCOTSに関するどんなマッピング、も(通常X.25(80))、国際的なX.25サービスがどこで使用されているか、そして、PIDがない以外に、X.25がコンズを提供するのにどこで使用されないか、そして、(Networkアドレスではなく、すなわち、DTEだけが運ばれます)CUDFが必要です。 これらの例外はX.121 AFI(セクション3)の使用で扱われるケースです。 意志がどこでも、可能であるところでX.121 AFIを使用することであり、このセクションで定義された書式は残っているケースのためのものです。
The approach could also be extended to use with other means of providing COTS (or CLTS). It is not appropriate for use where CONS or CLNS is used to provide COTS (or CLTS).
また、提供する他の手段でCOTSを使用するために進入路を広げることができました(または、CLTS)。 使用には、それはコンズかCLNSがCOTS(または、CLTS)を提供するのに使用されるところで適切ではありません。
4.1 Requirements
4.1 要件
The requirements for use of OSI over existing networks not supporting CONS or CLNS, when using the OSI Directory are:
OSIディレクトリを使用するときコンズかCLNSをサポートしない既存のネットワークの上のOSIの使用のための要件は以下の通りです。
1. The information for the layers below Transport must be obtained
from the Network Address. This is essential, because we wish to
use the OSI Directory in a standard manner, and the Network
Address is the information available.
1. Network AddressからTransportの下の層のための情報を得なければなりません。 これは不可欠です、標準の方法でOSIディレクトリを使用したいと思って、Network Addressが利用可能な情報であるので。
2. The Network Addresses must be globally unique, as they can be
looked up by anyone with access to the Directory.
2. だれでもディレクトリへのアクセスで彼らを見上げることができるので、Network Addressesはグローバルにユニークでなければなりません。
3. The Network Address should be allocated so that confusion with a
``real'' Network Address (i.e., one which defines an NSAP using
CONS or CLNS as opposed to X.25(80) or RFC 1006) is unlikely.
3. Network Addressを割り当てるべきであるので、「本当」のNetwork Address(すなわち、X.25(80)かRFC1006と対照的にコンズかCLNSを使用することでNSAPを定義するもの)への混乱はありそうもないです。
4. Network Addresses must be interpretable on the basis of a well
known information, or on information which can be obtained from
the (application level) OSI Directory. (This RFConly uses well
known information).
4. ネットワークAddressesはよく知られている情報に基づいた(アプリケーションレベル)OSIディレクトリから得ることができる情報の上で解明できるに違いありません。 (このRFConlyはよく知られている情報を使用します。)
5. The identity of the network in question must be deducible from the
Network Address
5. 問題のネットワークのアイデンティティはNetwork Addressから推定可能であるに違いありません。
6. All network specific addressing information (including the SNPA)
must be deducible from the Network Address
6. すべてが(SNPAを含んでいます)がNetwork Addressから推定可能であるに違いないという特定のアドレス指定情報をネットワークでつなぎます。
Hardcastle-Kille Page 5
Hardcastle-Kille5ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
4.2 IDP Choice
4.2 IDP選択
The IDP is used with Telex AFI. The Telex AFI is used because:
IDPはTelex AFIと共に使用されます。 Telex AFIが使用されている、:
o It gives the largest DSP
o それは最も大きいDSPに与えます。
o It is less likely than other forms to be used for ``real'' Network
Addresses
o それは「本当」のNetwork Addressesに他のフォームほど使用されそうにはありません。
The following AFIs might have been chosen, but are not used for the reasons given:
以下のAFIsは選ばれたかもしれませんが、あげられた理由に使用されません:
o Local (the values must be globally unique)
o ローカル(値はグローバルにユニークでなければなりません)
o X.121 (because it may be confused with other uses of OSI network
addresses)
o X.121(OSIネットワーク・アドレスの他の用途に混乱するかもしれないので)
o DCC and ICD (because it may be confused with other uses of OSI
network addresses)
o DCCとICD(OSIネットワーク・アドレスの他の用途に混乱するかもしれないので)
The IDI should be assigned in a manner appropriate to the use of the encoding. For example, for operation on a private network within an organisation, the telex number of that organisation would be a good choice. Some well known networks are given assignments in Appendix A.
IDIはコード化の使用に適切な方法で割り当てられるべきです。 例えば、機構の中の私設のネットワークにおける操作のために、その機構のテレックス番号は良い選択でしょう。 Appendix Aの課題を与えるよく知られているネットワークもあります。
4.3 The DSP Encoding
4.3 DSPコード化
The network address is used as follows.
ネットワーク・アドレスは以下の通り使用されます。
o A (sub)network is identified by the IDP and a small part of the
DSP.
o (潜水艦)ネットワークはDSPのIDPと小さい部分によって特定されます。
o The remainder of the DSP encodes network specific information
o DSPエンコードの残りは特殊情報をネットワークでつなぎます。
The DSP format is now defined. The top level format is independent of the means used to provde COTS. Two formats for the remainder of the DSP are then defined, for specific means of providing COTS.
DSP書式は現在、定義されます。 最高平らな形式はprovde COTSに使用される手段から独立しています。 そして、DSPの残りのための2つの書式がCOTSを提供する特定の手段のために定義されます。
A decimal abstract encoding is defined for the DSP. The ECMA 117 format might have been used, but it is not suitable. [TC386]. Use of a binary encoding, with the DSP structured in ASN.1 would have been a
10進抽象的なコード化はDSPのために定義されます。 ECMA117形式は使用されたかもしれませんが、それは適当ではありません。 [TC386。] 中のASN.1が持っているaであるDSPが構造化されていたa2進のコード化の使用
Hardcastle-Kille Page 6
Hardcastle-Kille6ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
very attractive approach. However, there is insufficient space in the Network Address for this to be feasible. The following structure is defined:
非常に魅力的なアプローチ。 しかしながら、これが可能であるように、不十分なスペースがNetwork Addressにあります。 以下の構造は定義されます:
____________________________________
|_Digit___||1-2__|______3-27_______|_
|_Meaning_||PrefixN|etwork_Specific_|
____________________________________ |_ケタ___||1-2__|______3-27_______|_ |_意味_||PrefixN|_の特定のetwork_|
2 digits Prefix. This allows for multiple usage of the same DSP, by
not consuming it all. It also allows for the DSP to be used with
different encodings.
2 ケタPrefix。 これは、それを皆、消費しないことによって、同じDSPの複数の使用法を考慮します。 また、それは、DSPが異なったencodingsと共に使用されるのを許容します。
Network Specific The network specific allocation should be less than
20 digits if this DSP structure is to be used with any IDI format.
This is increased to 27 for the Telex format.
Specificをネットワークでつないでください。このDSP構造がどんなIDI形式と共にも使用されることであるなら、ネットワークの特定の配分は20ケタ未満であるべきです。 これはTelex形式のために27まで増強されます。
The IDP + 2 digit prefix identify a subnetwork in which the value of the remainder of the DSP (Network Specific Part) is to be interpreted.
IDP+2ケタ接頭語は解釈されるDSP(ネットワークSpecific Part)の残りの値がことであるサブネットワークを特定します。
4.4 X.25(80) Network Specific Format
4.4 X.25(80)のネットワークの特定の形式
The IDP/Prefix identifies an X.25(80) subnetwork. There is a need to represent a DTE Number, and optionally an X.25 Protocol ID or CUDF (many implementations require these due to shortage of X.121 address space) in the DSP. This is structured in one of two possible ways:
IDP/接頭語はX.25(80)サブネットワークを特定します。 任意にDTE Numberを表す必要があります。DSPのX.25Protocol IDかCUDF(多くの実装がX.121アドレス空間の不足にこれらの支払われるべきものを必要とします)。 これは2つの可能な方法の1つで構造化されます:
________________________
|_Digit___||1R|emainder_|
|_Meaning_||0_|_DTE____|_
________________________ |_ケタ___||1R|emainder_| |_意味_||0_|_DTE____|_
____________________________________________________________
|_Digit___||_1___|_______2________|3_--_(n*3)+2_|Remainder_|_
|_Meaning_||Type__|PID/CUDF_Length_|_PID/CUDF___|___DTE____|_
|_Values__||1_or_2_|_____n________|_____________|__________|_
____________________________________________________________ |_ケタ___||_1___|_______2________|3_--_(n*3)+2_|残り_|_ |_意味_||__をタイプしてください。|PID/CUDF_長さの_|_PID/CUDF___|___DTE____|_ |___を評価します。||1 _か_2_|_____n________|_____________|__________|_
The network specific part is structured as follows:
ネットワークの特定の一部が以下の通り構造化されます:
Type This has the following values
タイプThisには、以下の値があります。
0 DTE only
0 DTE専用
1 DTE + PID
1 DTE+PID
Hardcastle-Kille Page 7
Hardcastle-Kille7ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
2 DTE + CUDF
2 DTE+CUDF
3-9 Reserved
3-9 予約されています。
PID/CUDF Length The length of the PID/CUDF in octets
八重奏における、PID/CUDFの長さのPID/CUDF Length
PID/CUDF The PID/CUDF takes as many digits as indicated by 3 times
octet 2. Each octet of the PID/CUDF is encoded as three decimal
digits, representing the decimal value of the octet.
PID/CUDF PID/CUDFは3回の八重奏2で示されるのと同じくらい多くのケタを取ります。 八重奏のデシマル値を表して、PID/CUDFの各八重奏は3つの10進数字としてコード化されます。
DTE The DTE is terminated by the end of the Network Address.
DTE DTEはNetwork Addressの端までに終えられます。
For example, the JANET DTE 000005111600 with ASCII CUDF ``12'' would be encoded in the following way. The first lines describe the abstract notation. Note that where the IDI is not of maximum length, that the translation to concrete decimal is not mechanical
例えば、ジャネットDTE、000005111600 ASCII CUDFと共に、「12インチは以下の方法でコード化されるでしょう」。 最初の系列は抽象的な記法を説明します。 IDIが最大の長さのものでなく、それが具体的な小数への翻訳であるそれが機械的でないことに注意してください。
_______________________________________________________________________________ |Part___|_|_____IDP_________|_______________________DSP_______________________|_ |Comp___|_|AFI__|___IDI_____|Prefix_|Dte+Cudf_|Len|________CUDF_+_DTE_________|_ |Octet__|_|____|____________|_1-2___|___3_____|_4_|___________5-20____________|_ |Value__|T|elex_|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|__ |Ct_Dec_|_|54___|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|_ |Ct_Bin_|_|54___|00_72_87_22_|_02___|_____22______|04_90_50_00_00_51_11_60_0f_|_
_______________________________________________________________________________ |部分___|_|_____IDP_________|_______________________DSP_______________________|_ |コンピュータ___|_|AFI__|___イディ_____|接頭語_|Dte+Cudf_|レン|________CUDF_+_DTE_________|_ |八重奏__|_|____|____________|_1-2___|___3_____|_4_|___________5-20____________|_ |値の__|T|elex_|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|__ |ct_12月の_|_|54___|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|_ |ct_容器_|_|54___|00_72_87_22_|_02___|_____22______|04 _90_50_00_00_51_11_60_0f_|_
Note that concrete binary is representing octets in hexadecimal. This is the syntax most likely to be used in practice. The CUDF is represented by two octets 049 and 050 (decimal), which map to six digits.
具体的なバイナリーが16進における八重奏を表していることに注意してください。 これは実際には最も使用されそうな構文です。 2つの八重奏049と050(10進)でCUDFは表されます。(八重奏はケタを6に写像します)。
4.5 TCP/IP (RFC 1006) Network Specific Format
4.5 TCP/IP(RFC1006)のネットワークの特定の形式
The IDP and 2 digit prefix identifies a TCP/IP network where RFC 1006 is applied. It is necessary to use an IP Address, as there are insufficient bits to fit in a domain. It is structured as follows:
IDPと2ケタ接頭語はRFC1006が適用されているTCP/IPネットワークを特定します。 ドメインをうまくはめ込むために不十分なビットがあるとき、IP Addressを使用するのが必要です。 それは以下の通り構造化されます:
__________________________________________________________
|_Digit___||_1-12____|13-17_(optional)_|18-22_(optional)_|_
|_Meaning_||IP_Address_|____port_______|__Transport_Set__|_
__________________________________________________________ |_ケタ___||_1-12____|13-17 _(任意)の_|18-22 _(任意)の_|_ |_意味_||IP_アドレス_|____ポート_______|__輸送_は__を設定します。|_
Hardcastle-Kille Page 8
Hardcastle-Kille8ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
For TCP/IP there shall be a 20 digit long network-specific part. First 12 digits are for the IP address. The port number can be up to 65535, and needs 5 digits (this is optional, and is defaulted as defined in RFC 1006). Finally, there is a third part to the address, which is defined here as ``transport set'' that indicates what kind of IP-based transport protocols is used. This is a decimal number from 0-65535 which is really a 16-bit flag word. 1 is TCP, 2 is UDP. Further values of this code are assigned by the IANA. If the transport set is not there or no bits are set, it means ``default'' which is TCP. This is encoded in 5 digits. For example, the IP Address 10.0.0.6 with port 9 over UDP is encoded as:
TCP/IPのために、20のケタの長いネットワーク特有の部分があるでしょう。 最初の12ケタはIPアドレスのためのものです。 ポートナンバーは、最大65535であることができ、5ケタを必要とします(これとして、RFC1006で定義されていた状態で任意であり、デフォルトとします)。 最終的に、アドレスへの3番目の部分があります。(アドレスはここでどういうIPベースのトランスポート・プロトコルが使用されているかを示す「輸送セット」と定義されます)。 これは本当に16ビットの旗の単語である0-65535からの10進数です。 1がTCPである、2はUDPです。 このコードのさらなる値はIANAによって割り当てられます。 輸送セットがそこにないか、またはビットが全く設定されないなら、それはTCPである「デフォルト」を意味します。 これは5ケタでコード化されます。 例えば、UDPの上にポート9があるIP Address10.0.0.6は以下としてコード化されます。
____________________________________________________________________________ |Part______|_|_____IDP_________|____________________DSP____________________|_ |Component_|_|AFI__|___IDI_____|Prefix_|___IP_Address_____|_Port__|_T_Set__|_ |Octet_____|_|____|____________|_1-2___|______3-14________|_15-19_|_20-24__|_ |Value_____|T|elex_|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|__ |Cncrt_Dec_|_|54___|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|_ |Cncrt_Bin_|_|54___|00_72_87_22_|_03___|01_00_00_00_00_06_|00_00_9|0_00_02_|_
____________________________________________________________________________ |部分______|_|_____IDP_________|____________________DSP____________________|_ |コンポーネント_|_|AFI__|___イディ_____|接頭語_|___IP_アドレス_____|_ポート__|_T_は__を設定します。|_ |八重奏_____|_|____|____________|_1-2___|______3-14________|_15-19_|_20-24__|_ |値_____|T|elex_|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|__ |Cncrt_12月の_|_|54___|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|_ |Cncrt_容器_|_|54___|00_72_87_22_|_03___|01_00_00_00_00_06_|00_00_9|0_00_02_|_
5 Encoding
5 コード化
This document describes allocation of Network Addresses, with the DSP considered in Abstract Decimal. The encoding of this for use in protocols (typically as Concrete Binary) is described in ISO 8348 Addendum 2 [ISO87a].
このドキュメントはDSPが抽象的なDecimalで考えられているNetwork Addressesの配分について説明します。 プロトコル(通常Concrete Binaryとしての)における使用のためのこのコード化はISO8348Addendum2[ISO87a]で説明されます。
6 References
6つの参照箇所
References
参照
[CCI80] CCITT. Recommendation X.25, interface between DTE and DCE
for packet mode terminals, 1980.
[CCI80]CCITT。 推薦X.25、パケット端末、1980年のためにDTEとDCEの間で連結してください。
[CCI88] The Directory --- overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[CCI88] ディレクトリ--- 1988年12月の概念の、そして、モデルの、そして、サービスの概要。 CCITT X.500シリーズ勧告。
[CGC91] R. Colella, E. Gardner, and R. Callon. Guidelines for OSI
NSAP Allocation in the Internet. Request for Comments 1237,
[CGC91] R.Colella、E.ガードナー、およびR.Callon。 インターネットのオウシNSAP Allocationのためのガイドライン。 コメント1237を求める要求
Hardcastle-Kille Page 9
Hardcastle-Kille9ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
NIST, July 1991.
1991年7月のNIST。
[ISO87a] Information processing systems - data communications -
network services definition: Addendum 2 - network layer
addressing, March 1987. ISO TC 97/SC 6.
[ISO87a]情報処理システム(データ通信)はサービス定義をネットワークでつなぎます: 付加物2--1987年3月のネットワーク層アドレシング。 ISO Tc97/サウスカロライナ6。
[ISO87b] ISO DIS 7498-3 on naming and addressing, May 1987.
ISO/IEC/JTC-1/SC 21.
1987年5月の命名とアドレシングの[ISO87b]ISO DIS7498-3。 ISO/IEC/JTC-1/Sc21。
[Kil88] S.E. Kille. The QUIPU directory service. In IFIP WG 6.5
Conference on Message Handling Systems and Distributed
Applications, pages 173--186. North Holland Publishing,
October 1988.
[Kil88]東南Kille。 QUIPUディレクトリサービス。 Message Handling SystemsとDistributed Applicationsの上のIFIP WG6.5コンファレンス、173--186ページで。 1988年10月に発行される北のオランダ。
[Kil89] S.E. Kille. An interim approach to use of network addresses.
Research Note RN/89/13, Department of Computer Science,
University College London, February 1989.
[Kil89]東南Kille。 ネットワーク・アドレスの使用への当座のアプローチ。 1989年2月に注意Rn/89/13、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドンについて研究してください。
[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Services
on top of the TCP. Request for Comments 1006, Northrop
Corporation Technology Center, May 1987.
[RC87]マーシャル・T.ローズとドワイト・E.キャス。 TCPの上のISO Transport Services。 コメントのために1006(ノースロップ社の技術センター)は1987がそうするかもしれないよう要求してください。
[Ros90] M.T. Rose. The ISO development environment: User's manual
(version 6.0), January 1990.
[Ros90]M.T.は上昇しました。 ISO開発環境: 1990年1月のユーザマニュアル(バージョン6.0)。
[SA88] F. Sirovich and M. Antonellini. The THORN X.500 distributed
directory environment. In Esprit Conference Week, November
1988.
[SA88] F.SirovichとM.Antonellini。 THORN X.500はディレクトリ環境を分配しました。 エスプリコンファレンス週、1988年11月に。
[TC386] ECMA TC32. Domain specific part of network layer addresses.
ECMA Standard 117, ECMA, June 1986.
[TC386]ECMA TC32。 ネットワーク層アドレスのドメインの特定の部分。 ECMA規格117、ECMA、1986年6月。
7 Security Considerations
7 セキュリティ問題
Security considerations are not discussed in this memo.
このメモでセキュリティ問題について議論しません。
8 Author's Address
8作者のアドレス
Steve Hardcastle-Kille
Department of Computer Science
University College London
スティーブ・Hardcastle-Killeコンピュータサイエンス学部ユニバーシティ・カレッジロンドン
Hardcastle-Kille Page 10
Hardcastle-Kille10ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
Gower Street
WC1E 6BT
England
WC1E 6BTイギリスガウアー・ストリート
Phone: +44-71-380-7294
以下に電話をしてください。 +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
メール: S.Kille@CS.UCL.AC.UK
Hardcastle-Kille Page 11
Hardcastle-Kille11ページ
RFC 1277 Encoding Network Addresses November 1991
1991年11月にネットワーク・アドレスをコード化するRFC1277
A Allocations for well known networks
よく知られているネットワークのためのAllocations
A.1 Values
A.1値
This appendix gives an allocation for three well known networks. All
are allocated on the basis of the supposed Telex number 00728722.
This number is being used in pilot operations, and so is retained
here.
_______________________________________
|_________Net__________Telex____Prefix_|
| International X.25 |007 28722 01 |
| Janet |007 28722 02 |
| Darpa/NSF Internet |007 28722 03 |
|_IXI________________|007_28722_06_____|
この付録は3つのよく知られているネットワークのために配分を与えます。 想定されたTelex No.00728722に基づいてすべてを割り当てます。 この数は、パイロットオペレーションで使用されているので、ここで保有されます。 _______________________________________ |_________ネット__________テレックス____接頭語_| | 国際X.25|007 28722 01 | | ジャネット|007 28722 02 | | Darpa/NSFインターネット|007 28722 03 | |_IXI________________|007_28722_06_____|
The international X.25 allocation is only used where a CUDF or PID is needed. In other cases, an X.121 form Network Address with no DSP should be used.
国際的なX.25配分はCUDFかPIDが必要であるところで使用されるだけです。 他の場合では、DSPのないX.121フォームNetwork Addressは使用されるべきです。
A.2 Delegation
A.2委譲
The values assigned in this document are now in widespread use. As the number is arbitrary, it would be undesirable to change the numbers without a sound technical reason. However, it is important to guarantee that the numbers are stable.
本書では割り当てられた値は現在、普及使用中です。 数が任意であるように、論理的に正しい技術的な理由なしで数を変えるのは望ましくないでしょう。 しかしながら、数が安定しているのを保証するのは重要です。
This Internet Draft commits UCL not to reassign the portions of the number space allocated here. The DARPA/NSF Internet space (Prefix 03) is delegated to the IANA.
このインターネットDraftは、ここに割り当てられた数のスペースの部分を再選任しないようにUCLを遂行します。 DARPA/NSFインターネット空間(接頭語03)をIANAへ代表として派遣します。
Hardcastle-Kille Page 12
Hardcastle-Kille12ページ
一覧
スポンサーリンク
