RFC2334 日本語訳
2334 Server Cache Synchronization Protocol (SCSP). J. Luciani, G.Armitage, J. Halpern, N. Doraswamy. April 1998. (Format: TXT=98161 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
Lucianiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2334年のベイネットワークスカテゴリ: 標準化過程G.アーミテージBellcore J.アルペルンNewbridge N.Doraswamyベイネットワークス1998年4月
Server Cache Synchronization Protocol (SCSP)
サーバキャッシュ同期プロトコル(SCSP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document describes the 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.
このドキュメントは、Server Cache Synchronizationプロトコル(SCSP)について説明して、Non Broadcast Multiple Access(NBMA)ネットワークの中にSCSPの使用で書かれています。 いくらかまっすぐな前進の用法はBMAネットワークに適切です。 SCSPは、分配されたプロトコル実体のための一般化されたキャッシュキャッシュ同期/模写問題を解決するのを試みます。 本書ではSCSPがいくつかの手段でServer Group(SG)に縛られるその分配されたサーバ実体でどのようにクライアント/サーバパラダイムで堆積しても、役立たれているクライアントの状態の情報を含むそれらのキャッシュのコンテンツ(または、それの部分)を同期させることを願ってください。
1. Introduction
1. 序論
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [10].
キーワードが解釈しなければならない、本書では現れるとき、[10]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
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
どんなプロトコルもそれ自体をクライアント/サーバパラダイムにおけるただ一つのサーバを持つことなどの1ポイントの失敗に制限しないのは、恐らく明白な目的です。 そこで同等余分なサーバがあると
Luciani, et. al. Standards Track [Page 1] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[1ページ]。
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.
このドキュメントはServer Cache Synchronizationプロトコル(SCSP)について説明します。 SCSPは上で説明された問題を扱っている間、一般化されたサーバ同期/キャッシュ模写問題を解決します。 SCSPはいくつかの手段で1セットの特定のプロトコルのServer Groupに制限されたサーバ実体(SG)のキャッシュ(または、キャッシュの部分)を同期させます。(Logical IP Subnet(LIS)[1])に属す例えばすべてのNHRPサーバ。 特定のサーバが使用するクライアント/サーバプロトコルはProtocol ID(PID)によって特定されます。 SGsは当然ながらSGIDと呼ばれるIDによって特定されます。 したがって、組み合わせPID/SGIDがSGのサーバが同期しているクライアント/サーバプロトコルとそのプロトコルのインスタンスの両方を特定することに注意してください。 これは同じプロトコルの複数のインスタンスで同時に、稼働中であり、互いの如何にかかわらずそれらのサーバを同期させるかもしれないのを含意します。 情報がSG LISのNBMAマッピングに登録されたクライアントのIPを含んでいるIPを使用することでNHRP[2]の同期しなければならない情報のタイプに関する例を見られることができます。
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[3]のHello、Database Synchronization、およびFlooding Proceduresについて言及するべきです。
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.
後述のように、プロトコルは三相に直面しています。 1番目、非常に簡潔なフェーズがそうである、こんにちは、2台のデバイスが、彼らが互いに話すことができることを決定するところで位相を合わせます。 それに続くのは、データベース同期です。 SCSPの操作は、2つの実体には新情報が受信されているときのポイントまで、利用可能な同じデータがあると仮定します。 データベース同期フェーズはこれを確実にします。
Luciani, et. al. Standards Track [Page 2] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[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.)
その後に、実体は、氾濫州に入って、残っています。 氾濫状態では、学習されるどんな新情報もすべての隣人に送ります、情報が学習されたもの(もしあれば)を除いて。 システムのすべての新情報がこれによってすべてのノードに伝播されます、その結果、状態を回復します。皆は同じことを知っています。 各リンクで確かに氾濫するので、低率パケット損失のどんなパターンも分裂を引き起こさないでしょう。 (明らかに、全体の隣人関係はパケット損失の十分高い速度で下りるでしょうが、リンクが働いていないなら、それは1つが必要とするものです。)
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プロトコルSpecific仕様の使用にそれを結びつけなければなりません。 別々のドキュメントでそのような仕様をするでしょう。 例えば、[8][9]。
2. Overview
2. 概要
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]からキャッシュ分配メカニズムを借ります。 しかしながら、義務的なShortest Path First(SPF)計算は全くそれらの技術と異なっていません、そして、SCSPは同期技術にかかわらず存在するキャッシュされた情報を保存するのに必要であるそれを超えてどんな追加メモリ要件も課しません。
Luciani, et. al. Standards Track [Page 3] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[3ページ]。
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).
以下の議論のために基準系を与えるために、用語のLocal Server(LS)、Directly Connected Server(DCS)、およびRemote Server(RS)を導入します。 LSは精査中のサーバです。 SCSPプロトコルについて議論するとき、すなわちすべての声明がLSの見解から出されます。 DCSは直接LSに接続されるサーバです。 例えば、LSの間のVCとDCSは存在しています。 したがって、接続する他のあらゆるサーバの観点からそれまであらゆるサーバが直接DCSです、そして、あらゆるサーバがゼロを持っているLSであるか、より多くのDCSsが直接それに接続しました。 LSの見解から、RSはサーバです、LSからLSまで別々です(いつもすなわち、RSがLSから遠くの2つ以上のホップですが、DCSは遠くでいつもLSからワンバウンドです)。(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は3つの潜水艦プロトコルを含んでいます: 「こんにちは」というプロトコル、「キャッシュ整列」プロトコル、および「キャッシュ州のアップデート」プロトコル。 「こんにちは」というプロトコルは、LSとDCSとの接続がDCSが操作上的であるかどうかと、双方向的であるか、単方向、または非機能的であるかを確かめるのに使用されます。 「キャッシュ整列」(カリフォルニア)プロトコルで、LSはDCSsのキャッシュのものと全体のキャッシュを同期させることができます。 「キャッシュ州のアップデート」(CSU)プロトコルは、与えられたSGのためにサーバにおけるキャッシュエントリーの状態をアップデートするのに使用されます。 セクション2.1、2.2、および2.3 それらが使用するHello、カリフォルニアの、より徹底的な説明、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のベースの同期はプロトコルインスタンス基礎あたりのaに実行されます。 すなわち、SCSPの別々のインスタンスは与えられた箱へ駆け込む与えられたプロトコルの各インスタンスのための走行です。 プロトコルはProtocol ID経由でSCSPで特定されます、そして、プロトコルのインスタンスはServer Group ID(SGID)によって特定されます。 したがって、PID/SGID組は唯一SCSPのインスタンスを特定します。 一般に、めったに与えられたプロトコル(どれが分配されているか、そして、必要性は同期をキャッシュする)の多くのインスタンスが同じ物理的な箱の中に稼働しているのが、事実でないので、これは問題ではありません。 しかしながら、これがそうであるときに、実質費用でコントロールでメインテナンストラフィックのかなりの減少をほとんど可能にしないFamily ID(Helloプロトコルで簡潔に説明される)と呼ばれるメカニズムがあります。 SCSPを使用している与えられたプロトコルに適切であるときに、Family IDメカニズムの使用は与えられたSCSPプロトコルで特定の状態で完全に定義された仕様になるでしょう。
Luciani, et. al. Standards Track [Page 4] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[4ページ]。
+---------------+
| |
+------->| DOWN |<-------+
| | | |
| +---------------+ |
| | ^ |
| | | |
| | | |
| | | |
| @ | |
| +---------------+ |
| | | |
| | WAITING | |
| +--| |--+ |
| | +---------------+ | |
| | ^ ^ | |
| | | | | |
| @ | | @ |
+---------------+ +---------------+
| BIDIRECTIONAL |---->| UNIDIRECTIONAL|
| | | |
| CONNECTION |<----| CONNECTION |
+---------------+ +---------------+
+---------------+ | | +------->| 下に| <、-、-、-、-、-、--+ | | | | | +---------------+ | | | ^ | | | | | | | | | | | | | | @ | | | +---------------+ | | | | | | | 待ち| | | +--| |--+ | | | +---------------+ | | | | ^ ^ | | | | | | | | | @ | | @ | +---------------+ +---------------+ | 双方向|、-、-、--、>| 単方向| | | | | | 接続| <、-、-、--、| 接続| +---------------+ +---------------+
Figure 1: Hello Finite State Machine (HFSM)
図1: こんにちは、有限州は機械加工します。(HFSM)
2.1 Hello Protocol
2.1に、こんにちは、プロトコル
"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.
「こんにちは」というメッセージは、LSとDCSとの接続がDCSが操作上的であるかどうかと、双方向的であるか、単方向、または非機能的であるかを確かめるのに使用されます。 これをするために、あらゆるLS MUSTが定期的にHelloメッセージをDCSsに送ります。
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がSCSPを実行する目的のためのダイレクト接続がいたがっているSGの同輩サーバのアドレスを表すNBMAアドレスのリストでLSを構成しなければなりません。 すなわち、これらのアドレスはひとりよがりのDCSsのアドレスです。 これらの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にはそれぞれのDCSsに関連しているHello Finite州Machine(HFSM)が与えられたSGのためにあります、そして、(図1を見ます)HFSMはサーバの間の接続性の状態をモニターします。
Luciani, et. al. Standards Track [Page 5] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[5ページ]。
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.
NBMAの平らな接続性が確立された後に、HFSMは「待ち」州への“Down"州と変遷で始まります。 Waiting州では、一度、LSがDCSへのメッセージをHelloに送り始めます。 Helloメッセージは: 以下で説明されるLSが最近Helloメッセージ(以下で説明されるように)を聞いたDCSs、HelloInterval、およびDeadFactorを特定するLSのID(LSID)に設定されるSender ID、ゼロまたは、より多くのReceiver ID。 ここに、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がDCSsの1つからHelloメッセージを受け取るとき、LSはLSIDがそれがただ受け取ったそのメッセージのReceiver ID分野の1つにあるかを確認するためにチェックします、そして、LSがそのHelloメッセージからSender IDを保存します。 LSIDがReceiverの1つにあるなら、IDはその時Bidirectional ConnectionへのHFSMが述べるLS変遷をさばきます、そうでなければ、それが移行します。Unidirectional Connection状態へのHFSM。 保存されたSender IDはDCSのID(DCSID)です。 LSがそれ自身のHelloメッセージをDCSに送る次回以前何らかのポイントでは、LSはLSの自己のHelloメッセージを送るときLSが使用するReceiver IDのリストに対して保存しているDCSIDをチェックするでしょう。 DCSIDがReceiver 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.
こんにちは、また、メッセージはHelloIntervalとDeadFactorを含んでいます。 「現在」のHelloメッセージを送るサーバで連続したHelloメッセージを発信させるとき、Hello間隔は時間(秒の)の広告を出します。 すなわち、DCSからのHelloメッセージのレセプションの間の時間がそのDCSによって広告に掲載されたHelloIntervalを超えているなら、次のHelloメッセージは遅くLSによって考えられることです。 LSがその時間隔HelloInterval*DeadFactor秒(DeadFactorが前のHelloメッセージのDCSによって広告に掲載されたところ)以内にHelloメッセージ(Receiver ID分野の1つにLSのLSIDを含んでいる)を受け取らないなら、LS MUSTは、DCSが失速すると考えます。 2つのものの1つがどのポイントでそうするかは起こります: 1) 最後のHelloInterval*DeadFactor秒の間、何かHelloメッセージを受け取っているならLSが移行するはずである、Unidirectional Connection州へのそのDCSのためのHFSM。 そして、さもなければ、LSが移行するはずである、Waiting州へのそのDCSのためのHFSM、Receiver IDリストからDCSIDを取り外してください。
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基礎あたりのaにあることに注意してください。 このようにして、例えば、NBMAアドレスXに関連している2つのサーバ(SG Aの1つとSG Bのもう片方)とNBMAアドレスYに関連している別の2つのサーバ(SG Aの1つともSG Bのもう片方)があって、NBMAアドレスの間には、適当な二地点間VCがあれば、VC(1PID/SGIDあたり1つ)の各側面で動く2HFSMsがあります。
Luciani, et. al. Standards Track [Page 6] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[6ページ]。
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.
こんにちは、メッセージは、マルチポイント接続にポイントを利用するために単一のReceiver IDの代わりにReceiver IDのリストを含んでいます。 ある間、1DCSあたり1HFSM、LS MUSTはポイントの葉としてマルチポイント接続に愛着しているDCSsにただ一つのHelloメッセージだけを送ります。 LSは、LSのものが次のHelloメッセージを送るときReceiver IDのリストにDCSIDsを含んでいることによって、これをします。 LSがHelloメッセージを聞いた非失速しているDCSsからのDCSIDsだけが含まれています。
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メッセージを受け取ることなどの異常などんな出来事もWaiting州への変遷にHFSMを引き起こします。 しかしながら、NBMAの接続性の損失はDown州への変遷にHFSMを引き起こします。 Helloメッセージ以外の何か適切に形成されたSCSPメッセージが受信されているなら、Bidirectional Connection州にはHFSMがあるまで、それらのメッセージを無視しなければなりません(これがケースのために例えば接続がかかわった多点へのポイントがあるところにあります)。
Luciani, et. al. Standards Track [Page 7] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[7ページ]。
+------------+
| |
+--->| DOWN |
| | |
| +------------+
| |
^ |
| @
| +------------+
| |Master/Slave|
|-<--| |<---+
| |Negotiation | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Cache | |
|-<--| |-->-|
| | Summarize | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Update | |
|-<--| |-->-|
| | Cache | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | | |
+-<--| Aligned |-->-+
| |
+------------+
+------------+ | | +--->| 下に| | | | | +------------+ | | ^ | | @ | +------------+ | |マスター/奴隷| |、-、<、--、| | <、-、--+ | |交渉| | | +------------+ | | | | ^ | ^ | @ | | +------------+ | | | キャッシュ| | |、-、<、--、| |、--、>、-、|、|、| まとめます。| | | +------------+ | | | | ^ | ^ | @ | | +------------+ | | | アップデート| | |、-、<、--、| |、--、>、-、|、|、| キャッシュ| | | +------------+ | | | | ^ | ^ | @ | | +------------+ | | | | | +-<--| 並べられます。| -->。+ | | +------------+
Figure 2: Cache Alignment Finite State Machine
図2: 整列有限状態機械をキャッシュしてください。
2.2 Cache Alignment Protocol
2.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).
「キャッシュAlignment」(カリフォルニア)メッセージは、それぞれのDCSsのキャッシュのものとキャッシュを同期させるのにLSによって使用されます。 すなわち、カリフォルニアメッセージで、穂ばらみLSはそれぞれのDCSsに連動できます。 カリフォルニアメッセージがゼロがあとに続いたカリフォルニアヘッダーを含んでいるか、または、より多くのCache州Advertisement Summaryが(CSAS記録)を記録します。
Luciani, et. al. Standards Track [Page 8] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[8ページ]。
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には、Cache Alignment Finiteの州のMachineの(CAFSM)1PID/SGIDあたりのaのそれぞれのDCSsに関連している(図2を見る)基礎があります、そして、CAFSMはサーバの間のキャッシュ整列の状態をモニターします。 CAFSMはDown州で始まります。 CAFSMはHFSMに関連しています、そして、そのHFSMがBidirectional州に達すると、CAFSMはMaster/奴隷Negotiation州に移行します。 Master/奴隷Negotiation州は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がMaster/奴隷Negotiation州に達すると、LSはCAFSMに関連しているDCSにカリフォルニアメッセージを送るでしょう。 カリフォルニアメッセージの形式はセクションB.2.1で説明されます。 LSが送る最初のカリフォルニアメッセージはCSAS記録がなく、Sender ID分野にLSIDを保管しているカリフォルニアヘッダー、Receiver ID分野のDCSID、カリフォルニア一連番号、および3ビットを含んでいます。 これらの3ビットは、M(マスター/奴隷)ビットと、I(マスターの初期設定)ビットと、O(より多くの)ビットです。 LSによって特定のDCSに送られた最初のカリフォルニアメッセージでは、M、O、およびIビットは1つに設定されます。 LSがCAReXmtInterval秒にDCSからカリフォルニアメッセージを受け取らないなら、それはただ送ったカリフォルニアメッセージを再送します。 LSは、CAFSMがCache Summarize州に移行するか、またはHFSMがBidirectional州から移行するまでこれをし続けています。 いつでも、HFSMはBidirectional州、Down州へのCAFSM変遷から移行します。
2.2.1 Master Slave Negotiation State
2.2.1 マスター奴隷交渉状態
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:
Master/奴隷Negotiation州では、LSが交換で果たす役割が以下のパケット処理によりますが、LSがDCSからカリフォルニアメッセージを受け取るとき:
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からのカリフォルニアがそうしたならM、私、およびOビットが1つにセットして、カリフォルニアメッセージにはCSAS記録が全くなくて、DCSのカリフォルニアメッセージの指定されるとしてのSender 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
a) CAReXmtIntervalの下側まで数えられるタイマが止められる、b) そのDCSに対応するCAFSMはCache Summarize州に移行します、そして、LSは奴隷c)の役割を引き受けます。 LSはそれがそれ自身のカリフォルニア一連番号d)としてカリフォルニアメッセージで受けたカリフォルニア一連番号を採用します。 LSは以下の通りformatedされるDCSにカリフォルニアメッセージを送ります: MとIビットはゼロに設定されます、そして、Sender ID分野はLSIDに設定されます、そして、Receiver ID分野はDCSIDに設定されます、そして、カリフォルニア一連番号はDCSのカリフォルニアメッセージに現れたカリフォルニア一連番号に設定されます。 送られるCSAS記録があって(すなわち、LSのキャッシュが空でないなら)、それらが皆、このカリフォルニアメッセージに収まらないなら、Oビットは設定されます。
Luciani, et. al. Standards Track [Page 9] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[9ページ]。
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.
1とCSAS記録の始発はカリフォルニアメッセージに含まれています。 さもなければ、Oビットはゼロに設定されます、そして、どれかCSAS Recordsが、送られる必要があるなら、それらの記録はカリフォルニアメッセージで含められています。
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からのカリフォルニアメッセージにはMがあって、私にオフであるビットとSender IDがあるなら、指定されるように、DCSのカリフォルニアメッセージは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はCache Summarize州に移行します、そして、LSはマスターc)の役割を引き受けます。 LSは受信されたカリフォルニアメッセージを処理しなければなりません。 . d)の下でカリフォルニアのメッセージ処理に関する説明をします。 LSは以下の通りformatedされるDCSにカリフォルニアメッセージを送ります: Mビットが1つに設定されて、Iビットがゼロに設定されて、Sender ID分野がLSIDに設定されて、Receiver ID分野がDCSIDに設定されて、LSの現在のカリフォルニア一連番号は、1つ増加されて、カリフォルニアメッセージに置かれます。 何かLSからDCSに送られるCSAS記録があれば(すなわち、LSのキャッシュが空でないなら)、Oビットは1つに設定されます、そして、初期のセットのCSAS記録はLSがDCSに発信するというカリフォルニアメッセージで含められています。
3) Otherwise, the packet must be ignored.
3) さもなければ、パケットを無視しなければなりません。
2.2.2 The Cache Summarize State
2.2.2 キャッシュは状態をまとめます。
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つの傑出しているカリフォルニアメッセージに最も攻撃してください。 LSのCAFSMがいったんCache Summarize州に移行すると、カリフォルニアメッセージの交換の系列は以下の通り起こります:
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ビットでカリフォルニアメッセージを受け取るか(例えばMビットはDCSのカリフォルニアに設定されます、そして、LSはマスターです)、またはIビットが設定されるなら、CAFSM変遷はMaster/奴隷にNegotiation州を支持します。
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の現在のカリフォルニア一連番号よりそれほど1であるカリフォルニア一連番号でカリフォルニアメッセージを受け取るなら、メッセージは写しです、そして、メッセージを捨てなければなりません。
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の現在のカリフォルニア一連番号と等しいカリフォルニア一連番号でカリフォルニアメッセージを受け取るなら、カリフォルニアメッセージを処理しなければなりません。 「カリフォルニアのメッセージ処理」に関する説明を以下にします。 DCSからカリフォルニアメッセージを受け取ったことの結果、以下は起こるでしょう:
Luciani, et. al. Standards Track [Page 10] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[10ページ]。
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必須の過程いずれもCSASはメッセージc)を容認されたカリフォルニアに記録します。 LSのカリフォルニア一連番号を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記録が全くあって、受信されたカリフォルニアメッセージがOビットを休みにするなら、CAFSMはUpdate Cache州に移行します。 2) LSには送らないそれ以上のCSAS記録が全くあって、受信されたカリフォルニアメッセージにLSがCSAS記録を全く含まないカリフォルニアメッセージ(新しいカリフォルニア一連番号がある)を返送するその時、Oビットがオフな状態でOビットがあるなら。 CAReXmtIntervalの下側まで数えられるタイマをリセットしてください。 3) LSに送るより多くのCSAS記録があるなら、LSはLSの次のセットのCSAS記録がある次のカリフォルニアメッセージを送ります。 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の現在のカリフォルニア一連番号と等しいカリフォルニア一連番号でカリフォルニアメッセージを受け取るなら、カリフォルニアメッセージは写しです、そして、LS MUSTはそれがちょうど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の現在のカリフォルニア一連番号よりさらに1であるカリフォルニア一連番号でカリフォルニアメッセージを受け取るなら、メッセージを有効であり、処理しなければなりません。 「カリフォルニアのメッセージ処理」に関する説明を以下にします。 DCSからカリフォルニアメッセージを受け取ったことの結果、以下は起こるでしょう:
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必須の過程いずれもCSASはメッセージb)を容認されたカリフォルニアに記録します。 カリフォルニアのカリフォルニア一連番号へのLSのカリフォルニア一連番号のセットは. 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) Oビットがオフな状態でLSがちょうどカリフォルニアメッセージを送って、受信されたカリフォルニアメッセージがOビットを休みにするなら、CAFSMはUpdate Cache州に移行します、そして、CSAS記録なしでOビットがオフな状態でLSはカリフォルニアメッセージを送ります。 2) LSに送るCSAS記録がまだあるなら、CSAS記録がそれにある状態で、LS MUSTはカリフォルニアメッセージを送ります。
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
a) LSからDCSに送られるメッセージがLSが、発信する必要があるという最後のCSAS記録を含んでいないなら、Oビットが. b)にある状態で、カリフォルニアメッセージを送ります。 LSからDCSに送られるメッセージがLSが、必要があるという最後のCSAS記録を含んでいるなら
Luciani, et. al. Standards Track [Page 11] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[11ページ]。
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.
発信して、DCSからただ受け取られたカリフォルニアメッセージがOビットを休みにし、次に、カリフォルニアメッセージは下に噛み付かれたO、およびLS変遷によるCAFSMをUpdate Cache州に送る、c) LSからDCSに送られるメッセージがLSが、発信する必要があって、DCSからただ受け取られたカリフォルニアメッセージがOビットをオンに持っていたという最後のCSAS記録を含んでいるなら、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のカリフォルニアより同輩ともうひとつカリフォルニア一連番号でカリフォルニアメッセージを受け取るなら、誤りは発生しました、そして、CAFSMはMaster/奴隷Negotiation州に移行します。
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.
Update Cache状態へのCAFSMがそれが送った最後のカリフォルニアメッセージのコピーであることを保たなければならない移行のLSとLS SHOULDがLSがカリフォルニアの過程の間、奴隷であったならCAReXmtIntervalと等しいタイマを設定することに注意してください。 タイマが期限が切れるか、またはLSがDCSからCSU Solicit(CSUS)メッセージ(CSUSメッセージはセクション2.2.3で説明される)を受け取るなら、LSはカリフォルニアメッセージのコピーをリリースします。 この理由はDCS(マスターである)がLSによって送られた最後のカリフォルニアメッセージを失うと最後のカリフォルニアSequence番号が使用されている状態でDCSが前のカリフォルニアメッセージを再送するということです。 それが起こるなら、LSは、また、最後に送られたカリフォルニアメッセージを再送する必要があるでしょうに。
2.2.2.1 "CA message processing":
2.2.2.1 「カリフォルニアのメッセージ処理」:
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.
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.
2.2.3 The Update Cache State
2.2.3 The Update Cache State
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.
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.
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
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
Luciani, et. al. Standards Track [Page 12] RFC 2334 SCSP April 1998
Luciani, et. al. Standards Track [Page 12] RFC 2334 SCSP April 1998
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.
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.
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.
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.
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.
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.
2.2.4 The Aligned State
2.2.4 The Aligned State
While in the Aligned state, an LS will perform the Cache State Update Protocol as described in Section 2.3.
While in the Aligned state, an LS will perform the Cache State Update Protocol as described in Section 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.
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.
2.3 Cache State Update Protocol
2.3 Cache State Update Protocol
"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
"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
Luciani, et. al. Standards Track [Page 13] RFC 2334 SCSP April 1998
Luciani, et. al. Standards Track [Page 13] RFC 2334 SCSP April 1998
only when the corresponding CAFSM is in either the Aligned State or the Update Cache State.
only when the corresponding CAFSM is in either the Aligned State or the Update Cache State.
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.
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.
Examples of such changes in state are as follows:
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) 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.
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.
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.
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.
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.
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
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
Luciani, et. al. Standards Track [Page 14] RFC 2334 SCSP April 1998
Luciani, et. al. Standards Track [Page 14] RFC 2334 SCSP April 1998
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.
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.
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.
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.
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.
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.
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.
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.
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) 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.
Luciani, et. al. Standards Track [Page 15] RFC 2334 SCSP April 1998
Luciani, et. al. Standards Track [Page 15] RFC 2334 SCSP April 1998
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) 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
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) 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.
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.
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.
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.
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.
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
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
Luciani, et. al. Standards Track [Page 16] RFC 2334 SCSP April 1998
Luciani, et. al. Standards Track [Page 16] RFC 2334 SCSP April 1998
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.
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.
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.
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.
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.
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.
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
メッシュがその完全なメッシュにCSU Requestを送って、送付サーバがCSU RequestのCSA Recordsを送るマルチポイント接続へのポイントの完全なメッシュ、およびそのあるサーバに1セットのサーバがあるならそれに注意してください、すべての0xFFs Receiver ID、そして、ソースそれら自身のCSU Requestに、CSA Recordsを適切にあふれさせるようにそれらのCSA Recordsをメッシュに含んで、それがメッシュで他のあらゆるサーバに必要であるというわけではないでしょう。 メッシュのあらゆるサーバが、CSU Requestを聞いて、適宜含まれているCSA Recordsを処理したでしょう、したがって、これはそうです。 したがって、完全なメッシュのサーバは、単一の論理的なポートであるメッシュとそうが「LSがDCSからCSA記録を受け取るとき、そのLSはそれが受け取られたDCS以外のあらゆるDCSへCSA Recordをあふれること」が壊れていないという定規であると考えるかもしれません。 完全なメッシュの受信サーバは、まだReceiver ID分野としてCSU Requestを送ったサーバのSender IDとIDとして返答サーバのLSIDを含むCSU ReplyメッセージがあるCSA記録を承認する必要があるでしょう。 と対照的に、タイムアウト、特有へのセットがCSA Recordを承認しなかったDCSIDであったならケース、CSU RequestのReceiver IDを再送してください、(すべての0xFFs Receiver ID、) 完全なメッシュが完全なメッシュに取り付けられたサーバのために電波媒体をエミュレートするので、放送媒体におけるSCSPの使用はまた、このテクニックを使用するかもしれません。 完全なメッシュのこの使用のさらなる議論か電波媒体の使用がクライアント/サーバプロトコルに残されます。
Luciani, et. al. Standards Track [Page 17] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[17ページ]。
specific documents.
特定のドキュメント。
2.4 The meaning of "More Up To Date"/"Newness"
2.4 「より最新」/「新しさ」の意味
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 Recordは、記録に含まれた情報が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のキャッシュエントリーに保管されていた情報より「日付」次第である情報を含むかどうか決定する際に使用される情報のスリーピースがあります: 1) Cache Key、2) Originator ID(OID)、およびCSA Sequenceが達する3によって)説明されるOriginator。 これらのフィールドの詳しい情報に関してセクション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:
これらのスリーピースの情報を考えて、CSASが記録する、(それがCSA Recordの一部であったかスタンドアロンである、)、以下のすべてが本当であるなら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 RecordのCache KeyはLSのキャッシュエントリー、2で)保存されたCache Keyに合っています。 CSAS RecordのOIDはLSのキャッシュエントリー、3で)保存されたOIDに合っています。 LSのキャッシュエントリーでは、CSAS RecordのCSA Sequence NumberがCSA Sequence Numberよりすばらしいです。
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はジェネリック氾濫プロトコルを定義します。 多くの関連する問題が以上がクライアント/サーバプロトコルで適切に特定のドキュメントを定義したということであるキャッシュメインテナンスとトポロジーメインテナンスに比例しています。 例えば、与えられたプロトコルのためにジェネリックキャッシュエントリータイムアウトメカニズムを定義するか、またはサーバの間の隣接番組情報の広告を出すのが、1つがSGのサーバのトポ地図を入手できるくらい望ましいかもしれません。 これらのようなメカニズムが望ましいときに、それらはクライアント/サーバのプロトコルの特定のドキュメントで定義されるでしょう。
Luciani, et. al. Standards Track [Page 18] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[18ページ]。
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.
カリフォルニアMessage--キャッシュAlignment Message Theseメッセージで、LSはDCSsの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--キャッシュAlignment Finite州Machine CAFSMはLSと特定のDCSの間のキャッシュ整列の状態をモニターします。 1LSから見られるDCSあたり1CAFSMが存在しています。
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 Record--キャッシュ州Advertisement Record A 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 Record--キャッシュ州Advertisement Summary Record A 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 Message--キャッシュ州UpdateメッセージThisはLSがキャッシュエントリーの状態で変化を意識するようになるときLSからDCSsに送られたメッセージです。
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 Message--LSとDCSがカリフォルニアメッセージを交換した後にキャッシュ州Update Solicit Message ThisメッセージはLSによってDCSに送られます。 CSUSメッセージは全体のCSA記録(まさしくCSASに保持された概要情報と対照的に)のための懇願を表す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--直接、Connected Server DCSは直接LSに接続されるサーバです。 例えば、LSの間のVCとDCSは存在しています。 今期は、サーバと彼らの同期に関して話すとき、基準系を与えるのに用語の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--こんにちは、Finite州Machine An LSはそれぞれのDCSsと共にa HFSM関連しているのに持っています。 HFSMはLSと特定のDCSの間の接続性の状態をモニターします。
Luciani, et. al. Standards Track [Page 19] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[19ページ]。
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--地方のServer 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--地方のServer 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 Thisがさばくプロトコルは与えられたメッセージに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--LSの見解からのリモートServer(RS)、RSはサーバです、LSからLSまで別々です(いつもすなわち、RSがLSから遠くの2つ以上のホップですが、DCSは遠くでいつもLSからワンバウンドです)。(LSは直接接続されません)。 別の方法で述べられない場合、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.
サーバGroup SCSPはいくつかの手段で1セットのSGに制限されたサーバ実体のキャッシュ(または、キャッシュの部分)を同期させます。SG--、(Logical IP Subnet(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--サーバGroup ID This IDは唯一、SGのサーバが同期しているインスタンスクライアント/サーバプロトコルを特定する16ビットの識別分野です。 これは同じプロトコルの複数のインスタンスで同時に、稼働中であり、互いの如何にかかわらずそれらのサーバを同期させるかもしれないのを含意します。
Luciani, et. al. Standards Track [Page 20] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[20ページ]。
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と共にカプセル化されたLLC/SNAPです、そして、OUIは0×00 00-5eとPID=0×00-05と等しいです。
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つの部品があります: 固定部分、義務的な部分、および拡大は離れています。 メッセージの固定部分は、あらゆるパケットに存在していて、以下で見せられます。 特定のメッセージタイプ(すなわち、カリフォルニア、CSU Request/回答、Hello、CSUS)に、義務的な部分は特定です、そして、それはそれのそれぞれが情報がSGの中で同期している特定のキャッシュエントリー(Helloメッセージに関するケースを除いた)の状態に適切な情報を含むMandatory Common Partとゼロか、より多くの記録を含んでいます(他のパケット要素の中で)。 拡大部分は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.
以下のメッセージ・フォーマットでは、「未使用」として示される分野を、そのようなメッセージの伝達のゼロに設定されて、そのようなメッセージを受け取り次第無視しなければなりません。
B.1 Fixed Part
部分が固定されたB.1
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
This is the version of the SCSP protocol being used. The current
version is 1.
バージョンThisは使用される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)).
タイプCode Thisはメッセージのためのコードがタイプするということです。(例えば、Hello(5)、CSU Request(2)、CSU Reply(3)(CSUS(4)、カリフォルニア(1)))。
Packet Size
The total length of the SCSP packet, in octets (excluding link
layer and/or other protocol encapsulation).
パケットSize、八重奏における、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チェックサム。 パケットが長さがバイトの奇数であるなら、この計算はまるでパケットの端まで0×00に設定された1バイトを追加するかのように実行されます。
Luciani, et. al. Standards Track [Page 21] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[21ページ]。
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.
どんな拡大もメッセージに存在していないとき、Of Extensions Thisがさばく始めはゼロとしてコード化されます。 拡大が存在していると、この分野は固定ヘッダーの先端から最初の拡大の始まりまでのオフセットでコード化されるでしょう。
B.2.0 Mandatory Part
B.2.0の義務的な部分
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 Cache州Update Request/回答など)への操作特殊情報を含みます、そして、それはそれのそれぞれが情報がSGの中で同期している特定のキャッシュエントリー(Helloメッセージに関するケースを除いた)の状態に適切な情報を含むMandatory Common Part(セクションB.2.0.1では、説明される)とゼロか、より多くの記録を含んでいます(他のパケット要素の中で)。 メッセージタイプに頼っていて、これらの記録は、Cache州Advertisement Summary(CSAS)記録(セクションB.2.0.2では、説明される)かCache州Advertisement(CSA)記録のどちらかであるかもしれません(セクションB.2.2.1では、説明されます)。 CSA Recordsは(すなわち、CSAS Record)と何らかの追加クライアント/サーバが特殊情報について議定書の中で述べるというキャッシュエントリーの情報の概要を含んでいます。 義務的な一般的な部分書式とCSAS Record書式はすぐに以下に示されます、SCSPメッセージにおける彼らの使用を示している前に、メッセージ記述の中で模写を防ぐために。
B.2.0.1 Mandatory Common Part
B.2.0.1の義務的な一般的な部分
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロトコルID| サーバグループID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 未使用| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者IDレン| Recvr IDレン| 記録の数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者ID(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機ID(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Luciani, et. al. Standards Track [Page 22] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[22ページ]。
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:
ID Thisがさばくプロトコルは与えられたメッセージにSCSPを利用しているクライアント/サーバプロトコルを特定する識別子を含んでいます。 この分野へのプロトコルIDの課題はセクションC.で説明されるようにIANAに明け渡されます。現在のドキュメントがあるプロトコルには、以下の定義された値があります:
1 - ATMARP
2 - NHRP
3 - MARS
4 - DHCP
5 - LNNI
1--ATMARP2--NHRP3--火星4--DHCP5--LNNI
Server Group ID
This ID is uniquely identifies the instance of a given
client/server protocol for which servers are being synchronized.
サーバGroup ID This IDは唯一そうです。サーバが同期している与えられたクライアント/サーバプロトコルのインスタンスを特定します。
Flags
The Flags field is message specific, and its use will be described
in the specific message format sections below.
Flagsがさばく旗はメッセージ特有です、そして、使用は下の特定のメッセージ・フォーマット部で説明されるでしょう。
Sender ID Len
This field holds the length in octets of the Sender ID.
IDレンThisがさばく送付者はSender IDの八重奏における長さを保持します。
Recvr ID Len
This field holds the length in octets of the Receiver ID.
レンThisがさばくRecvr IDはReceiver 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.
Records This分野の数は与えられたメッセージに関連している追加記録の数を含んでいます。 これらの記録の正確な形式は、メッセージに特定であり、下のセクションのそれぞれのメッセージタイプのために説明されるでしょう。
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 Thisは与えられたメッセージを送るサーバに割り当てられた識別子です。 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 Thisは与えられたメッセージを受け取ることであるサーバに割り当てられた識別子です。 1つの可能な課題が与えられたメッセージを受け取ることであるサーバのプロトコルアドレスであるかもしれません。
Luciani, et. al. Standards Track [Page 23] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[23ページ]。
B.2.0.2 Cache State Advertisement Summary Record (CSAS record)
B.2.0.2キャッシュ州の広告概要記録(CSAS記録)
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記録がServer Group ID(SGID)を含んでいなくて、またProtocol 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.
また、Hop Countの値とCSAS RecordのRecord Length分野がCSAS記録が「スタンドアロン」の記録として存在しているかどうか、またはCSAS記録がCSA Recordに「埋め込まれているかどうか」に依存していることに注意してください。 これは以下でさらに説明されます。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホップカウント| レコード長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要なレンをキャッシュしてください。| Orig IDレン|N| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CSA一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キーをキャッシュしてください… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 創始者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.
ホップCount This分野は下げられる前に記録が取るかもしれないホップの数を表します。 したがって、記録が横断する各サーバでは、Hop Countは減少します。 CSAS記録が「スタンドアロン」の記録(すなわち、それはCSA記録の中で埋め込まれていない)であるときに、概要がキャッシュ整列プロセスの間、ワンバウンドで越えられないので、この分野は1に設定されます。 CSAS記録が「埋め込まれる」なら、次に、Hop CountがあるというCSA記録の中では、1を引いたSGの基数はほぼ確実にそうである行政上定義された値によりセットしていました。 CSA Recordが懇願(すなわち、CSUSメッセージで送られたCSAS Recordに対応した)に対応して送られたCSU Requestの中で運ばれるとき、前の規則への例外が起こることに注意してください。 どのケース、Hop Count SHOULD、1に設定されてくださいか。
Luciani, et. al. Standards Track [Page 24] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[24ページ]。
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が記録する記録的なLength Ifは「スタンドアロン」の記録です、次に、この値はバイトで12+「キャッシュKey Leng」+「Orig IDレン」です。 さもなければ、この値は12+「キャッシュKey Leng」+「Orig IDレン」+sizeof(「キャッシュエントリーへのクライアント/サーバプロトコルSpecific Part」)に設定されます。 与えられたProtocol IDのためのクライアント/サーバのプロトコルの特定のドキュメントからClient/サーバプロトコルSpecific Partのサイズを得るかもしれません。
Cache Key Len
Length of the Cache Key field in bytes.
バイトで表現されるCache Key分野のKeyレンLengthをキャッシュしてください。
Orig ID Len.
Length of the Originator ID field in bytes.
Orig 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 Request/回答で含まれたCSAS Recordで使用されるだけです。 請求されたCSA Recordによって表されたキャッシュエントリーがもうLSのキャッシュで存在していないと(詳細に関してセクション2.3を見てください)LSがCSA記録のための懇願を受けるのは、可能です。 この場合、LSは直接CSUSメッセージをCSU RequestにCSAS Recordを回避します、そして、LSはNビットが、キャッシュエントリーがもう存在しないのを意味するように設定します。 それでも、もう存在しないCSA記録に請求したDCSはCSU Replyと共に応じるでしょう。 通常、このビットはゼロに設定されます。
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 Sequence Number This分野はまとめられるCSAの記録的なインスタンスの「新しさ」を特定する一連番号を含んでいます。 「より大きい」一連番号は、より最近の広告を意味します。 したがって、キャッシュエントリーの一部(すべて)の州が、アップデートする必要があるなら、新しい状態の広告を出すCSA記録は前の広告に対応するものより大きいCSA Sequence Numberを含まなければなりません。 この数はCSA記録の創始者によって割り当てられます。 CSA Sequence Numberは起因するサーバかクライアントによって割り当てられるかもしれません(サーバに存在に広告を出させました)。
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
CSA Sequence Numberは32ビットの署名している数です。 CSA Sequence Numberスペースの中では、No.-2^31(0×80000000)は予約されています。 したがって、No.-2^31+1(0×80000001)と2^31-1(0x7fffffff)の間には、与えられたCache KeyのためのCSA Sequence Numberスペースの使用可能な部分があります。 +1初めて作成したキャッシュエントリーにCSA Recordを溯源するとき、LSは-2^31を使用します。 その都度、キャッシュエントリーは何らかの方法で変更されます、そして、その変更が、SGの他のサーバに連動する必要があると、LSは交際したCSA Sequence番号を増加します。
Luciani, et. al. Standards Track [Page 25] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[25ページ]。
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.
アップデートの広告を出すとき、Cache Keyに与えて、その新しいCSA Sequence Numberを使用します。 かつて与えられたCSA Sequence Numberが2^31-2に達して、関連キャッシュエントリーが変更されたのが、事実であるのでSGのサーバの残りにアップデートを送らなければならないなら、LSは最初に他のサーバからキャッシュエントリーを取り除かせるCSA Recordを送ることによって、与えられたキャッシュエントリーからSGを追放しなければなりません、そして、このCSA Recordは2^31-1のCSA Sequence Numberを運びます。 キャッシュエントリーが掃除される正確なパケット・フォーマットとメカニズムは適切なプロトコル特定のドキュメントで定義されます。 次に、除いているCSA Recordが各DCSによって承認された後にLSが新しいCSA Recordにアップデートされた情報を運ばせて、この新しいCSA Recordが-2^のCSA Sequence Numberを運ぶ、31、+1
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 Recordは与えられたOIDとCache Keyに、SGの中でユニークなCSA Sequence Numberを含まなければなりません。 この数(プロトコル詳細ドキュメントに明らかにそれと反対に述べられない場合)を得るRECOMMENDEDメソッドが既存のキャッシュエントリーに関連しているCSA Sequence NumberへのCSA RecordにCSA Sequence Numberをはめ込むことである、(時代遅れのキャッシュエントリーが既に存在しているか、そして、ゼロ、そうでなければ)、そのうえ、aは定数を構成しました。 特定のドキュメントがそうするプロトコルが、キャッシュエントリーをアップデートする前に再開しているLSのOIDを含むすべてのキャッシュエントリーが掃除されるのを必要とすることに注意してください。 この場合、それでも、アップデートしているCSA Recordは以前に既存のキャッシュエントリーと構成された定数に関連しているCSA Sequence NumberにCSA Sequence Numberセットを含むでしょう。
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.
キャッシュKey Thisは与えられた「プロトコルID/サーバグループID」組のために、唯一、CSA Recordの創始者が同輩と同期させたがっている1つのデータを特定するデータベースルックアップキーです。 一般に、このキーはバイトSCSPがキャッシュにおける、与えられた片のデータに関連づける小さい不透明なストリングになるでしょう。 このようにして、例えば、創始者はATMアドレスのものがあるIPアドレスの製本に4バイトの特定のストリングを割り当てるかもしれません。 概して、CSA記録の起因するサーバはサーバが与えられたサーバが溯源して、同輩と同期させたがっているデータのあらゆる要素のためにSGでCache Keyを生成するのに原因となります。
Originator ID
This field contains an ID administratively assigned to the server
which is the originator of CSA Records.
Thisがさばく創始者IDは行政上CSA Recordsの創始者であるサーバに割り当てられたIDを含んでいます。
Luciani, et. al. Standards Track [Page 26] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[26ページ]。
B.2.1 Cache Alignment (CA)
B.2.1キャッシュ整列(カリフォルニア)
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:
Cache Alignment(カリフォルニア)メッセージで、LSはサーバグループの中でDCSsのキャッシュのものと全体のキャッシュを同期させることができます。 カリフォルニアメッセージタイプコードは1です。 カリフォルニアのメッセージの義務的な部分形式は以下の通りです:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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記録| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CSAS記録| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
キャッシュ整列プロセスの配列で支援するためにユニークな識別子を提供するカリフォルニアSequence Number A価値。 「より大きい」一連番号は、より最近のカリフォルニアメッセージを意味します。 奴隷サーバはいつもマスターサーバの前のカリフォルニアメッセージをそれが送る現在のカリフォルニアメッセージに一連番号を回避します、そして、奴隷はマスターのカリフォルニアメッセージを承認します。 初期のカリフォルニアプロセスが堅苦しいので、奴隷がそれが以前に受けたのと同じ一連番号を受けないなら、奴隷の前のカリフォルニアメッセージの情報はそれとなく承認されます。 各CAFSMに関連している別々のカリフォルニアのSequence Numberスペースがあることに注意してください。
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.
それが(re)スタートキャッシュ整列に必要であり、CAFSMがMaster/奴隷Negotiation状態に入るときはいつも、カリフォルニアSequence Numberは以前に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.
義務的な一般的な部分の義務的なCommon PartはセクションB.2.0.1で詳細に説明されます。 2つの分野が与えられたメッセージタイプに、コーディングが特定である義務的な一般的な部分にあります。 これらの分野は、「記録の数」分野と「旗」分野です。
Luciani, et. al. Standards Track [Page 27] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[27ページ]。
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.
RecordsのNumberがさばくカリフォルニアメッセージのための義務的な一般的な部分のRecordsの数はカリフォルニアのメッセージの義務的な部分に追加されたCSAS Recordsの数を与えます。
Flags
The Flags field of the mandatory common part for the CA message
has the following format:
Flagsがさばくカリフォルニアメッセージのための義務的な一般的な部分の旗は以下の形式を持っています:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|I|O| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|I|O| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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はキャッシュ整列のための交渉プロセスの一部です。 このビットがその時設定されるとき、カリフォルニアメッセージの送付者は、整列プロセスを導きたがっているのを示しています。 このビットは「マスター/奴隷ビット」です。
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 Whenはセットして、このビットは、カリフォルニアメッセージの送付者が、それがマスターか奴隷の状態を交渉している状態にいると信じているのを示します。 このビットは「初期設定ビット」です。
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.
○ このビットは、カリフォルニアメッセージの送付者には送るより多くの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記録を追加するというCSAS記録。 これらのCSAS記録はCSA記録に埋め込まれていません。 CSAS記録に関する詳細に関してセクションB.2.0.2を見てください。
B.2.2 Cache State Update Request (CSU Request)
B.2.2キャッシュ州の更新要求(CSU要求)
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
Cache州Update Request(CSU Request)メッセージは、メッセージを送りながら直接サーバに接続されるサーバにおけるキャッシュエントリーの状態をアップデートするのに使用されます。 LSが1つ以上のキャッシュの状態で変化を観測するとき、1つのサーバ(LS)から直接接続されたサーバ(DCS)にCSU Requestメッセージを送ります。
Luciani, et. al. Standards Track [Page 28] RFC 2334 SCSP April 1998
et Luciani、アル。 規格はSCSP1998年4月にRFC2334を追跡します[28ページ]。
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.
エントリー。 LSは、CSUを受けるのによる状態のそのような変化がLSのデータベースかキャッシュされたエントリーの状態の変化を観測するのによるアップデートがLSで溯源したどの原因を要求するかを観測します。 キャッシュエントリーの状態の変化は、CSUメッセージに以下に示すように「キャッシュ州の広告」(CSA)記録をCSU Requestの義務的な部分の端に追加することによって、述べられます。
The CSU Request message type code is 2. The CSU Request message mandatory part format is as follows:
CSU Requestメッセージタイプコードは2です。 CSU Requestのメッセージの義務的な部分形式は以下の通りです:
一覧
スポンサーリンク
