RFC2333 日本語訳

Network Working Group                                        D. Cansever
Request for Comments: 2333                        GTE Laboratories, Inc.
Category: Standards Track                                     April 1998

Canseverがコメントのために要求するワーキンググループD.をネットワークでつないでください: 2333年のGTE研究所Inc.カテゴリ: 標準化過程1998年4月

                 NHRP Protocol Applicability Statement

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

要約

   As required by the Routing Protocol Criteria [RFC 1264], this memo
   discusses the applicability of the Next Hop Resolution Protocol
   (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access
   (NBMA) networks, such as ATM, SMDS and X.25.

必要に応じて、ルート設定プロトコルCriteria[RFC1264]で、このメモはNon-放送Multiple Access(NBMA)ネットワークの上でIPデータグラムのルーティングでNext Hop Resolutionプロトコル(NHRP)の適用性について議論します、ATMや、SMDSやX.25などのように。

1. Protocol Documents

1. プロトコルドキュメント

   The NHRP protocol description is defined in [1].  The NHRP MIB
   description is defined in [2].

NHRPプロトコル記述は[1]で定義されます。 NHRP MIB記述は[2]で定義されます。

2. Introduction

2. 序論

   This document summarizes the key features of NHRP and discusses the
   environments for which the protocol is well suited.  For the purposes
   of description, NHRP can be considered a generalization of Classical
   IP and ARP over ATM which is defined in [3] and of the Transmission
   of IP Datagrams over the SMDS Service, defined in [4].  This
   generalization occurs in 2 distinct directions.

このドキュメントは、NHRPに関する重要な特色をまとめて、プロトコルがよく合っている環境について議論します。 記述の目的のために、[3]で定義されるATMの上のClassical IPとARPと[4]で定義されたSMDS Serviceの上のIPデータグラムのTransmissionの一般化であるとNHRPを考えることができます。 この一般化は2つの異なった方向に起こります。

   Firstly, NHRP avoids the need to go through extra hops of routers
   when the Source and Destination belong to different Logical Internet
   Subnets (LIS).  Of course, [3] and [4] specify that when the source
   and destination belong to different LISs, the source station must
   forward data packets to a router that is a member of multiple LISs,
   even though the source and destination stations may be on the same
   logical NBMA network.  If the source and destination stations belong
   to the same logical NBMA network, NHRP provides the source station

まず第一に、SourceとDestinationが異なったLogicalインターネットSubnets(LIS)に属すと、NHRPはルータの付加的なホップを通る必要性を避けます。 もちろん、[3]と[4]は、ソースと目的地が異なったLISsに属すと、発信局が複数のLISsのメンバーであるルータにデータ・パケットを送らなければならないと指定します、ソースと目的地ステーションが同じ論理的なNBMAネットワークにあるかもしれませんが。 ソースと目的地ステーションが同じ論理的なNBMAネットワークのものなら、NHRPは発信局を提供します。

Cansever                    Standards Track                     [Page 1]

RFC 2333              NHRP Protocol Applicability             April 1998

Cansever標準化過程[1ページ]RFC2333NHRPは適用性1998年4月に議定書を作ります。

   with an inter-LIS address resolution mechanism at the end of which
   both stations can exchange packets without having to use the services
   of intermediate routers.  This feature is also referred to as
   "short-cut" routing.  If the destination station is not part of the
   logical NBMA network, NHRP provides the source with the NBMA address
   of the current egress router towards the destination.

終わりのそれの相互LISアドレス解決メカニズムで、中間的ルータのサービスを利用する必要はなくて、両方のステーションはパケットを交換できます。 また、この特徴は「ショートカット」ルーティングと呼ばれます。 目的地ステーションが論理的なNBMAネットワークの一部でないなら、NHRPは目的地に向かった現在の出口ルータのNBMAアドレスをソースに提供します。

   The second generalization is that NHRP is not specific to a
   particular NBMA technology.  Of course, [3] assumes an ATM network
   and [4] assumes an SMDS network at their respective subnetwork
   layers.

2番目の一般化はNHRPが特定のNBMA技術に特定でないということです。 もちろん、[3]はATMネットワークを仮定します、そして、[4]は彼らのそれぞれのサブネットワーク層でSMDSネットワークを仮定します。

   NHRP is specified for resolving the destination NBMA addresses of IP
   datagrams over IP subnets within a large NBMA cloud.  NHRP has been
   designed to be extensible to network layer protocols other than IP,
   possibly subject to other network layer protocol specific additions.

NHRPは大きいNBMA雲の中でIPサブネットの上でIPデータグラムの送付先NBMAアドレスを決議するのに指定されます。 NHRPは、IPと、ことによると他のネットワーク層プロトコルの特定の追加を条件としてネットワーク層プロトコルに広げることができるように設計されています。

   As an important application of NHRP, the Multiprotocol Over ATM
   (MPOA) Working Group of the ATM Forum has decided to adopt and to
   integrate NHRP into its MPOA Protocol specification [5].  As such,
   NHRP will be used in resolving the ATM addresses of MPOA packets
   destined outside the originating subnet.

NHRP、採用して、統合するATM Forumの作業部会がNHRPを決めたMultiprotocol Over ATM(MPOA)の重要なアプリケーション、そのMPOAプロトコル仕様[5]。 そういうものとして、NHRPは起因するサブネットの外で運命づけられたMPOAパケットのATMアドレスを決議する際に使用されるでしょう。

3. Key Features

3. 重要な特色

   NHRP provides a mechanism to obtain the NBMA network address of the
   destination, or of a router along the path to the destination. NHRP
   is not a routing protocol, but may make use of routing information.
   This is further discussed in Section 5.

NHRPは、経路に沿って目的地、またはルータのNBMAネットワーク・アドレスを目的地に得るためにメカニズムを提供します。 NHRPはルーティング・プロトコルではありませんが、ルーティング情報を利用するかもしれません。 セクション5でさらにこれについて議論します。

   The most prominent feature of NHRP is that it avoids extra router
   hops in an NBMA with multiple LISs.  To this goal, NHRP provides the
   source with the NBMA address of the destination, if the destination
   is directly attached to the NBMA. If the destination station is not
   attached to the NBMA, then NHRP provides the source with the NBMA
   address of an exit router that has connectivity to the destination.
   In general, there may be multiple exit routers that have connectivity
   to the destination.  If NHRP uses the services of a dynamic routing
   algorithm in fulfilling its function, which is necessary for robust
   and scalable operation, then the exit router identified by NHRP
   reflects the selection made by the network layer dynamic routing
   protocol.  In general, the selection made by the routing protocol
   would often reflect a desirable attribute, such as identifying the
   exit router that induces the least number of hops in the original
   routed path.

NHRPの最も際立った特徴は複数のLISsとNBMAで付加的なルータホップを避けるということです。 この目標に、NHRPは目的地のNBMAアドレスをソースに提供します、目的地が直接NBMAに付けられるなら。 目的地ステーションがNBMAに付けられないなら、NHRPは目的地に接続性を持っている出口ルータのNBMAアドレスをソースに提供します。 一般に、目的地に接続性を持っている複数の出口ルータがあるかもしれません。 NHRPが機能を発揮することにおける、ダイナミックルーティングアルゴリズムのサービス(強健でスケーラブルな操作に必要である)を利用するなら、NHRPによって特定された出口ルータはネットワーク層ダイナミックルーティングプロトコルによってされた選択を反映します。 一般に、ルーティング・プロトコルによってされた選択はしばしば望ましい属性を反映して、それが最少の数を引き起こす出口ルータは特定しているように元の発送された経路を跳びます。

Cansever                    Standards Track                     [Page 2]

RFC 2333              NHRP Protocol Applicability             April 1998

Cansever標準化過程[2ページ]RFC2333NHRPは適用性1998年4月に議定書を作ります。

   NHRP is defined for avoiding extra hops in the delivery of IP packets
   with a single destination.  As such, it is not intended for direct
   use in a point-to-multipoint communication setting.  However,
   elements of NHRP may be used in certain multicast scenarios for the
   purpose of providing short cut routing. Such an effort is discussed
   in [6].  In this case, NHRP would avoid intermediate routers in the
   multicast path. The scalability of providing short-cut paths in a
   multicast environment is an open issue.

NHRPは、単一の目的地があるIPパケットの配送で付加的なホップを避けるために定義されます。 そういうものとして、それはポイントツーマルチポイントコミュニケーション設定でのダイレクト使用のために意図しません。 しかしながら、NHRPの要素はショートカットルーティングを提供する目的に、あるマルチキャストシナリオで使用されるかもしれません。 [6]でそのような取り組みについて議論します。 この場合、NHRPはマルチキャスト経路で中間的ルータを避けるでしょう。 マルチキャスト環境における、短いカットの経路を提供するスケーラビリティは未解決の問題です。

   NHRP can be used in host-host, host-router and router-host
   communications.  When used in router-router communication, NHRP (as
   defined in [1]) can produce persistent routing loops if the
   underlying routing protocol looses information critical to loop
   suppression. This may occur when there is a change in router metrics
   across the autonomous system boundaries.  NHRP for router-router
   communication that avoids persistent forwarding loops will be
   addressed in a separate document.

ホスト兼ホスト、ホストルータ、およびルータホストコミュニケーションでNHRPを使用できます。 NHRP、いつが中でルータルータコミュニケーションを使用したか。([1])で定義されるように、基本的なルーティング・プロトコルが抑圧を輪にするために重要な情報を発射するなら、永続的なルーティング輪を生産できます。 ルータ測定基準における変化が自律システム境界のむこうにあるとき、これは起こるかもしれません。 永続的な推進輪を避けるルータルータコミュニケーションのためのNHRPは別々のドキュメントで扱われるでしょう。

   A special case of router-router communication where loops will not
   occur is when the destination host is directly adjacent to the non-
   NBMA interface of the egress router.  If it is believed that the
   adjacency of the destination station to the egress router is a stable
   topological configuration, then NHRP can safely be used in this
   router-router communication scenario.  If the NHRP Request has the Q
   bit set, indicating that the requesting party is a router, and if the
   destination station is directly adjacent to the egress router as a
   stable topological configuration, then the egress router can issue a
   corresponding NHRP reply.  If the destination is not adjacent to the
   egress router, and if Q bit is set in the Request, then a safe mode
   of operation for the egress router would be to issue a negative NHRP
   Reply (NAK) for this particular request, thereby enforce data packets
   to follow the routed path.

輪が現れないルータルータコミュニケーションの特別なケースはあて先ホストが直接出口ルータの非NBMAのインタフェースに隣接している時です。 出口ルータへの目的地ステーションの隣接番組が安定した位相的な構成であると信じられているなら、このルータルータコミュニケーションシナリオで安全にNHRPを使用できます。 NHRP RequestがQビットを設定させるなら、要求がパーティーへ行くのを示すのは、ルータです、そして、目的地ステーションが直接安定した位相的な構成としての出口ルータに隣接しているなら、出口ルータは対応するNHRP回答を発行できます。 目的地が出口ルータに隣接していないで、QビットがRequestに設定されるなら、出口ルータのための操作の安全なモードは、この特定の要求のために、否定的NHRP Reply(NAK)を発行して、その結果、発送された経路に続くようにデータ・パケットを実施するだろうことです。

   As a result of having inter-LIS address resolution capability, NHRP
   allows the communicating parties to exchange packets by fully
   utilizing the particular features of the NBMA network.  One such
   example is the use of QoS guarantees when the NMBA network is ATM.

相互LISアドレス解決能力を持っていることの結果、NHRPは、NBMAネットワークの特定の特徴を完全に利用することによってパケットを交換するために交信にパーティーを許容します。 NMBAネットワークがATMであるときに、その一例はQoS保証の使用です。

   Here, due to short-cut routing, ATM provided QoS guarantees can be
   implemented without having to deal with the issues of re-assembling
   and re-segmenting IP packets at each network layer hop.

ここを、各ネットワーク層で組み立て直すのと再区分IPパケットの問題に対処する必要はなくてQoS保証を実装することができるなら、ショートカットルーティングのため、ATMは跳びます。

   NHRP protocol can be viewed as a client-server interaction.  An NHRP
   Client is the one who issues an NHRP Request. An NHRP Server is the
   one who issues a reply to an NHRP request, or the one who forwards a
   received NHRP request to another Server. Of course, an NHRP entity
   may act both as a Client and a Server.

クライアント/サーバ相互作用としてNHRPプロトコルを見なすことができます。 NHRP ClientはNHRP Requestを発行する人です。 NHRP ServerはNHRP要求に回答を発行するか、または受信されたNHRP要求を転送する人を別のServerに発行する人です。もちろん、NHRP実体はClientとServerとして機能するかもしれません。

Cansever                    Standards Track                     [Page 3]

RFC 2333              NHRP Protocol Applicability             April 1998

Cansever標準化過程[3ページ]RFC2333NHRPは適用性1998年4月に議定書を作ります。

4. Use of NHRP

4. NHRPの使用

   In general, issuing an NHRP request is an application dependent
   action [7].  For applications that do not have particular QoS
   requirements, and that are executed within a short period of time, an
   NBMA short-cut may not be a necessity. In situations where there is a
   "cost" associated with NBMA short-cuts, such applications may be
   better served by network layer hop-by-hop routing. Here, "cost" may
   be understood in a monetary context, or as additional strain on the
   equipment that implements short-cuts. Therefore, there is a trade-off
   between the "cost" of a short-cut path and its utility to the user.
   Reference [7] proposes that this trade-off should be addressed at the
   application level. In an environment consisting of LANs and routers
   that are interconnected via dedicated links, the basic routing
   decision is whether to forward a packet to a router, or to broadcast
   it locally.  Such a decision on local vs. remote is based on the
   destination address. When routing IP packets over an NBMA network,
   where there is potentially a direct Source to Destination
   connectivity with QoS options, the decision on local vs. remote is no
   longer as fundamentally important as in the case where packets have
   to traverse routers that are interconnected via dedicated links.
   Thus, in an NBMA network with QoS options, the basic decision becomes
   the one of short-cut vs. hop-by-hop network layer routing.  In this
   case, the relevant criterion becomes applications' QoS requirements
   [7]. NHRP is particularly applicable for environments where the
   decision on local vs. remote is superseded by the decision on short-
   cut vs. hop-by-hop network layer routing.

一般に、NHRP要求を出すのは、アプリケーションに依存する動作[7]です。 特定のQoS要件を持たないで、短期間以内に作成されるアプリケーションにおいてNBMAショートカットは必要性でないかもしれません。 NBMAショートカットに関連している「費用」がある状況で、ホップごとのネットワーク層ルーティングでそのようなアプリケーションに役立つほうがよいです。 ここで、「費用」は通貨の文脈か、ショートカットを実装する設備における追加緊張として理解されるかもしれません。 したがって、ショートカット経路の「費用」とユーザへのそのユーティリティの間には、トレードオフがあります。 参照[7]は、このトレードオフがアプリケーションレベルで扱われるべきであるよう提案します。 専用リンクを通してインタコネクトされるLANとルータから成る環境で、基本的なルーティング決定はパケットをルータに送るか、または局所的にそれを放送するということです。 リモートに対する地方のそのような決定は送付先アドレスに基づいています。 NBMAネットワークの上にIPパケットを発送するとき、リモートに対する地方の決定はもう基本的にケースほど中パケットが専用リンクを通してインタコネクトされるルータを横断しなければならない重要ではありません。そこに、Destinationの接続性へのダイレクトSourceがQoSオプションと共に潜在的にあります。 したがって、QoSオプションがあるNBMAネットワークでは、基本的な決定はショートカット対ホップごとのネットワーク層ルーティングの1つになります。 この場合、関連評価基準はアプリケーションのQoS要件[7]になります。 環境には、NHRPは短いカットの決定でリモートに対する地方の決定がホップごとのネットワーク層ルーティングに対して取って代わられるところで特に適切です。

   Let us assume that the trade-off is in favor of a short-cut NBMA
   route.  Generally, an NHRP request can be issued by a variety of NHRP
   aware entities, including hosts and routers with NBMA interfaces.  If
   an IP packet traverses multiple hops before a short-cut path has been
   established, then there is a chance that multiple short-cut paths
   could be formed. In order to avoid such an undesirable situation, a
   useful operation rule is to authorize only the following entities to
   issue an NHRP request and to perform short-cut routing.

トレードオフがショートカットNBMAルートを支持してあると仮定しましょう。 一般に、さまざまなNHRPの意識している実体でNHRP要求を出すことができます、NBMAインタフェースがあるホストとルータを含んでいて。 ショートカット経路が確立される前にIPパケットが複数のホップを横断するなら、複数のショートカット経路を形成できたという見込みがあります。 そのような望ましくない状況を避けるために、役に立つ操作規定は以下の実体だけがNHRP要求を出して、ショートカットルーティングを実行するのを認可することです。

     i)  The host that originates the IP packet, if the host has an NBMA
         interface.
     ii) The first router along the routing path of the IP packet such
         that the next hop is reachable through the NBMA interface of
         that particular router.
    iii) A policy router within an NBMA network through which the IP
         packet has to traverse.

