Network Working Group                                            W. Zhao
Request for Comments: 3528                                H. Schulzrinne
Category: Experimental                               Columbia University
                                                              E. Guttman
                                                        Sun Microsystems
                                                              April 2003
        
Network Working Group                                            W. Zhao
Request for Comments: 3528                                H. Schulzrinne
Category: Experimental                               Columbia University
                                                              E. Guttman
                                                        Sun Microsystems
                                                              April 2003
        

Mesh-enhanced Service Location Protocol (mSLP)

网状增强服务定位协议(mSLP)

Status of this Memo

本备忘录的状况

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2003). All Rights Reserved.

版权所有(C)互联网协会(2003年)。版权所有。

Abstract

摘要

This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti-entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally.

本文档介绍Mesh增强服务位置协议(mSLP)。mSLP通过基于作用域的完全网状对等目录代理(DA)体系结构增强了服务位置协议(SLP)。对等DAs通过反熵和直接转发在共享范围内交换新的服务注册。mSLP提高了SLP DA服务的可靠性和一致性,简化了具有多个DA的系统中的服务代理(SA)注册。mSLP与SLPv2向后兼容,可以增量部署。

Table of Contents

目录

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Notation Conventions . . . . . . . . . . . . . . . . . .  2
       1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . .  3
       1.3.  Compatibility  . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope-based Fully-meshed Peering DA Architecture . . . . . . .  4
   3.  Peer Relationship Management . . . . . . . . . . . . . . . . .  6
       3.1.  Learning about New Peers . . . . . . . . . . . . . . . .  6
       3.2.  Establishing a Peering Connection  . . . . . . . . . . .  6
       3.3.  Exchanging Information about Existing Peers  . . . . . .  6
       3.4.  Maintaining a Peer Relationship  . . . . . . . . . . . .  7
       3.5.  Tearing Down a Peer Relationship . . . . . . . . . . . .  7
   4.  Registration Propagation Control . . . . . . . . . . . . . . .  7
       4.1.  Accept ID and Propagation Order  . . . . . . . . . . . .  7
       4.2.  Version Timestamp and Registration Version Resolution  .  8
        
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Notation Conventions . . . . . . . . . . . . . . . . . .  2
       1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . .  3
       1.3.  Compatibility  . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope-based Fully-meshed Peering DA Architecture . . . . . . .  4
   3.  Peer Relationship Management . . . . . . . . . . . . . . . . .  6
       3.1.  Learning about New Peers . . . . . . . . . . . . . . . .  6
       3.2.  Establishing a Peering Connection  . . . . . . . . . . .  6
       3.3.  Exchanging Information about Existing Peers  . . . . . .  6
       3.4.  Maintaining a Peer Relationship  . . . . . . . . . . . .  7
       3.5.  Tearing Down a Peer Relationship . . . . . . . . . . . .  7
   4.  Registration Propagation Control . . . . . . . . . . . . . . .  7
       4.1.  Accept ID and Propagation Order  . . . . . . . . . . . .  7
       4.2.  Version Timestamp and Registration Version Resolution  .  8
        
       4.3.  Mesh Forwarding Extension  . . . . . . . . . . . . . . .  8
       4.4.  Summary Vector . . . . . . . . . . . . . . . . . . . . .  9
       4.5.  Service Deregistration . . . . . . . . . . . . . . . . . 10
       4.6.  Anti-entropy Request Message . . . . . . . . . . . . . . 10
       4.7.  Anti-entropy . . . . . . . . . . . . . . . . . . . . . . 11
       4.8.  Direct Forwarding  . . . . . . . . . . . . . . . . . . . 11
       4.9.  SrvAck Message . . . . . . . . . . . . . . . . . . . . . 12
       4.10. Control Information  . . . . . . . . . . . . . . . . . . 12
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Protocol Timing Defaults . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       10.1. Normative References . . . . . . . . . . . . . . . . . . 13
       10.2. Informative References . . . . . . . . . . . . . . . . . 14
   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
        
       4.3.  Mesh Forwarding Extension  . . . . . . . . . . . . . . .  8
       4.4.  Summary Vector . . . . . . . . . . . . . . . . . . . . .  9
       4.5.  Service Deregistration . . . . . . . . . . . . . . . . . 10
       4.6.  Anti-entropy Request Message . . . . . . . . . . . . . . 10
       4.7.  Anti-entropy . . . . . . . . . . . . . . . . . . . . . . 11
       4.8.  Direct Forwarding  . . . . . . . . . . . . . . . . . . . 11
       4.9.  SrvAck Message . . . . . . . . . . . . . . . . . . . . . 12
       4.10. Control Information  . . . . . . . . . . . . . . . . . . 12
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Protocol Timing Defaults . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       10.1. Normative References . . . . . . . . . . . . . . . . . . 13
       10.2. Informative References . . . . . . . . . . . . . . . . . 14
   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
        
1. Introduction
1. 介绍

In the Service Location Protocol (SLPv2 [RFC2608]), Directory Agents (DAs) accept service registrations from Service Agents (SAs) and answer queries from User Agents (UAs); they enhance the performance and scalability of SLPv2. The use of scopes in SLPv2 further improves its scalability. In general, a DA can serve multiple scopes, and a scope can be served by multiple DAs. When multiple DAs are present for a scope, how should they interact with each other? This document describes the Mesh-enhanced Service Location Protocol (mSLP), addressing this open issue in SLPv2.

在服务位置协议(SLPv2[RFC2608])中,目录代理(DAs)接受来自服务代理(SA)的服务注册,并回答来自用户代理(UAs)的查询;它们增强了SLPv2的性能和可扩展性。SLPv2中作用域的使用进一步提高了其可伸缩性。通常,DA可以服务于多个作用域,并且一个作用域可以由多个DA服务。当一个作用域存在多个DA时,它们应该如何相互交互?本文档描述了Mesh增强服务位置协议(mSLP),解决了SLPv2中的这个开放问题。

