RFC1735 日本語訳
1735 NBMA Address Resolution Protocol (NARP). J. Heinanen, R.Govindan. December 1994. (Format: TXT=24485 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Heinanen
Request for Comments: 1735 Telecom Finland
Category: Experimental R. Govindan
ISI
December 1994
Heinanenがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1735年のテレコムフィンランドカテゴリ: 実験的なR.Govindan ISI1994年12月
NBMA Address Resolution Protocol (NARP)
NBMAアドレス解決プロトコル(NARP)
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
IESG Note:
IESGは以下に注意します。
Note that the work contained in this memo does not describe an Internet standard. This work represents an early stage in the ongoing efforts to resolve direct communication over NBMA subnets. It is a suitable experimental protocol for early deployment. It is expect that it will be superceded by other work being developed within the IETF.
このメモに含まれた仕事がインターネット標準について説明しないことに注意してください。 この仕事は、NBMAサブネットの上でダイレクトコミュニケーションを決議するために進行中の取り組みで初期段階を表します。 それは早めの展開のための適当な実験プロトコルです。 それはそれがIETFの中で開発される他の仕事でスーパー割譲されると予想することです。
Abstract
要約
This document describes the NBMA Address Resolution Protocol (NARP). NARP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. Although this document focuses on NARP in the context of IP, the technique is applicable to other network layer protocols as well. This RFC is a product of the Routing over Large Clouds Working Group of the IETF.
このドキュメントはNBMA Address Resolutionプロトコル(NARP)について説明します。 Non-放送(あて先端末が同じNBMAネットワークにつなげられれば(NBMA)がaあて先端末のNBMAアドレスを見つけるためにネットワークでつなぐMulti-アクセスリンクレイヤ)につなげられたソース端末(ホストかルータ)でNARPを使用できます。 このドキュメントはIPの文脈でNARPに焦点を合わせますが、テクニックはまた、他のネットワーク層プロトコルに適切です。 このRFCはIETFのLarge Clouds作業部会の上のルート設定の成果です。
1. Introduction
1. 序論
The NBMA Address Resolution Protocol (NARP) allows a source terminal (a host or router), wishing to communicate over a Non-Broadcast, Multi-Access link layer (NBMA) network, to find out the NBMA addresses of a destination terminal if the destination terminal is connected to the same NBMA network as the source.
NBMA Address Resolutionプロトコル(NARP)はソース端末(ホストかルータ)を許容します、あて先端末がソースと同じNBMAネットワークにつなげられるならNon-放送、Multi-アクセスの上の(NBMA)がネットワークでつなぐリンクレイヤを伝えて、あて先端末のNBMAアドレスを見つけることを願っていて。
Heinanen & Govindan [Page 1] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[1ページ]RFC1735NBMAアルプ(NARP)1994年12月
A conventional address resolution protocol, such as ARP [1, 2] for IP, may not be sufficient to resolve the NBMA address of the destination terminal, since it only applies to terminals belonging to the same IP subnetwork, whereas an NBMA network can consist of multiple logically independent IP subnets (LISs, [3]).
IPのためのARP[1、2]などの従来のアドレス解決プロトコルはあて先端末のNBMAアドレスを決議するために十分でないかもしれません、NBMAネットワークが同じIPサブネットワークに属す端末複数の論理的に独立しているIPサブネットから成ることができますが、それが適用されるだけであるので。(LISs([3]))。
Once the NBMA address of the destination terminal is resolved, the source may either start sending IP packets to the destination (in a connectionless NBMA network such as SMDS) or may first establish a connection to the destination with the desired bandwidth and QOS characteristics (in a connection oriented NBMA network such as ATM).
一度、あて先端末のNBMAアドレスが決議されているか、ソースが、目的地(SMDSなどのコネクションレスなNBMAネットワークにおける)にIPパケットを送り始めるかもしれませんか、または1番目が必要な帯域幅とQOSの特性(指向のNBMAがATMなどのようにネットワークでつなぐ接続における)で目的地に取引関係を築きますように。
An NBMA network can be non-broadcast either because it technically doesn't support broadcasting (e.g., an X.25 network) or because broadcasting is not feasible for one reason or another (e.g., an SMDS broadcast group or an extended Ethernet would be too large).
放送が(例えば、X.25ネットワーク)であると技術的にサポートしないか、または何らかの理由には、放送が可能でないので、NBMAネットワークは非放送できます(例えば、SMDS放送グループか拡張イーサネットが大き過ぎるでしょう)。
2. Protocol Overview
2. プロトコル概要
In this section, we briefly describe how a source S uses NARP to determine the NBMA address of a destination D or to find out that such an address doesn't exist. S first checks if the destination terminal belongs to the same IP subnetwork as S itself. If so, S resolves the NBMA address of D using conventional means, such as ARP [1, 2] or preconfigured tables. If D resides in another subnetwork, S formulates a NARP request containing the source and destination IP addresses. S then forwards the request to an entity called the "NBMA ARP Server" (NAS).
このセクションで、私たちは簡潔にソースSが目的地DのNBMAアドレスを決定するか、またはそのようなアドレスが存在しないのを見つけるのにどうNARPを使用するかを説明します。 Sは、最初に、あて先端末がS自体と同じIPサブネットワークに属すかどうかチェックします。 そうだとすれば、Sは、ARP[1、2]かあらかじめ設定されたテーブルなどの従来の手段を使用することでDのNBMAアドレスを決議します。 Dが別のサブネットワークに住んでいるなら、Sはソースを含むNARP要求と送付先IPアドレスを定式化します。 そして、Sは「NBMA ARPサーバ」(NAS)と呼ばれる実体に要求を転送します。
For administrative and policy reasons, a physical NBMA network may be partitioned into several disjoint logical NBMA networks. NASs cooperatively resolve the NBMA next hop within their logical NBMA network. In the following we'll always use the term "NBMA network" to mean a logical NBMA network. If S is connected to several NBMA networks, it should have at least one NAS in each of them. In order to know which NAS(s) to query for which destination addresses, a multi-homed S should also be configured to receive reachability information from its NASs.
管理と方針理由、ネットワークが仕切られるかもしれない物理的なNBMAに関しては、数個が論理的なNBMAネットワークをばらばらにならせます。 NASsは、次のNBMAが彼らの論理的なNBMAネットワークの中を飛び越すと協力して決議します。 以下では、私たちは、論理的なNBMAネットワークを意味するのにいつも「NBMAネットワーク」という用語を使用するつもりです。 SがいくつかのNBMAネットワークに関連づけられるなら、それはそれぞれの彼らに少なくとも1NASを持つべきです。 どの目的地にアドレス、aについて質問するかためにどのNAS(s)を知っているか、マルチ、家へ帰り、また、Sは、NASsから可到達性情報を受け取るために構成されるべきです。
Each NAS "serves" a pre-configured set of terminals and peers with a pre-configured set of NASs, which all belong to the same NBMA network. A NAS may also peer with routers outside the served NBMA. A NAS exchanges reachability information with its peers (and possibly with the terminals it serves) using regular routing protocols. This exchange is used to construct a forwarding table in every NAS. The forwarding table determines the next hop NAS towards the NARP request's destination or a next hop router outside the NBMA.
各NASはNASsのすべて、あらかじめ設定されたセットであらかじめ設定されたセットの端末と同輩に「役立ちます」。(NASsは同じNBMAネットワークのものです)。 また、役立たれたNBMAの外にルータがある状態で、NASはじっと見るかもしれません。 NASは、通常のルーティング・プロトコルを使用することで同輩(ことによると端末で、それは役立ちます)と可到達性情報を交換します。 この交換は、あらゆるNASで推進テーブルを組み立てるのに使用されます。 推進テーブルはNBMAの外でNARP要求の目的地か次のホップルータに向かって次のホップNASを決定します。
Heinanen & Govindan [Page 2] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[2ページ]RFC1735NBMAアルプ(NARP)1994年12月
After receiving a NARP request, the NAS checks if it "serves" D. If so, the NAS resolves D's NBMA address, using mechanisms beyond the scope of this document (examples of such mechanisms include ARP [1, 2] and pre-configured tables). The NAS then either forwards the NARP request to D or generates a positive NARP reply on its behalf. The reply contains D's IP and NBMA address and is sent back to S. NARP replies usually traverse the same sequence of NASs as the NARP request (in reverse order, of course).
NARP要求を受け取った後に、NASは、それがしたがって、NAS決心DのNBMAが扱うD.Ifに「役立つかどうか」チェックします、このドキュメントの範囲を超えてメカニズムを使用して(そのようなメカニズムに関する例はARP[1、2]とあらかじめ設定されたテーブルを含んでいます)。 NASはそして、NARP要求をDに転送するか、またはそのに代わって積極的なNARP回答を生成します。 NARPが要求するように(もちろん逆順で)、回答は、DのIPとNBMAアドレスを含んでいて、通常、NASsの同じ系列を横断するためにS. NARPが、返答する返送されます。
If the NAS does not serve D, it extracts from its forwarding table the next hop towards D. If the next hop is a peer NAS, it forwards the NARP request to the next hop. If the next hop is a peer router outside the served NBMA or if no such next hop entry is found, the NAS generates a negative NARP reply.
NASがそうしないなら、Dに役立ってください、それ。D.Ifに向かった次のホップをテーブルに送るのからの次が飛び越す抽出が同輩NASである、それはNARP要求を次のホップに転送します。 次のホップが役立たれたNBMAの外の同輩ルータであるか次のそのようなホップエントリーが全く見つけられないなら、NASは否定的NARP回答を生成します。
A NAS receiving a NARP reply may cache the NBMA address information contained therein. If a subsequent NARP request for the same target address does not desire an authorative reply, a caching NAS can then respond with the cached non-authoritative NBMA address or with cached negative information. A well behaving terminal should always first accept a non-authoritative reply. Only if communication attempt based on the non-authoritative information fails, the terminal can choose to issue another request this time asking for an authoritative reply.
NARP回答を受け取るNASはそこに含まれたNBMAアドレス情報をキャッシュするかもしれません。 同じあて先アドレスを求めるその後のNARP要求がauthorative回答を望んでいないなら、キャッシュNASはキャッシュされた非正式のNBMAアドレスかキャッシュされた否定的情報で応じることができます。 井戸振る舞い端末は最初に、いつも非正式の回答を受け入れるはずです。 非信頼できる情報に基づくコミュニケーション試みが失敗する場合にだけ、端末は、今回正式の回答を求めながら別の要求を出すのを選ぶことができます。
NARP requests and replies never cross the borders of an NBMA network. Thus, IP traffic out off and into an NBMA network always traverses an IP router at its border. Network layer filtering can then be implemented at these border routers.
NARP要求と回答はNBMAネットワークの境界を決して越えません。 したがって、ネットワークとNBMAネットワークの中へのIPトラフィックは境界でいつもIPルータを横断します。 そして、これらの境界ルータでネットワーク層フィルタリングを実装することができます。
3. Configuration
3. 構成
Terminals
端末
To participate in NARP, a terminal connected to an NBMA network
should to be configured with the IP address(es) of its NAS(s). If
the terminal is attached to several NBMA networks, it should also
be configured to receive reachability information from its NAS(s)
so that it can determine, which IP destinations are reachable
through which NBMA networks.
NARPに参加するために、NBMAネットワークにつなげられた端末は扱うべきです。IPによって構成されるのはNAS(s)の(es)を扱います。 また、端末がいくつかのNBMAネットワークに取り付けられるなら、NAS(s)から可到達性情報を受け取るのも、どのIPの目的地がどのNBMAネットワークを通して届いているかを決定できるように構成されているべきです。
NBMA ARP Servers
NBMA ARPサーバ
A NAS is configured with a set of IP address prefixes that
correspond to the IP addresses of the terminals it is serving.
Moreover, the NAS must be configured to exchange reachability
information with its peer NASs (if any). In addition, the NAS may
be configured to exchange reachability information with routers
NASはそれが役立っている端末のIPアドレスに対応する1セットのIPアドレス接頭語によって構成されます。 そのうえ、同輩NASs(もしあれば)と可到達性情報を交換するためにNASを構成しなければなりません。 さらに、NASは、可到達性情報をルータと交換するために構成されるかもしれません。
Heinanen & Govindan [Page 3] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[3ページ]RFC1735NBMAアルプ(NARP)1994年12月
outside the served NBMA. And finally, if a served terminal is
attached to several NBMA networks, the NAS may need to be
configured to send reachability information to such a terminal.
役立たれたNBMAの外で。 そして、最終的に、役立たれた端末がいくつかのNBMAネットワークに取り付けられるなら、NASは、可到達性情報をそのような端末に送るために構成される必要があるかもしれません。
4. Packet Formats
4. パケット・フォーマット
NARP requests and replies are carried in IP packets as protocol type 54. This section describes the packet formats of NARP requests and replies:
NARP要求と回答はプロトコルタイプ54としてIPパケットで運ばれます。 このセクションはNARP要求と回答のパケット・フォーマットについて説明します:
NARP Request
NARP要求
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| ホップカウント| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NBMAの長さ| NBMAアドレス| +-+-+-+-+-+-+-+-+ | | (可変長) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
The NARP version number. Currently this value is 1.
NARPバージョンが付番するバージョン。 現在の、この値は1です。
Hop Count
The Hop count indicates the maximum number of NASs that a request
or reply is allowed to traverse before being discarded.
Hopが数えるホップCountは捨てられる前に要求か回答が横断できるNASsの最大数を示します。
Checksum
The standard IP checksum over the entire NARP packet (starting with
the fixed header).
チェックサム、全体のNARPパケット(固定ヘッダーから始める)の上の標準のIPチェックサム。
Type
The NARP packet type. The NARP Request has a Type code 1.
NARPパケットタイプをタイプしてください。 NARP Requestには、Typeコード1があります。
Code
A response to an NARP request may contain cached information. If an
authoritative answer is desired, then code 2 (NARP Request for
Authoritative Information) should be used. Otherwise, a code value
of 1 (NARP Request) should be used.
NARP要求への応答が含むかもしれないコードAは情報をキャッシュしました。 正式の答えが望まれているなら、コード2(Authoritative情報のためのNARP Request)は使用されるべきです。 さもなければ、1(NARP Request)のコード値は使用されるべきです。
Heinanen & Govindan [Page 4] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[4ページ]RFC1735NBMAアルプ(NARP)1994年12月
Source and Destination IP Addresses
Respectively, these are the IP addresses of the NARP requestor and
the target terminal for which the NBMA address is desired.
ソースとDestination IP Addresses Respectively、これらはNBMAアドレスが望まれているNARP要請者と目標端末のIPアドレスです。
NBMA Length and NBMA Address
The NBMA length field is the length of the NBMA address of the
source terminal in bits. The NBMA address itself is zero-filled to
the nearest 32-bit boundary.
NBMAの長さがさばくNBMA LengthとNBMA Addressはビットのソース端末のNBMAアドレスの長さです。 NBMAアドレス自体は最も近い32ビットの境界に無いっぱいにされます。
NARP Reply
NARP回答
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| ホップカウント| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NBMAの長さ| NBMAアドレス| +-+-+-+-+-+-+-+-+ | | (可変長) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
The NARP version number. Currently this value is 1.
NARPバージョンが付番するバージョン。 現在の、この値は1です。
Hop Count
The Hop count indicates the maximum number of NASs that a request
or reply is allowed to traverse before being discarded.
Hopが数えるホップCountは捨てられる前に要求か回答が横断できるNASsの最大数を示します。
Checksum
The standard IP checksum over the entire NARP packet (starting with
the fixed header).
チェックサム、全体のNARPパケット(固定ヘッダーから始める)の上の標準のIPチェックサム。
Type
The NARP packet type. The NARP Reply has a Type code 2.
NARPパケットタイプをタイプしてください。 NARP Replyには、Typeコード2があります。
Code
NARP replies may be positive or negative. A Positive, Non-
authoritative Reply carries a code of 1, while a Positive,
Authoritative Reply carries a code of 2. A Negative, Non-
authoritative Reply carries a code of 3 and a Negative,
Authoritative reply carries a code of 4.
コードNARP回答は、肯定しているか、または否定しているかもしれません。 Positiveであり、Nonの正式のReplyはPositiveである間、1のコードを運んで、Authoritative Replyは2のコードを運びます。 Negativeであり、Nonの正式のReplyは3のコードとNegativeを運んで、Authoritative回答は4のコードを運びます。
Heinanen & Govindan [Page 5] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[5ページ]RFC1735NBMAアルプ(NARP)1994年12月
The general rule is that a NAS should not reply to an NARP request
for authoritative information with cached information, but may do
so for an NARP request. A NAS implementation is allowed to relax
this rule and return non-authoritative information even in case
authorative was desired if the NAS becomes heavily loaded and the
cached information is very recently updated.
一般的な規則はNASが信頼できる情報のためにキャッシュされた情報でNARP要求に答えるべきではありませんが、NARP要求のためにそうするかもしれないということです。 NASが大いにロードされるようになるならauthorativeが望まれさえするといけなかったので、NAS実装は、この規則を弛緩して、非信頼できる情報を返すことができます、そして、非常に最近、キャッシュされた情報をアップデートします。
Source and Destination IP Address
Respectively, these are the IP addresses of the NARP requestor and
the target terminal for which the NBMA address is desired.
ソースとDestination IP Address Respectively、これらはNBMAアドレスが望まれているNARP要請者と目標端末のIPアドレスです。
NBMA Length and NBMA Address
The NBMA length field is the length of the NBMA address of the
destination terminal in bits. The NBMA address itself is zero-
filled to the nearest 32-bit boundary. Negative replies do not
carry the NBMA length or the NBMA address field.
NBMAの長さがさばくNBMA LengthとNBMA Addressはビットのあて先端末のNBMAアドレスの長さです。 NBMAアドレス自体は最も近い32ビットの境界に無いっぱいにされます。 否定的な返事はNBMAの長さかNBMAアドレス・フィールドを運びません。
A NAS may cache NBMA replies.
NASはNBMA回答をキャッシュするかもしれません。
5. Protocol Operation
5. プロトコル操作
The external behavior of a NAS may be described in terms of two procedures (processRequest and processReply) operating on two tables (forwardingTable and cacheTable). In an actual implementation, the code and data structures may be realized differently.
2個のテーブル(forwardingTableとcacheTable)で作動する2つの手順(processRequestとprocessReply)でNASの外部の動きは説明されるかもしれません。 実際の実装では、コードとデータ構造は異なって実現されるかもしれません。
Each NAS has a forwardingTable consisting of entries with the fields:
各NASはforwardingTableを分野でエントリーから成らせます:
<networkLayerAddrPrefix, type, outIf, outIfAddr>
<networkLayerAddrPrefix、タイプ、outIf、outIfAddr>。
The networkLayerAddrPrefix field identifies a set of IP addresses known to the NAS. It consists of two subfields <ipAddr, mask>.
networkLayerAddrPrefix分野はNASにおいて知られている1セットのIPアドレスを特定します。 それは2部分体<ipAddr、マスク>から成ります。
The type field indicates the type of the networkLayerAddrPrefix. The possible values are:
タイプ分野はnetworkLayerAddrPrefixのタイプを示します。 可能な値は以下の通りです。
- locallyServed: The NAS is itself serving the
networkLayerAddrPrefix. The outIf field denotes the NBMA interface
via which the served terminals can be reached and the outIfAddr
field has no meaning. Such a forwardingTable entry has been
created by manual configuration.
- locallyServedしました: NASはnetworkLayerAddrPrefixに役立っています。 outIf分野はを通した役立たれた端末に達することができて、outIfAddr分野には意味でないのがあるNBMAインタフェースを指示します。 そのようなforwardingTableエントリーは手動の構成によって作成されました。
- nasLearned: The NAS has learned about the networkLayerAddrPrefix
from another NAS. The outIf and outIfAddr fields, respectively,
denote the NBMA interface and IP address of this next hop NAS.
Such a forwardingTable entry is a result of network layer address
prefix information exchange with one of the NAS' peer NASs.
- nasLearnedしました: NASはnetworkLayerAddrPrefixに関して別のNASから学びました。 outIfとoutIfAddr分野はそれぞれこの次のホップNASのNBMAインタフェースとIPアドレスを指示します。 そのようなforwardingTableエントリーはNASの同輩NASsの1つとのネットワーク層アドレス接頭語情報交換の結果です。
Heinanen & Govindan [Page 6] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[6ページ]RFC1735NBMAアルプ(NARP)1994年12月
- externallyLearned: The NAS has learned about the
networkLayerAddrPrefix from a peer router outside the served NBMA.
The outIf and outIfAddr fields, respectively, denote the NBMA
interface and IP address of this next hop NAS. Such a
forwardingTable entry is a result of network layer address prefix
information exchange with one of the NAS' peer routers.
- externallyLearnedしました: NASはnetworkLayerAddrPrefixに関して役立たれたNBMAの外の同輩ルータから学びました。 outIfとoutIfAddr分野はそれぞれこの次のホップNASのNBMAインタフェースとIPアドレスを指示します。 そのようなforwardingTableエントリーはNASの同輩ルータの1つがあるネットワーク層アドレス接頭語情報交換の結果です。
The protocol used to exchange networkLayerAddrPrefix information among the NASs can be any regular IP intra-domain or inter-domain routing protocol.
NASsの中でnetworkLayerAddrPrefix情報を交換するのに使用されるプロトコルはどんな通常のIPイントラドメインか相互ドメインルーティング・プロトコルであるかもしれません。
In addition to the forwardingTable, each NAS has an NARP cacheTable consisting of entries with the fields:
forwardingTableに加えて、各NASはNARP cacheTableを分野でエントリーから成らせます:
<networkLayerAddr, nbmaAddr, timeStamp>
<networkLayerAddr、nbmaAddr、タイムスタンプ>。
The entries in the cacheTable are learned from NARP replies traversing the NAS. In case of a negative cache entry the nbmaAddr is empty. The timeStamp field records the time when the cacheTable entry has been created or updated. It is used to determine if an entry is a very recent one and to age old entries after a certain hold period.
cacheTableのエントリーはNASを横断するNARP回答から学習されます。 否定的キャッシュエントリーの場合には、nbmaAddrは空です。 timeStamp分野はcacheTableエントリーを作成されるか、またはアップデートしてある時を記録します。 それは、エントリーが非常に最近のものであるかどうか決定して、ある保持の期間の後に古いエントリーを年をとるのに使用されます。
The following pseudocode defines how NBMA NARP requests and replies are processed by an NAS.
以下の擬似コードはNBMA NARP要求と回答がNASによってどう処理されるかを定義します。
procedure processRequest(request);
let bestMatch == matchForwardingTable(request.dIPa) do
if bestMatch then
if bestMatch.type == locallyServed then
let nbmaAddr == arp(request.dIPa) do
if nbmaAddr then
genPosAuthReply(request.sIPa, request.dIPa, nbmaAddr)
else
genNegAuthReply(request.sIPa, request.dIPa)
end
end
elseif bestMatch.type == nasLearned then
if not requestForAuthInfo?(request) or
realBusyRightNow?() then
let cacheMatch == matchCacheTable(request.dIPa) do
if cacheMatch and
(not requestForAuthInfo?(request) or
realRecentCacheEntry?(cacheMatch)) then
if cacheMatch.nbmaAddr == EMPTY then
genNegNonAuthReply(request.sIPa, request.dIPa)
else
genPosNonAuthReply(request.sIPa, request.dIPa,
手順processRequest(要求します)。 次に、nbmaAddrの当時のgenPosAuthReply(request.sIPa、request.dIPa、nbmaAddr)のほかのgenNegAuthReply(request.sIPa、request.dIPa)が終わりのelseif bestMatchを終わらせるならbestMatch.type=locallyServedがnbmaAddr=arp(request.dIPa)をするなら、次にmatchForwardingTable(request.dIPa)がbestMatchであるならするbestMatch=をさせてください; requestForAuthInfoでないならその時、=nasLearnedをタイプしてください--次に、(要求)かそれともrealBusyRightNow?()がcacheMatchと(requestForAuthInfoでない--(要求)かそれともrealRecentCacheEntry?(cacheMatch))その時ならEMPTYの当時のgenNegNonAuthReply(request.sIPa、request.dIPa)のほかのcacheMatch.nbmaAddr=genPosNonAuthReplyであるならmatchCacheTable(request.dIPa)がするcacheMatch=をさせた、(request.sIPa、request.dIPa
Heinanen & Govindan [Page 7] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[7ページ]RFC1735NBMAアルプ(NARP)1994年12月
cacheMatch.nbmaAddr)
end
else /* no cache match */
forwardRequest(request, bestMatch.OutIf,
bestMatch.OutIfAddr)
end
end
else /* request for authoritative information */
forwardRequest(request, bestMatch.OutIf,
bestMatch.OutIfAddr)
end
else /* bestMatch.type == externallyLearned */
genNegAuthReply(request.sIPa, request.dIPa)
end
else /* no match in forwardingTable */
genNegAuthReply(request.sIPa, request.dIPa)
end
end
end
cacheMatch.nbmaAddr) 終わりのキャッシュのマッチのほかの/*ノー*/forwardRequest(要求、bestMatch.OutIf、bestMatch.OutIfAddr)はほかの/*が、信頼できる情報のために= externallyLearned*/genNegAuthReply(request.sIPa、request.dIPa)がほかの/*ノーを終わらせる*/forwardRequest(要求、bestMatch.OutIf、bestMatch.OutIfAddr)エンドのほかの/*bestMatch.typeがforwardingTable*/genNegAuthReply(request.sIPa、request.dIPa)終わりの終わりのエンドで合っているよう要求する終わりを終わらせます。
procedure processReply(reply);
addCacheTableEntry(reply.dIPa, reply.nbmaAddr, currentTime);
if reply.sIPa == selfIpAddr then
/* reply is to the NAS itself */
else
let bestMatch == matchForwardingTable(reply.sIPa) do
if bestMatch then
forwardReply(reply, bestMatch.outIf, bestMatch.outIfAddr)
end
end
end
end
手順processReply(回答)。 addCacheTableEntry(reply.dIPa、reply.nbmaAddr、currentTime)。 それ自体で*/ほかのNASにreply.sIPa=selfIpAddr当時の/*回答があるなら、bestMatchの当時のforwardReply(回答、bestMatch.outIf、bestMatch.outIfAddr)が終わりの終わりのエンドを終わらせるなら、matchForwardingTable(reply.sIPa)がするbestMatch=をさせてください。
The semantics of the procedures used in the pseudocode are explained below.
擬似コードで用いられた手順の意味論は以下で説明されます。
matchForwardingTable(ipAddress) returns the forwardingTable entry whose networkLayerAddrPrefix field is the longest match for ipAddress or FALSE if no match is found.
マッチが全く見つけられないなら、matchForwardingTable(ipAddress)はipAddressかFALSEのために、networkLayerAddrPrefix分野が最も長いマッチであるforwardingTableエントリーを返します。
arp(ipAddress) resolves the NBMA address corresponding to ipAddress. It returns FALSE if the resolution fails.
arp(ipAddress)はipAddressに対応するNBMAアドレスを決議します。 解決が失敗するなら、それはFALSEを返します。
genPosAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr) and genPosNonAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr) generate a positive, authoritative and non-authoritative reply with sourceIpAddr, destIpAddr, and destNbmaAddr in Source IP address, Destination IP address, and NBMA Address fields, respectively.
genPosAuthReply(sourceIpAddr、destIpAddr、destNbmaAddr)とgenPosNonAuthReply(sourceIpAddr、destIpAddr、destNbmaAddr)はSource IPアドレス、Destination IPアドレス、およびNBMA Address分野のsourceIpAddr、destIpAddr、およびdestNbmaAddrと共に積極的で、正式の、そして、非正式の回答をそれぞれ発生させます。
Heinanen & Govindan [Page 8] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[8ページ]RFC1735NBMAアルプ(NARP)1994年12月
genNegAuthReply(sourceIpAddr, destIpAddr) and genNegNonAuthReply(sourceIpAddr, destIpAddr) respectively generate a negative, authoritative and non-authoritative reply with sourceIpAddr and destIpAddr in Source IP address and Destination IP address fields, respectively.
genNegAuthReply、(sourceIpAddr、destIpAddr)、genNegNonAuthReply、(sourceIpAddr、destIpAddr) Source IPアドレスとDestination IPアドレス・フィールドのsourceIpAddrとdestIpAddrと共にネガ、正式の、そして、非正式の回答をそれぞれそれぞれ発生させてください。
requestForAuthInfo?(request) tests if request is a Request for authoritative information.
requestForAuthInfo?(要求)は要求が信頼できる情報のためのRequestであるならテストされます。
realBusyRightNow?() returns TRUE if the NAS is heavily loaded and FALSE otherwise.
realBusyRightNow?そうでなければ、()はNASが大いに積み込まれるか、そして、FALSEをTRUEに返します。
realRecentCacheEntry?(cacheTableEntry) returns TRUE if the cacheTableEntry is very recently updated and FALSE otherwise.
realRecentCacheEntry?そうでなければ、(cacheTableEntry)は非常に最近、cacheTableEntryをアップデートするか、そして、FALSEをTRUEに返します。
matchCacheTable(ipAddr) returns a cacheTable entry whose networkLayerAddr field is equal to ipAddr or FALSE if no match is found.
matchCacheTable(ipAddr)はマッチが全く見つけられないならnetworkLayerAddr分野がipAddrかFALSEと等しいcacheTableエントリーを返します。
forwardRequest(request, interface, ipAddr) decrements the Hop count field of request, recomputes the NARP Checksum field, and forwards request to ipAddr of interface provided that the value of the Hop count field remains positive.
最もforwardRequestに、(要求、インタフェース、ipAddr)は要求(NARP Checksumがさばいて、Hopカウント分野の値が積極的にままであればフォワードがインタフェースのipAddrに要求するrecomputes)のHopカウント分野を減少させます。
addCacheTableEntry(ipAddr, nbmaAddr, time) adds a new entry to the cacheTable or overwrites an existing entry whose networkLayerAddr field is equal to ipAddr.
addCacheTableEntry(ipAddr、nbmaAddr、時間)は新しいエントリーをcacheTableに加えるか、またはnetworkLayerAddr分野がipAddrと等しい既存のエントリーを上書きします。
forwardReply(reply, interface, ipAddr) decrements the Hop count field of request, recomputes the NARP Checksum field, and forwards reply to ipAddr of interface provided that the value of the Hop count field remains positive.
forwardReplyは要求のHopカウント分野を減少させます(ipAddr、返答してください、そして、連結してください)、NARP Checksumがさばくrecomputes、そして、Hopカウント分野の値が積極的にままであれば、フォワードはインタフェースのipAddrに答えます。
Like NASs, each NBMA terminal has a forwardingTable and a cacheTable. The forwardingTable is either manually configured or filled via reachability information exchange with the terminal's NASs or peer routers.
NASsのように、それぞれのNBMA端末にはforwardingTableとcacheTableがあります。 forwardingTableは端末のNASsか同輩ルータがある可到達性情報交換で手動で構成されるか、またはいっぱいにされます。
When the terminal wishes to find out the NBMA address of a particular destination terminal, it first checks if a matching entry is found in the forwardingTable. If not, the destination is unreachable and the terminal gives up. If a forwardingTable entry is found, and if the next hop belongs to one of the terminal's NASs, the terminal next consults its cacheTable to obtain the NBMA address. If no cache match is found, the terminal generates a NARP request to the next hop NAS. If the reply to the NARP request is positive, the terminal learns the NBMA address and updates its cacheTable with the new information.
特定のあて先端末のNBMAアドレスを見つけるという端末の願望であるときに、それは、最初に、合っているエントリーがforwardingTableで見つけられるかどうかチェックします。 そうでなければ、目的地は手が届きません、そして、端末はあきらめます。 forwardingTableエントリーが見つけられて、次のホップが端末のNASsの1つに属すなら、次の端末は、NBMAアドレスを得るためにcacheTableに相談します。 キャッシュマッチが全く見つけられないなら、端末は次のホップNASにNARP要求を発生させます。 NARP要求に関する回答が積極的であるなら、端末は、NBMAアドレスを学んで、新情報でcacheTableをアップデートします。
Heinanen & Govindan [Page 9] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[9ページ]RFC1735NBMAアルプ(NARP)1994年12月
6. Discussion
6. 議論
The NARP semantics resembles closely the ATMARP semantics described in [2]. The only actual differences are:
NARP意味論は密接に[2]で説明されたATMARP意味論に類似しています。 唯一の実際の違いは以下の通りです。
- NARP requests and replies include a hop count to prevent them from
looping forever in case of misconfigured NAS routing.
- NARP要求と回答は、それらがいつまでもmisconfigured NASルーティングの場合に輪にするのを防ぐためにホップカウントを含んでいます。
- NARP request and replies distinguish between authoritative and
non-authoritative information.
- NARP要求と回答は正式、そして、非信頼できる情報を見分けます。
In order to keep the NBMA terminals as simple as possible, it would be desirable to extend the the ATMARP protocol a little further so that it could be also used as the terminal-NAS protocol. This could be easily accomplished just by adding three new operation codes to ATMARP to cover the different kinds of queries and responses. NARP would then become the NAS-NAS protocol. Finally, if the NASs are co-located with the "classical" ATM ARP servers, the terminals would not need to make any distinction between between local and foreign IP subnetworks.
NBMA端末をできるだけ簡単に保って、ATMARPプロトコルを少し広げるのは、また、さらに端末-NASプロトコルとしてそれを使用できるくらい望ましいでしょう。 質問と応答の異種をカバーするために3つの新しい命令コードしかATMARPに加えないことによって、容易にこれを達成できるでしょう。 そして、NARPはNAS-NASプロトコルになるでしょう。 NASsがサーバ、端末が地方の、そして、外国のIPサブネットワークの間でどんな区別もする必要はないだろう「古典的な」ATM ARPと共に最終的に共同見つけられているなら。
The NASs can also act as "connectionless servers" for the terminal by advertizing to it all destinations no matter if they are inside or outside the served NBMA. Then, the terminal could choose either to try to resolve the NBMA address of the destination or just to send the IP packets to the NAS. The latter option may be desirable if communication with the destination is short-lived and/or doesn't require much network resources.
また、NBMAの中、または、役立たれたNBMAの外にそれらがあるならすべての目的地ノー、をそれにadvertizingするのによる端末への「コネクションレスなサーバ」が重要であるときに、NASsは行動できます。 そして、端末は、目的地のNBMAアドレスを決議しようとするか、またはまさしくIPパケットをNASに送ろうとするのを選ぶかもしれません。 目的地とのコミュニケーションが短命である、そして/または、多くのネットワーク資源を必要としないなら、後者のオプションは望ましいかもしれません。
NARP supports portability of NBMA terminals. A terminal can be moved anywhere within the NBMA network and still keep its original IP address as long as its NAS(s) remain the same. Requests for authoritative information will always return the correct NBMA address.
NARPはNBMA端末の携帯性を支持します。 NAS(s)が同じままで残っている限り、端末は、NBMAネットワークの中でどこでも動かされて、まだオリジナルのIPアドレスを保管できます。 信頼できる情報に関する要求はいつも正しいNBMAアドレスを返すでしょう。
References
参照
[1] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,
November 1982.
[1] プラマー、D.、「イーサネットは解決プロトコルを記述します--、イーサネットハードウェアの上でトランスミッションのための48.bitイーサネットアドレスにネットワーク・プロトコルアドレスを変換する、」、STD37、RFC826、MIT(1982年11月)
[2] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-
Packard Laboratories, January 1994.
[2]Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、ヒューレットパッカード研究所、1月1994
[3] Piscitello, D., and J. Lawrence, "Transmission of IP Datagrams
over the SMDS Service, RFC 1209, Bell Communications Research,
March 1991.
[3]Piscitello、D.、およびJ.ローレンス、「SMDSサービスの上のIPデータグラムの送信、RFC1209、ベルコミュニケーションズ・リサーチ、1991年3月。」
Heinanen & Govindan [Page 10] RFC 1735 NBMA ARP (NARP) December 1994
Heinanen&Govindan[10ページ]RFC1735NBMAアルプ(NARP)1994年12月
Acknowledgements
承認
We would like to thank John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern of Network Systems, and Paul Francis of Bellcore for their valuable insight and comments to earlier versions of this draft.
この草稿の以前のバージョンへの彼らの貴重な見識とコメントについてAdaptiveのJohn Burnett、ANSのデニスファーガソン、Network Systemsのジョエル・アルペルン、およびBellcoreのポール・フランシスに感謝申し上げます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Juha Heinanen Telecom Finland PO Box 228 SF-33101 Tampere Finland
ユハHeinanen電子通信フィンランドPO Box228SF-33101タンペレフィンランド
Phone: +358 49 500 958 EMail: Juha.Heinanen@datanet.tele.fi
以下に電話をしてください。 +358 49 500 958はメールされます: Juha.Heinanen@datanet.tele.fi
Ramesh Govindan USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
Ramesh Govindan USC/情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: +1 310-822-1511 EMail: govindan@isi.edu
以下に電話をしてください。 +1 310-822-1511 メールしてください: govindan@isi.edu
Heinanen & Govindan [Page 11]
Heinanen&Govindan[11ページ]
一覧
スポンサーリンク