i) IPパケットを溯源するホストホストがNBMAに. iiを連結させるなら 最初のルータ、IPパケットのルーティング経路に沿って、次が跳ぶようなものはそんなに特定のルータiii)のNBMAインタフェースを通して届いています。 IPパケットが横断しなければならないNBMAネットワークの中で終えた方針ルータ。

Cansever                    Standards Track                     [Page 4]

RFC 2333              NHRP Protocol Applicability             April 1998

Cansever標準化過程[4ページ]RFC2333NHRPは適用性1998年4月に議定書を作ります。

5. Protocol Scalability

5. プロトコルスケーラビリティ

   As previously indicated, NHRP is defined for the delivery of IP
   packets with a single destination. Thus, this discussion is confined
   to a unicast setting.  The scalability of NHRP can be analyzed at
   three distinct levels:

同じくらい以前示されて、NHRPは単一の目的地があるIPパケットの配送のために定義されます。 したがって、この議論はユニキャスト設定に閉じ込められます。 3つの異なったレベルでNHRPのスケーラビリティを分析できます:

     o Client level
     o LIS level
     o Domain level

o クライアントレベルo LISレベルo Domainレベル

   At the the Client level, the scalability of NHRP is affected by the
   processing and memory limitations of the NIC that provides interface
   to the NBMA network.  When the NBMA network is connection oriented,
   such as ATM, NIC limitations may bound the scalability of NHRP in
   certain applications.  For example, a server that handles hundreds of
   requests per second using an ATM interface may be bounded by the
   performance characteristics of the corresponding NIC.  Similarly,
   when the NHRP Client resides at an NBMA interface of a router, memory
   and processing limitations of router's NIC may bound the scalability
   of NHRP.  This is because routers generally deal with an aggregation
   of traffic from multiple sources, which in turn creates a potentially
   large number of SVCCs out of the router's NBMA interface.

