RFC3528 日本語訳

3528 Mesh-enhanced Service Location Protocol (mSLP). W. Zhao, H.Schulzrinne, E. Guttman. April 2003. (Format: TXT=35208 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文

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)

Mesh-enhanced Service Location Protocol (mSLP)

Status of this Memo

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.

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 Notice

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

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

Abstract

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.

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.

Table of Contents

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

Zhao, et al.                  Experimental                      [Page 1]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

Zhao, et al. Experimental [Page 1] RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003

       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. Introduction

   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.

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.

   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 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.

1.1. Notation Conventions

1.1. Notation Conventions

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

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

Zhao, et al.                  Experimental                      [Page 2]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

Zhao, et al. Experimental [Page 2] RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003

1.2. Terminology

1.2. Terminology

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

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

   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.

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.

   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.

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.

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

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

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

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

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

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.

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

   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 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.

   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.

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.

1.3. Compatibility

1.3. Compatibility

   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 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

Zhao, et al.                  Experimental                      [Page 3]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

Zhao, et al. Experimental [Page 3] RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003

   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.

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.

            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

Table 1. Interactions involving an MDA or MSA

2. Scope-based Fully-meshed Peering DA Architecture

2. Scope-based Fully-meshed Peering DA Architecture

                                 (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

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

   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 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.

   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.

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.

   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

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

Zhao, et al.                  Experimental                      [Page 4]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

Zhao, et al. Experimental [Page 4] RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003

   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.

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.

                 (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

Figure 2. Options for registering with MDAs

   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.

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.

   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".

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".

Zhao, et al.                  Experimental                      [Page 5]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

Zhao, et al. Experimental [Page 5] RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003

3. Peer Relationship Management

3. Peer Relationship Management

3.1. Learning about New Peers

3.1. Learning about New Peers

   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.

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.

3.2. Establishing a Peering Connection

3.2. Establishing a Peering Connection

   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.

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.

      +------+    (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

Figure 3. Establishing a peering connection

3.3. Exchanging Information about Existing Peers

3.3. Exchanging Information about Existing Peers

   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:

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:

      (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 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).

Zhao, et al.                  Experimental                      [Page 6]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

Zhao, et al. Experimental [Page 6] RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003

   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 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.

      +------+      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

Figure 4. Exchanging information about existing peers

3.4. Maintaining a Peer Relationship

3.4. Maintaining a Peer Relationship

      +------+              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

Figure 5. Maintaining a peer relationship

   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).

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).

3.5. Tearing Down a Peer Relationship

3.5. Tearing Down a Peer Relationship

   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.

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.

4. Registration Propagation Control

4. Registration Propagation Control

4.1. Accept ID and Propagation Order

4.1. Accept ID and Propagation Order

   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.

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.

Zhao, et al.                  Experimental                      [Page 7]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

Zhao, et al. Experimental [Page 7] RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003

       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

Figure 6. Accept ID entry

   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.

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.

4.2. Version Timestamp and Registration Version Resolution

4.2. Version Timestamp and Registration Version Resolution

   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.

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.

   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 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).

4.3. Mesh Forwarding Extension

4.3. Mesh Forwarding Extension

   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).

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).

   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.

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.

Zhao, et al.                  Experimental                      [Page 8]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

Zhao, et al. Experimental [Page 8] RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003

       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 Abbreviation 1 RqstFwd 2 Fwded

                 Figure 7. MeshFwd extension and its Fwd-IDs

Figure 7. MeshFwd extension and its Fwd-IDs

   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.

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.

   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.

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.

4.4. Summary Vector

4.4. Summary Vector

   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.

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.

   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.

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.

Zhao, et al.                  Experimental                      [Page 9]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

Zhao, et al. Experimental [Page 9] RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003

4.5. Service Deregistration

4.5. Service Deregistration

   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.

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.

4.6. Anti-entropy Request Message

4.6. Anti-entropy Request Message

   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.

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.

       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

Anti-Entropy Type Type ID selective 1 complete 2

          Figure 8. AntiEtrpRqst message and anti-entropy types

Figure 8. AntiEtrpRqst message and anti-entropy types

   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.

AntiEtrpRqstメッセージは、同輩から新規登録州を要求するのにMDAによって使用されます。 反エントロピータイプは、選択能力があるか、または完全です。 IDが指定されたいずれもIDを受け入れるよりすばらしいと受け入れてください。タイプは反エントロピーであるなら選択能力があります、そうした登録州だけ、メッセージでは、要求されています。 DAがメッセージで指定されていないと受け入れてください。タイプは反エントロピーであるなら完全です、そうしたすべての登録州、IDが指定されたいずれもメッセージのIDを受け入れるよりすばらしいと受け入れてください、有、要求されています。

   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

