1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
|
<pre>Network Working Group W. Zhao
Request for Comments: 3528 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
April 2003
<span class="h1">Mesh-enhanced Service Location Protocol (mSLP)</span>
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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Notation Conventions . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.2">1.2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Compatibility . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Scope-based Fully-meshed Peering DA Architecture . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Peer Relationship Management . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. Learning about New Peers . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Establishing a Peering Connection . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. Exchanging Information about Existing Peers . . . . . . <a href="#page-6">6</a>
<a href="#section-3.4">3.4</a>. Maintaining a Peer Relationship . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.5">3.5</a>. Tearing Down a Peer Relationship . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. Registration Propagation Control . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. Accept ID and Propagation Order . . . . . . . . . . . . <a href="#page-7">7</a>
4.2. Version Timestamp and Registration Version Resolution . 8
<span class="grey">Zhao, et al. Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
<a href="#section-4.3">4.3</a>. Mesh Forwarding Extension . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.4">4.4</a>. Summary Vector . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.5">4.5</a>. Service Deregistration . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.6">4.6</a>. Anti-entropy Request Message . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.7">4.7</a>. Anti-entropy . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.8">4.8</a>. Direct Forwarding . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.9">4.9</a>. SrvAck Message . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.10">4.10</a>. Control Information . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6">6</a>. Protocol Timing Defaults . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-9">9</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-11">11</a>. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-12">12</a>. Full Copyright Statement . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
In the Service Location Protocol (SLPv2 [<a href="./rfc2608" title=""Service Location Protocol, Version 2"">RFC2608</a>]), 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 [<a href="./rfc1771" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC1771</a>]). 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.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Notation Conventions</span>
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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Zhao, et al. Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terminology</span>
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 (<a href="#section-4.3">Section 4.3</a>) 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.
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Compatibility</span>
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 <a href="./rfc2608">RFC 2608</a> [<a href="./rfc2608" title=""Service Location Protocol, Version 2"">RFC2608</a>]. For simplicity and
<span class="grey">Zhao, et al. Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
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 <a href="./rfc2608">RFC 2608</a>
MDA <--> SA DA <--> SA <a href="./rfc2608">RFC 2608</a>
MDA <--> UA DA <--> UA <a href="./rfc2608">RFC 2608</a>
MSA <--> DA SA <--> DA <a href="./rfc2608">RFC 2608</a>
MSA <--> UA SA <--> UA <a href="./rfc2608">RFC 2608</a>
Table 1. Interactions involving an MDA or MSA
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Scope-based Fully-meshed Peering DA Architecture</span>
(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
<span class="grey">Zhao, et al. Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
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".
<span class="grey">Zhao, et al. Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Peer Relationship Management</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Learning about New Peers</span>
An MDA can learn about new peers via static configuration, DHCP
[<a href="./rfc2610" title=""DHCP Options for Service Location Protocol"">RFC2610</a>], and DAAdvert multicast and unicast. In any case, an MDA
MUST get a peer's DAAdvert before establishing a peer relationship to
the peer.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Establishing a Peering Connection</span>
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
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Exchanging Information about Existing Peers</span>
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).
<span class="grey">Zhao, et al. Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
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
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Maintaining a Peer Relationship</span>
+------+ 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 (<a href="#section-6">Section 6</a>).
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Tearing Down a Peer Relationship</span>
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Registration Propagation Control</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Accept ID and Propagation Order</span>
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.
<span class="grey">Zhao, et al. Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
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.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Version Timestamp and Registration Version Resolution</span>
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).
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Mesh Forwarding Extension</span>
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.
<span class="grey">Zhao, et al. Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
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.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Summary Vector</span>
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.
<span class="grey">Zhao, et al. Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Service Deregistration</span>
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.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Anti-entropy Request Message</span>
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
<span class="grey">Zhao, et al. Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
registration states originally accepted by MDA1 and MDA3, plus those
originally accepted by MDA2 and having an accept timestamp greater
than T2.
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. Anti-entropy</span>
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
<span class="h3"><a class="selflink" id="section-4.8" href="#section-4.8">4.8</a>. Direct Forwarding</span>
+------+ 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.
<span class="grey">Zhao, et al. Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
<span class="h3"><a class="selflink" id="section-4.9" href="#section-4.9">4.9</a>. SrvAck Message</span>
According to [<a href="./rfc2608" title=""Service Location Protocol, Version 2"">RFC2608</a>], 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.
<span class="h3"><a class="selflink" id="section-4.10" href="#section-4.10">4.10</a>. Control Information</span>
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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Summary</span>
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.
<span class="grey">Zhao, et al. Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Protocol Timing Defaults</span>
Interval Name Default Value Defined in
------------------- ------------- -----------
CONFIG_DA_KEEPALIVE 200 seconds <a href="#section-3.4">Section 3.4</a>
CONFIG_DA_TIMEOUT 300 seconds <a href="#section-3.4">Section 3.4</a>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
The Mesh Forwarding (MeshFwd) extension ID, 0x0006, described in
<a href="#section-4.3">Section 4.3</a>, has been assigned by IANA out of the SLP extension space
(<a href="./rfc2608#section-9.1">RFC 2608, Section 9.1</a>) 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 <a href="#section-4.6">Section 4.6</a>, has been assigned by IANA (<a href="./rfc2608">RFC</a>
<a href="./rfc2608">2608</a>, <a href="#section-15">Section 15</a>).
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
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.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>
Thomas Narten, James Kempf, Mike Day, Mikael Pahmp, Ira McDonald,
Qiaobing Xie and Xingang Guo provided valuable comments for this
document.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC2608">RFC2608</a>] Guttman, E., Perkins, C., Veizades, J. and M. Day,
"Service Location Protocol, Version 2", <a href="./rfc2608">RFC 2608</a>, June
1999.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Zhao, et al. Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-RFC1771">RFC1771</a>] Rekhter, R. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", <a href="./rfc1771">RFC 1771</a>, March 1995.
[<a id="ref-RFC2610">RFC2610</a>] Perkins, C. and E. Guttman, "DHCP Options for Service
Location Protocol", <a href="./rfc2610">RFC 2610</a>, June, 1999.
[<a id="ref-EPID-ALGO">EPID-ALGO</a>] 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.
[<a id="ref-UPDA-PROP">UPDA-PROP</a>] 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.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Authors' Addresses</span>
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
<span class="grey">Zhao, et al. Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3528">RFC 3528</a> Mesh-enhanced Service Location Protocol (mSLP) April 2003</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Full Copyright Statement</span>
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]
</pre>
|