Clientレベルでは、NHRPのスケーラビリティは処理で影響を受けます、そして、提供するNICのメモリ限界はNBMAネットワークに連結します。 NBMAネットワークがATM、NICなどのような指向の接続であるときに、制限はバウンドするかもしれません。あるアプリケーションにおけるNHRPのスケーラビリティ。 例えば、ATMインタフェースを使用するのがあるかもしれない1秒あたり何百もの要求を扱うサーバは対応するNICの性能の特性でバウンドしました。 同様に、NHRP Clientが住んでいると、ルータのNICのルータのNBMAインタフェース、メモリ、および処理限界のときに、NHRPのスケーラビリティはバウンドしているかもしれません。 これはルータが一般に複数のソースからのルータのNBMAインタフェースから多くのSVCCsを順番に作成するトラフィックの集合に対処するからです。

   At the LIS level, the main issue is to maintain and deliver a sizable
   number of NBMA to Network layer address mappings within large LISs.
   To this goal, NHRP implementations can use the services of the Server
   Cache Synchronization Protocol (SCSP) [8] that allows multiple
   synchronized NHSs within an LIS, and hence resolve the associated
   scalability issue.

LISレベルでは、本題は、大きいLISsの中のNetwork層のアドレス・マッピングにNBMAのかなり大きい数を維持して、提供することです。 この目標に、NHRP実装は、LISの中の複数の連動しているNHSsを許容するServer Cache Synchronizationプロトコル(SCSP)[8]のサービスを利用して、したがって、関連スケーラビリティ問題を解決できます。

   At the NHRP Domain level, network layer routing is used in resolving
   the NBMA address of a destination outside the LIS.  As such, the
   scalability of NHRP is closely tied to the scalability of the network
   layer routing protocol used by NHRP.  Dynamic network layer routing
   protocols are proven to scale well.  Thus, when used in conjunction
   with dynamic routing algorithms, at the NHRP domain level, NHRP
   should scale in the same order as the routing algorithm, subject to
   the assumption that all the routers along the path are NHRP aware.
   If an NHRP Request is processed by a router that does not implement
   NHRP, it will be silently discarded.  Then, short-cuts cannot be
   implemented and connectivity will be provided on a hop-by-hop basis.

