RFC2335 日本語訳

2335 A Distributed NHRP Service Using SCSP. J. Luciani. April 1998. (Format: TXT=14007 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                         J. Luciani
Request for Comments: 2335                                  Bay Networks
Category: Standards Track                                     April 1998

Lucianiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2335年のベイネットワークスカテゴリ: 標準化過程1998年4月

                 A Distributed NHRP Service Using SCSP

SCSPを使用する分配された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 a method for distributing an NHRP service
   within a LIS [1].  This method uses the Server Cache Synchronization
   Protocol (SCSP) [2] to synchronize the client information databases
   held by NHRP Servers (NHSs) within a LIS.

このドキュメントはLIS[1]の中にNHRPサービスを広げるためのメソッドを説明します。 このメソッドは、LISの中でNHRP Servers(NHSs)によって保持されたクライアント情報データベースを同期させるのにServer Cache Synchronizationプロトコル(SCSP)[2]を使用します。

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 [4].

キーワードが解釈しなければならない、本書では現れるとき、[4]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?

   NHRP Clients (NHCs) register their existence and reachability
   information with NHRP Servers (NHSs).  There may be multiple NHSs in
   a given Logical IP Subnet (LIS).  NHCs do not necessarily register
   with all NHSs in a LIS; however, all NHCs need to be able to query at
   least one NHS about any NHC within the LIS.  Thus, the contents of
   the NHS databases in a LIS need to be synchronized across the LIS.
   The Server Cache Synchronization Protocol (SCSP) solves the
   generalized server synchronization/cache-replication problem for
   distributed databases and thus SCSP may be applied to the NHS
   database synchronization problem within the LIS.

NHRP Clients(NHCs)は彼らの存在と可到達性情報をNHRP Servers(NHSs)に示します。 複数のNHSsが与えられたLogical IP Subnet(LIS)にあるかもしれません。 NHCsは必ずLISのすべてのNHSsとともに記名するというわけではありません。 しかしながら、すべてのNHCsが、LISの中のどんなNHCに関しても少なくとも1NHSについて質問できる必要があります。 したがって、LISのNHSデータベースの内容は、LISの向こう側に連動する必要があります。 Server Cache Synchronizationプロトコル(SCSP)は分散データベースのための一般化されたサーバキャッシュ同期/模写問題を解決します、そして、その結果、SCSPはLISの中のNHSデータベース同期問題に当てはまられるかもしれません。

Luciani                     Standards Track                     [Page 1]

RFC 2335                    NHRP Using SCSP                   April 1998

1998年4月にSCSPを使用するLuciani標準化過程[1ページ]RFC2335NHRP

   SCSP is defined in two parts: the protocol independent part and the
   client/server protocol specific part.  The protocol independent part
   is defined in [2] whereas this document will specify the
   client/server protocol specific part where NHRP is the client/server
   protocol.

SCSPは2つの部品で定義されます: プロトコルの独立している一部とクライアント/サーバは特定の部分について議定書の中で述べます。 [2] このドキュメントはクライアント/サーバプロトコル特定のパートどこNHRPを指定するだろうか、しかし、独立している部分が定義されるプロトコルはクライアント/サーバプロトコルです。

   This document is separate from [2] because it was felt that it was
   desirable to allow the client/server protocol specific part
   specification for NHRP to progress independently from the protocol
   independent specification.

NHRPが独自に進歩をするようにクライアント/サーバプロトコルに特定の部分仕様を許容するのが望ましいと感じられたので、このドキュメントは[2]からプロトコルの独立している仕様から別々です。

2. Overview

2. 概要

   All NHSs belonging to a Logical IP Subnet (LIS) [1] are said to
   belong to a Server Group (SG).  An SG is identified by, not
   surprisingly, its SGID which is contained in a field in all SCSP
   packets.  All SCSP packets contain a Protocol ID (PID) field as well.
   This PID field is set to 0x0002 to signify that SCSP synchronizing
   NHS databases as opposed to synchronizing some other protocol's
   databases (see Section B.2.0.1 of [2] for more details).  In general,
   PIDs for SCSP will be assigned by IANA as described in Section C of
   [2].  In the case of NHRP, the client/server protocol specific
   specification was initially written at the same time as SCSP, and
   thus a PID=0x0002 was assigned by the author.

Logical IP Subnet(LIS)[1]に属すすべてのNHSsがServer Group(SG)に属すと言われています。 すべてのSCSPパケットの分野に保管されているSGID、SGは当然ながら特定されます。 すべてのSCSPパケットがまた、Protocol ID(PID)分野を含んでいます。 0×0002にこのPID分野がある他のプロトコルのデータベースを同期させることと対照的にNHSデータベースを同期させるそのSCSPを意味するように設定されます(その他の詳細のための[2]のセクションB.2.0.1を見てください)。 一般に、SCSPのためのPIDsは[2]のセクションCで説明されるようにIANAによって割り当てられるでしょう。 NHRPの場合では、特定の仕様が初めはSCSP、およびその結果、PIDと同時に書かれたクライアント/サーバプロトコル=0×0002は作者によって割り当てられました。

   SCSP places no topological requirements upon an NHRP SG.  Obviously,
   however, the resultant graph of NHSs must span the set of NHSs to be
   synchronized.  For more information about the client/server protocol
   independent part of SCSP, the reader is encouraged to see [2].

SCSPはどんな位相的な要件もNHRP SGに置きません。 しかしながら、明らかに、NHSsの結果のグラフは、連動するようにNHSsのセットにかからなければなりません。 クライアント/サーバに関する詳しい情報に関しては、SCSPの独立している部分について議定書の中で述べてください、そして、読者が[2]を見るよう奨励されます。

   When a SG is using SCSP for synchronization, an NHC will register
   with only one NHS, but the NHC MAY use any NHS in the SG.  When an
   NHC wishes to leave a SG, the NHC MUST do one of the following: 1)
   the NHC MUST send an NHRP Purge Request for itself requesting a
   reply, and it MUST wait for an NHRP Purge Reply, 2) the NHC MUST keep
   the Request ID it used when registering itself in non-volatile RAM
   and use a Request ID larger than the one saved when re-registering,
   or 3) the NHC MUST not re-register for a time equal to the Holding
   Time specified in the previous registration.  It is necessary to do
   one of the previous in order to prevent the unlikely case of race
   conditions from occurring during updated.  In the case where method 2
   is used, the NHS with which the NHC registered uses its ID as the OID
   and the Request ID from the NHC as the CSA Sequence Number in the
   CSA(S) Record.