mSLP defines a scope-based fully-meshed peering DA architecture: for each scope, all DAs serving the scope form a fully-meshed peer relationship (similar to IBGP [RFC1771]). Peer DAs exchange new service registrations in shared scopes via anti-entropy [EPID-ALGO,UPDA-PROP] and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies SA registrations in systems with multiple DAs.

mSLP定义了一个基于作用域的全网格对等DA体系结构:对于每个作用域,服务于该作用域的所有DA形成一个全网格对等关系(类似于IBGP[RFC1771])。对等DA通过反熵[EPID-ALGO,UPDA-PROP]和直接转发在共享范围内交换新的服务注册。mSLP提高了SLP DA服务的可靠性和一致性,并简化了具有多个DA的系统中的SA注册。

1.1. Notation Conventions
1.1. 符号约定

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。

1.2. Terminology
1.2. 术语

Peer DAs (or Peers) DAs that share one or multiple scopes are peers.

对等DAs(或对等)共享一个或多个作用域的DAs是对等的。

Peering Connection A persistent connection (e.g., TCP) that provides reliable and ordered transfers between two peers. The closing of a peering connection terminates the peer relationship.

对等连接在两个对等方之间提供可靠且有序传输的持久连接(如TCP)。对等连接的关闭终止对等关系。

Mesh-enhanced DA (MDA) An MDA carries the "mesh-enhanced" attribute keyword in its DA Advertisement (DAAdvert) message, maintains peering connections to all peers, and properly interacts with peers.

网状增强DA(MDA)MDA在其DA广告(DAAD)消息中携带“网状增强”属性关键字,维护与所有对等方的对等连接,并与对等方正确交互。

Mesh-enhanced SA (MSA) An MSA uses the Mesh Forwarding extension (Section 4.3) when it registers with MDAs.

网状增强SA(MSA)MSA在向MDA注册时使用网状转发扩展(第4.3节)。

Registration Update A registration update refers to a Service Registration (SrvReg) or Service Deregistration (SrvDeReg) message.

注册更新注册更新是指服务注册(SrvReg)或服务注销(SrvDeReg)消息。

Registration State A registration state refers to an entry in the registration database.

注册状态注册状态是指注册数据库中的条目。

Accept DA When a DA accepts a registration update from an SA, the DA is the accept DA for the update.

接受DA当DA接受SA的注册更新时,DA是更新的接受DA。

Accept Timestamp The arrival timestamp of a registration update at its accept DA is the accept timestamp of the update. All accept timestamps assigned by the same DA MUST be monotonically increasing.

Accept Timestamp注册更新在其Accept DA的到达时间戳是更新的Accept Timestamp。由同一DA分配的所有接受时间戳必须单调递增。

Version Timestamp When an MSA sends a registration update to an MDA, the MSA assigns a version timestamp to the update. All version timestamps assigned by the same MSA MUST be monotonically increasing.

版本时间戳当MSA向MDA发送注册更新时,MSA为更新分配版本时间戳。由同一MSA分配的所有版本时间戳必须单调递增。

1.3. Compatibility
1.3. 兼容性

mSLP is designed as a lightweight enhancement to SLPv2. It is backward compatible with SLPv2. mSLP defines two enhanced entities: MDAs and MSAs. They can be deployed incrementally. An enhanced entity supports extended operations without affecting its original functionality as defined in RFC 2608 [RFC2608]. For simplicity and

mSLP是作为SLPv2的轻量级增强而设计的。它与SLPv2向后兼容。mSLP定义了两个增强的实体:MDA和MSA。它们可以增量部署。增强实体支持扩展操作,而不影响RFC 2608[RFC2608]中定义的原始功能。为简便起见

compatibility, an enhanced entity works as a non-enhanced entity to interact with non-enhanced entities. Table 1 summarizes all interactions involving an MDA or MSA.

兼容性,增强实体作为非增强实体与非增强实体交互。表1总结了涉及MDA或MSA的所有交互。

            Interaction       Equivalent To     Defined In
            ----------------------------------------------
            MDA <--> MDA                           mSLP
            MDA <--> MSA                           mSLP
            MDA <--> DA        DA <--> DA        RFC 2608
            MDA <--> SA        DA <--> SA        RFC 2608
            MDA <--> UA        DA <--> UA        RFC 2608
            MSA <--> DA        SA <--> DA        RFC 2608
            MSA <--> UA        SA <--> UA        RFC 2608
        
            Interaction       Equivalent To     Defined In
            ----------------------------------------------
            MDA <--> MDA                           mSLP
            MDA <--> MSA                           mSLP
            MDA <--> DA        DA <--> DA        RFC 2608
            MDA <--> SA        DA <--> SA        RFC 2608
            MDA <--> UA        DA <--> UA        RFC 2608
            MSA <--> DA        SA <--> DA        RFC 2608
            MSA <--> UA        SA <--> UA        RFC 2608
        

Table 1. Interactions involving an MDA or MSA

表1。涉及MDA或MSA的交互作用

2. Scope-based Fully-meshed Peering DA Architecture
2. 基于作用域的全网格对等DA体系结构
                                 (x,y)
          +--------------------------------------------------+
          |                  +------------+                  |
          |                  |  MDA4 (z)  |                  |
          |                  +------------+                  |
          |                        | (z)                     |
   +------------+     (y)    +------------+     (y)    +------------+
   | MDA1 (x,y) | ---------- | MDA3 (y,z) | ---------- | MDA2 (x,y) |
   +------------+            +------------+            +------------+
        
                                 (x,y)
          +--------------------------------------------------+
          |                  +------------+                  |
          |                  |  MDA4 (z)  |                  |
          |                  +------------+                  |
          |                        | (z)                     |
   +------------+     (y)    +------------+     (y)    +------------+
   | MDA1 (x,y) | ---------- | MDA3 (y,z) | ---------- | MDA2 (x,y) |
   +------------+            +------------+            +------------+
        

Figure 1. A scope-based fully-meshed peering DA architecture

图1。一种基于作用域的全网格对等DA体系结构

