idnits 2.17.1 draft-zhao-slp-da-interaction-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in '[Target Category: Experimental]', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'EPID-ALGO' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'UPDA-PROP' is defined on line 624, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT W. Zhao 3 draft-zhao-slp-da-interaction-16.txt H. Schulzrinne 4 [Target Category: Experimental] Columbia University 5 January 20, 2003 E. Guttman 6 Expires: July 20, 2003 Sun Microsystems 8 Mesh-enhanced Service Location Protocol 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document describes the Mesh-enhanced Service Location Protocol 38 (mSLP). mSLP enhances SLP with a scope-based fully-meshed peering 39 Directory Agent (DA) architecture. Peer DAs exchange new service 40 registrations in shared scopes via anti-entropy and direct 41 forwarding. mSLP improves the reliability and consistency of SLP DA 42 services, and simplifies Service Agent (SA) registrations in systems 43 with multiple DAs. mSLP is backward compatible with SLPv2 and can be 44 deployed incrementally. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1. Notation Conventions . . . . . . . . . . . . . . . . . . . 3 50 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Scope-based Fully-meshed Peering DA Architecture . . . . . 4 53 3. Peer Relationship Management . . . . . . . . . . . . . . . 6 54 3.1. Learning about New Peers . . . . . . . . . . . . . . . . . 6 55 3.2. Establishing a Peering Connection . . . . . . . . . . . . 6 56 3.3. Exchanging Information about Existing Peers . . . . . . . 6 57 3.4. Maintaining a Peer Relationship . . . . . . . . . . . . . 7 58 3.5. Tearing Down a Peer Relationship . . . . . . . . . . . . . 7 59 4. Registration Propagation Control . . . . . . . . . . . . . 8 60 4.1. Accept ID and Propagation Order . . . . . . . . . . . . . 8 61 4.2. Version Timestamp and Registration Version Resolution . . 8 62 4.3. Mesh Forwarding Extension . . . . . . . . . . . . . . . . 9 63 4.4. Summary Vector . . . . . . . . . . . . . . . . . . . . . . 9 64 4.5. Service Deregistration . . . . . . . . . . . . . . . . . . 10 65 4.6. Anti-entropy Request Message . . . . . . . . . . . . . . . 10 66 4.7. Anti-entropy . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.8. Direct Forwarding . . . . . . . . . . . . . . . . . . . . 11 68 4.9. SrvAck Message . . . . . . . . . . . . . . . . . . . . . . 12 69 4.10. Control Information . . . . . . . . . . . . . . . . . . . 12 70 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Protocol Timing Defaults . . . . . . . . . . . . . . . . . 13 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 73 8. Security Considerations . . . . . . . . . . . . . . . . . 13 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 13 75 10. Normative References . . . . . . . . . . . . . . . . . . . 13 76 11. Non-normative References . . . . . . . . . . . . . . . . . 14 77 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 78 13. Full Copyright Statement . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 In the Service Location Protocol (SLPv2 [RFC2608]), Directory Agents 83 (DAs) accept service registrations from Service Agents (SAs) and 84 answer queries from User Agents (UAs); they enhance the performance 85 and scalability of SLPv2. The use of scopes in SLPv2 further improves 86 its scalability. In general, a DA can serve multiple scopes, and a 87 scope can be served by multiple DAs. When multiple DAs are present 88 for a scope, how should they interact with each other? This document 89 describes the Mesh-enhanced Service Location Protocol (mSLP) to 90 address this open issue in SLPv2. 92 mSLP defines a scope-based fully-meshed peering DA architecture: for 93 each scope, all DAs serving the scope form a fully-meshed peer 94 relationship (similar to IBGP [RFC1771]). Peer DAs exchange new 95 service registrations in shared scopes via anti-entropy [EPID- 96 ALGO,UPDA-PROP] and direct forwarding. mSLP improves the reliability 97 and consistency of SLP DA services, and simplifies SA registrations 98 in systems with multiple DAs. 100 1.1. Notation Conventions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 1.2. Terminology 108 Peer DAs (or Peers) 109 DAs that share one or multiple scopes are peers. 111 Peering Connection 112 A persistent connection (e.g., TCP) that provides reliable and 113 ordered transfers between two peers. The closing of a peering 114 connection terminates the peer relationship. 116 Mesh-enhanced DA (MDA) 117 An MDA carries the "mesh-enhanced" attribute keyword in its DA 118 Advertisement (DAAdvert) message, maintains peering connections 119 to all peers, and properly interacts with peers. 121 Mesh-enhanced SA (MSA) 122 An MSA uses the Mesh Forwarding extension (Section 4.3) when it 123 registers with MDAs. 125 Registration Update 126 A registration update refers to a Service Registration (SrvReg) 127 or Service Deregistration (SrvDeReg) message. 129 Registration State 130 A registration state refers to an entry in the registration 131 database. 133 Accept DA 134 When a DA accepts a registration update from an SA, the DA is 135 the accept DA for the update. 137 Accept Timestamp 138 The arrival timestamp of a registration update at its accept DA 139 is the accept timestamp of the update. All accept timestamps 140 assigned by the same DA MUST be monotonically increasing. 142 Version Timestamp 143 When an MSA sends a registration update to an MDA, the MSA 144 assigns a version timestamp to the update. All version 145 timestamps assigned by the same MSA MUST be monotonically 146 increasing. 148 1.3. Compatibility 150 mSLP is designed as a lightweight enhancement to SLPv2. It is 151 backward compatible with SLPv2. mSLP defines two enhanced entities: 152 MDA and MSA. MDAs and MSAs can be deployed incrementally. An enhanced 153 entity supports extended operations without affecting its original 154 functionality as defined in RFC 2608 [RFC2608]. For simplicity and 155 compatibility, an enhanced entity works as a non-enhanced entity to 156 interact with non-enhanced entities. Table 1 summarizes all 157 interactions involving an MDA or MSA. 159 Interaction Equivalent To Defined In 160 ---------------------------------------------- 161 MDA <--> MDA mSLP 162 MDA <--> MSA mSLP 163 MDA <--> DA DA <--> DA RFC 2608 164 MDA <--> SA DA <--> SA RFC 2608 165 MDA <--> UA DA <--> UA RFC 2608 166 MSA <--> DA SA <--> DA RFC 2608 167 MSA <--> UA SA <--> UA RFC 2608 169 Table 1. Interactions involving an MDA or MSA 171 2. Scope-based Fully-meshed Peering DA Architecture 173 (x,y) 174 +--------------------------------------------------+ 175 | +------------+ | 176 | | MDA4 (z) | | 177 | +------------+ | 178 | | (z) | 179 +------------+ (y) +------------+ (y) +------------+ 180 | MDA1 (x,y) | ---------- | MDA3 (y,z) | ---------- | MDA2 (x,y) | 181 +------------+ +------------+ +------------+ 183 Figure 1. A scope-based fully-meshed peering DA architecture 185 mSLP employs a scope-based fully-meshed peering DA architecture. For 186 each scope, all MDAs that serve the scope form a fully-meshed peer 187 relationship. Figure 1 shows an example for four MDAs and three 188 scopes (x, y, and z). Note that a single peering connection is needed 189 between two peers for exchanging all service registrations in their 190 shared scopes. 192 This architecture enhances SLP DA services. First, it improves the 193 consistency among peer DAs by automatically reconciling inconsistent 194 states among them. Second, it enables newly booted and rebooted MDAs 195 to catch up all new registrations at once from their peers purely 196 through DA interaction, without involving SAs. 198 This architecture also simplifies SA registrations. In SLPv2, an SA 199 needs to discover and register with all existing DAs in its scopes, 200 and re-register when new DAs are discovered or old DAs are found to 201 have rebooted. In mSLP, for all MDAs, an MSA only needs to discover 202 and register with sufficient number of them such that the union of 203 their scopes covers its scopes; the registrations will then be 204 propagated automatically to other MDAs in the registration scopes. 205 For example, in Figure 2, MSA1 only needs to discover and register 206 with MDA2, or with both MDA1 and MDA3. 208 (option2) +------------+ (option2) 209 +----------------- | MSA1 (x,y) | -----------------+ 210 | +------------+ | 211 | | (option1) | 212 V V V 213 +----------+ +------------+ +----------+ 214 | MDA1 (x) | ----------- | MDA2 (x,y) | ----------- | MDA3 (y) | 215 +----------+ +------------+ +----------+ 217 Figure 2. Options for registering with MDAs 219 Furthermore, this architecture provides scaling advantages. Consider 220 a scope that has N SAs and M DAs, and assume N > M >= 2. Although 221 mSLP and SLPv2 need the same number of SLP messages to distribute 222 registrations from N SAs to M DAs, mSLP can reduce the number of 223 agents needed for taking care of registration distribution, and 224 reduce the number of TCP connections needed if each SA uses TCP for 225 its registrations. More specifically, the agents that need to take 226 care of registration distribution are all N SAs in SLPv2, but only M 227 DAs in mSLP. Also, the number of needed TCP connections is N*M in 228 SLPv2 as each SA has to connect with each DA and register, but only 229 N+M*(M-1)/2 in mSLP as each SA only needs to connect to one 230 contacting DA of a full mesh of M node and register, then 231 registrations are propagated through the DA mesh. For N=100 and M=10, 232 SLPv2 needs 1000 TCP connections, but mSLP only needs 145 such 233 connections. 235 Note that as mSLP employs full-mesh topology, which is mainly for 236 simplicity and reliability, it cannot scale to a large number of MDAs 237 in a single mesh. In general, mSLP can be applied if the number of 238 MDAs in a mesh is in the order of tens or below. One way to avoid 239 having a large number of MDAs in a mesh is to split the scope into 240 several finer scopes. For example, if we have N MDAs for scope "x", 241 and N is too large, then we can split "x" into two finer scopes: 242 "x-1" and "x-2", with N1 MDAs for "x-1" only, N2 MDAs for "x-2" only, 243 N3 MDAs for both "x-1" and "x-2", and N1+N2+N3=N. Thus, instead of 244 having a large full mesh of size N, now we have two smaller full 245 meshes of size N1+N3 and N2+N3, respectively. Accordingly, a service 246 registration that previously targets for scope "x" now needs to be 247 registered under both "x-1" and "x-2". 249 3. Peer Relationship Management 251 3.1. Learning about New Peers 253 An MDA can learn about new peers via static configuration, DHCP 254 [RFC2610], and DAAdvert multicast and unicast. In any case, an MDA 255 MUST get a peer's DAAdvert before establishing a peer relationship to 256 the peer. 258 3.2. Establishing a Peering Connection 260 After getting a new peer's DAAdvert, an MDA establishes a peering 261 connection (if such a connection does not exist yet) to the peer, and 262 sends its DAAdvert via the connection (Figure 3). An MDA can identify 263 a peering connection initiated by a peer by receiving the peer's 264 DAAdvert from the connection. Normally, a single peering connection 265 is set up between two peers, but there is a small possibility that a 266 pair of peering connections might be created between two peers if 267 they try to initiate a connection to each other almost at the same 268 time. Thus, when an MDA identifies a new peering connection initiated 269 by a peer, it SHOULD check whether it has initiated another peering 270 connection to the peer. If this is the case, and it has a lower- 271 numbered IP address than the peer, then the MDA SHOULD terminate the 272 connection it has initiated. 274 +------+ (1) MDA2's DAAdvert | +------+ 275 | | <----------------------+ | | 276 | MDA1 | (2) Create a Peering Connection | MDA2 | 277 | | ---------------------------------------> | | 278 +------+ (3) MDA1's DAAdvert +------+ 280 Figure 3. Establishing a peering connection 282 3.3. Exchanging Information about Existing Peers 284 After establishing a peering connection, two peers (say MDA1 and 285 MDA2) exchange information about their existing peers by forwarding 286 peers' DAAdverts via the peering connection (Figure 4). MDA1 will 287 forward the DAAdvert of a peer (say MDA3) to MDA2 if 289 (1) MDA3 shares scopes with MDA2, and 290 (2) MDA3 is an active peer of MDA1 (there is a peering connection 291 between MDA3 and MDA1) or an accept DA of MDA1 (MDA1 has 292 registrations originally accepted by MDA3). 294 MDA2 operates similarly. Note that all DAAdverts can be sent as one 295 TCP stream for efficiency. Exchanging information about existing 296 peers enables an MDA to learn about new peers incrementally. 298 +------+ DAAdverts of MDA1's existing peers +------+ 299 | | ------------------------------------------> | | 300 | MDA1 | (Peering Connection) | MDA2 | 301 | | <------------------------------------------ | | 302 +------+ DAAdverts of MDA2's existing peers +------+ 304 Figure 4. Exchanging information about existing peers 306 3.4. Maintaining a Peer Relationship 308 +------+ MDA1's DAAdvert +------+ 309 | | ---------------------------------------> | | 310 | MDA1 | (Peering Connection) | MDA2 | 311 | | <--------------------------------------- | | 312 +------+ MDA2's DAAdvert +------+ 314 Figure 5. Maintaining a peer relationship 316 To detect failures (network partitions and peer crashes), mSLP uses a 317 heart-beat mechanism. An MDA sends its DAAdvert to peers (Figure 5) 318 every CONFIG_DA_KEEPALIVE seconds. The timeout value for this message 319 is CONFIG_DA_TIMEOUT seconds (Section 6). 321 3.5. Tearing Down a Peer Relationship 323 An MDA SHOULD tear down a peer relationship when it finds that the 324 peer has closed the peering connection, when it receives a DAAdvert 325 multicast from the peer with a DA stateless boot timestamp set to 0 326 (meaning that the peer is going to shutdown), or when it has not 327 received the peer's DAAdvert for more than CONFIG_DA_TIMEOUT seconds. 329 4. Registration Propagation Control 331 4.1. Accept ID and Propagation Order 333 When an MDA accepts a registration update from an MSA, the MDA 334 assigns a unique accept ID to the update. An accept ID has two 335 components: accept DA and accept timestamp. Figure 6 shows the format 336 for an accept ID entry. A registration state has the same accept ID 337 as that of the latest update applied to it. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Accept Timestamp | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Accept Timestamp, cont'd. | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Length of Accept DA URL | Accept DA URL \ 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 6. Accept ID entry 351 An MDA MUST propagate registrations in the increasing order of their 352 accept IDs, i.e., registrations having the same accept DA MUST be 353 propagated in the increasing order of their accept timestamps. Note 354 that registrations having different accept DAs MAY be propagated in 355 any orders. 357 4.2. Version Timestamp and Registration Version Resolution 359 When registrations are propagated among MDAs, their arrival 360 timestamps at MDAs cannot be used for version resolution. For 361 example, assume that MSA1 sends a registration (R1) to MDA1 first, 362 and a new version of the same registration (R2) to MDA2 later. When 363 R1 and R2 are propagated, the arrival timestamp of R1 at MDA2 is 364 later than that of R2, but R1 SHOULD NOT overwrite R2 at MDA2 as R2 365 is a newer version. 367 In mSLP, an MDA uses the version timestamp for registration version 368 resolution. mSLP assumes that each registration is updated only by 369 one SA, thus an MDA does not need to compare version timestamps from 370 different MSAs. An MDA installs a registration update if the update 371 has a newer version timestamp (from an MSA), or the update does not 372 have the Mesh Forwarding extension (from a non-MSA). 374 4.3. Mesh Forwarding Extension 376 The Mesh Forwarding (MeshFwd) extension carries a version timestamp 377 and an accept ID entry. Figure 7 shows its format and two defined 378 Forwarding IDs (Fwd-IDs). 380 The MeshFwd extension is used with a Srv(De)Reg message, but it can 381 only be used with a fresh SrvReg, or a complete SrvDeReg. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | MeshFwd Extension ID = 0x0006 | Next Extension Offset (NEO) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | NEO, cont'd. | Fwd-ID | Version Timestamp | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Version Timestamp, cont'd. | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Version Timestamp, cont'd. | Accept ID Entry \ 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Fwd-ID Abbreviation 396 1 RqstFwd 397 2 Fwded 399 Figure 7. MeshFwd Extension and its Fwd-IDs 401 An MSA uses the RqstFwd MeshFwd extension (Fwd-ID = RqstFwd, accept 402 timestamp = 0) in a Srv(De)Reg to explicitly request an MDA (the 403 accept DA) to forward the message. 405 An MDA uses the Fwded MeshFwd extension (Fwd-ID = Fwded, accept 406 timestamp != 0) in each Srv(De)Reg sent from it to another MDA: 407 either forwarding a Srv(De)Reg received from an MSA (if the message 408 has the RqstFwd MeshFwd extension), or propagating a registration 409 state in its database. 411 4.4. Summary Vector 413 An MDA uses a summary vector to represent its received Srv(De)Reg(s) 414 that have a MeshFwd extension. This summary vector records the latest 415 accept timestamp for each accept DA that appears in the MeshFwd 416 extension. For example, consider n MDAs for a scope, if MDAi has a 417 summary vector as ((MDA1, T1), (MDA2, T2), ..., (MDAn, Tn)), then 418 MDAi has received all registrations originally accepted by MDAj up to 419 timestamp Tj, where 1<=i,j<=n. 421 An MDA updates its summary vector when it receives a Srv(De)Reg that 422 has a MeshFwd extension. The MDA adds a new accept ID to its summary 423 vector if the Srv(De)Reg has a new accept DA; the MDA updates the 424 accept timestamp of an existing accept ID in its summary vector if 425 the Srv(De)Reg has an existing accept DA. 427 4.5. Service Deregistration 429 When an MDA receives a SrvDeReg that has a MeshFwd extension, it 430 SHOULD retain the corresponding registration in the database, and 431 mark it as deleted. This way, the registration will not appear in any 432 query reply, and an earlier SrvReg will not mistakenly cause the 433 registration to reappear in the database. A registration state will 434 be purged from the database when it expires. 436 4.6. Anti-entropy Request Message 438 The Anti-entropy Request (AntiEtrpRqst) message carries an anti- 439 entropy type ID and a list of accept ID entries. Figure 8 shows its 440 format and two defined anti-entropy type IDs. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Service Location Header (AntiEtrpRqst Function-ID = TBD) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Anti-Entropy Type ID | Number of Accept ID Entries | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Accept ID Entry 1 . . . Accept ID Entry k \ 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Anti-Entropy Type Type ID 453 selective 1 454 complete 2 456 Figure 8. AntiEtrpRqst message and anti-entropy types 458 The AntiEtrpRqst message is used by an MDA to request new 459 registration states from a peer. The anti-entropy type is either 460 selective or complete. If the anti-entropy type is selective, only 461 registration states that have an accept ID greater than any specified 462 accept ID in the message are requested. If the anti-entropy type is 463 complete, all registration states that have an accept ID greater than 464 any specified accept ID in the message or have an accept DA not 465 specified in the message are requested. 467 For example, consider three MDAs (MDA1, MDA2, and MDA3) for a scope. 468 MDA2 has registration states originally accepted by MDA1, MDA2, and 469 MDA3. If MDA1 sends a selective AntiEtrpRqst to MDA2 using an accept 470 ID list as ((MDA2, T2)), then MDA1 only requests registration states 471 that are originally accepted by MDA2, and have an accept timestamp 472 greater than T2. If MDA1 sends a complete AntiEtrpRqst to MDA2 using 473 an accept ID list as ((MDA2, T2)), then MDA1 requests all 474 registration states originally accepted by MDA1 and MDA3, plus those 475 originally accepted by MDA2 and having an accept timestamp greater 476 than T2. 478 4.7. Anti-entropy 480 Anti-entropy is used for exchanging initial registration states when 481 two peers know each other at the first time, and for catching up new 482 registration states after failures. 484 When an MDA receives an AntiEtrpRqst from a peer, it sends the 485 requested new registration states in the increasing order of their 486 accept IDs. At last a Service Acknowledgment (SrvAck) message is sent 487 to indicate that the processing of a corresponding AntiEtrpRqst has 488 been completed (Figure 9). A new registration state is sent as a 489 fresh SrvReg with its remaining lifetime. A newly deregistered state 490 is propagated as a SrvDeReg. Note that multiple Srv(De)Reg(s) can be 491 sent as one TCP stream for efficiency. 493 +------+ AntiEtrpRqst +------+ 494 | | -------------------------------------------> | | 495 | MDA1 | (Peering Connection) | MDA2 | 496 | | <------------------------------------------- | | 497 +------+ New States via Srv(De)Reg(s) + SrvAck +------+ 499 Figure 9. Anti-entropy via AntiEtrpRqst, Srv(De)Reg(s) and SrvAck 501 4.8. Direct Forwarding 503 +------+ RqstFwd Srv(De)Reg +------+ Fwded Srv(De)Reg +------+ 504 | | ---------------------> | | --------------------> | | 505 | MSA1 | | MDA1 | | MDA2 | 506 | | <--------------------- | | | | 507 +------+ SrvAck +------+ +------+ 509 Figure 10. Direct forwarding of a Srv(De)Reg 511 After sending all new registration states accepted by itself to a 512 peer (via anti-entropy), an MDA directly forwards newly received 513 registration updates from MSAs to the peer until a failure occurs. 515 In Figure 10, when a Srv(De)Reg is directly forwarded from MDA1 to 516 MDA2, its Fwd-ID is set to Fwded, and its accept timestamp is set to 517 its arrival timestamp at MDA1. Note that a direct forwarding is 518 performed asynchronously: MDA1 can send a SrvAck to MSA1 before it 519 forwards the Srv(De)Reg to MDA2. Also note that the direct forwarding 520 of a Srv(De)Reg goes only one-hop from its accept DA to all peers. 522 4.9. SrvAck Message 524 According to [RFC2608], a DA MUST reply with a SrvAck to a Srv(De)Reg 525 when the message is received from an SA. However, an MDA SHOULD NOT 526 reply with a SrvAck to a Srv(De)Reg if the message is received from a 527 peer. This is for efficiency because peers exchange Srv(De)Reg 528 messages via reliable peering connections. Note that an MDA MUST 529 reply with a SrvAck to an AntiEtrpRqst. 531 4.10. Control Information 533 For each registration entry, an MDA maintains the following control 534 information: accept ID (for registration propagation), version 535 timestamp (for registration version resolution - rejecting previous 536 updates), and deletion flag (deregistered or not). 538 For all registration entries, an MDA maintains a summary vector to 539 reflect its received registrations so far. 541 5. Summary 543 mSLP extends SLPv2 with three new definitions: a new attribute - 544 "mesh-enhanced" for DAAdvert, a new message extension - MeshFwd, and 545 a new message type - AntiEtrpRqst. 547 A UA MAY prefer an MDA to a non-MDA since an MDA is more likely to 548 reliably contain the complete set of current service registrations 549 for the UA's scopes. 551 A non-MSA needs to discover and register with all DAs in its scopes. 552 It does not use the MeshFwd extension. 554 A non-MDA accepts Srv(De)Reg(s) from SAs normally. It does not 555 forward them. 557 For all MDAs, an MSA only needs to discover and register with 558 sufficient number of them such that they cover its scopes. It uses 559 the MeshFwd extension when it registers with MDAs. 561 An MDA carries the "mesh-enhanced" attribute keyword in its DAAdvert. 562 It maintains a peer relationship to each peer. It accepts 563 registrations from SAs and peers, propagates registrations via anti- 564 entropy and direct forwarding to peers. 566 6. Protocol Timing Defaults 568 Interval Name Default Value Defined in 569 ------------------- ------------- ----------- 570 CONFIG_DA_KEEPALIVE 200 seconds Section 3.4 571 CONFIG_DA_TIMEOUT 300 seconds Section 3.4 573 7. IANA Considerations 575 The Mesh Forwarding (MeshFwd) extension ID, 0x0006, described in 576 Section 4.3, has been assigned by IANA out of the SLP extension space 577 (RFC 2608, Section 9.1) reserved for "optional to implement" 578 extensions (i.e., the 0x0000-0x3FFF range). 580 The function-ID of the Anti-entropy Request (AntiEtrpRqst) message 581 type, TBD, described in Section 4.6, is to be assigned by IANA in the 582 12-255 range (RFC 2608, Section 15). 584 8. Security Considerations 586 mSLP uses standard SLPv2 authentication. First, an MDA SHOULD 587 authenticate other MDAs before setting up a peer relationship with 588 them so as to prevent any malicious MDA from joining the DA mesh. 589 Second, as a successful attack at an MDA may affect all MDAs in the 590 DA mesh, an MDA SHOULD authenticate MSAs before accepting and 591 forwarding their Srv(De)Reg messages to prevent illegitimate 592 modification or elimination of service registrations. Third, as an 593 MSA depends on the MDA with which it registers to forward its 594 Srv(De)Reg messages, it SHOULD authenticate the MDA to avoid using a 595 malicious MDA. 597 9. Acknowledgments 599 James Kempf, Mike Day, Mikael Pahmp, Ira McDonald, Qiaobing Xie and 600 Xingang Guo provided valuable comments for this document. 602 10. Normative References 604 [RFC2608] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service 605 location protocol, version 2", RFC 2608, June 1999. 607 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 608 requirement levels", BCP 14, RFC 2119, March 1997. 610 11. Non-normative References 612 [RFC1771] Y. Rekhter and T. Li, "A border gateway protocol 4 613 (BGP-4)", RFC 1771, March 1995. 615 [RFC2610] C. Perkins and E. Guttman, "DHCP options for service 616 location protocol", RFC 2610, June, 1999. 618 [EPID-ALGO] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, 619 S. Shenker, H. Sturgis, D. Swinehart and D. Terry, "Epidemic 620 algorithms for replicated database maintenance", the sixth ACM 621 symposium on principles of distributed computing, Vancouver, 622 Canada, 1987. 624 [UPDA-PROP] K. Petersen, M. Spreizer, D. Terry, M. Theimer and 625 A. Demers, "Flexible update propagation for weakly consistent 626 replication", the sixteenth ACM symposium on operating systems 627 principles, Saint Malo, France, 1997. 629 12. Authors' Addresses 631 Weibin Zhao 632 Department of Computer Science 633 Columbia University 634 1214 Amsterdam Avenue, MC 0401 635 New York, NY 10027-7003 637 EMail: zwb@cs.columbia.edu 639 Henning Schulzrinne 640 Department of Computer Science 641 Columbia University 642 1214 Amsterdam Avenue, MC 0401 643 New York, NY 10027-7003 645 EMail: hgs@cs.columbia.edu 647 Erik Guttman 648 Sun Microsystems 649 Eichhoelzelstr. 7 650 74915 Waibstadt 651 Germany 653 EMail: Erik.Guttman@sun.com 655 13. Full Copyright Statement 657 Copyright (C) The Internet Society (2003). All Rights Reserved. 659 This document and translations of it may be copied and furnished to 660 others, and derivative works that comment on or otherwise explain it 661 or assist in its implementation may be prepared, copied, published 662 and distributed, in whole or in part, without restriction of any 663 kind, provided that the above copyright notice and this paragraph are 664 included on all such copies and derivative works. However, this 665 document itself may not be modified in any way, such as by removing 666 the copyright notice or references to the Internet Society or other 667 Internet organizations, except as needed for the purpose of 668 developing Internet standards in which case the procedures for 669 copyrights defined in the Internet Standards process must be 670 followed, or as required to translate it into languages other than 671 English. 673 The limited permissions granted above are perpetual and will not be 674 revoked by the Internet Society or its successors or assigns. 676 This document and the information contained herein is provided on an 677 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 678 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 679 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 680 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 681 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.