diff options
Diffstat (limited to 'doc/rfc/rfc3528.txt')
| -rw-r--r-- | doc/rfc/rfc3528.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc3528.txt b/doc/rfc/rfc3528.txt new file mode 100644 index 0000000..8dec0c8 --- /dev/null +++ b/doc/rfc/rfc3528.txt @@ -0,0 +1,843 @@ + + + + + + +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) + +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. + +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. + +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 + + + +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 + +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. + + 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 + + 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 + + +1.2. Terminology + + 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. + + 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. + + 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. + + 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. + + 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 + + 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 + + + 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 + + Table 1. Interactions involving an MDA or MSA + +2. Scope-based Fully-meshed Peering DA Architecture + + (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 + + 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 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 + + + 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) | + +----------+ +------------+ +----------+ + + 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. + + 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 + + +3. Peer Relationship Management + +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. + +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. + + +------+ (1) MDA2's DAAdvert | +------+ + | | <----------------------+ | | + | MDA1 | (2) Create a Peering Connection | MDA2 | + | | ---------------------------------------> | | + +------+ (3) MDA1's DAAdvert +------+ + + Figure 3. Establishing a peering connection + +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: + + (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 + + + 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 +------+ + + Figure 4. Exchanging information about existing peers + +3.4. Maintaining a Peer Relationship + + +------+ MDA1's DAAdvert +------+ + | | ---------------------------------------> | | + | MDA1 | (Peering Connection) | MDA2 | + | | <--------------------------------------- | | + +------+ MDA2's DAAdvert +------+ + + 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). + +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. + +4. Registration Propagation Control + +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. + + + + + +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 \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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. + +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. + + 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 + + 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. + + + + + +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 \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fwd-ID Abbreviation + 1 RqstFwd + 2 Fwded + + 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 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 + + 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. + + + + + + + + +Zhao, et al. Experimental [Page 9] + +RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003 + + +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. + +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. + + 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 + + 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. + + 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 + + + + +Zhao, et al. Experimental [Page 10] + +RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003 + + + registration states originally accepted by MDA1 and MDA3, plus those + originally accepted by MDA2 and having an accept timestamp greater + than T2. + +4.7. Anti-entropy + + 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. + + +------+ 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 + +4.8. Direct Forwarding + ++------+ RqstFwd Srv(De)Reg +------+ Fwded Srv(De)Reg +------+ +| | ---------------------> | | --------------------> | | +| MSA1 | | MDA1 | | MDA2 | +| | <--------------------- | | | | ++------+ SrvAck +------+ +------+ + + Figure 10. Direct forwarding of a 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. + + 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. + + + +Zhao, et al. Experimental [Page 11] + +RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003 + + +4.9. SrvAck Message + + 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. + +4.10. Control Information + + 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). + + For all registration entries, an MDA maintains a summary vector to + reflect its received registrations so far. + +5. Summary + + 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. + + 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. + + A non-MSA needs to discover and register with all DAs in its scopes. + It does not use the MeshFwd extension. + + A non-MDA accepts Srv(De)Reg(s) from SAs. It does not forward them. + + 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. + + 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. + + + + + + + + + +Zhao, et al. Experimental [Page 12] + +RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003 + + +6. Protocol Timing Defaults + + 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 + + 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). + + 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). + +8. Security Considerations + + 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. + +9. Acknowledgments + + Thomas Narten, James Kempf, Mike Day, Mikael Pahmp, Ira McDonald, + Qiaobing Xie and Xingang Guo provided valuable comments for this + document. + +10. References + +10.1. Normative References + + [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, + "Service Location Protocol, Version 2", RFC 2608, June + 1999. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + +Zhao, et al. Experimental [Page 13] + +RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003 + + +10.2. Informative References + + [RFC1771] Rekhter, R. and T. Li, "A Border Gateway Protocol 4 + (BGP-4)", RFC 1771, March 1995. + + [RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service + Location Protocol", RFC 2610, June, 1999. + + [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. + + [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. + +11. Authors' Addresses + + Weibin Zhao + Department of Computer Science + Columbia University + 1214 Amsterdam Avenue, MC 0401 + New York, NY 10027-7003 + + EMail: zwb@cs.columbia.edu + + + Henning Schulzrinne + Department of Computer Science + Columbia University + 1214 Amsterdam Avenue, MC 0401 + New York, NY 10027-7003 + + EMail: hgs@cs.columbia.edu + + + Erik Guttman + Sun Microsystems + Eichhoelzelstr. 7 + 74915 Waibstadt + Germany + + EMail: Erik.Guttman@sun.com + + + + + +Zhao, et al. Experimental [Page 14] + +RFC 3528 Mesh-enhanced Service Location Protocol (mSLP) April 2003 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (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. + + 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. + + + + + + + + + + + + + + + + + + + +Zhao, et al. Experimental [Page 15] + |