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
Network Working Group J. Luciani
Request for Comments: 2334 Bay Networks
Category: Standards Track G. Armitage
Bellcore
J. Halpern
Newbridge
N. Doraswamy
Bay Networks
April 1998
Server Cache Synchronization Protocol (SCSP)
服务器缓存同步协议（SCSP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. SCSP attempts to solve the generalized cache synchronization/cache-replication problem for distributed protocol entities. However, in this document, SCSP is couched in terms of the client/server paradigm in which distributed server entities, which are bound to a Server Group (SG) through some means, wish to synchronize the contents (or a portion thereof) of their caches which contain information about the state of clients being served.
本文档描述了服务器缓存同步协议（SCSP），并根据SCSP在非广播多址（NBMA）网络中的使用编写；尽管如此，有点直截了当的用法适用于BMA网络。SCSP试图解决分布式协议实体的通用缓存同步/缓存复制问题。然而，在本文档中，SCSP是根据客户机/服务器范例来表述的，在这种范例中，通过某种方式绑定到服务器组（SG）的分布式服务器实体希望同步其缓存的内容（或其中的一部分），其中包含有关正在服务的客户机状态的信息。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [10].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[10]中的说明进行解释。
It is perhaps an obvious goal for any protocol to not limit itself to a single point of failure such as having a single server in a client/server paradigm. Even when there are redundant servers, there
对于任何协议来说，不局限于单一故障点（例如在客户机/服务器模式中只有一台服务器）可能是一个明显的目标。即使有冗余服务器，也会有
still remains the problem of cache synchronization; i.e., when one server becomes aware of a change in state of cache information then that server must propagate the knowledge of the change in state to all servers which are actively mirroring that state information. Further, this must be done in a timely fashion without putting undue resource strains on the servers. Assuming that the state information kept in the server cache is the state of clients of the server, then in order to minimize the burden placed upon the client it is also highly desirable that clients need not have complete knowledge of all servers which they may use. However, any mechanism for synchronization should not preclude a client from having access to several (or all) servers. Of course, any solution must be reasonably scalable, capable of using some auto-configuration service, and lend itself to a wide range of authentication methodologies.
仍然存在缓存同步问题；i、 例如，当一台服务器意识到缓存信息的状态发生变化时，该服务器必须将状态变化的知识传播给所有积极镜像该状态信息的服务器。此外，这必须及时完成，而不会给服务器带来过度的资源紧张。假设保存在服务器缓存中的状态信息是服务器的客户端的状态，那么为了最大限度地减轻客户端的负担，还非常希望客户端不需要完全了解它们可能使用的所有服务器。但是，任何同步机制都不应阻止客户端访问多个（或所有）服务器。当然，任何解决方案都必须具有合理的可扩展性，能够使用一些自动配置服务，并适用于多种身份验证方法。
This document describes the Server Cache Synchronization Protocol (SCSP). SCSP solves the generalized server synchronization/cache-replication problem while addressing the issues described above. SCSP synchronizes caches (or a portion of the caches) of a set of server entities of a particular protocol which are bound to a Server Group (SG) through some means (e.g., all NHRP servers belonging to a Logical IP Subnet (LIS)[1]). The client/server protocol which a particular server uses is identified by a Protocol ID (PID). SGs are identified by an ID which, not surprisingly, is called a SGID. Note, therefore, that the combination PID/SGID identifies both the client/server protocol for which the servers of the SG are being synchronized as well as the instance of that protocol. This implies that multiple instances of the same protocol may be in operation at the same time and have their servers synchronized independently of each other. An example of types of information that must be synchronized can be seen in NHRP[2] using IP where the information includes the registered clients' IP to NBMA mappings in the SG LIS.
本文档介绍服务器缓存同步协议（SCSP）。SCSP解决了通用服务器同步/缓存复制问题，同时解决了上述问题。SCSP通过某种方式（例如，属于逻辑IP子网（LIS）[1]的所有NHRP服务器）同步绑定到服务器组（SG）的特定协议的一组服务器实体的缓存（或缓存的一部分）。特定服务器使用的客户机/服务器协议由协议ID（PID）标识。sg由一个ID标识，该ID被称为SGID，这并不奇怪。因此，请注意，PID/SGID组合标识SG的服务器正在同步的客户机/服务器协议以及该协议的实例。这意味着同一协议的多个实例可能同时运行，并且它们的服务器彼此独立地同步。使用IP的NHRP[2]中可以看到必须同步的信息类型的示例，其中信息包括SG LIS中注册客户端的IP到NBMA映射。
The simplest way to understand SCSP is to understand that the algorithm used here is quite similar to that used in OSPF[3]. In fact, if the reader wishes to understand more details of the tradeoffs and reliability aspects of SCSP, they should refer to the Hello, Database Synchronization, and Flooding Procedures in OSPF [3].
理解SCSP最简单的方法是理解此处使用的算法与OSPF中使用的算法非常相似[3]。事实上，如果读者希望了解SCSP的权衡和可靠性方面的更多细节，他们应该参考OSPF[3]中的Hello、数据库同步和泛洪过程。
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.
如后所述，该协议经历三个阶段。第一个非常简短的阶段是hello阶段，两台设备确定它们可以相互通话。接下来是数据库同步。SCSP的操作假定在收到新信息之前，两个实体具有相同的可用数据。数据库同步阶段确保了这一点。
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.
在数据库同步中，两个邻居交换有关其数据库中每个条目的摘要信息。使用摘要是因为数据库本身可能相当大。根据这些总结，邻居可以确定是否存在彼此需要的信息。如果是，则要求并提供。因此，在此操作阶段结束时，两个邻居的数据库中有相同的数据。
After that, the entities enter and remain in flooding state. In flooding state, any new information that is learned is sent to all neighbors, except the one (if any) that the information was learned from. This causes all new information in the system to propagate to all nodes, thus restoring the state that everyone knows the same thing. Flooding is done reliably on each link, so no pattern of low rate packet loss will cause a disruption. (Obviously, a sufficiently high rate of packet loss will cause the entire neighbor relationship to come down, but if the link does not work, then that is what one wants.)
之后，实体进入并保持泛洪状态。在泛洪状态下，学习到的任何新信息都会发送给所有邻居，但从中学习信息的邻居（如果有）除外。这会导致系统中的所有新信息传播到所有节点，从而恢复每个人都知道相同事情的状态。泛洪在每个链路上都是可靠的，因此低速率数据包丢失模式不会造成中断。（显然，足够高的数据包丢失率将导致整个邻居关系崩溃，但如果链路不工作，那么这就是我们想要的。）
Because the database synchronization procedure is run whenever a link comes up, the system robustly ensures that all participating nodes have all available information. It properly recovers from partitions, and copes with other failures.
由于数据库同步过程是在链接出现时运行的，因此系统将可靠地确保所有参与节点都具有所有可用信息。它正确地从分区恢复，并处理其他故障。
The SCSP specification is not useful as a stand alone protocol. It must be coupled with the use of an SCSP Protocol Specific specification which defines how a given protocol would make use of the synchronization primitives supplied by SCSP. Such specification will be done in separate documents; e.g., [8] [9].
SCSP规范作为独立协议没有用处。它必须与SCSP协议特定规范的使用相结合，该规范定义了给定协议如何利用SCSP提供的同步原语。此类规范将在单独的文件中完成；e、 g.，[8][9]。
SCSP places no topological requirements upon the SG. Obviously, however, the resultant graph must span the set of servers to be synchronized. SCSP borrows its cache distribution mechanism from the link state protocols [3,4]. However, unlike those technologies, there is no mandatory Shortest Path First (SPF) calculation, and SCSP imposes no additional memory requirements above and beyond that which is required to save the cached information which would exist regardless of the synchronization technology.
SCSP不对SG提出拓扑要求。然而，显然，结果图必须跨越要同步的服务器集。SCSP借用了链路状态协议的缓存分配机制[3,4]。但是，与这些技术不同的是，不存在强制的最短路径优先（SPF）计算，SCSP对内存的要求不超过保存缓存信息所需的内存要求，无论采用何种同步技术，缓存信息都会存在。
In order to give a frame of reference for the following discussion, the terms Local Server (LS), Directly Connected Server (DCS), and Remote Server (RS) are introduced. The LS is the server under scrutiny; i.e., all statements are made from the perspective of the LS when discussing the SCSP protocol. The DCS is a server which is directly connected to the LS; e.g., there exists a VC between the LS and DCS. Thus, every server is a DCS from the point of view of every other server which connects to it directly, and every server is an LS which has zero or more DCSs directly connected to it. From the perspective of an LS, an RS is a server, separate from the LS, which is not directly connected to the LS (i.e., an RS is always two or more hops away from an LS whereas a DCS is always one hop away from an LS).
为了给下面的讨论提供一个参考框架，引入了术语本地服务器（LS）、直接连接服务器（DCS）和远程服务器（RS）。LS是受监视的服务器；i、 例如，在讨论SCSP协议时，所有陈述都是从LS的角度进行的。DCS是直接连接到LS的服务器；e、 例如，LS和DCS之间存在VC。因此，从直接连接到它的每台其他服务器的角度来看，每台服务器都是一个DCS，并且每台服务器都是一个LS，它有零个或多个直接连接到它的DCS。从LS的角度来看，RS是一个独立于LS的服务器，它不直接连接到LS（即，RS总是离LS有两个或多个跃点，而DCS总是离LS有一个跃点）。
SCSP contains three sub protocols: the "Hello" protocol, the "Cache Alignment" protocol, and the "Cache State Update" protocol. The "Hello" protocol is used to ascertain whether a DCS is operational and whether the connection between the LS and DCS is bidirectional, unidirectional, or non-functional. The "Cache Alignment" (CA) protocol allows an LS to synchronize its entire cache with that of the cache of its DCSs. The "Cache State Update" (CSU) protocol is used to update the state of cache entries in servers for a given SG. Sections 2.1, 2.2, and 2.3 contain a more in-depth explanation of the Hello, CA, and CSU protocols and the messages they use.
SCSP包含三个子协议：“Hello”协议、“缓存对齐”协议和“缓存状态更新”协议。“Hello”协议用于确定DCS是否运行，以及LS和DCS之间的连接是否为双向、单向或非功能性连接。“缓存对齐”（CA）协议允许LS将其整个缓存与其DCS的缓存进行同步。“缓存状态更新”（CSU）协议用于更新给定SG服务器中缓存项的状态。第2.1、2.2和2.3节对Hello、CA和CSU协议及其使用的消息进行了更深入的解释。
SCSP based synchronization is performed on a per protocol instance basis. That is, a separate instance of SCSP is run for each instance of the given protocol running in a given box. The protocol is identified in SCSP via a Protocol ID and the instance of the protocol is identified by a Server Group ID (SGID). Thus the PID/SGID pair uniquely identify an instance of SCSP. In general, this is not an issue since it is seldom the case that many instances of a given protocol (which is distributed and needs cache synchronization) are running within the same physical box. However, when this is the case, there is a mechanism called the Family ID (described briefly in the Hello Protocol) which enables a substantial reduction in maintenance traffic at little real cost in terms of control. The use of the Family ID mechanism, when appropriate for a given protocol which is using SCSP, will be fully defined in the given SCSP protocol specific specification.
基于SCSP的同步在每个协议实例的基础上执行。也就是说，为在给定框中运行的给定协议的每个实例运行一个单独的SCSP实例。协议通过协议ID在SCSP中标识，协议实例通过服务器组ID（SGID）标识。因此，PID/SGID对唯一标识SCSP实例。一般来说，这不是一个问题，因为给定协议的许多实例（是分布式的，需要缓存同步）很少在同一个物理机箱中运行。然而，在这种情况下，有一种称为Family ID（在Hello协议中简要描述）的机制，它能够在控制方面以很少的实际成本大幅减少维护通信量。当适用于使用SCSP的给定协议时，将在给定SCSP协议特定规范中完全定义族ID机制的使用。
+---------------+
| |
+------->| DOWN |<-------+
| | | |
| +---------------+ |
| | ^ |
| | | |
| | | |
| | | |
| @ | |
| +---------------+ |
| | | |
| | WAITING | |
| +--| |--+ |
| | +---------------+ | |
| | ^ ^ | |
| | | | | |
| @ | | @ |
+---------------+ +---------------+
| BIDIRECTIONAL |---->| UNIDIRECTIONAL|
| | | |
| CONNECTION |<----| CONNECTION |
+---------------+ +---------------+
+---------------+
| |
+------->| DOWN |<-------+
| | | |
| +---------------+ |
| | ^ |
| | | |
| | | |
| | | |
| @ | |
| +---------------+ |
| | | |
| | WAITING | |
| +--| |--+ |
| | +---------------+ | |
| | ^ ^ | |
| | | | | |
| @ | | @ |
+---------------+ +---------------+
| BIDIRECTIONAL |---->| UNIDIRECTIONAL|
| | | |
| CONNECTION |<----| CONNECTION |
+---------------+ +---------------+
Figure 1: Hello Finite State Machine (HFSM)
图1:Hello有限状态机（HFSM）
"Hello" messages are used to ascertain whether a DCS is operational and whether the connections between the LS and DCS are bidirectional, unidirectional, or non-functional. In order to do this, every LS MUST periodically send a Hello message to its DCSs.
“Hello”消息用于确定DCS是否可运行，以及LS和DCS之间的连接是否为双向、单向或非功能性连接。为此，每个LS必须定期向其DCS发送Hello消息。
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必须配置一个NBMA地址列表，该列表表示SG中的对等服务器的地址，LS希望与之直接连接以运行SCSP；也就是说，这些地址是潜在DCS的地址。使用这些NBMA地址配置LS的机制超出了本文件的范围；尽管一种可能的机制是自动配置服务器。
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有一个Hello有限状态机（HFSM）与给定SG的每个DCS（见图1）关联，HFSM监控服务器之间的连接状态。
The HFSM starts in the "Down" State and transitions to the "Waiting" State after NBMA level connectivity has been established. Once in the Waiting State, the LS starts sending Hello messages to the DCS. The Hello message includes: a Sender ID which is set to the LS's ID (LSID), zero or more Receiver IDs which identify the DCSs from which the LS has recently heard a Hello message (as described below), and a HelloInterval and DeadFactor which will be described below. At this point, the DCS may or may not already be sending its own Hello messages to the LS.
HFSM在“关闭”状态下启动，并在建立NBMA级连接后过渡到“等待”状态。一旦处于等待状态，LS开始向DCS发送Hello消息。Hello消息包括：设置为LS的ID（LSID）的发送方ID、零个或多个接收方ID（标识LS最近从中听到Hello消息的dcs）（如下所述）以及HelloInterval和DeadFactor（如下所述）。此时，DCS可能正在或可能尚未向LS发送其自己的Hello消息。
When the LS receives a Hello message from one of its DCSs, the LS checks to see if its LSID is in one of the Receiver ID fields of that message which it just received, and the LS saves the Sender ID from that Hello message. If the LSID is in one of the Receiver ID fields then the LS transitions the HFSM to the Bidirectional Connection state otherwise it transitions the HFSM into the Unidirectional Connection state. The Sender ID which was saved is the DCS's ID (DCSID). At some point before the next time that the LS sends its own Hello message to the DCS, the LS will check the saved DCSID against a list of Receiver IDs which the LS uses when sending the LS's own Hello messages. If the DCSID is not found in the list of Receiver IDs then it is added to that list before the LS sends its Hello message.
当LS从其一个DCS接收到Hello消息时，LS检查其LSID是否位于其刚接收到的消息的一个接收方ID字段中，并且LS保存该Hello消息的发送方ID。如果LSID位于其中一个接收器ID字段中，则LS将HFSM转换为双向连接状态，否则将HFSM转换为单向连接状态。保存的发送方ID是DCS的ID（DCSID）。在LS下次向DCS发送自己的Hello消息之前的某个时间点，LS将根据LS发送自己的Hello消息时使用的接收器ID列表检查保存的DCSID。如果在接收方ID列表中找不到DCSID，则会在LS发送其Hello消息之前将其添加到该列表中。
Hello messages also contain a HelloInterval and a DeadFactor. The Hello interval advertises the time (in seconds) between sending of consecutive Hello messages by the server which is sending the "current" Hello message. That is, if the time between reception of Hello messages from a DCS exceeds the HelloInterval advertised by that DCS then the next Hello message is to be considered late by the LS. If the LS does not receive a Hello message, which contains the LS's LSID in one of the Receiver ID fields, within the interval HelloInterval*DeadFactor seconds (where DeadFactor was advertised by the DCS in a previous Hello message) then the LS MUST consider the DCS to be stalled. At which point one of two things will happen: 1) if any Hello messages have been received during the last HelloInterval*DeadFactor seconds then the LS should transition the HFSM for that DCS to the Unidirectional Connection State; otherwise, the LS should transition the HFSM for that DCS to the Waiting State and remove the DCSID from the Receiver ID list.
Hello消息还包含HelloInterval和DeadFactor。Hello interval播发发送“当前”Hello消息的服务器发送连续Hello消息之间的时间（秒）。也就是说，如果从DCS接收Hello消息的间隔时间超过该DCS播发的HelloInterval，则LS将认为下一条Hello消息延迟。如果LS没有接收到一个hello消息，该消息包含一个接收器ID字段中的LS的LSID，则在间隔HelLoopult*死区秒（DeadFactor在前一个hello消息中由DCS广告），然后LS必须考虑DCS停止。此时将发生两件事中的一件：1）如果在最后的HelloInterval*DeadFactor秒期间收到任何Hello消息，则LS应将该DCS的HFSM转换为单向连接状态；否则，LS应将该DCS的HFSM转换为等待状态，并从接收器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的。因此，例如，如果有两台服务器（一台在SG A中，另一台在SG B中）与NBMA地址X相关联，另外两台服务器（一台在SG A中，另一台在SG B中）与NBMA地址Y相关联，并且NBMA地址之间存在合适的点对点VC，则VC的每侧上运行两个hfsm（每个PID/SGID一个）。
Hello messages contain a list of Receiver IDs instead of a single Receiver ID in order to make use of point to multipoint connections. While there is an HFSM per DCS, an LS MUST send only a single Hello message to its DCSs attached as leaves of a point to multipoint connection. The LS does this by including DCSIDs in the list of Receiver IDs when the LS's sends its next Hello message. Only the DCSIDs from non-stalled DCSs from which the LS has heard a Hello message are included.
Hello消息包含接收器ID列表，而不是单个接收器ID，以便使用点对多点连接。虽然每个DCS都有HFSM，但LS必须仅向其作为点对多点连接的叶子连接的DCS发送一条Hello消息。LS通过在LS发送下一条Hello消息时将DCSID包括在接收方ID列表中来实现这一点。仅包括来自未停止的DCS的DCSID，LS已从中听到Hello消息。
Any abnormal event, such as receiving a malformed SCSP message, causes the HFSM to transition to the Waiting State; however, a loss of NBMA connectivity causes the HFSM to transition to the Down State. Until the HFSM is in the Bidirectional Connection State, if any properly formed SCSP messages other than Hello messages are received then those messages MUST be ignored (this is for the case where, for example, there is a point to multipoint connection involved).
任何异常事件（如接收到格式错误的SCSP消息）都会导致HFSM转换到等待状态；但是，失去NBMA连接会导致HFSM过渡到关闭状态。在HFSM处于双向连接状态之前，如果接收到除Hello消息以外的任何格式正确的SCSP消息，则必须忽略这些消息（例如，在涉及点对多点连接的情况下）。
+------------+
| |
+--->| DOWN |
| | |
| +------------+
| |
^ |
| @
| +------------+
| |Master/Slave|
|-<--| |<---+
| |Negotiation | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Cache | |
|-<--| |-->-|
| | Summarize | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Update | |
|-<--| |-->-|
| | Cache | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | | |
+-<--| Aligned |-->-+
| |
+------------+
+------------+
| |
+--->| DOWN |
| | |
| +------------+
| |
^ |
| @
| +------------+
| |Master/Slave|
|-<--| |<---+
| |Negotiation | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Cache | |
|-<--| |-->-|
| | Summarize | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Update | |
|-<--| |-->-|
| | Cache | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | | |
+-<--| Aligned |-->-+
| |
+------------+
Figure 2: Cache Alignment Finite State Machine
图2：缓存对齐有限状态机
"Cache Alignment" (CA) messages are used by an LS to synchronize its cache with that of the cache of each of its DCSs. That is, CA messages allow a booting LS to synchronize with each of its DCSs. A CA message contains a CA header followed by zero or more Cache State Advertisement Summary records (CSAS records).
LS使用“缓存对齐”（CA）消息将其缓存与其每个DCS的缓存同步。也就是说，CA消息允许引导LS与其每个DCS同步。CA消息包含一个CA头，后跟零个或多个缓存状态播发摘要记录（CSAS记录）。
An LS has a Cache Alignment Finite State Machine (CAFSM) associated (see Figure 2) with each of its DCSs on a per PID/SGID basis, and the CAFSM monitors the state of the cache alignment between the servers. The CAFSM starts in the Down State. The CAFSM is associated with an HFSM, and when that HFSM reaches the Bidirectional State, the CAFSM transitions to the Master/Slave Negotiation State. The Master/Slave Negotiation State causes either the LS or DCS to take on the role of master over the cache alignment process. In a sense, the master server sets the tempo for the cache alignment.
LS有一个缓存对齐有限状态机（CAFSM），它在每个PID/SGID的基础上与每个DCS关联（见图2），并且CAFSM监控服务器之间缓存对齐的状态。CAFSM在关闭状态下启动。CAFSM与HFSM关联，当HFSM达到双向状态时，CAFSM转换到主/从协商状态。主/从协商状态会导致LS或DCS在缓存对齐过程中扮演主的角色。从某种意义上说，主服务器设置缓存对齐的速度。
When the LS's CAFSM reaches the Master/Slave Negotiation State, the LS will send a CA message to the DCS associated with the CAFSM. The format of CA messages are described in Section B.2.1. The first CA message which the LS sends includes no CSAS records and a CA header which contains the LSID in the Sender ID field, the DCSID in the Receiver ID field, a CA sequence number, and three bits. These three bits are the M (Master/Slave) bit, the I (Initialization of master) bit, and the O (More) bit. In the first CA message sent by the LS to a particular DCS, the M, O, and I bits are set to one. If the LS does not receive a CA message from the DCS in CAReXmtInterval seconds then it resends the CA message it just sent. The LS continues to do this until the CAFSM transitions to the Cache Summarize State or until the HFSM transitions out of the Bidirectional State. Any time the HFSM transitions out of the Bidirectional State, the CAFSM transitions to the Down State.
当LS的CAFSM达到主/从协商状态时，LS将向与CAFSM相关联的DCS发送CA消息。CA消息的格式见第B.2.1节。LS发送的第一条CA消息不包括CSAS记录和CA头，CA头包含发送方ID字段中的LSID、接收方ID字段中的DCSID、CA序列号和三位。这三个位是M（主/从）位、I（主初始化）位和O（更多）位。在LS发送到特定DCS的第一条CA消息中，M、O和I位设置为1。如果LS在CAReXmtInterval秒内未收到来自DCS的CA消息，则会重新发送刚刚发送的CA消息。LS将继续执行此操作，直到CAFSM转换到缓存汇总状态或HFSM转换出双向状态。无论何时HFSM转换出双向状态，CAFSM都会转换到Down状态。
When the LS receives a CA message from the DCS while in the Master/Slave Negotiation State, the role the LS plays in the exchange depends on packet processing as follows:
当LS在主/从协商状态下从DCS接收到CA消息时，LS在交换中扮演的角色取决于数据包处理，如下所示：
1) If the CA from the DCS has the M, I, and O bits set to one and there are no CSAS records in the CA message and the Sender ID as specified in the DCS's CA message is larger than the LSID then
1) 如果来自DCS的CA将M、I和O位设置为1，并且CA消息中没有CSAS记录，并且DCS CA消息中指定的发送方ID大于LSID，则
a) The timer counting down the CAReXmtInterval is stopped. b) The CAFSM corresponding to that DCS transitions to the Cache Summarize State and the LS takes on the role of slave. c) The LS adopts the CA sequence number it received in the CA message as its own CA sequence number. d) The LS sends a CA message to the DCS which is formated as follows: the M and I bits are set to zero, the Sender ID field is set to the LSID, the Receiver ID field is set to the DCSID, and the CA sequence number is set to the CA sequence number that appeared in the DCS's CA message. If there are CSAS records to be sent (i.e., if the LS's cache is not empty), and if all of them will not fit into this CA message then the O bit is set to
a) 停止对CareXmtInServal进行倒计时的计时器。b） 与该DCS对应的CAFSM转换为缓存汇总状态，LS承担从机角色。c） LS采用其在CA消息中接收的CA序列号作为其自己的CA序列号。d） LS向DCS发送CA消息，其格式如下：M和I位设置为零，发送方ID字段设置为LSID，接收方ID字段设置为DCSID，CA序列号设置为DCS CA消息中出现的CA序列号。如果要发送CSAS记录（即，如果LS的缓存不是空的），并且如果所有这些记录都不适合此CA消息，则O位设置为
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.
CA消息中包括一个和初始CSAS记录集；否则，O位设置为零，如果需要发送任何CSAS记录，则这些记录将包含在CA消息中。
2) If the CA message from the DCS has the M and I bits off and the Sender ID as specified in the DCS's CA message is smaller than the LSID then
2) 如果来自DCS的CA消息的M和I位为off，且DCS CA消息中指定的发送方ID小于LSID，则
a) The timer counting down the CAReXmtInterval is stopped. b) The CAFSM corresponding to that DCS transitions to the Cache Summarize State and the LS takes on the role of master. c) The LS must process the received CA message. An explanation of CA message processing is given below. d) The LS sends a CA message to the DCS which is formated as follows: the M bit is set to one, I bit is set to zero, the Sender ID field is set to the LSID, the Receiver ID field is set to the DCSID, and the LS's current CA sequence number is incremented by one and placed in the CA message. If there are any CSAS records to be sent from the LS to the DCS (i.e., if the LS's cache is not empty) then the O bit is set to one and the initial set of CSAS records are included in the CA message that the LS is sending to the DCS.
a) 停止对CareXmtInServal进行倒计时的计时器。b） 与该DCS相对应的CAFSM转换为缓存汇总状态，LS承担主控角色。c） LS必须处理收到的CA消息。下面给出CA消息处理的说明。d） LS向DCS发送CA消息，其格式如下：M位设置为1，I位设置为0，发送方ID字段设置为LSID，接收方ID字段设置为DCSID，LS当前CA序列号递增1并放入CA消息中。如果有任何CSAS记录要从LS发送到DCS（即，如果LS的缓存不为空），则O位设置为1，初始CSAS记录集包含在LS发送到DCS的CA消息中。
3) Otherwise, the packet must be ignored.
3) 否则，必须忽略该数据包。
At any given time, the master or slave have at most one outstanding CA message. Once the LS's CAFSM has transitioned to the Cache Summarize State the sequence of exchanges of CA messages occurs as follows:
在任何给定时间，主服务器或从服务器最多有一条未完成的CA消息。一旦LS的CAFSM转换为缓存汇总状态，CA消息的交换顺序如下所示：
1) If the LS receives a CA message with the M bit set incorrectly (e.g., the M bit is set in the CA of the DCS and the LS is master) or if the I bit is set then the CAFSM transitions back to the Master/Slave Negotiation State.
1) 如果LS接收到错误设置了M位的CA消息（例如，DCS的CA中设置了M位，LS为主），或者如果设置了I位，则CAFSM转换回主/从协商状态。
2) If the LS is master and the LS receives a CA message with a CA sequence number which is one less than the LS's current CA sequence number then the message is a duplicate and the message MUST be discarded.
2) 如果LS为主机，且LS接收到CA序列号比LS当前CA序列号小一的CA消息，则该消息为重复消息，必须丢弃该消息。
3) If the LS is master and the LS receives a CA message with a CA sequence number which is equal to the LS's current CA sequence number then the CA message MUST be processed. An explanation of "CA message processing" is given below. As a result of having received the CA message from the DCS the following will occur:
3) 如果LS为主机，且LS接收到CA序列号等于LS当前CA序列号的CA消息，则必须处理CA消息。下文对“CA消息处理”进行了解释。由于从DCS接收到CA消息，将发生以下情况：
a) The timer counting down the CAReXmtInterval is stopped. b) The LS must process any CSAS records in the received CA message. c) Increment the LS's CA sequence number by one. d) The cache exchange continues as follows:
a) 停止对CareXmtInServal进行倒计时的计时器。b） LS必须处理接收到的CA消息中的任何CSAS记录。c） 将LS的CA序列号增加1。d） 缓存交换继续进行，如下所示：
1) If the LS has no more CSAS records to send and the received CA message has the O bit off then the CAFSM transitions to the Update Cache State. 2) If the LS has no more CSAS records to send and the received CA message has the O bit on then the LS sends back a CA message (with new CA sequence number) which contains no CSAS records and with the O bit off. Reset the timer counting down the CAReXmtInterval. 3) If the LS has more CSAS records to send then the LS sends the next CA message with the LS's next set of CSAS records. If LS is sending its last set of CSAS records then the O bit is set off otherwise the O bit is set on. Reset the timer counting down the CAReXmtInterval.
1) 如果LS没有更多的CSAS记录要发送，并且收到的CA消息的O位已关闭，则CAFSM将转换到更新缓存状态。2） 如果LS没有更多的CSAS记录要发送，并且接收到的CA消息的O位为on，则LS将发送回一条CA消息（具有新的CA序列号），该消息不包含CSAS记录，且O位为off。重置计时器，使CAReXmtInterval倒计时。3） 如果LS有更多的CSAS记录要发送，则LS将发送下一个CA消息以及LS的下一组CSAS记录。如果LS正在发送其最后一组CSAS记录，则O位设置为off，否则O位设置为on。重置计时器，使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接收到CA序列号等于LS当前CA序列号的CA消息，则CA消息是重复的，LS必须重新发送刚刚发送到DCS的CA消息。
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接收到CA序列号比LS当前CA序列号多一个的CA消息，则该消息有效，必须进行处理。下文对“CA消息处理”进行了解释。由于从DCS接收到CA消息，将发生以下情况：
a) The LS must process any CSAS records in the received CA message. b) Set the LS's CA sequence number to the CA sequence number in the CA message. c) The cache exchange continues as follows:
a) LS必须处理接收到的CA消息中的任何CSAS记录。b） 将LS的CA序列号设置为CA消息中的CA序列号。c） 缓存交换继续进行，如下所示：
1) If the LS had just sent a CA message with the O bit off and the received CA message has the O bit off then the CAFSM transitions to the Update Cache State and the LS sends a CA message with no CSAS records and with the O bit off. 2) If the LS still has CSAS records to send then the LS MUST send a CA message with CSAS records in it.
1) 如果LS刚刚发送了一条CA消息，且O位已关闭，而收到的CA消息的O位已关闭，则CAFSM将转换为更新缓存状态，LS发送一条没有CSAS记录且O位已关闭的CA消息。2） 如果LS仍有CSAS记录要发送，则LS必须发送包含CSAS记录的CA消息。
a) If the message being sent from the LS to the DCS does not contain the last CSAS records that the LS needs to send then the CA message is sent with the O bit on. b) If the message being sent from the LS to the DCS does contain the last CSAS records that the LS needs to
a) 如果从LS发送到DCS的消息不包含LS需要发送的最后一个CSAS记录，则发送CA消息时O位为on。b） 如果从LS发送到DCS的消息包含LS需要发送的最后一条CSAS记录
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接收的CA消息的O位关闭，然后CA消息在O位关闭的情况下发送，LS将CAFSM转换为更新缓存状态。c） 如果从LS发送到DCS的消息确实包含LS需要发送的最后一条CSAS记录，并且刚从DCS接收到的CA消息的O位为on，则发送CA消息时O位为off，对齐过程继续。
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接收到CA序列号既不等于当前LS的CA序列号也不大于当前LS的CA序列号的CA消息，则发生错误，CAFSM转换到主/从机协商状态。
Note that if the LS was slave during the CA process then the LS upon transitioning the CAFSM to the Update Cache state MUST keep a copy of the last CA message it sent and the LS SHOULD set a timer equal to CAReXmtInterval. If either the timer expires or the LS receives a CSU Solicit (CSUS) message (CSUS messages are described in Section 2.2.3) from the DCS then the LS releases the copy of the CA message. The reason for this is that if the DCS (which is master) loses the last CA message sent by the LS then the DCS will resend its previous CA message with the last CA Sequence number used. If that were to occur the LS would need to resend its last sent CA message as well.
请注意，如果LS在CA过程中是从属的，则在将CAFSM转换为更新缓存状态时，LS必须保留其发送的最后一条CA消息的副本，并且LS应将计时器设置为等于CAReXmtInterval。如果计时器过期或LS从DCS接收到CSU请求（CSU）消息（CSU消息在第2.2.3节中描述），则LS将释放CA消息的副本。原因是，如果DCS（主控）丢失了LS发送的最后一条CA消息，则DCS将使用最后一条CA序列号重新发送其先前的CA消息。如果发生这种情况，LS也需要重新发送其上次发送的CA消息。
2.2.2.1 "CA message processing":
2.2.2.1 “CA消息处理”：
The LS makes a list of those cache entries which are more "up to date" in the DCS than the LS's own cache. This list is called the CSA Request List (CRL). See Section 2.4 for a description of what it means for a CSA (Client State Advertisement) record or CSAS record to be more "up to date" than an LS's cache entry.
LS会列出DCS中比LS自己的缓存更“最新”的缓存项列表。该列表称为CSA请求列表（CRL）。有关CSA（客户端状态公告）记录或CSAS记录比LS缓存项更“最新”的含义的说明，请参见第2.4节。
If the CRL of the associated CAFSM of the LS is empty upon transition into the Update Cache State then the CAFSM immediately transitions into the Aligned State.
如果LS的关联CAFSM的CRL在转换为更新缓存状态时为空，则CAFSM立即转换为对齐状态。
If the CRL is not empty upon transition into the Update Cache State then the LS solicits the DCS to send the CSA records corresponding to the summaries (i.e., CSAS records) which the LS holds in its CRL. The solicited CSA records will contain the entirety of the cached information held in the DCS's cache for the given cache entry. The LS solicits the relevant CSA records by forming CSU Solicit (CSUS) messages from the CRL. See Section B.2.4 for the description of the CSUS message format. The LS then sends the CSUS messages to the DCS. The DCS responds to the CSUS message by sending to the LS one or more
如果CRL在转换到更新缓存状态时不为空，则LS请求DCS发送与LS在其CRL中保存的摘要（即CSAS记录）相对应的CSA记录。请求的CSA记录将包含DCS缓存中针对给定缓存条目保存的所有缓存信息。LS通过从CRL生成CSU请求（CSU）消息来请求相关CSA记录。有关CSU消息格式的说明，请参见第B.2.4节。然后，LS将CSU消息发送至DCS。DCS通过向LS发送一条或多条信息来响应CSU信息
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消息中标识的所有较新缓存信息的CSU请求消息。收到CSU请求后，LS将发送一个或多个CSU回复，如第2.3节所述。请注意，在任何给定时间，LS最多可能有一条CSU消息未完成。
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.
就在第一条CSU消息从LS发送到与CAFSM相关联的DCS之前，计时器设置为CSUSReXmtInterval秒。如果在计时器到期之前，尚未收到CSUS消息中与CSAS记录对应的所有CSA记录，则将创建一条新的CSUS消息，其中包含尚未收到相应CSA记录的所有CSAS记录，以及先前CSUS消息中未包含的其他CSAS记录。然后将新的CSU信息发送至DCS。如果在计时器到期之前的某个时间点，已收到先前发送的CSU消息中包含的所有CSAS记录的所有CSA记录更新，则计时器停止。一旦计时器停止，如果有其他CSAS记录未包含在先前的CSU消息中，但在CRL中，则计时器将重置，并创建一条新的CSU消息，其中仅包含CRL中尚未发送至DCS的CSAS记录。此过程将继续，直到LS收到CRL中所有CSA记录对应的CSA记录。当LS具有完全更新的缓存时，LS将与DC相关联的CAFSM转换为对齐状态。
If an LS receives a CSUS message or a CA message with a Receiver ID which is not the LS's LSID then the message must be discarded and ignored. This is necessary since an LS may be a leaf of a point to multipoint connection with other servers in the SG.
如果LS接收到的CSU消息或CA消息的接收方ID不是LS的LSID，则必须丢弃并忽略该消息。这是必要的，因为LS可能是与SG中其他服务器的点对多点连接的一个叶。
While in the Aligned state, an LS will perform the Cache State Update Protocol as described in Section 2.3.
当处于对齐状态时，LS将执行第2.3节所述的缓存状态更新协议。
Note that an LS may receive a CSUS message while in the Aligned State and, the LS MUST respond to the CSUS message with the appropriate CSU Request message in a similar fashion to the method previously described in Section 2.2.3.
请注意，LS可能在对齐状态下接收CSU消息，并且LS必须以与第2.2.3节中先前描述的方法类似的方式使用适当的CSU请求消息响应CSU消息。
"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
“缓存状态更新”（CSU）消息用于根据给定的PID/SGID动态更新服务器中缓存项的状态。CSU消息包含零个或多个“缓存状态公告”（CSA）记录，每个记录都包含其自己的特定缓存项状态快照。LS可向DCS发送/从DCS接收CSU
only when the corresponding CAFSM is in either the Aligned State or the Update Cache State.
仅当相应的CAFSM处于对齐状态或更新缓存状态时。
There are two types of CSU messages: CSU Requests and CSU Replies. See Sections B.2.2 and B.2.3 respectively for message formats. A CSU Request message is sent from an LS to one or more DCSs for one of two reasons: either the LS has received a CSUS message and MUST respond only to the DCS which originated the CSUS message, or the LS has become aware of a change of state of a cache entry. An LS becomes aware of a change of state of a cache entry either through receiving a CSU Request from one of its DCSs or as a result of a change of state being observed in a cached entry originated by the LS. In the former case, the LS will send a CSU Request to each of its DCSs except the DCS from which the LS became aware of the change in state. In the latter case, the LS will send a CSU Request to each of its DCSs. The change in state of a particular cache entry is noted in a CSA record which is then appended to the end of the CSU Request message mandatory part. In this way, state changes are propagated throughout the SG.
有两种类型的CSU消息：CSU请求和CSU回复。有关消息格式，请分别参见第B.2.2节和第B.2.3节。从LS向一个或多个DCS发送CSU请求消息的原因有两种：LS已收到CSU消息，且必须仅响应发出CSU消息的DCS，或者LS已意识到缓存项的状态变化。LS通过从其DCS之一接收CSU请求或由于在LS发起的缓存项中观察到状态变化而意识到缓存项的状态变化。在前一种情况下，LS将向其每个DCS发送CSU请求，除了LS从中了解到状态变化的DC。在后一种情况下，LS将向其每个DCS发送CSU请求。在CSA记录中记录特定缓存项的状态变化，然后将该记录附加到CSU请求消息强制部分的末尾。通过这种方式，状态更改在整个SG中传播。
Examples of such changes in state are as follows:
这种状态变化的例子如下：
1) a server receives a request from a client to add an entry to its cache, 2) a server receives a request from a client to remove an entry from its cache, 3) a cache entry has timed out in the server's cache, has been refreshed in the server's cache, or has been administratively modified.
1) 服务器从客户端接收到向其缓存中添加项的请求，2）服务器从客户端接收到从其缓存中删除项的请求，3）服务器缓存中的缓存项已超时，已在服务器缓存中刷新，或已被管理性修改。
When an LS receives a CSU Request from one of its DCSs, the LS acknowledges one or more CSA Records which were contained in the CSU Request by sending a CSU Reply. The CSU Reply contains one or more CSAS records which correspond to those CSA records which are being acknowledged. Thus, for example, if a CSA record is dropped (or delayed in processing) by the LS because there are insufficient resources to process it then a corresponding CSAS record is not included in the CSU Reply to the DCS.
当LS从其一个DCS接收到CSU请求时，LS通过发送CSU回复来确认CSU请求中包含的一个或多个CSA记录。CSU回复包含一个或多个CSA记录，这些记录对应于正在确认的CSA记录。因此，例如，如果由于没有足够的资源来处理CSA记录，因此LS丢弃（或延迟处理）CSA记录，则相应的CSA记录不包括在CSU对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.
请注意，LS可能会在收到CSU回复之前发送多个CSU请求消息，确认CSU请求中包含的任何CSA记录。还请注意，CSU回复可能包含对来自多个CSU请求的CSA记录的确认。因此，“请求”和“答复”这两个词可能有点混淆。
Note that a CSA Record contains a CSAS Record followed by client/server protocol specific information contained in a cache entry (see Section B.2.0.2 for CSAS record format information and
请注意，CSA记录包含一个CSAS记录，后面是缓存项中包含的客户端/服务器协议特定信息（CSAS记录格式信息和
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.
第B.2.2.1节（CSA记录格式信息）。当LS认为CSA记录代表的缓存信息比LS缓存中包含的缓存信息更“最新”（见第2.4节）时，会发生两件事：1）LS缓存更新为更为最新的信息，和2）LS将包含CSA记录的CSU请求发送到其每个DCS，CSA记录到达的DCS除外。这样，状态更改将在PID/SGID中传播。当然，在某些时候，LS也会通过向相应的DCS发送包含相应CSAS记录的CSU回复消息来确认CSA记录的接收。
When an LS sends a new CSU Request, the LS keeps track of the outstanding CSA records in that CSU Request and to which DCSs the LS sent the CSU Request. For each DCS to which the CSU Request was sent, a timer set to CSUReXmtInterval seconds is started just prior to sending the CSU Request. This timer is associated with the CSA Records contained in that CSU Request such that if that timer expires prior to having all CSA Records acknowledged from that DCS then (and only then) a CSU Request is re-sent by the LS to that DCS. However, the re-sent CSU Request only contains those CSA Records which have not yet been acknowledged. If all CSA Records associated with a timer becomes acknowledged then the timer is stopped. Note that the re-sent CSA Records follow the same time-out and retransmit rules as if they were new. Retransmission will occur a configured number of times for a given CSA Record and if acknowledgment fails to occur then an "abnormal event" has occurred at which point the then the HFSM associated with the DCS is transitioned to the Waiting State.
当LS发送新的CSU请求时，LS会跟踪该CSU请求中未完成的CSA记录以及LS向哪个DCS发送CSU请求。对于向其发送CSU请求的每个DCS，在发送CSU请求之前，将启动设置为CSUREXMTINERVAL秒的计时器。该计时器与该CSU请求中包含的CSA记录相关联，因此，如果该计时器在该DCS确认所有CSA记录之前过期，则（且仅在那时）LS将CSU请求重新发送至该DCS。但是，重新发送的CSU请求仅包含尚未确认的CSA记录。如果与计时器关联的所有CSA记录都已确认，则计时器将停止。请注意，重新发送的CSA记录遵循与新记录相同的超时和重新传输规则。对于给定的CSA记录，将进行配置次数的重新传输，如果确认失败，则发生“异常事件”，此时与DCS相关的HFSM将转换为等待状态。
A CSA Record instance is said to be on a "DCS retransmit queue" when it is associated with the previously mentioned timer. Only the most up-to-date CSA Record is permitted to be queued to a given DCS retransmit queue. Thus, if a less up-to-date CSA Record is queued to the DCS retransmit queue when a newer CSA Record instance is about to be queued to that DCS retransmit queue then the older CSA Record instance is dequeued and disassociated with its timer immediately prior to enqueuing the newer instance of the CSA Record.
当CSA记录实例与前面提到的计时器关联时，它被称为位于“DCS重新传输队列”上。只允许将最新的CSA记录排入给定的DCS重新传输队列。因此，当较新的CSA记录实例即将排队到DCS重传队列时，如果较新的CSA记录实例排队到DCS重传队列，则较旧的CSA记录实例将在将较新的CSA记录实例排队之前立即退出队列并与其计时器断开关联。
When an LS receives a CSU Reply from one of its DCSs then the LS checks each CSAS record in the CSU Reply against the CSAS Record portion of the CSA Records which are queued to the DCS retransmit queue.
当LS从其一个DCS接收到CSU回复时，LS将对照CSA记录中排队至DCS重传队列的CSA记录部分检查CSU回复中的每个CSA记录。
1) If there exists an exact match between the CSAS record portion of the CSA record and a CSAS Record in the CSU Reply then that CSA Record is considered to be acknowledged and is thus dequeued from the DCS retransmit queue and is disassociated with its timer.
1) 如果CSA记录的CSAS记录部分与CSU回复中的CSAS记录之间存在精确匹配，则该CSA记录被视为已确认，因此从DCS重传队列中退出队列，并与其计时器断开关联。
2) If there exists a match between the CSAS record portion of the CSA record and a CSAS Record in the CSU Reply except for the CSA Sequence number then
2) 如果CSA记录的CSAS记录部分与CSU回复中的CSAS记录（CSA序列号除外）之间存在匹配，则
a) If the CSA Record queued to the DCS retransmit queue has a CSA Sequence Number which is greater than the CSA Sequence Number in the CSAS Record of the the CSU Reply then the CSAS Record in the CSU Reply is ignored. b) If the CSA Record queued to the DCS retransmit queue has a CSA Sequence Number which is less than the CSA Sequence Number in the CSAS Record of the the CSU Reply then CSA Record which is queued to the DCS retransmit queue is dequeued and the CSA Record is disassociated with its timer. Further, a CSUS Message is sent to that DCS which sent the more up-to-date CSAS Record. All normal CSUS processing occurs as if the CSUS were sent as part of the CA protocol.
a) 若排入DCS重传队列的CSA记录的CSA序列号大于CSU应答的CSAS记录中的CSA序列号，则忽略CSU应答中的CSAS记录。b） 若排队至DCS重传队列的CSA记录的CSA序列号小于CSU应答的CSAS记录中的CSA序列号，则排队至DCS重传队列的CSA记录将退出队列，CSA记录与其计时器解除关联。此外，一条CSU消息被发送到发送最新CSAS记录的DCS。所有正常的CSU处理都是作为CA协议的一部分发送的。
When an LS receives a CSU Request message which contains a CSA Record which contains a CSA Sequence Number which is smaller than the CSA Sequence number of the cached CSA then the LS MUST acknowledge the CSA record in the CSU Request but it MUST do so by sending a CSU Reply message containing the CSAS Record portion of the CSA Record stored in the cache and not the CSAS Record portion of the CSA Record contained in the CSU Request.
当LS接收到包含CSA记录的CSU请求消息时，该CSA记录包含的CSA序列号小于缓存CSA的CSA序列号，则LS必须确认CSU请求中的CSA记录，但必须发送CSU回复消息，该CSU回复消息包含存储在CSA中的CSA记录的CSA记录部分缓存而不是CSU请求中包含的CSA记录的CSAS记录部分。
An LS responds to CSUS messages from its DCSs by sending CSU Request messages containing the appropriate CSA records to the DCS. If an LS receives a CSUS message containing a CSAS record for an entry which is no longer in its database (e.g., the entry timed out and was discarded after the Cache Alignment exchange completed but before the entry was requested through a CSUS message), then the LS will respond by copying the CSAS Record from the CSUS message into a CSU Request message and the LS will set the N bit signifying that this record is a NULL record since the cache entry no longer exists in the LS's cache. Note that in this case, the "CSA Record" included in the CSU Request to signify the NULL cache entry is literally only a CSAS Record since no client/server protocol specific information exists for the cache entry.
LS通过向DCS发送包含适当CSA记录的CSU请求消息来响应来自其DCS的CSU消息。如果LS接收到一条CSUS消息，其中包含一条已不在其数据库中的条目的CSAS记录（例如，该条目超时，在缓存对齐交换完成后，但在通过CSUS消息请求该条目之前被丢弃），然后，LS将通过将CSAS记录从CSU消息复制到CSU请求消息中进行响应，LS将设置N位，表示该记录为空记录，因为LS的缓存中不再存在缓存条目。注意，在这种情况下，CSU请求中包含的表示空缓存项的“CSA记录”实际上只是CSAS记录，因为缓存项不存在客户机/服务器协议特定的信息。
If an LS receives a CSA Record in a CSU Request from a DCS for which the LS has an identical CSA record posted to the corresponding DCS's DCS retransmit queue then the CSA Record on the DCS retransmit queue is considered to be implicitly acknowledged. Thus, the CSA Record is dequeued from the DCS retransmit queue and is disassociated with its timer. The CSA Record sent by the DCS MUST still be acknowledged by the LS in a CSU Reply, however. This is useful in the case of point
如果LS从DCS收到CSU请求中的CSA记录，并且LS的CSA记录已发布到相应DCS的DCS重传队列，则认为DCS重传队列上的CSA记录已被隐式确认。因此，CSA记录从DCS重传队列中退出队列，并与其计时器解除关联。但是，DCS发送的CSA记录仍必须由LS在CSU回复中确认。这在点的情况下很有用
to multipoint connections where the rule that "when an LS receives a CSA record from a DCS, that LS floods the CSA Record to every DCS except the DCS from which it was received" might be broken.
对于多点连接，“当LS从DCS接收到CSA记录时，LS将CSA记录发送到每个DCS（接收到CSA记录的DCS除外）”的规则可能会被打破。
If an LS receives a CSU with a Receiver ID which is not equal to the LSID and is not set to all 0xFFs then the CSU must be discarded and ignored. This is necessary since the LS may be a leaf of a point to multipoint connection with other servers in the LS's SG.
如果LS接收到的CSU的接收器ID不等于LSID且未设置为所有0xFFs，则必须丢弃并忽略该CSU。这是必要的，因为LS可能是与LS的SG中的其他服务器的点对多点连接的一部分。
An LS MAY send a CSU Request to the all 0xFFs Receiver ID when the LS is a root of a point to multipoint connection with a set of its DCSs. If an LS receives a CSU Request with the all 0xFFs Receiver ID then it MUST use the Sender ID in the CSU Request as the Receiver ID of the CSU Reply (i.e., it MUST unicast its response to the sender of the request) when responding. If the LS wishes to send a CSU Request to the all 0xFFs Receiver ID then it MUST create a time-out and retransmit timer for each of the DCSs which are leaves of the point to multipoint connection prior to sending the CSU Request. If in this case, the time-out and retransmit timer expires for a given DCS prior to acknowledgment of a given CSA Record then the LS MUST use the specific DCSID as the Receiver ID rather than the all 0xFFs Receiver ID. Similarly, if it is necessary to re-send a CSA Record then the LS MUST specify the specific DCSID as the Receiver ID rather than the all 0xFFs Receiver ID.
当LS是具有一组DCS的点对多点连接的根时，LS可以向all 0xFFs接收器ID发送CSU请求。如果LS接收到具有所有0xFFs接收方ID的CSU请求，则在响应时必须使用CSU请求中的发送方ID作为CSU回复的接收方ID（即，它必须单播其对请求发送方的响应）。如果LS希望向all 0xFFs接收器ID发送CSU请求，则必须在发送CSU请求之前，为每个点对多点连接的DCS创建超时和重传计时器。在这种情况下，如果在确认给定CSA记录之前，给定DCS的超时和重传计时器过期，则LS必须使用特定DCSID作为接收器ID，而不是所有0xFFs接收器ID。类似地，如果需要重新发送CSA记录，则LS必须指定特定的DCSID作为接收器ID，而不是all 0xFFs接收器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请求，并且发送服务器将CSU请求中的CSA记录发送到all 0xFFs接收器ID，那么mesh中的每个其他服务器都不必将其自己的包含这些CSA记录的CSU请求发送到mesh中，以便正确地淹没CSA记录。这是因为mesh中的每台服务器都会听到CSU请求，并会适当地处理包含的CSA记录。因此，在一个完整的网格中的服务器可以认为网格是一个单一的逻辑端口，因此“当LS从DCS接收到CSA记录时，它将CSA记录洪泛到每个DCS，除非接收到的DCS除外”。全mesh中的接收服务器仍需要使用CSU回复消息确认CSA记录，其中包含回复服务器的LSID作为发送方ID，发送CSU请求的服务器的ID作为接收方ID字段。在超时和重传情况下，CSU请求的接收器ID将设置为未确认CSA记录的特定DCSID（与all 0xFFs接收器ID相反）。由于完整网格模拟连接到完整网格的服务器的广播媒体，因此在广播媒体上使用SCSP也可以使用此技术。关于使用全网或使用广播媒体的进一步讨论留给客户机/服务器协议
specific documents.
具体文件。
During the cache alignment process and during normal CSU processing, a CSAS Record is compared against the contents of an LS's cache entry to decide whether the information contained in the record is more "up to date" than the corresponding cache entry of the LS.
在缓存对齐过程和正常CSU处理期间，将CSAS记录与LS缓存项的内容进行比较，以确定记录中包含的信息是否比LS的相应缓存项更“最新”。
There are three pieces of information which are used in determining whether a record contains information which is more "up to date" than the information contained in the cache entry of an LS which is processing the record: 1) the Cache Key, 2) the Originator which is described by an Originator ID (OID), and 3) the CSA Sequence number. See Section B.2.0.2 for more information on these fields.
有三条信息用于确定记录是否包含比正在处理记录的LS的缓存条目中包含的信息更“最新”的信息：1）缓存密钥，2）由发起者ID（OID）描述的发起者，以及3）CSA序列号。有关这些字段的更多信息，请参见第B.2.0.2节。
Given these three pieces of information, a CSAS record (be it part of a CSA Record or be it stand-alone) is considered to be more "up to date" than the information contained in the cache of an LS if all of the following are true:
鉴于这三条信息，如果满足以下所有条件，则CSAS记录（无论是CSA记录的一部分还是独立记录）被认为比LS缓存中包含的信息更“最新”：
1) The Cache Key in the CSAS Record matches the stored Cache Key in the LS's cache entry, 2) The OID in the CSAS Record matches the stored OID in the LS's cache entry, 3) The CSA Sequence Number in the CSAS Record is greater than CSA Sequence Number in the LS's cache entry.
1) CSAS记录中的缓存密钥与LS缓存项中存储的缓存密钥匹配，2）CSAS记录中的OID与LS缓存项中存储的OID匹配，3）CSAS记录中的CSA序列号大于LS缓存项中的CSA序列号。
Discussion and Conclusions
讨论和结论
While the above text is couched in terms of synchronizing the knowledge of the state of a client within the cache of servers contained in a SG, this solution generalizes easily to any number of database synchronization problems (e.g., LECS synchronization).
虽然上面的文本是根据同步SG中包含的服务器缓存中的客户机状态知识来表达的，但该解决方案很容易推广到任何数量的数据库同步问题（例如，LECS同步）。
SCSP defines a generic flooding protocol. There are a number of related issues relative to cache maintenance and topology maintenance which are more appropriately defined in the client/server protocol specific documents; for example, it might be desirable to define a generic cache entry time-out mechanism for a given protocol or to advertise adjacency information between servers so that one could obtain a topo-map of the servers in a SG. When mechanisms like these are desirable, they will be defined in the client/server protocol specific documents.
SCSP定义了一个通用泛洪协议。与缓存维护和拓扑维护相关的许多问题在客户机/服务器协议特定文档中有更合适的定义；例如，可能需要为给定协议定义通用缓存条目超时机制，或者在服务器之间公布邻接信息，以便可以获得SG中服务器的拓扑图。当需要这些机制时，它们将在客户机/服务器协议特定文档中定义。
Appendix A: Terminology and Definitions
附录A：术语和定义
CA Message - Cache Alignment Message These messages allow an LS to synchronize its entire cache with that of the cache of one of its DCSs.
CA消息-缓存对齐消息这些消息允许LS将其整个缓存与其一个DCS的缓存同步。
CAFSM - Cache Alignment Finite State Machine The CAFSM monitors the state of the cache alignment between an LS and a particular DCS. There exists one CAFSM per DCS as seen from an LS.
CAFSM-缓存对齐有限状态机CAFSM监视LS和特定DCS之间的缓存对齐状态。从LS上看，每个DCS存在一个CAFSM。
CSA Record - Cache State Advertisement Record A CSA is a record within a CSU message which identifies an update to the status of a "particular" cache entry.
CSA记录-缓存状态播发记录CSA是CSU消息中的一个记录，用于标识对“特定”缓存项状态的更新。
CSAS Record - Cache State Advertisement Summary Record A CSAS contains a summary of the information in a CSA. A server will send CSAS records describing its cache entries to another server during the cache alignment process. CSAS records are also included in a CSUS messages when an LS wants to request the entire CSA from the DCS. The LS is requesting the CSA from the DCS because the LS believes that the DCS has a more recent view of the state of the cache entry in question.
CSAS记录-缓存状态播发摘要记录CSAS包含CSA中的信息摘要。在缓存对齐过程中，服务器将向另一台服务器发送描述其缓存项的CSAS记录。当LS希望从DCS请求整个CSA时，CSAS记录也包含在CSU消息中。LS向DCS请求CSA，因为LS认为DCS对相关缓存项的状态有一个更新的视图。
CSU Message - Cache State Update message This is a message sent from an LS to its DCSs when the LS becomes aware of a change in state of a cache entry.
CSU消息-缓存状态更新消息这是当LS意识到缓存项的状态发生变化时，LS向其DCS发送的消息。
CSUS Message - Cache State Update Solicit Message This message is sent by an LS to its DCS after the LS and DCS have exchanged CA messages. The CSUS message contains one or more CSAS records which represent solicitations for entire CSA records (as opposed to just the summary information held in the CSAS).
CSU消息-缓存状态更新请求消息此消息由LS在LS和DC交换CA消息后发送到其DC。CSUS消息包含一个或多个CSAS记录，这些记录表示对整个CSA记录的请求（而不仅仅是CSAS中保存的摘要信息）。
DCS - Directly Connected Server The DCS is a server which is directly connected to the LS; e.g., there exists a VC between the LS and DCS. This term, along with the terms LS and RS, is used to give a frame of reference when talking about servers and their synchronization. Unless explicitly stated to the contrary, there is no implied difference in functionality between a DCS, LS, and RS.
DCS-直接连接的服务器DCS是直接连接到LS的服务器；e、 例如，LS和DCS之间存在VC。这个术语与术语LS和RS一起，用于在讨论服务器及其同步时提供一个参考框架。除非明确说明相反，否则DCS、LS和RS之间的功能没有隐含差异。
HFSM - Hello Finite State Machine An LS has a HFSM associated with each of its DCSs. The HFSM monitors the state of the connectivity between the LS and a particular DCS.
Hello有限状态机LS有一个与其每个DCS关联的HFSM。HFSM监控LS和特定DCS之间的连接状态。
LS - Local Server The LS is the server under scrutiny; i.e., all statements are made from the perspective of the LS. This term, along with the terms DCS and RS, is used to give a frame of reference when talking about servers and their synchronization. Unless explicitly stated to the contrary, there is no implied difference in functionality between a DCS, LS, and RS.
LS-本地服务器LS是正在检查的服务器；i、 例如，所有声明都是从LS的角度进行的。这个术语与术语DCS和RS一起，用于在讨论服务器及其同步时提供一个参考框架。除非明确说明相反，否则DCS、LS和RS之间的功能没有隐含差异。
LSID - Local Server ID The LSID is a unique token that identifies an LS. This value might be taken from the protocol address of the LS.
LSID-本地服务器ID LSID是标识LS的唯一令牌。此值可能来自LS的协议地址。
PID - Protocol ID This field contains an identifier which identifies the client/server protocol which is making use of SCSP for the given message. The assignment of Protocol IDs for this field is given over to IANA as described in Section C.
PID-协议ID此字段包含一个标识符，该标识符标识为给定消息使用SCSP的客户端/服务器协议。如第C节所述，将该字段的协议ID分配给IANA。
RS - Remote Server (RS) From the perspective of an LS, an RS is a server, separate from the LS, which is not directly connected to the LS (i.e., an RS is always two or more hops away from an LS whereas a DCS is always one hop away from an LS). Unless otherwise stated an RS refers to a server in the SG. This term, along with the terms LS and DCS, is used to give a frame of reference when talking about servers and their synchronization. Unless explicitly stated to the contrary, there is no implied difference in functionality between a DCS, LS, and RS.
RS-远程服务器（RS）从LS的角度来看，RS是一个独立于LS的服务器，它不直接连接到LS（即，RS始终与LS相隔两个或多个跃点，而DCS始终与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.
SG-服务器组SCSP通过某种方式（例如，属于逻辑IP子网（LIS）[1]的所有服务器）同步绑定到SG的一组服务器实体的缓存（或部分缓存）。因此，SG只是围绕一些共性的一组服务器。
SGID - Server Group ID This ID is a 16 bit identification field that uniquely identifies the instance client/server protocol for which the servers of the SG are being synchronized. This implies that multiple instances of the same protocol may be in operation at the same time and have their servers synchronized independently of each other.
SGID-服务器组ID此ID是一个16位标识字段，唯一标识正在同步SG服务器的实例客户端/服务器协议。这意味着同一协议的多个实例可能同时运行，并且它们的服务器彼此独立地同步。
Appendix B: SCSP Message Formats
附录B：SCSP消息格式
This section of the appendix includes the message formats for SCSP. SCSP protocols are LLC/SNAP encapsulated with an LLC=0xAA-AA-03 and OUI=0x00-00-5e and PID=0x00-05.
附录的本节包括SCSP的消息格式。SCSP协议采用LLC=0xAA-AA-03、OUI=0x00-00-5e和PID=0x00-05进行LLC/SNAP封装。
SCSP has 3 parts to every packet: the fixed part, the mandatory part, and the extensions part. The fixed part of the message exists in every packet and is shown below. The mandatory part is specific to the particular message type (i.e., CA, CSU Request/Reply, Hello, CSUS) and, it includes (among other packet elements) a Mandatory Common Part and zero or more records each of which contains information pertinent to the state of a particular cache entry (except in the case of a Hello message) whose information is being synchronized within a SG. The extensions part contains the set of extensions for the SCSP message.
SCSP对每个数据包有3个部分：固定部分、强制部分和扩展部分。消息的固定部分存在于每个数据包中，如下所示。强制部分特定于特定的消息类型（即CA、CSU请求/应答、Hello、CSU），并且它包括（除其他分组元素外）强制公共部分和零个或多个记录，每个记录包含与特定缓存项的状态相关的信息（Hello消息的情况除外）其信息正在SG内同步。extensions部分包含SCSP消息的扩展集。
In the following message formats, the fields marked as "unused" MUST be set to zero upon transmission of such a message and ignored upon receipt of such a message.
在以下消息格式中，标记为“未使用”的字段必须在传输此类消息时设置为零，并在收到此类消息时忽略。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type Code | Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Start Of Extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type Code | Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Start Of Extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version This is the version of the SCSP protocol being used. The current version is 1.
版本这是正在使用的SCSP协议的版本。当前版本为1。
Type Code This is the code for the message type (e.g., Hello (5), CSU Request(2), CSU Reply(3), CSUS (4), CA (1)).
类型代码这是消息类型的代码（例如，Hello（5）、CSU请求（2）、CSU回复（3）、CSU（4）、CA（1））。
Packet Size The total length of the SCSP packet, in octets (excluding link layer and/or other protocol encapsulation).
数据包大小SCSP数据包的总长度，以八位字节为单位（不包括链路层和/或其他协议封装）。
Checksum The standard IP checksum over the entire SCSP packet starting at the fixed header. If the packet is an odd number of bytes in length then this calculation is performed as if a byte set to 0x00 is appended to the end of the packet.
校验和从固定报头开始的整个SCSP数据包的标准IP校验和。如果数据包的长度为奇数字节，则执行此计算时，就好像将设置为0x00的字节追加到数据包的末尾一样。
Start Of Extensions This field is coded as zero when no extensions are present in the message. If extensions are present then this field will be coded with the offset from the top of the fixed header to the beginning of the first extension.
扩展的开始当消息中没有扩展时，此字段编码为零。如果存在扩展，则此字段将使用从固定标题顶部到第一个扩展开始的偏移量进行编码。
The mandatory part of the SCSP packet contains the operation specific information for a given message type (e.g., SCSP Cache State Update Request/Reply, etc.), and it includes (among other packet elements) a Mandatory Common Part (described in Section B.2.0.1) and zero or more records each of which contains information pertinent to the state of a particular cache entry (except in the case of a Hello message) whose information is being synchronized within a SG. These records may, depending on the message type, be either Cache State Advertisement Summary (CSAS) Records (described in Section B.2.0.2) or Cache State Advertisement (CSA) Records (described in Section B.2.2.1). CSA Records contain a summary of a cache entry's information (i.e., a CSAS Record) plus some additional client/server protocol specific information. The mandatory common part format and CSAS Record format is shown immediately below, prior to showing their use in SCSP messages, in order to prevent replication within the message descriptions.
SCSP数据包的强制部分包含给定消息类型（例如，SCSP缓存状态更新请求/回复等）的操作特定信息，并且包括（除其他数据包元素外）强制公共部分（在第B.2.0.1节中描述）以及零个或多个记录，其中每个记录包含与特定高速缓存条目的状态相关的信息（Hello消息的情况除外），其信息在SG内被同步。根据消息类型，这些记录可以是缓存状态播发摘要（CSAS）记录（见第B.2.0.2节）或缓存状态播发（CSA）记录（见第B.2.2.1节）。CSA记录包含缓存项信息（即CSAS记录）的摘要以及一些额外的客户端/服务器协议特定信息。在SCSP消息中显示其使用之前，下面将显示强制通用部件格式和CSAS记录格式，以防止消息描述中的复制。
Sections B.2.1 through B.2.5 have a substantial overlap in format. This overlapping format is called the mandatory common part and its format is shown below:
第B.2.1节至第B.2.5节在格式上有很大重叠。这种重叠格式称为强制性公共部分，其格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | Server Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID Len | Recvr ID Len | Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | Server Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID Len | Recvr ID Len | Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol ID This field contains an identifier which identifies the client/server protocol which is making use of SCSP for the given message. The assignment of Protocol IDs for this field is given over to IANA as described in Section C. Protocols with current documents have the following defined values:
Protocol ID此字段包含一个标识符，该标识符标识为给定消息使用SCSP的客户端/服务器协议。如第C节所述，此字段的协议ID分配给IANA。具有当前文件的协议具有以下定义值：
1 - ATMARP 2 - NHRP 3 - MARS 4 - DHCP 5 - LNNI
1-ATMARP 2-NHRP 3-MARS 4-DHCP 5-LNNI
Server Group ID This ID is uniquely identifies the instance of a given client/server protocol for which servers are being synchronized.
服务器组ID此ID唯一标识正在为其同步服务器的给定客户端/服务器协议的实例。
Flags The Flags field is message specific, and its use will be described in the specific message format sections below.
标志标志标志字段是特定于消息的，其使用将在下面的特定消息格式部分中描述。
Sender ID Len This field holds the length in octets of the Sender ID.
Sender ID Len此字段保存发件人ID的长度（以八位字节为单位）。
Recvr ID Len This field holds the length in octets of the Receiver ID.
Recvr ID Len此字段保存接收器ID的长度（以八位字节为单位）。
Number of Records This field contains the number of additional records associated with the given message. The exact format of these records is specific to the message and will be described for each message type in the sections below.
记录数此字段包含与给定消息关联的其他记录数。这些记录的确切格式是特定于消息的，并将在以下各节中针对每种消息类型进行描述。
Sender ID This is an identifier assigned to the server which is sending the given message. One possible assignment might be the protocol address of the sending server.
发件人ID这是分配给发送给定邮件的服务器的标识符。一种可能的分配可能是发送服务器的协议地址。
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这是分配给要接收给定消息的服务器的标识符。一个可能的分配可能是接收给定消息的服务器的协议地址。
CSAS records contain a summary of information contained in a cache entry of a given client/server database which is being synchronized through the use of SCSP. The summary includes enough information for SCSP to look into the client/server database for the appropriate database cache entry and then compare the "newness" of the summary against the "newness" of the cached entry.
CSAS记录包含通过使用SCSP同步的给定客户机/服务器数据库的缓存项中包含的信息摘要。摘要包含足够的信息，SCSP可以在客户机/服务器数据库中查找适当的数据库缓存项，然后将摘要的“新性”与缓存项的“新性”进行比较。
Note that CSAS records do not contain a Server Group ID (SGID) nor do they contain a Protocol ID. These IDs are necessary to identify which protocol and which instance of that protocol for which the summary is applicable. These IDs are present in the mandatory common part of each message.
请注意，CSAS记录不包含服务器组ID（SGID），也不包含协议ID。这些ID对于标识摘要适用的协议和该协议的实例是必需的。这些ID存在于每条消息的必需公共部分中。
Note also that the values of the Hop Count and Record Length fields of a CSAS Record are dependent on whether the CSAS record exists as a "stand-alone" record or whether the CSAS record is "embedded" in CSA Record. This is further described below.
还要注意，CSAS记录的跃点计数和记录长度字段的值取决于CSAS记录是否作为“独立”记录存在，或者CSAS记录是否“嵌入”在CSA记录中。这将在下文中进一步描述。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key Len | Orig ID Len |N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key Len | Orig ID Len |N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop Count This field represents the number of hops that the record may take before being dropped. Thus, at each server that the record traverses, the Hop Count is decremented. This field is set to 1 when the CSAS record is a "stand-alone" record (i.e., it is not embedded within a CSA record) since summaries do not go beyond one hop during the cache alignment process. If a CSAS record is "embedded" within a CSA record then the Hop Count is set to an administratively defined value which is almost certainly greater than or equal to the the cardinality of the SG minus one. Note that an exception to the previous rule occurs when the CSA Record is carried within a CSU Request which was sent in response to a solicitation (i.e., in response to a CSAS Record which was sent in a CSUS message); in which case, the Hop Count SHOULD be set to 1.
跃点计数此字段表示记录在删除之前可能需要的跃点数。因此，在记录遍历的每个服务器上，跃点计数都会减少。当CSAS记录为“独立”记录（即，它未嵌入CSA记录）时，此字段设置为1，因为在缓存对齐过程中摘要不会超过一个跃点。如果CSAS记录“嵌入”在CSA记录中，则跃点计数设置为管理定义的值，该值几乎肯定大于或等于SG的基数减1。注意，当CSA记录包含在CSU请求中时，会出现前一规则的例外情况，CSU请求是响应请求发送的（即，响应CSU消息中发送的CSAS记录）；在这种情况下，跃点计数应设置为1。
Record Length If the CSAS record is a "stand-alone" record then this value is 12+"Cache Key Leng"+"Orig ID Len" in bytes; otherwise, this value is set to 12+"Cache Key Leng"+"Orig ID Len"+ sizeof("Client/Server Protocol Specific Part for cache entry"). The size of the Client/Server Protocol Specific Part may be obtained from the client/server protocol specific document for the given Protocol ID.
记录长度如果CSAS记录是“独立”记录，则该值为12+“缓存密钥长度”+“原始ID长度”，以字节为单位；否则，该值将设置为12+“缓存密钥长度”+“原始ID长度”+sizeof（“缓存条目的客户端/服务器协议特定部分”）。客户机/服务器协议特定部分的大小可以从给定协议ID的客户机/服务器协议特定文档中获得。
Cache Key Len Length of the Cache Key field in bytes.
缓存密钥Len缓存密钥字段的长度（字节）。
Orig ID Len. Length of the Originator ID field in bytes.
原始ID Len。原始发件人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记录实际上是空记录。该位仅用于CSU请求/回复中包含的CSAS记录，该请求/回复是响应CSU消息发送的。当请求的CSA记录所代表的缓存条目不再存在于LS的缓存中时，LS可能会收到CSA记录的请求（有关详细信息，请参阅第2.3节）。在这种情况下，LS将CSAS记录直接从CSUS消息复制到CSU请求中，LS设置N位，表示缓存项不再存在。请求不再存在CSA记录的DC仍将回复CSU回复。该位通常设置为零。
CSA Sequence Number This field contains a sequence number that identifies the "newness" of a CSA record instance being summarized. A "larger" sequence number means a more recent advertisement. Thus, if the state of part (or all) of a cache entry needs to be updated then the CSA record advertising the new state MUST contain a CSA Sequence Number which is larger than the one corresponding to the previous advertisement. This number is assigned by the originator of the CSA record. The CSA Sequence Number may be assigned by the originating server or by the client which caused its server to advertise its existence.
CSA序列号此字段包含一个序列号，用于标识正在汇总的CSA记录实例的“新性”。“较大”的序列号表示最近的广告。因此，如果需要更新缓存项的部分（或全部）状态，则公布新状态的CSA记录必须包含大于对应于先前公布的CSA序列号的CSA序列号。该编号由CSA记录的发起人指定。CSA序列号可由发起服务器或导致其服务器公布其存在的客户端分配。
The CSA Sequence Number is a signed 32 bit number. Within the CSA Sequence Number space, the number -2^31 (0x80000000) is reserved. Thus, the usable portion of the CSA Sequence Number space for a given Cache Key is between the numbers -2^31+1 (0x80000001) and 2^31-1 (0x7fffffff). An LS uses -2^31+1 the first time it originates a CSA Record for a cache entry that it created. Each time the cache entry is modified in some manner and when that modification needs to be synchronized with the other servers in the SG, the LS increments the CSA Sequence number associated with the
CSA序列号是一个有符号的32位数字。在CSA序列号空间中，保留数字-2^31（0x8000000）。因此，给定缓存键的CSA序列号空间的可用部分在数字-2^31+1（0x80000001）和2^31-1（0x7fffffff）之间。LS在第一次为其创建的缓存项创建CSA记录时使用-2^31+1。每次以某种方式修改缓存条目时，以及当该修改需要与SG中的其他服务器同步时，LS都会增加与缓存条目相关联的CSA序列号
given Cache Key and uses that new CSA Sequence Number when advertising the update. If it is ever the case that a given CSA Sequence Number has reached 2^31-2 and the associated cache entry has been modified such that an update must be sent to the rest of the servers in the SG then the given cache entry MUST first be purged from the SG by the LS by sending a CSA Record which causes the cache entry to be removed from other servers and this CSA Record carries a CSA Sequence Number of 2^31-1. The exact packet format and mechanism by which a cache entry is purged is defined in the appropriate protocol specific document. After the purging CSA Record has been acknowledged by each DCS, an LS will then send a new CSA Record carrying the updated information, and this new CSA Record will carry a CSA Sequence Number of -2^31+1.
给定缓存密钥，并在公布更新时使用该新CSA序列号。如果给定的CSA序列号已达到2^31-2，并且相关的缓存项已被修改，因此必须向SG中的其余服务器发送更新，则LS必须首先通过发送CSA记录从SG中清除给定的缓存项，该记录导致缓存项从其他服务器中删除这个CSA记录带有CSA序列号2^31-1。清除缓存项的确切数据包格式和机制在相应的协议特定文档中定义。各DCS确认吹扫CSA记录后，LS将发送一个新的CSA记录，其中包含更新的信息，该新的CSA记录将包含一个CSA序列号-2^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达到对齐状态后，如果需要同步对现有缓存项的更新或需要同步新缓存项，则随后的CSA记录必须包含给定OID和缓存密钥在SG内唯一的CSA序列号。获得该编号的推荐方法（除非协议特定文档中明确规定相反）是将CSA记录中的CSA序列号设置为与现有缓存项相关联的CSA序列号（如果已存在过期缓存项，则为零）加上配置的常量。注意，协议特定文档可能要求在更新缓存项之前清除包含重启LS的OID的所有缓存项；在这种情况下，更新CSA记录仍将包含一个CSA序列号，该序列号被设置为与先前存在的缓存项关联的CSA序列号加上一个配置的常量。
Cache Key This is a database lookup key that uniquely identifies a piece of data which the originator of a CSA Record wishes to synchronize with its peers for a given "Protocol ID/Server Group ID" pair. This key will generally be a small opaque byte string which SCSP will associate with a given piece of data in a cache. Thus, for example, an originator might assign a particular 4 byte string to the binding of an IP address with that of an ATM address. Generally speaking, the originating server of a CSA record is responsible for generating a Cache Key for every element of data that the the given server originates and which the server wishes to synchronize with its peers in the SG.
缓存密钥这是一个数据库查找密钥，它唯一地标识CSA记录的发起人希望与给定“协议ID/服务器组ID”对的对等方同步的一段数据。该键通常是一个不透明的小字节字符串，SCSP将其与缓存中的给定数据段相关联。因此，例如，发起者可能会将特定的4字节字符串分配给IP地址与ATM地址的绑定。一般来说，CSA记录的发起服务器负责为给定服务器发起并且服务器希望与SG中的对等方同步的每个数据元素生成缓存密钥。
Originator ID This field contains an ID administratively assigned to the server which is the originator of CSA Records.
发起人ID此字段包含管理分配给作为CSA记录发起人的服务器的ID。
The Cache Alignment (CA) message allows an LS to synchronize its entire cache with that of the cache of its DCSs within a server group. The CA message type code is 1. The CA message mandatory part format is as follows:
Cache Alignment（CA）消息允许LS将其整个缓存与其服务器组中DCS的缓存进行同步。CA消息类型代码为1。CA消息强制部分格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CA Sequence Number A value which provides a unique identifier to aid in the sequencing of the cache alignment process. A "larger" sequence number means a more recent CA message. The slave server always copies the sequence number from the master server's previous CA message into its current CA message which it is sending and the the slave acknowledges the master's CA message. Since the initial CA process is lock-step, if the slave does not receive the same sequence number which it previously received then the information in the slave's previous CA message is implicitly acknowledged. Note that there is a separate CA Sequence Number space associated with each CAFSM.
CA序列号提供唯一标识符以帮助对缓存对齐过程进行排序的值。“较大”的序列号表示最近的CA消息。从属服务器总是将主服务器上一个CA消息中的序列号复制到它正在发送的当前CA消息中，从属服务器确认主服务器的CA消息。由于初始CA过程是锁定步骤，如果从机未接收到与先前接收到的序列号相同的序列号，则隐式确认从机先前CA消息中的信息。请注意，每个CAFSM都有一个单独的CA序列号空间。
Whenever it is necessary to (re)start cache alignment and the CAFSM enters the Master/Slave Negotiation state, the CA Sequence Number should be set to a value not previously seen by the DCS. One possible scheme is to use the machine's time of day counter.
每当需要（重新）启动缓存对齐且CAFSM进入主/从协商状态时，CA序列号应设置为DCS以前未看到的值。一种可能的方案是使用机器的时间计数器。
Mandatory Common Part The mandatory common part is described in detail in Section B.2.0.1. There are two fields in the mandatory common part whose codings are specific to a given message type. These fields are the "Number of Records" field and the "Flags" field.
强制性公用部分第B.2.0.1节详细描述了强制性公用部分。强制公共部分中有两个字段，其编码特定于给定的消息类型。这些字段是“记录数”字段和“标志”字段。
Number of Records The Number of Records field of the mandatory common part for the CA message gives the number of CSAS Records appended to the CA message mandatory part.
记录数CA消息的强制公共部分的记录数字段提供附加到CA消息强制部分的CSAS记录数。
Flags The Flags field of the mandatory common part for the CA message has the following format:
标志CA消息的必需公共部分的标志字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|I|O| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|I|O| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M This bit is part of the negotiation process for the cache alignment. When this bit is set then the sender of the CA message is indicating that it wishes to lead the alignment process. This bit is the "Master/Slave bit".
M该位是缓存对齐协商过程的一部分。当设置此位时，CA消息的发送方表示希望引导对齐过程。该位为“主/从位”。
I When set, this bit indicates that the sender of the CA message believes that it is in a state where it is negotiating for the status of master or slave. This bit is the "Initialization bit".
I当设置时，该位表示CA消息的发送方认为其处于协商主或从状态的状态。该位为“初始化位”。
O This bit indicates that the sender of the CA message has more CSAS records to send. This implies that the cache alignment process must continue. This bit is the "mOre bit" despite its dubious name.
O此位表示CA消息的发送方有更多CSAS记录要发送。这意味着缓存对齐过程必须继续。这个比特是“更多比特”，尽管它的名字可疑。
All other fields of the mandatory common part are coded as described in Section B.2.0.1.
强制性公共部分的所有其他字段按照第B.2.0.1节所述进行编码。
CSAS record The CA message appends CSAS records to the end of its mandatory part. These CSAS records are NOT embedded in CSA records. See Section B.2.0.2 for details on CSAS records.
CSAS记录CA消息将CSAS记录附加到其强制部分的末尾。这些CSA记录未嵌入CSA记录中。有关CSAS记录的详细信息，请参见第B.2.0.2节。
The Cache State Update Request (CSU Request) message is used to update the state of cache entries in servers which are directly connected to the server sending the message. A CSU Request message is sent from one server (the LS) to directly connected server (the DCS) when the LS observes changes in the state of one or more cache
缓存状态更新请求（CSU请求）消息用于更新直接连接到发送消息的服务器的服务器中缓存项的状态。当LS观察到一个或多个缓存状态的变化时，CSU请求消息从一个服务器（LS）发送到直接连接的服务器（DCS）
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通过接收导致LS数据库更新的CSU请求或通过观察由LS发起的缓存条目的状态变化来观察这种状态变化。通过将“缓存状态公告”（CSA）记录附加到CSU请求的强制部分的末尾，在CSU消息中记录缓存项的状态变化，如下所示。
The CSU Request message type code is 2. The CSU Request message mandatory part format is as follows:
CSU请求消息类型代码为2。CSU请求消息强制部分格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mandatory Common Part The mandatory common part is described in detail in Section B.2.0.1. There are two fields in the mandatory common part whose codings are specific to a given message type. These fields are the "Number of Records" field and the "Flags" field.
强制性公用部分第B.2.0.1节详细描述了强制性公用部分。强制公共部分中有两个字段，其编码特定于给定的消息类型。这些字段是“记录数”字段和“标志”字段。
Number of Records The Number of Records field of the mandatory common part for the CSU Request message gives the number of CSA Records appended to the CSU Request message mandatory part.
记录数CSU请求消息的强制公共部分的记录数字段提供附加到CSU请求消息强制部分的CSA记录数。
Flags Currently, there are no flags defined for the Flags field of the mandatory common part for the CSU Request message.
标志当前，没有为CSU请求消息的必需公共部分的标志字段定义标志。
All other fields of the mandatory common part are coded as described in Section B.2.0.1.
强制性公共部分的所有其他字段按照第B.2.0.1节所述进行编码。
CSA Record See Section B.2.2.1.
CSA记录见第B.2.2.1节。
CSA records contain the information necessary to relate the current state of a cache entry in an SG to the servers being synchronized. CSA records contain a CSAS Record header and a client/server protocol specific part. The CSAS Record includes enough information for SCSP to look into the client/server database for the appropriate database cache entry and then compare the "newness" of the summary against the "newness" of the cached entry. If the information contained in the CSA is more new than the cached entry of the receiving server then the cached entry is updated accordingly with the contents of the CSA Record. The client/server protocol specific part of the CSA Record is documented separately for each such protocol. Examples of the protocol specific parts for NHRP and ATMARP are shown in [8] and [9] respectively.
CSA记录包含将SG中缓存项的当前状态与正在同步的服务器关联所需的信息。CSA记录包含CSAS记录头和特定于客户端/服务器协议的部分。CSAS记录包含足够的信息，SCSP可以在客户机/服务器数据库中查找适当的数据库缓存项，然后将摘要的“新性”与缓存项的“新性”进行比较。如果CSA中包含的信息比接收服务器的缓存条目更新，那么缓存条目将相应地用CSA记录的内容更新。CSA记录中特定于客户机/服务器协议的部分针对每个协议单独记录。[8]和[9]分别显示了NHRP和ATMARP协议特定部分的示例。
The amount of information carried by a specific CSA record may exceed the size of a link layer PDU. Hence, such CSA records MUST be fragmented across a number of CSU Request messages. The method by which this is done, is client/server protocol specific and is documented in the appropriate protocol specific document.
特定CSA记录承载的信息量可能超过链路层PDU的大小。因此，此类CSA记录必须在多个CSU请求消息中分段。完成此操作的方法是特定于客户端/服务器协议的，并记录在相应的特定于协议的文档中。
The content of a CSA record is as follows:
CSA记录的内容如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client/Server Protocol Specific Part for cache entry ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client/Server Protocol Specific Part for cache entry ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CSAS Record See Section B.2.0.2 for rules and format for filling out a CSAS Record when it is "embedded" in a CSA Record.
当CSA记录“嵌入”在CSA记录中时，填写CSAS记录的规则和格式见第B.2.0.2节。
Client/Server Protocol Specific Part for cache entry This field contains the fields which are specific to the protocol specific portion of SCSP processing. The particular set of fields are defined in separate documents for each protocol user of SCSP. The Protocol ID, which identifies which protocol is using SCSP in the given packet, is located in the mandatory part of the message.
缓存条目的客户端/服务器协议特定部分此字段包含特定于SCSP处理的协议特定部分的字段。特定字段集在SCSP的每个协议用户的单独文档中定义。协议ID位于消息的强制部分，用于标识给定数据包中使用SCSP的协议。
The Cache State Update Reply (CSU Reply) message is sent from a DCS to an LS to acknowledge one or more CSA records which were received in a CSU Request. Reception of a CSA record in a CSU Request is acknowledged by including a CSAS record in the CSU Reply which corresponds to the CSA record being acknowledged. The CSU Reply message is the same in format as the CSU Request message except for the following: the type code is 3, only CSAS Records (rather than CSA records) are returned, and only those CSAS Records for which CSA Records are being acknowledged are returned. This implies that a given LS sending a CSU Request may not receive an acknowledgment in a single CSU Reply for all the CSA Records included in the CSU Request.
缓存状态更新回复（CSU回复）消息从DCS发送至LS，以确认CSU请求中收到的一个或多个CSA记录。CSU请求中CSA记录的接收通过在CSU回复中包含CSAS记录来确认，CSU回复对应于被确认的CSA记录。CSU回复消息的格式与CSU请求消息的格式相同，不同之处在于：类型代码为3，只返回CSA记录（而不是CSA记录），并且只返回CSA记录被确认的CSA记录。这意味着，对于CSU请求中包含的所有CSA记录，发送CSU请求的给定LS可能不会在单个CSU回复中收到确认。
This message allows one server (LS) to solicit the entirety of CSA record data stored in the cache of a directly connected server (DCS). The DCS responds with CSU Request messages containing the appropriate CSA records. The CSUS message type code is 4. The CSUS message format is the same as that of the CSU Reply message. CSUS messages solicit CSU Requests from only one server (the one identified by the Receiver ID in the Mandatory Part of the message).
此消息允许一台服务器（LS）请求存储在直接连接服务器（DCS）缓存中的全部CSA记录数据。DCS用包含适当CSA记录的CSU请求消息进行响应。CSU消息类型代码为4。CSU消息格式与CSU回复消息的格式相同。CSU消息仅从一台服务器（由消息强制部分中的接收方ID标识的服务器）请求CSU请求。
B.2.5 Hello:
B.2.5 你好：
The Hello message is used to check connectivity between the sending server (the LS) and one of its directly connected neighbor servers (the DCSs). The Hello message type code is 5. The Hello message mandatory part format is as follows:
Hello消息用于检查发送服务器（LS）与其一个直接连接的邻居服务器（DCS）之间的连接。Hello消息类型代码为5。Hello message强制部分格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | DeadFactor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Family ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Receiver ID Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Receiver ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | DeadFactor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Family ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Receiver ID Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Receiver ID Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval The hello interval advertises the time between sending of consecutive Hello Messages. If the LS does not receive a Hello message from the DCS (which contains the LSID as a Receiver ID) within the HelloInterval advertised by the DCS then the DCS's Hello is considered to be late. Also, the LS MUST send its own Hello message to a DCS within the HelloInterval which it advertised to the DCS in the LS's previous Hello message to that DCS (otherwise the DCS would consider the LS's Hello to be late).
HelloInterval hello interval播发发送连续hello消息之间的时间。如果LS在DCS播发的HelloInterval内未收到来自DCS的Hello消息（其中包含作为接收器ID的LSID），则DCS的Hello将被视为延迟。此外，LS必须将自己的Hello消息发送到HelLoad区间内的DCS，该广告在LS的以前的Hello消息中向DCS发布到DCS（否则DCS会考虑LS的Hello会晚点）。
DeadFactor This is a multiplier to the HelloInterval. If an LS does not receive a Hello message which contains the LS's LSID as a Receiver ID within the interval HelloInterval*DeadFactor from a given DCS, which advertised the HelloInterval and DeadFactor in a previous Hello message, then the LS MUST consider the DCS to be stalled; at this point, one of two things MUST happen: 1) if the LS has received any Hello messages from the DCS during this time then the LS transitions the corresponding HFSM to the Unidirectional State; otherwise, 2) the LS transitions the corresponding HFSM to the Waiting State.
DeadFactor这是HelloInterval的乘数。如果LS没有接收到一个hello消息，该消息包含LS的LSID作为一个接收者ID在一个给定的DCS的区间HelLoopkult*死区因子中，它在先前的hello消息中公告了HelLoad和死区因子，那么LS必须考虑DCS停止；此时，必须发生以下两种情况之一：1）如果LS在此期间收到来自DCS的任何Hello消息，则LS将相应的HFSM转换为单向状态；否则，2）LS将相应的HFSM转换为等待状态。
Family ID This is an opaque bit string which is used to refer to an aggregate of Protocol ID/SGID pairs. Only a single HFSM is run for all Protocol ID/SGID pairs assigned to a Family ID. Thus, there is a one to many mapping between the single HFSM and the CAFSMs corresponding to each of the Protocol ID/SGID pairs. This might have the net effect of substantially reducing HFSM maintenance traffic. See the protocol specific SCSP documents for further details.
Family ID这是一个不透明的位字符串，用于引用协议ID/SGID对的集合。对于分配给一个族ID的所有协议ID/SGID对，只运行一个HFSM。因此，单个HFSM和对应于每个协议ID/SGID对的CAFSM之间存在一对多映射。这可能具有显著减少HFSM维护流量的净效果。有关更多详细信息，请参阅特定于协议的SCSP文档。
Mandatory Common Part The mandatory common part is described in detail in Section B.2.0.1. There are two fields in the mandatory common part whose codings are specific to a given message type. These fields are the "Number of Records" field and the "Flags" field.
强制性公用部分第B.2.0.1节详细描述了强制性公用部分。强制公共部分中有两个字段，其编码特定于给定的消息类型。这些字段是“记录数”字段和“标志”字段。
Number of Records The Number of Records field of the mandatory common part for the Hello message contains the number of "Additional Receiver ID" records which are included in the Hello. Additional Receiver ID records contain a length field and a Receiver ID field. Note that the count in "Number of Records" does NOT include the Receiver ID which is included in the Mandatory Common Part.
记录数Hello消息的必填公共部分的记录数字段包含Hello消息中包含的“附加接收方ID”记录数。其他接收器ID记录包含长度字段和接收器ID字段。请注意，“记录数”中的计数不包括强制性公共部分中包含的接收方ID。
Flags Currently, there are no flags defined for the Flags field of the mandatory common part for the Hello message.
标志当前，没有为Hello消息的必需公共部分的标志字段定义标志。
All other fields of the mandatory common part are coded as described in Section B.2.0.1.
强制性公共部分的所有其他字段按照第B.2.0.1节所述进行编码。
Additional Receiver ID Record This record contains a length field followed by a Receiver ID. Since it is conceivable that the length of a given Receiver ID may vary even within an SG, each additional Receiver ID heard (beyond the first one) will have both its length in bytes and value encoded in an "Additional Receiver ID Record". Receiver IDs are IDs of a DCS from which the LS has heard a recent Hello (i.e., within DeadFactor*HelloInterval as advertised by the DCS in a previous Hello message).
附加接收器ID记录此记录包含一个长度字段，后跟一个接收器ID。由于可以想象，给定接收器ID的长度即使在SG内也可能不同，因此听到的每个附加接收器ID（第一个之外）都将以字节为单位的长度和编码在“附加接收器ID记录”中的值。接收方ID是DCS的ID，LS从中听到最近的Hello（即，在DCS在先前Hello消息中公布的DeadFactor*HelloInterval内）。
The format for this record is as follows:
该记录的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rec ID Len | Receiver ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rec ID Len | Receiver ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the LS has not heard from any DCS then the LS sets the Hello message fields as follows: Recvr ID Len is set to zero and no storage is allocated for the Receiver ID in the Common Mandatory Part, "Number of Records" is set to zero, and no storage is allocated for "Additional Receiver ID Records".
如果LS未收到任何DCS的通知，则LS将Hello消息字段设置如下：Recvr ID Len设置为零，且公共强制部分中的接收器ID未分配存储，“记录数”设置为零，且“其他接收器ID记录”未分配存储。
If the LS has heard from exactly one DCS then the LS sets the Hello message fields as follows: the Receiver ID of the DCS which was heard and the length of that Receiver ID are encoded in the Common Mandatory Part, "Number of Records" is set to zero, and no storage is allocated for "Additional Receiver ID Records".
如果LS只听到一个DCS，则LS将Hello消息字段设置如下：听到的DCS的接收器ID和接收器ID的长度编码在公共强制部分，“记录数”设置为零，并且没有为“其他接收器ID记录”分配存储。
If the LS has heard from two or more DCSs then the LS sets the Hello message fields as follows: the Receiver ID of the first DCS which was heard and the length of that Receiver ID are encoded in the Common Mandatory Part, "Number of Records" is set to the number of "Additional" DCSs heard, and for each additional DCS an "Additional Receiver ID Record" is formed and appended to the end of the Hello message.
如果LS已从两个或多个DCS听到，则LS将Hello消息字段设置如下：听到的第一个DC的接收器ID和接收器ID的长度编码在公共强制部分，“记录数”设置为听到的“附加”DCS的数量，并且对于每个附加DC“附加接收方ID记录”被形成并附加到Hello消息的末尾。
The Extensions Part, if present, carries one or more extensions in {Type, Length, Value} triplets.
扩展部分（如果存在）包含一个或多个{Type，Length，Value}三元组的扩展。
Extensions have the following format:
扩展具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type The extension type code (see below).
键入扩展类型代码（请参见下文）。
Length The length in octets of the value (not including the Type and Length fields; a null extension will have only an extension header and a length of zero).
Length值的长度（以八位字节为单位）（不包括Type和Length字段；空扩展名只有一个扩展名头和长度为零）。
When extensions exist, the extensions part is terminated by the End of Extensions extension, having Type = 0 and Length = 0.
存在扩展时，扩展部分在扩展的末尾终止，类型为0，长度为0。
Extensions may occur in any order but any particular extension type may occur only once in an SCSP packet. An LS MUST NOT change the order of extensions.
扩展可以以任何顺序出现，但任何特定的扩展类型在SCSP数据包中只能出现一次。LS不得更改扩展的顺序。
Type = 0 Length = 0
类型=0长度=0
When extensions exist, the extensions part is terminated by the End Of Extensions extension.
当存在扩展时，扩展部分在扩展结束时终止。
Type = 1 Length = variable
类型=1长度=变量
The SCSP Authentication Extension is carried in SCSP packets to convey the authentication information between an LS and a DCS in the same SG.
SCSP身份验证扩展在SCSP数据包中携带，用于在同一SG中的LS和DCS之间传输身份验证信息。
Authentication is done pairwise on an LS to DCS basis; i.e., the authentication extension is generated at each LS. If a received packet fails the authentication test then an "abnormal event" has occurred. The packet is discarded and this event is logged.
认证是在LS到DCS的基础上成对进行的；i、 例如，在每个LS处生成认证扩展。如果收到的数据包未通过身份验证测试，则发生“异常事件”。数据包将被丢弃，并记录此事件。
The presence or absence of authentication is a local matter.
认证的存在与否是一个局部问题。
The authentication header has the following format:
身份验证标头具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a table that maintains the keys and other information such as hash algorithm. LS and DCS communicate either off-line using manual keying or online using a key management protocol to populate this table. The receiving SCSP entity always allocates the SPI and the parameters associated with it.
安全参数索引（SPI）可以被认为是表的索引，该表维护键和其他信息，如哈希算法。LS和DCS使用手动键控进行离线通信，或使用密钥管理协议进行在线通信，以填充此表。接收SCSP实体始终分配SPI及其相关参数。
The authentication data field contains the MAC (Message Authentication Code) calculated over the entire SCSP payload. The length of this field is dependent on the hash algorithm used to calculate the MAC.
身份验证数据字段包含在整个SCSP有效负载上计算的MAC（消息身份验证代码）。此字段的长度取决于用于计算MAC的哈希算法。
The default hash algorithm to be supported is HMAC-MD5-128 [11]. HMAC is safer than normal keyed hashes. Other hash algorithms MAY be supported by def.
支持的默认哈希算法是HMAC-MD5-128[11]。HMAC比普通密钥散列更安全。def可能支持其他哈希算法。
IANA will assign the numbers to identify the algorithm being used as described in Section C.
IANA将分配编号，以识别第C节所述的正在使用的算法。
SPI's can be negotiated either manually or using an Internet Key Management protocol. Manual keying MUST be supported. The following parameters are associated with the tuple <SPI, DCS ID>- lifetime, Algorithm, Key. Lifetime indicates the duration in seconds for which
SPI可以手动协商，也可以使用Internet密钥管理协议协商。必须支持手动键控。以下参数与元组<SPI，DCS ID>-生存期、算法、密钥相关。生存期表示持续时间（以秒为单位）
the key is valid. In case of manual keying, this duration can be infinite. Also, in order to better support manual keying, there may be multiple tuples active at the same time (DCS ID being the same).
密钥是有效的。在手动键控的情况下，此持续时间可以是无限的。此外，为了更好地支持手动键控，可能同时有多个元组处于活动状态（DCS ID相同）。
Any Internet standard key management protocol MAY be used to negotiate the SPI and parameters.
任何互联网标准密钥管理协议都可用于协商SPI和参数。
At the time of adding the authentication extension header, LS looks up in a table to fetch the SPI and the security parameters based on the DCS ID. If there are no entries in the table and if there is support for key management, the LS initiates the key management protocol to fetch the necessary parameters. The LS then calculates the hash by zeroing authentication data field before calculating the MAC on the sending end. The result replaces in the zeroed authentication data field. If key management is not supported and authentication is mandatory, the packet is dropped and this information is logged.
在添加身份验证扩展标头时，LS在表中查找以根据DCS ID获取SPI和安全参数。如果表中没有条目并且支持密钥管理，则LS启动密钥管理协议以获取必要的参数。LS然后在计算发送端的MAC之前，通过将身份验证数据字段归零来计算哈希。结果替换为零身份验证数据字段中的值。如果不支持密钥管理且必须进行身份验证，则会丢弃数据包并记录此信息。
When receiving traffic, an LS fetches the parameters based on the SPI and its ID. The authentication data field is extracted before zeroing out to calculate the hash. It computes the hash on the entire payload and if the hash does not match, then an "abnormal event" has occurred.
当接收流量时，LS根据SPI及其ID获取参数。在清零以计算哈希之前提取身份验证数据字段。它计算整个有效负载上的哈希，如果哈希不匹配，则发生“异常事件”。
It is important that the keys chosen are strong as the security of the entire system depends on the keys being chosen properly and the correct implementation of the algorithms.
选择的密钥必须牢固，因为整个系统的安全性取决于正确选择的密钥和算法的正确实现。
SCSP has a peer to peer trust model. It is recommended to use an Internet standard key management protocol to negotiate the keys between the neighbors. Transmitting the keys in clear text, if other methods of negotiation is used, compromises the security completely.
SCSP具有对等信任模型。建议使用Internet标准密钥管理协议在邻居之间协商密钥。如果使用其他协商方法，以明文形式传输密钥将完全危及安全性。
Data integrity covers the entire SCSP payload. This guarantees that the message was not modified and the source is authenticated as well. If authentication extension is not used or if the security is compromised, then SCSP servers are liable to both spoofing attacks, active attacks and passive attacks.
数据完整性覆盖整个SCSP有效负载。这保证了消息没有被修改，并且源也经过了身份验证。如果未使用身份验证扩展或安全性受到损害，则SCSP服务器容易受到欺骗攻击、主动攻击和被动攻击。
There is no mechanism to encrypt the messages. It is assumed that a standard layer 3 confidentiality mechanism will be used to encrypt and decrypt messages. As integrity is calculated on an SCSP message
没有加密消息的机制。假定将使用标准的第3层保密机制对消息进行加密和解密。因为完整性是根据SCSP消息计算的
and not on each record, there is an implied trust between all the servers in a domain. It is recommend to use the security extension between all the servers in a domain and not just a subset servers.
而且不是在每个记录上，域中的所有服务器之间都存在隐含的信任。建议在域中的所有服务器之间使用安全扩展，而不仅仅是在服务器子集之间。
Any SCSP server is susceptible to Denial of Service (DOS) attacks. A rouge host can inundate its neighboring SCSP server with SCSP packets. However, if the authentication option is used, SCSP databases will not become corrupted, as the bogus packets will be discarded when the authentication check fails.
任何SCSP服务器都容易受到拒绝服务（DOS）攻击。rouge主机可以用SCSP数据包淹没其相邻的SCSP服务器。但是，如果使用身份验证选项，则SCSP数据库不会损坏，因为当身份验证检查失败时，虚假数据包将被丢弃。
Due to the pairwise authentication model of SCSP, the information received from any properly authenticated server is trusted and propagated throughout the server group. Consequently, if security of any SCSP server is compromised, the entire database becomes vulnerable to curruption originating from the compromised server.
由于SCSP的成对身份验证模型，从任何经过正确身份验证的服务器接收的信息都是可信的，并在整个服务器组中传播。因此，如果任何SCSP服务器的安全性受到损害，整个数据库都会容易受到来自受损服务器的中断的攻击。
Type = 2 Length = variable
类型=2长度=变量
The SCSP Vendor-Private Extension is carried in SCSP packets to convey vendor-private information between an LS and a DCS in the same SG and is thus of limited use. If a finer granularity (e.g., CSA record level) is desired then then given client/server protocol specific SCSP document MUST define such a mechanism. Obviously, however, such a protocol specific mechanism might look exactly like this extension. The Vendor Private Extension MAY NOT appear more than once in an SCSP packet for a given Vendor ID value.
SCSP供应商专用扩展在SCSP数据包中携带，用于在同一SG中的LS和DCS之间传输供应商专用信息，因此用途有限。如果需要更精细的粒度（例如CSA记录级别），则给定的特定于客户端/服务器协议的SCSP文档必须定义这种机制。然而，显然，这种特定于协议的机制可能与此扩展完全相同。对于给定的供应商ID值，供应商专用扩展不能在SCSP数据包中出现多次。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID 802 Vendor ID as assigned by the IEEE [7].
供应商ID 802由IEEE分配的供应商ID[7]。
Data The remaining octets after the Vendor ID in the payload are vendor-dependent data.
数据有效负载中供应商ID之后的剩余八位字节是供应商相关数据。
If the receiver does not handle this extension, or does not match the Vendor ID in the extension then the extension may be completely ignored by the receiver.
如果接收方不处理此扩展，或与扩展中的供应商ID不匹配，则接收方可能会完全忽略此扩展。
C. IANA Considerations
C.国际航空航天协会的考虑
Any and all requests for value assignment from the various number spaces described in this document require proper documentation. Possible forms of documentation include, but are not limited to, RFCs or the product of another cooperative standards body (e.g., the MPOA and LANE subworking group of the ATM Forum). Other requests may also be accepted, under the advice of a "designated expert". (Contact the IANA for the contact information of the current expert.)
本文件中描述的各种数字空间的任何和所有赋值请求都需要适当的文档。可能的文件形式包括但不限于RFC或其他合作标准机构（例如，ATM论坛的MPOA和LANE子工作组）的产品。在“指定专家”的建议下，也可接受其他请求。（有关当前专家的联系信息，请联系IANA。）
References
工具书类
[1] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", Laubach, RFC 2225, April 1998.
[1] Laubach，M.和J.Halpern，“ATM上的经典IP和ARP”，Laubach，RFC 2225，1998年4月。
[2] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[2] Luciani，J.，Katz，D.，Piscitello，D.，Cole，B.，和N.Doraswamy，“NMBA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[3] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[3] Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[4] "P-NNI V1", Dykeman, Goguen, 1996.
[4] “P-NNI V1”，达克曼，戈根，1996年。
[5] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[5] Armitage，G.“支持基于UNI 3.0/3.1的ATM网络上的多播”，RFC 2022，1996年11月。
[6] Keene, "LAN Emulation over ATM Version 2 - LNNI specification", btd-lane-lnni-02.08
[6] Keene，“ATM版本2上的局域网仿真-LNNI规范”，btd-lane-LNNI-02.08
[7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[7] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[8] Luciani, J., "A Distributed NHRP Service Using SCSP", RFC 2335, April 1998.
[8] Luciani，J.，“使用SCSP的分布式NHRP服务”，RFC 2335，1998年4月。
[9] Luciani, J., "A Distributed ATMARP Service Using SCSP", Work In Progress.
[9] Luciani，J.，“使用SCSP的分布式ATMARP服务”，正在进行中。
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[11] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[11] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
Acknowledgments
致谢
This memo is a distillation of issues raised during private discussions, on the IP-ATM mailing list, and during the Dallas IETF (12/95). Thanks to all who have contributed but particular thanks to following people (in no particular order): Barbara Fox of Harris and Jeffries; Colin Verrilli of IBM; Raj Nair, and Matthew Doar of Ascom Nexion; Andy Malis of Cascade; Andre Fredette of Bay Networks; James Watt of Newbridge; and Carl Marcinik of Fore.
本备忘录是对私下讨论、IP-ATM邮件列表和达拉斯IETF（1995年12月）期间提出的问题的总结。感谢所有做出贡献的人，但特别要感谢以下人员（不按特定顺序）：哈里斯和杰弗里斯的芭芭拉·福克斯；IBM的科林·维里利；Raj Nair和Ascom Nexion的Matthew Doar；卡斯克特的安迪·马利斯；海湾网络公司的安德烈·弗雷德特；新桥的詹姆斯·瓦特；还有Fore的Carl Marcinik。
Authors' Addresses
作者地址
James V. Luciani Bay Networks, Inc. 3 Federal Street, BL3-03 Billerica, MA 01821
詹姆斯诉卢西亚尼湾网络公司，马萨诸塞州比尔里卡联邦街3号，BL3-03，邮编01821
Phone: +1-978-916-4734
EMail: luciani@baynetworks.com
Phone: +1-978-916-4734
EMail: luciani@baynetworks.com
Grenville Armitage Bell Labs Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733
新泽西州霍尔德尔市克劳福德角路101号格伦维尔·阿米蒂奇·贝尔实验室朗讯科技公司07733
Phone: +1 201 829 2635
EMail: gja@lucent.com
Phone: +1 201 829 2635
EMail: gja@lucent.com
Joel M. Halpern Newbridge Networks Corp. 593 Herndon Parkway Herndon, VA 22070-5241
Joel M.Halpern Newbridge Networks Corp.弗吉尼亚州赫恩登公园路593号，邮编22070-5241
Phone: +1-703-708-5954
EMail: jhalpern@Newbridge.COM
Phone: +1-703-708-5954
EMail: jhalpern@Newbridge.COM
Naganand Doraswamy Bay Networks, Inc. 3 Federal St, BL3-03 Billerice, MA 01821
Naganand Doraswamy Bay Networks，Inc.马萨诸塞州比尔莱斯联邦街3号BL3-03邮编01821
Phone: +1-978-916-1323
EMail: naganand@baynetworks.com
Phone: +1-978-916-1323
EMail: naganand@baynetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。