RFC2332 日本語訳
2332 NBMA Next Hop Resolution Protocol (NHRP). J. Luciani, D. Katz, D.Piscitello, B. Cole, N. Doraswamy. April 1998. (Format: TXT=126978 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Luciani
Request for Comments: 2332 Bay Networks
Category: Standards Track D. Katz
cisco Systems
D. Piscitello
Core Competence, Inc.
B. Cole
Juniper Networks
N. Doraswamy
Bay Networks
April 1998
Lucianiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2332年のベイネットワークスカテゴリ: 規格Track D.キャッツコクチマスSystems D.Piscitello Core Competence Inc.B.コールJuniper Networks N.Doraswamyベイネットワークス1998年4月
NBMA Next Hop Resolution Protocol (NHRP)
次のNBMAは解決プロトコルを飛び越します。(NHRP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. If the destination is connected to the NBMA subnetwork, then the NBMA next hop is the destination station itself. Otherwise, the NBMA next hop is the egress router from the NBMA subnetwork that is "nearest" to the destination station. NHRP is intended for use in a multiprotocol internetworking layer environment over NBMA subnetworks.
このドキュメントはNBMA Next Hop Resolutionプロトコル(NHRP)について説明します。 Non-放送(目的地ステーションに向かって「次のNBMAは跳ぶ」インターネットワーキング層のアドレスとNBMAサブネットワークアドレスを決定するMulti-アクセス(NBMA)サブネットワーク)につなげられた発信局(ホストかルータ)でNHRPを使用できます。 目的地がNBMAサブネットワークにつなげられるなら、次のNBMAが飛び越すその時による目的地ステーション自体です。 さもなければ、“nearest"であるNBMAサブネットワークから目的地ステーションまでNBMA次ホップは出口ルータです。 NHRPはNBMAサブネットワークの上の「マルチ-プロトコル」インターネットワーキング層の環境における使用のために意図します。
Note that while this protocol was developed for use with NBMA subnetworks, it is possible, if not likely, that it will be applied to BMA subnetworks as well. However, this usage of NHRP is for further study.
それがこのプロトコルが使用のためにNBMAサブネットワークで開発されましたが、可能であるか、またはありそうであり、また、BMAサブネットワークに適用されることに注意してください。 しかしながら、さらなる研究にはNHRPのこの使用法があります。
This document is intended to be a functional superset of the NBMA Address Resolution Protocol (NARP) documented in [1].
このドキュメントは[1]に記録されたNBMA Address Resolutionプロトコル(NARP)の機能的なスーパーセットであることを意図します。
Luciani, et. al. Standards Track [Page 1] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[1ページ]。
Operation of NHRP as a means of establishing a transit path across an NBMA subnetwork between two routers will be addressed in a separate document (see [13]).
2つのルータの間のNBMAサブネットワークの向こう側にトランジット経路を確立する手段としてのNHRPの操作は別々のドキュメントに記述されるでしょう。([13])を見てください。
1. Introduction
1. 序論
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [15].
キーワードが解釈しなければならない、本書では現れるとき、[15]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
The NBMA Next Hop Resolution Protocol (NHRP) allows a source station (a host or router), wishing to communicate over a Non-Broadcast, Multi-Access (NBMA) subnetwork, to determine the internetworking layer addresses and NBMA addresses of suitable "NBMA next hops" toward a destination station. A subnetwork can be non-broadcast either because it technically doesn't support broadcasting (e.g., an X.25 subnetwork) or because broadcasting is not feasible for one reason or another (e.g., an SMDS multicast group or an extended Ethernet would be too large). If the destination is connected to the NBMA subnetwork, then the NBMA next hop is the destination station itself. Otherwise, the NBMA next hop is the egress router from the NBMA subnetwork that is "nearest" to the destination station.
NBMA Next Hop Resolutionプロトコル(NHRP)は発信局(ホストかルータ)を許容します、目的地ステーションに向かって適当な「次のNBMAは跳ぶ」インターネットワーキング層のアドレスとNBMAアドレスを決定するためにNon-放送、Multi-アクセス(NBMA)サブネットワークの上で交信することを願っていて。 (例えば、X.25サブネットワーク)を放送するのを技術的に支持しないか、または何らかの理由には、放送が可能でないので、サブネットワークは非放送できます(例えば、SMDSマルチキャストグループか拡張イーサネットが大き過ぎるでしょう)。 目的地がNBMAサブネットワークにつなげられるなら、次のNBMAが飛び越すその時による目的地ステーション自体です。 さもなければ、“nearest"であるNBMAサブネットワークから目的地ステーションまでNBMA次ホップは出口ルータです。
One way to model an NBMA network is by using the notion of logically independent IP subnets (LISs). LISs, as defined in [3] and [4], have the following properties:
NBMAネットワークをモデル化する1つの方法は論理的に独立しているIPサブネット(LISs)の概念を使用することです。 [3]と[4]で定義されるLISsは以下の特性を持っています:
1) All members of a LIS have the same IP network/subnet number
and address mask.
1) LISのすべてのメンバーには、数とアドレスがマスクをかける同じIPネットワーク/サブネットがあります。
2) All members of a LIS are directly connected to the same
NBMA subnetwork.
2) LISのすべてのメンバーが直接同じNBMAサブネットワークに接続されます。
3) All hosts and routers outside of the LIS are accessed via
a router.
3) ルータでLISにおける外部のすべてのホストとルータはアクセスされます。
4) All members of a LIS access each other directly (without
routers).
4) LISのすべてのメンバーが直接(ルータなしで)互いにアクセスします。
Address resolution as described in [3] and [4] only resolves the next hop address if the destination station is a member of the same LIS as the source station; otherwise, the source station must forward packets to a router that is a member of multiple LIS's. In multi-LIS
[3]と[4]で説明されるアドレス決議は目的地ステーションが発信局と同じLISのメンバーである場合にだけ次のホップアドレスを決議します。 さもなければ、発信局は複数のLISのメンバーであるルータにパケットを送らなければなりません。 マルチLISで
Luciani, et. al. Standards Track [Page 2] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[2ページ]。
configurations, hop-by-hop address resolution may not be sufficient to resolve the "NBMA next hop" toward the destination station, and IP packets may have multiple IP hops through the NBMA subnetwork.
構成、ホップごとのアドレス解決は、目的地ステーション、およびIPに向かって「次のNBMAは跳ぶ」というパケットがNBMAサブネットワークを通して複数のIPホップを持っているかもしれないと決議するために十分でないかもしれません。
Another way to model NBMA is by using the notion of Local Address Groups (LAGs) [10]. The essential difference between the LIS and the LAG models is that while with the LIS model the outcome of the "local/remote" forwarding decision is driven purely by addressing information, with the LAG model the outcome of this decision is decoupled from the addressing information and is coupled with the Quality of Service and/or traffic characteristics. With the LAG model any two entities on a common NBMA network could establish a direct communication with each other, irrespective of the entities' addresses.
NBMAをモデル化する別の方法はLocal Address Groups(LAGs)[10]の概念を使用することです。 LISとLAGモデルの本質的な相違はこの決定の結果がLAGモデルと共に、「地方かリモートな」推進決定の結果がLISモデルと共にアドレス指定情報によって純粋に動かされますが、アドレス指定情報から衝撃を吸収されて、Service、そして/または、交通の特性のQualityに結びつけられるということです。 LAGモデルと共に、一般的なNBMAネットワークのどんな2つの実体も互いとのダイレクトコミュニケーションを確立するかもしれません、実体のアドレスの如何にかかわらず。
Support for the LAG model assumes the existence of a mechanism that allows any entity (i.e., host or router) connected to an NBMA network to resolve an internetworking layer address to an NBMA address for any other entity connected to the same NBMA network. This resolution would take place regardless of the address assignments to these entities. Within the parameters described in this document, NHRP describes such a mechanism. For example, when the internetworking layer address is of type IP, once the NBMA next hop has been resolved, the source may either start sending IP packets to the destination (in a connectionless NBMA subnetwork such as SMDS) or may first establish a connection to the destination with the desired bandwidth (in a connection-oriented NBMA subnetwork such as ATM).
LAGモデルのサポートはNBMAネットワークに関連づけられたどんな実体(すなわち、ホストかルータ)も同じNBMAネットワークに関連づけられたいかなる他の実体のためのNBMAアドレスにもインターネットワーキング層のアドレスを決議できるメカニズムの存在を仮定します。 この解決はこれらの実体へのアドレス課題にかかわらず行われるでしょう。 本書では説明されたパラメタの中では、NHRPはそのようなメカニズムについて説明します。 タイプIPにはインターネットワーキング層のアドレスがあるとき、例えば、かつての次のホップが持っているNBMAが決議されて、ソースは、目的地(SMDSなどのコネクションレスなNBMAサブネットワークの)にIPパケットを送り始めるか、または最初に、必要な帯域幅(ATMなどの接続指向のNBMAサブネットワークの)で接続を目的地に確立するかもしれません。
Use of NHRP may be sufficient for hosts doing address resolution when those hosts are directly connected to an NBMA subnetwork, allowing for straightforward implementations in NBMA stations. NHRP also has the capability of determining the egress point from an NBMA subnetwork when the destination is not directly connected to the NBMA subnetwork and the identity of the egress router is not learned by other methods (such as routing protocols). Optional extensions to NHRP provide additional robustness and diagnosability.
NHRPの使用はそれらのホストが直接NBMAサブネットワークに接続されるときアドレス解決をしているホストに十分であるかもしれません、NBMAステーションで簡単な実現を考慮して。 また、NHRPには、目的地が直接NBMAサブネットワークにつなげられないで、また出口ルータのアイデンティティが他の方法(ルーティング・プロトコルなどの)によって学習されないときNBMAサブネットワークからの出口ポイントを決定する能力があります。 NHRPへの任意の拡大は追加丈夫さとdiagnosabilityを提供します。
Address resolution techniques such as those described in [3] and [4] may be in use when NHRP is deployed. ARP servers and services over NBMA subnetworks may be required to support hosts that are not capable of dealing with any model for communication other than the LIS model, and deployed hosts may not implement NHRP but may continue to support ARP variants such as those described in [3] and [4]. NHRP is intended to reduce or eliminate the extra router hops required by the LIS model, and can be deployed in a non-interfering manner with existing ARP services [14].
NHRPが配備されるとき、[3]と[4]で説明されたものなどのアドレス解決のテクニックは使用中であるかもしれません。 NBMAサブネットワークの上のARPサーバとサービスがLISモデル以外のコミュニケーションのためのどんなモデルにも対処できないホストを支持するのに必要であるかもしれなく、配備されたホストは、NHRPを実行しませんが、[3]と[4]で説明されたものなどのARP異形を支持し続けるかもしれません。 NHRPはLISモデルによって必要とされた余分なルータホップを減少するか、または排除することを意図して、既存のARPサービス[14]で非干渉方法で配備できます。
Luciani, et. al. Standards Track [Page 3] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[3ページ]。
The operation of NHRP to establish transit paths across NBMA subnetworks between two routers requires additional mechanisms to avoid stable routing loops, and will be described in a separate document (see [13]).
2つのルータの間のNBMAサブネットワークの向こう側にトランジット経路を確立するNHRPの操作は、追加メカニズムが安定したルーティング輪を避けるのが必要であり、別々のドキュメントで説明されるでしょう。([13])を見てください。
2. Overview
2. 概観
2.1 Terminology
2.1 用語
The term "network" is highly overloaded, and is especially confusing in the context of NHRP. We use the following terms:
「ネットワーク」という用語は、非常に積みすぎられて、NHRPの文脈で特に混乱させられています。 私たちは次の用語を使用します:
Internetwork layer--the media-independent layer (IP in the case of
TCP/IP networks).
インターネットワーク層--メディアから独立している層(TCP/IPネットワークの場合におけるIP)。
Subnetwork layer--the media-dependent layer underlying the
internetwork layer, including the NBMA technology (ATM, X.25, SMDS,
etc.)
サブネットワーク層--NBMA技術を含むインターネットワーク層の基礎となるメディア依存する層(ATM、X.25、SMDSなど)
The term "server", unless explicitly stated to the contrary, refers
to a Next Hop Server (NHS). An NHS is an entity performing the
Next Hop Resolution Protocol service within the NBMA cloud. An NHS
is always tightly coupled with a routing entity (router, route
server or edge device) although the converse is not yet guaranteed
until ubiquitous deployment of this functionality occurs. Note
that the presence of intermediate routers that are not coupled with
an NHS entity may preclude the use of NHRP when source and
destination stations on different sides of such routers and thus
such routers may partition NHRP reachability within an NBMA
network.
明らかにそれと反対に述べられない場合、「サーバ」という用語はNext Hop Server(NHS)について言及します。 NHSはNBMA雲の中でNext Hop Resolutionプロトコルサービスを実行する実体です。 この機能性の遍在している展開が起こるまで、逆はまだ保証されていませんが、NHSはいつもしっかりルーティング実体(ルータ、ルートサーバまたはエッジデバイス)に結びつけられます。 そのようなルータとその結果、そのようなルータ異なる側の上のソースと目的地ステーションがNBMAネットワークの中でNHRPの可到達性を仕切るとき、NHS実体に結びつけられない中間的ルータの存在がNHRPの使用を排除するかもしれないことに注意してください。
The term "client", unless explicitly stated to the contrary, refers
to a Next Hop Resolution Protocol client (NHC). An NHC is an
entity which initiates NHRP requests of various types in order to
obtain access to the NHRP service.
明らかにそれと反対に述べられない場合、「クライアント」という用語はNext Hop Resolutionプロトコルクライアント(NHC)について言及します。 NHCはNHRPサービスへのアクセスを得るために様々なタイプのNHRP要求を開始する実体です。
The term "station" generally refers to a host or router which
contains an NHRP entity. Occasionally, the term station will
describe a "user" of the NHRP client or service functionality; the
difference in usage is largely semantic.
一般に、「ステーション」という用語はNHRP実体を含むホストかルータについて言及します。 時折、用語ステーションはNHRPクライアントかサービスの機能性の「ユーザ」について説明するでしょう。 用法の違いは主に意味的です。
2.2 Protocol Overview
2.2 プロトコル概観
In this section, we briefly describe how a source S (which potentially can be either a router or a host) uses NHRP to determine the "NBMA next hop" to destination D.
このセクションで、私たちは簡潔にソースS(潜在的にルータかホストのどちらかであるかもしれません)が目的地へ「次のNBMAは跳び」Dを決定するのにどうNHRPを使用するかを説明します。
Luciani, et. al. Standards Track [Page 4] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[4ページ]。
For administrative and policy reasons, a physical NBMA subnetwork may be partitioned into several, disjoint "Logical NBMA subnetworks". A Logical NBMA subnetwork is defined as a collection of hosts and routers that share unfiltered subnetwork connectivity over an NBMA subnetwork. "Unfiltered subnetwork connectivity" refers to the absence of closed user groups, address screening or similar features that may be used to prevent direct communication between stations connected to the same NBMA subnetwork. (Hereafter, unless otherwise specified, we use the term "NBMA subnetwork" to mean *logical* NBMA subnetwork.)
管理と方針理由で、物理的なNBMAサブネットワークは数個に仕切られるかもしれなくて、「論理的なNBMAサブネットワーク」をばらばらにならせてください。 Logical NBMAサブネットワークはNBMAサブネットワークの上で非濾過のサブネットワークの接続性を共有するホストとルータの収集と定義されます。 「非濾過のサブネットワークの接続性」は同じNBMAサブネットワークにつなげられたステーションのダイレクトコミュニケーションを防ぐのに使用されるかもしれないクローズド・ユーザ・グループ、アドレス選別または同様の特徴の欠如を示します。 (今後、別の方法で指定されない場合、私たちは用語*論理的な*NBMA意味する「NBMAサブネットワーク」サブネットワークを使用します。)
Placed within the NBMA subnetwork are one or more entities that implement the NHRP protocol. Such stations which are capable of answering NHRP Resolution Requests are known as "Next Hop Servers" (NHSs). Each NHS serves a set of destination hosts, which may or may not be directly connected to the NBMA subnetwork. NHSs cooperatively resolve the NBMA next hop within their logical NBMA subnetwork. In addition to NHRP, NHSs may support "classical" ARP service; however, this will be the subject of a separate document [14].
NBMAサブネットワークの中に置かれているのは、NHRPプロトコルを実行する1つ以上の実体です。 NHRP Resolution Requestsに答えることができるそのようなステーションが「次のホップサーバ」として知られています(NHSs)。 各NHSはあて先ホストのセットに役立ちます。(そのあて先ホストは、直接NBMAサブネットワークに接続されるかもしれません)。 NHSsは、次のNBMAが彼らの論理的なNBMAサブネットワークの中を飛び越すと協力して決議します。 NHRPに加えて、NHSsは「古典的な」ARPサービスを支持するかもしれません。 しかしながら、これは別々のドキュメント[14]の対象になるでしょう。
An NHS maintains a cache which contains protocol layer address to NBMA subnetwork layer address resolution information. This cache can be constructed from information obtained from NHRP Register packets (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply packets, or through mechanisms outside the scope of this document (examples of such mechanisms might include ARP[3] and pre-configured tables). Section 6.2 further describes cache management issues.
NHSはNBMAサブネットワーク層のアドレス解決情報にプロトコル層アドレスを含むキャッシュを維持します。 セクション5.2.3と5.2を見てください。NHRP Registerパケットから得られた情報からこのキャッシュを構成できる、(.4) NHRP Resolution Request/回答パケットか、このドキュメント(そのようなメカニズムに関する例は、ARP[3]を含んだかもしれなくて、テーブルをあらかじめ設定した)の範囲の外のメカニズムを通して。 セクション6.2はさらにキャッシュ管理問題について説明します。
For a station within a given LIS to avoid providing NHS functionality, there must be one or more NHSs within the NBMA subnetwork which are providing authoritative address resolution information on its behalf. Such an NHS is said to be "serving" the station. A station on a LIS that lacks NHS functionality and is a client of the NHRP service is known as NHRP Client or just NHCs. If a serving NHS is to be able to supply the address resolution information for an NHC then NHSs must exist at each hop along all routed paths between the NHC making the resolution request and the destination NHC. The last NHRP entity along the routed path is the serving NHS; that is, NHRP Resolution Requests are not forwarded to destination NHCs but rather are processed by the serving NHS.
与えられたLISの中のステーションが、機能性をNHSに供給するのを避けるように、NBMAサブネットワークの中にそのに代わって正式のアドレス解決情報を提供している1NHSsがあるに違いありません。 そのようなNHSはステーションに「役立っている」と言われています。 NHSの機能性を欠いて、NHRPサービスのクライアントであるLISの上のステーションはNHRP ClientかまさしくNHCsとして知られています。 給仕NHSがNHCのためのアドレス解決情報を提供するつもりであることができるなら、NHSsは解決要求をするNHCと目的地NHCの間のすべての発送された経路に沿って各ホップに存在しなければなりません。 発送された経路に沿った最後のNHRP実体は給仕NHSです。 すなわち、NHRP Resolution Requestsは目的地NHCsに送られませんが、給仕NHSによってむしろ処理されます。
An NHC also maintains a cache of protocol address to NBMA address resolution information. This cache is populated through information obtained from NHRP Resolution Reply packets, from manual configuration, or through mechanisms outside the scope of this document.
また、NHCはNBMAアドレス解決情報にプロトコルアドレスのキャッシュを維持します。 このキャッシュはNHRP Resolution Replyパケット、手動の構成から入手された情報を通して、または、このドキュメントの範囲の外のメカニズムを通して居住されます。
Luciani, et. al. Standards Track [Page 5] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[5ページ]。
The protocol proceeds as follows. An event occurs triggering station S to want to resolve the NBMA address of a path to D. This is most likely to be when a data packet addressed to station D is to be emitted from station S (either because station S is a host, or station S is a transit router), but the address resolution could also be triggered by other means (a routing protocol update packet, for example). Station S first determines the next hop to station D through normal routing processes (for a host, the next hop may simply be the default router; for routers, this is the "next hop" to the destination internetwork layer address). If the destination's address resolution information is already available in S's cache then that information is used to forward the packet. Otherwise, if the next hop is reachable through one of its NBMA interfaces, S constructs an NHRP Resolution Request packet (see Section 5.2.1) containing station D's internetwork layer address as the (target) destination address, S's own internetwork layer address as the source address (Next Hop Resolution Request initiator), and station S's NBMA addressing information. Station S may also indicate that it prefers an authoritative NHRP Resolution Reply (i.e., station S only wishes to receive an NHRP Resolution Reply from an NHS serving the destination NHC). Station S emits the NHRP Resolution Request packet towards the destination.
プロトコルは以下の通り続きます。 出来事はステーションS(ステーションSがホストであるかステーションSがトランジットルータであるので)から放たれるためにD.Thisへの経路のNBMAアドレスがステーションDに記述されたデータ・パケットがいつかということである最も傾向があると決議したいステーションSの引き金となりながら、起こりますが、また、他の手段(例えば、ルーティング・プロトコルアップデートパケット)でアドレス解決を引き起こすことができるでしょう。 駅Sは最初に、正常なルーティングの過程で次のホップをステーションDに決定します(ホストにとって、次のホップは単にデフォルトルータであるかもしれません; ルータのために、これは送付先インターネットワーク層のアドレスへの「次のホップ」です)。 目的地のアドレス解決情報がSのキャッシュで既に利用可能であるなら、その情報は、パケットを進めるのに使用されます。 さもなければ、次のホップがNBMAインタフェースの1つを通して届くなら、(目標)送付先アドレス、ソースアドレス(次のHop Resolution Request創始者)としてのSの自己のインターネットワーク層のアドレス、およびステーションSのNBMAアドレス指定情報としてステーションDのインターネットワーク層のアドレスを含んでいて、SはNHRP Resolution Requestパケット(セクション5.2.1を見る)を組み立てます。 また、駅Sは、正式のNHRP Resolution Replyを好むのを示すかもしれません(すなわち、ステーションSは目的地NHCに役立つNHSからNHRP Resolution Replyを受け取るだけでありたいです)。 駅SはNHRP Resolution Requestパケットを目的地に向かって放ちます。
If the NHRP Resolution Request is triggered by a data packet then S may, while awaiting an NHRP Resolution Reply, choose to dispose of the data packet in one of the following ways:
NHRP Resolution Requestがデータ・パケットによって引き起こされるなら、Sは、NHRP Resolution Replyを待っている間、以下の方法の1つでデータ・パケットを処分するのを選ぶかもしれません:
(a) Drop the packet
(b) Retain the packet until the NHRP Resolution Reply arrives
and a more optimal path is available
(c) Forward the packet along the routed path toward D
(a) 低下してください、NHRP Resolution Replyが到着するまで、パケット(b)はパケットを保有して、より最適の経路は利用可能な(c)が発送された経路に沿ってDに向かってパケットを送るということです。
The choice of which of the above to perform is a local policy matter, though option (c) is the recommended default, since it may allow data to flow to the destination while the NBMA address is being resolved. Note that an NHRP Resolution Request for a given destination MUST NOT be triggered on every packet.
選択は上記のどれを実行するかをローカルの方針問題です、オプション(c)はお勧めのデフォルトですが、NBMAアドレスが決議されている間、データがそれで目的地に注ぐことができるかもしれないので。 あらゆるパケットの上で与えられた目的地へのNHRP Resolution Requestを引き起こさなければならないというわけではないことに注意してください。
When the NHS receives an NHRP Resolution Request, a check is made to see if it serves station D. If the NHS does not serve D, the NHS forwards the NHRP Resolution Request to another NHS. Mechanisms for determining how to forward the NHRP Resolution Request are discussed in Section 3.
NHSがNHRP Resolution Requestを受けるとき、ステーションD.Ifに役立つならNHSがDに役立たないのを確実にするのをチェックをして、NHSは別のNHSにNHRP Resolution Requestを送ります。 セクション3でNHRP Resolution Requestを進める方法を決定するためのメカニズムについて議論します。
If this NHS serves D, the NHS resolves station D's NBMA address information, and generates a positive NHRP Resolution Reply on D's behalf. NHRP Resolution Replies in this scenario are always marked as "authoritative". The NHRP Resolution Reply packet contains the
このNHSがDに役立つなら、NHSはステーションDのNBMAアドレス情報を決議して、Dに代わって積極的なNHRP Resolution Replyを発生させます。 このシナリオのNHRP Resolution Repliesは「正式である」としていつもマークされます。 NHRP Resolution Replyパケットは含んでいます。
Luciani, et. al. Standards Track [Page 6] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[6ページ]。
address resolution information for station D which is to be sent back to S. Note that if station D is not on the NBMA subnetwork, the next hop internetwork layer address will be that of the egress router through which packets for station D are forwarded.
ステーションDがNBMAサブネットワーク、次のホップインターネットワーク層のアドレスにないなら出口ルータのものになるステーションDへのパケットが進められるS.Noteが送り返されることになっているステーションDのための解決情報を記述してください。
A transit NHS receiving an NHRP Resolution Reply may cache the address resolution information contained therein. To a subsequent NHRP Resolution Request, this NHS may respond with the cached, "non- authoritative" address resolution information if the NHS is permitted to do so (see Sections 5.2.2 and 6.2 for more information on non- authoritative versus authoritative NHRP Resolution Replies). Non- authoritative NHRP Resolution Replies are distinguished from authoritative NHRP Resolution Replies so that if a communication attempt based on non-authoritative information fails, a source station can choose to send an authoritative NHRP Resolution Request. NHSs MUST NOT respond to authoritative NHRP Resolution Requests with cached information.
NHRP Resolution Replyを受けるトランジットNHSはそこに含まれたアドレス解決情報をキャッシュするかもしれません。 その後のNHRP Resolution Requestに、NHSがそうすることが許可されるなら(セクション5.2 詳しい情報のための.2と6.2がオンであることを正式のNHRP Resolution Repliesに対して非正式の状態で見てください)、このNHSはキャッシュされて、「非正式」のアドレス解決情報で応じるかもしれません。 非正式のNHRP Resolution Repliesは、非信頼できる情報に基づくコミュニケーション試みが失敗するなら、発信局が、正式のNHRP Resolution Requestを送るのを選ぶことができるように、正式のNHRP Resolution Repliesと区別されます。 NHSsはキャッシュされた情報で正式のNHRP Resolution Requestsに応じてはいけません。
If the determination is made that no NHS in the NBMA subnetwork can reply to the NHRP Resolution Request for D then a negative NHRP Resolution Reply (NAK) is returned. This occurs when (a) no next-hop resolution information is available for station D from any NHS, or (b) an NHS is unable to forward the NHRP Resolution Request (e.g., connectivity is lost).
決断をするなら、NBMAサブネットワークのそのノーNHSはDのためにNHRP Resolution Requestに答えることができて、次に、否定的NHRP Resolution Reply(NAK)を返します。 (b) (a) どんな次のホップ解決情報もどんなNHSからのステーションDにも利用可能でないときに、これが起こるか、またはNHSはNHRP Resolution Requestを進めることができません(例えば、接続性は無くなっています)。
NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, and NHRP Error Indications follow a routed path in the same fashion that NHRP Resolution Requests and NHRP Resolution Replies do. Specifically, "requests" and "indications" follow the routed path from Source Protocol Address (which is the address of the station initiating the communication) to the Destination Protocol Address. "Replies", on the other hand, follow the routed path from the Destination Protocol Address back to the Source Protocol Address with the following exceptions: in the case of a NHRP Registration Reply and in the case of an NHC initiated NHRP Purge Request, the packet is always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if one does not exists then one MUST be created.
NHRP Resolution RequestsとNHRP Resolution Repliesがするのと同じファッションでNHRP Registration Requests、NHRP Purge Requests、NHRP Purge Replies、およびNHRP Error Indicationsは発送された経路に続きます。 明確に、「要求」と「指摘」は発送されたSourceプロトコルAddress(コミュニケーションを開始するステーションのアドレスである)からDestinationプロトコルAddressまでの経路に続きます。 他方では、「回答」は以下の例外がある発送されたDestinationプロトコルAddressからSourceプロトコルAddressまでの経路に続きます: NHRP Registration Replyの場合とNHCの場合では、ダイレクトVCを通して開始しているNHRP Purge Request、パケットをいつも返す、(セクション5.2 .4と5.2を見てください、.5)。 1がそうしない、存在、そして、作成しなければなりません。
NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA subnetwork however further study is being done in this area (see Section 7). Thus, the internetwork layer data traffic out of and into an NBMA subnetwork always traverses an internetwork layer router at its border.
この領域でどのようにさらなる研究をしていても(セクション7を見てください)、NHRP RequestsとNHRP RepliesはNBMAサブネットワークの境界を越えません。 したがって、サブネットワークとNBMAサブネットワークの中へのインターネットワーク層のデータ通信量は境界でいつもインターネットワーク層のルータを横断します。
NHRP optionally provides a mechanism to send a NHRP Resolution Reply which contains aggregated address resolution information. For example, suppose that router X is the next hop from station S to station D and that X is an egress router for all stations sharing an
NHRPは、集められたアドレス解決情報を含むNHRP Resolution Replyを送るために任意にメカニズムを提供します。 例えば、ステーションSからステーションDまでそのルータXが次のホップであり、それがXであるなら、すべてのステーションへの出口ルータは共有されています。
Luciani, et. al. Standards Track [Page 7] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[7ページ]。
internetwork layer address prefix with station D. When an NHRP Resolution Reply is generated in response to a NHRP Resolution Request, the responder may augment the internetwork layer address of station D with a prefix length (see Section 5.2.0.1). A subsequent (non-authoritative) NHRP Resolution Request for some destination that shares an internetwork layer address prefix (for the number of bits specified in the prefix length) with D may be satisfied with this cached information. See section 6.2 regarding caching issues.
セクション5.2を見てください。インターネットワーク層のアドレス接頭語、ステーションD.Whenに、NHRP Resolution ReplyがNHRP Resolution Requestに対応して発生して、接頭語の長さに従って応答者がステーションDのインターネットワーク層のアドレスを増大させるかもしれない、(.0 .1)。 インターネットワーク層のアドレス接頭語(接頭語の長さで指定されたビットの数のための)をDと共有するいくつかの目的地がこれに満足するかもしれないので、その後(非正式の)のNHRP Resolution Requestは情報をキャッシュしました。 問題をキャッシュすることに関するセクション6.2を見てください。
To dynamically detect subnetwork-layer filtering in NBMA subnetworks (e.g., X.25 closed user group facility, or SMDS address screens), to trace the routed path that an NHRP packet takes, or to provide loop detection and diagnostic capabilities, a "Route Record" may be included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route Record extensions are the NHRP Forward Transit NHS Record Extension and the NHRP Reverse Transit NHS Record Extension. They contain the internetwork (and subnetwork layer) addresses of all intermediate NHSs between source and destination and between destination and source respectively. When a source station is unable to communicate with the responder (e.g., an attempt to open an SVC fails), it may attempt to do so successively with other subnetwork layer addresses in the NHRP Forward Transit NHS Record Extension until it succeeds (if authentication policy permits such action). This approach can find a suitable egress point in the presence of subnetwork-layer filtering (which may be source/destination sensitive, for instance, without necessarily creating separate logical NBMA subnetworks) or subnetwork-layer congestion (especially in connection-oriented media).
セクション5.3.2と5.3を見てください。サブネットワーク層がNBMAでサブネットワーク(例えば、X.25クローズド・ユーザ・グループ施設、またはSMDSアドレススクリーン)をフィルターにかけるのをダイナミックに検出するか、NHRPパケットが取る発送された経路をたどるか、または輪の検出と診断能力を前提とするために、「ルート記録」がNHRPパケットに含まれるかもしれない、(.3)。 Route Record拡張子は、NHRP Forward Transit NHS Record ExtensionとNHRP Reverse Transit NHS Record Extensionです。 彼らはソースと目的地の間と、そして、目的地とソースの間にそれぞれすべての中間的NHSsのインターネットワーク(そして、サブネットワーク層)アドレスを保管しています。 発信局が応答者とコミュニケートできないとき(SVCを開く例えば試みるのは失敗します)、他のサブネットワーク層のアドレスがNHRP Forward Transit NHS Record Extensionにある状態で、それは相次ぐときにそれほど成功するまで(認証方針がそのような動作を可能にするなら)しようとして未遂に終わるかもしれません。 このアプローチによって、サブネットワーク層のフィルタリング(例えば、必ず別々の論理的なNBMAサブネットワークを作成するというわけではなくて敏感なソース/目的地であるかもしれない)かサブネットワーク層の混雑(特に接続指向のメディアにおける)があるとき適当な出口がポイントであるのに当たることができます。
3. Deployment
3. 展開
NHRP Resolution Requests traverse one or more hops within an NBMA subnetwork before reaching the station that is expected to generate a response. Each station, including the source station, chooses a neighboring NHS to which it will forward the NHRP Resolution Request. The NHS selection procedure typically involves applying a destination protocol layer address to the protocol layer routing table which causes a routing decision to be returned. This routing decision is then used to forward the NHRP Resolution Request to the downstream NHS. The destination protocol layer address previously mentioned is carried within the NHRP Resolution Request packet. Note that even though a protocol layer address was used to acquire a routing decision, NHRP packets are not encapsulated within a protocol layer header but rather are carried at the NBMA layer using the encapsulation described in Section 5.
応答を発生させると予想されるステーションに達する前に、NHRP Resolution RequestsはNBMAサブネットワークの中の1つ以上のホップを横断します。 発信局を含む各ステーションがそれがNHRP Resolution Requestを送る隣接しているNHSを選びます。 NHS選択手順は、返されるというルーティング決定を引き起こすプロトコル層経路指定テーブルに送付先プロトコル層アドレスを適用することを通常伴います。 そして、このルーティング決定は、川下のNHSにNHRP Resolution Requestを送るのに使用されます。 以前に参照された送付先プロトコル層アドレスはNHRP Resolution Requestパケットの中で運ばれます。 NHRPパケットがプロトコル層アドレスがルーティング決定を取得するのに使用されましたが、プロトコル層ヘッダーの中に要約されませんが、NBMA層でセクション5で説明されたカプセル化を使用することでむしろ運ばれることに注意してください。
Luciani, et. al. Standards Track [Page 8] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[8ページ]。
Each NHS/router examines the NHRP Resolution Request packet on its way toward the destination. Each NHS which the NHRP packet traverses on the way to the packet's destination might modify the packet (e.g., updating the Forward Record extension). Ignoring error situations, the NHRP Resolution Request eventually arrives at a station that is to generate an NHRP Resolution Reply. This responding station "serves" the destination. The responding station generates an NHRP Resolution Reply using the source protocol address from within the NHRP packet to determine where the NHRP Resolution Reply should be sent.
各NHS/ルータは目的地に向かった途中でNHRP Resolution Requestパケットを調べます。 NHRPパケットがパケットの目的地への途中に横断する各NHSはパケット(例えば、Forward Record拡張子をアップデートする)を変更するかもしれません。 エラー状態を無視して、NHRP Resolution Requestは結局、NHRP Resolution Replyを発生させることになっているステーションに到着します。 この応じるステーションは目的地に「役立ちます」。 応じるステーションは、NHRP Resolution Replyがどこに送られるべきであるかを決定するのにNHRPパケットからのソースプロトコルアドレスを使用することでNHRP Resolution Replyを発生させます。
Rather than use routing to determine the next hop for an NHRP packet, an NHS may use other applicable means (such as static configuration information ) in order to determine to which neighboring NHSs to forward the NHRP Resolution Request packet as long as such other means would not cause the NHRP packet to arrive at an NHS which is not along the routed path. The use of static configuration information for this purpose is beyond the scope of this document.
むしろ、NHSは、NHRPパケットが他の手段で長いときにそういうものとして発送された経路に沿ってないNHSに到着しないようにNHRP Resolution Requestパケットを進めることをどの隣接しているNHSsに決定するかに、NHRPパケットのために次のホップを決定するのにルーティングを使用するより他の適切な手段(静的な設定情報などの)を使用するかもしれません。 静的な設定情報の使用はこのためにこのドキュメントの範囲を超えています。
The NHS serving a particular destination must lie along the routed path to that destination. In practice, this means that all egress routers must double as NHSs serving the destinations beyond them, and that hosts on the NBMA subnetwork are served by routers that double as NHSs. Also, this implies that forwarding of NHRP packets within an NBMA subnetwork requires a contiguous deployment of NHRP capable routers. It is important that, in a given LIS/LAG which is using NHRP, all NHSs within the LIS/LAG have at least some portion of their resolution databases synchronized so that a packet arriving at one router/NHS in a given LIS/LAG will be forwarded in the same fashion as a packet arriving at a different router/NHS for the given LIS/LAG. One method, among others, is to use the Server Cache Synchronization Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used when a LIS/LAG contains two or more router/NHSs.
発送された経路に沿ってその目的地には特定の目的地に役立つNHSがいなければなりません。 実際には、これは、すべての出口ルータをそれらを超えて目的地に役立つNHSsの役目も兼ねなければならなくて、NBMAサブネットワークの上のホストがNHSsの役目も兼ねるルータによって役立たれていることを意味します。 また、これは、NBMAサブネットワークの中のNHRPパケットの推進がNHRPのできるルータの隣接の展開を必要とするのを含意します。 LIS/LAGの中のすべてのNHSsが同じファッションで与えられたLIS/LAGの1ルータ/NHSに到着するパケットを進めるように与えられたLIS/LAGのために異なったルータ/NHSに到着するパケットとしてNHRPを使用している与えられたLIS/LAGで彼らの解決データベースの少なくとも何らかの部分を同期させるのは重要です。 1つの方法はServer Cache Synchronizationプロトコル(SCSP)[12]を特に使用することです。 SCSPがLIS/LAGが2ルータ/NHSsを含むとき使用される方法であることはRECOMMENDEDです。
During migration to NHRP, it cannot be expected that all routers within the NBMA subnetwork are NHRP capable. Thus, NHRP traffic which would otherwise need to be forwarded through such routers can be expected to be dropped due to the NHRP packet not being recognized. In this case, NHRP will be unable to establish any transit paths whose discovery requires the traversal of the non-NHRP speaking routers. If the client has tried and failed to acquire a cut through path then the client should use the network layer routed path as a default.
NHRPへの移動の間、NBMAサブネットワークの中のすべてのルータができるNHRPであることを期待できません。 したがって、認識されないNHRPパケットのためそうでなければそのようなルータを通して進められる必要があるNHRP交通が落とされると予想できます。 この場合、NHRPは発見が非NHRPの話すルータの縦断を必要とするどんなトランジット経路も確立できないでしょう。 クライアントが、試みて、経路を通してカットを取得するのに失敗したなら、クライアントはデフォルトとしてネットワーク層の発送された経路を使用するべきです。
If an NBMA technology offers a group, an anycast, or a multicast addressing feature then the NHC may be configured with such an address (appropriate to the routing realm it participates in) which would be assigned to all NHS serving that routing realm. This
NBMA技術がグループ、anycast、またはマルチキャストアドレシング機能を提供するなら、そのルーティング分野に役立つすべてのNHSに割り当てられるそのようなアドレス(それが参加するルーティング分野に適切な)によってNHCは構成されるかもしれません。 これ
Luciani, et. al. Standards Track [Page 9] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[9ページ]。
address can then be used for establishing an initial connection to an NHS to transmit a registration request. This address may not be used for sending NHRP requests. The resulting VC may be used for NHRP requests if and only if the registration response is received over that VC, thereby indicating that one happens to have anycast connected to an NHS serving the LIS/LAG. In the case of non- connection oriented networks, or of multicast (rather than anycast) addresses, the addres MUST NOT be used for sending NHRP resolution requests.
そして、登録要求を伝えるために初期の接続をNHSに確立するのにアドレスを使用できます。 このアドレスは送付NHRP要求に使用されないかもしれません。 結果として起こるVCがNHRP要求に使用されるかもしれない、登録応答である場合にだけ、そのVCの上に受け取られて、その結果、1つでたまたまLIS/LAGに役立つNHSにanycastを接続するのを示すのは、そうです。 非接続している指向のネットワーク、またはマルチキャスト(anycastよりむしろ)アドレスの場合では、送付NHRP解決要求にaddresを使用してはいけません。
When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined for the NHC directly to the NHC. That is, the NHRP message MUST NOT transit through any NHS which is not serving the NHC when the NHRP message is currently at an NHS which does serve the NHC (this, of course, assumes the NHRP message is destined for the NHC). Further, an NHS which serves an NHC SHOULD have a direct NBMA level connection to that NHC (see Section 5.2.3 and 5.2.4 for examples).
NHSがNHCに「役立つ」と、NHS MUSTはNHCのために直接NHCに運命づけられたメッセージをNHRPに送ります。 どんなNHSを通したNHRPメッセージであるときにNHCに役立っていないトランジットではなく、すなわち、メッセージがそうしなければならないNHRPが現在、NHCに役立つNHSにあります(これは、もちろんNHRPメッセージがNHCのために運命づけられていると仮定します)。 さらに、NHC SHOULDに役立つNHSがダイレクトNBMAにそのNHCに平らにさせる、接続を(セクション5.2 .3と5.2を見てください、例のための.4)
With the exception of NHRP Registration Requests (see Section 5.2.3 and 5.2.4 for details of the NHRP Registration Request case), an NHC MUST send NHRP messages over a direct NBMA level connection between the serving NHS and the served NHC.
NHRP Registration Requests(セクション5.2.3とNHRP Registration Requestの細部のための.4がケースに入れる5.2を見る)を除いて、NHC MUSTはダイレクトNBMAレベルの上のNHRPメッセージに給仕NHSと役立たれたNHCとの接続を送ります。
It may not be desirable to maintain semi-permanent NBMA level connectivity between the NHC and the NHS. In this case, when NBMA level connectivity is initially setup between the NHS and the NHC (as described in Section 5.2.4), the NBMA address of the NHS should be obtained through the NBMA level signaling technology. This address should be stored for future use in setting up subsequent NBMA level connections. A somewhat more information rich technique to obtain the address information (and more) of the serving NHS would be for the NHC to include the Responder Address extension (see Section 5.3.1) in the NHRP Registration Request and to store the information returned to the NHC in the Responder Address extension which is subsequently included in the NHRP Registration Reply. Note also that, in practice, a client's default router should also be its NHS; thus a client may be able to know the NBMA address of its NHS from the configuration which was already required for the client to be able to communicate. Further, as mentioned in Section 4, NHCs may be configured with the addressing information of one or more NHSs.
半永久的なNBMAがNHCとNHSの間の接続性を平らにすると主張するのは望ましくないかもしれません。 この場合NBMAの平らな接続性が初めはNHSとNHCの間でセットアップすること(セクション5.2.4で説明されるように)であるときに、技術を示すNBMAレベルを通してNHSのNBMAアドレスを得るべきです。 このアドレスはその後のNBMA平らな接続をセットアップすることにおける今後の使用のために格納されるべきです。 給仕NHSに関するアドレス情報(さらに)を得るいくらか多くの情報強者のテクニックは、NHCがNHRP Registration RequestにResponder Address拡張子(セクション5.3.1を見る)を含んで、次にNHRP Registration Replyに含まれているResponder Address拡張子でNHCに返された情報を格納するだろうことです。 また、また、クライアントのデフォルトルータが実際にはNHSであるべきであることに注意してください。 したがって、クライアントはクライアントが交信できるように既に必要であった構成からNHSのNBMAアドレスを知ることができるかもしれません。 さらに、NHCsはセクション4で言及されるように1NHSsに関するアドレス指定情報によって構成されるかもしれません。
4. Configuration
4. 構成
Next Hop Clients
次のホップクライアント
An NHC connected to an NBMA subnetwork MAY be configured with the
Protocol address(es) and NBMA address(es) of its NHS(s). The
NHS(s) will likely also represent the NHC's default or peer
NHS(s)のプロトコルアドレス(es)とNBMAアドレス(es)によってNBMAサブネットワークに接続されたNHCは構成されるかもしれません。 また、NHS(s)はおそらくNHCのデフォルトか同輩の代理をするでしょう。
Luciani, et. al. Standards Track [Page 10] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[10ページ]。
routers, so their NBMA addresses may be obtained from the NHC's
existing configuration. If the NHC is attached to several
subnetworks (including logical NBMA subnetworks), the NHC should
also be configured to receive routing information from its NHS(s)
and peer routers so that it can determine which internetwork layer
networks are reachable through which subnetworks.
ルータであり、したがって、NHCの既存の構成からそれらのNBMAアドレスを得るかもしれません。 また、NHCがいくつかのサブネットワークに取り付けられるなら(論理的なNBMAサブネットワークを含んでいて)、NHCは、どのインターネットワーク層のネットワークがどのサブネットワークを通して届いているかを決定できるようにNHS(s)と同輩ルータからルーティング情報を受け取るために構成されるべきです。
Next Hop Servers
次のホップサーバ
An NHS is configured with knowledge of its own internetwork layer
and NBMA addresses. An NHS MAY also be configured with a set of
internetwork layer address prefixes that correspond to the
internetwork layer addresses of the stations it serves. The NBMA
addresses of the stations served by the NHS may be learned via NHRP
Registration packets.
NHSはそれ自身のインターネットワーク層とNBMAアドレスに関する知識によって構成されます。 NHS MAY、また、それが役立つステーションのインターネットワーク層のアドレスに対応する1セットのインターネットワーク層のアドレス接頭語で、構成されてください。 NHSによって役立たれたステーションのNBMAアドレスはNHRP Registrationパケットを通して学習されるかもしれません。
If a served NHC is attached to several subnetworks, the
router/route-server coresident with the serving NHS may also need
to be configured to advertise routing information to such NHCs.
また、役立たれたNHCがいくつかのサブネットワークに取り付けられるなら、給仕NHSをもっているルートルータ/サーバコレジデントは、そのようなNHCsにルーティング情報の広告を出すために構成される必要があるかもしれません。
If an NHS acts as an egress router for stations connected to other
subnetworks than the NBMA subnetwork, the NHS must, in addition to
the above, be configured to exchange routing information between
the NBMA subnetwork and these other subnetworks.
ステーションへの出口ルータがNBMAサブネットワーク以外のサブネットワークに接続したのでNHSが行動するなら、上記に加えて、NBMAサブネットワークとこれらの他のサブネットワークの間でルーティング情報を交換するためにNHSを構成しなければなりません。
In all cases, routing information is exchanged using conventional
intra-domain and/or inter-domain routing protocols.
すべての場合では、従来のイントラドメイン、そして/または、相互ドメインルーティング・プロトコルを使用することでルーティング情報を交換します。
5. NHRP Packet Formats
5. NHRPパケット・フォーマット
This section describes the format of NHRP packets. In the following, unless otherwise stated explicitly, the unqualified term "request" refers generically to any of the NHRP packet types which are "requests". Further, unless otherwise stated explicitly, the unqualified term "reply" refers generically to any of the NHRP packet types which are "replies".
このセクションはNHRPパケットの形式について説明します。 以下では、別の方法で明らかに述べられない場合、「要求」という資格のない用語は一般的に「要求」であるNHRPパケットタイプのいずれにも言及します。 さらに、別の方法で明らかに述べられない場合、「回答」という資格のない用語は一般的に「回答」であるNHRPパケットタイプのいずれにも言及します。
An NHRP packet consists of a Fixed Part, a Mandatory Part, and an Extensions Part. The Fixed Part is common to all NHRP packet types. The Mandatory Part MUST be present, but varies depending on packet type. The Extensions Part also varies depending on packet type, and need not be present.
NHRPパケットはFixed Part、Mandatory Part、およびExtensions Partから成ります。 すべてのNHRPパケットタイプに、Fixed Partは一般的です。 Mandatory Partは存在していなければなりませんが、パケットタイプに頼っていて、異なります。 Extensions Partもパケットタイプに頼っていて、異なって、存在している必要はありません。
The length of the Fixed Part is fixed at 20 octets. The length of the Mandatory Part is determined by the contents of the extensions offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part length is equal to total packet length (ar$pktsz) minus 20 otherwise the mandatory part length is equal to ar$extoff minus 20. The length
Fixed Partの長さは20の八重奏のときに固定されています。 拡大のコンテンツで、分野(ar$「外-紳士」)を相殺しましたMandatory Partの長さが決定している。 ar$「外-紳士」=0×0であるなら、義務的な部分の長さは、20を引いてパケット長(ar$pktsz)を合計するために等しいです。そうでなければ、義務的な部分の長さは20を引いてar$「外-紳士」と等しいです。 長さ
Luciani, et. al. Standards Track [Page 11] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[11ページ]。
of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs may increase the size of an NHRP packet as a result of extension processing, but not beyond the offered maximum packet size of the NBMA network.
Extensions Partはar$「外-紳士」を引いてar$pktszによって含意されます。 NHSsは拡張処理の結果、NHRPパケットのサイズを増加させますが、NBMAネットワークの提供された最大のパケットサイズを超えて増加するかもしれないというわけではありません。
NHRP packets are actually members of a wider class of address mapping and management protocols being developed by the IETF. A specific encapsulation, based on the native formats used on the particular NBMA network over which NHRP is carried, indicates the generic IETF mapping and management protocol. For example, SMDS networks always use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet is preceded by the following LLC/SNAP encapsulation:
NHRPパケットは実際にIETFによって開発されるより広いクラスのアドレス・マッピングと管理プロトコルのメンバーです。 特定のNBMAネットワークで上NHRPが運ばれる使用されるネイティブの形式に基づく特定のカプセル化は一般的なIETFマッピングと管理プロトコルを示します。 例えば、SMDSネットワークはNBMA層[4]でいつもLLC/SNAPカプセル化を使用します、そして、以下のLLC/SNAPカプセル化はNHRPパケットに先行します:
[0xAA-AA-03] [0x00-00-5E] [0x00-03]
[0xAA-AA-03] [0×00 00-5E][0×00-03]
The first three octets are LLC, indicating that SNAP follows. The SNAP OUI portion is the IANA's OUI, and the SNAP PID portion identifies the mapping and management protocol. A field in the Fixed Header following the encapsulation indicates that it is NHRP.
SNAPが続くのを示して、最初の3つの八重奏がLLCです。 SNAP OUI部分はIANAのOUIです、そして、SNAP PID部分はマッピングと管理プロトコルを特定します。 カプセル化に続くFixed Headerの分野は、それがNHRPであることを示します。
ATM uses either LLC/SNAP encapsulation of each packet (including NHRP), or uses no encapsulation on VCs dedicated to a single protocol (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or identification of NHRP, using a NLPID of 0x0080 and the same SNAP contents as above (see [8], [9]).
ATMはそれぞれのパケット(NHRPを含んでいる)のLLC/SNAPカプセル化かVCsの上のどんなカプセル化もただ一つのプロトコルに捧げなかった用途のどちらかを使用します。([7])を見てください。 フレームRelayとX.25はともにNHRPのNLPID/SNAPカプセル化か識別を使用します、同じくらい上で0×0080と同じSNAPコンテンツのNLPIDを使用して。([8]([9]))を見てください。
Fields marked "unused" MUST be set to zero on transmission, and ignored on receipt.
「未使用であること」が示される分野を、トランスミッションのときにゼロに設定されて、領収書の上で無視しなければなりません。
Most packet types (ar$op.type) have both internetwork layer protocol-independent fields and protocol-specific fields. The protocol type/snap fields (ar$pro.type/snap) qualify the format of the protocol-specific fields.
ほとんどのパケットタイプ(ar$op.type)には、インターネットワーク層のプロトコル独立者分野とプロトコル特有の分野の両方があります。 プロトコルタイプ/スナップ分野(ar$pro.type/スナップ)はプロトコル特有の分野の形式に資格を与えます。
5.1 NHRP Fixed Header
5.1 ヘッダーに固定されたNHRP
The Fixed Part of the NHRP packet contains those elements of the NHRP packet which are always present and do not vary in size with the type of packet.
NHRPパケットのFixed Partはいつも存在していて、パケットのタイプに従って大小の差がないNHRPパケットのそれらの要素を含んでいます。
Luciani, et. al. Standards Track [Page 12] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[12ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$afn | ar$pro.type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap | ar$hopcnt | ar$pktsz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$chksum | ar$extoff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$op.version | ar$op.type | ar$shtl | ar$sstl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ar$afn| ar$pro.type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ar$pro.snap| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ar$pro.snap| ar$hopcnt| ar$pktsz| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ar$chksum| ar$「外-紳士」| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ar$op.version| ar$op.type| ar$shtl| ar$sstl| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$afn
Defines the type of "link layer" addresses being carried. This
number is taken from the 'address family number' list specified in
[6]. This field has implications to the coding of ar$shtl and
ar$sstl as described below.
「リンクレイヤ」のタイプが記述する運ばれるar$afn Defines。 この数は[6]で指定された'アドレスファミリーナンバ'リストから抜粋されます。 この分野は以下で説明されるようにar$shtlとar$sstlのコード化に意味を持っています。
ar$pro.type
field is a 16 bit unsigned integer representing the following
number space:
ar$pro.type分野は以下の数のスペースを表す16の噛み付いている符号のない整数です:
0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs.
0x0100 to 0x03FF Reserved for future use by the IETF.
0x0400 to 0x04FF Allocated for use by the ATM Forum.
0x0500 to 0x05FF Experimental/Local use.
0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes.
0×0000 同等なNLPIDsによって定義された0x00FFプロトコルに。 0×0100 IETFによる今後の使用のために0x03FF Reservedに。 0×0400 ATM Forumによる使用のために0x04FF Allocatedに。 0×0500 0x05FF Experimental/地方の使用に。 0×0600 同等なEthertypesによって定義された0xFFFFプロトコルに。
(based on the observations that valid Ethertypes are never smaller
than 0x600, and NLPIDs never larger than 0xFF.)
(観測に基づいて、その有効なEthertypesは0xFFより決して大きくない0×600、およびNLPIDsより決して小さくはありません。)
ar$pro.snap
When ar$pro.type has a value of 0x0080, a SNAP encoded extension is
being used to encode the protocol type. This snap extension is
placed in the ar$pro.snap field. This is termed the 'long form'
protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be
zero on transmit and ignored on receive. The ar$pro.type field
itself identifies the protocol being referred to. This is termed
the 'short form' protocol ID.
ar$pro.snap When ar$pro.typeは0×0080の値、SNAPをコード化させます。拡張子は、プロトコルタイプをコード化するのに使用されています。 この即座の拡大はar$pro.snap分野に置かれます。 これは'長いフォーム'プロトコルIDと呼ばれます。 伝わって、無視されて、ar$pro.snap分野がar$プロ!=0x0080であるならオンであるはずがない、オンである、受信してください。 ar$pro.type分野自体は示されるプロトコルを特定します。 これは'縮約形'プロトコルIDと呼ばれます。
In all cases, where a protocol has an assigned number in the
ar$pro.type space (excluding 0x0080) the short form MUST be used
when transmitting NHRP messages; i.e., if Ethertype or NLPID
codings exist then they are used on transmit rather than the
NHRPメッセージを送るとき、すべての場合では、縮約形を使用しなければなりません。(そこではプロトコルがar$pro.typeスペース(0×0080を除いた)に規定番号を持っています)。 すなわち、EthertypeかNLPIDコーディングが存在しているなら、それらが使用されるその時はむしろ伝わります。
Luciani, et. al. Standards Track [Page 13] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[13ページ]。
ethertype. If both Ethertype and NLPID codings exist then when
transmitting NHRP messages, the Ethertype coding MUST be used (this
is consistent with RFC 1483 coding). So, for example, the
following codings exist for IP:
ethertype。 NHRPメッセージを送るとき、EthertypeとNLPIDコーディングの両方が存在しているなら、Ethertypeコード化を使用しなければなりません(これは1483年のRFCコード化と一致しています)。 そのように、例えば、以下のコーディングはIPのために存在しています:
SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
NLPID: ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00
以下を折ってください。 ar$pro.typeは0×00-80、0×00 00-00-08-00のar$pro.snap=NLPIDと等しいです: ar$pro.typeは0×00CCと等しく、ar$pro.snapは0×00 00-00-00-00のEthertypeと等しいです: ar$pro.typeは0×08-00、0×00ar$pro.snap=00-00-00-00と等しいです。
and thus, since the Ethertype coding exists, it is used in
preference.
そして、その結果、Ethertypeコード化が存在しているので、それは好みに使用されます。
ar$hopcnt
The Hop count indicates the maximum number of NHSs that an NHRP
packet is allowed to traverse before being discarded. This field
is used in a similar fashion to the way that a TTL is used in an IP
packet and should be set accordingly. Each NHS decrements the TTL
as the NHRP packet transits the NHS on the way to the next hop
along the routed path to the destination. If an NHS receives an
NHRP packet which it would normally forward to a next hop and that
packet contains an ar$hopcnt set to zero then the NHS sends an
error indication message back to the source protocol address
stating that the hop count has been exceeded (see Section 5.2.7)
and the NHS drops the packet in error; however, an error
indication is never sent as a result of receiving an error
indication. When a responding NHS replies to an NHRP request, that
NHS places a value in ar$hopcnt as if it were sending a request of
its own.
Hopが数えるar$hopcntは捨てられる前にNHRPパケットが横断できるNHSsの最大数を示します。 この分野は同様にTTLがIPパケットで使用されて、それに従って、用意ができるべきである方法に使用されます。 NHRPパケットが目的地への発送された経路に沿った次のホップへの途中にNHSを通過するのに従って、各NHSはTTLを減少させます。 NHSが通常、それが次のホップに送るNHRPパケットを受けて、そのパケットがhopcntがゼロに設定したarドルを含んでいるなら、NHSはホップカウントが超えられていると述べるソースプロトコルアドレスに誤り表示メッセージを送り返します、そして、(セクション5.2.7を見てください)NHSはパケットを間違って落とします。 しかしながら、誤り表示を受けることの結果、誤り表示を決して送りません。 応じるNHSがNHRP要求に答えると、まるでそれ自身の要求を送るかのようにそのNHSはar$hopcntに値を置きます。
ar$pktsz
The total length of the NHRP packet, in octets (excluding link
layer encapsulation).
ar$は八重奏(リンクレイヤカプセル化を除いた)でNHRPパケットの全長をpktszします。
ar$chksum
The standard IP checksum over the entire NHRP packet starting at
the fixed header. If the packet is an odd number of bytes in
length then this calculation is performed as if a byte set to 0x00
is appended to the end of the packet.
固定ヘッダーで始まって、ar$は全体のNHRPパケットの上で標準のIPチェックサムをchksumします。 パケットが長さがバイトの奇数であるなら、この計算はまるでパケットの端まで0×00に設定された1バイトを追加するかのように実行されます。
ar$extoff
This field identifies the existence and location of NHRP
extensions. If this field is 0 then no extensions exist otherwise
this field represents the offset from the beginning of the NHRP
packet (i.e., starting from the ar$afn field) of the first
extension.
extoff Thisがさばくar$はNHRP拡張子の存在と位置を特定します。 この分野が0であるなら、拡大は全く存在していません。そうでなければ、この分野は最初の拡大のNHRPパケット(すなわち、ar$afn野原から始める)の始まりからオフセットを表します。
Luciani, et. al. Standards Track [Page 14] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[14ページ]。
ar$op.version
This field indicates what version of generic address mapping and
management protocol is represented by this message.
op.version Thisがさばくar$は、一般的なアドレス・マッピングと管理プロトコルのどんなバージョンがこのメッセージによって表されるかを示します。
0 MARS protocol [11].
1 NHRP as defined in this document.
0x02 - 0xEF Reserved for future use by the IETF.
0xF0 - 0xFE Allocated for use by the ATM Forum.
0xFF Experimental/Local use.
0 火星プロトコル[11]。 1 本書では定義されるNHRP。 0×02--IETFによる今後の使用のために0xEF Reserved。 0xF0--ATM Forumによる使用のために0xFE Allocated。 0xFF Experimental/地方の使用。
ar$op.type
When ar$op.version == 1, this is the NHRP packet type: NHRP
Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration
Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP
Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet
Types in the range 128 to 255 are reserved for research or use in
other protocol development and will be administered by IANA as
described in Section 9.
ar$、op.type When ar op.version=1ドル、これはNHRPパケットタイプです: NHRP解決要求(1)、NHRP解決回答(2)、NHRP登録要求(3)、NHRP登録回答(4)、NHRPパージ要求(5)、NHRPパージ回答(6)、またはNHRP誤り表示(7)。 範囲128〜255でのNHRPパケットTypesの使用は、他のプロトコル開発における研究か使用のために控えられて、セクション9で説明されるようにIANAによって管理されるでしょう。
ar$shtl
Type & length of source NBMA address interpreted in the context of
the 'address family number'[6] indicated by ar$afn. See below for
more details.
ar$afnによって示された'アドレスファミリーナンバ'[6]の文脈で解釈されたソースNBMAアドレスのar$shtl Typeと長さ。 その他の詳細に関して以下を見てください。
ar$sstl
Type & length of source NBMA subaddress interpreted in the context
of the 'address family number'[6] indicated by ar$afn. When an
NBMA technology has no concept of a subaddress, the subaddress
length is always coded ar$sstl = 0 and no storage is allocated for
the subaddress in the appropriate mandatory part. See below for
more details.
ar$afnによって示された'アドレスファミリーナンバ'[6]の文脈で解釈されたソースNBMA subaddressのar$sstl Typeと長さ。 NBMA技術に「副-アドレス」の概念が全くないとき、「副-アドレス」の長さはsstl=0ドルいつもコード化されたarです、そして、適切な義務的な部分の「副-アドレス」のために格納を全く割り当てません。 その他の詳細に関して以下を見てください。
Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr T/L) and subnetwork layer subaddresses type/length fields (e.g., ar$sstl, Cli SAddr T/L) are coded as follows:
サブネットワーク層のアドレスのタイプ/長さの分野(例えば、ar$shtl、Cli Addr T/L)とサブネットワーク層の「副-アドレス」のタイプ/長さの分野(例えば、ar$sstl、Cli SAddr T/L)は以下の通りコード化されます:
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| length |
+-+-+-+-+-+-+-+-+
7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ |0|x| 長さ| +-+-+-+-+-+-+-+-+
The most significant bit is reserved and MUST be set to zero. The second most significant bit (x) is a flag indicating whether the address being referred to is in:
最も重要なビットを予約されていて、ゼロに設定しなければなりません。 2番目の最上位ビット(x)は参照されるアドレスが以下にあるかを示す旗です。
- NSAP format (x = 0).
- Native E.164 format (x = 1).
- NSAPは(x=0)をフォーマットします。 - ネイティブのE.164は(x=1)をフォーマットします。
Luciani, et. al. Standards Track [Page 15] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[15ページ]。
For NBMA technologies that use neither NSAP nor E.164 format addresses, x = 0 SHALL be used to indicate the native form for the particular NBMA technology.
0NSAPもE.164形式アドレスも使用しないNBMA技術、x=SHALLに関しては、使用されて、特定のNBMA技術のためのネイティブの書式を示してください。
If the NBMA network is ATM and a subaddress (e.g., Source NBMA SubAddress, Client NBMA SubAddress) is to be included in any part of the NHRP packet then ar$afn MUST be set to 0x000F; further, the subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr T/L) and subnetwork layer subaddress type/length fields (e.g., ar$sstl, Cli SAddr T/L) MUST be coded as in [11]. If the NBMA network is ATM and no subaddress field is to be included in any part of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008 (E.164) accordingly.
NBMAネットワークがATMであり、「副-アドレス」(例えば、Source NBMA SubAddress、Client NBMA SubAddress)がNHRPパケットのどんな一部にも含まれるつもりであるなら、ar$afnは0x000Fに用意ができなければなりません。 さらに、サブネットワーク層のアドレスのタイプ/長さの分野(例えば、ar$shtl、Cli Addr T/L)とサブネットワークは[11]で分野(例えば、ar$sstl、Cli SAddr T/L)をコード化しなければならない「副-アドレス」のタイプ/長さを層にします。 どんな「副-アドレス」分野もNBMAネットワークがATMであり、NHRPパケットのどんな一部にも含まれないことであるなら、ar$afnはそれに従って、0×0003へのセット(NSAP)か0×0008であるかもしれません(E.164)。
The bottom 6 bits is an unsigned integer value indicating the length of the associated NBMA address in octets. If this value is zero the flag x is ignored.
6ビットの下部は八重奏における、関連NBMAアドレスの長さを示す符号のない整数値です。 この値がゼロであるなら、旗xは無視されます。
5.2.0 Mandatory Part
5.2.0 義務的な部分
The Mandatory Part of the NHRP packet contains the operation specific information (e.g., NHRP Resolution Request/Reply, etc.) and variable length data which is pertinent to the packet type.
NHRPパケットのMandatory Partは操作特殊情報(例えば、NHRP Resolution Request/回答など)とパケットタイプに、適切な可変長データを含んでいます。
5.2.0.1 Mandatory Part Format
5.2.0.1 義務的な部分形式
Sections 5.2.1 through 5.2.6 have a very similar mandatory part. This mandatory part includes a common header and zero or more Client Information Entries (CIEs). Section 5.2.7 has a different format which is specified in that section.
セクション5.2 .1〜5.2に、.6には、非常に同様の義務的な部分があります。 この義務的な部分は一般的なヘッダーとゼロか、より多くのClient情報Entries(CIEs)を含んでいます。 セクション5.2 .7 そのセクションで指定される異なった形式を持っています。
The common header looks like the following:
一般的なヘッダーは以下に似ています:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Protoレン| Dst Protoレン| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDを要求してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースNBMA Address(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースNBMA Subaddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースプロトコルAddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地プロトコルAddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Luciani, et. al. Standards Track [Page 16] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[16ページ]。
And the CIEs have the following format:
そして、CIEsには、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 接頭語の長さ| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マキシマム・トランスミッション・ユニット| 把持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cli Addr T/L| Cli SAddr T/L| Cli Protoレン| 好み| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントNBMA Address(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントNBMA Subaddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントプロトコルAddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ..................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 接頭語の長さ| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マキシマム・トランスミッション・ユニット| 把持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cli Addr T/L| Cli SAddr T/L| Cli Protoレン| 好み| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントNBMA Address(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントNBMA Subaddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントプロトコルAddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meanings of the fields are as follows:
分野の意味は以下の通りです:
Src Proto Len
This field holds the length in octets of the Source Protocol
Address.
レンThisがさばくSrcプロトはSourceプロトコルAddressの八重奏における長さを保持します。
Dst Proto Len
This field holds the length in octets of the Destination Protocol
Address.
レンThisがさばくDstプロトはDestinationプロトコルAddressの八重奏における長さを保持します。
Flags
These flags are specific to the given message type and they are
explained in each section.
与えられたメッセージタイプに、Theseが旗を揚げさせる旗は特定です、そして、それらは各セクションで説明されます。
Luciani, et. al. Standards Track [Page 17] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[17ページ]。
Request ID
A value which, when coupled with the address of the source,
provides a unique identifier for the information contained in a
"request" packet. This value is copied directly from an "request"
packet into the associated "reply". When a sender of a "request"
receives "reply", it will compare the Request ID and source address
information in the received "reply" against that found in its
outstanding "request" list. When a match is found then the
"request" is considered to be acknowledged.
ソースのアドレスに結びつけられると「要求」パケットに含まれた情報のためのユニークな識別子を提供するID A価値を要求してください。 この値は直接「要求」パケットから関連「回答」にコピーされます。 「要求」の送付者が「回答」を受けるとき、それは傑出している「要求」リストで見つけられたそれに対して容認された「回答」におけるRequest IDとソースアドレス情報を比較するでしょう。 マッチがその時見つけられるとき、「要求」が承認されると考えられます。
The value is taken from a 32 bit counter that is incremented each
time a new "request" is transmitted. The same value MUST be used
when resending a "request", i.e., when a "reply" has not been
received for a "request" and a retry is sent after an appropriate
interval.
32ビットの新しい「要求」が伝えられるたびに増加しているカウンタから値を取ります。 「要求」を再送するとき、同じ値を使用しなければなりません、すなわち、「要求」のために「回答」を受け取っていなくて、適切な間隔の後に再試行を送るとき。
It is RECOMMENDED that the initial value for this number be 0. A
node MAY reuse a sequence number if and only if the reuse of the
sequence number is not precluded by use of a particular method of
synchronization (e.g., as described in Appendix A).
この数のための初期の値が0であることはRECOMMENDEDです。 そして、ノードが一連番号を再利用するかもしれない、一連番号の再利用が同期の特定の方法の使用で排除されない場合にだけ(例えば、Appendix Aで説明されるように)。
The NBMA address/subaddress form specified below allows combined E.164/NSAPA form of NBMA addressing. For NBMA technologies without a subaddress concept, the subaddress field is always ZERO length and ar$sstl = 0.
以下で指定されたNBMAアドレス/「副-アドレス」フォームは結合したE.164/NSAPAフォームのNBMAアドレシングを許容します。 「副-アドレス」概念のないNBMA技術のために、「副-アドレス」分野は、sstl=0ドルいつもZEROの長さとarです。
Source NBMA Address
The Source NBMA address field is the address of the source station
which is sending the "request". If the field's length as specified
in ar$shtl is 0 then no storage is allocated for this address at
all.
Source NBMAアドレスがさばくソースNBMA Addressは「要求」を送る発信局のアドレスです。 ar$shtlの指定されるとしてのフィールドの長さが0であるなら、全くこのアドレスのために格納を全く割り当てません。
Source NBMA SubAddress
The Source NBMA subaddress field is the address of the source
station which is sending the "request". If the field's length as
specified in ar$sstl is 0 then no storage is allocated for this
address at all.
Source NBMA subaddressがさばくソースNBMA SubAddressは「要求」を送る発信局のアドレスです。 ar$sstlの指定されるとしてのフィールドの長さが0であるなら、全くこのアドレスのために格納を全く割り当てません。
For those NBMA technologies which have a notion of "Calling Party Addresses", the Source NBMA Addresses above are the addresses used when signaling for an SVC.
「パーティをアドレスと呼びます」という考えを持っているそれらのNBMA技術のために、上のSource NBMA AddressesはSVCのために合図するとき使用されるアドレスです。
"Requests" and "indications" follow the routed path from Source Protocol Address to the Destination Protocol Address. "Replies", on the other hand, follow the routed path from the Destination Protocol Address back to the Source Protocol Address with the following
「要求」と「指摘」は発送されたSourceプロトコルAddressからDestinationプロトコルAddressまでの経路に続きます。 他方では、「回答」は以下で発送されたDestinationプロトコルAddressからSourceプロトコルAddressまでの経路に続きます。
Luciani, et. al. Standards Track [Page 18] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[18ページ]。
exceptions: in the case of a NHRP Registration Reply and in the case of an NHC initiated NHRP Purge Request, the packet is always returned via a direct VC (see Sections 5.2.4 and 5.2.5).
例外: セクション5.2.4と5.2を見てください。NHRP Registration Replyの場合とNHCの場合では、ダイレクトVCを通して開始しているNHRP Purge Request、パケットをいつも返す、(.5)。
Source Protocol Address
This is the protocol address of the station which is sending the
"request". This is also the protocol address of the station toward
which a "reply" packet is sent.
ソースプロトコルAddress Thisは「要求」を送るステーションのプロトコルアドレスです。 また、これは「回答」パケットが送られるステーションのプロトコルアドレスです。
Destination Protocol Address
This is the protocol address of the station toward which a
"request" packet is sent.
目的地プロトコルAddress Thisは「要求」パケットが送られるステーションのプロトコルアドレスです。
Code
This field is message specific. See the relevant message sections
below. In general, this field is a NAK code; i.e., when the field
is 0 in a reply then the packet is acknowledging a request and if
it contains any other value the packet contains a negative
acknowledgment.
Thisがさばくコードはメッセージ特有です。 下の関連メッセージ部を見てください。 一般に、この分野はNAKコードです。 すなわち、その時分野が回答で0であるときに、パケットは要求を承諾しています、そして、他の値を含んでいるなら、パケットは否定応答を含んでいます。
Prefix Length
This field is message specific. See the relevant message sections
below. In general, however, this fields is used to indicate that
the information carried in an NHRP message pertains to an
equivalence class of internetwork layer addresses rather than just
a single internetwork layer address specified. All internetwork
layer addresses that match the first "Prefix Length" bit positions
for the specific internetwork layer address are included in the
equivalence class. If this field is set to 0x00 then this field
MUST be ignored and no equivalence information is assumed (note
that 0x00 is thus equivalent to 0xFF).
接頭語Length This分野はメッセージ特有です。 下の関連メッセージ部を見てください。 一般に、しかしながら、この分野は、NHRPメッセージで運ばれた情報がまさしくアドレスが指定したただ一つのインターネットワーク層よりむしろインターネットワーク層のアドレスの同値類に関係するのを示すのに使用されます。 特定のインターネットワーク層のアドレスのための最初の「接頭語の長さ」ビット位置に合っているすべてのインターネットワーク層のアドレスが同値類に含まれています。 この分野が0×00に設定されるなら、この分野を無視しなければなりません、そして、等価性情報は全く想定されません(その結果、0×00が0xFFに同等であることに注意してください)。
Maximum Transmission Unit
This field gives the maximum transmission unit for the relevant
client station. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA.
最大のTransmission Unit This分野は関連クライアントステーションにマキシマム・トランスミッション・ユニットを与えます。 この値が0であるなら、デフォルトMTUが使用されているか、または与えられたNBMAに、そのような交渉が可能であるなら、シグナリングで交渉されたMTUは使用されています。
Holding Time
The Holding Time field specifies the number of seconds for which
the Next Hop NBMA information specified in the CIE is considered to
be valid. Cached information SHALL be discarded when the holding
time expires. This field must be set to 0 on a NAK.
TimeをHolding Timeがさばく持っていると、CIEで指定されたNext Hop NBMA情報が有効であると考えられる秒数は指定されます。 把持時間が期限が切れるとき、捨てられて、情報SHALLをキャッシュしました。 NAKにこの分野を0に設定しなければなりません。
Luciani, et. al. Standards Track [Page 19] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[19ページ]。
Cli Addr T/L
Type & length of next hop NBMA address specified in the CIE. This
field is interpreted in the context of the 'address family
number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).
次のホップNBMAアドレスのCli Addr T/L Typeと長さはCIEで指定しました。 この分野はar$afn(ATMのための例えば、ar$afn=0×0003)によって示された'アドレスファミリーナンバ'[6]の文脈で解釈されます。
Cli SAddr T/L
Type & length of next hop NBMA subaddress specified in the CIE.
This field is interpreted in the context of the 'address family
number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes
the address an E.164 and the subaddress an ATM Forum NSAP address).
When an NBMA technology has no concept of a subaddress, the
subaddress is always null with a length of 0. When the address
length is specified as 0 no storage is allocated for the address.
次のホップNBMA subaddressのCli SAddr T/L Typeと長さはCIEで指定しました。 この分野はar$afnによって示された'アドレスファミリーナンバ'[6]の文脈で解釈されます(ATMのための例えば、ar$afn=0×0015は、アドレスをE.164にして、「副-アドレス」をATM Forum NSAPアドレスにします)。 NBMA技術に「副-アドレス」の概念が全くないとき、「副-アドレス」はいつも0の長さのヌルです。 0としてアドレスの長さを指定するとき、アドレスのために格納を全く割り当てません。
Cli Proto Len
This field holds the length in octets of the Client Protocol
Address specified in the CIE.
レンThisがさばくCliプロトはCIEで指定されたClientプロトコルAddressの八重奏における長さを保持します。
Preference
This field specifies the preference for use of the specific CIE
relative to other CIEs. Higher values indicate higher preference.
Action taken when multiple CIEs have equal or highest preference
value is a local matter.
Thisがさばく好みは他のCIEsに比例して特定のCIEの使用のための好みを指定します。 より高い値は、より高い好みを示します。 複数のCIEsに等しいか最も高い好みの値があると取られた行動は地域にかかわる事柄です。
Client NBMA Address
This is the client's NBMA address.
クライアントNBMA Address ThisはクライアントのNBMAアドレスです。
Client NBMA SubAddress
This is the client's NBMA subaddress.
クライアントNBMA SubAddress ThisはクライアントのNBMA subaddressです。
Client Protocol Address
This is the client's internetworking layer address specified.
クライアントプロトコルAddress Thisはアドレスが指定したクライアントのインターネットワーキング層です。
Note that an NHS may cache source address binding information from an NHRP Resolution Request if and only if the conditions described in Section 6.2 are met for the NHS. In all other cases, source address binding information appearing in an NHRP message MUST NOT be cached.
そして、NHSがNHRP Resolution Requestからのソースアドレス結合情報をキャッシュするかもしれないことに注意してください、セクション6.2で説明された条件がNHSのために満たされる場合にだけ。 他のすべての場合では、NHRPメッセージに現れるソースアドレス結合情報をキャッシュしてはいけません。
5.2.1 NHRP Resolution Request
5.2.1 NHRP解決要求
The NHRP Resolution Request packet has a Type code of 1. Its mandatory part is coded as described in Section 5.2.0.1 and the message specific meanings of the fields are as follows:
NHRP Resolution Requestパケットには、1のTypeコードがあります。 セクション5.2.0で説明されて、.1と分野のメッセージの特定の意味は以下の通りときに、義務的な部分はコード化されます:
Flags - The flags field is coded as follows:
旗--旗の分野は以下の通りコード化されます:
Luciani, et. al. Standards Track [Page 20] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[20ページ]。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Q|A|D|U|S| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Set if the station sending the NHRP Resolution Request is a
router; clear if the it is a host.
QはNHRP Resolution Requestを送るステーションがルータであるならセットしました。 明確である、それはホストです。
A
This bit is set in a NHRP Resolution Request if only
authoritative next hop information is desired and is clear
otherwise. See the NHRP Resolution Reply section below for
further details on the "A" bit and its usage.
必要であり、そうでなければ、次の正式のホップ情報だけが明確であるなら、ThisビットはNHRP Resolution Requestに設定されます。 さらに詳しい明細については「A」ビットの上の下のNHRP Resolution Reply部とその用法を見てください。
D
Unused (clear on transmit)
D未使用です。(クリアする、伝える、)
U
This is the Uniqueness bit. This bit aids in duplicate address
detection. When this bit is set in an NHRP Resolution Request
and one or more entries exist in the NHS cache which meet the
requirements of the NHRP Resolution Request then only the CIE in
the NHS's cache with this bit set will be returned. Note that
even if this bit was set at registration time, there may still be
multiple CIEs that might fulfill the NHRP Resolution Request
because an entire subnet can be registered through use of the
Prefix Length in the CIE and the address of interest might be
within such a subnet. If the "uniqueness" bit is set and the
responding NHS has one or more cache entries which match the
request but no such cache entry has the "uniqueness" bit set,
then the NHRP Resolution Reply returns with a NAK code of "13 -
Binding Exists But Is Not Unique" and no CIE is included. If a
client wishes to receive non- unique Next Hop Entries, then
the client must have the "uniqueness" bit set to zero in its NHRP
Resolution Request. Note that when this bit is set in an NHRP
Registration Request, only a single CIE may be specified in the
NHRP Registration Request and that CIE must have the Prefix
Length field set to 0xFF.
U、これはUniquenessビットです。 これは写しアドレス検出における援助に噛み付きました。 このビットがNHRP Resolution Requestに設定されて、1つ以上のエントリーがNHSキャッシュで存在するとき、このビットがセットした状態でどれがNHSのキャッシュで次に、NHRP Resolution Request CIEだけに関する必要条件を満たすか返すでしょう。 このビットが登録時に設定されたとしても、CIEにおけるPrefix Lengthの使用で全体のサブネットを登録できて、そのようなサブネットの中に興味深いアドレスがあるかもしれないのでNHRP Resolution Requestを実現させるかもしれない複数のCIEsがまだあるかもしれないことに注意してください。 「ユニークさ」ビットが設定されて、応じているNHSには要求に合っている1つ以上のキャッシュエントリーがありますが、どんなそのようなキャッシュエントリーでも「ユニークさ」ビットを設定しないなら、NHRP Resolution Replyは「13--結合は、存在していますが、ユニークでないこと」のNAKコードとともに帰ります、そして、どんなCIEも含まれていません。 クライアントが非ユニークなNext Hop Entriesを受け取りたいなら、クライアントはNHRP Resolution Requestに「ユニークさ」ビットをゼロに設定させなければなりません。 このビットがNHRP Registration Requestに設定されるとき、NHRP Registration Requestで独身のCIEだけを指定してもよくて、CIEがPrefix Length分野を0xFFに設定させなければならないことに注意してください。
S
Set if the binding between the Source Protocol Address and the
Source NBMA information in the NHRP Resolution Request is
guaranteed to be stable and accurate (e.g., these addresses are
those of an ingress router which is connected to an ethernet stub
network or the NHC is an NBMA attached host).
SourceプロトコルAddressとNHRP Resolution RequestのSource NBMA情報の間の結合が安定していて正確になるように保証されるなら(例えば、これらのアドレスはイーサネットスタッブネットワークに接続されるイングレスルータのものであるかNHCはNBMAの付属ホストです)、Sはセットしました。
Luciani, et. al. Standards Track [Page 21] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[21ページ]。
Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP Resolution Request. If one is specified then that entry carries the pertinent information for the client sourcing the NHRP Resolution Request. Usage of the CIE in the NHRP Resolution Request is described below:
セクション5.2を見てください。ゼロか1CIEs、(.0 .1は)NHRP Resolution Requestで指定されてもよいです。 1つが指定されるなら、そのエントリーはNHRP Resolution Requestの出典を明示するクライアントのために適切な情報を運びます。 NHRP Resolution RequestのCIEの使用法は以下で説明されます:
Prefix Length
If a CIE is specified in the NHRP Resolution Request then the
Prefix Length field may be used to qualify the widest acceptable
prefix which may be used to satisfy the NHRP Resolution Request.
In the case of NHRP Resolution Request/Reply, the Prefix Length
specifies the equivalence class of addresses which match the
first "Prefix Length" bit positions of the Destination Protocol
Address. If the "U" bit is set in the common header then this
field MUST be set to 0xFF.
接頭語Length If a CIEはNHRP Resolution Requestで指定されて、次に、Prefix Length分野は、使用されるかもしれない中で最も広い許容できる接頭語がNHRP Resolution Requestを満たすのに資格を与えるのに使用されるかもしれません。 NHRP Resolution Request/回答の場合では、Prefix LengthはDestinationプロトコルAddressの最初の「接頭語の長さ」ビット位置に合っているアドレスの同値類を指定します。 「U」ビットが一般的なヘッダーに設定されるなら、この分野を0xFFに設定しなければなりません。
Maximum Transmission Unit
This field gives the maximum transmission unit for the source
station. A possible use of this field in the NHRP Resolution
Request packet is for the NHRP Resolution Requester to ask for a
target MTU.
最大のTransmission Unit This分野はマキシマム・トランスミッション・ユニットを発信局に与えます。 NHRP Resolution Requestパケットにおけるこの分野の活用可能性はNHRP Resolution Requesterが目標MTUを求めることです。
Holding Time
The Holding Time specified in the one CIE permitted to be
included in an NHRP Resolution Request is the amount of time
which the source address binding information in the NHRP
Resolution Request is permitted to cached by transit and
responding NHSs. Note that this field may only have a non-zero
value if the S bit is set.
Holding TimeがNHRP Resolution Requestに含まれていることが許可された1CIEで指定したTimeを持つのは、ソースアドレスがNHRP Resolution Requestの情報を縛って、トランジットでキャッシュされて、NHSsを反応させるのに受入れられる時間です。 Sビットが設定される場合にだけこの分野には非ゼロ値があるかもしれないことに注意してください。
All other fields in the CIE MUST be ignored and SHOULD be set to 0.
CIE MUSTの他のすべての分野、無視されてください、SHOULD、0に設定されてください。
The Destination Protocol Address in the common header of the Mandatory Part of this message contains the protocol address of the station for which resolution is desired. An NHC MUST send the NHRP Resolution Request directly to one of its serving NHSs (see Section 3 for more information).
このメッセージのMandatory Partの一般的なヘッダーのDestinationプロトコルAddressは解決が望まれているステーションのプロトコルアドレスを含んでいます。 NHC MUSTは直接NHSsに役立つ1つにNHRP Resolution Requestを送ります(詳しい情報に関してセクション3を見てください)。
5.2.2 NHRP Resolution Reply
5.2.2 NHRP解決回答
The NHRP Resolution Reply packet has a Type code of 2. CIEs correspond to Next Hop Entries in an NHS's cache which match the criteria in the NHRP Resolution Request. Its mandatory part is coded as described in Section 5.2.0.1. The message specific meanings of the fields are as follows:
NHRP Resolution Replyパケットには、2のTypeコードがあります。 CIEsはNHSのキャッシュにおけるNHRP Resolution Requestで評価基準に合っているNext Hop Entriesに対応しています。 義務的な部分はセクション5.2.0で.1に説明されるようにコード化されます。 分野のメッセージの特定の意味は以下の通りです:
Flags - The flags field is coded as follows:
旗--旗の分野は以下の通りコード化されます:
Luciani, et. al. Standards Track [Page 22] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[22ページ]。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Q|A|D|U|S| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Copied from the NHRP Resolution Request. Set if the NHRP
Resolution Requester is a router; clear if it is a host.
QはNHRP解決要求からコピーされました。 NHRP Resolution Requesterがルータであるなら、セットしてください。 それがホストであるなら、クリアしてください。
A
Set if the next hop CIE in the NHRP Resolution Reply is
authoritative; clear if the NHRP Resolution Reply is non-
authoritative.
SetはNHRP Resolution Replyの次のホップCIEであるなら正式です。 NHRP Resolution Replyが非正式であるなら、クリアしてください。
When an NHS receives a NHRP Resolution Request for authoritative
information for which it is the authoritative source, it MUST
respond with a NHRP Resolution Reply containing all and only
those next hop CIEs which are contained in the NHS's cache which
both match the criteria of the NHRP Resolution Request and are
authoritative cache entries. An NHS is an authoritative source
for a NHRP Resolution Request if the information in the NHS's
cache matches the NHRP Resolution Request criteria and that
information was obtained through a NHRP Registration Request or
through synchronization with an NHS which obtained this
information through a NHRP Registration Request. An
authoritative cache entry is one which is obtained through a NHRP
Registration Request or through synchronization with an NHS which
obtained this information through a NHRP Registration Request.
NHSがそれが権威筋である信頼できる情報のためにNHRP Resolution Requestを受けて、NHRP Resolution Replyがすべてを含んでいて応じなければならなくて、次のものだけがNHSのキャッシュに含まれているCIEsを飛び越すと(ともにNHRP Resolution Requestの評価基準を合わせて、正式のキャッシュエントリーです)。 NHSのキャッシュにおける情報がNHRP Resolution Request評価基準に合っているなら、NHSはNHRP Resolution Requestのための権威筋です、そして、NHRP Registration Requestを通して、または、NHSとの同期を通してどれがNHRP Registration Requestを通してこの情報を得たかというその情報を得ました。 正式のキャッシュエントリーはNHRP Registration Requestを通してこの情報を得たNHSがあるNHRP Registration Requestを通して、または、同期を通して得られるものです。
An NHS obtains non-authoritative CIEs through promiscuous
listening to NHRP packets other than NHRP Registrations which are
directed at it. A NHRP Resolution Request which indicates a
request for non-authoritative information should cause a NHRP
Resolution Reply which contains all entries in the replying NHS's
cache (i.e., both authoritative and non-authoritative) which
match the criteria specified in the request.
NHSはそれが向けられるNHRP Registrations以外のNHRPパケットの無差別な聴取で非正式のCIEsを入手します。 非信頼できる情報に関する要求が返答しているNHSのキャッシュ(すなわち、ともに正式の、そして、非正式の)における評価基準に合っているすべてのエントリーを含むNHRP Resolution Replyを引き起こすべきであるのを示すNHRP Resolution Requestは要求で指定しました。
D
Set if the association between destination and the associate next
hop information included in all CIEs of the NHRP Resolution Reply
is guaranteed to be stable for the lifetime of the information
(the holding time). This is the case if the Next Hop protocol
address in a CIE identifies the destination (though it may be
different in value than the Destination address if the
destination system has multiple addresses) or if the destination
is not connected directly to the NBMA subnetwork but the egress
router to that destination is guaranteed to be stable (such as
NHRP Resolution ReplyのすべてのCIEsに次のホップ情報を含んでいる目的地と仲間との仲間が情報(把持時間)の生涯安定しているために保証されるなら、Dはセットしました。 CIEのNext Hopプロトコルアドレスが目的地を特定するか(目的地システムに複数のアドレスがあるなら、Destinationアドレスと値において異なるかもしれませんが)、目的地が直接NBMAサブネットワークにつなげられませんが、またはその目的地への出口ルータが安定しているために保証されるならこれがそうである、(
Luciani, et. al. Standards Track [Page 23] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[23ページ]。
when the destination is immediately adjacent to the egress router
through a non-NBMA interface).
目的地がすぐに非NBMAインタフェースを通した出口ルータに隣接している、)
U
This is the Uniqueness bit. See the NHRP Resolution Request
section above for details. When this bit is set, only one CIE is
included since only one unique binding should exist in an NHS's
cache.
U、これはUniquenessビットです。 詳細において、NHRP Resolution Request部が上であることを見てください。 このビットが設定されるとき、1つのユニークな結合だけがNHSのキャッシュで存在するべきであるので、1CIEだけが含まれています。
S
Copied from NHRP Resolution Request message.
SはNHRP Resolution Requestメッセージからコピーされました。
One or more CIEs are specified in the NHRP Resolution Reply. Each CIE contains NHRP next hop information which the responding NHS has cached and which matches the parameters specified in the NHRP Resolution Request. If no match is found by the NHS issuing the NHRP Resolution Reply then a single CIE is enclosed with the a CIE Code set appropriately (see below) and all other fields MUST be ignored and SHOULD be set to 0. In order to facilitate the use of NHRP by minimal client implementations, the first CIE MUST contain the next hop with the highest preference value so that such an implementation need parse only a single CIE.
1CIEsがNHRP Resolution Replyで指定されます。 各CIEは応じているNHSがどれをキャッシュするか、そして、パラメタがNHRP Resolution Requestでどのマッチを指定したかというNHRPホップの次情報を含んでいます。 無視されて、マッチがNHSによって見つけられるノー、とSHOULDであるなら、0に設定されてください。 最初のCIE MUSTがNHRPの最小量のクライアント実現による使用を容易にするために最も高い好みの値がある次のホップを含んでいるので、そのような実現の必要性は独身のCIEだけを分析します。
Code
If this field is set to zero then this packet contains a
positively acknowledged NHRP Resolution Reply. If this field
contains any other value then this message contains an NHRP
Resolution Reply NAK which means that an appropriate
internetworking layer to NBMA address binding was not available
in the responding NHS's cache. If NHRP Resolution Reply contains
a Client Information Entry with a NAK Code other than 0 then it
MUST NOT contain any other CIE. Currently defined NAK Codes are
as follows:
Ifをコード化してください。この分野はその時このパケットのゼロを合わせるセットが明確に承認されたNHRP Resolution Replyを含んでいるということです。 この分野が他の値を含んでいるなら、このメッセージはNBMAアドレス結合への適切なインターネットワーキング層が応じているNHSのキャッシュで利用可能でなかったことを意味するNHRP Resolution Reply NAKを含んでいます。 NHRP Resolution Replyが0以外のNAK CodeとClient情報Entryを含んでいるなら、それはいかなる他のCIEも含んではいけません。 現在定義されたNAK Codesは以下の通りです:
4 - Administratively Prohibited
4--行政上禁止されています。
An NHS may refuse an NHRP Resolution Request attempt for
administrative reasons (due to policy constraints or routing
state). If so, the NHS MUST send an NHRP Resolution Reply
which contains a NAK code of 4.
NHSは管理理由のためのNHRP Resolution Request試み(方針規制かルーティング状態による)を拒否するかもしれません。 そうだとすれば、NHS MUSTは4のNAKコードを含むNHRP Resolution Replyを送ります。
5 - Insufficient Resources
5--不十分なリソース
If an NHS cannot serve a station due to a lack of resources
(e.g., can't store sufficient information to send a purge if
routing changes), the NHS MUST reply with a NAKed NHRP
Resolution Reply which contains a NAK code of 5.
NHSが財源不足(例えば、変化を発送するなら、パージを送るために十分な情報を格納できない)のためステーションに役立つことができないなら、NHS MUSTは5のNAKコードを含むNAKed NHRP Resolution Replyと共に返答します。
Luciani, et. al. Standards Track [Page 24] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[24ページ]。
12 - No Internetworking Layer Address to NBMA Address Binding
Exists
12--NBMAアドレス結合へのインターネットワーキング層のアドレスは全く存在していません。
This code states that there were absolutely no internetworking
layer address to NBMA address bindings found in the responding
NHS's cache.
このコードは、応じているNHSのキャッシュで見つけられたNBMAアドレス結合へのインターネットワーキング層のアドレスが全く絶対にないと述べます。
13 - Binding Exists But Is Not Unique
13--結合は、存在していますが、ユニークではありません。
This code states that there were one or more internetworking
layer address to NBMA address bindings found in the responding
NHS's cache, however none of them had the uniqueness bit set.
このコードはしかしながら、応じているNHSのキャッシュで見つけられたNBMAアドレス結合への1つ以上のインターネットワーキング層のアドレスがあって、それらのいずれでもユニークさのビットを設定しなかったと述べます。
Prefix Length
In the case of NHRP Resolution Reply, the Prefix Length specifies
the equivalence class of addresses which match the first "Prefix
Length" bit positions of the Destination Protocol Address.
NHRP Resolution Replyに関するケース、接頭語Length In Prefix LengthはDestinationプロトコルAddressの最初の「接頭語の長さ」ビット位置に合っているアドレスの同値類を指定します。
Holding Time
The Holding Time specified in a CIE of an NHRP Resolution Reply
is the amount of time remaining before the expiration of the
client information which is cached at the replying NHS. It is
not the value which was registered by the client.
Time Holding TimeがNHRP Resolution ReplyのCIEで指定されるままにするのは、返答しているNHSでキャッシュされるクライアント情報の満了の前に残っている時間です。 それはクライアントによって示された値ではありません。
The remainder of the fields for the CIE for each next hop are
filled out as they were defined when the next hop was registered
with the responding NHS (or one of the responding NHS's
synchronized servers) via the NHRP Registration Request.
それらが定義されて、いつ、次のホップがあったかが応じているNHSとともに記名したという(応じているNHSのものの1つはサーバを同期させました)ことであったので、次の各ホップのためのCIEのための分野の残りはNHRP Registration Requestを通して書き込まれます。
Load-splitting may be performed when more than one Client Information Entry is returned to a requester when equal preference values are specified. Also, the alternative addresses may be used in case of connectivity failure in the NBMA subnetwork (such as a failed call attempt in connection-oriented NBMA subnetworks).
等しい好みの値を指定するとき、1Client情報Entryをリクエスタに返すとき、負荷分かれることを実行するかもしれません。 また、代替アドレスはNBMAサブネットワーク(接続指向のNBMAサブネットワークの失敗した呼び出し試みなどの)での接続性失敗の場合に使用されるかもしれません。
Any extensions present in the NHRP Resolution Request packet MUST be present in the NHRP Resolution Reply even if the extension is non- Compulsory.
NHRP Resolution Requestパケットの現在のどんな拡大も拡大が非コンパルソリーであってもNHRP Resolution Replyに存在していなければなりません。
If an unsolicited NHRP Resolution Reply packet is received, an Error Indication of type Invalid NHRP Resolution Reply Received SHOULD be sent in response.
パケットは求められていないNHRP Resolution Replyであるなら受け取られています、タイプInvalid NHRP Resolution Reply Received SHOULDのError Indication。送られた応答になってください。
When an NHS that serves a given NHC receives an NHRP Resolution Reply destined for that NHC then the NHS must MUST send the NHRP Resolution Reply directly to the NHC (see Section 3).
与えられたNHCに役立つNHSがいつ次に、NHC NHSが受けなければならない運命づけられたNHRP Resolution Replyを受けるかが直接NHCにNHRP Resolution Replyを送らなければなりません(セクション3を見てください)。
Luciani, et. al. Standards Track [Page 25] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[25ページ]。
5.2.3 NHRP Registration Request
5.2.3 NHRP登録要求
The NHRP Registration Request is sent from a station to an NHS to notify the NHS of the station's NBMA information. It has a Type code of 3. Each CIE corresponds to Next Hop information which is to be cached at an NHS. The mandatory part of an NHRP Registration Request is coded as described in Section 5.2.0.1. The message specific meanings of the fields are as follows:
ステーションのNBMA情報についてNHSに通知するためにステーションからNHSにNHRP Registration Requestを送ります。 それには、3のTypeコードがあります。 各CIEはNHSでキャッシュされることであるNext Hop情報に対応しています。 NHRP Registration Requestの義務的な部分はセクション5.2.0で.1に説明されるようにコード化されます。 分野のメッセージの特定の意味は以下の通りです:
Flags - The flags field is coded as follows:
旗--旗の分野は以下の通りコード化されます:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U
This is the Uniqueness bit. When set in an NHRP Registration
Request, this bit indicates that the registration of the protocol
address is unique within the confines of the set of synchronized
NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC
cache. Any attempt to register a binding between the protocol
address and an NBMA address when this bit is set MUST be rejected
with a Code of "14 - Unique Internetworking Layer Address Already
Registered" if the replying NHS already has a cache entry for the
protocol address and the cache entry has the "uniqueness" bit
set. A registration of a CIE's information is rejected when the
CIE is returned with the Code field set to anything other than
0x00. See the description of the uniqueness bit in NHRP
Resolution Request section above for further details. When this
bit is set only, only one CIE MAY be included in the NHRP
Registration Request.
U、これはUniquenessビットです。 NHRP Registration Requestに設定されると、このビットは、プロトコルアドレスの登録が連動しているNHSsのセットの境界の中でユニークであることを示します。 NHS/NHCキャッシュにこの「ユニークさ」資格を与える人を格納しなければなりません。 返答しているNHSにプロトコルアドレスとキャッシュエントリーのためのキャッシュエントリーが既にあるなら、プロトコルアドレスとNBMAアドレスの間の結合を登録するこのビットが「層のアドレスが既に登録した14--ユニークなインターネットワーキング」のCodeと共にセットを拒絶しなければならないということであることのどんな試みも「ユニークさ」ビットを設定させます。 Code分野セットでCIEを何にでも返すとき、0×00を除いて、CIEの情報の登録を拒絶します。 NHRP Resolution Request部でのユニークさのビットの記述が上であることをさらに詳しい明細については見てください。 このビットが1CIE MAYだけを設定することであるときには、NHRP Registration Requestで含められてください。
Request ID
The request ID has the same meaning as described in Section
5.2.0.1. However, the request ID for NHRP Registrations which is
maintained at each client MUST be kept in non-volatile memory so
that when a client crashes and reregisters there will be no
inconsistency in the NHS's database. In order to reduce the
overhead associated with updating non-volatile memory, the actual
updating need not be done with every increment of the Request ID
but could be done, for example, every 50 or 100 increments. In
this scenario, when a client crashes and reregisters it knows to
add 100 to the value of the Request ID in the non-volatile memory
before using the Request ID for subsequent registrations.
ID要求IDにはセクション5.2.0における説明されるのと同じ意味が.1にあるよう要求してください。 しかしながら、クライアントがいつクラッシュするか、そして、そこの「再-レジスタ」がNHSのデータベースで少しも矛盾にならないように、非揮発性メモリーに各クライアントで維持されるNHRP Registrationsのための要求IDを保たなければなりません。 関連している非揮発性メモリーであるアップデートでオーバーヘッドを下げるために、実際のアップデートは、Request IDのあらゆる増分でしなければならないというわけではありませんが、例えば50か100の増分毎ができました。 このシナリオ、クライアントがいつクラッシュするか、そして、および「再-レジスタ」では、それはその後の登録証明書にRequest IDを使用する前に非揮発性メモリーのRequest IDの値に100を加えるのを知っています。
Luciani, et. al. Standards Track [Page 26] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[26ページ]。
One or more CIEs are specified in the NHRP Registration Request. Each CIE contains next hop information which a client is attempting to register with its servers. Generally, all fields in CIEs enclosed in NHRP Registration Requests are coded as described in Section 5.2.0.1. However, if a station is only registering itself with the NHRP Registration Request then it MAY code the Cli Addr T/L, Cli SAddr T/L, and Cli Proto Len as zero which signifies that the client address information is to be taken from the source information in the common header (see Section 5.2.0.1). Below, further clarification is given for some fields in a CIE in the context of a NHRP Registration Request.
1CIEsがNHRP Registration Requestで指定されます。 各CIEはクライアントがサーバに登録するのを試みている次のホップ情報を含んでいます。 一般に、NHRP Registration Requestsに同封されたCIEsのすべての分野がセクション5.2.0で.1に説明されるようにコード化されます。 セクション5.2を見てください。しかしながら、ステーションがNHRP Registration Requestにそれ自体を登録しているだけであるならクライアントアドレス情報が一般的なヘッダーでソース情報から取ることであることを意味するゼロとしてCli Addr T/L、Cli SAddr T/L、およびCli Protoレンをコード化するかもしれない、(.0 .1)。 以下では、NHRP Registration Requestの文脈のCIEのいくつかの分野にさらなる明確化を与えます。
Code
This field is set to 0x00 in NHRP Registration Requests.
ThisがさばくコードはNHRP Registration Requestsの0×00に設定されます。
Prefix Length
接頭語の長さ
This field may be used in a NHRP Registration Request to register
equivalence information for the Client Protocol Address specified
in the CIE of an NHRP Registration Request In the case of NHRP
Registration Request, the Prefix Length specifies the equivalence
class of addresses which match the first "Prefix Length" bit
positions of the Client Protocol Address. If the "U" bit is set
in the common header then this field MUST be set to 0xFF.
この分野はClientのためのプロトコルAddressがNHRP Registration Request InのCIEでNHRP Registration Requestに関するケースを指定したという等価性情報を登録するのにNHRP Registration Requestで使用されるかもしれなくて、Prefix LengthはClientプロトコルAddressの最初の「接頭語の長さ」ビット位置に合っているアドレスの同値類を指定します。 「U」ビットが一般的なヘッダーに設定されるなら、この分野を0xFFに設定しなければなりません。
The NHRP Registration Request is used to register an NHC's NHRP information with its NHSs. If an NHC is configured with the protocol address of a serving NHS then the NHC may place the NHS's protocol address in the Destination Protocol Address field of the NHRP Registration Request common header otherwise the NHC must place its own protocol address in the Destination Protocol Address field.
NHRP Registration Requestは、NHCのNHRP情報をNHSsに登録するのに使用されます。 NHCが給仕NHSのプロトコルアドレスによって構成されるなら、NHCはNHRP Registration Requestの一般的なヘッダーのDestinationプロトコルAddress分野にNHSのプロトコルアドレスを置くかもしれません。そうでなければ、NHCはDestinationプロトコルAddress分野にそれ自身のプロトコルアドレスを置かなければなりません。
When an NHS receives an NHRP Registration Request which has the Destination Protocol Address field set to an address which belongs to a LIS/LAG for which the NHS is serving then if the Destination Protocol Address field is equal to the Source Protocol Address field (which would happen if the NHC put its protocol address in the Destination Protocol Address) or the Destination Protocol Address field is equal to the protocol address of the NHS then the NHS processes the NHRP Registration Request after doing appropriate error checking (including any applicable policy checking).
NHSがDestinationプロトコルAddress分野がSourceプロトコルAddress分野と等しいならNHSがその時役立つLIS/LAGに属すアドレスにDestinationプロトコルAddress分野を設定させるNHRP Registration Requestを受けるとき; または、(NHCがDestinationプロトコルAddressにプロトコルアドレスを入れるなら、起こるでしょう)、DestinationプロトコルAddress分野はNHSのプロトコルアドレスと等しく、適切な誤りの照合をした後に、次に、NHSはNHRP Registration Requestを処理します(どんな適切な方針の照合も含んでいて)。
When an NHS receives an NHRP Registration Request which has the Destination Protocol Address field set to an address which does not belong to a LIS/LAG for which the NHS is serving then the NHS forwards the packet down the routed path toward the appropriate LIS/LAG.
NHSがDestinationプロトコルAddress分野をアドレスに設定させるNHRP Registration Requestを受けるとき、どれがNHSがその時NHSに役立つLIS/LAGに属さないかが適切なLIS/LAGに向かった発送された経路の下側にパケットを送ります。
Luciani, et. al. Standards Track [Page 27] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[27ページ]。
When an NHS receives an NHRP Registration Request which has the Destination Protocol Address field set to an address which belongs to a LIS/LAG for which the NHS is serving then if the Destination Protocol Address field does not equal the Source Protocol Address field and the Destination Protocol Address field does not equal the protocol address of the NHS then the NHS forwards the message to the appropriate NHS within the LIS/LAG as specified by Destination Protocol Address field.
NHSがNHSがその時役立つLIS/LAGに属すアドレスにDestinationプロトコルAddress分野を設定させるNHRP Registration Requestを受けるとき、DestinationプロトコルAddress分野がSourceプロトコルAddress分野と等しくなく、またDestinationプロトコルAddress分野がNHSのプロトコルアドレスと等しくないなら、NHSは指定されるとしてのAddressがさばくDestinationプロトコルによるLIS/LAGの中の適切なNHSにメッセージを転送します。
It is possible that a misconfigured station will attempt to register with the wrong NHS (i.e., one that cannot serve it due to policy constraints or routing state). If this is the case, the NHS MUST reply with a NAK-ed Registration Reply of type Can't Serve This Address.
misconfiguredステーションが、間違ったNHS(すなわち、方針規制かルーティング状態のためそれに役立つことができないもの)とともに記名するのを試みるのは、可能です。 これがそうであるなら、NHS MUSTはServe This Addressではなく、タイプCanのNAK-教育Registration Replyと共に返答します。
If an NHS cannot serve a station due to a lack of resources, the NHS MUST reply with a NAK-ed Registration Reply of type Registration Overflow.
NHSが財源不足のためステーションに役立つことができないなら、NHS MUSTはタイプRegistration OverflowのNAK-教育Registration Replyと共に返答します。
In order to keep the registration entry from being discarded, the station MUST re-send the NHRP Registration Request packet often enough to refresh the registration, even in the face of occasional packet loss. It is recommended that the NHRP Registration Request packet be sent at an interval equal to one-third of the Holding Time specified therein.
登録エントリーが捨てられるのを妨げるために、ステーションは登録をリフレッシュできるくらいのしばしばNHRP Registration Requestパケットを再送しなければなりません、時々のパケット損失に直面してさえ。 そこに指定されたHolding Timeの1/3と等しい間隔で、NHRP Registration Requestパケットを送るのはお勧めです。
5.2.4 NHRP Registration Reply
5.2.4 NHRP登録回答
The NHRP Registration Reply is sent by an NHS to a client in response to that client's NHRP Registration Request. If the Code field of a CIE in the NHRP Registration Reply has anything other than zero in it then the NHRP Registration Reply is a NAK otherwise the reply is an ACK. The NHRP Registration Reply has a Type code of 4.
NHRP Registration ReplyはNHSによってそのクライアントのNHRP Registration Requestに対応してクライアントに送られます。 NHRP Registration ReplyのCIEのCode分野にそれのゼロ以外の何かがあるなら、NHRP Registration ReplyはNAKです。そうでなければ、回答はACKです。 NHRP Registration Replyには、4のTypeコードがあります。
An NHRP Registration Reply is formed from an NHRP Registration Request by changing the type code to 4, updating the CIE Code field, and filling in the appropriate extensions if they exist. The message specific meanings of the fields are as follows:
CIE Code分野をアップデートして、存在しているなら適切な拡大に記入して、NHRP Registration Replyは、NHRP Registration Requestからタイプコードを4に変えることによって、形成されます。 分野のメッセージの特定の意味は以下の通りです:
Attempts to register the information in the CIEs of an NHRP Registration Request may fail for various reasons. If this is the case then each failed attempt to register the information in a CIE of an NHRP Registration Request is logged in the associated NHRP Registration Reply by setting the CIE Code field to the appropriate error code as shown below:
NHRP Registration RequestのCIEsの情報を登録する試みは様々な理由で失敗するかもしれません。 これがそうであるなら、NHRP Registration RequestのCIEの情報を登録する各未遂はログインされて、CIE Codeを設定するのによる関連NHRP Registration Replyが以下に示される適切なエラーコードとして以下をさばくということです。
Luciani, et. al. Standards Track [Page 28] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[28ページ]。
CIE Code
CIEコード
0 - Successful Registration
0--うまくいっている登録
The information in the CIE was successfully registered with the
NHS.
CIEの情報は首尾よくNHSに登録されました。
4 - Administratively Prohibited
4--行政上禁止されています。
An NHS may refuse an NHRP Registration Request attempt for
administrative reasons (due to policy constraints or routing
state). If so, the NHS MUST send an NHRP Registration Reply
which contains a NAK code of 4.
NHSは管理理由のためのNHRP Registration Request試み(方針規制かルーティング状態による)を拒否するかもしれません。 そうだとすれば、NHS MUSTは4のNAKコードを含むNHRP Registration Replyを送ります。
5 - Insufficient Resources
5--不十分なリソース
If an NHS cannot serve a station due to a lack of resources,
the NHS MUST reply with a NAKed NHRP Registration Reply which
contains a NAK code of 5.
NHSが財源不足のためステーションに役立つことができないなら、NHS MUSTは5のNAKコードを含むNAKed NHRP Registration Replyと共に返答します。
14 - Unique Internetworking Layer Address Already Registered
If a client tries to register a protocol address to NBMA
address binding with the uniqueness bit on and the protocol
address already exists in the NHS's cache then if that cache
entry also has the uniqueness bit on then this NAK Code is
returned in the CIE in the NHRP Registration Reply.
14--また、そのキャッシュエントリーにユニークさのビットがこのNAK CodeがNHRP Registration ReplyのCIEで返されるその時あるなら、クライアントがユニークさがあるNBMAアドレス結合へのプロトコルアドレスがかみついたレジスタに試みるユニークなInternetworking Layer Address Already Registered Ifとプロトコルアドレスはその時、NHSのキャッシュで既に存在します。
Due to the possible existence of asymmetric routing, an NHRP Registration Reply may not be able to merely follow the routed path back to the source protocol address specified in the common header of the NHRP Registration Reply. As a result, there MUST exist a direct NBMA level connection between the NHC and its NHS on which to send the NHRP Registration Reply before NHRP Registration Reply may be returned to the NHC. If such a connection does not exist then the NHS must setup such a connection to the NHC by using the source NBMA information supplied in the common header of the NHRP Registration Request.
非対称のルーティングの可能な存在のため、NHRP Registration Replyは単にNHRP Registration Replyの一般的なヘッダーで指定されたソースプロトコルアドレスに発送された経路に続いて戻すことができないかもしれません。 その結果、NHCとそのNHSとのNHRP Registration ReplyをNHCに返すかもしれない前にNHRP Registration Replyを送るダイレクトNBMA平らな接続は存在しなければなりません。 そのような接続が存在していないなら、NHSは、NHRP Registration Requestの一般的なヘッダーで提供されたソースNBMA情報を使用することによって、そのような接続をNHCにセットアップしなければなりません。
5.2.5 NHRP Purge Request
5.2.5 NHRPパージ要求
The NHRP Purge Request packet is sent in order to invalidate cached information in a station. The NHRP Purge Request packet has a type code of 5. The mandatory part of an NHRP Purge Request is coded as described in Section 5.2.0.1. The message specific meanings of the fields are as follows:
ステーションでキャッシュされた情報を無効にするためにNHRP Purge Requestパケットを送ります。 NHRP Purge Requestパケットには、5のタイプコードがあります。 NHRP Purge Requestの義務的な部分はセクション5.2.0で.1に説明されるようにコード化されます。 分野のメッセージの特定の意味は以下の通りです:
Flags - The flags field is coded as follows:
旗--旗の分野は以下の通りコード化されます:
Luciani, et. al. Standards Track [Page 29] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[29ページ]。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N
When set, this bit tells the receiver of the NHRP Purge Request
that the requester does not expect to receive an NHRP Purge
Reply. If an unsolicited NHRP Purge Reply is received by a
station where that station is identified in the Source Protocol
Address of the packet then that packet must be ignored.
設定されたいつ、このビットは、Nが、NHRP Purge Replyを受け取ると予想しないとリクエスタがするNHRP Purge Requestの受信機を言うか。 求められていないNHRP Purge ReplyがそのステーションがパケットのSourceプロトコルAddressで特定されるステーションによって受け取られるなら、そのパケットを無視しなければなりません。
One or more CIEs are specified in the NHRP Purge Request. Each CIE contains next hop information which is to be purged from an NHS/NHC cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests are coded as described in Section 5.2.0.1. Below, further clarification is given for some fields in a CIE in the context of a NHRP Purge Request.
1CIEsがNHRP Purge Requestで指定されます。 各CIEはNHS/NHCキャッシュが追放されることである次のホップ情報を含んでいます。 一般に、NHRP Purge Requestsに同封されたCIEsのすべての分野がセクション5.2.0で.1に説明されるようにコード化されます。 以下では、NHRP Purge Requestの文脈のCIEのいくつかの分野にさらなる明確化を与えます。
Code
This field is set to 0x00 in NHRP Purge Requests.
ThisがさばくコードはNHRP Purge Requestsの0×00に設定されます。
Prefix Length
接頭語の長さ
In the case of NHRP Purge Requests, the Prefix Length specifies
the equivalence class of addresses which match the first "Prefix
Length" bit positions of the Client Protocol Address specified in
the CIE. All next hop information which contains a protocol
address which matches an element of this equivalence class is to
be purged from the receivers cache.
NHRP Purge Requestsの場合では、Prefix LengthはCIEで指定されたClientプロトコルAddressの最初の「接頭語の長さ」ビット位置に合っているアドレスの同値類を指定します。 この同値類の要素に合っているプロトコルアドレスを含む次のホップ情報は受信機キャッシュが追放されることです。
The Maximum Transmission Unit and Preference fields of the CIE are
coded as zero. The Holding Time should be coded as zero but there
may be some utility in supplying a "short" holding time to be
applied to the matching next hop information before that
information would be purged; this usage is for further study. The
Client Protocol Address field and the Cli Proto Len field MUST be
filled in. The Client Protocol Address is filled in with the
protocol address to be purged from the receiving station's cache
while the Cli Proto Len is set the length of the purged client's
protocol address. All remaining fields in the CIE MAY be set to
zero although the client NBMA information (and associated length
fields) MAY be specified to narrow the scope of the NHRP Purge
Request if requester desires. However, the receiver of an NHRP
Purge Request may choose to ignore the Client NBMA information if
it is supplied.
CIEのMaximum Transmission UnitとPreference分野はゼロとしてコード化されます。 Holding Timeはゼロとしてコード化されるべきですが、その情報が掃除される前に次の合っているホップ情報に適用されるべき「短い」把持時間を供給するのにおいて何らかのユーティリティがあるかもしれません。 さらなる研究にはこの用法があります。 ClientプロトコルAddress分野とCliプロトレン分野に記入しなければなりません。 ClientプロトコルAddressはプロトコルアドレスで記入されて、受入れステーションのキャッシュはCli Protoレンが掃除されたクライアントのプロトコルアドレスの長さのセットである間、追放されます。 残りがCIE MAYでさばくのは、クライアントNBMA情報(そして、関連長さの分野)がリクエスタ願望であるならNHRP Purge Requestの範囲を狭くするために指定されるかもしれませんが、ゼロにセットすることです。 しかしながら、それを供給するなら、NHRP Purge Requestの受信機は、Client NBMA情報を無視するのを選ぶかもしれません。
Luciani, et. al. Standards Track [Page 30] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[30ページ]。
An NHRP Purge Request packet is sent from an NHS to a station to cause it to delete previously cached information. This is done when the information may be no longer valid (typically when the NHS has previously provided next hop information for a station that is not directly connected to the NBMA subnetwork, and the egress point to that station may have changed).
以前にキャッシュされた情報を削除することを引き起こすためにNHRP Purge RequestパケットをNHSからステーションに送ります。 情報がもう有効でないときに(通常、NHSは以前にいつ直接NBMAサブネットワークにつなげられないステーションに次のホップ情報を提供しましたか、そして、そのステーションへのポイントが変えたかもしれない出口)、これをします。
An NHRP Purge Request packet may also be sent from an NHC to an NHS with which the NHC had previously registered. This allows for an NHC to invalidate its registration with NHRP before it would otherwise expire via the holding timer. If an NHC does not have knowledge of a protocol address of a serving NHS then the NHC must place its own protocol address in the Destination Protocol Address field and forward the packet along the routed path. Otherwise, the NHC must place the protocol address of a serving NHS in this field.
また、NHCからNHCが以前に登録したNHSにNHRP Purge Requestパケットを送るかもしれません。 そうでなければ、把持タイマを通して期限が切れる前にこれは、NHCがNHRPとの登録を無効にするのを許容します。 NHCに給仕NHSのプロトコルアドレスに関する知識がないなら、NHCはDestinationプロトコルAddress分野にそれ自身のプロトコルアドレスを置いて、発送された経路に沿ってパケットを送らなければなりません。 さもなければ、NHCは給仕NHSのプロトコルアドレスをこの分野に置かなければなりません。
Serving NHSs may need to send one or more new NHRP Purge Requests as a result of receiving a purge from one of their served NHCs since the NHS may have previously responded to NHRP Resolution Requests for that NHC's NBMA information. These purges are "new" in that they are sourced by the NHS and not the NHC; that is, for each NHC that previously sent a NHRP Resolution Request for the purged NHC NBMA information, an NHRP Purge Request is sent which contains the Source Protocol/NBMA Addresses of the NHS and the Destination Protocol Address of the NHC which previously sent an NHRP Resolution Request prior to the purge.
NHSsに役立つのは、NHSが以前にそのNHCのNBMA情報のためにNHRP Resolution Requestsに応じたかもしれないので彼らの役立たれたNHCsの1つからパージを受けることの結果、1新しいNHRP Purge Requestsを送る必要があるかもしれません。 それらがNHCではなく、NHSによって出典を明示されるので、これらのパージは「新しいです」。 すなわち、以前に掃除されたNHC NBMA情報のためにNHRP Resolution Requestを送った各NHCに関しては、NHSのSourceプロトコル/NBMA Addressesとパージの前に以前にNHRP Resolution Requestを送ったNHCのDestinationプロトコルAddressを含むNHRP Purge Requestを送ります。
The station sending the NHRP Purge Request MAY periodically retransmit the NHRP Purge Request until either NHRP Purge Request is acknowledged or until the holding time of the information being purged has expired. Retransmission strategies for NHRP Purge Requests are a local matter.
NHRP Purge Requestが承認されるか、または掃除される情報の把持時間が期限が切れるまで、NHRP Purge Requestを送るステーションはNHRP Purge Requestを定期的に再送するかもしれません。 NHRP Purge RequestsのためのRetransmission戦略は地域にかかわる事柄です。
When a station receives an NHRP Purge Request, it MUST discard any previously cached information that matches the information in the CIEs.
ステーションがNHRP Purge Requestを受けるとき、それはCIEsの情報に合っているどんな以前にキャッシュされた情報も捨てなければなりません。
An NHRP Purge Reply MUST be returned for the NHRP Purge Request even if the station does not have a matching cache entry assuming that the "N" bit is off in the NHRP Purge Request.
ステーションに「N」ビットがNHRPパージ要求でオフであると仮定する合っているキャッシュエントリーがなくても、NHRP Purge RequestのためにNHRP Purge Replyを返さなければなりません。
If the station wishes to reestablish communication with the destination shortly after receiving an NHRP Purge Request, it should make an authoritative NHRP Resolution Request in order to avoid any stale cache entries that might be present in intermediate NHSs (See section 6.2.2.). It is recommended that authoritative NHRP Resolution Requests be made for the duration of the holding time of the old information.
NHRP Purge Requestを受けたすぐ後にステーションが目的地とのコミュニケーションを回復させたいなら、それは、中間的NHSsでどんな存在するかもしれない聞き古したキャッシュエントリーも避けるために正式のNHRP Resolution Requestを作るべきです(.2にセクション6.2を見てください)。 正式のNHRP Resolution Requestsが旧情報の把持時間の持続時間のために作られているのは、お勧めです。
Luciani, et. al. Standards Track [Page 31] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[31ページ]。
5.2.6 NHRP Purge Reply
5.2.6 NHRPパージ回答
The NHRP Purge Reply packet is sent in order to assure the sender of an NHRP Purge Request that all cached information of the specified type has been purged from the station sending the reply. The NHRP Purge Reply has a type code of 6.
指定されたタイプのすべてのキャッシュされた情報が回答を送りながらステーションから追放されたことをNHRP Purge Requestの送付者に知らせるためにNHRP Purge Replyパケットを送ります。 NHRP Purge Replyには、6のタイプコードがあります。
An NHRP Purge Reply is formed from an NHRP Purge Request by merely changing the type code in the request to 6. The packet is then returned to the requester after filling in the appropriate extensions if they exist.
NHRP Purge Replyは、NHRP Purge Requestから単に要求におけるタイプコードを6に変えることによって、形成されます。 そして、存在しているなら適切な拡大に記入した後に、パケットをリクエスタに返します。
5.2.7 NHRP Error Indication
5.2.7 NHRP誤り表示
The NHRP Error Indication is used to convey error indications to the sender of an NHRP packet. It has a type code of 7. The Mandatory Part has the following format:
NHRP Error Indicationは、NHRPパケットの送付者に誤り指摘を伝えるのに使用されます。 それには、7のタイプコードがあります。 Mandatory Partには、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of NHRP Packet in error (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Protoレン| Dst Protoレン| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| 誤りは相殺されました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースNBMA Address(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースNBMA Subaddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースプロトコルAddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地プロトコルAddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 間違いNHRP Packet(可変長)のコンテンツ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len
This field holds the length in octets of the Source Protocol
Address.
レンThisがさばくSrcプロトはSourceプロトコルAddressの八重奏における長さを保持します。
Dst Proto Len
This field holds the length in octets of the Destination Protocol
Address.
レンThisがさばくDstプロトはDestinationプロトコルAddressの八重奏における長さを保持します。
Luciani, et. al. Standards Track [Page 32] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[32ページ]。
Error Code
An error code indicating the type of error detected, chosen from
the following list:
以下のリストから検出されて、選ばれた誤りのタイプを示す誤りCode Anエラーコード:
1 - Unrecognized Extension
1--認識されていない拡大
When the Compulsory bit of an extension in NHRP packet is set,
the NHRP packet cannot be processed unless the extension has
been processed. The responder MUST return an NHRP Error
Indication of type Unrecognized Extension if it is incapable of
processing the extension. However, if a transit NHS (one which
is not going to generate a reply) detects an unrecognized
extension, it SHALL ignore the extension.
NHRPパケットの拡大のコンパルソリービットが設定されるとき、拡大が処理されていない場合、NHRPパケットを処理できません。 拡大を処理できないなら、応答者はタイプUnrecognized ExtensionのNHRP Error Indicationを返さなければなりません。 しかしながら、トランジットであるなら、NHS(回答を発生させないもの)は認識されていない拡大を検出します、それ。SHALLは拡大を無視します。
3 - NHRP Loop Detected
3--検出されたNHRP輪
A Loop Detected error is generated when it is determined that
an NHRP packet is being forwarded in a loop.
輪でNHRPパケットを進めているのが決定しているとき、Loop Detected誤りは発生します。
6 - Protocol Address Unreachable
6--アドレスについて議定書の中で述べてください、手の届かなさ
This error occurs when a packet it moving along the routed path
and it reaches a point such that the protocol address of
interest is not reachable.
パケットであるときに、この誤りが発生する、それ、発送された経路とそれに沿って動くのがポイントに達するので、興味深いプロトコルアドレスは届いていません。
7 - Protocol Error
7--プロトコル誤り
A generic packet processing error has occurred (e.g., invalid
version number, invalid protocol type, failed checksum, etc.)
一般的なパケット整理過程の誤差は起こりました。(例えば、無効のバージョン番号、無効のプロトコルタイプ、失敗したチェックサムなど)
8 - NHRP SDU Size Exceeded
8--超えられていたNHRP SDUサイズ
If the SDU size of the NHRP packet exceeds the MTU size of the
NBMA network then this error is returned.
NHRPパケットのSDUサイズがNBMAネットワークのMTUサイズを超えているなら、この誤りは返されます。
9 - Invalid Extension
9--無効の拡大
If an NHS finds an extension in a packet which is inappropriate
for the packet type, an error is sent back to the sender with
Invalid Extension as the code.
NHSがパケットタイプに、不適当なパケットで拡大を見つけるなら、誤りはコードとしてのInvalid Extensionと共に送付者に送り返されます。
10 - Invalid NHRP Resolution Reply Received
10--無効のNHRP解決回答は受信されました。
If a client receives a NHRP Resolution Reply for a Next Hop
Resolution Request which it believes it did not make then an
error packet is sent to the station making the reply with an
error code of Invalid Reply Received.
クライアントがそれが作らなかったと信じているNext Hop Resolution RequestのためにNHRP Resolution Replyを受け取るなら、Invalid Reply Receivedのエラーコードで回答をするステーションに誤りパケットを送ります。
Luciani, et. al. Standards Track [Page 33] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[33ページ]。
11 - Authentication Failure
11--認証失敗
If a received packet fails an authentication test then this
error is returned.
容認されたパケットが認証テストに失敗するなら、この誤りは返されます。
15 - Hop Count Exceeded
15--超えられていたホップカウント
The hop count which was specified in the Fixed Header of an
NHRP message has been exceeded.
NHRPメッセージのFixed Headerで指定されたホップカウントは超えられています。
Error Offset
The offset in octets into the original NHRP packet in which an
error was detected. This offset is calculated starting from the
NHRP Fixed Header.
誤りOffset、誤りが検出されたオリジナルのNHRPパケットへの八重奏におけるオフセット。 NHRP Fixed Headerから始めて、このオフセットは計算されます。
Source NBMA Address
The Source NBMA address field is the address of the station which
observed the error.
Source NBMAアドレスがさばくソースNBMA Addressは誤りを観測したステーションのアドレスです。
Source NBMA SubAddress
The Source NBMA subaddress field is the address of the station
which observed the error. If the field's length as specified in
ar$sstl is 0 then no storage is allocated for this address at all.
Source NBMA subaddressがさばくソースNBMA SubAddressは誤りを観測したステーションのアドレスです。 ar$sstlの指定されるとしてのフィールドの長さが0であるなら、全くこのアドレスのために格納を全く割り当てません。
Source Protocol Address
This is the protocol address of the station which issued the Error
packet.
ソースプロトコルAddress ThisはErrorパケットを発行したステーションのプロトコルアドレスです。
Destination Protocol Address
This is the protocol address of the station which sent the packet
which was found to be in error.
目的地プロトコルAddress Thisは間違っているのがわかったパケットを送ったステーションのプロトコルアドレスです。
An NHRP Error Indication packet SHALL NEVER be generated in response to another NHRP Error Indication packet. When an NHRP Error Indication packet is generated, the offending NHRP packet SHALL be discarded. In no case should more than one NHRP Error Indication packet be generated for a single NHRP packet.
NHRP Error IndicationパケットSHALL NEVER、別のNHRP Error Indicationパケットに対応して、発生してください。 NHRP Error Indicationであるときに、パケットは発生して、怒っているNHRPパケットはSHALLです。捨てられます。 1つ以上のNHRP Error Indicationパケットは単一のNHRPパケットのために決して、発生するべきではありません。
If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA and Source Protocol address fields of a transiting NHRP Error Indication packet then the NHS will quietly drop the packet and do nothing (this scenario would occur when the NHRP Error Indication packet was itself in a loop).
NHSがトランジットのNHRP Error IndicationパケットのSource NBMAとSourceプロトコルアドレス・フィールドでそれ自身のプロトコルとNBMA Addressesを見ると、NHSは静かにパケットを落として、何もしないでしょう(NHRP Error Indicationパケットが輪にそれ自体であったとき、このシナリオは起こるでしょう)。
Note that no extensions may be added to an NHRP Error Indication.
拡大が全くNHRP Error Indicationに加えられないかもしれないことに注意してください。
Luciani, et. al. Standards Track [Page 34] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[34ページ]。
5.3 Extensions Part
5.3の拡大が離れています。
The Extensions Part, if present, carries one or more extensions in
{Type, Length, Value} triplets.
存在しているなら、Extensions Partはタイプ、Length、Valueで1つ以上の拡大を運びます。三つ子。
Extensions have the following format:
拡大には、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|u| タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C
"Compulsory." If clear, and the NHS does not recognize the type
code, the extension may safely be ignored. If set, and the NHS
does not recognize the type code, the NHRP "request" is considered
to be in error. (See below for details.)
C「コンパルソリー。」 クリアしてください。そうすれば、NHSがタイプコードを認識しないなら、拡大は安全に無視されるかもしれません。 セットしてください。そうすれば、NHSがタイプコードを認識しないなら、NHRP「要求」が間違っていると考えられます。 (詳細に関して以下を見てください。)
u
Unused and must be set to zero.
そして、u Unused、ゼロに設定しなければなりません。
Type
The extension type code (see below). The extension type is not
qualified by the Compulsory bit, but is orthogonal to it.
拡大タイプコードをタイプしてください(以下を見てください)。 拡大タイプは、コンパルソリービットによって資格がありませんが、それと直交しています。
Length
The length in octets of the value (not including the Type and
Length fields; a null extension will have only an extension header
and a length of zero).
長さ、価値(TypeとLength分野; ヌル拡大を含まないのにおいて、拡張ヘッダーとゼロの長さしかない)の八重奏における長さ。
When extensions exist, the extensions list is terminated by the Null TLV, having Type = 0 and Length = 0.
拡大が存在するとき、拡大リストはNull TLVによって終えられて、Typeに0とLength=0と等しくさせます。
Extensions may occur in any order, but any particular extension type may occur only once in an NHRP packet unless explicitly stated to the contrary in the extensions definition. For example, the vendor- private extension may occur multiple times in a packet in order to allow for extensions which do not share the same vendor ID to be represented. It is RECOMMENDED that a given vendor include no more than one Vendor Private Extension.
拡大は順不同に起こるかもしれませんが、拡大定義で明らかにそれと反対に述べられない場合、どんな特定の拡大タイプもNHRPパケットに一度だけ起こるかもしれません。 例えば、業者の個人的な拡大は、同じ業者IDを共有しない拡大が表されるのを許容するためにパケットに複数の回起こるかもしれません。 与えられた業者が1Vendor兵士のExtensionを入れるのは、RECOMMENDEDです。
An NHS MUST NOT change the order of extensions. That is, the order of extensions placed in an NHRP packet by an NHC (or by an NHS when an NHS sources a packet) MUST be preserved as the packet moves between NHSs. Minimal NHC implementations MUST only recognize, but
NHS MUST NOTは拡大の注文を変えます。 NHSsの間のパケット移動としてすなわち、NHC(NHSであるときに、NHSはパケットの出典を明示する)によってNHRPパケットに置かれた拡大の注文を保存しなければなりません。 しかし、最小量のNHC実現は認識するだけでよいです。
Luciani, et. al. Standards Track [Page 35] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[35ページ]。
not necessarily parse, the Vendor Private extension and the End Of Extensions extension. Extensions are only present in a "reply" if they were present in the corresponding "request" with the exception of Vendor Private extensions. The previous statement is not intended to preclude the creation of NHS-only extensions which might be added to and removed from NHRP packets by the same NHS; such extensions MUST not be propagated to NHCs.
必ずない、分析してください、Vendor兵士の拡張子とEnd Of Extensions拡張子。 Vendor兵士の拡張子を除いて、それらが対応する「要求」に存在していたなら、拡大は単に「回答」で存在しています。 前言がNHSだけ拡張子の創造を排除することを意図しません(パケットは、同じNHSによって加えられて、NHRPから移されるかもしれません)。 そのような拡大をNHCsに伝播してはいけません。
The Compulsory bit provides for a means to add to the extension set. If the bit is set in an extension then the station responding to the NHRP message which contains that extension MUST be able to understand the extension (in this case, the station responding to the message is the station that would issue an NHRP reply in response to a NHRP request). As a result, the responder MUST return an NHRP Error Indication of type Unrecognized Extension. If the Compulsory bit is clear then the extension can be safely ignored; however, if an ignored extension is in a "request" then it MUST be returned, unchanged, in the corresponding "reply" packet type.
コンパルソリービットは拡大セットに加える手段に備えます。 ビットが拡大で設定されるなら、その拡大を含むNHRPメッセージに応じるステーションは拡大を理解できなければなりません(この場合、メッセージに応じるステーションはNHRP要求に対応してNHRP回答を発行するステーションです)。 その結果、応答者はタイプUnrecognized ExtensionのNHRP Error Indicationを返さなければなりません。 コンパルソリービットが明確であるなら、安全に拡大を無視できます。 しかしながら、無視された拡大が「要求」にあるなら、それを返さなければなりません、変わりがありません、対応する「回答」パケットタイプで。
If a transit NHS (one which is not going to generate a "reply") detects an unrecognized extension, it SHALL ignore the extension. If the Compulsory bit is set, the transit NHS MUST NOT cache the information contained in the packet and MUST NOT identify itself as an egress router (in the Forward Record or Reverse Record extensions). Effectively, this means, if a transit NHS encounters an extension which it cannot process and which has the Compulsory bit set then that NHS MUST NOT participate in any way in the protocol exchange other than acting as a forwarding agent.
NHS(「回答」を発生させないもの)はトランジットであるなら認識されていない拡大を検出します、それ。SHALLは拡大を無視します。 コンパルソリービットが設定されるなら、トランジットNHS MUST NOTは、パケットに含まれた情報をキャッシュして、それ自体が出口ルータであると認識してはいけません(Forward RecordかReverse Record拡張子で)。 これは、事実上、NHSがトランジットであるならそれが処理できないで、コンパルソリービットが、その時NHS MUST NOTが何らかの方法で小口運送業者として務めるのを除いたプロトコル交換に参加するように設定する拡大に遭遇することを意味します。
The NHRP extension Type space is subdivided to encourage use outside the IETF.
NHRP拡大Typeスペースは、IETFの外で使用を奨励するために分筆されます。
0x0000 - 0x0FFF Reserved for NHRP.
0x1000 - 0x11FF Allocated to the ATM Forum.
0x1200 - 0x37FF Reserved for the IETF.
0x3800 - 0x3FFF Experimental use.
0×0000--NHRPのために予約された0x0FFF。 0×1000--気圧フォーラムに割り当てられた0x11FF。 0×1200--IETFのために予約された0x37FF。 0×3800--0x3FFF Experimental使用。
IANA will administer the ranges reserved for the IETF as described in Section 9. Values in the 'Experimental use' range have only local significance.
IANAはIETFのためにセクション9で説明されるように予約された範囲を管理するでしょう。 '実験用'範囲の値には、ローカルの意味しかありません。
5.3.0 The End Of Extensions
5.3.0拡大の終わり
Compulsory = 1
Type = 0
Length = 0
1つのタイプ=0長さ=のコンパルソリー=0
Luciani, et. al. Standards Track [Page 36] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[36ページ]。
When extensions exist, the extensions list is terminated by the End Of Extensions/Null TLV.
拡大が存在するとき、拡大リストはEnd Of Extensions/ヌルTLVによって終えられます。
5.3.1 Responder Address Extension
5.3.1 応答者アドレス拡大
Compulsory = 1
Type = 3
Length = variable
1コンパルソリー=Typeが3Length=変数と等しいです。
This extension is used to determine the address of the NHRP responder; i.e., the entity that generates the appropriate "reply" packet for a given "request" packet. In the case of an NHRP Resolution Request, the station responding may be different (in the case of cached replies) than the system identified in the Next Hop field of the NHRP Resolution Reply. Further, this extension may aid in detecting loops in the NHRP forwarding path.
この拡張子はNHRP応答者のアドレスを決定するのに使用されます。 すなわち、与えられた「要求」パケットのために適切な「回答」パケットを発生させる実体。 NHRP Resolution Requestの場合では、ステーションの応じるのはNHRP Resolution ReplyのNext Hop分野で特定されたシステムと異なっているかもしれません(キャッシュされた回答の場合における)。 さらに、この拡大はNHRP推進経路に輪を検出する際に支援されるかもしれません。
This extension uses a single CIE with the extension specific meanings of the fields set as follows:
この拡大は分野の特定の意味が以下の通り設定する拡大を伴う独身のCIEを使用します:
The Prefix Length fields MUST be set to 0 and ignored.
Prefix Length分野を0に設定されて、無視しなければなりません。
CIE Code
5 - Insufficient Resources
If the responder to an NHRP Resolution Request is an egress point
for the target of the address resolution request (i.e., it is one
of the stations identified in the list of CIEs in an NHRP
Resolution Reply) and the Responder Address extension is included
in the NHRP Resolution Request and insufficient resources to
setup a cut-through VC exist at the responder then the Code field
of the Responder Address Extension is set to 5 in order to tell
the client that a VC setup attempt would in all likelihood be
rejected; otherwise this field MUST be coded as a zero. NHCs MAY
use this field to influence whether they attempt to setup a cut-
through to the egress router.
CIE Code5--NHRP Resolution Requestへの応答者の不十分なResources Ifはアドレス解決要求の目標のための出口ポイント(すなわち、それはNHRP Resolution ReplyでCIEsのリストで特定されたステーションの1つである)であり、Responder Addressは拡大です; 通じて切れるのをセットアップするためにNHRP Resolution Requestと不十分なリソースに含まれていて、VCが応答者に存在していて、次に、Responder Address ExtensionのCode分野がVCセットアップ試みが十中八九拒絶されるとクライアントに言うために5に設定されるという、ことです。 さもなければ、ゼロとしてこの分野をコード化しなければなりません。 彼らが、出口ルータに終えたカットをセットアップするのを試みるか否かに関係なく、NHCsは影響を及ぼすこの分野を使用するかもしれません。
Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the
responder. If this value is 0 then either the default MTU is used
or the MTU negotiated via signaling is used if such negotiation is
possible for the given NBMA.
最大のTransmission Unit This分野は応答者によって好まれたマキシマム・トランスミッション・ユニットを与えます。 この値が0であるなら、デフォルトMTUが使用されているか、または与えられたNBMAに、そのような交渉が可能であるなら、シグナリングで交渉されたMTUは使用されています。
Holding Time
The Holding Time field specifies the number of seconds for which
the NBMA information of the responser is considered to be valid.
Cached information SHALL be discarded when the holding time
expires.
TimeをHolding Timeがさばく持っていると、responserのNBMA情報が有効であると考えられる秒数は指定されます。 把持時間が期限が切れるとき、捨てられて、情報SHALLをキャッシュしました。
Luciani, et. al. Standards Track [Page 37] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[37ページ]。
"Client Address" information is actually "Responder Address" information for this extension. Thus, for example, Cli Addr T/L is the responder NBMA address type and length field.
「クライアントAddress」情報は実際にこの拡大のための「応答者アドレス」情報です。 このようにして、そして、例えば、Cli Addr T/Lは、応答者NBMAアドレスタイプと長さの分野です。
If a "requester" desires this information, the "requester" SHALL include this extension with a value of zero. Note that this implies that no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out.
「リクエスタ」願望この情報、「リクエスタ」であるなら、SHALLはゼロの値でこの拡大を含んでいます。 これが、拡大の「値」部分が書き込まれるまで格納が全くHolding TimeとType/長さの分野に割り当てられないのを含意することに注意してください。
If an NHS is generating a "reply" packet in response to a "request" containing this extension, the NHS SHALL include this extension, containing its protocol address in the "reply". If an NHS has more than one protocol address, it SHALL use the same protocol address consistently in all of the Responder Address, Forward Transit NHS Record, and Reverse Transit NHS Record extensions. The choice of which of several protocol address to include in this extension is a local matter.
この拡大を含んでいて、NHSが「要求」に対応して「回答」パケットを発生させているなら、NHS SHALLはこの拡大を含んでいます、「回答」におけるプロトコルアドレスを含んでいて。 NHSがそうしたなら、1つ以上はアドレスについて議定書の中で述べて、それは同じプロトコルがResponder Address、Forward Transit NHS Record、およびReverse Transit NHS Record拡張子のすべてに一貫して記述するSHALL使用です。 選択はこの拡大で数個のプロトコルアドレスのどれを含んでいるかを地域にかかわる事柄です。
If an NHRP Resolution Reply packet being forwarded by an NHS contains a protocol address of that NHS in the Responder Address Extension then that NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the NHRP Resolution Reply.
NHSによって進められるNHRP Resolution ReplyパケットがResponder Address ExtensionにそのNHSのプロトコルアドレスを含んでいるなら、そのNHS SHALLは「NHRP輪は検出した」タイプのNHRP Error Indicationを発生させて、NHRP Resolution Replyを捨てます。
If an NHRP Resolution Reply packet is being returned by an intermediate NHS based on cached data, it SHALL place its own address in this extension (differentiating it from the address in the Next Hop field).
中間介在物でNHRP Resolution Replyパケットを返しているなら、NHSはキャッシュされたデータを基礎づけて、それはこの拡大でSHALLの場所のそれ自身のアドレス(Next Hop分野でアドレスとそれを区別して)です。
5.3.2 NHRP Forward Transit NHS Record Extension
5.3.2 NHRPの前進のトランジットNHSは拡大を記録します。
Compulsory = 1
Type = 4
Length = variable
1コンパルソリー=Typeが4Length=変数と等しいです。
The NHRP Forward Transit NHS record contains a list of transit NHSs through which a "request" has traversed. Each NHS SHALL append to the extension a Forward Transit NHS element (as specified below) containing its Protocol address. The extension length field and the ar$chksum fields SHALL be adjusted appropriately.
横断されて、NHRP Forward Transit NHS記録は「要求」がそうしたトランジットNHSsのリストを含んでいます。 プロトコルアドレスを含んでいて、各NHS SHALLはForward Transit NHS要素(以下で指定されるとしての)を拡大に追加します。 拡大長さの分野とar$chksumはSHALLをさばきます。適切に調整されます。
The responding NHS, as described in Section 5.3.1, SHALL NOT update this extension.
応じているNHSであり、SHALL NOTはセクション5.3.1で説明されるようにこの拡大をアップデートします。
In addition, NHSs that are willing to act as egress routers for packets from the source to the destination SHALL include information about their NBMA Address.
さらに、パケットのための出口ルータとしてソースから目的地SHALLまで機能しても構わないと思っているNHSsがそれらのNBMA Addressの情報を含んでいます。
Luciani, et. al. Standards Track [Page 38] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[38ページ]。
This extension uses a single CIE per NHS Record element with the extension specific meanings of the fields set as follows:
この拡大は分野の特定の意味が以下の通り設定する拡大と共にNHS Record要素あたり1独身のCIEを使用します:
The Prefix Length fields MUST be set to 0 and ignored.
Prefix Length分野を0に設定されて、無視しなければなりません。
CIE Code
5 - Insufficient Resources
If an NHRP Resolution Request contains an NHRP Forward Transit
NHS Record Extension and insufficient resources to setup a cut-
through VC exist at the current transit NHS then the CIE Code
field for NHRP Forward Transit NHS Record Extension is set to 5
in order to tell the client that a VC setup attempt would in all
likelihood be rejected; otherwise this field MUST be coded as a
zero. NHCs MAY use this field to influence whether they attempt
to setup a cut-through as described in Section 2.2. Note that
the NHRP Reverse Transit NHS Record Extension MUST always have
this field set to zero.
CIE Code5--、不十分なResources If、NHRP Resolution RequestはNHRP Forward Transit NHS Record Extensionを含んでいます、そして、VCを通したカットをセットアップする不十分なリソースは現在のトランジットNHSに存在しています、そして、次に、NHRP Forward Transit NHS Record ExtensionのためのCIE Code分野はVCセットアップ試みが十中八九拒絶されるとクライアントに言うために5に設定されます、。 さもなければ、ゼロとしてこの分野をコード化しなければなりません。 彼らが、セクション2.2で説明されるように通じて切れるのをセットアップするのを試みるか否かに関係なく、NHCsは影響を及ぼすこの分野を使用するかもしれません。 NHRP Reverse Transit NHS Record Extensionがこの分野をいつもゼロに設定させなければならないことに注意してください。
Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the
transit NHS. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA.
最大のTransmission Unit This分野はトランジットNHSによって好まれたマキシマム・トランスミッション・ユニットを与えます。 この値が0であるなら、デフォルトMTUが使用されているか、または与えられたNBMAに、そのような交渉が可能であるなら、シグナリングで交渉されたMTUは使用されています。
Holding Time
The Holding Time field specifies the number of seconds for which
the NBMA information of the transit NHS is considered to be valid.
Cached information SHALL be discarded when the holding time
expires.
TimeをHolding Timeがさばく持っていると、トランジットNHSのNBMA情報が有効であると考えられる秒数は指定されます。 把持時間が期限が切れるとき、捨てられて、情報SHALLをキャッシュしました。
"Client Address" information is actually "Forward Transit NHS Address" information for this extension. Thus, for example, Cli Addr T/L is the transit NHS NBMA address type and length field.
「クライアントAddress」情報は実際にこの拡大のための「前進のトランジットNHSアドレス」情報です。 このようにして、そして、例えば、Cli Addr T/Lは、トランジットNHS NBMAアドレスタイプと長さの分野です。
If a "requester" wishes to obtain this information, it SHALL include this extension with a length of zero. Note that this implies that no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out.
「リクエスタ」はaであるならこの情報を得たがっていて、それはSHALLです。長さのゼロがあるこの拡大を含めてください。 これが、拡大の「値」部分が書き込まれるまで格納が全くHolding TimeとType/長さの分野に割り当てられないのを含意することに注意してください。
If an NHS has more than one Protocol address, it SHALL use the same Protocol address consistently in all of the Responder Address, Forward NHS Record, and Reverse NHS Record extensions. The choice of which of several Protocol addresses to include in this extension is a local matter.
NHSには、1つ以上のプロトコルアドレスがあって、それは同じプロトコルがResponder Address、Forward NHS Record、およびReverse NHS Record拡張子のすべてに一貫して記述するSHALL使用です。 この拡大で含んでいる選択はプロトコルが数個のどれを記述するかを地域にかかわる事柄です。
Luciani, et. al. Standards Track [Page 39] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[39ページ]。
If a "request" that is being forwarded by an NHS contains the Protocol Address of that NHS in one of the Forward Transit NHS elements then the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the "request".
NHSによって進められている「要求」がForward Transit NHS要素の1つにそのNHSのプロトコルAddressを含んでいるなら、NHS SHALLは「NHRP輪は検出した」タイプのNHRP Error Indicationを発生させて、「要求」を捨てます。
5.3.3 NHRP Reverse Transit NHS Record Extension
5.3.3NHRPはトランジットのNHSの記録的な拡張子を覆します。
Compulsory = 1
Type = 5
Length = variable
1コンパルソリー=Typeが5Length=変数と等しいです。
The NHRP Reverse Transit NHS record contains a list of transit NHSs through which a "reply" has traversed. Each NHS SHALL append a Reverse Transit NHS element (as specified below) containing its Protocol address to this extension. The extension length field and ar$chksum SHALL be adjusted appropriately.
横断されて、NHRP Reverse Transit NHS記録は「回答」がそうしたトランジットNHSsのリストを含んでいます。 この拡大にプロトコルアドレスを含んでいて、各NHS SHALLはReverse Transit NHS要素(以下で指定されるとしての)を追加します。 拡大の長さは、$chksum SHALLをさばいて、arします。適切に調整されます。
The responding NHS, as described in Section 5.3.1, SHALL NOT update this extension.
応じているNHSであり、SHALL NOTはセクション5.3.1で説明されるようにこの拡大をアップデートします。
In addition, NHSs that are willing to act as egress routers for packets from the source to the destination SHALL include information about their NBMA Address.
さらに、パケットのための出口ルータとしてソースから目的地SHALLまで機能しても構わないと思っているNHSsがそれらのNBMA Addressの情報を含んでいます。
This extension uses a single CIE per NHS Record element with the extension specific meanings of the fields set as follows:
この拡大は分野の特定の意味が以下の通り設定する拡大と共にNHS Record要素あたり1独身のCIEを使用します:
The CIE Code and Prefix Length fields MUST be set to 0 and ignored.
CIE CodeとPrefix Length分野は0に用意ができて、無視しなければなりません。
Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the
transit NHS. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA.
最大のTransmission Unit This分野はトランジットNHSによって好まれたマキシマム・トランスミッション・ユニットを与えます。 この値が0であるなら、デフォルトMTUが使用されているか、または与えられたNBMAに、そのような交渉が可能であるなら、シグナリングで交渉されたMTUは使用されています。
Holding Time
The Holding Time field specifies the number of seconds for which
the NBMA information of the transit NHS is considered to be valid.
Cached information SHALL be discarded when the holding time
expires.
TimeをHolding Timeがさばく持っていると、トランジットNHSのNBMA情報が有効であると考えられる秒数は指定されます。 把持時間が期限が切れるとき、捨てられて、情報SHALLをキャッシュしました。
"Client Address" information is actually "Reverse Transit NHS Address" information for this extension. Thus, for example, Cli Addr T/L is the transit NHS NBMA address type and length field.
「クライアントAddress」情報は実際にこの拡大のための「逆のトランジットNHSアドレス」情報です。 このようにして、そして、例えば、Cli Addr T/Lは、トランジットNHS NBMAアドレスタイプと長さの分野です。
Luciani, et. al. Standards Track [Page 40] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[40ページ]。
If a "requester" wishes to obtain this information, it SHALL include this extension with a length of zero. Note that this implies that no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out.
「リクエスタ」はaであるならこの情報を得たがっていて、それはSHALLです。長さのゼロがあるこの拡大を含めてください。 これが、拡大の「値」部分が書き込まれるまで格納が全くHolding TimeとType/長さの分野に割り当てられないのを含意することに注意してください。
If an NHS has more than one Protocol address, it SHALL use the same Protocol address consistently in all of the Responder Address, Forward NHS Record, and Reverse NHS Record extensions. The choice of which of several Protocol addresses to include in this extension is a local matter.
NHSには、1つ以上のプロトコルアドレスがあって、それは同じプロトコルがResponder Address、Forward NHS Record、およびReverse NHS Record拡張子のすべてに一貫して記述するSHALL使用です。 この拡大で含んでいる選択はプロトコルが数個のどれを記述するかを地域にかかわる事柄です。
If a "reply" that is being forwarded by an NHS contains the Protocol Address of that NHS in one of the Reverse Transit NHS elements then the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the "reply".
NHSによって進められている「回答」がReverse Transit NHS要素の1つにそのNHSのプロトコルAddressを含んでいるなら、NHS SHALLは「NHRP輪は検出した」タイプのNHRP Error Indicationを発生させて、「回答」を捨てます。
Note that this information may be cached at intermediate NHSs; if so, the cached value SHALL be used when generating a reply.
この情報が中間的NHSsでキャッシュされるかもしれないことに注意してください。 そうだとすれば、キャッシュはSHALLを評価します。回答を発生させるとき、使用されます。
5.3.4 NHRP Authentication Extension
5.3.4 NHRP認証拡張子
Compulsory = 1 Type = 7 Length = variable
1コンパルソリー=Typeが7Length=変数と等しいです。
The NHRP Authentication Extension is carried in NHRP packets to convey authentication information between NHRP speakers. The Authentication Extension may be included in any NHRP "request" or "reply" only.
NHRP Authentication Extensionは、NHRPスピーカーの間に認証情報を伝えるためにNHRPパケットで運ばれます。 Authentication ExtensionはどんなNHRP「要求」や「回答」だけにも含まれるかもしれません。
The authentication is always done pairwise on an NHRP hop-by-hop basis; i.e., the authentication extension is regenerated at each hop. If a received packet fails the authentication test, the station SHALL generate an Error Indication of type "Authentication Failure" and discard the packet. Note that one possible authentication failure is the lack of an Authentication Extension; the presence or absence of the Authentication Extension is a local matter.
ホップごとのNHRPベースで認証に対状をいつもします。 すなわち、認証拡大は各ホップで作り直されます。 容認されたパケットが認証テストに失敗するなら、ステーションSHALLはタイプ「認証失敗」のError Indicationを発生させて、パケットを捨てます。 1つの可能な認証失敗がAuthentication Extensionの不足であることに注意してください。 Authentication Extensionの存在か不在が地域にかかわる事柄です。
5.3.4.1 Header Format
5.3.4.1 ヘッダー形式
The authentication header has the following format:
認証ヘッダーには、以下の形式があります:
Luciani, et. al. Standards Track [Page 41] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[41ページ]。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Security Parameter Index (SPI)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Addr... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| セキュリティパラメタインデックス(SPI)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Addr… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +++++++++++認証データ… -+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a table that maintains the keys and other information such as hash algorithm. Src and Dst communicate either offline using manual keying or online using a key management protocol to populate this table. The sending NHRP entity always allocates the SPI and the parameters associated with it.
インデックスとして細切れ肉料理アルゴリズムなどのキーと他の情報を保守するテーブルにセキュリティParameter Index(SPI)を考えることができます。 SrcとDstは、かぎ管理がこのテーブルに居住するために議定書の中で述べる手動の合わせているかオンラインの使用を使用することでオフラインで交信します。 送付NHRP実体はいつもそれに関連しているSPIとパラメタを割り当てます。
Src Addr a variable length field is the address assigned to the outgoing interface. The length of the addr is obtained from the source protocol length field in the mandatory part of the NHRP header. The tuple <spi, src addr> uniquely identifies the key and other parameters that are used in authentication.
Src Addr a可変長フィールドは外向的なインタフェースに割り当てられたアドレスです。 NHRPヘッダーの義務的な一部のソースプロトコル長さの分野からaddrの長さを得ます。 tuple<spiであり、src addr>は唯一認証に使用される主要で他のパラメタを特定します。
The length of the authentication data field is dependent on the hash algorithm used. The data field contains the keyed hash calculated over the entire NHRP payload. The authentication data field is zeroed out before the hash is calculated.
認証データ・フィールドの長さは使用される細切れ肉料理アルゴリズムに依存しています。 データ・フィールドは全体のNHRPペイロードの上計算された合わせられた細切れ肉料理を含んでいます。 細切れ肉料理が計算される前に認証データ・フィールドのゼロは合わせられています。
5.3.4.2 SPI and Security Parameters Negotiation
5.3.4.2 SPIとセキュリティパラメタ交渉
SPI's can be negotiated either manually or using an Internet Key Management protocol. Manual keying MUST be supported. The following parameters are associated with the tuple <SPI, src>- lifetime, Algorithm, Key. Lifetime indicates the duration in seconds for which the key is valid. In case of manual keying, this duration can be infinite. Also, in order to better support manual keying, there may be multiple tuples active at the same time (Dst being the same).
SPIのものは、手動で交渉されるか、またはインターネットKey Managementプロトコルを使用できます。 手動の合わせることを支持しなければなりません。 以下のパラメタはtuple<SPI、src>-生涯、Algorithm、Keyに関連しています。 寿命はキーが有効である秒に持続時間を示します。 手動の合わせることの場合には、この持続時間は無限である場合があります。 また、手動の合わせることを支持するほうがよいために、同時にアクティブな複数のtuples(同じであるDst)があるかもしれません。
Algorithm specifies the hash algorithm agreed upon by the two entities. HMAC-MD5-128 [16] is the default algorithm. Other algorithms MAY be supported by defining new values. IANA will assign the numbers to identify the algorithm being used as described in Section 9.
アルゴリズムは2つの実体によって同意された細切れ肉料理アルゴリズムを指定します。 HMAC-MD5-128[16]はデフォルトアルゴリズムです。 他のアルゴリズムは、新しい値を定義することによって、支持されるかもしれません。 IANAは、アルゴリズムを特定するためにセクション9で説明されるように使用されることで数を割り当てるでしょう。
Any Internet standard key management protocol MAY so be used to negotiate the SPI and parameters.
したがって、どんなインターネット標準かぎ管理プロトコルも、SPIとパラメタを交渉するのに使用されるかもしれません。
Luciani, et. al. Standards Track [Page 42] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[42ページ]。
5.3.4.3 Message Processing
5.3.4.3 メッセージ処理
At the time of adding the authentication extension header, src looks up in a table to fetch the SPI and the security parameters based on the outgoing interface address. If there are no entries in the table and if there is support for key management, the src initiates the key management protocol to fetch the necessary parameters. The src constructs the Authentication Extension payload and calculates the hash by zeroing authentication data field. The result replaces in the zeroed authentication data field. The src address field in the payload is the IP address assigned to the outgoing interface.
認証拡張ヘッダーを加える時点で、srcは、外向的なインターフェース・アドレスに基づくパラメタをSPIとセキュリティにとって来るためにテーブルを調べます。 エントリーが全くテーブルになくて、かぎ管理のサポートがあれば、srcは、必要なパラメタをとって来るためにかぎ管理プロトコルを開始します。 srcは、Authentication Extensionペイロードを構成して、認証データ・フィールドのゼロを合わせることによって、細切れ肉料理について計算します。 結果はゼロで認証データ・フィールドを取り替えます。 ペイロードのsrcアドレス・フィールドは外向的なインタフェースに割り当てられたIPアドレスです。
If key management is not supported and authentication is mandatory, the packet is dropped and this information is logged.
かぎ管理が支持されないで、認証が義務的であるなら、パケットは落とされます、そして、この情報は登録されます。
On the receiving end, dst fetches the parameters based on the SPI and the ip address in the authentication extension payload. The authentication data field is extracted before zeroing out to calculate the hash. It computes the hash on the entire payload and if the hash does not match, then an "abnormal event" has occurred.
受ける側になって、dstはSPIに基づくパラメタと認証拡大ペイロードのipアドレスをとって来ます。 認証データ・フィールドは、ゼロの前に外に細切れ肉料理について計算するために抽出されます。 それは全体のペイロードの上の細切れ肉料理を計算します、そして、細切れ肉料理が合っていないなら、「異常な出来事」は起こりました。
5.3.4.4 Security Considerations
5.3.4.4 セキュリティ問題
It is important that the keys chosen are strong as the security of the entire system depends on the keys being chosen properly and the correct implementation of the algorithms.
全体のシステムのセキュリティが適切に選ばれているキーとアルゴリズムの正しい実現によるとき選ばれたキーが強いのは、重要です。
The security is performed on a hop by hop basis. The data received can be trusted only so much as one trusts all the entities in the path traversed. A chain of trust is established amongst NHRP entities in the path of the NHRP Message . If the security in an NHRP entity is compromised, then security in the entire NHRP domain is compromised.
セキュリティはホップ基礎によってホップに実行されます。 データは信じられた唯一のものさえ経路のすべての実体が横断した受託であったかもしれないなら受信されました。 信用のチェーンはNHRP Messageの経路のNHRP実体の中に設立されます。NHRP実体におけるセキュリティが妥協するなら、全体のNHRPドメインにおけるセキュリティは妥協します。
Data integrity covers the entire NHRP payload. This guarantees that the message was not modified and the source is authenticated as well. If authentication extension is not used or if the security is compromised, then NHRP entities are liable to both spoofing attacks, active attacks and passive attacks.
データの保全は全体のNHRPペイロードをカバーしています。 これは、メッセージが変更されないで、また、ソースが認証されるのを保証します。 認証拡大が使用されていないか、またはセキュリティが妥協するなら、NHRP実体はともにだましている攻撃、活発な攻撃、および受け身の攻撃に責任があります。
There is no mechanism to encrypt the messages. It is assumed that a standard layer 3 confidentiality mechanism will be used to encrypt and decrypt messages. It is recommended to use an Internet standard key management protocol to negotiate the keys between the neighbors. Transmitting the keys in clear text, if other methods of negotiation is used, compromises the security completely.
メッセージをコード化するために、メカニズムは全くありません。 標準の層3の秘密性メカニズムがメッセージをコード化して、解読するのに使用されると思われます。 隣人の間のキーを交渉するのにインターネット標準かぎ管理プロトコルを使用するのはお勧めです。 交渉の他の方法が使用されているならクリアテキストでキーを送ると、セキュリティは完全に妥協します。
Luciani, et. al. Standards Track [Page 43] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[43ページ]。
Any NHS is susceptible to Denial of Service (DOS) attacks that cause it to become overloaded, preventing legitimate packets from being acted upon properly. A rogue host can send request and registration packets to the first hop NHS. If the authentication option is not used, the registration packet is forwarded along the routed path requiring processing along each NHS. If the authentication option is used, then only the first hop NHS is susceptible to DOS attacks (i.e., unauthenticated packets will be dropped rather than forwarded on). If security of any host is compromised (i.e., the keys it is using to communicate with an NHS become known), then a rogue host can send NHRP packets to the first hop NHS of the host whose keys were compromised, which will then forward them along the routed path as in the case of unauthenticated packets. However, this attack requires that the rogue host to have the same first hop NHS as that of the compromised host. Finally, it should be noted that denial of service attacks that cause routers on the routed path to expend resources processing NHRP packets are also susceptable to attacks that flood packets at the same destination as contained in an NHRP packet's Destination Protocol Address field.
どんなNHSもそれが積みすぎられるようになるサービス妨害(DOS)攻撃によって影響されやすいです、正統のパケットが適切に作用されるのを防いで。 凶暴なホストは要求と登録パケットを最初のホップNHSに送ることができます。 認証オプションが使用されていないなら、各NHSに沿って処理するのが必要でありながら、発送された経路に沿って登録パケットを進めます。 認証オプションが使用されているなら、最初のホップNHSだけがDOS攻撃に影響されやすいです(すなわち、非認証されたパケットは進めるよりむしろ落とされるでしょう)。 どんなホストのセキュリティも妥協するなら(すなわち、それがNHSとコミュニケートするのに使用しているキーは知られるようになります)、凶暴なホストはキーが妥協したホストの最初のホップNHSへのパケットをNHRPに送ることができます。(次に、NHSは非認証されたパケットのケースのように発送された経路に沿ってそれらを進めるでしょう)。 しかしながら、この攻撃は、最初に、同じようにいる凶暴なホストが易感染性宿主のものとしてNHSを飛び越すのを必要とします。 最終的に、また、発送された経路のルータがNHRPパケットを処理するリソースを費やすサービス不能攻撃もNHRPパケットのDestinationプロトコルAddress分野の含まれるのと同じ目的地にパケットをあふれさせる攻撃にsusceptableであることに注意されるべきです。
5.3.5 NHRP Vendor-Private Extension
5.3.5 NHRPの業者個人的な拡張子
Compulsory = 0
Type = 8
Length = variable
0コンパルソリー=Typeは8Length=変数と等しいです。
The NHRP Vendor-Private Extension is carried in NHRP packets to convey vendor-private information or NHRP extensions between NHRP speakers.
NHRP Vendor個人的なExtensionは、業者個人情報かNHRP拡張子をNHRPスピーカーの間に伝えるためにNHRPパケットで運ばれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 業者ID| データ… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID
802 Vendor ID as assigned by the IEEE [6]
IEEEによって割り当てられる業者ID802Vendor ID[6]
Data
The remaining octets after the Vendor ID in the payload are
vendor-dependent data.
データ、ペイロードのVendor IDの後の残っている八重奏は業者依存するデータです。
This extension may be added to any "request" or "reply" packet and it is the only extension that may be included multiple times. If the receiver does not handle this extension, or does not match the Vendor
この拡大はどんな「要求」か「回答」パケットにも加えられるかもしれません、そして、それは複数の回含まれるかもしれない唯一の拡大です。 受信機がこの拡大を扱わないか、またはVendorに合っていないなら
Luciani, et. al. Standards Track [Page 44] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[44ページ]。
ID in the extension then the extension may be completely ignored by the receiver. If a Vendor Private Extension is included in a "request" then it must be copied to the corresponding "reply".
受信機によって無視されて、次に、拡大がそうする拡大におけるIDは完全にそうです。Vendor兵士のExtensionが「要求」に含まれているなら、対応する「回答」にそれをコピーしなければなりません。
6. Protocol Operation
6. プロトコル操作
In this section, we discuss certain operational considerations of NHRP.
このセクションで、私たちはNHRPのある操作上の問題について議論します。
6.1 Router-to-Router Operation
6.1 ルータからルータへの操作
In practice, the initiating and responding stations may be either hosts or routers. However, there is a possibility under certain conditions that a stable routing loop may occur if NHRP is used between two routers. In particular, attempting to establish an NHRP path across a boundary where information used in route selection is lost may result in a routing loop. Such situations include the loss of BGP path vector information, the interworking of multiple routing protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such circumstances, NHRP should not be used. This situation can be avoided if there are no "back door" paths between the entry and egress router outside of the NBMA subnetwork. Protocol mechanisms to relax these restrictions are under investigation.
実際には、開始とステーションを反応させるのは、ホストかルータのどちらかであるかもしれません。 しかしながら、NHRPが2つのルータの間で使用されるなら一定の条件の下で、安定したルーティング輪が現れるかもしれない可能性があります。 ルート選択に使用される情報が無くなる境界の向こう側にNHRP経路を確立するのを試みるのが特に、ルーティング輪をもたらすかもしれません。 そのような状況はBGP経路ベクトル情報の損失、異なった測定基準(e.のg、RIP、およびOSPF)による複数のルーティング・プロトコルを織り込むことを含んでいます。 そのような事情では、NHRPを使用するべきではありません。 「裏口」経路が全くNBMAサブネットワークの外にエントリーと出口ルータの間になければ、この状況を避けることができます。 これらの規制を緩和するプロトコルメカニズムは調査中です。
In general it is preferable to use mechanisms, if they exist, in routing protocols to resolve the egress point when the destination lies outside of the NBMA subnetwork, since such mechanisms will be more tightly coupled to the state of the routing system and will probably be less likely to create loops.
一般に、メカニズムを使用するのは望ましいです、目的地がNBMAサブネットワークの外に位置するとき、出口ポイントを決議するためにルーティング・プロトコルで存在しているなら、そのようなメカニズムが、よりしっかりルーティングシステムの事情と結合されて、たぶん輪をより作成しそうにないので。
6.2 Cache Management Issues
6.2 キャッシュ管理問題
The management of NHRP caches in the source station, the NHS serving the destination, and any intermediate NHSs is dependent on a number of factors.
発信局、目的地に役立つNHS、およびどんな中間的NHSsでのNHRPキャッシュの管理も多くの要因に依存しています。
6.2.1 Caching Requirements
6.2.1 要件をキャッシュすること。
Source Stations
発信局
Source stations MUST cache all received NHRP Resolution Replies
that they are actively using. They also must cache "incomplete"
entries, i.e., those for which a NHRP Resolution Request has been
sent but those for which an NHRP Resolution Reply has not been
received. This is necessary in order to preserve the Request ID
発信局は彼らが活発に使用しているすべての容認されたNHRP Resolution Repliesをキャッシュしなければなりません。 また、彼らは「不完全な」エントリー、すなわち、NHRP Resolution Replyが受け取られていないものだけがNHRP Resolution Requestに送られたそれらをキャッシュしなければなりません。 これが、Request IDを保持するのに必要です。
Luciani, et. al. Standards Track [Page 45] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[45ページ]。
for retries, and provides the state necessary to avoid triggering
NHRP Resolution Requests for every data packet sent to the
destination.
目的地に送られたあらゆるデータ・パケットのためにNHRP Resolution Requestsの引き金となるのを避けるのに必要な状態を再試行して、提供します。
Source stations MUST purge expired information from their caches.
Source stations MUST purge the appropriate cached information upon
receipt of an NHRP Purge Request packet.
発信局は満期の情報からそれらのキャッシュから追放しなければなりません。 発信局はNHRP Purge Requestパケットを受け取り次第適切なキャッシュされた情報を掃除しなければなりません。
When a station has a co-resident NHC and NHS, the co-resident NHS
may reply to NHRP Resolution Requests from the co-resident NHC with
information which the station cached as a result of the co-resident
NHC making its own NHRP Resolution Requests as long as the co-
resident NHS follows the rules for Transit NHSs as seen below.
ステーションにコレジデントNHCとNHSがあるとき、コレジデントNHSは、以下が見られるように共同居住しているNHSがTransit NHSsのために約束を守る限り、それ自身のNHRP Resolution Requestsを作りながら、ステーションがコレジデントNHCの結果、キャッシュした情報でコレジデントNHCからNHRP Resolution Requestsに答えるかもしれません。
Serving NHSs
NHSsに役立ちます。
The NHS serving the destination (the one which responds
authoritatively to NHRP Resolution Requests) SHOULD cache protocol
address information from all NHRP Resolution Requests to which it
has responded if the information in the NHRP Resolution Reply has
the possibility of changing during its lifetime (so that an NHRP
Purge Request packet can be issued). The internetworking to NBMA
binding information provided by the source station in the NHRP
Resolution Request may also be cached if and only if the "S" bit is
set, the NHRP Resolution Request has included a CIE with the
Holding Time field set greater than zero (this is the valid Holding
Time for the source binding), and only for non-authoritative use
for a period not to exceed the Holding Time.
目的地(厳然とNHRP Resolution Requestsに応じるもの)SHOULDキャッシュプロトコルに役立つNHSはNHRP Resolution Replyの情報に生涯変化する可能性があるなら(NHRP Purge Requestパケットを発行できるように)それが応じたすべてのNHRP Resolution Requestsからの情報を記述します。 また、NHRP Resolution Requestの発信局によって提供されたNBMAの拘束力がある情報へのインターネットワーキングがキャッシュされるかもしれない、「S」に噛み付いた場合にだけ、セット、要求がしばらく把持時間を超えないようにゼロ(これはソース結合のための有効な把持時間である)より大きい把持時間分野セット、および非正式の使用のためだけのCIEを含んでいたというNHRP解決はそうです。
Transit NHSs
トランジットNHSs
A Transit NHS (lying along the NHRP path between the source station
and the responding NHS) may cache source binding information
contained in NHRP Resolution Request packets that it forwards if
and only if the "S" bit is set, the NHRP Resolution Request has
included a CIE with the Holding Time field set greater than zero
(this is the valid Holding Time for the source binding), and only
for non-authoritative use for a period not to exceed the Holding
Time.
Transit NHS(発信局と応じているNHSの間のNHRP経路に沿って横たわっている)がそれが進めるNHRP Resolution Requestパケットに含まれたソースの拘束力がある情報をキャッシュするかもしれない、「S」に噛み付いた場合にだけ、セット、要求がしばらく把持時間を超えないようにゼロ(これはソース結合のための有効な把持時間である)より大きい把持時間分野セット、および非正式の使用のためだけのCIEを含んでいたというNHRP解決はそうです。
A Transit NHS may cache destination information contained in NHRP
Resolution Reply CIE if only if the D bit is set and then only for
non-authoritative use for a period not to exceed the Holding Time
value contained in the CIE. A Transit NHS MUST NOT cache source
binding information contained in an NHRP Resolution Reply.
Transit NHSは、CIEに含まれたHolding Time値を超えないように唯一ならしばらくDビットが設定されてそして、非正式の使用のためだけのものであるならNHRP Resolution Reply CIEに含まれた目的地情報をキャッシュするかもしれません。 Transit NHSはNHRP Resolution Replyに含まれたソースの拘束力がある情報をキャッシュしてはいけません。
Luciani, et. al. Standards Track [Page 46] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[46ページ]。
Further, a transit NHS MUST discard any cached information when the
prescribed time has expired. It may return cached information in
response to non-authoritative NHRP Resolution Requests only.
さらに、トランジットNHS MUSTは処方された時間がいつ期限が切れたかというどんなキャッシュされた情報も捨てます。 それは非正式のNHRP Resolution Requestsだけに対応してキャッシュされた情報を返すかもしれません。
6.2.2 Dynamics of Cached Information
6.2.2 キャッシュされた情報の力学
NBMA-Connected Destinations
NBMAによって接続された目的地
NHRP's most basic function is that of simple NBMA address
resolution of stations directly attached to the NBMA subnetwork.
These mappings are typically very static, and appropriately chosen
holding times will minimize problems in the event that the NBMA
address of a station must be changed. Stale information will cause
a loss of connectivity, which may be used to trigger an
authoritative NHRP Resolution Request and bypass the old data. In
the worst case, connectivity will fail until the cache entry times
out.
NHRPの最も基本的な機能は簡単なNBMAでは、ステーションのアドレス解決が直接NBMAサブネットワークに付いたということです。 通常、これらのマッピングは非常に静的です、そして、ステーションのNBMAアドレスを変えなければならないと、適切に選ばれた把持時間は問題を最小にするでしょう。 聞き古した情報は、使用されるかもしれない接続性の損失が正式のNHRP Resolution Requestの引き金となって、古いデータを迂回させることを引き起こすでしょう。 最悪の場合には、接続性は外でキャッシュエントリー回数まで失敗するでしょう。
This applies equally to information marked in NHRP Resolution
Replies as being "stable" (via the "D" bit).
これは等しく「安定する」であるとして(「D」ビットを通した)NHRP Resolution Repliesでマークされた情報に適用されます。
Destinations Off of the NBMA Subnetwork
NBMAサブネットワークからの目的地
If the source of an NHRP Resolution Request is a host and the
destination is not directly attached to the NBMA subnetwork, and
the route to that destination is not considered to be "stable," the
destination mapping may be very dynamic (except in the case of a
subnetwork where each destination is only singly homed to the NBMA
subnetwork). As such the cached information may very likely become
stale. The consequence of stale information in this case will be a
suboptimal path (unless the internetwork has partitioned or some
other routing failure has occurred).
NHRP Resolution Requestの源がホストであり、目的地が直接NBMAサブネットワークに付けられていなくて、またその目的地へのルートが「安定している」と考えられないなら、目的地マッピングは非常にダイナミックであるかもしれません(サブネットワークに関するケースを除いて、各目的地がどこにあるかが単独でNBMAサブネットワークと家へ帰っただけです)。 そういうものとして、キャッシュされた情報はたぶん聞き古したであるなるかもしれません。 この場合、聞き古した情報の結果が準最適の経路になる、(インターネットワークが仕切ったか、またはある他のルーティング失敗が起こるのに持っている、)
6.3 Use of the Prefix Length field of a CIE
6.3 CIEのPrefix Length分野の使用
A certain amount of care needs to be taken when using the Prefix Length field of a CIE, in particular with regard to the prefix length advertised (and thus the size of the equivalence class specified by it). Assuming that the routers on the NBMA subnetwork are exchanging routing information, it should not be possible for an NHS to create a black hole by advertising too large of a set of destinations, but suboptimal routing (e.g., extra internetwork layer hops through the NBMA) can result. To avoid this situation an NHS that wants to send the Prefix Length MUST obey the following rule:
ある量の注意が、CIEのPrefix Length分野を使用するとき、取られる必要があります、特に広告に掲載された接頭語の長さに関して(その結果、同値類のサイズはそれで指定しました)。 NBMAサブネットワークの上のルータがルーティング情報を交換していると仮定する場合、NHSがルーティング(例えば、NBMAを通した余分なインターネットワーク層のホップ)が結果として生じることができるのを1セットの目的地で大き過ぎる、しかし、準最適の広告でブラックホールを作成するのは、可能であるべきではありません。 この状況を避けるために、Prefix Lengthを送りたがっているNHSは以下の規則に従わなければなりません:
The NHS examines the Network Layer Reachability Information (NLRI)
associated with the route that the NHS would use to forward towards
the destination (as specified by the Destination internetwork layer
NHSが目的地に向かって転送するNHSが使用するルートに関連しているNetwork Layer Reachability情報(NLRI)を調べる、(Destinationインターネットワーク層で、指定されます。
Luciani, et. al. Standards Track [Page 47] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[47ページ]。
address in the NHRP Resolution Request), and extracts from this
NLRI the shortest address prefix such that: (a) the Destination
internetwork layer address (from the NHRP Resolution Request) is
covered by the prefix, (b) the NHS does not have any routes with
NLRI which form a subset of what is covered by the prefix. The
prefix may then be used in the CIE.
NHRP Resolution Requestのアドレス)、これからの最も短いNLRIが記述する抽出は以下のことのようなものを前に置きます。 (a) (b) NHSには、Destinationインターネットワーク層のアドレス(NHRP Resolution Requestからの)は接頭語でカバーされていて、接頭語でカバーされていることに関する部分集合を形成するNLRIがあるどんなルートもありません。 そして、接頭語はCIEで使用されるかもしれません。
The Prefix Length field of the CIE should be used with restraint, in order to avoid NHRP stations choosing suboptimal transit paths when overlapping prefixes are available. This document specifies the use of the prefix length only when all the destinations covered by the prefix are "stable". That is, either:
CIEのPrefix Length分野は抑制と共に使用されるべきです、接頭語を重ね合わせるとき、トランジット経路が利用可能であることを準最適で選ばれるNHRPステーションを避けるために。 接頭語で覆われたすべての目的地が「安定している」ときだけ、このドキュメントは接頭語の長さの使用を指定します。 すなわち、どちらか:
(a) All destinations covered by the prefix are on the NBMA network,
or
(b) All destinations covered by the prefix are directly attached to
the NHRP responding station.
(a) 接頭語で覆われたすべての目的地がNBMAネットワークにあるか、または(b) 接頭語で覆われたすべての目的地が直接ステーションを反応させるNHRPに付けられています。
Use of the Prefix Length field of the CIE in other circumstances is outside the scope of this document.
このドキュメントの範囲の外に他の事情におけるCIEのPrefix Length分野の使用があります。
6.4 Domino Effect
6.4 ドミノ効果
One could easily imagine a situation where a router, acting as an ingress station to the NBMA subnetwork, receives a data packet, such that this packet triggers an NHRP Resolution Request. If the router forwards this data packet without waiting for an NHRP transit path to be established, then when the next router along the path receives the packet, the next router may do exactly the same - originate its own NHRP Resolution Request (as well as forward the packet). In fact such a data packet may trigger NHRP Resolution Request generation at every router along the path through an NBMA subnetwork. We refer to this phenomena as the NHRP "domino" effect.
人は容易に、イングレスステーションとしてNBMAサブネットワークに機能して、ルータがデータ・パケットを受ける状況を想像できました、このパケットがNHRP Resolution Requestの引き金となるように。 経路に沿った次のルータがパケットを受けるとき、NHRPトランジット経路が確立されるのを待たないルータがこのデータ・パケットを進めるなら、次のルータはちょうど同じくらいするかもしれません--それ自身のNHRP Resolution Request(パケットを進めるのと同じくらいよく)を溯源してください。 事実上、そのようなデータ・パケットはNBMAサブネットワークを通して経路に沿ったあらゆるルータにおけるNHRP Resolution Request世代の引き金となるかもしれません。 私たちはNHRP「ドミノ」効果とこの現象を呼びます。
The NHRP domino effect is clearly undesirable. At best it may result in excessive NHRP traffic. At worst it may result in an excessive number of virtual circuits being established unnecessarily. Therefore, it is important to take certain measures to avoid or suppress this behavior. NHRP implementations for NHSs MUST provide a mechanism to address this problem. One possible strategy to address this problem would be to configure a router in such a way that NHRP Resolution Request generation by the router would be driven only by the traffic the router receives over its non-NBMA interfaces (interfaces that are not attached to an NBMA subnetwork). Traffic received by the router over its NBMA-attached interfaces would not trigger NHRP Resolution Requests. Such a router avoids the NHRP domino effect through administrative means.
NHRPドミノ効果は明確に望ましくありません。 せいぜい、それは過度のNHRP交通をもたらすかもしれません。 最悪の場合はそれは不必要に確立される過度の数の仮想のサーキットをもたらすかもしれません。 したがって、この振舞いを避けるか、または抑圧するある対策を実施するのは重要です。 NHSsのためのNHRP実現は、このその問題を訴えるためにメカニズムを提供しなければなりません。 このその問題を訴える1つの可能な戦略はルータによるNHRP Resolution Request世代が単にルータが非NBMAインタフェース(NBMAサブネットワークに付けられていないインタフェース)の上で受ける交通で運転されるような方法でルータを構成するだろうことです。 ルータによってNBMAが付属しているインタフェースの上に受けられた交通はNHRP Resolution Requestsの引き金とならないでしょう。 そのようなルータは管理手段によるNHRPドミノ効果を避けます。
Luciani, et. al. Standards Track [Page 48] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[48ページ]。
7. NHRP over Legacy BMA Networks
7. 遺産BMAネットワークの上のNHRP
There would appear to be no significant impediment to running NHRP over legacy broadcast subnetworks. There may be issues around running NHRP across multiple subnetworks. Running NHRP on broadcast media has some interesting possibilities; especially when setting up a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both end stations are legacy attached. This use for NHRP requires further research.
走行NHRPのどんな重要な障害も遺産放送サブネットワークの上であるように見えないでしょう。 問題が複数のサブネットワークのむこうに走行NHRPの周りにあるかもしれません。 電波媒体でNHRPを走らせるのにおいて、いくつかのおもしろい可能性があります。 特にセットアップするとき、1か端のステーションの両方が遺産であるときに、相互ELANのために深く切っている相互LIS/LAG交通は付きました。 NHRPのこの使用はさらなる研究を必要とします。
8. Discussion
8. 議論
The result of an NHRP Resolution Request depends on how routing is configured among the NHSs of an NBMA subnetwork. If the destination station is directly connected to the NBMA subnetwork and the routed path to it lies entirely within the NBMA subnetwork, the NHRP Resolution Replies always return the NBMA address of the destination station itself rather than the NBMA address of some egress router. On the other hand, if the routed path exits the NBMA subnetwork, NHRP will be unable to resolve the NBMA address of the destination, but rather will return the address of the egress router. For destinations outside the NBMA subnetwork, egress routers and routers in the other subnetworks should exchange routing information so that the optimal egress router may be found.
NHRP Resolution Requestの結果はルーティングがNBMAサブネットワークのNHSsの中でどう構成されるかに依存します。 目的地ステーションが直接NBMAサブネットワークにつなげられて、それへの発送された経路がNBMAサブネットワークに完全に属すなら、NHRP Resolution Repliesはいつも何らかの出口ルータのNBMAアドレスよりむしろ目的地ステーション自体のNBMAアドレスを返します。 他方では、発送された経路がNBMAサブネットワークを出ると、NHRPは目的地のNBMAアドレスを決議できませんが、むしろ出口ルータのアドレスを返すでしょう。 NBMAサブネットワークの外の目的地と、他のサブネットワークの出口ルータとルータは、最適の出口ルータを見つけることができるようにルーティング情報を交換するべきです。
In addition to NHSs, an NBMA station could also be associated with one or more regular routers that could act as "connectionless servers" for the station. The station could then choose to resolve the NBMA next hop or just send the packets to one of its connectionless servers. The latter option may be desirable if communication with the destination is short-lived and/or doesn't require much network resources. The connectionless servers could, of course, be physically integrated in the NHSs by augmenting them with internetwork layer switching functionality.
また、NHSsに加えて、NBMAステーションもステーションへの「コネクションレスなサーバ」として機能できた1つ以上の通常のルータに関連しているかもしれません。 そして、ステーションは、次のNBMAが跳ぶか、またはただコネクションレスなサーバの1つにパケットを送ると決議するのを選ぶことができました。 目的地とのコミュニケーションが短命である、そして/または、多くのネットワーク資源を必要としないなら、後者のオプションは望ましいかもしれません。 もちろんNHSsでインターネットワーク層の切り換えの機能性に従って彼らを増大させることによって、物理的にコネクションレスなサーバを統合できるでしょう。
9. IANA Considerations
9. IANA問題
IANA will take advice from the Area Director appointed designated subject matter expert, in order to assign numbers from the various number spaces described herein. In the event that the Area Director appointed designated subject matter expert is unavailable, the relevant IESG Area Director will appoint another expert. Any and all requests for value assignment within a given number space will be accepted when the usage of the value assignment documented. Possible forms of documentantion include, but is not limited to, RFCs or the product of another cooperative standards body (e.g., the MPOA and LANE subworking group of the ATM Forum).
IANAは指定された内容の専門家に任命されたAreaディレクターから忠告を受け入れるでしょう、ここに説明された様々な数の空間から数を割り当てるために。 指定された内容の専門家に任命されたAreaディレクターが入手できない場合、関連IESG Areaディレクターは別の専門家を任命するでしょう。 記録された値の課題の用法であるときに、与えられた数のスペースの中の値の課題を求めるありとあらゆる要求を受け入れるでしょう。 documentantionの可能なフォームが含んでいる、別の協力的な標準化団体(例えば、ATM Forumのグループを「副-働」かせるMPOAとレイン)の有限でなくて、RFCsか製品です。
Luciani, et. al. Standards Track [Page 49] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[49ページ]。
References
参照
[1] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol (NARP)", RFC 1735, December 1994.
[1]Heinanen、J.、およびR.Govindan、「NBMAアドレス解決プロトコル(NARP)」、RFC1735 1994年12月。
[2] Plummer, D., "Address Resolution Protocol", STD 37, RFC 826, November 1982.
[2] プラマー、D.、「アドレス解決プロトコル」、STD37、RFC826、1982年11月。
[3] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[3] Laubach、M.、J.アルペルン、および「気圧での古典的なIPとARP」、RFC2225、4月1998日
[4] Piscitello,, D., and J. Lawrence, "Transmission of IP datagrams over the SMDS service", RFC 1209, March 1991.
[4] Piscitello、D.、およびJ.ローレンス、「SMDSサービスの上のIPデータグラムのトランスミッション」、RFC1209、3月1991日
[5] Protocol Identification in the Network Layer, ISO/IEC TR 9577:1990.
[5] 1990年にネットワーク層、ISO/IEC TR9577:識別について議定書の中で述べてください。
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[6] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[7] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。
[8] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, August 1992.
[8] Malis、A.、ロビンソン、D.、およびR.ウルマン、「Multiprotocolはパケット形態によるX.25とISDNで内部連絡します」、RFC1356、1992年8月。
[9] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, July 1993.
1993年7月の[9]ブラッドリーとT.とブラウン、C.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」RFC1490。
[10] Rekhter, Y., and D. Kandlur, ""Local/Remote" Forwarding Decision in Switched Data Link Subnetworks", RFC 1937, May 1996.
[10] Rekhter(Y.、およびD.Kandlur、「切り換えられたデータ・リンクサブネットワークでの「地方かリモートな」推進決定」、RFC1937)は1996がそうするかもしれません。
[11] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[11] アーミテージ、G.、「UNI3.0/3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1996年11月。
[12] Luciani, J., Armitage, G., and J. Halpern, "Server Cache Synchronization Protocol (SCSP) - NBMA", RFC 2334, April 1998.
[12] J.、アーミテージ、G.、およびJ.アルペルン、Lucianiに、「サーバキャッシュ同期は(SCSP)について議定書の中で述べます--NBMA」、RFC2334、4月1998日
[13] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork", Work In Progress.
[13] Y.、「NBMAサブネットワークの目的地へのNHRP」というRekhterは進行中で働いています。
[14] Luciani, J., et. al., "Classical IP and ARP over ATM to NHRP Transition", Work In Progress.
et[14]Luciani、J.、アル、「NHRPへの気圧での古典的なIPとARPは移行する」Work In Progress。
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[15] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Luciani, et. al. Standards Track [Page 50] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[50ページ]。
[16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[16]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
Acknowledgments
承認
We would like to thank (in no particular order) Thomas Narten of IBM for his comments in the role of Internet AD, Juha Heinenan of Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP and the original NHRP draft, which served as the basis for this work. Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco, and Grenville Armitage of Bellcore should also be acknowledged for comments and suggestions that improved this work substantially. We would also like to thank the members of the ION working group of the IETF, whose review and discussion of this document have been invaluable.
インターネットADの役割における彼のコメントのためのIBMのトーマスNartenとテレコムフィンランドのユハHeinenanとNBMA ARPへの彼らの作業とオリジナルのNHRP草稿のためのISIのRamesh Govidanに感謝申し上げます(特に決まった順番でなく)。(草稿はこの仕事の基礎として機能しました)。 また、コクチマス、およびBellcoreのグレンビルアーミテージのIBMのラッセル・ガルド、AdaptiveのJohn Burnett、ANSのデニスファーガソン、ベイネットワークスのアンドレFredette、Newbridgeのジョエル・アルペルン、NTTのポール・フランシス、トニー・李、ブライアン・グリーソン、およびヤコフRekhterは実質的にこの仕事を改良したコメントと提案のために承認されるべきです。 また、このドキュメントのレビューと議論が非常に貴重であるIETFのIONワーキンググループのメンバーに感謝申し上げます。
Authors' Addresses
作者のアドレス
James V. Luciani Dave Katz Bay Networks cisco Systems 3 Federal Street 170 W. Tasman Dr. Mail Stop: BL3-03 San Jose, CA 95134 USA Billerica, MA 01821 Phone: +1 408 526 8284 Phone: +1 978 916 4734 EMail: dkatz@cisco.com EMail: luciani@baynetworks.com
ジェームスV.LucianiデーヴキャッツベイネットワークスコクチマスSystems3の連邦政府の通り170W.タスマン博士メールStop: BL3-03カリフォルニア95134サンノゼ(米国)ビルリカ、MA 01821は以下に電話をします。 +1 8284が電話をする408 526: +1 4734年の978 916メール: dkatz@cisco.com メール: luciani@baynetworks.com
David Piscitello Bruce Cole Core Competence Juniper Networks 1620 Tuckerstown Road 3260 Jay St. Dresher, PA 19025 USA Santa Clara, CA 95054 Phone: +1 215 830 0692 Phone: +1 408 327 1900 EMail: dave@corecom.com EMail: bcole@jnx.com
Tuckerstown道路3260ジェイ通りDresher、PA19025米国サンタクララ、カリフォルニア 95054が電話をするデヴィッドPiscitelloブルースコールコアコンピタンス杜松ネットワーク1620: +1 0692が電話をする215 830: +1 1900年の408 327メール: dave@corecom.com メール: bcole@jnx.com
Naganand Doraswamy Bay Networks, Inc. 3 Federal Street Mail Stop: Bl3-03 Billerica, MA 01801 Phone: +1 978 916 1323 EMail: naganand@baynetworks.com
Naganand DoraswamyベイネットワークスInc.3の連邦政府の通りメール停止: Bl3-03ビルリカ、MA 01801は以下に電話をします。 +1 1323年の978 916メール: naganand@baynetworks.com
Luciani, et. al. Standards Track [Page 51] RFC 2332 NBMA NHRP April 1998
et Luciani、アル。 規格はNBMA NHRP1998年4月にRFC2332を追跡します[51ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Luciani, et. al. Standards Track [Page 52]
et Luciani、アル。 標準化過程[52ページ]
一覧
スポンサーリンク