mSLP employs a scope-based fully-meshed peering DA architecture. For each scope, all MDAs that serve the scope form a fully-meshed peer relationship. Figure 1 shows an example for four MDAs and three scopes (x, y, and z). Note that a single peering connection is needed between two peers for exchanging all service registrations in their shared scopes.

mSLP采用基于作用域的全网状对等DA体系结构。对于每个作用域,服务于该作用域的所有MDA都形成一个完全网状的对等关系。图1显示了四个MDA和三个作用域(x、y和z)的示例。请注意,两个对等方之间需要一个对等连接来交换其共享作用域中的所有服务注册。

This architecture enhances SLP DA services. First, it improves the consistency among peer DAs by automatically reconciling inconsistent states among them. Second, it enables newly booted and rebooted MDAs to catch up on all new registrations at once from their peers, purely through DA interaction, without involving SAs.

此体系结构增强了SLP DA服务。首先,它通过自动协调对等DAs之间的不一致状态来提高它们之间的一致性。其次,它使新启动和重新启动的MDA能够在不涉及SAs的情况下,纯粹通过DA交互,从其对等方一次赶上所有新注册。

This architecture also simplifies SA registrations. In SLPv2, an SA needs to discover and register with all existing DAs in its scopes, and re-register when new DAs are discovered or old DAs are found to have rebooted. In mSLP, for all MDAs, an MSA only needs to discover and register with a sufficient number of them, such that the union of

此体系结构还简化了SA注册。在SLPv2中,SA需要发现并向其作用域中的所有现有DAs注册,并在发现新DAs或发现旧DAs已重新启动时重新注册。在mSLP中,对于所有MDA,MSA只需要发现足够数量的MDA并向其注册,这样

their scopes covers its scopes; the registrations will then be propagated automatically to other MDAs in the registration scopes. For example, in Figure 2, MSA1 only needs to discover and register with MDA2, or with both MDA1 and MDA3.

他们的范围涵盖了它的范围;然后,注册将自动传播到注册范围中的其他MDA。例如,在图2中,MSA1只需要发现MDA2或同时使用MDA1和MDA3进行注册。

                 (option2)  +------------+  (option2)
         +----------------- | MSA1 (x,y) | -----------------+
         |                  +------------+                  |
         |                        | (option1)               |
         V                        V                         V
   +----------+             +------------+             +----------+
   | MDA1 (x) | ----------- | MDA2 (x,y) | ----------- | MDA3 (y) |
   +----------+             +------------+             +----------+
        
                 (option2)  +------------+  (option2)
         +----------------- | MSA1 (x,y) | -----------------+
         |                  +------------+                  |
         |                        | (option1)               |
         V                        V                         V
   +----------+             +------------+             +----------+
   | MDA1 (x) | ----------- | MDA2 (x,y) | ----------- | MDA3 (y) |
   +----------+             +------------+             +----------+
        

Figure 2. Options for registering with MDAs

图2。使用MDA注册的选项

Furthermore, this architecture provides scaling advantages. Consider a scope that has N SAs and M DAs, and assume N > M >= 2. Although mSLP and SLPv2 need the same number of SLP messages to distribute registrations from N SAs to M DAs, mSLP can reduce the number of agents needed for taking care of registration distribution, and reduce the number of TCP connections needed if each SA uses TCP for its registrations. More specifically, the agents that need to take care of registration distribution are all N SAs in SLPv2, but only M DAs in mSLP. Also, the number of needed TCP connections is N*M in SLPv2 as each SA has to connect with each DA and register, but only N+M*(M-1)/2 in mSLP as each SA only needs to connect to one contacting DA of a full mesh of M node and register, then registrations are propagated through the DA mesh. For N=100 and M=10, SLPv2 needs 1000 TCP connections, but mSLP only needs 145 such connections.

此外,该体系结构还提供了扩展优势。考虑具有n个SAS和M DAS的范围,假设n> m >=2。虽然mSLP和SLPv2需要相同数量的SLP消息来将注册从N SA分发到M DAs,但mSLP可以减少管理注册分发所需的代理数量,并减少每个SA使用TCP进行注册时所需的TCP连接数量。更具体地说,需要负责注册分发的代理在SLPv2中都是N SA,但在mSLP中只有M DAs。此外,在SLPv2中所需的TCP连接数为N*M,因为每个SA必须与每个DA连接并注册,但在mSLP中仅为N+M*(M-1)/2,因为每个SA只需要连接到M个节点的完整网格的一个接触DA并注册,然后注册通过DA网格传播。对于N=100和M=10,SLPv2需要1000个TCP连接,而mSLP只需要145个这样的连接。

Note that as mSLP employs full-mesh topology, which is mainly for simplicity and reliability, it cannot scale to a large number of MDAs in a single mesh. In general, mSLP can be applied if the number of MDAs in a mesh is on the order of tens or below. One way to avoid having a large number of MDAs in a mesh is to split the scope into several finer scopes. For example, if we have N MDAs for scope "x", and N is too large, then we can split "x" into two finer scopes: "x-1" and "x-2", with N1 MDAs for "x-1" only, N2 MDAs for "x-2" only, N3 MDAs for both "x-1" and "x-2", and N1+N2+N3=N. Thus, instead of having a large full mesh of size N, we now have two smaller full meshes of size N1+N3 and N2+N3, respectively. Accordingly, a service registration that previously targets for scope "x", now needs to be registered under both "x-1" and "x-2".

请注意,由于mSLP采用全网格拓扑(主要是为了简单性和可靠性),因此它无法在单个网格中扩展到大量MDA。通常,如果网格中的MDA数量在十个或以下,则可以应用mSLP。避免网格中存在大量MDA的一种方法是将作用域拆分为几个更精细的作用域。例如,如果作用域“x”有N个MDA,而N太大,那么我们可以将“x”分为两个更细的作用域:“x-1”和“x-2”,其中N1个MDA仅用于“x-1”,N2个MDA仅用于“x-2”,N3个MDA同时用于“x-1”和“x-2”,N1+N2+N3=N。因此,我们现在不再具有大小为N的大型完整网格,而是具有大小为N1+N3和N2+N3的两个较小完整网格,分别地因此,以前针对作用域“x”的服务注册现在需要同时在“x-1”和“x-2”下注册。