NHRP Domainレベルでは、ネットワーク層ルーティングはLISの外で目的地のNBMAアドレスを決議する際に使用されます。 そういうものとして、NHRPのスケーラビリティは密接にNHRPによって使用されたネットワーク層ルーティング・プロトコルのスケーラビリティに結ばれます。 ダイナミックなネットワーク層ルーティング・プロトコルがよく比例すると立証されます。 したがって、ダイナミックルーティングアルゴリズムに関連してNHRPドメインレベルに使用されると、NHRPは経路に沿ったすべてのルータがNHRP意識しているという仮定を条件としてルーティング・アルゴリズムとして同次を計量するはずです。 NHRP RequestがNHRPを実装しないルータによって処理されると、それは静かに捨てられるでしょう。 次に、ショートカットを実装することができません、そして、ホップごとのベースで接続性を提供するでしょう。

   Thus, when NHRP is implemented in conjunction with dynamic network
   layer routing, a scaling requirement for NHRP is that virtually all
   the routers within a logical NBMA network should be NHRP aware.

NHRPがダイナミックなネットワーク層ルーティングに関連して実装されるとき、したがって、NHRPのためのスケーリング要件は論理的なNBMAネットワークの中のほとんどすべてのルータがNHRP意識しているべきであるということです。

Cansever                    Standards Track                     [Page 5]

