[要約] RFC 2334は、Server Cache Synchronization Protocol（SCSP）に関する規格であり、キャッシュサーバー間の同期を目的としています。SCSPは、キャッシュの一貫性を維持し、ネットワークトラフィックを削減するために使用されます。
Network Working Group J. Luciani
Request for Comments: 2334 Bay Networks
Category: Standards Track G. Armitage
Bellcore
J. Halpern
Newbridge
N. Doraswamy
Bay Networks
April 1998
Server Cache Synchronization Protocol (SCSP)
サーバーキャッシュ同期プロトコル（SCSP）
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. SCSP attempts to solve the generalized cache synchronization/cache-replication problem for distributed protocol entities. However, in this document, SCSP is couched in terms of the client/server paradigm in which distributed server entities, which are bound to a Server Group (SG) through some means, wish to synchronize the contents (or a portion thereof) of their caches which contain information about the state of clients being served.
このドキュメントでは、サーバーキャッシュ同期プロトコル（SCSP）について説明し、Non Broadcast Multiple Access（NBMA）ネットワーク内でのSCSPの使用に関して記述されています。ただし、やや単純な使用法はBMAネットワークに適用できます。 SCSPは、分散プロトコルエンティティの一般化されたキャッシュ同期/キャッシュレプリケーションの問題を解決しようとします。ただし、このドキュメントでは、SCSPは、何らかの方法でサーバーグループ（SG）にバインドされている分散サーバーエンティティがそのコンテンツ（またはその一部）を同期することを望むクライアント/サーバーパラダイムに関して説明されています。提供されているクライアントの状態に関する情報を含むキャッシュ。
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 [10].
これらのキーワードは、このドキュメントに記載されている場合、[10]で説明されているように解釈する必要があります（必須、必須ではありません、必須、必須、必須ではありません、必須、必須ではありません）。
It is perhaps an obvious goal for any protocol to not limit itself to a single point of failure such as having a single server in a client/server paradigm. Even when there are redundant servers, there still remains the problem of cache synchronization; i.e., when one server becomes aware of a change in state of cache information then that server must propagate the knowledge of the change in state to all servers which are actively mirroring that state information. Further, this must be done in a timely fashion without putting undue resource strains on the servers. Assuming that the state information kept in the server cache is the state of clients of the server, then in order to minimize the burden placed upon the client it is also highly desirable that clients need not have complete knowledge of all servers which they may use. However, any mechanism for synchronization should not preclude a client from having access to several (or all) servers. Of course, any solution must be reasonably scalable, capable of using some auto-configuration service, and lend itself to a wide range of authentication methodologies.
クライアント/サーバーのパラダイムに単一のサーバーを配置するなど、単一の障害点に限定しないことは、どのプロトコルにとっても明らかな目標です。冗長サーバーがある場合でも、キャッシュ同期の問題は依然として残っています。つまり、1台のサーバーがキャッシュ情報の状態の変化に気づいたとき、そのサーバーは、その状態情報の変化をアクティブにミラーリングしているすべてのサーバーに、状態の変化に関する知識を伝達する必要があります。さらに、これは、サーバーに過度のリソースの負担をかけることなく、タイムリーに実行する必要があります。サーバーキャッシュに保持されている状態情報がサーバーのクライアントの状態であると仮定すると、クライアントにかかる負荷を最小限に抑えるために、クライアントが使用するすべてのサーバーの完全な知識を持っている必要がないことも強く望まれます。ただし、同期のメカニズムによって、クライアントが複数の（またはすべての）サーバーにアクセスできないようにすることはできません。もちろん、あらゆるソリューションは、ある程度スケーラブルで、いくつかの自動構成サービスを使用でき、幅広い認証方法論に適している必要があります。
This document describes the Server Cache Synchronization Protocol (SCSP). SCSP solves the generalized server synchronization/cache-replication problem while addressing the issues described above. SCSP synchronizes caches (or a portion of the caches) of a set of server entities of a particular protocol which are bound to a Server Group (SG) through some means (e.g., all NHRP servers belonging to a Logical IP Subnet (LIS)[1]). The client/server protocol which a particular server uses is identified by a Protocol ID (PID). SGs are identified by an ID which, not surprisingly, is called a SGID. Note, therefore, that the combination PID/SGID identifies both the client/server protocol for which the servers of the SG are being synchronized as well as the instance of that protocol. This implies that multiple instances of the same protocol may be in operation at the same time and have their servers synchronized independently of each other. An example of types of information that must be synchronized can be seen in NHRP[2] using IP where the information includes the registered clients' IP to NBMA mappings in the SG LIS.
このドキュメントでは、サーバーキャッシュ同期プロトコル（SCSP）について説明します。 SCSPは、上記の問題に対処しながら、一般化されたサーバー同期/キャッシュレプリケーションの問題を解決します。 SCSPは、特定のプロトコル（たとえば、論理IPサブネット（LIS）に属するすべてのNHRPサーバー）を通じてサーバーグループ（SG）にバインドされている特定のプロトコルのサーバーエンティティのセットのキャッシュ（またはキャッシュの一部）を同期します。 1]）。特定のサーバーが使用するクライアント/サーバープロトコルは、プロトコルID（PID）によって識別されます。 SGは、当然のことながらSGIDと呼ばれるIDで識別されます。したがって、PID / SGIDの組み合わせは、SGのサーバーが同期されているクライアント/サーバープロトコルと、そのプロトコルのインスタンスの両方を識別することに注意してください。これは、同じプロトコルの複数のインスタンスが同時に動作していて、サーバーが互いに独立して同期している可能性があることを意味します。同期が必要な情報のタイプの例は、IPを使用するNHRP [2]で確認できます。この情報には、SG LIS内の登録済みクライアントのIPからNBMAへのマッピングが含まれています。
The simplest way to understand SCSP is to understand that the algorithm used here is quite similar to that used in OSPF[3]. In fact, if the reader wishes to understand more details of the tradeoffs and reliability aspects of SCSP, they should refer to the Hello, Database Synchronization, and Flooding Procedures in OSPF [3].
SCSPを理解する最も簡単な方法は、ここで使用されるアルゴリズムがOSPF [3]で使用されるものと非常に似ていることを理解することです。実際、読者がSCSPのトレードオフと信頼性の側面の詳細を理解したい場合は、OSPFのHello、データベース同期、およびフラッディング手順を参照する必要があります[3]。
As described later, the protocol goes through three phases. The first, very brief phase is the hello phase where two devices determine that they can talk to each other. Following that is database synchronization. The operation of SCSP assumes that up to the point when new information is received, two entities have the same data available. The database synchronization phase ensures this.
後で説明するように、プロトコルは3つのフェーズを通過します。最初の非常に短いフェーズは、2つのデバイスが互いに通信できると判断するHelloフェーズです。その後、データベースの同期が行われます。 SCSPの操作では、新しい情報が受信される時点まで、2つのエンティティが同じデータを使用できると想定しています。データベースの同期フェーズでは、これが保証されます。
In database synchronization, the two neighbors exchange summary information about each entry in their database. Summaries are used since the database itself is potentially quite large. Based on these summaries, the neighbors can determine if there is information that each needs from the other. If so, that is requested and provided. Therefore, at the end of this phase of operation, the two neighbors have the same data in their databases.
データベースの同期では、2つのネイバーがデータベースの各エントリに関する要約情報を交換します。データベース自体が潜在的に非常に大きいため、要約が使用されます。これらの要約に基づいて、隣人はお互いに必要な情報があるかどうかを判断できます。もしそうなら、それは要求され、提供されます。したがって、この操作フェーズの最後に、2つのネイバーのデータベースに同じデータが格納されます。
After that, the entities enter and remain in flooding state. In flooding state, any new information that is learned is sent to all neighbors, except the one (if any) that the information was learned from. This causes all new information in the system to propagate to all nodes, thus restoring the state that everyone knows the same thing. Flooding is done reliably on each link, so no pattern of low rate packet loss will cause a disruption. (Obviously, a sufficiently high rate of packet loss will cause the entire neighbor relationship to come down, but if the link does not work, then that is what one wants.)
その後、エンティティは洪水状態に入り、洪水状態のままになります。フラッディングステートでは、学習された新しい情報は、情報が学習されたものを除いて、すべてのネイバーに送信されます。これにより、システム内のすべての新しい情報がすべてのノードに伝達されるため、誰もが同じことを知っている状態に戻ります。フラッディングは各リンクで確実に行われるため、低レートのパケット損失のパターンによって中断が発生することはありません。 （明らかに、パケット損失率が十分に高いと、ネイバー関係全体がダウンしますが、リンクが機能しない場合は、それが望ましいです。）
Because the database synchronization procedure is run whenever a link comes up, the system robustly ensures that all participating nodes have all available information. It properly recovers from partitions, and copes with other failures.
リンクが確立するたびにデータベースの同期手順が実行されるため、システムはすべての参加ノードがすべての利用可能な情報を確実に保持するようにします。パーティションから適切に回復し、他の障害に対処します。
The SCSP specification is not useful as a stand alone protocol. It must be coupled with the use of an SCSP Protocol Specific specification which defines how a given protocol would make use of the synchronization primitives supplied by SCSP. Such specification will be done in separate documents; e.g., [8] [9].
SCSP仕様は、スタンドアロンプロトコルとしては役に立ちません。これは、特定のプロトコルがSCSPによって提供される同期プリミティブをどのように利用するかを定義するSCSPプロトコル固有の仕様の使用と組み合わせる必要があります。そのような指定は、個別のドキュメントで行われます。例：[8] [9]。
SCSP places no topological requirements upon the SG. Obviously, however, the resultant graph must span the set of servers to be synchronized. SCSP borrows its cache distribution mechanism from the link state protocols [3,4]. However, unlike those technologies, there is no mandatory Shortest Path First (SPF) calculation, and SCSP imposes no additional memory requirements above and beyond that which is required to save the cached information which would exist regardless of the synchronization technology.
SCSPは、SGにトポロジ要件を課しません。ただし、当然、結果のグラフは、同期するサーバーのセットにまたがる必要があります。 SCSPは、リンク状態プロトコルからキャッシュ分散メカニズムを借用します[3、4]。ただし、これらのテクノロジーとは異なり、必須の最短パス優先（SPF）計算はありません。SCSPは、同期テクノロジーに関係なく存在するキャッシュされた情報を保存するために必要なメモリ要件を超える追加のメモリ要件を課しません。
In order to give a frame of reference for the following discussion, the terms Local Server (LS), Directly Connected Server (DCS), and Remote Server (RS) are introduced. The LS is the server under scrutiny; i.e., all statements are made from the perspective of the LS when discussing the SCSP protocol. The DCS is a server which is directly connected to the LS; e.g., there exists a VC between the LS and DCS. Thus, every server is a DCS from the point of view of every other server which connects to it directly, and every server is an LS which has zero or more DCSs directly connected to it. From the perspective of an LS, an RS is a server, separate from the LS, which is not directly connected to the LS (i.e., an RS is always two or more hops away from an LS whereas a DCS is always one hop away from an LS).
以下の説明の参照枠を与えるために、ローカルサーバー（LS）、直接接続サーバー（DCS）、およびリモートサーバー（RS）という用語が導入されています。 LSは精査中のサーバーです。つまり、SCSPプロトコルについて説明する場合、すべての記述はLSの観点から行われます。 DCSはLSに直接接続されているサーバーです。たとえば、LSとDCSの間にVCが存在します。したがって、すべてのサーバーは、直接接続する他のすべてのサーバーの観点から見たDCSであり、すべてのサーバーは、0個以上のDCSが直接接続されているLSです。 LSの観点から見ると、RSはLSとは別のサーバーであり、LSに直接接続されていません（つまり、RSは常にLSから2ホップ以上離れていますが、DCSは常に1ホップ離れています。 LS）。
SCSP contains three sub protocols: the "Hello" protocol, the "Cache Alignment" protocol, and the "Cache State Update" protocol. The "Hello" protocol is used to ascertain whether a DCS is operational and whether the connection between the LS and DCS is bidirectional, unidirectional, or non-functional. The "Cache Alignment" (CA) protocol allows an LS to synchronize its entire cache with that of the cache of its DCSs. The "Cache State Update" (CSU) protocol is used to update the state of cache entries in servers for a given SG. Sections 2.1, 2.2, and 2.3 contain a more in-depth explanation of the Hello, CA, and CSU protocols and the messages they use.
SCSPには、「Hello」プロトコル、「Cache Alignment」プロトコル、および「Cache State Update」プロトコルの3つのサブプロトコルが含まれています。 「Hello」プロトコルは、DCSが動作しているかどうか、およびLSとDCS間の接続が双方向、単方向、または機能していないかどうかを確認するために使用されます。 「キャッシュアライメント」（CA）プロトコルにより、LSはキャッシュ全体をDCSのキャッシュと同期させることができます。 「キャッシュ状態更新」（CSU）プロトコルは、特定のSGのサーバーのキャッシュエントリの状態を更新するために使用されます。セクション2.1、2.2、および2.3には、Hello、CA、およびCSUプロトコルと、それらが使用するメッセージの詳細な説明が含まれています。
SCSP based synchronization is performed on a per protocol instance basis. That is, a separate instance of SCSP is run for each instance of the given protocol running in a given box. The protocol is identified in SCSP via a Protocol ID and the instance of the protocol is identified by a Server Group ID (SGID). Thus the PID/SGID pair uniquely identify an instance of SCSP. In general, this is not an issue since it is seldom the case that many instances of a given protocol (which is distributed and needs cache synchronization) are running within the same physical box. However, when this is the case, there is a mechanism called the Family ID (described briefly in the Hello Protocol) which enables a substantial reduction in maintenance traffic at little real cost in terms of control. The use of the Family ID mechanism, when appropriate for a given protocol which is using SCSP, will be fully defined in the given SCSP protocol specific specification.
SCSPベースの同期は、プロトコルインスタンスごとに実行されます。つまり、特定のボックスで実行されている特定のプロトコルのインスタンスごとに、SCSPの個別のインスタンスが実行されます。プロトコルはプロトコルIDを介してSCSPで識別され、プロトコルのインスタンスはサーバーグループID（SGID）で識別されます。したがって、PID / SGIDペアはSCSPのインスタンスを一意に識別します。特定のプロトコルの多くのインスタンス（分散され、キャッシュの同期が必要）が同じ物理ボックス内で実行されることはほとんどないため、これは一般的に問題ではありません。ただし、この場合は、ファミリーIDと呼ばれるメカニズム（Helloプロトコルで簡単に説明）があり、制御に関して実質的なコストをほとんどかけずに保守トラフィックを大幅に削減できます。ファミリーIDメカニズムの使用は、SCSPを使用する特定のプロトコルに適切な場合、特定のSCSPプロトコル固有の仕様で完全に定義されます。
+---------------+
| |
+------->| DOWN |<-------+
| | | |
| +---------------+ |
| | ^ |
| | | |
| | | |
| | | |
| @ | |
| +---------------+ |
| | | |
| | WAITING | |
| +--| |--+ |
| | +---------------+ | |
| | ^ ^ | |
| | | | | |
| @ | | @ |
+---------------+ +---------------+
| BIDIRECTIONAL |---->| UNIDIRECTIONAL|
| | | |
| CONNECTION |<----| CONNECTION |
+---------------+ +---------------+
Figure 1: Hello Finite State Machine (HFSM)
図1：Hello有限状態マシン（HFSM）
"Hello" messages are used to ascertain whether a DCS is operational and whether the connections between the LS and DCS are bidirectional, unidirectional, or non-functional. In order to do this, every LS MUST periodically send a Hello message to its DCSs.
「Hello」メッセージは、DCSが機能しているかどうか、およびLSとDCS間の接続が双方向、単方向、または機能していないかどうかを確認するために使用されます。これを行うには、すべてのLSが定期的にHelloメッセージをDCSに送信する必要があります。
An LS must be configured with a list of NBMA addresses which represent the addresses of peer servers in a SG to which the LS wishes to have a direct connection for the purpose of running SCSP; that is, these addresses are the addresses of would-be DCSs. The mechanism for the configuration of an LS with these NBMA address is beyond the scope of this document; although one possible mechanism would be an autoconfiguration server.
LSは、LSCSPを実行する目的でLSが直接接続したいSG内のピアサーバーのアドレスを表すNBMAアドレスのリストで構成する必要があります。つまり、これらのアドレスは、DCSになるであろうアドレスです。これらのNBMAアドレスを使用してLSを構成するメカニズムは、このドキュメントの範囲外です。ただし、1つの可能なメカニズムは自動構成サーバーです。
An LS has a Hello Finite State Machine (HFSM) associated with each of its DCSs (see Figure 1) for a given SG, and the HFSM monitors the state of the connectivity between the servers.
LSには、特定のSGの各DCS（図1を参照）に関連付けられたHello有限状態マシン（HFSM）があり、HFSMはサーバー間の接続状態を監視します。
The HFSM starts in the "Down" State and transitions to the "Waiting" State after NBMA level connectivity has been established. Once in the Waiting State, the LS starts sending Hello messages to the DCS. The Hello message includes: a Sender ID which is set to the LS's ID (LSID), zero or more Receiver IDs which identify the DCSs from which the LS has recently heard a Hello message (as described below), and a HelloInterval and DeadFactor which will be described below. At this point, the DCS may or may not already be sending its own Hello messages to the LS.
HFSMは「ダウン」状態で開始し、NBMAレベルの接続が確立された後、「待機」状態に移行します。待機状態になると、LSはDCSへのHelloメッセージの送信を開始します。 Helloメッセージには、LSのID（LSID）に設定された送信者ID、LSが最近Helloメッセージを聞いたDCSを識別する0個以上の受信者ID（以下で説明）、およびHelloIntervalとDeadFactorが含まれます。以下に説明します。この時点で、DCSは独自のHelloメッセージをLSに送信している場合と送信していない場合があります。
When the LS receives a Hello message from one of its DCSs, the LS checks to see if its LSID is in one of the Receiver ID fields of that message which it just received, and the LS saves the Sender ID from that Hello message. If the LSID is in one of the Receiver ID fields then the LS transitions the HFSM to the Bidirectional Connection state otherwise it transitions the HFSM into the Unidirectional Connection state. The Sender ID which was saved is the DCS's ID (DCSID). At some point before the next time that the LS sends its own Hello message to the DCS, the LS will check the saved DCSID against a list of Receiver IDs which the LS uses when sending the LS's own Hello messages. If the DCSID is not found in the list of Receiver IDs then it is added to that list before the LS sends its Hello message.
LSがDCSの1つからHelloメッセージを受信すると、LSは、LSIDが受信したメッセージの受信者IDフィールドの1つにあるかどうかを確認し、LSはそのHelloメッセージから送信者IDを保存します。 LSIDがレシーバIDフィールドの1つにある場合、LSはHFSMを双方向接続状態に移行します。それ以外の場合、LSDはHFSMを単方向接続状態に移行します。保存された送信者IDは、DCSのID（DCSID）です。 LSが次に独自のHelloメッセージをDCSに送信する前のある時点で、LSは、LSが独自のHelloメッセージを送信するときに使用する受信者IDのリストに対して保存されたDCSIDをチェックします。 DCSIDがレシーバーIDのリストで見つからない場合、LSがそのHelloメッセージを送信する前にそのリストに追加されます。
Hello messages also contain a HelloInterval and a DeadFactor. The Hello interval advertises the time (in seconds) between sending of consecutive Hello messages by the server which is sending the "current" Hello message. That is, if the time between reception of Hello messages from a DCS exceeds the HelloInterval advertised by that DCS then the next Hello message is to be considered late by the LS. If the LS does not receive a Hello message, which contains the LS's LSID in one of the Receiver ID fields, within the interval HelloInterval*DeadFactor seconds (where DeadFactor was advertised by the DCS in a previous Hello message) then the LS MUST consider the DCS to be stalled. At which point one of two things will happen: 1) if any Hello messages have been received during the last HelloInterval*DeadFactor seconds then the LS should transition the HFSM for that DCS to the Unidirectional Connection State; otherwise, the LS should transition the HFSM for that DCS to the Waiting State and remove the DCSID from the Receiver ID list.
Helloメッセージには、HelloIntervalとDeadFactorも含まれています。 Helloインターバルは、「現在の」Helloメッセージを送信しているサーバーが連続してHelloメッセージを送信する間隔（秒単位）を通知します。つまり、DCSからのHelloメッセージの受信間の時間が、そのDCSによってアドバタイズされたHelloIntervalを超えた場合、次のHelloメッセージはLSによって遅れていると見なされます。 LSがHelloInterval * DeadFactor秒（DeadFactorが以前のHelloメッセージでDCSによって通知された）間隔内に、LSのLSIDをいずれかのレシーバーIDフィールドに含むHelloメッセージを受信しない場合、LSは、停止するDCS。この時点で、次の2つのいずれかが発生します。1）HelloInterval * DeadFactorの最後の秒の間にHelloメッセージが受信された場合、LSはそのDCSのHFSMを単方向接続状態に移行する必要があります。それ以外の場合、LSはそのDCSのHFSMを待機状態に移行し、DCSIDを受信者IDリストから削除する必要があります。
Note that the Hello Protocol is on a per PID/SGID basis. Thus, for example, if there are two servers (one in SG A and the other in SG B) associated with an NBMA address X and another two servers (also one in SG A and the other in SG B) associated with NBMA address Y and there is a suitable point-to-point VC between the NBMA addresses then there are two HFSMs running on each side of the VC (one per PID/SGID).
HelloプロトコルはPID / SGIDごとに基づいていることに注意してください。したがって、たとえば、NBMAアドレスXに関連付けられた2つのサーバー（SG Aに1つ、SG Bにもう1つ）があり、NBMAアドレスYに関連付けられた別の2つのサーバー（SG Aに1つ、SG Bにもう1つ）がある場合NBMAアドレス間に適切なポイントツーポイントVCがある場合、VCの両側で2つのHFSMが実行されます（PID / SGIDごとに1つ）。
Hello messages contain a list of Receiver IDs instead of a single Receiver ID in order to make use of point to multipoint connections. While there is an HFSM per DCS, an LS MUST send only a single Hello message to its DCSs attached as leaves of a point to multipoint connection. The LS does this by including DCSIDs in the list of Receiver IDs when the LS's sends its next Hello message. Only the DCSIDs from non-stalled DCSs from which the LS has heard a Hello message are included.
Helloメッセージには、ポイントツーマルチポイント接続を利用するために、単一のレシーバIDではなく、レシーバIDのリストが含まれています。 DCSごとにHFSMがありますが、LSは、ポイントツーマルチポイント接続のリーフとして接続されたDCSに単一のHelloメッセージのみを送信する必要があります。 LSは、LSが次のHelloメッセージを送信するときに、レシーバーIDのリストにDCSIDを含めることでこれを行います。 LSがHelloメッセージを受信した、停止していないDCSからのDCSIDのみが含まれます。
Any abnormal event, such as receiving a malformed SCSP message, causes the HFSM to transition to the Waiting State; however, a loss of NBMA connectivity causes the HFSM to transition to the Down State. Until the HFSM is in the Bidirectional Connection State, if any properly formed SCSP messages other than Hello messages are received then those messages MUST be ignored (this is for the case where, for example, there is a point to multipoint connection involved).
不正なSCSPメッセージの受信などの異常なイベントが発生すると、HFSMは待機状態に移行します。ただし、NBMA接続が失われると、HFSMがダウン状態に移行します。 HFSMが双方向接続状態になるまで、Helloメッセージ以外の適切に形成されたSCSPメッセージが受信された場合、それらのメッセージは無視する必要があります（これは、たとえば、ポイントツーマルチポイント接続が関係している場合に当てはまります）。
+------------+
| |
+--->| DOWN |
| | |
| +------------+
| |
^ |
| @
| +------------+
| |Master/Slave|
|-<--| |<---+
| |Negotiation | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Cache | |
|-<--| |-->-|
| | Summarize | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Update | |
|-<--| |-->-|
| | Cache | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | | |
+-<--| Aligned |-->-+
| |
+------------+
Figure 2: Cache Alignment Finite State Machine
図2：キャッシュアライメント有限状態マシン
"Cache Alignment" (CA) messages are used by an LS to synchronize its cache with that of the cache of each of its DCSs. That is, CA messages allow a booting LS to synchronize with each of its DCSs. A CA message contains a CA header followed by zero or more Cache State Advertisement Summary records (CSAS records).
「キャッシュアライメント」（CA）メッセージは、LSがそのキャッシュを各DCSのキャッシュと同期させるために使用します。つまり、CAメッセージにより、起動中のLSがそのDCSのそれぞれと同期できるようになります。 CAメッセージには、CAヘッダーの後に0個以上のキャッシュ状態アドバタイズメントサマリーレコード（CSASレコード）が含まれています。
An LS has a Cache Alignment Finite State Machine (CAFSM) associated (see Figure 2) with each of its DCSs on a per PID/SGID basis, and the CAFSM monitors the state of the cache alignment between the servers. The CAFSM starts in the Down State. The CAFSM is associated with an HFSM, and when that HFSM reaches the Bidirectional State, the CAFSM transitions to the Master/Slave Negotiation State. The Master/Slave Negotiation State causes either the LS or DCS to take on the role of master over the cache alignment process. In a sense, the master server sets the tempo for the cache alignment.
LSには、PID / SGIDごとに各DCSに関連付けられたキャッシュアライメント有限状態マシン（CAFSM）があり（図2を参照）、CAFSMはサーバー間のキャッシュアライメントの状態を監視します。 CAFSMはダウン状態で開始します。 CAFSMはHFSMに関連付けられており、そのHFSMが双方向状態に達すると、CAFSMはマスター/スレーブネゴシエーション状態に移行します。マスター/スレーブネゴシエーション状態により、LSまたはDCSのいずれかが、キャッシュアライメントプロセスでマスターの役割を引き継ぎます。ある意味で、マスターサーバーはキャッシュアラインメントのテンポを設定します。
When the LS's CAFSM reaches the Master/Slave Negotiation State, the LS will send a CA message to the DCS associated with the CAFSM. The format of CA messages are described in Section B.2.1. The first CA message which the LS sends includes no CSAS records and a CA header which contains the LSID in the Sender ID field, the DCSID in the Receiver ID field, a CA sequence number, and three bits. These three bits are the M (Master/Slave) bit, the I (Initialization of master) bit, and the O (More) bit. In the first CA message sent by the LS to a particular DCS, the M, O, and I bits are set to one. If the LS does not receive a CA message from the DCS in CAReXmtInterval seconds then it resends the CA message it just sent. The LS continues to do this until the CAFSM transitions to the Cache Summarize State or until the HFSM transitions out of the Bidirectional State. Any time the HFSM transitions out of the Bidirectional State, the CAFSM transitions to the Down State.
LSのCAFSMがマスター/スレーブネゴシエーション状態に達すると、LSはCAメッセージをCAFSMに関連付けられたDCSに送信します。 CAメッセージの形式については、セクションB.2.1で説明します。 LSが送信する最初のCAメッセージには、CSASレコードと、送信者IDフィールドのLSID、受信者IDフィールドのDCSID、CAシーケンス番号、および3ビットを含むCAヘッダーが含まれていません。これらの3つのビットは、M（マスター/スレーブ）ビット、I（マスターの初期化）ビット、およびO（その他）ビットです。 LSから特定のDCSに送信される最初のCAメッセージでは、M、O、およびIビットが1に設定されます。 LSがCAReXmtInterval秒以内にDCSからCAメッセージを受信しない場合、LSは送信したCAメッセージを再送信します。 LSは、CAFSMがキャッシュ要約状態に移行するまで、またはHFSMが双方向状態から移行するまで、これを続けます。 HFSMが双方向状態から遷移するときはいつでも、CAFSMはダウン状態に遷移します。
When the LS receives a CA message from the DCS while in the Master/Slave Negotiation State, the role the LS plays in the exchange depends on packet processing as follows:
LSがマスター/スレーブネゴシエーション状態のときにDCSからCAメッセージを受信すると、交換でLSが果たす役割は、次のようにパケット処理に依存します。
1) If the CA from the DCS has the M, I, and O bits set to one and there are no CSAS records in the CA message and the Sender ID as specified in the DCS's CA message is larger than the LSID then
1）DCSからのCAのM、I、およびOビットが1に設定されており、CAメッセージにCSASレコードがなく、DCSのCAメッセージで指定されている送信者IDがLSIDより大きい場合
a) The timer counting down the CAReXmtInterval is stopped. b) The CAFSM corresponding to that DCS transitions to the Cache Summarize State and the LS takes on the role of slave. c) The LS adopts the CA sequence number it received in the CA message as its own CA sequence number. d) The LS sends a CA message to the DCS which is formated as follows: the M and I bits are set to zero, the Sender ID field is set to the LSID, the Receiver ID field is set to the DCSID, and the CA sequence number is set to the CA sequence number that appeared in the DCS's CA message. If there are CSAS records to be sent (i.e., if the LS's cache is not empty), and if all of them will not fit into this CA message then the O bit is set to one and the initial set of CSAS records are included in the CA message; otherwise the O bit is set to zero and if any CSAS Records need to be sent then those records are included in the CA message.
a）CAReXmtIntervalをカウントダウンするタイマーが停止します。 b）そのDCSに対応するCAFSMがキャッシュ要約状態に移行し、LSがスレーブの役割を引き受けます。 c）LSは、自身のCAシーケンス番号として、CAメッセージで受信したCAシーケンス番号を採用します。 d）LSは、次のようなフォーマットのDCSにCAメッセージを送信します。MおよびIビットがゼロに設定され、送信者IDフィールドがLSIDに設定され、受信者IDフィールドがDCSIDに設定され、CAシーケンス番号は、DCSのCAメッセージに表示されたCAシーケンス番号に設定されます。送信するCSASレコードがあり（LSのキャッシュが空でない場合）、それらすべてがこのCAメッセージに適合しない場合、Oビットが1に設定され、CSASレコードの初期セットが含まれます。 CAメッセージ。それ以外の場合、Oビットはゼロに設定され、CSASレコードを送信する必要がある場合、それらのレコードはCAメッセージに含まれます。
2) If the CA message from the DCS has the M and I bits off and the Sender ID as specified in the DCS's CA message is smaller than the LSID then
2）DCSからのCAメッセージのMおよびIビットがオフで、DCSのCAメッセージで指定されている送信者IDがLSIDより小さい場合
a) The timer counting down the CAReXmtInterval is stopped. b) The CAFSM corresponding to that DCS transitions to the Cache Summarize State and the LS takes on the role of master. c) The LS must process the received CA message. An explanation of CA message processing is given below. d) The LS sends a CA message to the DCS which is formated as follows: the M bit is set to one, I bit is set to zero, the Sender ID field is set to the LSID, the Receiver ID field is set to the DCSID, and the LS's current CA sequence number is incremented by one and placed in the CA message. If there are any CSAS records to be sent from the LS to the DCS (i.e., if the LS's cache is not empty) then the O bit is set to one and the initial set of CSAS records are included in the CA message that the LS is sending to the DCS.
a) CAReXmtIntervalをカウントダウンするタイマーが停止します。 b）そのDCSに対応するCAFSMがキャッシュ要約状態に移行し、LSがマスターの役割を引き継ぎます。 c）LSは受信したCAメッセージを処理する必要があります。 CAメッセージ処理の説明を以下に示します。 d）LSは、次のフォーマットのDCSにCAメッセージを送信します。Mビットが1に設定され、Iビットがゼロに設定され、送信者IDフィールドがLSIDに設定され、受信者IDフィールドが受信者に設定されます。 DCSID、およびLSの現在のCAシーケンス番号が1ずつ増分され、CAメッセージに配置されます。 LSからDCSに送信されるCSASレコードがある場合（つまり、LSのキャッシュが空でない場合）、Oビットが1に設定され、CSASレコードの初期セットがLSのCAメッセージに含まれます。 DCSに送信しています。
3) Otherwise, the packet must be ignored.
3）それ以外の場合、パケットは無視する必要があります。
At any given time, the master or slave have at most one outstanding CA message. Once the LS's CAFSM has transitioned to the Cache Summarize State the sequence of exchanges of CA messages occurs as follows:
常に、マスターまたはスレーブには最大1つの未解決のCAメッセージがあります。 LSのCAFSMがキャッシュ要約状態に移行すると、CAメッセージの一連の交換が次のように行われます。
1) If the LS receives a CA message with the M bit set incorrectly (e.g., the M bit is set in the CA of the DCS and the LS is master) or if the I bit is set then the CAFSM transitions back to the Master/Slave Negotiation State.
1）LSがMビットが正しく設定されていないCAメッセージを受信した場合（たとえば、MビットがDCSのCAで設定され、LSがマスターである）、またはIビットが設定されている場合、CAFSMはマスターに戻ります。 /スレーブ交渉状態。
2) If the LS is master and the LS receives a CA message with a CA sequence number which is one less than the LS's current CA sequence number then the message is a duplicate and the message MUST be discarded.
2）LSがマスターであり、LSが、LSの現在のCAシーケンス番号より1つ少ないCAシーケンス番号を持つCAメッセージを受信する場合、メッセージは重複しているため、メッセージを破棄する必要があります。
3) If the LS is master and the LS receives a CA message with a CA sequence number which is equal to the LS's current CA sequence number then the CA message MUST be processed. An explanation of "CA message processing" is given below. As a result of having received the CA message from the DCS the following will occur:
3）LSがマスターであり、LSがLSの現在のCAシーケンス番号と等しいCAシーケンス番号を持つCAメッセージを受信する場合、CAメッセージを処理する必要があります。以下に「CAメッセージ処理」について説明します。 DCSからCAメッセージを受信した結果、次のことが起こります。
a) The timer counting down the CAReXmtInterval is stopped. b) The LS must process any CSAS records in the received CA message. c) Increment the LS's CA sequence number by one. d) The cache exchange continues as follows:
a) CAReXmtIntervalをカウントダウンするタイマーが停止します。 b）LSは、受信したCAメッセージのCSASレコードを処理する必要があります。 c）LSのCAシーケンス番号を1つ増やします。 d）キャッシュ交換は次のように続行されます。
1) If the LS has no more CSAS records to send and the received CA message has the O bit off then the CAFSM transitions to the Update Cache State. 2) If the LS has no more CSAS records to send and the received CA message has the O bit on then the LS sends back a CA message (with new CA sequence number) which contains no CSAS records and with the O bit off. Reset the timer counting down the CAReXmtInterval. 3) If the LS has more CSAS records to send then the LS sends the next CA message with the LS's next set of CSAS records. If LS is sending its last set of CSAS records then the O bit is set off otherwise the O bit is set on. Reset the timer counting down the CAReXmtInterval.
1）LSに送信するCSASレコードがなく、受信したCAメッセージのOビットがオフの場合、CAFSMはキャッシュ更新状態に移行します。 2）LSに送信するCSASレコードがなく、受信したCAメッセージにOビットがオンの場合、LSは、CSASレコードを含まず、OビットがオフのCAメッセージ（新しいCAシーケンス番号付き）を返します。 CAReXmtIntervalをカウントダウンするタイマーをリセットします。 3）LSに送信するCSASレコードがさらにある場合、LSは、LSの次のCSASレコードセットを含む次のCAメッセージを送信します。 LSがCSASレコードの最後のセットを送信している場合、Oビットはオフに設定され、そうでない場合はOビットがオンに設定されます。 CAReXmtIntervalをカウントダウンするタイマーをリセットします。
4) If the LS is slave and the LS receives a CA message with a CA sequence number which is equal to the LS's current CA sequence number then the CA message is a duplicate and the LS MUST resend the CA message which it had just sent to the DCS.
4）LSがスレーブであり、LSがLSの現在のCAシーケンス番号と等しいCAシーケンス番号を持つCAメッセージを受信する場合、CAメッセージは重複しており、LSは送信したばかりのCAメッセージを再送信する必要があります。 DCS。
5) If the LS is slave and the LS receives a CA message with a CA sequence number which is one more than the LS's current CA sequence number then the message is valid and MUST be processed. An explanation of "CA message processing" is given below. As a result of having received the CA message from the DCS the following will occur:
5）LSがスレーブであり、LSが、LSの現在のCAシーケンス番号よりも1つ多いCAシーケンス番号を持つCAメッセージを受信する場合、メッセージは有効であり、処理されなければなりません（MUST）。以下に「CAメッセージ処理」について説明します。 DCSからCAメッセージを受信した結果、次のことが起こります。
a) The LS must process any CSAS records in the received CA message. b) Set the LS's CA sequence number to the CA sequence number in the CA message. c) The cache exchange continues as follows:
a) LSは、受信したCAメッセージ内のCSASレコードを処理する必要があります。 b）LSのCAシーケンス番号をCAメッセージのCAシーケンス番号に設定します。 c）キャッシュ交換は次のように続行されます。
1) If the LS had just sent a CA message with the O bit off and the received CA message has the O bit off then the CAFSM transitions to the Update Cache State and the LS sends a CA message with no CSAS records and with the O bit off. 2) If the LS still has CSAS records to send then the LS MUST send a CA message with CSAS records in it.
1）LSがOビットをオフにしてCAメッセージを送信し、受信したCAメッセージがOビットをオフにした場合、CAFSMは更新キャッシュ状態に移行し、LSはCSASレコードがなくOを含むCAメッセージを送信します。ビットオフ。 2）LSにまだ送信するCSASレコードがある場合、LSは、CSASレコードを含むCAメッセージを送信する必要があります。
a) If the message being sent from the LS to the DCS does not contain the last CSAS records that the LS needs to send then the CA message is sent with the O bit on. b) If the message being sent from the LS to the DCS does contain the last CSAS records that the LS needs to send and the CA message just received from the DCS had the O bit off then the CA message is sent with the O bit off, and the LS transitions the CAFSM to the Update Cache State. c) If the message being sent from the LS to the DCS does contain the last CSAS records that the LS needs to send and the CA message just received from the DCS had the O bit on then the CA message is sent with the O bit off and the alignment process continues.
a）LSからDCSに送信されるメッセージに、LSが送信する必要がある最後のCSASレコードが含まれていない場合、CAメッセージはOビットをオンにして送信されます。 b）LSからDCSに送信されるメッセージに、LSが送信する必要がある最後のCSASレコードが含まれていて、DCSから受信したばかりのCAメッセージのOビットがオフの場合、CAメッセージはOビットがオフの状態で送信されます。 、そしてLSはCAFSMをUpdate Cache Stateに移行します。 c）LSからDCSに送信されるメッセージに、LSが送信する必要がある最後のCSASレコードが含まれていて、DCSから受信したばかりのCAメッセージにOビットがオンになっている場合、CAメッセージはOビットをオフにして送信されます。調整プロセスが続行されます。
6) If the LS is slave and the LS receives a CA message with a CA sequence number that is neither equal to nor one more than the current LS's CA sequence number then an error has occurred and the CAFSM transitions to the Master/Slave Negotiation State.
6）LSがスレーブで、LSが現在のLSのCAシーケンス番号と同じでも1でもないCAシーケンス番号を持つCAメッセージを受信した場合、エラーが発生し、CAFSMはマスター/スレーブネゴシエーション状態に移行します。
Note that if the LS was slave during the CA process then the LS upon transitioning the CAFSM to the Update Cache state MUST keep a copy of the last CA message it sent and the LS SHOULD set a timer equal to CAReXmtInterval. If either the timer expires or the LS receives a CSU Solicit (CSUS) message (CSUS messages are described in Section 2.2.3) from the DCS then the LS releases the copy of the CA message. The reason for this is that if the DCS (which is master) loses the last CA message sent by the LS then the DCS will resend its previous CA message with the last CA Sequence number used. If that were to occur the LS would need to resend its last sent CA message as well.
LSがCAプロセス中にスレーブだった場合、LSはCAFSMを更新キャッシュ状態に移行するときに、送信した最後のCAメッセージのコピーを保持する必要があり、LSはタイマーをCAReXmtIntervalに設定する必要があります（SHOULD）。タイマーが時間切れになるか、LSがDCSからCSU Solicit（CSUS）メッセージ（CSUSメッセージについてはセクション2.2.3で説明）を受信した場合、LSはCAメッセージのコピーを解放します。これは、DCS（マスター）がLSから送信された最後のCAメッセージを失った場合、DCSが最後のCAシーケンス番号を使用して以前のCAメッセージを再送信するためです。これが発生した場合、LSは最後に送信されたCAメッセージも再送信する必要があります。
2.2.2.1 "CA message processing":
2.2.2.1 「CAメッセージ処理」：
The LS makes a list of those cache entries which are more "up to date" in the DCS than the LS's own cache. This list is called the CSA Request List (CRL). See Section 2.4 for a description of what it means for a CSA (Client State Advertisement) record or CSAS record to be more "up to date" than an LS's cache entry.
LSは、LS自体のキャッシュよりもDCSで「最新」のキャッシュエントリのリストを作成します。このリストは、CSA要求リスト（CRL）と呼ばれます。 CSA（Client State Advertisement）レコードまたはCSASレコードがLSのキャッシュエントリよりも「最新」であることの意味については、セクション2.4を参照してください。
If the CRL of the associated CAFSM of the LS is empty upon transition into the Update Cache State then the CAFSM immediately transitions into the Aligned State.
LSの関連付けられたCAFSMのCRLがキャッシュ更新状態への移行時に空の場合、CAFSMは直ちに整列状態に移行します。
If the CRL is not empty upon transition into the Update Cache State then the LS solicits the DCS to send the CSA records corresponding to the summaries (i.e., CSAS records) which the LS holds in its CRL. The solicited CSA records will contain the entirety of the cached information held in the DCS's cache for the given cache entry. The LS solicits the relevant CSA records by forming CSU Solicit (CSUS) messages from the CRL. See Section B.2.4 for the description of the CSUS message format. The LS then sends the CSUS messages to the DCS. The DCS responds to the CSUS message by sending to the LS one or more CSU Request messages containing the entirety of newer cached information identified in the CSUS message. Upon receiving the CSU Request the LS will send one or more CSU Replies as described in Section 2.3. Note that the LS may have at most one CSUS message outstanding at any given time.
キャッシュ更新状態への移行時にCRLが空でない場合、LSはDCSに、LSがそのCRLに保持している要約（つまり、CSASレコード）に対応するCSAレコードを送信するように要請します。要請されたCSAレコードには、指定されたキャッシュエントリのDCSのキャッシュに保持されているキャッシュされた情報全体が含まれます。 LSは、CRLからCSU Solicit（CSUS）メッセージを形成することにより、関連するCSAレコードを要求します。 CSUSメッセージ形式の説明については、セクションB.2.4を参照してください。次に、LSはCSUSメッセージをDCSに送信します。 DCSは、CSUSメッセージで識別された新しいキャッシュ情報の全体を含む1つ以上のCSU要求メッセージをLSに送信することにより、CSUSメッセージに応答します。 CSU要求を受信すると、セクション2.3で説明されているように、LSは1つ以上のCSU応答を送信します。 LSには、常に最大1つのCSUSメッセージが未処理である可能性があることに注意してください。
Just before the first CSUS message is sent from an LS to the DCS associated with the CAFSM, a timer is set to CSUSReXmtInterval seconds. If all the CSA records corresponding to the CSAS records in the CSUS message have not been received by the time that the timer expires then a new CSUS message will be created which contains all the CSAS records for which no appropriate CSA record has been received plus additional CSAS records not covered in the previous CSUS message. The new CSUS message is then sent to the DCS. If, at some point before the timer expires, all CSA record updates have been received for all the CSAS records included in the previously sent CSUS message then the timer is stopped. Once the timer is stopped, if there are additional CSAS records that were not covered in the previous CSUS message but were in the CRL then the timer is reset and a new CSUS message is created which contains only those CSAS records from the CRL which have not yet been sent to the DCS. This process continues until all the CSA records corresponding CSAS records that were in the CRL have been received by the LS. When the LS has a completely updated cache then the LS transitions CAFSM associated with the DCS to the Aligned State.
最初のCSUSメッセージがLSからCAFSMに関連付けられたDCSに送信される直前に、タイマーがCSUSReXmtInterval秒に設定されます。 CSUSメッセージのCSASレコードに対応するすべてのCSAレコードが、タイマーの期限が切れるまでに受信されていない場合、適切なCSAレコードが受信されていないすべてのCSASレコードと追加のCSUSレコードを含む新しいCSUSメッセージが作成されます。前のCSUSメッセージでカバーされていないCSASレコード。次に、新しいCSUSメッセージがDCSに送信されます。タイマーが期限切れになる前のある時点で、以前に送信されたCSUSメッセージに含まれるすべてのCSASレコードのすべてのCSAレコードの更新が受信された場合、タイマーは停止します。タイマーが停止すると、前のCSUSメッセージでカバーされなかったがCRLにあった追加のCSASレコードがある場合、タイマーがリセットされ、CRLからのCSASレコードが含まれていないCSASレコードのみを含む新しいCSUSメッセージが作成されます。まだDCSに送信されました。このプロセスは、CRLにあったCSASレコードに対応するすべてのCSAレコードがLSによって受信されるまで続きます。 LSに完全に更新されたキャッシュがある場合、LSはDCSに関連付けられたCAFSMをAligned状態に移行します。
If an LS receives a CSUS message or a CA message with a Receiver ID which is not the LS's LSID then the message must be discarded and ignored. This is necessary since an LS may be a leaf of a point to multipoint connection with other servers in the SG.
LSが、LSのLSIDではない受信者IDを持つCSUSメッセージまたはCAメッセージを受信した場合、そのメッセージは破棄して無視する必要があります。 LSはSG内の他のサーバーとのポイントツーマルチポイント接続のリーフになる可能性があるため、これは必要です。
While in the Aligned state, an LS will perform the Cache State Update Protocol as described in Section 2.3.
LSは、Aligned状態のときに、セクション2.3で説明されているように、キャッシュ状態更新プロトコルを実行します。
Note that an LS may receive a CSUS message while in the Aligned State and, the LS MUST respond to the CSUS message with the appropriate CSU Request message in a similar fashion to the method previously described in Section 2.2.3.
LSはAligned状態のときにCSUSメッセージを受信する可能性があることに注意してください。LSは、セクション2.2.3で前述した方法と同様の方法で、適切なCSU要求メッセージでCSUSメッセージに応答する必要があります。
"Cache State Update" (CSU) messages are used to dynamically update the state of cache entries in servers on a given PID/SGID basis. CSU messages contain zero or more "Cache State Advertisement" (CSA) records each of which contains its own snapshot of the state of a particular cache entry. An LS may send/receive a CSU to/from a DCS only when the corresponding CAFSM is in either the Aligned State or the Update Cache State.
「キャッシュ状態更新」（CSU）メッセージは、特定のPID / SGIDベースでサーバーのキャッシュエントリの状態を動的に更新するために使用されます。 CSUメッセージには、0個以上の「キャッシュ状態アドバタイズ」（CSA）レコードが含まれ、各レコードには特定のキャッシュエントリの状態の独自のスナップショットが含まれます。 LSは、対応するCAFSMがAligned状態またはUpdate Cache状態にある場合にのみ、DCSとの間でCSUを送受信できます。
There are two types of CSU messages: CSU Requests and CSU Replies. See Sections B.2.2 and B.2.3 respectively for message formats. A CSU Request message is sent from an LS to one or more DCSs for one of two reasons: either the LS has received a CSUS message and MUST respond only to the DCS which originated the CSUS message, or the LS has become aware of a change of state of a cache entry. An LS becomes aware of a change of state of a cache entry either through receiving a CSU Request from one of its DCSs or as a result of a change of state being observed in a cached entry originated by the LS. In the former case, the LS will send a CSU Request to each of its DCSs except the DCS from which the LS became aware of the change in state. In the latter case, the LS will send a CSU Request to each of its DCSs. The change in state of a particular cache entry is noted in a CSA record which is then appended to the end of the CSU Request message mandatory part. In this way, state changes are propagated throughout the SG.
CSUメッセージには、CSU要求とCSU応答の2種類があります。メッセージ形式については、それぞれセクションB.2.2およびB.2.3を参照してください。 CSU要求メッセージがLSから1つ以上のDCSに送信されるのは、次の2つの理由のいずれかです。LSがCSUSメッセージを受信し、CSUSメッセージを発信したDCSのみに応答する必要がある、またはLSが変更を認識したキャッシュエントリの状態。 LSは、DCSの1つからCSU要求を受信するか、LSが発信したキャッシュされたエントリで状態の変化が観察された結果として、キャッシュエントリの状態の変化を認識します。前者の場合、LSは、LSが状態の変化を認識したDCS以外の各DCSにCSU要求を送信します。後者の場合、LSはそのDCSのそれぞれにCSU要求を送信します。特定のキャッシュエントリの状態の変化は、CSAレコードに記録され、CSAリクエストメッセージの必須部分の最後に追加されます。このようにして、状態変化はSG全体に伝播されます。
Examples of such changes in state are as follows:
このような状態の変化の例は次のとおりです。
1) a server receives a request from a client to add an entry to its cache, 2) a server receives a request from a client to remove an entry from its cache, 3) a cache entry has timed out in the server's cache, has been refreshed in the server's cache, or has been administratively modified.
1）サーバーがクライアントからキャッシュにエントリを追加するリクエストを受信する、2）サーバーがクライアントからリクエストを受信してキャッシュからエントリーを削除する、3）キャッシュエントリーがサーバーのキャッシュでタイムアウトした、サーバーのキャッシュで更新されたか、管理上変更されています。
When an LS receives a CSU Request from one of its DCSs, the LS acknowledges one or more CSA Records which were contained in the CSU Request by sending a CSU Reply. The CSU Reply contains one or more CSAS records which correspond to those CSA records which are being acknowledged. Thus, for example, if a CSA record is dropped (or delayed in processing) by the LS because there are insufficient resources to process it then a corresponding CSAS record is not included in the CSU Reply to the DCS.
LSがそのDCSの1つからCSU要求を受信すると、LSはCSU応答を送信することにより、CSU要求に含まれていた1つ以上のCSAレコードを確認します。 CSU応答には、確認されているCSAレコードに対応する1つ以上のCSASレコードが含まれています。したがって、たとえば、CSAレコードが処理するのに十分なリソースがないためにLSによってドロップされた（または処理が遅延した）場合、対応するCSASレコードはDCSへのCSU応答に含まれません。
Note that an LS may send multiple CSU Request messages before receiving a CSU Reply acknowledging any of the CSA Records contained in the CSU Requests. Note also that a CSU Reply may contain acknowledgments for CSA Records from multiple CSU Requests. Thus, the terms "request" and "reply" may be a bit confusing.
LSは、CSU要求に含まれるCSAレコードのいずれかを確認するCSU応答を受信する前に、複数のCSU要求メッセージを送信する場合があることに注意してください。また、CSU応答には、複数のCSU要求からのCSAレコードの確認応答が含まれる場合があることに注意してください。したがって、「要求」と「応答」という用語は少し混乱するかもしれません。
Note that a CSA Record contains a CSAS Record followed by client/server protocol specific information contained in a cache entry (see Section B.2.0.2 for CSAS record format information and Section B.2.2.1 for CSA record format information). When a CSA record is considered by the LS to represent cached information which is more "up to date" (see Section 2.4) than the cached information contained within the cache of the LS then two things happen: 1) the LS's cache is updated with the more up to date information, and 2) the LS sends a CSU Request containing the CSA Record to each of its DCSs except the one from which the CSA Record arrived. In this way, state changes are propagated within the PID/SGID. Of course, at some point, the LS will also acknowledge the reception of the CSA Record by sending the appropriate DCS a CSU Reply message containing the corresponding CSAS Record.
CSAレコードにはCSASレコードが含まれ、その後にキャッシュエントリに含まれるクライアント/サーバープロトコル固有の情報が続くことに注意してください（CSASレコードフォーマット情報についてはセクションB.2.0.2を、CSAレコードフォーマット情報についてはセクションB.2.2.1を参照）。 CSAレコードがLSによって、LSのキャッシュ内に含まれるキャッシュされた情報よりも「最新」（セクション2.4を参照）のキャッシュされた情報を表すと見なされると、次の2つのことが起こります。1）LSのキャッシュが更新されるより最新の情報、および2）LSは、CSAレコードを含むCSU要求を、CSAレコードが到着したものを除く各DCSに送信します。このようにして、状態の変更はPID / SGID内で伝達されます。もちろん、ある時点で、LSは、対応するCSASレコードを含むCSU応答メッセージを適切なDCSに送信することにより、CSAレコードの受信を確認します。
When an LS sends a new CSU Request, the LS keeps track of the outstanding CSA records in that CSU Request and to which DCSs the LS sent the CSU Request. For each DCS to which the CSU Request was sent, a timer set to CSUReXmtInterval seconds is started just prior to sending the CSU Request. This timer is associated with the CSA Records contained in that CSU Request such that if that timer expires prior to having all CSA Records acknowledged from that DCS then (and only then) a CSU Request is re-sent by the LS to that DCS. However, the re-sent CSU Request only contains those CSA Records which have not yet been acknowledged. If all CSA Records associated with a timer becomes acknowledged then the timer is stopped. Note that the re-sent CSA Records follow the same time-out and retransmit rules as if they were new. Retransmission will occur a configured number of times for a given CSA Record and if acknowledgment fails to occur then an "abnormal event" has occurred at which point the then the HFSM associated with the DCS is transitioned to the Waiting State.
LSが新しいCSU要求を送信すると、LSはそのCSU要求内の未解決のCSAレコードと、LSがCSU要求を送信したDCSを追跡します。 CSU要求が送信された各DCSについて、CSU要求を送信する直前に、CSUReXmtInterval秒に設定されたタイマーが開始されます。このタイマーは、そのCSU要求に含まれるCSAレコードに関連付けられているため、すべてのCSAレコードがそのDCSから確認応答される前にそのタイマーが期限切れになると、LSによってCSU要求がそのDCSに再送信されます。ただし、再送信されたCSU要求には、まだ確認されていないCSAレコードのみが含まれています。タイマーに関連付けられたすべてのCSAレコードが確認されると、タイマーは停止します。再送信されたCSAレコードは、新しい場合と同じタイムアウトおよび再送信ルールに従うことに注意してください。再送信は所定のCSAレコードに対して設定された回数発生し、確認が発生しない場合は「異常なイベント」が発生し、その時点でDCSに関連付けられたHFSMが待機状態に移行します。
A CSA Record instance is said to be on a "DCS retransmit queue" when it is associated with the previously mentioned timer. Only the most up-to-date CSA Record is permitted to be queued to a given DCS retransmit queue. Thus, if a less up-to-date CSA Record is queued to the DCS retransmit queue when a newer CSA Record instance is about to be queued to that DCS retransmit queue then the older CSA Record instance is dequeued and disassociated with its timer immediately prior to enqueuing the newer instance of the CSA Record.
CSA Recordインスタンスは、前述のタイマーに関連付けられている場合、「DCS再送信キュー」にあると言います。最新のCSAレコードのみが、特定のDCS再送信キューにキューイングすることが許可されています。したがって、新しいCSAレコードインスタンスがDCS再送信キューにキューイングされようとしているときに、最新ではないCSAレコードがDCS再送信キューにキューイングされると、古いCSAレコードインスタンスがデキューされ、直前のタイマーとの関連付けが解除されます。 CSAレコードの新しいインスタンスをエンキューします。
When an LS receives a CSU Reply from one of its DCSs then the LS checks each CSAS record in the CSU Reply against the CSAS Record portion of the CSA Records which are queued to the DCS retransmit queue.
LSがそのDCSの1つからCSU応答を受信すると、LSは、CSU応答内の各CSASレコードを、DCS再送信キューにキューイングされているCSAレコードのCSASレコード部分と照合します。
1) If there exists an exact match between the CSAS record portion of the CSA record and a CSAS Record in the CSU Reply then that CSA Record is considered to be acknowledged and is thus dequeued from the DCS retransmit queue and is disassociated with its timer.
1）CSAレコードのCSASレコード部分とCSU応答のCSASレコードの間に完全一致が存在する場合、そのCSAレコードは確認されたと見なされ、DCS再送信キューからデキューされ、タイマーとの関連付けが解除されます。
2) If there exists a match between the CSAS record portion of the CSA record and a CSAS Record in the CSU Reply except for the CSA Sequence number then
2）CSAシーケンス番号を除いて、CSAレコードのCSASレコード部分とCSU応答のCSASレコードの間に一致がある場合
a) If the CSA Record queued to the DCS retransmit queue has a CSA Sequence Number which is greater than the CSA Sequence Number in the CSAS Record of the the CSU Reply then the CSAS Record in the CSU Reply is ignored. b) If the CSA Record queued to the DCS retransmit queue has a CSA Sequence Number which is less than the CSA Sequence Number in the CSAS Record of the the CSU Reply then CSA Record which is queued to the DCS retransmit queue is dequeued and the CSA Record is disassociated with its timer. Further, a CSUS Message is sent to that DCS which sent the more up-to-date CSAS Record. All normal CSUS processing occurs as if the CSUS were sent as part of the CA protocol.
a) DCS再送信キューのキューに入れられたCSAレコードのCSAシーケンス番号が、CSU応答のCSASレコードのCSAシーケンス番号より大きい場合、CSU応答のCSASレコードは無視されます。 b）DCS再送信キューのキューに入れられたCSAレコードのCSAシーケンス番号が、CSU応答のCSASレコードのCSAシーケンス番号より小さい場合、DCS再送信キューのキューに入れられたCSAレコードがデキューされ、CSAレコードはタイマーとの関連付けが解除されています。さらに、CSUSメッセージは、最新のCSASレコードを送信したDCSに送信されます。通常のCSUS処理はすべて、CSUSがCAプロトコルの一部として送信されたかのように発生します。
When an LS receives a CSU Request message which contains a CSA Record which contains a CSA Sequence Number which is smaller than the CSA Sequence number of the cached CSA then the LS MUST acknowledge the CSA record in the CSU Request but it MUST do so by sending a CSU Reply message containing the CSAS Record portion of the CSA Record stored in the cache and not the CSAS Record portion of the CSA Record contained in the CSU Request.
LSが、キャッシュされたCSAのCSAシーケンス番号より小さいCSAシーケンス番号を含むCSAレコードを含むCSUリクエストメッセージを受信すると、LSは、CSUリクエストのCSAレコードを確認する必要がありますが、送信する必要があります。 CSU要求に含まれているCSAレコードのCSASレコード部分ではなく、キャッシュに保存されているCSAレコードのCSASレコード部分を含むCSU応答メッセージ。
An LS responds to CSUS messages from its DCSs by sending CSU Request messages containing the appropriate CSA records to the DCS. If an LS receives a CSUS message containing a CSAS record for an entry which is no longer in its database (e.g., the entry timed out and was discarded after the Cache Alignment exchange completed but before the entry was requested through a CSUS message), then the LS will respond by copying the CSAS Record from the CSUS message into a CSU Request message and the LS will set the N bit signifying that this record is a NULL record since the cache entry no longer exists in the LS's cache. Note that in this case, the "CSA Record" included in the CSU Request to signify the NULL cache entry is literally only a CSAS Record since no client/server protocol specific information exists for the cache entry.
LSは、適切なCSAレコードを含むCSU要求メッセージをDCSに送信することにより、DCSからのCSUSメッセージに応答します。 LSが、データベースに存在しないエントリのCSASレコードを含むCSUSメッセージを受信した場合（たとえば、エントリがタイムアウトし、キャッシュアライメントの交換が完了した後、CSUSメッセージを通じてエントリが要求される前に破棄された場合）、 LSはCSASレコードをCSUSメッセージからCSU要求メッセージにコピーすることで応答し、LSはNビットを設定して、キャッシュエントリがLSのキャッシュに存在しないため、このレコードがNULLレコードであることを示します。この場合、NSUキャッシュエントリを示すCSU要求に含まれる「CSAレコード」は、キャッシュエントリのクライアント/サーバープロトコル固有の情報が存在しないため、文字通りCSASレコードのみであることに注意してください。
If an LS receives a CSA Record in a CSU Request from a DCS for which the LS has an identical CSA record posted to the corresponding DCS's DCS retransmit queue then the CSA Record on the DCS retransmit queue is considered to be implicitly acknowledged. Thus, the CSA Record is dequeued from the DCS retransmit queue and is disassociated with its timer. The CSA Record sent by the DCS MUST still be acknowledged by the LS in a CSU Reply, however. This is useful in the case of point to multipoint connections where the rule that "when an LS receives a CSA record from a DCS, that LS floods the CSA Record to every DCS except the DCS from which it was received" might be broken.
LSが、LSSが対応するDCSのDCS再送信キューにポストされた同一のCSAレコードを持つDCSからのCSU要求でCSAレコードを受信した場合、DCS再送信キューのCSAレコードは暗黙的に確認されたと見なされます。したがって、CSAレコードはDCS再送信キューからデキューされ、タイマーとの関連付けが解除されます。ただし、DCSによって送信されたCSAレコードは、LSによってCSU応答で確認されなければなりません（MUST）。これは、「LSがDCSからCSAレコードを受信すると、LSがCSAレコードを、それが送信されたDCSを除くすべてのDCSにフラッディングする」というルールが破られる可能性があるポイントツーマルチポイント接続の場合に役立ちます。
If an LS receives a CSU with a Receiver ID which is not equal to the LSID and is not set to all 0xFFs then the CSU must be discarded and ignored. This is necessary since the LS may be a leaf of a point to multipoint connection with other servers in the LS's SG.
LSが、LSIDと等しくなく、すべての0xFFに設定されていないレシーバーIDを持つCSUを受信した場合、CSUを破棄して無視する必要があります。これは、LSがLSのSG内の他のサーバーとのポイントツーマルチポイント接続のリーフになる可能性があるために必要です。
An LS MAY send a CSU Request to the all 0xFFs Receiver ID when the LS is a root of a point to multipoint connection with a set of its DCSs. If an LS receives a CSU Request with the all 0xFFs Receiver ID then it MUST use the Sender ID in the CSU Request as the Receiver ID of the CSU Reply (i.e., it MUST unicast its response to the sender of the request) when responding. If the LS wishes to send a CSU Request to the all 0xFFs Receiver ID then it MUST create a time-out and retransmit timer for each of the DCSs which are leaves of the point to multipoint connection prior to sending the CSU Request. If in this case, the time-out and retransmit timer expires for a given DCS prior to acknowledgment of a given CSA Record then the LS MUST use the specific DCSID as the Receiver ID rather than the all 0xFFs Receiver ID. Similarly, if it is necessary to re-send a CSA Record then the LS MUST specify the specific DCSID as the Receiver ID rather than the all 0xFFs Receiver ID.
LSがそのDCSのセットとのポイントツーマルチポイント接続のルートである場合、LSはすべての0xFFsレシーバーIDにCSU要求を送信する場合があります。 LSがすべて0xFFsの受信者IDでCSU要求を受信した場合、応答時に、CSU要求の送信者IDをCSU応答の受信者IDとして使用する必要があります（つまり、要求の送信者への応答をユニキャストする必要があります）。 LSがすべての0xFFsレシーバーIDにCSU要求を送信したい場合、CSU要求を送信する前に、ポイントツーマルチポイント接続のリーフである各DCSのタイムアウトと再送信タイマーを作成する必要があります。この場合、特定のCSAレコードの確認応答の前に、特定のDCSのタイムアウトおよび再送信タイマーが期限切れになると、LSは、すべての0xFFsレシーバーIDではなく、特定のDCSIDをレシーバーIDとして使用する必要があります。同様に、CSAレコードを再送信する必要がある場合、LSは、すべての0xFFsレシーバーIDではなく、レシーバーIDとして特定のDCSIDを指定する必要があります。
Note that if a set of servers are in a full mesh of point to multipoint connections, and one server of that mesh sends a CSU Request into that full mesh, and the sending server sends the CSA Records in the CSU Request to the all 0xFFs Receiver ID then it would not be necessary for every other server in the mesh to source their own CSU Request containing those CSA Records into the mesh in order to properly flood the CSA Records. This is because every server in the mesh would have heard the CSU Request and would have processed the included CSA Records as appropriate. Thus, a server in a full mesh could consider the mesh to be a single logical port and so the rule that "when an LS receives a CSA record from a DCS, that LS floods the CSA Record to every DCS except the DCS from which it was received" is not broken. A receiving server in the full mesh would still need to acknowledge the CSA records with CSU Reply messages which contain the LSID of the replying server as the Sender ID and the ID of the server which sent the CSU Request as the Receiver ID field. In the time out and retransmit case, the Receiver ID of the CSU Request would be set to the specific DCSID which did not acknowledge the CSA Record (as opposed to the all 0xFFs Receiver ID). Since a full mesh emulates a broadcast media for the servers attached to the full mesh, use of SCSP on a broadcast medium might use this technique as well. Further discussion of this use of a full mesh or use of a broadcast media is left to the client/server protocol specific documents.
サーバーのセットがポイントツーマルチポイント接続のフルメッシュにあり、そのメッシュの1つのサーバーがCSU要求をそのフルメッシュに送信し、送信サーバーがCSU要求のCSAレコードをすべての0xFFレシーバーに送信することに注意してください。 IDを使用すると、CSAレコードを適切にフラッディングするために、メッシュ内の他のすべてのサーバーがそれらのCSAレコードを含む独自のCSUリクエストをメッシュに送信する必要がなくなります。これは、メッシュ内のすべてのサーバーがCSU要求を受信し、含まれているCSAレコードを適切に処理したためです。したがって、フルメッシュのサーバーは、メッシュを単一の論理ポートと見なすことができるため、「LSがDCSからCSAレコードを受信すると、LSは、CSAレコードを、それが送信元のDCSを除くすべてのDCSにフラッディングする受け取りました」は壊れていません。フルメッシュ内の受信サーバーは、送信側IDとして応答サーバーのLSIDと受信側IDフィールドとしてCSU要求を送信したサーバーのIDを含むCSU応答メッセージでCSAレコードを確認する必要があります。タイムアウトおよび再送信の場合、CSU要求の受信者IDは、CSAレコードを確認応答しなかった特定のDCSIDに設定されます（すべての0xFFの受信者IDではなく）。フルメッシュは、フルメッシュに接続されたサーバーのブロードキャストメディアをエミュレートするため、ブロードキャストメディアでSCSPを使用すると、この手法も使用される場合があります。このフルメッシュの使用またはブロードキャストメディアの使用についての詳細は、クライアント/サーバープロトコル固有のドキュメントに委ねられています。
During the cache alignment process and during normal CSU processing, a CSAS Record is compared against the contents of an LS's cache entry to decide whether the information contained in the record is more "up to date" than the corresponding cache entry of the LS.
キャッシュアライメントプロセス中および通常のCSU処理中に、CSASレコードはLSのキャッシュエントリの内容と比較され、レコードに含まれる情報がLSの対応するキャッシュエントリよりも「最新」であるかどうかが判断されます。
There are three pieces of information which are used in determining whether a record contains information which is more "up to date" than the information contained in the cache entry of an LS which is processing the record: 1) the Cache Key, 2) the Originator which is described by an Originator ID (OID), and 3) the CSA Sequence number. See Section B.2.0.2 for more information on these fields.
レコードに、レコードを処理しているLSのキャッシュエントリに含まれている情報よりも「最新」の情報が含まれているかどうかを判断するために使用される情報は3つあります。1）キャッシュキー、2） Originator ID（OID）で記述されたOriginator、および3）CSAシーケンス番号。これらのフィールドの詳細については、セクションB.2.0.2を参照してください。
Given these three pieces of information, a CSAS record (be it part of a CSA Record or be it stand-alone) is considered to be more "up to date" than the information contained in the cache of an LS if all of the following are true:
これらの3つの情報が与えられた場合、CSASレコード（CSAレコードの一部であっても、スタンドアロンであっても）は、以下のすべての場合、LSのキャッシュに含まれる情報よりも「最新」であると見なされます。本当です：
1) The Cache Key in the CSAS Record matches the stored Cache Key in the LS's cache entry, 2) The OID in the CSAS Record matches the stored OID in the LS's cache entry, 3) The CSA Sequence Number in the CSAS Record is greater than CSA Sequence Number in the LS's cache entry.
1）CSASレコードのキャッシュキーがLSのキャッシュエントリの保存されたキャッシュキーと一致する、2）CSASレコードのOIDがLSのキャッシュエントリの保存されたOIDと一致する、3）CSASレコードのCSAシーケンス番号がより大きいLSのキャッシュエントリのCSAシーケンス番号より。
Discussion and Conclusions
議論と結論
While the above text is couched in terms of synchronizing the knowledge of the state of a client within the cache of servers contained in a SG, this solution generalizes easily to any number of database synchronization problems (e.g., LECS synchronization).
上記のテキストは、SGに含まれているサーバーのキャッシュ内のクライアントの状態の知識を同期するという観点から説明されていますが、このソリューションは、任意の数のデータベース同期問題（LECS同期など）に簡単に一般化できます。
SCSP defines a generic flooding protocol. There are a number of related issues relative to cache maintenance and topology maintenance which are more appropriately defined in the client/server protocol specific documents; for example, it might be desirable to define a generic cache entry time-out mechanism for a given protocol or to advertise adjacency information between servers so that one could obtain a topo-map of the servers in a SG. When mechanisms like these are desirable, they will be defined in the client/server protocol specific documents.
SCSPは、一般的なフラッディングプロトコルを定義します。クライアント/サーバープロトコル固有のドキュメントでより適切に定義されている、キャッシュのメンテナンスとトポロジーのメンテナンスに関連する多くの関連する問題があります。たとえば、特定のプロトコルの汎用キャッシュエントリタイムアウトメカニズムを定義するか、SG内のサーバーのトポロジマップを取得できるようにサーバー間の隣接情報をアドバタイズすることが望ましい場合があります。このようなメカニズムが望ましい場合は、クライアント/サーバープロトコル固有のドキュメントで定義されます。
Appendix A: Terminology and Definitions
付録A：用語と定義
CA Message - Cache Alignment Message These messages allow an LS to synchronize its entire cache with that of the cache of one of its DCSs.
CAメッセージ-キャッシュアライメントメッセージこれらのメッセージにより、LSはキャッシュ全体をDCSの1つのキャッシュと同期させることができます。
CAFSM - Cache Alignment Finite State Machine The CAFSM monitors the state of the cache alignment between an LS and a particular DCS. There exists one CAFSM per DCS as seen from an LS.
CAFSM-キャッシュアラインメント有限状態マシンCAFSMは、LSと特定のDCS間のキャッシュアラインメントの状態を監視します。 LSから見た場合、DCSごとに1つのCAFSMが存在します。
CSA Record - Cache State Advertisement Record A CSA is a record within a CSU message which identifies an update to the status of a "particular" cache entry.
CSAレコード-キャッシュステートアドバタイズメントレコードCSAは、「特定の」キャッシュエントリのステータスの更新を識別するCSUメッセージ内のレコードです。
CSAS Record - Cache State Advertisement Summary Record A CSAS contains a summary of the information in a CSA. A server will send CSAS records describing its cache entries to another server during the cache alignment process. CSAS records are also included in a CSUS messages when an LS wants to request the entire CSA from the DCS. The LS is requesting the CSA from the DCS because the LS believes that the DCS has a more recent view of the state of the cache entry in question.
CSASレコード-キャッシュステートアドバタイズメントの要約レコードCSASには、CSA内の情報の要約が含まれています。サーバーは、キャッシュアライメントプロセス中に、キャッシュエントリを説明するCSASレコードを別のサーバーに送信します。 LSがDCSからCSA全体を要求する場合、CSASレコードはCSUSメッセージにも含まれます。 LSはDCSが問題のキャッシュエントリの状態のより最近のビューを持っていると信じているため、LSはDCSからCSAを要求しています。
CSU Message - Cache State Update message This is a message sent from an LS to its DCSs when the LS becomes aware of a change in state of a cache entry.
CSUメッセージ-キャッシュ状態更新メッセージこれは、LSがキャッシュエントリの状態の変化を認識したときに、LSからそのDCSに送信されるメッセージです。
CSUS Message - Cache State Update Solicit Message This message is sent by an LS to its DCS after the LS and DCS have exchanged CA messages. The CSUS message contains one or more CSAS records which represent solicitations for entire CSA records (as opposed to just the summary information held in the CSAS).
CSUSメッセージ-キャッシュ状態更新要請メッセージこのメッセージは、LSとDCSがCAメッセージを交換した後に、LSからそのDCSに送信されます。 CSUSメッセージには、（CSASに保持されている要約情報だけではなく）CSAレコード全体の要請を表す1つ以上のCSASレコードが含まれています。
DCS - Directly Connected Server The DCS is a server which is directly connected to the LS; e.g., there exists a VC between the LS and DCS. This term, along with the terms LS and RS, is used to give a frame of reference when talking about servers and their synchronization. Unless explicitly stated to the contrary, there is no implied difference in functionality between a DCS, LS, and RS.
DCS-直接接続されたサーバーDCSは、LSに直接接続されたサーバーです。たとえば、LSとDCSの間にVCが存在します。この用語は、LSおよびRSという用語とともに、サーバーとその同期について説明する際の参照フレームを提供するために使用されます。明確に反対の記述がない限り、DCS、LS、およびRSの機能に暗黙の違いはありません。
HFSM - Hello Finite State Machine An LS has a HFSM associated with each of its DCSs. The HFSM monitors the state of the connectivity between the LS and a particular DCS.
HFSM-Hello有限状態マシンLSには、各DCSに関連付けられたHFSMがあります。 HFSMは、LSと特定のDCSの間の接続状態を監視します。
LS - Local Server The LS is the server under scrutiny; i.e., all statements are made from the perspective of the LS. This term, along with the terms DCS and RS, is used to give a frame of reference when talking about servers and their synchronization. Unless explicitly stated to the contrary, there is no implied difference in functionality between a DCS, LS, and RS.
LS-ローカルサーバーLSは、監視対象のサーバーです。つまり、すべてのステートメントはLSの観点から作成されます。この用語は、DCSおよびRSという用語とともに、サーバーとその同期について説明する際の参照フレームを提供するために使用されます。明確に反対の記述がない限り、DCS、LS、およびRSの機能に暗黙の違いはありません。
LSID - Local Server ID The LSID is a unique token that identifies an LS. This value might be taken from the protocol address of the LS.
LSID-ローカルサーバーID LSIDは、LSを識別する一意のトークンです。この値は、LSのプロトコルアドレスから取得される場合があります。
PID - Protocol ID This field contains an identifier which identifies the client/server protocol which is making use of SCSP for the given message. The assignment of Protocol IDs for this field is given over to IANA as described in Section C.
PID-プロトコルIDこのフィールドには、特定のメッセージにSCSPを使用しているクライアント/サーバープロトコルを識別する識別子が含まれています。このフィールドのプロトコルIDの割り当ては、セクションCで説明されているようにIANAに渡されます。
RS - Remote Server (RS) From the perspective of an LS, an RS is a server, separate from the LS, which is not directly connected to the LS (i.e., an RS is always two or more hops away from an LS whereas a DCS is always one hop away from an LS). Unless otherwise stated an RS refers to a server in the SG. This term, along with the terms LS and DCS, is used to give a frame of reference when talking about servers and their synchronization. Unless explicitly stated to the contrary, there is no implied difference in functionality between a DCS, LS, and RS.
RS-リモートサーバー（RS）LSの観点から見ると、RSはLSとは別のサーバーであり、LSに直接接続されていません（つまり、RSは常にLSから2ホップ以上離れていますが、 DCSは常にLSから1ホップ離れています。特に明記しない限り、RSはSG内のサーバーを指します。この用語は、LSおよびDCSという用語とともに、サーバーとその同期について説明するときに参照の枠組みを示すために使用されます。明確に反対の記述がない限り、DCS、LS、およびRSの機能に暗黙の違いはありません。
SG - Server Group The SCSP synchronizes caches (or a portion of the caches) of a set of server entities which are bound to a SG through some means (e.g., all servers belonging to a Logical IP Subnet (LIS)[1]). Thus an SG is just a grouping of servers around some commonality.
SG-サーバーグループSCSPは、なんらかの方法でSGにバインドされている一連のサーバーエンティティ（たとえば、論理IPサブネット（LIS）[1]に属するすべてのサーバー）のキャッシュ（またはキャッシュの一部）を同期します。したがって、SGは、いくつかの共通点に基づくサーバーの単なるグループです。
SGID - Server Group ID This ID is a 16 bit identification field that uniquely identifies the instance client/server protocol for which the servers of the SG are being synchronized. This implies that multiple instances of the same protocol may be in operation at the same time and have their servers synchronized independently of each other.
SGID-サーバーグループIDこのIDは、SGのサーバーが同期されているインスタンスクライアント/サーバープロトコルを一意に識別する16ビットの識別フィールドです。これは、同じプロトコルの複数のインスタンスが同時に動作していて、サーバーが互いに独立して同期している可能性があることを意味します。
Appendix B: SCSP Message Formats
付録B：SCSPメッセージ形式
This section of the appendix includes the message formats for SCSP. SCSP protocols are LLC/SNAP encapsulated with an LLC=0xAA-AA-03 and OUI=0x00-00-5e and PID=0x00-05.
付録のこのセクションには、SCSPのメッセージ形式が含まれています。 SCSPプロトコルは、LLC = 0xAA-AA-03およびOUI = 0x00-00-5eおよびPID = 0x00-05でカプセル化されたLLC / SNAPです。
SCSP has 3 parts to every packet: the fixed part, the mandatory part, and the extensions part. The fixed part of the message exists in every packet and is shown below. The mandatory part is specific to the particular message type (i.e., CA, CSU Request/Reply, Hello, CSUS) and, it includes (among other packet elements) a Mandatory Common Part and zero or more records each of which contains information pertinent to the state of a particular cache entry (except in the case of a Hello message) whose information is being synchronized within a SG. The extensions part contains the set of extensions for the SCSP message.
SCSPには、すべてのパケットに対して3つの部分があります。固定部分、必須部分、および拡張部分です。メッセージの固定部分はすべてのパケットに存在し、以下に示されています。必須部分は特定のメッセージタイプ（CA、CSU要求/応答、Hello、CSUSなど）に固有であり、（他のパケット要素の中で）必須共通部分と、それぞれに関連する情報を含む0個以上のレコードが含まれます情報がSG内で同期されている特定のキャッシュエントリ（Helloメッセージの場合を除く）の状態。拡張部分には、SCSPメッセージの拡張のセットが含まれています。
In the following message formats, the fields marked as "unused" MUST be set to zero upon transmission of such a message and ignored upon receipt of such a message.
次のメッセージ形式では、「未使用」としてマークされたフィールドは、そのようなメッセージの送信時にゼロに設定されなければならず、そのようなメッセージの受信時に無視されなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type Code | Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Start Of Extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version This is the version of the SCSP protocol being used. The current version is 1.
バージョンこれは、使用されているSCSPプロトコルのバージョンです。現在のバージョンは1です。
Type Code This is the code for the message type (e.g., Hello (5), CSU Request(2), CSU Reply(3), CSUS (4), CA (1)).
タイプコードこれは、メッセージタイプのコードです（Hello（5）、CSU Request（2）、CSU Reply（3）、CSUS（4）、CA（1）など）。
Packet Size The total length of the SCSP packet, in octets (excluding link layer and/or other protocol encapsulation).
パケットサイズSCSPパケットの全長（オクテット単位）（リンク層や他のプロトコルのカプセル化を除く）。
Checksum The standard IP checksum over the entire SCSP 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.
チェックサム固定ヘッダーから始まるSCSPパケット全体の標準IPチェックサム。パケットの長さが奇数バイトである場合、この計算は、0x00に設定されたバイトがパケットの最後に追加されるかのように実行されます。
Start Of Extensions This field is coded as zero when no extensions are present in the message. If extensions are present then this field will be coded with the offset from the top of the fixed header to the beginning of the first extension.
Start Of Extensionsこのフィールドは、メッセージに拡張が存在しない場合、ゼロとしてコード化されます。拡張が存在する場合、このフィールドは、固定ヘッダーの先頭から最初の拡張の先頭までのオフセットでコード化されます。
The mandatory part of the SCSP packet contains the operation specific information for a given message type (e.g., SCSP Cache State Update Request/Reply, etc.), and it includes (among other packet elements) a Mandatory Common Part (described in Section B.2.0.1) and zero or more records each of which contains information pertinent to the state of a particular cache entry (except in the case of a Hello message) whose information is being synchronized within a SG. These records may, depending on the message type, be either Cache State Advertisement Summary (CSAS) Records (described in Section B.2.0.2) or Cache State Advertisement (CSA) Records (described in Section B.2.2.1). CSA Records contain a summary of a cache entry's information (i.e., a CSAS Record) plus some additional client/server protocol specific information. The mandatory common part format and CSAS Record format is shown immediately below, prior to showing their use in SCSP messages, in order to prevent replication within the message descriptions.
SCSPパケットの必須部分には、特定のメッセージタイプの操作固有情報（SCSPキャッシュ状態更新要求/応答など）が含まれ、必須の共通部分（セクションBで説明）が（他のパケット要素の中で）含まれています。 .2.0.1）および0個以上のレコードには、SG内で情報が同期されている特定のキャッシュエントリ（Helloメッセージの場合を除く）の状態に関連する情報が含まれます。これらのレコードは、メッセージタイプに応じて、キャッシュ状態アドバタイズメントサマリー（CSAS）レコード（セクションB.2.0.2で説明）またはキャッシュ状態アドバタイズメント（CSA）レコード（セクションB.2.2.1で説明）のいずれかになります。 CSAレコードには、キャッシュエントリの情報（つまり、CSASレコード）の概要と、クライアント/サーバープロトコル固有の追加情報が含まれています。メッセージの説明内での複製を防ぐために、SCSPメッセージでの使用を示す前に、必須の共通部分フォーマットとCSASレコードフォーマットをすぐ下に示します。
Sections B.2.1 through B.2.5 have a substantial overlap in format. This overlapping format is called the mandatory common part and its format is shown below:
セクションB.2.1からB.2.5までは、形式がかなり重複しています。この重複する形式は必須の共通部分と呼ばれ、その形式を以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | Server Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID Len | Recvr ID Len | Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol ID
This field contains an identifier which identifies the
client/server protocol which is making use of SCSP for the given
message. The assignment of Protocol IDs for this field is given
over to IANA as described in Section C. Protocols with current
documents have the following defined values:
1 - ATMARP 2 - NHRP 3 - MARS 4 - DHCP 5 - LNNI
1-ATMARP 2-NHRP 3-MARS 4-DHCP 5-LNNI
Server Group ID This ID is uniquely identifies the instance of a given client/server protocol for which servers are being synchronized.
サーバーグループIDこのIDは、サーバーが同期されている特定のクライアント/サーバープロトコルのインスタンスを一意に識別します。
Flags The Flags field is message specific, and its use will be described in the specific message format sections below.
フラグフラグフィールドはメッセージ固有であり、その使用については、以下の特定のメッセージフォーマットのセクションで説明します。
Sender ID Len This field holds the length in octets of the Sender ID.
Sender ID Lenこのフィールドは、Sender IDの長さをオクテット単位で保持します。
Recvr ID Len This field holds the length in octets of the Receiver ID.
Recvr ID Lenこのフィールドは、レシーバIDの長さをオクテット単位で保持します。
Number of Records This field contains the number of additional records associated with the given message. The exact format of these records is specific to the message and will be described for each message type in the sections below.
レコード数このフィールドには、特定のメッセージに関連付けられた追加のレコードの数が含まれます。これらのレコードの正確な形式はメッセージに固有であり、以下のセクションで各メッセージタイプについて説明します。
Sender ID This is an identifier assigned to the server which is sending the given message. One possible assignment might be the protocol address of the sending server.
送信者IDこれは、特定のメッセージを送信しているサーバーに割り当てられた識別子です。割り当ての1つとして、送信サーバーのプロトコルアドレスが考えられます。
Receiver ID This is an identifier assigned to the server which is to receive the given message. One possible assignment might be the protocol address of the server which is to receive the given message.
受信者IDこれは、特定のメッセージを受信するサーバーに割り当てられた識別子です。考えられる割り当ての1つは、特定のメッセージを受信するサーバーのプロトコルアドレスです。
CSAS records contain a summary of information contained in a cache entry of a given client/server database which is being synchronized through the use of SCSP. The summary includes enough information for SCSP to look into the client/server database for the appropriate database cache entry and then compare the "newness" of the summary against the "newness" of the cached entry.
CSASレコードには、SCSPを使用して同期されている特定のクライアント/サーバーデータベースのキャッシュエントリに含まれる情報の概要が含まれています。要約には、SCSPがクライアント/サーバーデータベースを調べて適切なデータベースキャッシュエントリを探し、要約の「新しさ」とキャッシュされたエントリの「新しさ」を比較するのに十分な情報が含まれています。
Note that CSAS records do not contain a Server Group ID (SGID) nor do they contain a Protocol ID. These IDs are necessary to identify which protocol and which instance of that protocol for which the summary is applicable. These IDs are present in the mandatory common part of each message.
CSASレコードにはサーバーグループID（SGID）が含まれておらず、プロトコルIDも含まれていないことに注意してください。これらのIDは、要約が適用されるプロトコルとそのプロトコルのインスタンスを識別するために必要です。これらのIDは、各メッセージの必須の共通部分に存在します。
Note also that the values of the Hop Count and Record Length fields of a CSAS Record are dependent on whether the CSAS record exists as a "stand-alone" record or whether the CSAS record is "embedded" in CSA Record. This is further described below.
CSASレコードのホップカウントフィールドとレコード長フィールドの値は、CSASレコードが「スタンドアロン」レコードとして存在するかどうか、またはCSASレコードがCSAレコードに「埋め込まれている」かどうかにも依存することに注意してください。これについては、以下でさらに説明します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key Len | Orig ID Len |N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop Count This field represents the number of hops that the record may take before being dropped. Thus, at each server that the record traverses, the Hop Count is decremented. This field is set to 1 when the CSAS record is a "stand-alone" record (i.e., it is not embedded within a CSA record) since summaries do not go beyond one hop during the cache alignment process. If a CSAS record is "embedded" within a CSA record then the Hop Count is set to an administratively defined value which is almost certainly greater than or equal to the the cardinality of the SG minus one. Note that an exception to the previous rule occurs when the CSA Record is carried within a CSU Request which was sent in response to a solicitation (i.e., in response to a CSAS Record which was sent in a CSUS message); in which case, the Hop Count SHOULD be set to 1.
ホップカウントこのフィールドは、レコードがドロップされるまでのホップ数を表します。したがって、レコードが通過する各サーバーで、ホップカウントが減少します。 CSASレコードが「スタンドアロン」レコードの場合（つまり、CSAレコード内に埋め込まれていない場合）、このフィールドは1に設定されます。これは、キャッシュアライメントプロセス中に要約が1ホップを超えないためです。 CSASレコードがCSAレコード内に「埋め込まれている」場合、ホップカウントは、ほぼ確実にSGのカーディナリティから1を引いた値以上の、管理上定義された値に設定されます。前のルールの例外は、CSAレコードが請求に応じて（つまり、CSUSメッセージで送信されたCSASレコードに応じて）送信されたCSUリクエスト内で運ばれるときに発生することに注意してください。その場合、ホップカウントは1に設定する必要があります（SHOULD）。
Record Length If the CSAS record is a "stand-alone" record then this value is 12+"Cache Key Leng"+"Orig ID Len" in bytes; otherwise, this value is set to 12+"Cache Key Leng"+"Orig ID Len"+ sizeof("Client/Server Protocol Specific Part for cache entry"). The size of the Client/Server Protocol Specific Part may be obtained from the client/server protocol specific document for the given Protocol ID.
レコード長CSASレコードが「スタンドアロン」レコードの場合、この値は12+ "Cache Key Leng" + "Orig ID Len"（バイト）です。それ以外の場合、この値は12+ "Cache Key Leng" + "Orig ID Len" + sizeof（ "Cache / Server Protocol Specific Part for cache entry"）に設定されます。クライアント/サーバープロトコル固有の部分のサイズは、指定されたプロトコルIDのクライアント/サーバープロトコル固有のドキュメントから取得できます。
Cache Key Len Length of the Cache Key field in bytes.
キャッシュキーの長さキャッシュキーフィールドの長さ（バイト単位）。
Orig ID Len. Length of the Originator ID field in bytes.
元のIDレンズ。 Originator IDフィールドの長さ（バイト単位）。
N The "N" bit signifies that this CSAS Record is actually a Null record. This bit is only used in a CSAS Record contained in a CSU Request/Reply which is sent in response to a CSUS message. It is possible that an LS may receive a solicitation for a CSA record when the cache entry represented by the solicited CSA Record no longer exists in the LS's cache (see Section 2.3 for details). In this case, the LS copies the CSAS Record directly from the CSUS message into the CSU Request, and the LS sets the N bit signifying that the cache entry does not exist any longer. The DCS which solicited the CSA record which no longer exists will still respond with a CSU Reply. This bit is usually set to zero.
N「N」ビットは、このCSASレコードが実際にはヌルレコードであることを示します。このビットは、CSUSメッセージに応答して送信されるCSU要求/応答に含まれるCSASレコードでのみ使用されます。要請されたCSAレコードによって表されるキャッシュエントリがLSのキャッシュに存在しない場合、LSはCSAレコードの要請を受け取る可能性があります（詳細はセクション2.3を参照）。この場合、LSはCSASレコードをCSUSメッセージからCSU要求に直接コピーし、LSはNビットを設定して、キャッシュエントリが存在しないことを示します。存在しないCSAレコードを要求したDCSは、引き続きCSU応答で応答します。このビットは通常ゼロに設定されます。
CSA Sequence Number This field contains a sequence number that identifies the "newness" of a CSA record instance being summarized. A "larger" sequence number means a more recent advertisement. Thus, if the state of part (or all) of a cache entry needs to be updated then the CSA record advertising the new state MUST contain a CSA Sequence Number which is larger than the one corresponding to the previous advertisement. This number is assigned by the originator of the CSA record. The CSA Sequence Number may be assigned by the originating server or by the client which caused its server to advertise its existence.
CSAシーケンス番号このフィールドには、要約されるCSAレコードインスタンスの「新しさ」を識別するシーケンス番号が含まれます。 「より大きな」シーケンス番号は、より新しい広告を意味します。したがって、キャッシュエントリの一部（またはすべて）の状態を更新する必要がある場合、新しい状態をアドバタイズするCSAレコードには、前のアドバタイズメントに対応するものよりも大きいCSAシーケンス番号を含める必要があります。この番号は、CSAレコードの作成者によって割り当てられます。 CSAシーケンス番号は、元のサーバーによって、またはその存在をアドバタイズする原因となったクライアントによって割り当てられます。
The CSA Sequence Number is a signed 32 bit number. Within the CSA Sequence Number space, the number -2^31 (0x80000000) is reserved. Thus, the usable portion of the CSA Sequence Number space for a given Cache Key is between the numbers -2^31+1 (0x80000001) and 2^31-1 (0x7fffffff). An LS uses -2^31+1 the first time it originates a CSA Record for a cache entry that it created. Each time the cache entry is modified in some manner and when that modification needs to be synchronized with the other servers in the SG, the LS increments the CSA Sequence number associated with the given Cache Key and uses that new CSA Sequence Number when advertising the update. If it is ever the case that a given CSA Sequence Number has reached 2^31-2 and the associated cache entry has been modified such that an update must be sent to the rest of the servers in the SG then the given cache entry MUST first be purged from the SG by the LS by sending a CSA Record which causes the cache entry to be removed from other servers and this CSA Record carries a CSA Sequence Number of 2^31-1. The exact packet format and mechanism by which a cache entry is purged is defined in the appropriate protocol specific document. After the purging CSA Record has been acknowledged by each DCS, an LS will then send a new CSA Record carrying the updated information, and this new CSA Record will carry a CSA Sequence Number of -2^31+1.
CSAシーケンス番号は、符号付き32ビット番号です。 CSAシーケンス番号スペース内で、数値-2 ^ 31（0x80000000）が予約されています。したがって、特定のキャッシュキーのCSAシーケンス番号スペースの使用可能な部分は、-2 ^ 31 + 1（0x80000001）と2 ^ 31-1（0x7fffffff）の間です。 LSは、作成したキャッシュエントリのCSAレコードを初めて作成するときに-2 ^ 31 + 1を使用します。キャッシュエントリが何らかの方法で変更されるたびに、その変更をSG内の他のサーバーと同期する必要がある場合、LSは指定されたキャッシュキーに関連付けられたCSAシーケンス番号をインクリメントし、更新をアドバタイズするときにその新しいCSAシーケンス番号を使用します。特定のCSAシーケンス番号が2 ^ 31-2に達し、関連するキャッシュエントリが変更されて更新がSG内の残りのサーバーに送信される必要がある場合は、所定のキャッシュエントリを最初に指定する必要があります。キャッシュエントリが他のサーバーから削除される原因となるCSAレコードを送信することにより、LSによってSGからSGからパージされ、このCSAレコードには2 ^ 31-1のCSAシーケンス番号が含まれます。キャッシュエントリが削除される正確なパケット形式とメカニズムは、適切なプロトコル固有のドキュメントで定義されています。パージするCSAレコードが各DCSによって確認された後、LSは更新された情報を運ぶ新しいCSAレコードを送信し、この新しいCSAレコードは-2 ^ 31 + 1のCSAシーケンス番号を運ぶ。
After a restart occurs and after the restarting LS's CAFSM has achieved the Aligned state, if an update to an existing cache entry needs to be synchronized or a new cache entry needs to be synchronized then the ensuing CSA Record MUST contain a CSA Sequence Number which is unique within the SG for the given OID and Cache Key. The RECOMMENDED method of obtaining this number (unless explicitly stated to the contrary in the protocol specific document) is to set the CSA Sequence Number in the CSA Record to the CSA Sequence Number associated with the existing cache entry (if an out of date cache entry already exists and zero if not) plus a configured constant. Note that the protocol specific document may require that all cache entries containing the OID of the restarting LS be purged prior to updating the cache entries; in this case, the updating CSA Record will still contain a CSA Sequence Number set to the CSA Sequence Number associated with the previously existing cache entry plus a configured constant.
再起動が発生し、LSのCAFSMがAligned状態に達した後、既存のキャッシュエントリの更新を同期する必要がある場合、または新しいキャッシュエントリを同期する必要がある場合は、次のCSAレコードにCSAシーケンス番号を含める必要があります。指定されたOIDとキャッシュキーのSG内で一意。この番号を取得するための推奨される方法（プロトコル固有のドキュメントで反対に明示されていない限り）は、CSAレコードのCSAシーケンス番号を既存のキャッシュエントリに関連付けられているCSAシーケンス番号に設定することです（古いキャッシュエントリの場合）すでに存在し、存在しない場合はゼロ）と構成済み定数。プロトコル固有のドキュメントでは、キャッシュエントリを更新する前に、再起動中のLSのOIDを含むすべてのキャッシュエントリを消去する必要があることに注意してください。この場合、更新中のCSAレコードには、以前に存在したキャッシュエントリに関連付けられたCSAシーケンス番号に設定されたCSAシーケンス番号と、構成された定数が含まれます。
Cache Key This is a database lookup key that uniquely identifies a piece of data which the originator of a CSA Record wishes to synchronize with its peers for a given "Protocol ID/Server Group ID" pair. This key will generally be a small opaque byte string which SCSP will associate with a given piece of data in a cache. Thus, for example, an originator might assign a particular 4 byte string to the binding of an IP address with that of an ATM address. Generally speaking, the originating server of a CSA record is responsible for generating a Cache Key for every element of data that the the given server originates and which the server wishes to synchronize with its peers in the SG.
キャッシュキーこれは、CSAレコードの発信者が特定の「プロトコルID /サーバーグループID」のペアのピアと同期することを希望するデータを一意に識別するデータベースルックアップキーです。このキーは、通常、小さな不透明なバイト文字列であり、SCSPはキャッシュ内の特定のデータに関連付けます。したがって、たとえば、発信者はIPアドレスとATMアドレスのバインディングに特定の4バイト文字列を割り当てることができます。一般的に言えば、CSAレコードの発信元サーバーは、特定のサーバーが発信し、サーバーがSGのピアと同期することを望むデータのすべての要素のキャッシュキーを生成する責任があります。
Originator ID This field contains an ID administratively assigned to the server which is the originator of CSA Records.
発信者IDこのフィールドには、CSAレコードの発信者であるサーバーに管理上割り当てられたIDが含まれます。
The Cache Alignment (CA) message allows an LS to synchronize its entire cache with that of the cache of its DCSs within a server group. The CA message type code is 1. The CA message mandatory part format is as follows:
キャッシュアライメント（CA）メッセージにより、LSはキャッシュ全体をサーバーグループ内のDCSのキャッシュと同期させることができます。 CAメッセージタイプコードは1です。CAメッセージの必須部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CA Sequence Number A value which provides a unique identifier to aid in the sequencing of the cache alignment process. A "larger" sequence number means a more recent CA message. The slave server always copies the sequence number from the master server's previous CA message into its current CA message which it is sending and the the slave acknowledges the master's CA message. Since the initial CA process is lock-step, if the slave does not receive the same sequence number which it previously received then the information in the slave's previous CA message is implicitly acknowledged. Note that there is a separate CA Sequence Number space associated with each CAFSM.
CAシーケンス番号キャッシュアライメントプロセスのシーケンスを支援する一意の識別子を提供する値。 「より大きい」シーケンス番号は、より新しいCAメッセージを意味します。スレーブサーバーは常に、シーケンス番号をマスターサーバーの以前のCAメッセージから送信中の現在のCAメッセージにコピーし、スレーブはマスターのCAメッセージを確認します。最初のCAプロセスはロックステップであるため、スレーブが以前に受信したものと同じシーケンス番号を受信しない場合、スレーブの以前のCAメッセージの情報は暗黙的に確認されます。各CAFSMに関連付けられている個別のCAシーケンス番号スペースがあることに注意してください。
Whenever it is necessary to (re)start cache alignment and the CAFSM enters the Master/Slave Negotiation state, the CA Sequence Number should be set to a value not previously seen by the DCS. One possible scheme is to use the machine's time of day counter.
キャッシュアラインメントを（再）開始する必要があり、CAFSMがマスター/スレーブネゴシエーション状態に入るときはいつでも、CAシーケンス番号は、DCSで以前には見られなかった値に設定する必要があります。 1つの可能なスキームは、マシンの時刻カウンターを使用することです。
Mandatory Common Part The mandatory common part is described in detail in Section B.2.0.1. There are two fields in the mandatory common part whose codings are specific to a given message type. These fields are the "Number of Records" field and the "Flags" field.
必須の共通部分必須の共通部分については、セクションB.2.0.1で詳しく説明します。必須の共通部分には2つのフィールドがあり、そのコーディングは特定のメッセージタイプに固有です。これらのフィールドは、「レコード数」フィールドと「フラグ」フィールドです。
Number of Records The Number of Records field of the mandatory common part for the CA message gives the number of CSAS Records appended to the CA message mandatory part.
レコード数CAメッセージの必須の共通部分のレコード数フィールドは、CAメッセージの必須部分に追加されたCSASレコードの数を示します。
Flags The Flags field of the mandatory common part for the CA message has the following format:
フラグCAメッセージの必須の共通部分のフラグフィールドの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|I|O| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M This bit is part of the negotiation process for the cache alignment. When this bit is set then the sender of the CA message is indicating that it wishes to lead the alignment process. This bit is the "Master/Slave bit".
Mこのビットは、キャッシュアライメントのネゴシエーションプロセスの一部です。このビットが設定されている場合、CAメッセージの送信者は、調整プロセスを主導したいことを示しています。このビットは「マスター/スレーブビット」です。
I When set, this bit indicates that the sender of the CA message believes that it is in a state where it is negotiating for the status of master or slave. This bit is the "Initialization bit".
I設定されている場合、このビットは、CAメッセージの送信者が、マスターまたはスレーブのステータスをネゴシエートしている状態にあるとCAメッセージが信じていることを示します。このビットは「初期化ビット」です。
O This bit indicates that the sender of the CA message has more CSAS records to send. This implies that the cache alignment process must continue. This bit is the "mOre bit" despite its dubious name.
Oこのビットは、CAメッセージの送信者に送信するCSASレコードがまだあることを示します。これは、キャッシュアライメントプロセスを続行する必要があることを意味します。このビットは、その疑わしい名前にもかかわらず、「mOreビット」です。
All other fields of the mandatory common part are coded as described in Section B.2.0.1.
必須の共通部分の他のすべてのフィールドは、セクションB.2.0.1で説明されているようにコーディングされます。
CSAS record The CA message appends CSAS records to the end of its mandatory part. These CSAS records are NOT embedded in CSA records. See Section B.2.0.2 for details on CSAS records.
CSASレコードCAメッセージは、必須部分の最後にCSASレコードを追加します。これらのCSASレコードはCSAレコードに埋め込まれていません。 CSASレコードの詳細については、セクションB.2.0.2を参照してください。
The Cache State Update Request (CSU Request) message is used to update the state of cache entries in servers which are directly connected to the server sending the message. A CSU Request message is sent from one server (the LS) to directly connected server (the DCS) when the LS observes changes in the state of one or more cache entries. An LS observes such a change in state by either receiving a CSU request which causes an update to the LS's database or by observing a change of state of a cached entry originated by the LS. The change in state of a cache entry is noted in a CSU message by appending a "Cache State Advertisement" (CSA) record to the end of the mandatory part of the CSU Request as shown below.
キャッシュ状態更新要求（CSU要求）メッセージは、メッセージを送信するサーバーに直接接続されているサーバーのキャッシュエントリの状態を更新するために使用されます。 LSが1つ以上のキャッシュエントリの状態の変化を観察すると、CSU要求メッセージが1つのサーバー（LS）から直接接続されたサーバー（DCS）に送信されます。 LSは、LSのデータベースを更新するCSU要求を受信するか、LSが発信したキャッシュされたエントリの状態の変化を観察することによって、このような状態の変化を観察します。キャッシュエントリの状態の変化は、以下に示すように、CSU要求の必須部分の最後に「キャッシュ状態アドバタイズ」（CSA）レコードを追加することにより、CSUメッセージに示されます。
The CSU Request message type code is 2. The CSU Request message mandatory part format is as follows:
CSU要求メッセージのタイプコードは2です。CSU要求メッセージの必須部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mandatory Common Part The mandatory common part is described in detail in Section B.2.0.1. There are two fields in the mandatory common part whose codings are specific to a given message type. These fields are the "Number of Records" field and the "Flags" field.
必須の共通部分必須の共通部分については、セクションB.2.0.1で詳しく説明します。必須の共通部分には2つのフィールドがあり、そのコーディングは特定のメッセージタイプに固有です。これらのフィールドは、「レコード数」フィールドと「フラグ」フィールドです。
Number of Records The Number of Records field of the mandatory common part for the CSU Request message gives the number of CSA Records appended to the CSU Request message mandatory part.
レコード数CSU要求メッセージの必須の共通部分のレコード数フィールドは、CSU要求メッセージの必須部分に追加されるCSAレコードの数を示します。
Flags Currently, there are no flags defined for the Flags field of the mandatory common part for the CSU Request message.
フラグ現在、CSU要求メッセージの必須の共通部分のフラグフィールドに定義されているフラグはありません。
All other fields of the mandatory common part are coded as described in Section B.2.0.1.
必須の共通部分の他のすべてのフィールドは、セクションB.2.0.1で説明されているようにコーディングされます。
CSA Record See Section B.2.2.1.
CSAレコードB.2.2.1項を参照してください。
CSA records contain the information necessary to relate the current state of a cache entry in an SG to the servers being synchronized. CSA records contain a CSAS Record header and a client/server protocol specific part. The CSAS Record includes enough information for SCSP to look into the client/server database for the appropriate database cache entry and then compare the "newness" of the summary against the "newness" of the cached entry. If the information contained in the CSA is more new than the cached entry of the receiving server then the cached entry is updated accordingly with the contents of the CSA Record. The client/server protocol specific part of the CSA Record is documented separately for each such protocol. Examples of the protocol specific parts for NHRP and ATMARP are shown in [8] and [9] respectively.
CSAレコードには、SGのキャッシュエントリの現在の状態を同期対象のサーバーに関連付けるために必要な情報が含まれています。 CSAレコードには、CSASレコードヘッダーとクライアント/サーバープロトコル固有の部分が含まれています。 CSASレコードには、SCSPがクライアント/サーバーデータベースを調べて適切なデータベースキャッシュエントリを探し、要約の「新しさ」とキャッシュされたエントリの「新しさ」を比較するのに十分な情報が含まれています。 CSAに含まれる情報が受信サーバーのキャッシュされたエントリよりも新しい場合、キャッシュされたエントリはCSAレコードの内容に応じて更新されます。 CSAレコードのクライアント/サーバープロトコル固有の部分は、そのようなプロトコルごとに個別に文書化されています。 NHRPおよびATMARPのプロトコル固有の部分の例は、それぞれ[8]および[9]に示されています。
The amount of information carried by a specific CSA record may exceed the size of a link layer PDU. Hence, such CSA records MUST be fragmented across a number of CSU Request messages. The method by which this is done, is client/server protocol specific and is documented in the appropriate protocol specific document.
特定のCSAレコードによって運ばれる情報の量は、リンク層PDUのサイズを超える場合があります。したがって、そのようなCSAレコードは、多数のCSU要求メッセージにわたってフラグメント化する必要があります。これを行う方法は、クライアント/サーバープロトコル固有であり、適切なプロトコル固有のドキュメントに記載されています。
The content of a CSA record is as follows:
CSAレコードの内容は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client/Server Protocol Specific Part for cache entry ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CSAS Record See Section B.2.0.2 for rules and format for filling out a CSAS Record when it is "embedded" in a CSA Record.
CSASレコードCSAレコードに「埋め込まれている」場合のCSASレコードの記入に関する規則と形式については、セクションB.2.0.2を参照してください。
Client/Server Protocol Specific Part for cache entry This field contains the fields which are specific to the protocol specific portion of SCSP processing. The particular set of fields are defined in separate documents for each protocol user of SCSP. The Protocol ID, which identifies which protocol is using SCSP in the given packet, is located in the mandatory part of the message.
キャッシュエントリのクライアント/サーバープロトコル固有の部分このフィールドには、SCSP処理のプロトコル固有の部分に固有のフィールドが含まれます。特定のフィールドセットは、SCSPのプロトコルユーザーごとに個別のドキュメントで定義されています。特定のパケットでSCSPを使用しているプロトコルを識別するプロトコルIDは、メッセージの必須部分にあります。
The Cache State Update Reply (CSU Reply) message is sent from a DCS to an LS to acknowledge one or more CSA records which were received in a CSU Request. Reception of a CSA record in a CSU Request is acknowledged by including a CSAS record in the CSU Reply which corresponds to the CSA record being acknowledged. The CSU Reply message is the same in format as the CSU Request message except for the following: the type code is 3, only CSAS Records (rather than CSA records) are returned, and only those CSAS Records for which CSA Records are being acknowledged are returned. This implies that a given LS sending a CSU Request may not receive an acknowledgment in a single CSU Reply for all the CSA Records included in the CSU Request.
キャッシュ状態更新応答（CSU応答）メッセージがDCSからLSに送信され、CSU要求で受信された1つ以上のCSAレコードを確認します。 CSU要求でのCSAレコードの受信は、確認されているCSAレコードに対応するCSAS応答にCSASレコードを含めることで確認されます。 CSU応答メッセージの形式はCSU要求メッセージと同じですが、次の点が異なります。タイプコードが3であり、CSAレコードではなくCSASレコードのみが返され、CSAレコードが確認されているCSASレコードのみが返されます。戻ってきた。これは、CSU要求を送信する特定のLSが、CSU要求に含まれるすべてのCSAレコードに対する単一のCSU応答で確認応答を受信しない可能性があることを意味します。
This message allows one server (LS) to solicit the entirety of CSA record data stored in the cache of a directly connected server (DCS). The DCS responds with CSU Request messages containing the appropriate CSA records. The CSUS message type code is 4. The CSUS message format is the same as that of the CSU Reply message. CSUS messages solicit CSU Requests from only one server (the one identified by the Receiver ID in the Mandatory Part of the message).
このメッセージにより、1つのサーバー（LS）が、直接接続されたサーバー（DCS）のキャッシュに格納されているCSAレコードデータ全体を要求することができます。 DCSは、適切なCSAレコードを含むCSU要求メッセージで応答します。 CSUSメッセージタイプコードは4です。CSUSメッセージの形式は、CSU応答メッセージの形式と同じです。 CSUSメッセージは、1つのサーバー（メッセージの必須部分の受信者IDで識別されるサーバー）からのみCSU要求を要求します。
B.2.5 Hello:
B.2.5 こんにちは：
The Hello message is used to check connectivity between the sending server (the LS) and one of its directly connected neighbor servers (the DCSs). The Hello message type code is 5. The Hello message mandatory part format is as follows:
Helloメッセージは、送信側サーバー（LS）とその直接接続された隣接サーバーの1つ（DCS）の間の接続を確認するために使用されます。 Helloメッセージタイプコードは5です。Helloメッセージの必須部分の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | DeadFactor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Family ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Receiver ID Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Receiver ID Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval
The hello interval advertises the time between sending of
consecutive Hello Messages. If the LS does not receive a Hello
message from the DCS (which contains the LSID as a Receiver ID)
within the HelloInterval advertised by the DCS then the DCS's Hello
is considered to be late. Also, the LS MUST send its own Hello
message to a DCS within the HelloInterval which it advertised to
the DCS in the LS's previous Hello message to that DCS (otherwise
the DCS would consider the LS's Hello to be late).
DeadFactor This is a multiplier to the HelloInterval. If an LS does not receive a Hello message which contains the LS's LSID as a Receiver ID within the interval HelloInterval*DeadFactor from a given DCS, which advertised the HelloInterval and DeadFactor in a previous Hello message, then the LS MUST consider the DCS to be stalled; at this point, one of two things MUST happen: 1) if the LS has received any Hello messages from the DCS during this time then the LS transitions the corresponding HFSM to the Unidirectional State; otherwise, 2) the LS transitions the corresponding HFSM to the Waiting State.
DeadFactorこれは、HelloIntervalの乗数です。前のHelloメッセージでHelloIntervalとDeadFactorをアドバタイズした特定のDCSから、HelloInterval * DeadFactor間隔内にLSのLSIDをレシーバIDとして含むHelloメッセージをLSが受信しない場合、LSはDCSが失速;この時点で、次の2つのいずれかが発生する必要があります。1）LSがこの間にDCSからHelloメッセージを受信した場合、LSは対応するHFSMを単方向状態に移行します。それ以外の場合、2）LSは対応するHFSMを待機状態に移行します。
Family ID This is an opaque bit string which is used to refer to an aggregate of Protocol ID/SGID pairs. Only a single HFSM is run for all Protocol ID/SGID pairs assigned to a Family ID. Thus, there is a one to many mapping between the single HFSM and the CAFSMs corresponding to each of the Protocol ID/SGID pairs. This might have the net effect of substantially reducing HFSM maintenance traffic. See the protocol specific SCSP documents for further details.
ファミリーIDこれは、プロトコルID / SGIDペアの集約を参照するために使用される不透明なビット文字列です。ファミリーIDに割り当てられたすべてのプロトコルID / SGIDペアに対して実行されるHFSMは1つだけです。したがって、単一のHFSMとプロトコルID / SGIDペアのそれぞれに対応するCAFSMの間には、1対多のマッピングがあります。これにより、HFSMメンテナンストラフィックが大幅に削減されるという最終的な効果が得られる場合があります。詳細については、プロトコル固有のSCSPドキュメントを参照してください。
Mandatory Common Part The mandatory common part is described in detail in Section B.2.0.1. There are two fields in the mandatory common part whose codings are specific to a given message type. These fields are the "Number of Records" field and the "Flags" field.
必須の共通部分必須の共通部分については、セクションB.2.0.1で詳しく説明します。必須の共通部分には2つのフィールドがあり、そのコーディングは特定のメッセージタイプに固有です。これらのフィールドは、「レコード数」フィールドと「フラグ」フィールドです。
Number of Records The Number of Records field of the mandatory common part for the Hello message contains the number of "Additional Receiver ID" records which are included in the Hello. Additional Receiver ID records contain a length field and a Receiver ID field. Note that the count in "Number of Records" does NOT include the Receiver ID which is included in the Mandatory Common Part.
レコード数Helloメッセージの必須の共通部分のレコード数フィールドには、Helloに含まれる「追加の受信者ID」レコードの数が含まれています。追加の受信者IDレコードには、長さフィールドと受信者IDフィールドが含まれています。 「レコード数」のカウントには、必須の共通部分に含まれている受信者IDが含まれていないことに注意してください。
Flags Currently, there are no flags defined for the Flags field of the mandatory common part for the Hello message.
フラグ現在、Helloメッセージの必須の共通部分のFlagsフィールドに定義されているフラグはありません。
All other fields of the mandatory common part are coded as described in Section B.2.0.1.
必須の共通部分の他のすべてのフィールドは、セクションB.2.0.1で説明されているようにコーディングされます。
Additional Receiver ID Record This record contains a length field followed by a Receiver ID. Since it is conceivable that the length of a given Receiver ID may vary even within an SG, each additional Receiver ID heard (beyond the first one) will have both its length in bytes and value encoded in an "Additional Receiver ID Record". Receiver IDs are IDs of a DCS from which the LS has heard a recent Hello (i.e., within DeadFactor*HelloInterval as advertised by the DCS in a previous Hello message).
追加の受信者IDレコードこのレコードには、長さフィールドとそれに続く受信者IDが含まれています。特定のレシーバーIDの長さはSG内でも変化することが考えられるため、（最初のものを超えて）聞かれる各追加のレシーバーIDは、バイト単位の長さと「追加のレシーバーIDレコード」にエンコードされた値の両方を持ちます。レシーバーIDは、LSが最近のHelloを聞いたDCSのIDです（つまり、前のHelloメッセージでDCSによって通知されたDeadFactor * HelloInterval内）。
The format for this record is as follows:
このレコードのフォーマットは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rec ID Len | Receiver ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the LS has not heard from any DCS then the LS sets the Hello message fields as follows: Recvr ID Len is set to zero and no storage is allocated for the Receiver ID in the Common Mandatory Part, "Number of Records" is set to zero, and no storage is allocated for "Additional Receiver ID Records".
LSがどのDCSからも聞いていない場合、LSはHelloメッセージフィールドを次のように設定します。RecvrID Lenがゼロに設定され、共通必須部分のレシーバーIDにストレージが割り当てられていないため、「Number of Records」はゼロ。「追加の受信者IDレコード」にはストレージが割り当てられません。
If the LS has heard from exactly one DCS then the LS sets the Hello message fields as follows: the Receiver ID of the DCS which was heard and the length of that Receiver ID are encoded in the Common Mandatory Part, "Number of Records" is set to zero, and no storage is allocated for "Additional Receiver ID Records".
LSが正確に1つのDCSから聞いた場合、LSはHelloメッセージフィールドを次のように設定します。聞いたDCSの受信者IDとその受信者IDの長さは、共通の必須部分である「レコード数」でエンコードされます。ゼロに設定すると、「追加の受信者IDレコード」にストレージは割り当てられません。
If the LS has heard from two or more DCSs then the LS sets the Hello message fields as follows: the Receiver ID of the first DCS which was heard and the length of that Receiver ID are encoded in the Common Mandatory Part, "Number of Records" is set to the number of "Additional" DCSs heard, and for each additional DCS an "Additional Receiver ID Record" is formed and appended to the end of the Hello message.
LSが2つ以上のDCSから聞いた場合、LSはHelloメッセージフィールドを次のように設定します。最初に聞いたDCSの受信者IDとその受信者IDの長さは、共通の必須部分である「レコード数"は、「追加の」DCSの数に設定され、追加のDCSごとに「追加の受信者IDレコード」が形成され、Helloメッセージの末尾に追加されます。
The Extensions Part, if present, carries one or more extensions in {Type, Length, Value} triplets.
拡張部分が存在する場合、それは{Type、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The extension type code (see below).
タイプ拡張タイプコード（下記参照）。
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).
長さ値のオクテット単位の長さ（タイプフィールドと長さフィールドは含まれません。null拡張は、拡張ヘッダーと長さ0のみを持ちます）。
When extensions exist, the extensions part is terminated by the End of Extensions extension, having Type = 0 and Length = 0.
エクステンションが存在する場合、エクステンション部分はEnd of Extensionsエクステンションで終了し、Type = 0およびLength = 0になります。
Extensions may occur in any order but any particular extension type may occur only once in an SCSP packet. An LS MUST NOT change the order of extensions.
拡張は任意の順序で発生しますが、特定の拡張タイプはSCSPパケットで1回だけ発生します。 LSは拡張の順序を変更してはなりません。
Type = 0 Length = 0
タイプ= 0長さ= 0
When extensions exist, the extensions part is terminated by the End Of Extensions extension.
拡張が存在する場合、拡張部分はEnd Of Extensions拡張で終了します。
Type = 1 Length = variable
タイプ= 1長さ=変数
The SCSP Authentication Extension is carried in SCSP packets to convey the authentication information between an LS and a DCS in the same SG.
SCSP認証拡張はSCSPパケットで伝送され、同じSG内のLSとDCSの間で認証情報を伝達します。
Authentication is done pairwise on an LS to DCS basis; i.e., the authentication extension is generated at each LS. If a received packet fails the authentication test then an "abnormal event" has occurred. The packet is discarded and this event is logged.
認証は、LSからDCSに基づいてペアで行われます。つまり、認証拡張機能は各LSで生成されます。受信したパケットが認証テストに失敗した場合、「異常なイベント」が発生しています。パケットは破棄され、このイベントが記録されます。
The presence or absence of authentication is a local matter.
認証の有無はローカルな問題です。
The authentication header has 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. LS and DCS communicate either off-line using manual keying or online using a key management protocol to populate this table. The receiving SCSP entity always allocates the SPI and the parameters associated with it.
セキュリティパラメータインデックス（SPI）は、ハッシュアルゴリズムなどのキーとその他の情報を保持するテーブルへのインデックスと考えることができます。 LSとDCSは、手動でキーを使用してオフラインで通信するか、キー管理プロトコルを使用してオンラインで通信して、このテーブルにデータを入力します。受信側のSCSPエンティティは、常にSPIとそれに関連付けられているパラメーターを割り当てます。
The authentication data field contains the MAC (Message Authentication Code) calculated over the entire SCSP payload. The length of this field is dependent on the hash algorithm used to calculate the MAC.
認証データフィールドには、SCSPペイロード全体で計算されたMAC（メッセージ認証コード）が含まれています。このフィールドの長さは、MACの計算に使用されるハッシュアルゴリズムによって異なります。
The default hash algorithm to be supported is HMAC-MD5-128 [11]. HMAC is safer than normal keyed hashes. Other hash algorithms MAY be supported by def.
サポートされるデフォルトのハッシュアルゴリズムはHMAC-MD5-128 [11]です。 HMACは、通常のキー付きハッシュよりも安全です。他のハッシュアルゴリズムは、defによってサポートされる場合があります。
IANA will assign the numbers to identify the algorithm being used as described in Section C.
IANAは、セクションCで説明されているように、使用されているアルゴリズムを識別するために番号を割り当てます。
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, DCS ID>- 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 (DCS ID being the same).
SPIは、手動で、またはインターネットキー管理プロトコルを使用してネゴシエートできます。手動キーイングをサポートする必要があります。以下のパラメーターは、タプル<SPI、DCS ID>-ライフタイム、アルゴリズム、キーに関連付けられています。ライフタイムは、キーが有効である期間を秒単位で示します。手動キーイングの場合、この期間は無限になる可能性があります。また、手動キーイングをより適切にサポートするために、同時にアクティブな複数のタプルが存在する場合があります（DCS IDは同じです）。
Any Internet standard key management protocol MAY be used to negotiate the SPI and parameters.
SPIとパラメータのネゴシエーションには、インターネット標準の鍵管理プロトコルを使用できます（MAY）。
At the time of adding the authentication extension header, LS looks up in a table to fetch the SPI and the security parameters based on the DCS ID. If there are no entries in the table and if there is support for key management, the LS initiates the key management protocol to fetch the necessary parameters. The LS then calculates the hash by zeroing authentication data field before calculating the MAC on the sending end. The result replaces in the zeroed authentication data field. If key management is not supported and authentication is mandatory, the packet is dropped and this information is logged.
認証拡張ヘッダーを追加するときに、LSはテーブルを検索して、DCS IDに基づいてSPIとセキュリティパラメーターをフェッチします。テーブルにエントリがなく、キー管理のサポートがある場合、LSはキー管理プロトコルを開始して、必要なパラメータをフェッチします。次に、LSは、送信側でMACを計算する前に、認証データフィールドをゼロ化してハッシュを計算します。結果は、ゼロ化された認証データフィールドで置き換えられます。キー管理がサポートされておらず、認証が必須である場合、パケットはドロップされ、この情報がログに記録されます。
When receiving traffic, an LS fetches the parameters based on the SPI and its ID. 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.
LSはトラフィックを受信すると、SPIとそのIDに基づいてパラメーターをフェッチします。認証データフィールドは、ハッシュを計算するためにゼロ設定する前に抽出されます。ペイロード全体のハッシュを計算し、ハッシュが一致しない場合は、「異常なイベント」が発生しています。
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.
システム全体のセキュリティは、適切に選択されたキーとアルゴリズムの正しい実装に依存するため、選択されたキーは強力であることが重要です。
SCSP has a peer to peer trust model. 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.
SCSPには、ピアツーピアの信頼モデルがあります。ネイバー間でキーをネゴシエートするには、インターネット標準のキー管理プロトコルを使用することをお勧めします。平文でキーを送信すると、他のネゴシエーション方法が使用されると、セキュリティが完全に損なわれます。
Data integrity covers the entire SCSP 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 SCSP servers are liable to both spoofing attacks, active attacks and passive attacks.
データの整合性は、SCSPペイロード全体をカバーします。これにより、メッセージが変更されておらず、ソースも認証されていることが保証されます。認証拡張機能が使用されていない場合、またはセキュリティが侵害されている場合、SCSPサーバーは、スプーフィング攻撃、アクティブ攻撃、パッシブ攻撃の両方に対して責任があります。
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. As integrity is calculated on an SCSP message and not on each record, there is an implied trust between all the servers in a domain. It is recommend to use the security extension between all the servers in a domain and not just a subset servers.
メッセージを暗号化するメカニズムはありません。メッセージの暗号化と復号化には、標準のレイヤー3機密性メカニズムが使用されると想定されています。整合性は各レコードではなくSCSPメッセージで計算されるため、ドメイン内のすべてのサーバー間に暗黙の信頼があります。サブセットサーバーだけでなく、ドメイン内のすべてのサーバー間でセキュリティ拡張機能を使用することをお勧めします。
Any SCSP server is susceptible to Denial of Service (DOS) attacks. A rouge host can inundate its neighboring SCSP server with SCSP packets. However, if the authentication option is used, SCSP databases will not become corrupted, as the bogus packets will be discarded when the authentication check fails.
すべてのSCSPサーバーは、サービス拒否（DOS）攻撃の影響を受けます。不正なホストは、SCSPパケットで隣接するSCSPサーバーを氾濫させる可能性があります。ただし、認証オプションが使用されている場合、認証チェックが失敗すると偽のパケットが破棄されるため、SCSPデータベースは破損しません。
Due to the pairwise authentication model of SCSP, the information received from any properly authenticated server is trusted and propagated throughout the server group. Consequently, if security of any SCSP server is compromised, the entire database becomes vulnerable to curruption originating from the compromised server.
SCSPのペアワイズ認証モデルにより、適切に認証されたサーバーから受信した情報は信頼され、サーバーグループ全体に伝播されます。その結果、SCSPサーバーのセキュリティが危険にさらされると、データベース全体が危険にさらされたサーバーに起因する破損に対して脆弱になります。
Type = 2 Length = variable
タイプ= 2長さ=変数
The SCSP Vendor-Private Extension is carried in SCSP packets to convey vendor-private information between an LS and a DCS in the same SG and is thus of limited use. If a finer granularity (e.g., CSA record level) is desired then then given client/server protocol specific SCSP document MUST define such a mechanism. Obviously, however, such a protocol specific mechanism might look exactly like this extension. The Vendor Private Extension MAY NOT appear more than once in an SCSP packet for a given Vendor ID value.
SCSP Vendor-Private ExtensionはSCSPパケットで伝送され、同じSG内のLSとDCSの間でベンダープライベート情報を伝達するため、用途が限られています。より細かい粒度（CSAレコードレベルなど）が必要な場合は、指定されたクライアント/サーバープロトコル固有のSCSPドキュメントでそのようなメカニズムを定義する必要があります。ただし、明らかに、このようなプロトコル固有のメカニズムは、この拡張機能とまったく同じように見える場合があります。ベンダープライベート拡張は、特定のベンダーID値のSCSPパケットに複数回出現することはできません。
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.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID 802 Vendor ID as assigned by the IEEE [7].
ベンダーID 802 IEEE [7]によって割り当てられたベンダーID。
Data The remaining octets after the Vendor ID in the payload are vendor-dependent data.
データペイロードのベンダーIDに続く残りのオクテットはベンダー依存のデータです。
If the receiver does not handle this extension, or does not match the Vendor ID in the extension then the extension may be completely ignored by the receiver.
受信者がこの拡張機能を処理しない場合、または拡張機能のベンダーIDと一致しない場合、拡張機能は受信者によって完全に無視される可能性があります。
C. IANA Considerations
C. IANAに関する考慮事項
Any and all requests for value assignment from the various number spaces described in this document require proper documentation. Possible forms of documentation include, but are not limited to, RFCs or the product of another cooperative standards body (e.g., the MPOA and LANE subworking group of the ATM Forum). Other requests may also be accepted, under the advice of a "designated expert". (Contact the IANA for the contact information of the current expert.)
このドキュメントで説明されているさまざまな番号スペースからの値の割り当てのすべてのリクエストには、適切なドキュメントが必要です。可能なドキュメントの形式には、RFCまたは他の共同標準化団体の製品（ATMフォーラムのMPOAおよびLANEサブワーキンググループなど）が含まれますが、これらに限定されません。 「指定された専門家」の助言の下で、他の要求も受け入れることができます。 （現在の専門家の連絡先情報については、IANAに連絡してください。）
References
参考文献
[1] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", Laubach, RFC 2225, April 1998.
[1] Laubach、M。、およびJ. Halpern、「Classical IP and ARP over ATM」、Laubach、RFC 2225、1998年4月。
[2] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[2] Luciani、J.、Katz、D.、Piscitello、D.、Cole、B。、およびN. Doraswamy、「NMBA Next Hop Resolution Protocol（NHRP）」、RFC 2332、1998年4月。
[3] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[3] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[4] "P-NNI V1", Dykeman, Goguen, 1996.
[4] 「P-NNI V1」、ダイクマン、ゴーゲン、1996。
[5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[5] アーミテージ、G。、「UNI 3.0 / 3.1ベースのATMネットワーク上のマルチキャストのサポート」、RFC 2022、1996年11月。
[6] Keene, "LAN Emulation over ATM Version 2 - LNNI specification", btd-lane-lnni-02.08
[6] Keene、「ATMバージョン2上のLANエミュレーション-LNNI仕様」、btd-lane-lnni-02.08
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[7] Reynolds、J.、およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[8] Luciani, J., "A Distributed NHRP Service Using SCSP", RFC 2335, April 1998.
[8] Luciani、J。、「SCSPを使用した分散NHRPサービス」、RFC 2335、1998年4月。
[9] Luciani, J., "A Distributed ATMARP Service Using SCSP", Work In Progress.
[9] Luciani、J。、「SCSPを使用した分散型ATMARPサービス」、作業中。
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[11] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed Hashing for Message Authentication」、RFC 2104、1997年2月。
Acknowledgments
謝辞
This memo is a distillation of issues raised during private discussions, on the IP-ATM mailing list, and during the Dallas IETF (12/95). Thanks to all who have contributed but particular thanks to following people (in no particular order): Barbara Fox of Harris and Jeffries; Colin Verrilli of IBM; Raj Nair, and Matthew Doar of Ascom Nexion; Andy Malis of Cascade; Andre Fredette of Bay Networks; James Watt of Newbridge; and Carl Marcinik of Fore.
このメモは、プライベートディスカッション、IP-ATMメーリングリスト、およびダラスIETF（12/95）で発生した問題の要約です。貢献してくれたすべての人に感謝しますが、特に順不同で以下の人々に感謝します。ハリスとジェフリーズのバーバラフォックス。 IBMのColin Verrilli。 Raj Nair、およびAscom NexionのMatthew Doar。カスケードのアンディ・マリス。ベイネットワークスのアンドレフレデット。ニューブリッジのジェームズ・ワット。フォアのカール・マルシニック。
Authors' Addresses
著者のアドレス
James V. Luciani Bay Networks, Inc. 3 Federal Street, BL3-03 Billerica, MA 01821
James V. Luciani Bay Networks、Inc. 3 Federal Street、BL3-03 Billerica、MA 01821
Phone: +1-978-916-4734
EMail: luciani@baynetworks.com
Grenville Armitage Bell Labs Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733
Grenville Armitage Bell Labs Lucent Technologies 101 Crawfords Corner Road Holmdel、NJ 07733
Phone: +1 201 829 2635
EMail: gja@lucent.com
Joel M. Halpern Newbridge Networks Corp. 593 Herndon Parkway Herndon, VA 22070-5241
Joel M. Halpern Newbridge Networks Corp. 593 Herndon Parkway Herndon、VA 22070-5241
Phone: +1-703-708-5954
EMail: jhalpern@Newbridge.COM
Naganand Doraswamy Bay Networks, Inc. 3 Federal St, BL3-03 Billerice, MA 01821
Naganand Doraswamy Bay Networks、Inc. 3 Federal St、BL3-03 Billerice、MA 01821
Phone: +1-978-916-1323
EMail: naganand@baynetworks.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。