3. Peer Relationship Management
3. 同伴关系管理
3.1. Learning about New Peers
3.1. 了解新同事

An MDA can learn about new peers via static configuration, DHCP [RFC2610], and DAAdvert multicast and unicast. In any case, an MDA MUST get a peer's DAAdvert before establishing a peer relationship to the peer.

MDA可以通过静态配置、DHCP[RFC2610]和DAAD多播和单播了解新的对等点。在任何情况下,MDA必须在与对等方建立对等关系之前获得对等方的DAAD。

3.2. Establishing a Peering Connection
3.2. 建立对等连接

After getting a new peer's DAAdvert, an MDA establishes a peering connection (if such a connection does not exist yet) to the peer, and sends its DAAdvert via the connection (Figure 3). An MDA can identify a peering connection initiated by a peer by receiving the peer's DAAdvert from the connection. Normally, a single peering connection is set up between two peers, but there is a small possibility that a pair of peering connections might be created between two peers if they try to initiate a connection to each other at almost the same time. Thus, when an MDA identifies a new peering connection initiated by a peer, it SHOULD check whether it has initiated another peering connection to the peer. If this is the case, and it has a lower-numbered IP address than the peer, then the MDA SHOULD terminate the connection it has initiated.

在获得一个新的对等方的DAAdvert后,MDA建立一个对等连接(如果这样的连接还不存在)到该对等方,并通过该连接发送其DAAdvert(图3)。MDA可以通过从连接接收对等方的数据广告来识别由对等方发起的对等连接。通常,在两个对等方之间建立一个对等连接,但如果两个对等方几乎同时尝试启动彼此的连接,则在两个对等方之间创建一对对等连接的可能性很小。因此,当MDA识别出一个由对等方发起的新对等连接时,它应该检查是否已经发起了另一个到对等方的对等连接。如果是这种情况,并且其IP地址的编号低于对等方,则MDA应终止其启动的连接。

      +------+    (1) MDA2's DAAdvert |                 +------+
      |      | <----------------------+                 |      |
      | MDA1 |    (2) Create a Peering Connection       | MDA2 |
      |      | ---------------------------------------> |      |
      +------+    (3) MDA1's DAAdvert                   +------+
        
      +------+    (1) MDA2's DAAdvert |                 +------+
      |      | <----------------------+                 |      |
      | MDA1 |    (2) Create a Peering Connection       | MDA2 |
      |      | ---------------------------------------> |      |
      +------+    (3) MDA1's DAAdvert                   +------+
        

Figure 3. Establishing a peering connection

图3。建立对等连接

3.3. Exchanging Information about Existing Peers
3.3. 交换关于现有对等点的信息

After establishing a peering connection, two peers (say, MDA1 and MDA2) exchange information about their existing peers by forwarding peers' DAAdverts via the peering connection (Figure 4). MDA1 will forward the DAAdvert of a peer (say, MDA3) to MDA2 if:

建立对等连接后,两个对等方(例如,MDA1和MDA2)通过对等连接转发对等方的DAAD来交换关于其现有对等方的信息(图4)。如果出现以下情况,MDA1将向MDA2转发对等方的数据广告(如MDA3):

(1) MDA3 shares scopes with MDA2, and (2) MDA3 is an active peer of MDA1 (i.e., there is a peering connection between MDA3 and MDA1) or an accept DA for registrations currently maintained by MDA1 (i.e., MDA1 has registrations originally accepted by MDA3).

(1) MDA3与MDA2共享作用域,(2)MDA3是MDA1的活动对等方(即,MDA3和MDA1之间存在对等连接)或接受当前由MDA1维护的注册的DA(即,MDA1具有最初由MDA3接受的注册)。

MDA2 operates similarly. Note that all DAAdverts can be sent as one TCP stream for efficiency. Exchanging information about existing peers enables an MDA to learn about new peers incrementally.

MDA2的工作原理类似。请注意,为了提高效率,所有DAAD都可以作为一个TCP流发送。交换关于现有对等点的信息使MDA能够增量地了解新对等点。

      +------+      DAAdverts of MDA1's existing peers     +------+
      |      | ------------------------------------------> |      |
      | MDA1 |             (Peering Connection)            | MDA2 |
      |      | <------------------------------------------ |      |
      +------+      DAAdverts of MDA2's existing peers     +------+
        
      +------+      DAAdverts of MDA1's existing peers     +------+
      |      | ------------------------------------------> |      |
      | MDA1 |             (Peering Connection)            | MDA2 |
      |      | <------------------------------------------ |      |
      +------+      DAAdverts of MDA2's existing peers     +------+
        

Figure 4. Exchanging information about existing peers

图4。交换关于现有对等点的信息

3.4. Maintaining a Peer Relationship
3.4. 维持同伴关系
      +------+              MDA1's DAAdvert             +------+
      |      | ---------------------------------------> |      |
      | MDA1 |           (Peering Connection)           | MDA2 |
      |      | <--------------------------------------- |      |
      +------+              MDA2's DAAdvert             +------+
        
      +------+              MDA1's DAAdvert             +------+
      |      | ---------------------------------------> |      |
      | MDA1 |           (Peering Connection)           | MDA2 |
      |      | <--------------------------------------- |      |
      +------+              MDA2's DAAdvert             +------+
        

Figure 5. Maintaining a peer relationship

图5。维持同伴关系

To detect failures (network partitions and peer crashes), mSLP uses a heart-beat mechanism. An MDA sends its DAAdvert to peers (Figure 5) every CONFIG_DA_KEEPALIVE seconds. The timeout value for this message is CONFIG_DA_TIMEOUT seconds (Section 6).

为了检测故障(网络分区和对等崩溃),mSLP使用心跳机制。MDA每配置一秒就向对等方发送一次数据广告(图5)。此消息的超时值为CONFIG_DA_timeout seconds(第6节)。

3.5. Tearing Down a Peer Relationship
3.5. 撕毁同伴关系