RFC 2333              NHRP Protocol Applicability             April 1998

Cansever標準化過程[5ページ]RFC2333NHRPは適用性1998年4月に議定書を作ります。

   One can also use static routing in conjunction with NHRP.  Then, not
   all the routers in the NBMA network need to be NHRP aware.  That is,
   since the routers that need to process NHRP control messages are
   specified by static routing, routers that are not included in the
   manually defined static paths do not have to be NHRP aware.  Of
   course, static routing does not scale, and if the destination is off
   the NBMA network, then the use of static routing could result in
   persistently suboptimal routes.  Use of static routing also has
   fairly negative failure modes.

また、1つはNHRPに関連してスタティックルーティングを使用できます。 そして、すべてではなく、NBMAのルータは意識していた状態でNHRPである必要性をネットワークでつなぎます。 すなわち、NHRPコントロールメッセージを処理する必要があるルータがスタティックルーティングによって指定されるので、手動で定義された静的な経路に含まれていないルータはNHRP意識している必要はありません。 もちろん、スタティックルーティングは比例しません、そして、目的地がNBMAネットワークにあるなら、スタティックルーティングの使用は持続して準最適のルートをもたらすかもしれません。 また、スタティックルーティングの使用には、否定的故障モードが公正にあります。

6. Discussion