SGが同期にSCSPを使用しているとき、NHCは1NHSだけとともに記名するでしょうが、NHC MAYはSGのどんなNHSも使用します。 NHCがSGを残したがっているとき、NHC MUSTは以下の1つをします: 1) NHC MUSTが要求自体のためのNHRP Purge Requestに回答を送って、それは、NHRP Purge Reply、NHC MUSTが非揮発性のRAMにそれ自体を登録するときそれが使用したRequest IDであることを保つ2を)待っていて、前の登録で指定されたHolding Timeと等しい時間、再登録するとき保存されたもの、または3より大きいID) NHC MUSTが再登録しないRequestを使用しなければなりません。 前の1つをするのが、競合条件のありそうもないケースがアップデートされる間、現れるのを防ぐのに必要です。 メソッド2が使用されている場合では、NHCが登録したNHSはCSA Sequence NumberとしてCSA(S)でNHCからOIDとしてのIDとRequest IDを使用します。 記録してください。

Luciani                     Standards Track                     [Page 2]

RFC 2335                    NHRP Using SCSP                   April 1998

1998年4月にSCSPを使用するLuciani標準化過程[2ページ]RFC2335NHRP

3.  Format of the CSA Record NHRP Specific Part

3. CSAの記録的なNHRP特定の部分の形式

   CSA Records in SCSP contain a "Client/Server Protocol Specific Part"
   which contains the non-protocol independent information for a given
   server's cache entry.