An MDA SHOULD tear down a peer relationship when it finds that the peer has closed the peering connection, when it receives a DAAdvert multicast from the peer with a DA stateless boot timestamp set to 0 (meaning that the peer is going to shutdown), or when it has not received the peer's DAAdvert for more than CONFIG_DA_TIMEOUT seconds.

当MDA发现对等方已关闭对等连接、从对等方接收到DAAD多播且DA无状态启动时间戳设置为0(意味着对等方将关闭)时,或者当MDA在超过配置DAU超时秒的时间内未接收到对等方的DAAD时,MDA应断开对等方关系。

4. Registration Propagation Control
4. 注册传播控制
4.1. Accept ID and Propagation Order
4.1. 接受ID和传播顺序

When an MDA accepts a registration update from an MSA, the MDA assigns a unique accept ID to the update. An accept ID has two components: an accept DA URL and an accept timestamp. The accept timestamp is a 64-bit integer representing elapsed microseconds since 00:00 Coordinated Universal Time (UTC), January 1, 1900. Figure 6 shows the format for an accept ID entry. A registration state has the same accept ID as that of the latest update applied to it.

当MDA接受来自MSA的注册更新时,MDA将为更新分配唯一的接受ID。accept ID有两个组件:accept DA URL和accept时间戳。接受时间戳是一个64位整数,表示自1900年1月1日00:00协调世界时(UTC)以来经过的微秒数。图6显示了accept ID条目的格式。注册状态具有与应用于它的最新更新相同的接受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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Accept Timestamp                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Accept Timestamp, cont'd.              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Length of Accept DA URL    |         Accept DA URL         \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Accept Timestamp                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Accept Timestamp, cont'd.              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Length of Accept DA URL    |         Accept DA URL         \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 6. Accept ID entry

图6。接受ID输入

An MDA MUST propagate registrations in the increasing order of their accept IDs, i.e., registrations having the same accept DA MUST be propagated in the increasing order of their accept timestamps. Note that registrations having different accept DAs MAY be propagated in any order.

MDA必须以接受ID的递增顺序传播注册,即具有相同接受DA的注册必须以接受时间戳的递增顺序传播。请注意,具有不同accept DA的注册可以以任何顺序传播。

4.2. Version Timestamp and Registration Version Resolution
4.2. 版本时间戳和注册版本解析

When registrations are propagated among MDAs, their arrival timestamps at MDAs cannot be used for version resolution. For example, assume that MSA1 sends a registration (R1) to MDA1 first, and a new version of the same registration (R2) to MDA2 later. When R1 and R2 are propagated, the arrival timestamp of R1 at MDA2 is later than that of R2, but R1 SHOULD NOT overwrite R2 at MDA2 as R2 is a newer version.

当注册在MDA之间传播时,它们在MDA处的到达时间戳不能用于版本解析。例如,假设MSA1首先向MDA1发送注册(R1),然后向MDA2发送同一注册的新版本(R2)。在传播R1和R2时,R1在MDA2处的到达时间戳晚于R2,但R1不应覆盖MDA2处的R2,因为R2是较新版本。

mSLP resolves registration versions using version timestamps. When an MSA sends a registration update to an MDA, the MSA assigns a version timestamp to the update. The version timestamp is a 64-bit integer representing elapsed microseconds since 00:00 UTC, January 1, 1900. mSLP assumes that each registration is updated only by one SA, thus an MDA does not need to compare version timestamps from different MSAs. An MDA installs a registration update if the update has a newer version timestamp (from an MSA), or the update does not have the Mesh Forwarding extension (from a non-MSA).

mSLP使用版本时间戳解析注册版本。当MSA向MDA发送注册更新时,MSA为更新分配版本时间戳。版本时间戳是一个64位整数,表示自1900年1月1日UTC 00:00以来经过的微秒数。mSLP假设每个注册仅由一个SA更新,因此MDA不需要比较来自不同MSA的版本时间戳。如果更新具有较新版本的时间戳(来自MSA),或者更新没有网状转发扩展(来自非MSA),MDA将安装注册更新。

4.3. Mesh Forwarding Extension
4.3. 网状转发扩展

The Mesh Forwarding (MeshFwd) extension carries a version timestamp and an accept ID entry. Figure 7 shows its format and two defined Forwarding IDs (Fwd-IDs).

网状转发(MeshFwd)扩展带有版本时间戳和接受ID条目。图7显示了它的格式和两个定义的转发ID(Fwd ID)。

The MeshFwd extension is used with a Srv(De)Reg message, but it can only be used with a fresh SrvReg, or a complete SrvDeReg.

MeshFwd扩展与Srv(De)Reg消息一起使用,但它只能与新的SrvReg或完整的SrvDeReg一起使用。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MeshFwd Extension ID = 0x0006 |  Next Extension Offset (NEO)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | NEO, cont'd.  |     Fwd-ID    |       Version Timestamp       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Version Timestamp, cont'd.                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Version Timestamp, cont'd.  |       Accept ID 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | MeshFwd Extension ID = 0x0006 |  Next Extension Offset (NEO)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | NEO, cont'd.  |     Fwd-ID    |       Version Timestamp       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Version Timestamp, cont'd.                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Version Timestamp, cont'd.  |       Accept ID Entry         \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Fwd-ID Abbreviation 1 RqstFwd 2 Fwded

Fwd ID缩写1 RqstFwd 2 Fwd

Figure 7. MeshFwd extension and its Fwd-IDs

图7。MeshFwd扩展及其Fwd-id

An MSA uses the RqstFwd MeshFwd extension (Fwd-ID = RqstFwd, accept timestamp = 0) in a Srv(De)Reg to explicitly request an MDA (the accept DA) to forward the message.

MSA使用Srv(De)Reg中的RqstFwd MeshFwd扩展(Fwd ID=RqstFwd,accept timestamp=0)显式请求MDA(accept DA)转发消息。

An MDA uses the Fwded MeshFwd extension (Fwd-ID = Fwded, accept timestamp != 0) in each Srv(De)Reg sent from it to another MDA, either forwarding a Srv(De)Reg received from an MSA (if the message has the RqstFwd MeshFwd extension), or propagating a registration state in its database.