例えば、3MDAs(MDA1、MDA2、およびMDA3)を範囲と考えてください。 MDA2はMDA1、MDA2、およびMDA3に元々、登録州を受け入れさせます。 MDA1が選択しているAntiEtrpRqstをMDA2使用に送る、((MDA2、T2))としてIDリストを認めてください、次に、MDA1が元々MDA2によって受け入れられる登録州を要求するだけである、有、タイムスタンプがT2よりすばらしいと受け入れてください。 MDA1が完全なAntiEtrpRqstをMDA2使用に送る、((MDA2、T2))としてIDリストを認めてください、そして、次に、MDA1はすべてを要求します。

Zhao, et al.                  Experimental                     [Page 10]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

チャオ、他 実験的な[10ページ]RFC3528メッシュ高度サービス位置のプロトコル(mSLP)2003年4月

   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.

反エントロピーは、2人の同輩が初めて互いを見分けるとき新規登録州を交換して、失敗の後に新規登録州をアップデートするのに使用されます。

   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を受けて、増加するオーダーで要求された新規登録州を送るか、それら、IDを受け入れてください。 ついに、対応するAntiEtrpRqstの処理が終了したのを(図9)示すためにService Acknowledgment(SrvAck)メッセージを送ります。 残っている生涯がある新鮮なSrvRegとして新規登録状態を送ります。 新たに反登録された状態はSrvDeRegとして伝播されます。1TCPが効率のために流れるとき複数のSrv(De)レッジを送ることができることに注意してください。

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

+------+ AntiEtrpRqst+------+ | | ------------------------------------------->|、|、| MDA1| (じっと見る接続) | MDA2| | | <------------------------------------------- | | +------+ Srv(De)レッジ+SrvAck+を通した新しいStates------+

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

図9。 AntiEtrpRqstを通した反エントロピー、Srv(De)レッジ、およびSrvAck

4.8. Direct Forwarding

4.8. ダイレクト推進

+------+   RqstFwd Srv(De)Reg   +------+   Fwded Srv(De)Reg    +------+
|      | ---------------------> |      | --------------------> |      |
| MSA1 |                        | MDA1 |                       | MDA2 |
|      | <--------------------- |      |                       |      |
+------+         SrvAck         +------+                       +------+

+------+ RqstFwd Srv(De)レッジ+------+ Fwded Srv(De)レッジ+------+ | | --------------------->|、| -------------------->|、|、| MSA1| | MDA1| | MDA2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| +------+ SrvAck+------+ +------+

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

図10。 Srv(De)レッジのダイレクト推進

   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は直接MSAsから同輩までの新たに受け取られた登録アップデートを進めます。

   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.

タイムスタンプを受け入れてください。そして、MDA1からMDA2まで直接Srv(De)レッジを進めるとき、図10では、Fwd-IDをFwdedに設定する、それ、MDA1の到着タイムスタンプに設定されます。 ダイレクト推進が非同期に実行されることに注意してください: Srv(De)レッジをMDA2に送る前にMDA1はSrvAckをMSA1に送ることができます。 また、a Srv(De)レッジのダイレクト推進がワンバウンドであるだけであるのになることに注意してください、それ、登録範囲にいるすべてのMDA1の同輩にDA(たとえば、MDA1)を受け入れてください。

Zhao, et al.                  Experimental                     [Page 11]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

チャオ、他 実験的な[11ページ]RFC3528メッシュ高度サービス位置のプロトコル(mSLP)2003年4月

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からSrv(De)レッジへのSrvAckとのDA MUST回答を受け取ります。 しかしながら、メッセージであるなら同輩からSrv(De)レッジへのSrvAckとのMDA SHOULD NOT回答を受け取ります。 同輩が頼もしいじっと見る接続でSrv(De)レッジメッセージを交換するので、これは効率のためのものです。 MDA MUSTが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は3つの新しい定義でSLPv2を広げています: 新しい属性--新しいメッセージ拡張子--MeshFwd、および新しいメッセージタイプ--DAAdvert、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.

MDAが非MDAよりUAの範囲への完全な当期の勤務登録証明書を確かに含みそうであって、UA MAYはMDAを好みます。

   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)レッジを受け入れます。 それはそれらを進めません。

   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.

