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
|
<pre>Network Working Group R. Finlayson
Request for Comments: 2771 LIVE.COM
Category: Informational February 2000
<span class="h1">An Abstract API for Multicast Address Allocation</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes the "abstract service interface" for the
dynamic multicast address allocation service, as seen by
applications. While it does not describe a concrete API (i.e., for a
specific programming language), it describes - in abstract terms -
the semantics of this service, including the guarantees that it makes
to applications.
Additional documents (not necessarily products of the IETF) would
describe concrete APIs for this service.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Applications are the customers of a multicast address allocation
service, so a definition of this service should include not only the
inter-node network protocols that are used to implement it, but also
the 'protocol' that applications use to access the service. While
APIs ("application programming interfaces") for specific programming
languages (or operating systems) are outside the domain of the IETF,
it is appropriate for us to define - in abstract terms - the semantic
interface that this service presents to applications. Specific APIs
would then be based upon this abstract service interface.
Note that it is possible to implement the multicast address
allocation service in at least two different ways. The first (and
perhaps most common) way is for end nodes to allocate addresses by
communicating with a separate "Address Allocation Server" node, using
the "Host to Address Allocation Server" network protocol (MADCAP)
[<a href="#ref-1" title=""Multicast Address Dynamic Client Allocation Protocol (MADCAP)"">1</a>][7]. Alternatively, an "Address Allocation Server" implementation
<span class="grey">Finlayson Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
might be co-located (along with one or more applications) on an end
node, in which case some other, internal, mechanism might be used to
access the server. In either case, however, the abstract service
interface (and, presumably, any specific APIs) would remain the same.
The remainder of this document describes the abstract interface.
Note that this interface is intended only for the allocation of
dynamic multicast addresses, as used by the traditional multicast
service model [<a href="#ref-2" title=""Host Extensions for IP Multicasting"">2</a>]. Future multicast service models might allocate or
assign multicast addresses in other ways, but this is outside the
scope of this document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Abstract Data Types</span>
The interface described below uses the following abstract data types:
- AddressFamily: e.g., IPv4 or IPv6
- MulticastAddress: An actual multicast address (i.e., that could
subsequently be used as the destination of a datagram)
- MulticastAddressSet: A set of "MulticastAddress"es
- LanguageTag: The code for a (human) language, as defined in [<a href="#ref-4" title=""Tags for the Identification of Languages"">4</a>]
- Scope: An "administrative scope" [<a href="#ref-3" title=""Administratively Scoped IP Multicast"">3</a>] from which multicast
addresses are to be allocated. Each scope is a
"MulticastAddressSet", with an associated set of
(character-string) names - indexed by "LanguageTag". (Each
language tag has at most one corresponding name, per
scope.) For each scope, a (language tag, name) pair may be
defined to be the 'default' name for this scope. (See the
section "Querying the name of a scope" below.)
(An implementation of this abstract data type might also
include other information, such as a default TTL for the
scope.)
- Time: An (absolute) event time. This is used for specifying the
"lifetime" of multicast addresses: the period of time during
which allocated multicast addresses are guaranteed to be
available. (It is also used to specify the desired start
time for an "advance allocation".)
<span class="grey">Finlayson Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
Note that a concrete API might prefer to specify some of
these times as relative times (i.e., relative to the current
time-of-day), rather than absolute time. (Relative times
have the advantage of not requiring clock synchronization.)
- Lease: A compound data type that describes the result of a
(successful) multicast address allocation. It consists of:
- [MulticastAddressSet] The set of addresses that were
allocated;
- [AddressFamily] The address family of these addresses
- [Time] The lifetime of these addresses (the same for
each address)
- [Time] The "start time" of the allocation. (See the
discussion of "advance allocation" below.) (A concrete
API would likely also include a MADCAP "Lease
Identifier" [<a href="#ref-1" title=""Multicast Address Dynamic Client Allocation Protocol (MADCAP)"">1</a>].)
- NestingRelationship: A binary data type that describes whether or
not two scopes nest. Two scopes nest if
traffic sent sent to a multicast group within
one scope could be seen by all hosts present
within the other scope were they to join the
multicast group within the first scope. This
value would be "False" for overlapping scopes
where only some (or none) of the hosts within
the second scope could see traffic sent to an
address due to the presence of an
administratively scoped boundary. In cases
where the first and second scopes are
topologically identical this value would be
"True."
- Status: A result code.
<span class="grey">Finlayson Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The Abstract Interface</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Allocating multicast addresses:</span>
alloc_multicast_addr(in AddressFamily family,
in Scope scope,
in Integer minDesiredAddresses,
in Integer maxDesiredAddresses,
in Time minDesiredStartTime,
in Time maxDesiredStartTime,
in Time minDesiredLifetime,
in Time maxDesiredLifetime,
out Lease multicastAddressSetLease,
out Status status)
This operation attempts to allocate a set of multicast addresses (the
size of this set is in the range [minDesiredAddresses,
maxDesiredAddresses]) within the given address family and scope, and
within a given range of desired lifetimes. ("minDesiredStartTime"
and "maxDesiredStartTime" are used to specify "advance allocation";
this is described in more detail below.)
If the address allocation succeeds, the result is returned in
"multicastAddressSetLease" (with "status" = OK).
During the lifetime of this lease, the allocation service will make a
"best-effort" attempt to not allocate any of these addresses to
others. (However, once the lease's lifetime has expired, any of its
addresses can be allocated to others.)
Multicast addresses are allocated for a limited lifetime. An
application may attempt to extend this lifetime, but this operation
may fail. Therefore, an application must be prepared for the
possibility it will not be able to use the same addresses for as long
as it desires. In particular, the application must be prepared to
either quit early (because its original multicast address assignments
have expired), or, alternatively, to occasionally 'renumber' its
multicast addresses (in some application or higher-level-protocol
dependent way), by making a new allocation. However, if an
application needs to consider 'renumbering', it will always know this
in advance, at the time it acquired its current address(es) - by
checking the lifetime in the returned lease. An application will
never need to be notified asynchronously of the need to 'renumber'.
<span class="grey">Finlayson Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
Possible errors:
- bad address family
- bad scope
- bad desired number of addresses (e.g., max < min)
- bad desired lifetimes (e.g., max < min)
- errors with the two "start time" parameters (see
"Advance allocation" below)
- no addresses can be allocated (for the requested parameters)
An allocation attempt can also fail with a result "status" code of
TRY_LATER, indicating that the requested allocation cannot be made at
this time, but that it might succeed if the caller retries the
attempt at some future time. (This future time is returned in the
"start time" field of the
"multicastAddressSetLease";
the other parts of this lease are undefined.)
Note that a concrete (i.e., programming language-specific) API for
multicast address allocation will probably include additional,
specialized variants of this general allocation operation. For
instance, it may include separate operations for:
- allocating only a single address
(i.e., minDesiredAddresses = maxDesiredAddresses = 1);
- (attempting to) allocate an address with a single, fixed
lifetime (i.e., minDesiredLifetime = maxDesiredLifetime);
- (attempting to) allocate an address for immediate use
(i.e., minDesiredStartTime = maxDesiredStartTime = 'now')
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Changing multicast addresses' lifetime:</span>
change_multicast_addr_lifetime(in Lease multicastAddressSetLease,
in Time minDesiredLifetime,
in Time maxDesiredLifetime,
out Time lifetime)
This operation attempts to change the lifetime of previously
allocated multicast addresses. Unless an error occurs, it returns
the new lifetime (which might remain unchanged).
Possible errors:
- bad address family
- bad durations (e.g., max < min)
<span class="grey">Finlayson Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
- the addresses' lifetime could not be changed
(and the existing lifetime was not in the requested range
[minDesiredLifetime,maxDesiredLifetime])
- the addresses were not ones that we had allocated
(see <a href="#section-5.9">section 5.9</a>) - or they have already expired
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> Deallocating multicast addresses:</span>
deallocate_multicast_addr(in Lease multicastAddressSetLease) This
operation attempts to deallocate previously allocated multicast
addresses.
Possible errors:
- bad address family
- the addresses were not ones that we had allocated
(or they have already expired)
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a> Querying the set of usable multicast address scopes:</span>
get_multicast_addr_scopes(in AddressFamily family,
out "set of" Scope)
This operation returns the set of administrative multicast address
scopes that are defined for this node.
Possible errors:
- bad address family
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a> Querying the name of a scope:</span>
get_scope_name(in Scope scope,
in LanguageTag language,
out String name,
out LanguageTag languageForName)
This operation returns a character-string name for a given scope. If
the scope has a name in the specified "language", then this name (and
language) is returned. Otherwise, the scope's default (language,
name) pair is returned.
Possible errors:
- bad scope.
<span class="grey">Finlayson Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a> Querying the nesting state of known usable multicast address scopes:</span>
get_scope_nesting_state(in "set of" Scope,
out "matrix of" NestingRelationship)
Possible errors:
- bad scope.
- nesting state undetermined at this time.
This operation would return a matrix that shows the
current nesting relationships between the supplied
set of scopes which would have previously been supplied
via the get_multicast_addr_scopes(...) function.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a> Querying the set of scopes that a given scope is known to nest inside:</span>
get_larger_scopes(in Scope,
out "set of" Scope)
This operation returns the set of administrative multicast
address scopes that are known to encompass the supplied
Scope.
Possible errors:
- bad scope.
- nesting state undetermined at this time.
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a> Querying the set of scopes that are known to nest inside a given scope:</span>
get_smaller_scopes(in Scope,
out "set of" Scope)
This operation returns the set of administrative multicast address
scopes that are known to nest inside the supplied Scope (NB this
would include those scopes that are topologically identical to the
supplied scope).
Possible errors:
- bad scope.
- nesting state undetermined at this time.
<span class="grey">Finlayson Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a> Note: The decision as to who is allowed to deallocate (or change</span>
<span class="h3"> the lifetime of) a previously allocated multicast address set lease</span>
is implementation-specific, and depends upon the security policy of
the host system. Thus it is not specified in this abstract API.
One possible starting point, however, is the following:
A previously allocated multicast address can be deallocated (or
have its lifetime queried or changed) by the same "principal", and
on the same node, as that which originally allocated it.
("principal" might, for example, be a "user" in the host operating
system.)
<span class="h3"><a class="selflink" id="section-3.10" href="#section-3.10">3.10</a> Advance allocation</span>
By specifying "minDesiredStartTime = maxDesiredStartTime = 'now'",
the address allocation operation - "alloc_multicast_addr" -
described above can be used to request a set of multicast
addresses that can be used *immediately* (and until their lifetime
expires). During this whole time, the addresses are not available
for allocation to others.
It is also possible - using the "minDesiredStartTime" and
"maxDesiredStartTime" parameters - to allocate multicast addresses
*in advance* - i.e., so that they have a future "start time" as
well as an expiration time. Before the start time, the multicast
addresses may be allocated to others.
Advance allocation is convenient for allocating addresses for
events that begin far in the future - e.g., several weeks or
months away. Without advance allocation, it would be necessary to
allocate addresses for a long period of time - even when it will
not be used. Such a request would not only be a wasteful use of
the multicast address space, but it may also be difficult to
implement (especially since address allocations are expected to
remain valid in spite of topology changes).
Advance allocation requests can produce the following errors (in
addition to those defined earlier):
- bad start time durations (e.g., max < min)
- requested start times conflict with requested lifetimes
(i.e., min start time > max lifetime)
<span class="grey">Finlayson Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
The following operation is also defined:
change_multicast_addr_start_time(in Lease multicastAddressSetLease,
in Time minDesiredStartTime,
in Time maxDesiredStartTime,
out Time startTime)
This operation attempts to change the start time of previously
allocated multicast addresses. Unless an error occurs, it returns
the new start time (which might remain unchanged).
Possible errors: the same as "change_multicast_addr_lifetime"
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
As noted in <a href="#section-5.9">section 5.9</a> above, each implementation of this abstract
API should define a security policy that specifies when (and by whom)
previously allocated multicast addresses can be deallocated (or
queried, or have their lifetime changed).
Because multicast addresses are a finite resource, there is a
potential for a "denial of service" attack by allocating a large
number of multicast addresses without deallocating them. Preventing
such an attack, however, is not the role of the API, but rather by
the underlying MAAS ("Multicast Address Allocation Server(s)" [<a href="#ref-6" title=""The Internet Multicast Address Allocation Architecture"">6</a>]).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgements</span>
Many thanks to other participants in the "MALLOC" working group - in
particular Steve Hanna, Dave Thaler, Roger Kermode, and Pavlin
Radoslavov - for their valuable comments.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
[<a id="ref-1">1</a>] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", <a href="./rfc2730">RFC 2730</a>, December 1999.
[<a id="ref-2">2</a>] Deering, S., "Host Extensions for IP Multicasting", STD 5, <a href="./rfc1112">RFC</a>
<a href="./rfc1112">1112</a>, August 1989.
[<a id="ref-3">3</a>] Meyer, D., "Administratively Scoped IP Multicast", <a href="https://www.rfc-editor.org/bcp/bcp23">BCP 23</a>, <a href="./rfc2365">RFC</a>
<a href="./rfc2365">2365</a>, July, 1998.
[<a id="ref-4">4</a>] Alvestrand, H., "Tags for the Identification of Languages", <a href="./rfc1766">RFC</a>
<a href="./rfc1766">1766</a>, March 1995.
<span class="grey">Finlayson Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
[<a id="ref-5">5</a>] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
<a href="./rfc2327">RFC 2327</a>, April 1998.
[<a id="ref-6">6</a>] Estrin, D., Handley, M. and D. Thaler, "The Internet Multicast
Address Allocation Architecture", Work in Progress.
[<a id="ref-7">7</a>] Kermode, R., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22MADCAP+Multicast+Scope+Nesting+State+Option%22'>"MADCAP Multicast Scope Nesting State Option"</a>, Work
in Progress.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Author's Address</span>
Ross Finlayson,
Live Networks, Inc. (LIVE.COM)
EMail: finlayson@live.com
WWW: <a href="http://www.live.com/">http://www.live.com/</a>
<span class="grey">Finlayson Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2771">RFC 2771</a> Abstract API for Multicast Address Allocation February 2000</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2000). 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.
Finlayson Informational [Page 11]
</pre>
|