MDA在从它发送到另一个MDA的每个Srv(De)Reg中使用Fwded MeshFwd扩展名(Fwd ID=Fwded,accept timestamp!=0),或者转发从MSA接收的Srv(De)Reg(如果消息具有RqstFwd MeshFwd扩展名),或者在其数据库中传播注册状态。

4.4. Summary Vector
4.4. 摘要向量

An MDA uses a summary vector to represent its received Srv(De)Reg(s) that have a MeshFwd extension. This summary vector records the latest accept timestamp for each accept DA that appears in the MeshFwd extension. For example, consider n MDAs for a scope, if MDAi has a summary vector as ((MDA1, T1), (MDA2, T2), ..., (MDAn, Tn)), then MDAi has received all registrations originally accepted by MDAj up to timestamp Tj, where 1<=i,j<=n.

MDA使用摘要向量来表示其接收到的具有MeshFwd扩展名的Srv(De)Reg。此摘要向量记录出现在MeshFwd扩展中的每个accept DA的最新accept时间戳。例如,考虑一个范围的N MDAs,如果MDAi有一个摘要向量为((MDA1,T1),(MDA2,T2),…,(M丹,Tn)),那么MDAi已经接收到最初由MDAJ接受的所有注册到时间戳Tj,其中1 <= i,j <n。

An MDA updates its summary vector when it receives a Srv(De)Reg that has a MeshFwd extension. The MDA adds a new accept ID to its summary vector if the Srv(De)Reg has a new accept DA; the MDA updates the accept timestamp of an existing accept ID in its summary vector if the Srv(De)Reg has an existing accept DA.

MDA在收到具有MeshFwd扩展名的Srv(De)Reg时更新其摘要向量。如果Srv(De)Reg有一个新的accept DA,MDA会向其摘要向量添加一个新的accept ID;如果Srv(De)Reg具有现有的accept DA,MDA将更新其摘要向量中现有accept ID的accept时间戳。

4.5. Service Deregistration
4.5. 撤销服务注册

When an MDA receives a SrvDeReg that has a MeshFwd extension, it SHOULD retain the corresponding registration in the database, and mark it as deleted. This way, the registration will not appear in any query reply, and an earlier SrvReg will not mistakenly cause the registration to reappear in the database. A registration state will be purged from the database when it expires.

当MDA接收到具有MeshFwd扩展名的SrvDeReg时,它应该在数据库中保留相应的注册,并将其标记为已删除。这样,注册将不会出现在任何查询回复中,并且早期的SrvReg不会错误地导致注册重新出现在数据库中。注册状态过期时将从数据库中清除。

4.6. Anti-entropy Request Message
4.6. 反熵请求消息

The Anti-entropy Request (AntiEtrpRqst) message carries an anti-entropy type ID and a list of accept ID entries. Figure 8 shows its format and two defined anti-entropy type IDs.

反熵请求(antiterprqst)消息包含一个反熵类型ID和一个接受ID条目列表。图8显示了它的格式和两个定义的反熵类型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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Service Location Header (AntiEtrpRqst Function-ID =  12)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Anti-Entropy Type ID     |  Number of Accept ID Entries  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Accept ID Entry 1         . . .         Accept ID Entry k   \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Service Location Header (AntiEtrpRqst Function-ID =  12)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Anti-Entropy Type ID     |  Number of Accept ID Entries  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Accept ID Entry 1         . . .         Accept ID Entry k   \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Anti-Entropy Type Type ID selective 1 complete 2

反熵类型ID选择1完整2

Figure 8. AntiEtrpRqst message and anti-entropy types

图8。反ETRPRQST消息和反熵类型

The AntiEtrpRqst message is used by an MDA to request new registration states from a peer. The anti-entropy type is either selective or complete. If the anti-entropy type is selective, only registration states that have an accept ID greater than any specified accept ID in the message are requested. If the anti-entropy type is complete, all registration states that have an accept ID greater than any specified accept ID in the message or have an accept DA not specified in the message are requested.

MDA使用AntiEtrpRqst消息从对等方请求新的注册状态。反熵类型要么是选择性的,要么是完全的。如果反熵类型是选择性的,则只请求接受ID大于消息中任何指定接受ID的注册状态。如果反熵类型已完成,则将请求接受ID大于消息中任何指定接受ID或消息中未指定接受DA的所有注册状态。

For example, consider three MDAs (MDA1, MDA2, and MDA3) for a scope. MDA2 has registration states originally accepted by MDA1, MDA2, and MDA3. If MDA1 sends a selective AntiEtrpRqst to MDA2 using an accept ID list as ((MDA2, T2)), then MDA1 only requests registration states that are originally accepted by MDA2, and have an accept timestamp greater than T2. If MDA1 sends a complete AntiEtrpRqst to MDA2 using an accept ID list as ((MDA2, T2)), then MDA1 requests all

例如,对于一个作用域,考虑三个MDAs(MDA1、MDA2和MDA3)。MDA2具有MDA1、MDA2和MDA3最初接受的注册状态。如果MDA1使用接受ID列表((MDA2,T2))向MDA2发送选择性AntiEtrpRqst,则MDA1仅请求MDA2最初接受的注册状态,且接受时间戳大于T2。如果MDA1使用接受ID列表((MDA2,T2))向MDA2发送完整的AntiEtrpRqst,则MDA1请求所有

registration states originally accepted by MDA1 and MDA3, plus those originally accepted by MDA2 and having an accept timestamp greater than T2.

MDA1和MDA3最初接受的注册状态,加上MDA2最初接受并具有大于T2的接受时间戳的注册状态。

4.7. Anti-entropy
4.7. 反熵

Anti-entropy is used for exchanging initial registration states when two peers recognize each other for the first time, and for updating new registration states after failures.

反熵用于当两个对等点第一次相互识别时交换初始注册状态,以及在失败后更新新的注册状态。