すべてのMDAsのために、MSAは十分な数の彼らを発見して、ともに記名する必要があるだけです、彼らが範囲を覆うように。 MDAsとともに記名するとき、それは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はDAAdvertの「メッシュで高められた」属性キーワードを運びます。 それは各同輩との同輩関係を維持します。 それは、SAsと同輩から登録証明書を受け入れて、反エントロピーとダイレクト推進で登録証明書を同輩に伝播します。

Zhao, et al.                  Experimental                     [Page 12]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

チャオ、他 実験的な[12ページ]RFC3528メッシュ高度サービス位置のプロトコル(mSLP)2003年4月

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

中で定義された間隔名前デフォルト値------------------- ------------- ----------- CONFIG_DA_KEEPALIVE200秒セクション3.4 CONFIG_DA_TIMEOUT300秒セクション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).

Mesh Forwarding(MeshFwd)拡大ID(セクション4.3で説明された0×0006)はIANAによって「実行するために任意」拡大(すなわち、0×0000 0x3FFFの範囲)のために予約されたSLP拡大スペース(RFC2608、セクション9.1)から割り当てられました。

   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).

Anti-エントロピーRequest(AntiEtrpRqst)メッセージタイプの機能ID(セクション4.6で説明された12)はIANA(RFC2608、セクション15)によって割り当てられました。

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もDAメッシュを接合するのを防ぐために彼らとの同輩関係をセットアップする前に、MDA SHOULDは他のMDAsを認証します。 2番目に、MDAでのうまくいっている攻撃がDAのすべてのMDAsに影響するとき、サービス登録証明書の違法な変更か除去を防ぐ彼らのSrv(De)レッジメッセージを受け入れて、転送する前に、メッシュ、MDA SHOULDはMSAsを認証します。 MSAがどれに登録するかでMDAによるように3番目に、Srv(De)にレッジメッセージを転送してください、それ。SHOULDは悪意がある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.

トーマスNarten、ジェームス・ケンフ、マイク・デー、マイケルPahmp、イラ・マクドナルド、Qiaobingシェ、および新港クオはこのドキュメントのための貴重なコメントを提供しました。

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.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。

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

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

Zhao, et al.                  Experimental                     [Page 13]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

チャオ、他 実験的な[13ページ]RFC3528メッシュ高度サービス位置のプロトコル(mSLP)2003年4月

10.2. Informative References

10.2. 有益な参照

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

1995年の[RFC1771]RekhterとR.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。

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

[RFC2610] パーキンスとC.とE.Guttman、「サービス位置のプロトコルのためのDHCPオプション」、RFC2610、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.グリーンとC.ハウザーとW.アイルランド人とJ.ラーソンとS.ShenkerとH.スタージスとD.SwinehartとD.テリー、「模写されたデータベースメンテナンスのための流行のアルゴリズム」、分散コンピューティングの原則に関する6番目の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.ピーターセン、M.Spreizer、D.テリー、M.TheimerとA.Demers、「弱々しく一貫した模写のためのフレキシブルなアップデート伝播」、オペレーティングシステム原則、セイント・マロ、フランス、1997に関する16番目のACMシンポジウム。

11. Authors' Addresses

11. 作者のアドレス

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

Weibinチャオコンピュータサイエンス学部Columbia University1214アムステルダムアベニュー、ニューヨーク、ニューヨークのM.C.0401 10027-7003

   EMail: zwb@cs.columbia.edu

メール: zwb@cs.columbia.edu

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

ヘニングSchulzrinneコンピュータサイエンス学部Columbia University1214アムステルダムアベニュー、ニューヨーク、ニューヨークのM.C.0401 10027-7003

   EMail: hgs@cs.columbia.edu

メール: hgs@cs.columbia.edu

   Erik Guttman
   Sun Microsystems
   Eichhoelzelstr. 7
   74915 Waibstadt
   Germany

エリックGuttmanサン・マイクロシステムズEichhoelzelstr。 7 74915Waibstadtドイツ

   EMail: Erik.Guttman@sun.com

メール: Erik.Guttman@sun.com

Zhao, et al.                  Experimental                     [Page 14]

RFC 3528     Mesh-enhanced Service Location Protocol (mSLP)   April 2003

チャオ、他 実験的な[14ページ]RFC3528メッシュ高度サービス位置のプロトコル(mSLP)2003年4月

12. Full Copyright Statement

12. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Zhao, et al.                  Experimental                     [Page 15]

チャオ、他 実験的[15ページ]

一覧

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

スポンサーリンク

checkout

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

上に戻る