SCSPのCSA Recordsは与えられたサーバのキャッシュエントリーのための非プロトコルの独立している情報を含む「クライアント/サーバのプロトコルの特定の一部」を含んでいます。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Address Family Number     |     NHRP Protocol Type        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Snap                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Snap      | NHRP Vers Num |            Flags              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Request ID                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    State      | Prefix Length |            unused             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Maximum Transmission Unit    |        Holding Time           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Client Subnetwork Address (variable length)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Client Subnetwork 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスファミリー番号| NHRPプロトコルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スナップ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スナップ| NHRP Versヌム| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDを要求してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| 接頭語の長さ| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マキシマム・トランスミッション・ユニット| 把持時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cli Addr T/L| Cli SAddr T/L| Cli Protoレン| 好み| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントSubnetwork Address(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントSubnetwork Subaddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クライアントプロトコルAddress(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following six fields contain values specified in the common
   header of the mandatory part of an NHRP Registration Request or NHRP
   Purge Request packet which caused the
   creation/deletion/modification/update/etc. of an NHS's cache entry.

以下の6つの分野がNHSのキャッシュエントリーの作成/削除/変更/アップデート/などを引き起こしたNHRP Registration RequestかNHRP Purge Requestパケットの義務的な一部の一般的なヘッダーで指定された値を含んでいます。

   Address Family Number
     Defines the type of "link layer" addresses being carried.  This
     number is taken from the 'address family number' list specified in
     [3].  This field is the same field which would be supplied in an
     NHRP packet in the ar$afn field.

Family Number Definesが運ばれる「リンクレイヤ」アドレスのタイプであると扱ってください。 この数は[3]で指定された'アドレスファミリーナンバ'リストから抜粋されます。 この分野はar$afn分野のNHRPパケットで供給される同じ野原です。

   NHRP Protocol Type
     This field is the same field which would be supplied in an NHRP
     packet in the ar$pro.type field.

Type ThisがさばくNHRPプロトコルはar$pro.type分野のNHRPパケットで供給される同じ野原です。

   Snap
     This field is the same field which would be supplied in an NHRP
     packet in the ar$pro.snap field.

Thisがさばくスナップはar$pro.snap分野のNHRPパケットで供給される同じ野原です。

Luciani                     Standards Track                     [Page 3]

RFC 2335                    NHRP Using SCSP                   April 1998

1998年4月にSCSPを使用するLuciani標準化過程[3ページ]RFC2335NHRP

   NHRP Vers Num
     This field indicates what version of generic address mapping and
     management protocol that is represented by this message.  This
     field contains 0x01 for the NHRP protocol version 1.  This field is
     the same field which would be supplied in an NHRP packet in the
     ar$op.version field.

ヌムThisがさばくNHRP Versはこのメッセージによって表されるジェネリックアドレス・マッピングと管理プロトコルのすべてのバージョンを示します。 この分野はNHRPプロトコルバージョン1のための0×01を含んでいます。 この分野はar$op.version分野のNHRPパケットで供給される同じ野原です。

   Flags
     Defined flags are as follows:

Definedが旗を揚げさせる旗は以下の通りです:

        0                   1
        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |U|A|       unused              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|A| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       U
         This is the Uniqueness bit.

U、これはUniquenessビットです。

       A
         When set, this bit specifies that the cache entry was created
         as a result of ATMARP client interaction with the NHS.

Whenセット、このビットはキャッシュエントリーがNHSがあるATMARPクライアントとの対話の結果、作成されたと指定します。

   Request ID
     This field contains the Request ID value placed in the cache entry
     of the NHS as a result of an NHRP Registration Request.  This NHS
     is the NHS causing a synchronization event.

ThisがさばくIDがNHRP Registration Requestの結果、NHSのキャッシュエントリーに置かれたRequest ID価値を含むよう要求してください。 このNHSは同期イベントを引き起こすNHSです。

   State
     This field contains a value which represents the new state of the
     client.

Thisがさばく状態はクライアントの新しい状態を表す値を含んでいます。

       0 - Client is registered and available.
       1 - Client reregistered.
       2 - Client has been purged.
       3 - No such client data in server cache

0--クライアントは、登録されていて手があいています。 1--クライアントは再登録しました。 2--クライアントは掃除されました。 3--サーバキャッシュにおけるそのようなクライアントデータでない

     Note that a time-out of a cache entry does not cause a CSA Record
     to be sent because, if everything is working properly then all NHSs
     have the cache entry timing out at the same time.  Thus, the
     individual NHSs would take the appropriate actions necessary.

キャッシュエントリーのタイムアウトでCSA Recordを送らないことに注意してください、すべてなら、適切にすべてのNHSsがキャッシュエントリーに調節させるその時を外で同時にの扱うのは、そうです。 したがって、個々のNHSsは必要な状態で適切な行動を取るでしょう。

   The following ten fields contain values specified in or derived from
   the CIE of an NHRP Registration Request or NHRP Purge Request packet
   which caused the creation/deletion/modification/update/etc. of an
   NHS's cache entry.

以下の10の分野がNHSのキャッシュエントリーの作成/削除/変更/アップデート/などを引き起こしたパケットが指定されるか、またはNHRP Registration RequestかNHRP Purge RequestのCIEから引き出された値を含んでいます。

Luciani                     Standards Track                     [Page 4]

RFC 2335                    NHRP Using SCSP                   April 1998

1998年4月にSCSPを使用するLuciani標準化過程[4ページ]RFC2335NHRP

   Prefix Length
     This field contains the internetwork layer address prefix length
     value covered by the cache entry being synchronized.

接頭語Length This分野は同時にするキャッシュエントリーでカバーされたインターネットワーク層のアドレス接頭語長さの価値を含んでいます。

   Maximum Transmission Unit
     This field contains a value supplied by or derived from information
     in the CIE of the NHRP Registration Request packet.

最大のTransmission Unit This分野が、NHRP Registration RequestパケットのCIEで供給された値を含むか、または情報に由来していました。

   Holding Time
     The Holding Time field specifies the number of seconds remaining
     for which the Next Hop NBMA information specified in the CIE of the
     NHRP Registration Request is considered to be valid by the NHS
     initiating the synchronization event.

TimeをHolding Timeがさばく持っていると、NHRP Registration RequestのCIEで指定されたNext Hop NBMA情報が同期イベントを開始するNHSで有効であると考えられる秒の残りの数は指定されます。

   Cli Addr T/L
     Type & length of next hop NBMA address (see [1]).

次にのCli Addr T/L Typeと長さはNBMAアドレスを飛び越します。([1])を見てください。

   Cli SAddr T/L
     Type & length of next hop NBMA subaddress (see [1]).

次にのCli SAddr T/L Typeと長さはNBMA subaddressを飛び越します。([1])を見てください。

   Cli Proto Len
     This field holds the length in octets of the Client Protocol
     Address.

レンThisがさばくCliプロトはClientプロトコルAddressの八重奏における長さを保持します。

   Preference
     This field specifies the preference value for use of the next hop
     NBMA information specified.

Thisがさばく好みはNBMA情報が指定した次のホップの使用に好みの値を指定します。

   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.

クライアントプロトコルAddress Thisはクライアントのインターネットワーキング層のアドレスです。

4.  Values for SCSP Protocol Independent Part

4. SCSPのプロトコルの独立している一部への値

   The following sections give values for fields of the SCSP Protocol
   Independent Part of the various SCSP messages.

以下のセクションは様々なSCSPメッセージのSCSPプロトコル無党派Partの分野に値を与えます。

4.1 Values for the SCSP "Mandatory Common Part"

4.1 SCSP「義務的な一般的な部分」への値

   Protocol ID = 0x0002
   Sender ID Len = 0x04
   Recvr ID Len = 0x04

プロトコルID=0x0002送付者IDレン=0x04Recvr IDレン=0x04

Luciani                     Standards Track                     [Page 5]

RFC 2335                    NHRP Using SCSP                   April 1998

1998年4月にSCSPを使用するLuciani標準化過程[5ページ]RFC2335NHRP

   See Section B.2.0.1 of [2] for a detailed description of these
   fields.

これらの分野の詳述のための[2]のセクションB.2.0.1を見てください。

4.2 Values for the SCSP "CSAS Record"

4.2 SCSP「CSAS記録」のための値

   Cache Key Len = 0x04
   Orig ID Len = 0x04

キャッシュ主要なレン=0x04Orig IDレン=0x04

   See Section B.2.0.2 of [2] for a detailed description of these
   fields.

これらの分野の詳述のための[2]のセクションB.2.0.2を見てください。

5. Security Considerations

5. セキュリティ問題

   Relevant security considerations are documented in [1] and [2].

関連セキュリティ問題は[1]と[2]に記録されます。

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] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server
   Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.

[2]Luciani、J.、アーミテージ、G.、アルペルン、J.、およびN.Doraswamy、「サーバキャッシュ同期プロトコル(SCSP)」、RFC2334、1998年4月。

   [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
   October 1994.

[3] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。

   [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.

[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Acknowledgments

承認

   I would like to thank (in no particular order) Maxine Burns of ISR
   and Joel Halpern of Newbridge.  I would also like to thank the
   members of the ION working group of the IETF, whose review and
   discussion of this document has been invaluable.

ISRのマクシーン・バーンズとNewbridgeのジョエル・アルペルンに感謝申し上げます(特に決まった順番でなく)。 また、このドキュメントのレビューと議論が非常に貴重であるIETFのIONワーキンググループのメンバーに感謝申し上げます。

Author's Address

作者のアドレス

   James V. Luciani
   Bay Networks, Inc.
   3 Federal Street, BL3-03
   Billerica, MA  01821

ジェームスV.Lucianiベイネットワークス, Inc.3のFederal通り、BL3-03ビルリカ、MA 01821

   Phone: +1-978-916-4734
   EMail: luciani@baynetworks.com

以下に電話をしてください。 +1-978-916-4734 メールしてください: luciani@baynetworks.com

Luciani                     Standards Track                     [Page 6]

RFC 2335                    NHRP Using SCSP                   April 1998

1998年4月にSCSPを使用するLuciani標準化過程[6ページ]RFC2335NHRP

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                     Standards Track                     [Page 7]

Luciani標準化過程[7ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

times コマンドが使用した時間を表示する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る