When an MDA receives an AntiEtrpRqst from a peer, it sends the requested new registration states in the increasing order of their accept IDs. At last a Service Acknowledgment (SrvAck) message is sent to indicate that the processing of a corresponding AntiEtrpRqst has been completed (Figure 9). A new registration state is sent as a fresh SrvReg with its remaining lifetime. A newly deregistered state is propagated as a SrvDeReg. Note that multiple Srv(De)Reg(s) can be sent as one TCP stream for efficiency.

当MDA从对等方接收到AntiEtrpRqst时,它会按照其accept ID的递增顺序发送请求的新注册状态。最后,将发送一条服务确认(SrvAck)消息,以指示相应AntiEtrpRqst的处理已完成(图9)。新的注册状态将作为剩余生存期的新SrvReg发送。新注销的状态作为SrvDeReg进行传播。请注意,为了提高效率,可以将多个Srv(De)Reg作为一个TCP流发送。

      +------+                AntiEtrpRqst                  +------+
      |      | -------------------------------------------> |      |
      | MDA1 |            (Peering Connection)              | MDA2 |
      |      | <------------------------------------------- |      |
      +------+     New States via Srv(De)Reg(s) + SrvAck    +------+
        
      +------+                AntiEtrpRqst                  +------+
      |      | -------------------------------------------> |      |
      | MDA1 |            (Peering Connection)              | MDA2 |
      |      | <------------------------------------------- |      |
      +------+     New States via Srv(De)Reg(s) + SrvAck    +------+
        

Figure 9. Anti-entropy via AntiEtrpRqst, Srv(De)Reg(s) and SrvAck

图9。通过反ETRPRQST、Srv(De)Reg(s)和SrvAck实现反熵

4.8. Direct Forwarding
4.8. 直接转发
+------+   RqstFwd Srv(De)Reg   +------+   Fwded Srv(De)Reg    +------+
|      | ---------------------> |      | --------------------> |      |
| MSA1 |                        | MDA1 |                       | MDA2 |
|      | <--------------------- |      |                       |      |
+------+         SrvAck         +------+                       +------+
        
+------+   RqstFwd Srv(De)Reg   +------+   Fwded Srv(De)Reg    +------+
|      | ---------------------> |      | --------------------> |      |
| MSA1 |                        | MDA1 |                       | MDA2 |
|      | <--------------------- |      |                       |      |
+------+         SrvAck         +------+                       +------+
        

Figure 10. Direct forwarding of a Srv(De)Reg

图10。直接转发Srv(De)Reg

After sending all new registration states accepted by itself to a peer (via anti-entropy), an MDA directly forwards newly received registration updates from MSAs to the peer until a failure occurs.

在将自己接受的所有新注册状态发送给对等方(通过反熵)之后,MDA直接将新收到的注册更新从MSA转发给对等方,直到发生故障。

In Figure 10, when a Srv(De)Reg is directly forwarded from MDA1 to MDA2, its Fwd-ID is set to Fwded, and its accept timestamp is set to its arrival timestamp at MDA1. Note that a direct forwarding is performed asynchronously: MDA1 can send a SrvAck to MSA1 before it forwards the Srv(De)Reg to MDA2. Also note that the direct forwarding of a Srv(De)Reg goes only one-hop from its accept DA (say, MDA1) to all MDA1's peers that are in the registration scopes.

在图10中,当Srv(De)Reg直接从MDA1转发到MDA2时,其Fwd ID设置为Fwded,其接受时间戳设置为MDA1处的到达时间戳。请注意,直接转发是异步执行的:MDA1可以在将Srv(De)Reg转发给MDA2之前向MSA1发送SrvAck。还请注意,Srv(De)Reg的直接转发仅从其accept DA(例如,MDA1)到注册范围内的所有MDA1对等方一跳。

4.9. SrvAck Message
4.9. SrvAck消息

According to [RFC2608], a DA MUST reply with a SrvAck to a Srv(De)Reg when the message is received from an SA. However, an MDA SHOULD NOT reply with a SrvAck to a Srv(De)Reg if the message is received from a peer. This is for efficiency because peers exchange Srv(De)Reg messages via reliable peering connections. Note that an MDA MUST reply with a SrvAck to an AntiEtrpRqst.

根据[RFC2608],当从SA收到消息时,DA必须使用SrvAck回复Srv(De)Reg。但是,如果从对等方收到消息,MDA不应使用SrvAck回复Srv(De)Reg。这是为了提高效率,因为对等方通过可靠的对等连接交换Srv(De)Reg消息。注意,MDA必须用SrvAck回复AntiEtrpRqst。

4.10. Control Information
4.10. 控制信息

For each registration entry, an MDA maintains the following control information: an accept ID (for registration propagation), a version timestamp (for registration version resolution - rejecting previous updates), and a deletion flag (deregistered or not).

对于每个注册条目,MDA维护以下控制信息:接受ID(用于注册传播)、版本时间戳(用于注册版本解析-拒绝以前的更新)和删除标志(是否注销)。

For all registration entries, an MDA maintains a summary vector to reflect its received registrations so far.

对于所有注册条目,MDA维护一个摘要向量,以反映到目前为止收到的注册。

5. Summary
5. 总结

mSLP extends SLPv2 with three new definitions: a new attribute - "mesh-enhanced" for DAAdvert, a new message extension - MeshFwd, and a new message type - AntiEtrpRqst.

mSLP使用三个新定义扩展了SLPv2:一个新属性“mesh enhanced”,用于DAAD,一个新消息扩展-MeshFwd,以及一个新消息类型-AntiEtrpRqst。

A UA MAY prefer an MDA to a non-MDA since an MDA is more likely to reliably contain the complete set of current service registrations for the UA's scopes.

UA可能更喜欢MDA而不是非MDA,因为MDA更可能可靠地包含UA作用域的当前服务注册的完整集合。

A non-MSA needs to discover and register with all DAs in its scopes. It does not use the MeshFwd extension.

非MSA需要发现其作用域中的所有DAs并向其注册。它不使用MeshFwd扩展。

A non-MDA accepts Srv(De)Reg(s) from SAs. It does not forward them.

非MDA从SAs接受Srv(De)Reg。它不转发它们。

