RFC 3528
Mesh-enhanced Service Location Protocol (mSLP)
Mesh-enhanced Service Location Protocol (mSLP) 🦋
Network Working Group 🌸 this one is from the Network Working Group.
RFC number: 3528 ✨ Category: Experimental 🧪 Date: April 2003 📅
Authors: W. Zhao, H. Schulzrinne (Columbia University), and E. Guttman (Sun Microsystems) 👯♀️
The title block doesn't say this RFC obsoletes or updates anything, so it stands on its own 💅
Status of This Memo 🧠
Okay so this memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind 🙅♀️. They're asking for discussion and suggestions for improvement, so bring your ideas 💜. And 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 levels up the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture 👑. Peer DAs swap new service registrations in shared scopes using anti-entropy and direct forwarding 🔁. The result is better reliability and consistency for SLP DA services, plus simpler Service Agent (SA) registrations when you've got multiple DAs 🫶. mSLP is backward compatible with SLPv2 and can be rolled out 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
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 . . . . . . . . . . . . . . . . . . . 151. Introduction 🎀
Okay so 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 boost the performance and scalability of SLPv2 🚀. Scopes make SLPv2 even more scalable 💅. A DA can serve multiple scopes, and a scope can be served by multiple DAs 🧚. So when multiple DAs show up for one scope, how should they interact? 🤔 That's the open issue this document goes after, and mSLP is the answer 👑.
mSLP defines a scope-based fully-meshed peering DA architecture 🕸️. For each scope, all the DAs serving that 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 it 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] 🧐.
1.2. Terminology 📖
Here's the vocab you'll need, bestie 💜
- 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 ⏰. This one's a hard rule, no cap 🔥.
- 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 🕰️. Also a hard rule, periodt 💅.
1.3. Compatibility 🫧
mSLP is designed as a lightweight enhancement to SLPv2, and it's 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 compatibility, an enhanced entity works as a non-enhanced entity when it interacts with non-enhanced entities 🫶. Table 1 summarizes all interactions involving an MDA or MSA, and honestly it's giving clarity 📊.
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 MSA2. 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 🦋
okay so mSLP runs on a scope-based fully-meshed peering DA architecture 💅 for every scope, all the MDAs serving that scope form a fully-meshed peer relationship, meaning everyone is connected to everyone. Figure 1 is a cute little example with four MDAs and three scopes (x, y, and z) 🧚. Also, bestie, a single peering connection is all you need between two peers to exchange every service registration in their shared scopes. no extra connections needed 🫶
this architecture levels up SLP DA services in two big ways 🔥. First, it improves consistency among peer DAs by automatically reconciling inconsistent states between them. Second, newly booted and rebooted MDAs can catch up on all new registrations at once from their peers, purely through DA interaction, without involving SAs. iconic 👑
it also makes SA registrations way easier 💖 in SLPv2, an SA has to discover and register with every existing DA in its scopes, and then re-register whenever new DAs show up or old DAs turn out to have rebooted. in mSLP, an MSA only needs to discover and register with enough MDAs so that the union of their scopes covers its own scopes. the registrations then get propagated automatically to the other MDAs in the registration scopes. main character energy ✨ 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 🌸
and the scaling? literally chef's kiss 🤌 Consider a scope that has N SAs and M DAs, where N > M >= 2. mSLP and SLPv2 need the same number of SLP messages to distribute registrations from N SAs to M DAs. BUT mSLP can reduce the number of agents handling registration distribution, and it can reduce the number of TCP connections needed if each SA uses TCP for its registrations. in SLPv2, all N SAs are the agents taking care of distribution, but in mSLP it's only the M DAs 🙈 The TCP count is also different. SLPv2 needs N*M connections, because each SA has to connect with each DA and register. mSLP only needs N+M*(M-1)/2, because each SA only connects to one contacting DA of a full mesh of M nodes and registers, and then the registrations get propagated through the DA mesh. For N=100 and M=10, SLPv2 needs 1000 TCP connections, but mSLP only needs 145 of them. 😭🎀
⚠️ bestie, full-mesh topology is mainly about simplicity and reliability, so 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 a giant 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, we can split "x" into two finer scopes, "x-1" and "x-2". We'd have N1 MDAs for "x-1" only, N2 MDAs for "x-2" only, and N3 MDAs for both "x-1" and "x-2", with N1+N2+N3=N. Instead of one big full mesh of size N, we now have two smaller full meshes of size N1+N3 and N2+N3. The tradeoff is that a service registration that used to target scope "x" now needs to be registered under both "x-1" and "x-2" 🦋
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 that peer. no DAAdvert, no peer relationship, periodt 🙅♀️
3.2. Establishing a Peering Connection
okay so after getting a new peer's DAAdvert, an MDA establishes a peering connection (if one doesn't already exist) to that peer, and sends its DAAdvert over the connection (Figure 3) 💌 An MDA can identify a peering connection that a peer initiated by receiving the peer's DAAdvert from that connection. Normally a single peering connection gets set up between two peers, BUT there's a small chance that a pair of peering connections gets created if both peers try to initiate a connection to each other at almost the same time 😭 So when an MDA identifies a new peering connection initiated by a peer, it SHOULD check whether it has already initiated another peering connection to that peer. If that's the case, and it has a lower-numbered IP address than the peer, then the MDA SHOULD terminate the connection it initiated. tiebreaker energy 💅
+------+ (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 a peering connection is set up, two peers (say, MDA1 and MDA2) swap info about their existing peers by forwarding peers' DAAdverts over 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).
MDA2 operates similarly 🔁 Also, all DAAdverts can be sent as one TCP stream for efficiency. This info-swapping is how an MDA learns 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
to detect failures (network partitions and peer crashes), mSLP uses a heart-beat mechanism 💓 An MDA sends its DAAdvert to its peers (Figure 5) every CONFIG_DA_KEEPALIVE seconds. The timeout value for this message is CONFIG_DA_TIMEOUT seconds (Section 6).
+------+ MDA1's DAAdvert +------+
| | ---------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <--------------------------------------- | |
+------+ MDA2's DAAdvert +------+Figure 5. Maintaining a peer relationship 💜
3.5. Tearing Down a Peer Relationship
an MDA SHOULD tear down a peer relationship when it finds 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 the peer is going to shut down), or when it hasn't received the peer's DAAdvert for more than CONFIG_DA_TIMEOUT seconds. bye bye, peer 👋
4. Registration Propagation Control 🔐
4.1. Accept ID and Propagation Order
when an MDA accepts a registration update from an MSA, the MDA gives the update a unique accept ID 🆔 An accept ID has two parts: 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 the latest update applied to it.
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 📋
the ordering rule is a big deal 📣 An MDA MUST propagate registrations in the increasing order of their accept IDs. That means registrations with the same accept DA MUST be propagated in increasing order of their accept timestamps. Registrations with different accept DAs MAY be propagated in any order. flexible but still organized 🧠
4.2. Version Timestamp and Registration Version Resolution
when registrations get propagated among MDAs, their arrival timestamps at MDAs can't be used for version resolution 🙅♀️ For example, say MSA1 sends a registration (R1) to MDA1 first, and then a newer version of the same registration (R2) to MDA2. 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, because R2 is the newer version. plot twist, the arrival time lies 🫠
mSLP resolves registration versions using version timestamps 💎 When an MSA sends a registration update to an MDA, the MSA assigns a version timestamp to that update. The version timestamp is a 64-bit integer representing elapsed microseconds since 00:00 UTC, January 1, 1900. mSLP assumes each registration is updated by only one SA, so an MDA doesn't 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 if the update doesn't have the Mesh Forwarding extension (from a non-MSA). ✨ the version timestamp is the tea, not the arrival time ☕
4.3. Mesh Forwarding Extension ✨
Okay bestie, the Mesh Forwarding (MeshFwd) extension is the one that carries a version timestamp and an accept ID entry 💖 Figure 7 shows its format, plus the two Forwarding IDs (Fwd-IDs) it can have 🎀
The MeshFwd extension goes along with a Srv(De)Reg message, but it can only be used with a fresh SrvReg, or a complete SrvDeReg 🫶 That's the rule, no cap.
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-IDsAn 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 it sends to another MDA 💅 It does this either when it's forwarding a Srv(De)Reg it got from an MSA (if that message has the RqstFwd MeshFwd extension), or when it's propagating a registration state in its database.
4.4. Summary Vector 🌈
An MDA uses a summary vector to keep track of its received Srv(De)Reg(s) that have a MeshFwd extension. This summary vector records the latest accept timestamp for each accept DA that shows up in the MeshFwd extension. For example, say there are 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. Main character energy 👑
An MDA updates its summary vector whenever it receives a Srv(De)Reg that has a MeshFwd extension. If the Srv(De)Reg has a new accept DA, the MDA adds a new accept ID to its summary vector. If the Srv(De)Reg has an accept DA that's already there, the MDA updates the accept timestamp of that existing accept ID instead ✨
4.5. Service Deregistration 🙈
When an MDA receives a SrvDeReg that has a MeshFwd extension, it SHOULD retain the matching registration in the database and mark it as deleted. This way, the registration won't show up in any query reply, and an earlier SrvReg can't accidentally bring it back to life in the database 💀 A registration state gets purged from the database once 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 the 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 typesThe AntiEtrpRqst message is how an MDA asks a peer for new registration states. The anti-entropy type is either selective or complete. If it's selective, only the registration states with an accept ID greater than any accept ID specified in the message get requested. If it's complete, the request covers all registration states with an accept ID greater than any specified in the message, or with an accept DA that isn't specified in the message 🦋
For example, picture 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 with an accept ID list of ((MDA2, T2)), then MDA1 only requests registration states originally accepted by MDA2 that have an accept timestamp greater than T2. If MDA1 sends a complete AntiEtrpRqst to MDA2 with that same accept ID list, then MDA1 requests all registration states originally accepted by MDA1 and MDA3, plus those originally accepted by MDA2 with an accept timestamp greater than T2 😭
4.7. Anti-entropy 💜
Anti-entropy is how two peers swap their initial registration states when they recognise each other for the first time. It's also how new registration states get updated after failures 🔥
When an MDA gets an AntiEtrpRqst from a peer, it sends the requested new registration states in increasing order of their accept IDs. At last, a Service Acknowledgment (SrvAck) message gets sent to show that the processing of the matching AntiEtrpRqst is done (Figure 9). Each new registration state goes out as a fresh SrvReg with its remaining lifetime, and a newly deregistered state goes out 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 SrvAck4.8. Direct Forwarding ⭐
+------+ RqstFwd Srv(De)Reg +------+ Fwded Srv(De)Reg +------+
| | ---------------------> | | --------------------> | |
| MSA1 | | MDA1 | | MDA2 |
| | <--------------------- | | | |
+------+ SrvAck +------+ +------+
Figure 10. Direct forwarding of a Srv(De)RegAfter an MDA has sent all the new registration states it accepted itself to a peer (via anti-entropy), it directly forwards newly received registration updates from MSAs to that peer until a failure happens 🫶
In Figure 10, when a Srv(De)Reg gets 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 direct forwarding happens asynchronously: MDA1 can send a SrvAck to MSA1 before it forwards the Srv(De)Reg to MDA2 🧚 Also note that direct forwarding of a Srv(De)Reg only goes one hop, from its accept DA (say, MDA1) to all of MDA1's peers that are in the registration scopes.
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, since peers swap Srv(De)Reg messages over 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 keeps track of the following control information: an accept ID (for registration propagation), a version timestamp (for registration version resolution, which means rejecting previous updates), and a deletion flag (deregistered or not) ✨
For all registration entries, an MDA maintains a summary vector to reflect the registrations it has received 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, but it does not forward them 💀
For all MDAs, an MSA only needs to discover and register with a sufficient number of them, so 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, and it accepts registrations from SAs and peers, then propagates registrations to peers via anti-entropy and direct forwarding 💖
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.47. 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, and security matters here because a single bad actor can cause real chaos ⚠️
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 it registers with 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.
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 ✨
These are the people who wrote it, bestie 🫶 Here's where you can find them:
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.com12. Full Copyright Statement 💜
This is legal text, so I kept every word exactly as written. No edits, bestie 💅
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. Thank you, Internet Society! 🫶
📦 where this page comes from
- ietf: rfc3528 2003-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms