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
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Network Working Group J. Luciani
Request for Comments: 2443 Bay Networks
Category: Experimental A. Gallo
IBM
November 1998
<span class="h1">A Distributed MARS Service Using SCSP</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document describes a method for distributing a MARS service
within a LIS[1]. This method uses the Server Cache Synchronization
Protocol (SCSP)[<a href="#ref-2" title=""Server Cache Synchronization Protocol"">2</a>] to synchronize the MARS Server databases within a
LIS. When SCSP is used to synchronize the caches of MARS Servers in
a LIS, the LIS defines the boundary of an SCSP Server Group (SG).
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [<a href="#ref-5" title=""Key Words for use in RFCs to Indicate Requirement Levels,"">5</a>].
The MARS is an extended analog of the ATMARP Server introduced in
[<a href="#ref-4" title=""Classic IP and ARP over ATM"">4</a>]. It provides the necessary connection and addressing services
required by layer 3 multicast services over ATM. There are three
basic elements to the MARS model. First, the MARS Server which
manages and distributes layer 3 group membership information to the
LIS. Second, MARS Clients which register with and query a single MARS
Server for layer 3 multicast information. Third, MCS Clients which
register with a single MARS Server and provide layer 3 multicast
forwarding services for a LIS.
Both MARS Clients and MCS Clients explicitly register with the MARS
Server before exchanging layer 3 multicast information. During the
registration process MARS Clients are place on the Cluster Control VC
<span class="grey">Luciani & Gallo Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
(CCVC) and MCS Clients are placed on the Server Control VC (SCVC).
Both the CCVC and SCVC are then used to propagate layer 3 multicast
updates to the clients which make up a LIS. During the registration
process MARS Clients are also assigned a unique Cluster Member ID
(CMI) which is used to identify reflected packets in the presence of
MCS Clients.
In the Distributed MARS Model there MAY be multiple MARS Servers in a
given LIS, and since any MARS Server within the LIS MUST be able to
provide layer 3 multicast information about any multicast group
within the LIS, there MUST be a method by which to synchronize
multicast information across all MARS Servers within the LIS.
The Server Cache Synchronization Protocol (SCSP) solves the
generalized server synchronization/cache-replication problem for
distributed databases, and thus SCSP MAY be applied to the MARS
Server database synchronization problem within a LIS. When SCSP is
used to synchronize the caches of MARS Servers in a LIS, the LIS
defines the boundary of and SCSP Server Group (SG).
SCSP is defined in two parts: the protocol independent part and the
client/server protocol specific part. The protocol independent part
is specified in [<a href="#ref-2" title=""Server Cache Synchronization Protocol"">2</a>] whereas this document will specify the
client/server protocol specific part where the MARS Server is the
client/server protocol.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Overview</span>
All MARS Servers belonging to a LIS are said to belong to a Server
Group (SG). A SG is identified by, not surprisingly, its SGID which
is contained in a field in all SCSP packets. All SCSP packets contain
a Protocol ID (PID) field as well. This PID field is set to 0x0003 to
signify that SCSP is synchronizing MARS Server databases as opposed
to synchronizing some other protocol's databases. (see Section
B.2.0.1 of [<a href="#ref-2" title=""Server Cache Synchronization Protocol"">2</a>] for more details). In general, PIDs for SCSP will be
assigned by IANA upon request given that a client/server protocol
specific specification has been written. In the case of MARS Servers,
the client/server protocol specific specification was written at the
same time as SCSP, and thus a PID=0x0003 was assigned in [<a href="#ref-2" title=""Server Cache Synchronization Protocol"">2</a>].
SCSP places no topological requirements upon a MARS Server SG.
Obviously, however, the resultant graph of MARS Servers must span the
set of MARS Servers being synchronized. For more information about
the client/server protocol independent part of SCSP, the reader is
encouraged to see [<a href="#ref-2" title=""Server Cache Synchronization Protocol"">2</a>].
<span class="grey">Luciani & Gallo Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
When a SG is using SCSP for synchronization, a MARS Client or MCS
Client will register with only one MARS Server although it is allowed
to choose any MARS Server in the SG for this registration. At
registration time the MARS Client or MCS Client will be added to that
MARS Servers respective CCVC or SCVC. Also, MARS Clients will be
issued a unique CMI for the entire LIS. This document assumes at a
minimum each MARS Server in the SG will be configured with a unique
range of CMIs to assign to clients registering with that MARS Server.
Use of some external means for allocating CMIs to MARS Servers in a
SG is possible but beyond the scope of this document.
When a MARS Client or MCS Client successfully registers with a MARS
Server in the SG that MARS Server will propagate the registration
information to its peer MARS Servers. The same propagation will occur
for any subsequent group membership information learned from the
clients. The peer MARS Server will then update its group membership
database and propagate the information out its own CCVC or SCVC if
needed.
In the case of a MARS Server failure all peer MARS Servers in the SG
MUST flush the client/group membership information learned from the
failed MARS Server. The clients belonging to the failed MARS Servers
CCVC and SCVC will migrate to the next available MARS Server as
specified in Section 5.3 of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>]. When a client detects a failure of
its MARS, it steps to the next backup MARS Server and attempts to
register with the server. If the registration is successful the
client will re-join all of its previous group membership information.
If the registration fails, the process repeats until a functional
MARS Server is found.
Determining the operational state of a MARS Servers in a SG requires
that each MARS Server send out an "alive" or "heartbeat" message
similar to the MARS Redirect message sent out on the CCVC or SCVC for
MARS Clients. However, this message will only be sent to MARS Servers
in the SG and is from here on defined as the MARS Server Redirect
Entry.
In order to detect that a MARS Server failure has occurred each
server MUST update it's MARS Server Redirect Entry state at least
every 2 minutes, it is RECOMMENDED that it is updated every 1 minute.
Failure to receive two consecutive MARS Server Redirect Entry updates
from a given MARS Server in the SG will cause all membership
information learned from this server to be flushed. The MARS Server
Redirect Entry state is also used to create the MARS_REDIRECT_MAP
messages sent out on CCVC for each MARS Server in the SG. The
ordering of each server learned will be based on the MARS Servers
SCSP Sender ID. The ordering of the MARS_REDIRECT_MAP will first
<span class="grey">Luciani & Gallo Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
contain the list of MARS Servers learned via MARS Server Redirect
Entry updates in ascending order based on the SCSP Sender ID,
followed by any externally configured or learned backup MARS Servers.
In the case of a MARS Client or MCS Client failure where the client
is unexpectedly removed from the CCVC or SCVC the MARS Server MUST
notify its peer SG members via a proxy deregister for that client.
Upon receiving a proxy deregister request from a peer SG member all
membership information for the deregistering client MUST be removed.
Any Clients sending multicast data to the failed client should also
receive an unexpected removal of this client which will intern cause
the sending client to revalidate the multicast groups current
membership as outlined in Section 5.1.5.1 of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Format of the CSA Record MARS Specific Part</span>
CSA Records in SCSP contain a "Client/Server Protocol Specific Part"
which contains the non-protocol independent information for a given
server's cache entry.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP | Unused | Version | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Cluster Member ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM SubAddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hardware Type
Defines the type of "link layer" addresses being carried. This
value is the ATM Forum 'address family number' specified in [<a href="#ref-3" title=""Assigned Numbers"">3</a>] as
15 decimal (0x000F). This is the mar$afn field defined in [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
<span class="grey">Luciani & Gallo Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
Protocol Type
This field is the protocol type number for the protocol using MARS
from [<a href="#ref-3" title=""Assigned Numbers"">3</a>]. (IPv4 is 0x0800). This is the mar$pro.type field from
[<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Protocol SNAP
This field is the optional protocol SNAP extension to protocol
type. This is the mar$pro.snap field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Version Number
0 MARS Specific part of the CSA record.
0x01 Reserved for NHRP.
0x02 - 0xEF Reserved for future use by the IETF.
0xF0 - 0xFE Allocated for use by the ATM Forum.
0xFF Experimental/Local use.
Version Number for this document MUST be set to 0x00.
State
1 MARS Server Redirect Entry.
2 MCS Serve/Register request.
3 MARS Client Join/Register request.
4 MARS Client Leave/Deregister request.
5 MCS Unserve/Deregister request.
All other State values should cause the CSA to be discarded.
Flags
The flags field is used to contain several flags and is similar to
the mar$flags field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
mar$flags
Bit 15 - mar$flags.layer3grp
Bit 13 - mar$flags.register
Bit 0-7 - mar$flags.sequence
All remaining bits are reserved and MUST be zero. The
mars$flags.sequence field is of local significance only to the
Local Server (LS).
Cluster Member CMI
This field contains the CMI which uniquely identifies each endpoint
within a LIS. This is the mar$cmi field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Src Addr Len
This field contains the length of the Source Protocol Address
field. For IPv4, the value is 4 if an address is specified. A null
(non-existent) address MUST be coded as zero length, and no space
allocated for it in the message body. This is the mar$spln field
from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
<span class="grey">Luciani & Gallo Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
Group Addr Len
This field contains the length of the Group Protocol Address field.
For IPv4, the value is 4 if an address is specified. A null (non-
existent) address MUST be coded as zero length, and no space
allocated for it in the message body. This is the mar$tpln field
from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
ATM Addr T/L
This field contains the type and length of the Source ATM Address
field. The type and length encoding is described in Section 5.1.2
of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
ATM SubAddr T/L
This field contains the type and length of the Source ATM
SubAddress field. The type and length encoding is described in
Section 5.1.2 of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Source Protocol Address
This is the internetwork address for the source of an address
binding in a MARS server cache entry. If null, no storage will be
allocated. This is the mar$spa field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Source ATM Address
This is the Source's ATM address of an address binding in a MARS
server cache entry. The address, if specified, is E.164 or ATM
Forum NSAPA. This is the mar$sha field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Source ATM SubAddress
This is the Source's ATM subaddress of an address binding in a MARS
server cache entry. The subaddress, if specified, is an ATM Forum
NSAPA. If null, no storage will be allocated. This is the mar$ssa
field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Minimum Multicast Group Address
This is the internetwork address of the lower bound on the range of
multicast group addresses for the address binding in a MARS server
cache entry. If null, no storage will be allocated. This is the
mar$min.N field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Maximum Multicast Group Address
This is the internetwork address of the upper bound on the range of
multicast group addresses for the address binding in a MARS server
cache entry. If null, no storage will be allocated. This is the
mar$max.N field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
<span class="grey">Luciani & Gallo Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Values for SCSP Protocol Independent Part</span>
The following sections give values for fields of the SCSP Protocol
Independent Part of the various SCSP messages.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Values for the SCSP "Mandatory Common Part"</span>
Protocol ID = 0x0003
Sender ID Len = 0x04
Recvr ID Len = 0x04
See Section B.2.0.1 of [<a href="#ref-2" title=""Server Cache Synchronization Protocol"">2</a>] for a detailed description of these
fields.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a> Values for the SCSP "CSAS Record"</span>
Cache Key Len = 0x04
Orig ID Len = 0x04
See Section B.2.0.2 of [<a href="#ref-2" title=""Server Cache Synchronization Protocol"">2</a>] for a detailed description of these
fields.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Detailed State Descriptions</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a> MARS Server Redirect Entry.</span>
The MARS Server Redirect Entry is used to determine the operational
state of a MARS Server in the SG. Each server MUST update it's MARS
Server Redirect Entry state at least every 2 minutes, it is
RECOMMENDED that it is updated every 1 minute.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP | Unused | Version | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Cluster Member ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM SubAddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Luciani & Gallo Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
Hardware Type
This value is the ATM Forum 'address family number' specified in
[<a href="#ref-3" title=""Assigned Numbers"">3</a>] as 15 decimal (0x000F).
Protocol Type
This field is the protocol type number for the protocol using MARS
from [<a href="#ref-3" title=""Assigned Numbers"">3</a>]. (IPv4 is 0x0800).
Protocol SNAP
This field is the optional protocol SNAP extension to protocol
type. This is the mar$pro.snap field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Version Number
Version Number for this document MUST be set to 0x00.
State
State value is coded as 1 decimal for a MARS Server Redirect Entry.
The Flags, Cluster Member ID, Src Addr Len, and Group Addr Len fields
are unused and set to zero.
The ATM Addr T/L, ATM SubAddr T/L, Source ATM Address, and Source ATM
SubAddress fields define the ATM address for the source of the MARS
Server Redirect Entry in the SG. The coding for these fields are the
same as described in <a href="#section-3">Section 3</a> of this document.
Failure to receive two consecutive MARS Server Redirect Entry updates
from a given MARS Server in the SG will cause all membership
information learned from this server to be flushed. When a valid MARS
Server Redirect Entry update is received the source of this update
will be placed into the table of backup MARS Servers sent in the
MARS_REDIRECT_MAP message. The ordering of servers in the
MARS_REDIRECT_MAP will first contain the list of MARS Servers learned
via MARS Server Redirect Entry updates in ascending order based on
the SCSP Sender ID, followed by any externally configured or learned
backup MARS Servers. The format of the MARS_REDIRECT_MAP can be found
in Section 5.4.3 of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a> MCS Serve/Register request.</span>
The MCS Serve/Register request is used to propagate the registering
or servicing of specific groups by an MCS Client within the SG
domain. It is similar to an MARS_MSERV request defined in <a href="#section-6.2.2">Section</a>
<a href="#section-6.2.2">6.2.2</a> and 6.2.3 of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>]. When a MARS Server in the SG successfully
adds a new MCS Client to it's SCVC or adds MCS support for a specific
group it MUST send a MCS Serve/Register request to the SG. An MCS
Client can only register with one MARS Server in the SG.
<span class="grey">Luciani & Gallo Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP | Unused | Version | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Cluster Member ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM SubAddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hardware Type
This value is the ATM Forum 'address family number' specified in
[<a href="#ref-3" title=""Assigned Numbers"">3</a>] as 15 decimal (0x000F).
Protocol Type
This field is the protocol type number for the protocol using MARS
from [<a href="#ref-3" title=""Assigned Numbers"">3</a>]. (IPv4 is 0x0800).
Protocol SNAP
This field is the optional protocol SNAP extension to protocol
type. This is the mar$pro.snap field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Version Number
Version Number for this document MUST be set to 0x00.
State
State value is coded as 2 decimal for a MCS Serve/Register request.
Flags
The flags field is used to contain several flags:
<span class="grey">Luciani & Gallo Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
mar$flags
Bit 15 - mar$flags.layer3grp
Bit 13 - mar$flags.register
Bit 0-7 - mar$flags.sequence
The mar$flags.register bit MUST be set the same as in the
originating MARS_MSERV request. The mar$flags.layer3grp bit MUST be
zero and the mar$flags.sequence bits are of local significance only
to the LS.
Cluster Member CMI
This field contains the CMI assigned by the MARS Server which
processed the MARS_MSERV request and uniquely identifies the MCS
Client in the MARS server cache.
Src Addr Len
This field contains the length of the Source Protocol Address
field. For IPv4, the value is 4 if an address is specified. A null
(non-existent) address MUST be coded as zero length, and no space
allocated for it in the message body.
Group Addr Len
This field contains the length of the Group Protocol Address field.
If the register bit in the flags field is set to 1 in the request
this field MUST be zero. If the register bit is zero in the flags
field the value of this field for IPv4 is 4.
ATM Addr T/L
This field contains the type and length of the Source ATM Address
field for the MCS Client that originated the MARS_MSERV request.
The type and length encoding is described in <a href="#section-3">Section 3</a>.
ATM SubAddr T/L
This field contains the type and length of the Source ATM
SubAddress field for the MCS Client that originated the MARS_MSERV
request. The type and length encoding is described in <a href="#section-3">Section 3</a>.
Source Protocol Address
This is the internetwork address for the source of an address
binding in a MARS server cache entry. If Src Addr Len is set to
zero no storage will be allocated.
Source ATM Address
This is the MCS Client's ATM address of an address binding in a
MARS server cache entry. The address is E.164 or ATM Forum NSAPA.
<span class="grey">Luciani & Gallo Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
Source ATM SubAddress
This is the MCS Client's ATM subaddress of an address binding in a
MARS server cache entry. The subaddress, if specified, is an ATM
Forum NSAPA. If null, no storage will be allocated.
Minimum Multicast Group Address
This is the internetwork address of the lower bound on the range of
multicast group addresses for the address binding in a MARS server
cache entry. If Group Addr Len is set to zero no storage will be
allocated.
Maximum Multicast Group Address
This is the internetwork address of the upper bound on the range of
multicast group addresses for the address binding in a MARS server
cache entry. If Group Addr Len is set to zero no storage will be
allocated.
An MCS Client can only register with one MARS Server in the SG and is
only placed on the SCVC for the MARS Server for which it is
registered with.
When a MCS Client Serve/Register request specifying a group address
is received by a MARS Server it MUST create a cache entry associated
with this client. In addition to adding the cache entry it MUST send
out a MARS_MIGRATE message on it's CCVC. This is needed so that
clients using a mesh topology can migrate to a server based topology.
Details regarding the MARS_MIGRATE message can be found in <a href="#section-5.1.6">Section</a>
<a href="#section-5.1.6">5.1.6</a> of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a> MARS Client Join/Register request.</span>
The MARS Client Join/Register request is used to propagate the
registering or joining of specific group ranges by MARS Clients
within the SG domain. It is similar to the MARS_JOIN request defined
in Sections <a href="#section-5.2.1">5.2.1</a> to <a href="#section-5.2.3">5.2.3</a> of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>]. When a MARS Server in the SG
successfully registers a new MARS Client or a registered client joins
a specific group address range the MARS Server MUST send a MARS
Client Join/Register request to the SG. A MARS Client can only
register with one MARS Server in the SG and is placed only on that
servers CCVC.
<span class="grey">Luciani & Gallo Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Type | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SNAP | Unused | Version | State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Cluster Member ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr Len | Group Addr Len| ATM Addr T/L |ATM SubAddr T/L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ATM SubAddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Multicast Group Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hardware Type
This value is the ATM Forum 'address family number' specified in
[<a href="#ref-3" title=""Assigned Numbers"">3</a>] as 15 decimal (0x000F).
Protocol Type
This field is the protocol type number for the protocol using MARS
from [<a href="#ref-3" title=""Assigned Numbers"">3</a>]. (IPv4 is 0x0800).
Protocol SNAP
This field is the optional protocol SNAP extension to protocol
type. This is the mar$pro.snap field from [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>].
Version Number
Version Number for this document MUST be set to 0x00.
State
State value is coded as 3 decimal for a MARS Client Join/Register
request.
<span class="grey">Luciani & Gallo Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
Flags
The flags field is used to contain several flags:
mar$flags
Bit 15 - mar$flags.layer3grp
Bit 13 - mar$flags.register
Bit 0-7 - mar$flags.sequence
The mars$flags.layer3grp and mar$flags.register bits MUST be set
the same as in the originating MARS_JOIN request. The
mar$flags.sequence bits are of local significance only to the LS.
Cluster Member CMI
This field contains the CMI assigned by the MARS Server which
processed the MARS_JOIN request and uniquely identifies the MARS
Client in the MARS server cache.
Src Addr Len
This field contains the length of the Source Protocol Address
field. For IPv4, the value is 4 if an address is specified. A null
(non-existent) address MUST be coded as zero length, and no space
allocated for it in the message body.
Group Addr Len
This field contains the length of the Group Protocol Address field.
If the register bit in the flags field is set to 1 in the request
this field MUST be zero. If the register bit is zero in the flags
field the value of this field for IPv4 is 4.
ATM Addr T/L
This field contains the type and length of the Source ATM Address
field for the MARS Client that originated the MARS_JOIN request.
The type and length encoding is described in <a href="#section-3">Section 3</a>.
ATM SubAddr T/L
This field contains the type and length of the Source ATM
SubAddress field for the MARS Client that originated the MARS_JOIN
request. The type and length encoding is described in <a href="#section-3">Section 3</a>.
Source Protocol Address
This is the internetwork address for the source of an address
binding in a MARS server cache entry. If Src Addr Len is set to
zero no storage will be allocated.
Source ATM Address
This is the MARS Client's ATM address of an address binding in a
MARS server cache entry. The address is E.164 or ATM Forum NSAPA.
<span class="grey">Luciani & Gallo Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
Source ATM SubAddress
This is the MARS Client's ATM subaddress of an address binding in a
MARS server cache entry. The subaddress, if specified, is an ATM
Forum NSAPA. If null, no storage will be allocated.
Minimum Multicast Group Address
This is the internetwork address of the lower bound on the range of
multicast group addresses for the address binding in a MARS server
cache entry. If Group Addr Len is set to zero no storage will be
allocated.
Maximum Multicast Group Address
This is the internetwork address of the upper bound on the range of
multicast group addresses for the address binding in a MARS server
cache entry. If Group Addr Len is set to zero no storage will be
allocated.
An MARS Client can only register with one MARS Server in the SG and
is only placed on the CCVC for the MARS Server for which it is
registered with. If the mar$flags.layer3grp is set to 1 than the
Minimum and Maximum Multicast Group Addresses MUST be equal for IPv4.
When a MARS Client Join/Register request is sent with the
mar$flags.register bit set to 1 all of the servers in the SG will
create a cache entry for this client using the information in the
request.
When a registered MARS Client issues a MARS_JOIN for a specific group
address range a MARS Client Join/Register request MUST be sent to the
servers in the SG. The actions taken by each server in the SG depend
on previous group membership actions and MCS supported groups.
Each MARS Server MUST perform the necessary redistribution and hole
punching algorithms before propagating this request to the CCVC and
SCVC on each server. The redistribution and hole punching algorithms
used for propagating join requests to the CCVC are the same as
defined in Sections <a href="#section-6.1.2">6.1.2</a> and <a href="#section-6.2.4">6.2.4</a> of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>]. If the originating
MARS_JOIN request is a duplicate of a previously joined range or
contains no group address range than a MARS Client Join/Register MUST
NOT be sent to the SG.
The redistribution and hole punching algorithms used for propagating
join requests as MARS_SJOIN request on a SCVC is the same as <a href="#section-6.2.4">Section</a>
<a href="#section-6.2.4">6.2.4</a> except for the following. Only the MARS Servers which contain
the registered MCS Clients for the target group ranges should
propagate this information to their SCVCs.
<span class="grey">Luciani & Gallo Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a> MARS Client Leave/Deregister request.</span>
The MARS Client Leave/Deregister request is used to propagate the
deregistering or leaving of specific group ranges by registered MARS
Clients within the SG domain. It is similar to the MARS_LEAVE request
defined in Sections <a href="#section-5.2.1">5.2.1</a> to <a href="#section-5.2.3">5.2.3</a> of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>]. When a MARS Server in the
SG successfully deregisters a registered MARS Client or a registered
client leaves a specific group address range for which it had joined
the MARS Server MUST send a MARS Client Leave/Deregister request to
the SG. If a registered MARS Client is unexpectedly removed from the
CCVC the MARS Server MUST act as a proxy and send a MARS Client
Leave/Deregister request to the SG.
The format and meanings of the fields in a MARS Client
Leave/Deregister request are the same as in <a href="#section-5.3">Section 5.3</a> except the
State is coded as 4 decimal for a MARS Client Leave/Deregister
request.
When a MARS Client Leave/Deregister request is sent with the
mar$flags.register bit set to 1 all of the servers in the SG
receiving this update MUST purge all cache entries for this client.
When a registered MARS Client issues a MARS_LEAVE for a specific
group address range a MARS Client LEAVE/Deregister request MUST be
sent to the servers in the SG. The actions taken by each server in
the SG depend on previous group membership actions and MCS supported
groups.
Each MARS Server MUST perform the necessary redistribution and hole
punching algorithms before propagating this request to the CCVC and
SCVC on each server. The redistribution and hole punching algorithms
used for propagating leave requests to the CCVC are the same as
defined in Sections <a href="#section-6.1.2">6.1.2</a> and <a href="#section-6.2.4">6.2.4</a> of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>]. If the originating
MARS_LEAVE request does not correspond to a previously joined range
or contains no group address range than a MARS Client
Leave/Deregister MUST NOT be sent to the SG.
The redistribution and hole punching algorithms used for propagating
leave requests as MARS_SLEAVE requests on a SCVC is the same as
<a href="#section-6.2.4">Section 6.2.4</a> except for the following. Only the MARS Servers which
contain the registered MCS Clients for the target group ranges should
propagate this information to their SCVCs.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a> MCS Unserve/Deregister request.</span>
The MCS Unserve/Deregister request is used to propagate the
deregistering or unservicing of specific groups by a registered MCS
Client within the SG domain. It is similar to an MARS_MUNSERV request
<span class="grey">Luciani & Gallo Experimental [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
defined in <a href="#section-6.2.2">Section 6.2.2</a> and 6.2.3 of [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>]. When a MARS Server in the
SG successfully deregisters a registered MCS Client or registered MCS
Client stops serving a specific group address range for which it had
serviced the MARS Server MUST send a MCS Unserve/Deregister request
to the SG. If a registered MCS Client is unexpectedly removed from
the SCVC the MARS Server owning the SCVC MUST act as a proxy and send
a MCS Unserve/Deregister request to the SG.
The format and meanings of the fields in a MCS Unserve/Deregister
request are the same as in <a href="#section-5.2">Section 5.2</a> except the State is coded as 5
decimal for a MCS Unserve/Deregister request.
When a MCS Client Unserve/Deregister request is sent with the
mar$flags.register bit set to 1 all of the servers in the SG
receiving this update MUST purge all cache entries for this client.
When a registered MCS Client issues a MARS_MUNSERV for a specific
group address range being served a MCS Client Unserve/Deregister
request MUST be sent to the servers in the SG. The members of the SG
that receive this update must then clear the cache entry associated
with this MCS Client.
In addition to clearing one or more cache entries associated with
receiving a MCS Client Unserve/Deregister request each MARS Server
in the SG MUST send out a MARS_LEAVE message on it's CCVC in order
for clients to change back to a mesh topology.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
There is no mechanism to encrypt the CSA Record MARS Specific Part of
the message exchanged between servers. However, there are base SCSP
security features in the SCSP Protocol Independent part [<a href="#ref-2" title=""Server Cache Synchronization Protocol"">2</a>] which can
be used to protect against attacks.
Any SCSP MARS is susceptible to Denial of Service (DOS) attacks. A
rouge MARS Client can inundate its Server with MARS packets. This is
a base MARS problem as currently defined by [<a href="#ref-1" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">1</a>]. A rouge host can
also inundate its neighboring SCSP MARS with SCSP packets. However,
if the authentication option is used, the SCSP MARS databases will
not become corrupted, as the bogus packets will be discarded when the
authentication check fails.
Due to the pair wise authentication model of SCSP MARS, the
information received from any properly authenticated server is
trusted and propagated throughout the server group. Consequently, if
security of any SCSP MARS server is compromised, the entire database
becomes vulnerable to corruption originating from the compromised
server.
<span class="grey">Luciani & Gallo Experimental [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
References
[<a id="ref-1">1</a>] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", <a href="./rfc2022">RFC 2022</a>, November 1996.
[<a id="ref-2">2</a>] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server
Cache Synchronization Protocol", <a href="./rfc2334">RFC 2334</a>, April 1998.
[<a id="ref-3">3</a>] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, <a href="./rfc1700">RFC 1700</a>,
October 1994. See also: <a href="http://www.iana.org/numbers.html">http://www.iana.org/numbers.html</a>
[<a id="ref-4">4</a>] Laubach, M., "Classic IP and ARP over ATM", <a href="./rfc1577">RFC 1577</a>, January
1994.
[<a id="ref-5">5</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.
Acknowledgments
The authors would like to thank Grenville Armitage for his previous
distributed MARS work and also the members of the ION working group
of the IETF, whose review and discussion of this document has been
invaluable.
Authors' Addresses
James V. Luciani
Bay Networks, Inc.
3 Federal Street, BL3-04
Billerica, MA 01821
Phone: +1-508-916-4734
EMail: luciani@baynetworks.com
Anthony M. Gallo
IBM, Networking Hardware Division
Dept. M6LA/B664
P.O. Box 12195
Research Triangle Park, NC 27709
Phone: +1-919-254-9889
EMail: gallo@raleigh.ibm.com
<span class="grey">Luciani & Gallo Experimental [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc2443">RFC 2443</a> MARS Service Using SCSP November 1998</span>
Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.
Luciani & Gallo Experimental [Page 18]
</pre>
|