For all MDAs, an MSA only needs to discover and register with sufficient number of them, such that they cover its scopes. It uses the MeshFwd extension when it registers with MDAs.

对于所有的MDA,MSA只需要发现并注册足够数量的MDA,以便它们覆盖其范围。当它向mda注册时,它使用MeshFwd扩展。

An MDA carries the "mesh-enhanced" attribute keyword in its DAAdvert. It maintains a peer relationship to each peer. It accepts registrations from SAs and peers, propagates registrations via anti-entropy and direct forwarding to peers.

MDA在其DAAD中包含“网格增强”属性关键字。它与每个对等体保持对等关系。它接受SA和对等方的注册,通过反熵传播注册,并直接转发给对等方。

6. Protocol Timing Defaults
6. 协议定时默认值
     Interval Name          Default Value      Defined in
   -------------------      -------------      -----------
   CONFIG_DA_KEEPALIVE       200 seconds       Section 3.4
   CONFIG_DA_TIMEOUT         300 seconds       Section 3.4
        
     Interval Name          Default Value      Defined in
   -------------------      -------------      -----------
   CONFIG_DA_KEEPALIVE       200 seconds       Section 3.4
   CONFIG_DA_TIMEOUT         300 seconds       Section 3.4
        
7. IANA Considerations
7. IANA考虑

The Mesh Forwarding (MeshFwd) extension ID, 0x0006, described in Section 4.3, has been assigned by IANA out of the SLP extension space (RFC 2608, Section 9.1) reserved for "optional to implement" extensions (i.e., the 0x0000-0x3FFF range).

第4.3节中描述的网状转发(MeshFwd)扩展ID 0x0006已由IANA从SLP扩展空间(RFC 2608,第9.1节)中分配,该扩展空间是为“可选实现”扩展(即0x0000-0x3FFF范围)保留的。

The function-ID of the Anti-entropy Request (AntiEtrpRqst) message type, 12, described in Section 4.6, has been assigned by IANA (RFC 2608, Section 15).

IANA(RFC 2608,第15节)已分配了第4.6节中描述的反熵请求(AntietTPRQST)消息类型12的功能ID。

8. Security Considerations
8. 安全考虑

mSLP uses standard SLPv2 authentication. First, an MDA SHOULD authenticate other MDAs before setting up a peer relationship with them so as to prevent any malicious MDA from joining the DA mesh. Second, as a successful attack at an MDA may affect all MDAs in the DA mesh, an MDA SHOULD authenticate MSAs before accepting and forwarding their Srv(De)Reg messages to prevent illegitimate modification or elimination of service registrations. Third, as an MSA depends on the MDA with which it registers to forward its Srv(De)Reg messages, it SHOULD authenticate the MDA to avoid using a malicious MDA.

mSLP使用标准的SLPv2身份验证。首先,MDA应在与其他MDA建立对等关系之前对其进行身份验证,以防止任何恶意MDA加入DA网格。其次,由于对MDA的成功攻击可能会影响DA mesh中的所有MDA,MDA应在接受和转发其Srv(De)Reg消息之前对MSA进行身份验证,以防止非法修改或消除服务注册。第三,由于MSA依赖于其注册以转发其Srv(De)Reg消息的MDA,因此它应该验证MDA以避免使用恶意MDA。

9. Acknowledgments
9. 致谢

Thomas Narten, James Kempf, Mike Day, Mikael Pahmp, Ira McDonald, Qiaobing Xie and Xingang Guo provided valuable comments for this document.

Thomas Narten、James Kempf、Mike Day、Mikael Pahmp、Ira McDonald、谢乔冰和郭新刚为本文件提供了宝贵的意见。

10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.

[RFC2608]Guttman,E.,Perkins,C.,Veizades,J.和M.Day,“服务位置协议,版本2”,RFC 26081999年6月。

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

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

10.2. Informative References
10.2. 资料性引用

[RFC1771] Rekhter, R. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.

[RFC1771]Rekhter,R.和T.Li,“边境网关协议4(BGP-4)”,RFC 17711995年3月。

[RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June, 1999.

[RFC2610]Perkins,C.和E.Guttman,“服务位置协议的DHCP选项”,RFC 2610,1999年6月。

[EPID-ALGO] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D. Swinehart and D. Terry, "Epidemic algorithms for replicated database maintenance", the sixth ACM symposium on principles of distributed computing, Vancouver, Canada, 1987.

[EPID-ALGO]A.Demers,D.Greene,C.Hauser,W.Irish,J.Larson,S.Shenker,H.Sturgis,D.Swinehart和D.Terry,“复制数据库维护的流行算法”,第六届ACM分布式计算原理研讨会,加拿大温哥华,1987年。

[UPDA-PROP] K. Petersen, M. Spreizer, D. Terry, M. Theimer and A. Demers, "Flexible update propagation for weakly consistent replication", the sixteenth ACM symposium on operating systems principles, Saint Malo, France, 1997.

[UPDA-PROP]K.Petersen,M.Spreizer,D.Terry,M.Theimer和A.Demers,“用于弱一致性复制的灵活更新传播”,第十六届ACM操作系统原理研讨会,法国圣马洛,1997年。

11. Authors' Addresses
11. 作者地址

Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003

赵伟斌哥伦比亚大学计算机科学系,地址:纽约州纽约市阿姆斯特丹大道1214号,邮编:0401,邮编:10027-7003

   EMail: zwb@cs.columbia.edu
        
   EMail: zwb@cs.columbia.edu
        

Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003

Henning Schulzrinne哥伦比亚大学计算机科学系,地址:纽约州纽约市阿姆斯特丹大道1214号,邮编:0401,邮编:10027-7003

   EMail: hgs@cs.columbia.edu
        
   EMail: hgs@cs.columbia.edu
        

Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany

埃里克·古特曼太阳微系统公司。74915德国威伯斯塔特

   EMail: Erik.Guttman@sun.com
        
   EMail: Erik.Guttman@sun.com
        
12. Full Copyright Statement
12. 完整版权声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

版权所有(C)互联网协会(2003年)。版权所有。

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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。