6. 議論

   NHRP does not replace existing routing protocols. In general, routing
   protocols are used to determine the proper path from a source host or
   router, or intermediate router, to a particular destination.  If the
   routing protocol indicates that the proper path is via an interface
   to an NBMA network, then NHRP may be used at the NBMA interface to
   resolve the destination IP address into the corresponding NBMA
   address.  Of course, the use of NHRP is subject to considerations
   discussed in Section 4.

NHRPは既存のルーティング・プロトコルを置き換えません。 一般に、ルーティング・プロトコルは、送信元ホストかルータからの適切な経路、または特定の目的地への中間的ルータを決定するのに使用されます。 ルーティング・プロトコルが、NBMAネットワークへのインタフェースを通して適切な経路があるのを示すなら、NHRPは、送付先IPアドレスに対応するNBMAアドレスに変えるのにNBMAインタフェースで使用されるかもしれません。 もちろん、NHRPの使用はセクション4で議論した問題を受けることがあります。

   Assuming that NHRP is applicable and the destination address has been
   resolved, packets are forwarded using the particular data forwarding
   and path determination mechanisms of the underlying NBMA network.
   Here, the sequence of events are such that route determination is
   performed by IP routing, independent of NHRP. Then, NHRP is used to
   create a short-cut track upon the path determined by the IP routing
   protocol. Therefore, NHRP "shortens" the routed path.  NHRP (as
   defined in [1]) is not sufficient to suppress persistent forwarding
   loops when used for router-router communication if the underlying
   routing protocol looses information critical to loop suppression [9].
   Work is in progress [10] to augment NHRP to enable its use for the
   router-router communication without persistent forwarding loops.

NHRPが適切であり、送付先アドレスが決定されたと仮定して、基本的なNBMAネットワークの特定のデータ推進と経路決断メカニズムを使用することでパケットを進めます。 出来事の系列がここの、そのようなものであるので、ルート決断はNHRPの如何にかかわらずIPルーティングで実行されます。 そして、NHRPは、IPルーティング・プロトコルで決定している経路にショートカット道を作成するのに使用されます。 したがって、NHRPは発送された経路を「短くします」。 NHRP、(中で定義されるように、基本的なルーティング・プロトコルが抑圧[9]を輪にするために重要な情報を発射するならルータルータコミュニケーションに使用される場合、[1])はしつこい推進輪を抑圧するために十分ではありません。 しつこい推進輪なしでルータルータコミュニケーションの使用を可能にするためにNHRPを増大させるために、進行中[10]には仕事があります。

   When the routed path keeps changing on some relatively short time
   scale, such as seconds, this situation will have an effect on the
   operation of NHRP. In certain router-router operations, changes in
   the routed path could create persistent routing loops. In host-
   router, or router-host communications, frequent changes in routed
   paths could result in inefficiencies such as frequent creation of
   short-cut paths which are short lived.

発送された経路が秒などの比較的短い何らかのタイムスケールで変化し続けるとき、この状況はNHRPの操作に影響を与えるでしょう。 あるルータルータ操作では、発送された経路の変化はしつこいルーティング輪を作成するかもしれません。 ホストルータ、またはルータホストコミュニケーションでは、発送された経路の頻繁な変化は送られた状態で短いショートカット経路の創造によく行くような非能率をもたらすかもしれません。

7. Security Considerations

7. セキュリティ問題

   NHRP is an address resolution protocol, and SCSP is a database
   synchronization protocol.  As such, they are possibly subject to
   server (for NHRP) or peer (for SCSP) spoofing and denial of service
   attacks.  They both provide authentication mechanisms to allow their

NHRPはアドレス解決プロトコルです、そして、SCSPはデータベース同期プロトコルです。 そういうものとして、それらはことによるとサーバ(NHRPのための)か同輩(SCSPのための)スプーフィングとサービス不能攻撃を受けることがあります。 それらの両方が許容する認証機構を提供する、それら

Cansever                    Standards Track                     [Page 6]

RFC 2333              NHRP Protocol Applicability             April 1998

Cansever標準化過程[6ページ]RFC2333NHRPは適用性1998年4月に議定書を作ります。

   use in environments in which spoofing is a concern.  Details can be
   found in sections 5.3.4 in [1] and B.3.1 in [8].  There are no
   additional security constraints or concerns raised in this document
   that are not already discussed in the referenced sections.

スプーフィングが関心である環境で、使用します。 [8]で[1]とB.3.1のセクション5.3.4で詳細を見つけることができます。 参照をつけられたセクションで既に議論しない本書では高められたどんな追加担保規制も関心もありません。

References

参照

   [1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and
       N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC
       2332, April 1998.

[1] Luciani、J.、キャッツ、D.、Piscitello、D.、コール、B.、およびN.Doraswamy、「次のNMBAは解決プロトコル(NHRP)を飛び越します」、RFC2332、1998年4月。

   [2] Greene, M., and J. Luciani, "NHRP Management Information Base",
       Work in Progress.

[2] グリーン、M.、およびJ.Luciani、「NHRP管理情報ベース」が進行中で働いています。

   [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] Lawrance, J., and D. Piscitello, "The Transmission of IP
       datagrams over the SMDS service", RFC 1209, March 1991.

[4]Lawrance、J.、およびD.Piscitello、「SMDSサービスの上のIPデータグラムのTransmission」、RFC1209、1991年3月。

   [5] Multiprotocol Over ATM Version 1.0, ATM Forum Document
       af-mpoa-0087.000

[5] Multiprotocol Over ATMバージョン1.0、ATM Forum Document af-mpoa-0087.000

   [6] Rekhter, Y., and D. Farinacci, "Support for Sparse Mode PIM over
       ATM", Work in Progress.

[6] Y.、およびD.ファリナッチ、「気圧でのまばらなモードPIMのサポート」というRekhterは進行中で働いています。

   [7] Rekhter, Y., and D. Kandlur, "Local/Remote" Forwarding Decision
       in Switched Data Link Subnetworks", RFC 1937, May 1996.

[7] 「Rekhter、Y.、およびD.Kandlur、「地方かリモートな」推進決定は中でデータ・リンクサブネットワークを切り換えた」RFC1937は1996がそうするかもしれません。

   [8] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server
       Cache Synchronization Protocol (SCSP) - NBMA", RFC 2334, April
       1998.

[8] Luciani、J.、アーミテージ、G.、アルペルン、J.、およびN.Doraswamy、「サーバキャッシュ同期は(SCSP)について議定書の中で述べます--NBMA」、RFC2334、1998年4月。

   [9] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework
       Document", RFC 1932, April 1996.

[9] コール、R.、シュル、D.、およびC.Villamizar、「気圧でのIP:」 「枠組みのドキュメント」、RFC1932、1996年4月。

   [10] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork",
        Work in Progress.

[10] Y.、「NBMAサブネットワークの目的地へのNHRP」というRekhterは進行中で働いています。

Acknowledgements

承認

   The author acknowledges valuable contributions and comments from many
   participants of the ION Working Group, in particular from Joel
   Halpern of Newbridge Networks, David Horton of Centre for Information
   Technology Research, Andy Malis of Nexion, Yakov Rekhter and George
   Swallow of Cisco Systems and Curtis Villamizar of ANS.

作者はION作業部会の多くの関係者から有価約因とコメントを承諾します、特にニューブリッジネットワークスのジョエル・アルペルン、情報Technology ResearchのためのCentreのデヴィッドホートン、NexionのアンディMalis、シスコシステムズのヤコフRekhterとジョージSwallow、およびANSのカーティスVillamizarから。

Cansever                    Standards Track                     [Page 7]

RFC 2333              NHRP Protocol Applicability             April 1998

Cansever標準化過程[7ページ]RFC2333NHRPは適用性1998年4月に議定書を作ります。

Author's Address

作者のアドレス

   Derya H. Cansever
   GTE Laboratories Inc.
   40 Sylvan Rd. MS 51
   Waltham MA 02254

Derya H.Cansever GTE研究所株式会社40森の精、通り MS51ウォルサムMA 02254

   Phone: +1 617 466 4086
   EMail: dcansever@gte.com

以下に電話をしてください。 +1 4086年の617 466メール: dcansever@gte.com

Cansever                    Standards Track                     [Page 8]

RFC 2333              NHRP Protocol Applicability             April 1998

Cansever標準化過程[8ページ]RFC2333NHRPは適用性1998年4月に議定書を作ります。

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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Cansever                    Standards Track                     [Page 9]

Cansever標準化過程[9ページ]