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
|
<pre>Network Working Group G. Armitage
Request for Comments: 2269 Lucent Technologies
Category: Informational January 1998
<span class="h1">Using the MARS Model in non-ATM NBMA Networks</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 (1998). All Rights Reserved.
Abstract
Initially developed for IP over ATM, the <a href="./rfc2022">RFC 2022</a> (MARS) model is
also applicable to other NBMA networks that provide the equivalent of
switched, point to multipoint connections. This short document is
intended to state the obvious equivalences, and explain the less
obvious implications. No changes to the MARS model per se are
suggested or required. <a href="./rfc2022">RFC 2022</a> is not required over NBMA networks
that offer Ethernet-like group addressing functionality.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Most network layer models, like the one described in STD 5, <a href="./rfc1112">RFC 1112</a>
[<a href="#ref-1" title=""Host Extensions for IP Multicasting"">1</a>] for IP multicasting, assume sources may send their packets to an
abstract 'multicast group addresses'. Link layer support for such an
abstraction is assumed to exist, and is provided by technologies such
as Ethernet.
Some NBMA networks (e.g. ATM using UNI3.0 or UNI3.1 signaling [<a href="#ref-4" title=""ATM User-Network Interface Specification Version 3.0"">4</a>,<a href="#ref-5" title=""ATM User Network Interface (UNI) Specification Version 3.1"">5</a>])
do not support a multicast (or group) address abstraction. In these
environments multicasting is typically supported through point to
multipoint calls (or emulated with multiple point to point calls).
The MARS model (<a href="./rfc2022">RFC 2022</a>) [<a href="#ref-2" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks."">2</a>] was originally developed by the IP over
ATM working group, and so uses ATM-centric descriptive language. For
completeness this memo explains how <a href="./rfc2022">RFC 2022</a> can be applied to other
NBMA technologies.
<span class="grey">Armitage Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2269">RFC 2269</a> MARS Model in non-ATM NBMA Networks January 1998</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. <a href="./rfc2022">RFC 2022</a>'s basic assumptions.</span>
Section 3 of [<a href="#ref-2" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks."">2</a>] describes the basic assumptions that the MARS model
makes about the services available from the link layer network (using
ATM as the specific case). In summary these are:
The ATM model broadly describes an 'AAL User' as any entity that
establishes and manages VCs and underlying AAL services to
exchange data. An IP over ATM interface is a form of 'AAL User'
The most fundamental limitations of UNI 3.0/3.1's multicast
support are:
Only point to multipoint, unidirectional VCs may be
established.
Only the root (source) node of a given VC may add or remove
leaf nodes.
Leaf nodes are identified by their unicast ATM addresses.
Given this point to multipoint call service, the MARS document goes
on to describe two architectures for emulating multipoint to
multipoint IP multicasting - the VC Mesh, and the Multicast Server.
In either case it was assumed that IP/ATM interfaces (whether in
routers or hosts) are allowed to originate and manage outgoing point
to multipoint calls without network operator intervention or manual
provisioning.
The MARS document also specifies that AAL5 be used for all SVCs,
implying a requirement that the underlying link service supports the
atomic exchange of PDUs.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Generalising the MARS model.</span>
Any NBMA service that offers an equivalent to (or superset of) the
ATM point to multipoint call service can use the MARS model directly.
It must be possible to transmit atomic data units bi-directionally
with point to point calls, and unidirectionally (from root to leaves)
on point to multipoint calls.
A MARS is an entity known by its NBMA address.
A MARS Client is an entity known by its NBMA address.
An MCS (where needed) is an entity known by its NBMA address.
<span class="grey">Armitage Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2269">RFC 2269</a> MARS Model in non-ATM NBMA Networks January 1998</span>
The MARS control messages defined in sections <a href="#section-4">4</a> onwards of the MARS
document are shown carrying ATM addresses. Using different mar$afn
(Address Family) values in the fixed header of MARS control messages
allows MARS entities to indicate they are carrying other types of
NBMA addresses (as done in NHRP [<a href="#ref-3" title=""NBMA Next Hop Resolution Protocol (NHRP)"">3</a>]). As for NHRP, the
interpretation of the 'sub-address' fields shall be in the context of
the address family selected (which means it will often simply be
null).
In all cases where {IP, ATM.1, ATM.2, ...} mappings are referred to,
they may be interpreted as {IP, NBMA.1, NBMA.2, ...} in the context
of whatever NBMA network you are deploying MARS.
The MARS Cluster is defined in [<a href="#ref-2" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks."">2</a>] as:
The set of ATM interfaces chosing to participate in direct ATM
connections to achieve multicasting of AAL_SDUs between
themselves.
It is trivial to observe that the cluster definition is independent
of the underlying link layer technology. A revised definition
becomes:
The set of NBMA interfaces chosing to participate in direct NBMA
connections to achieve multicasting of packets between themselves.
The term 'Cluster Member' continues to refer to an endpoint that is
currently using a specific MARS for multicast support. The potential
scope of a cluster may be the entire membership of a LIS, while the
actual scope of a cluster depends on which LIS members are actually
registered with the cluster's MARS at any given time.
Section 3.4 of [<a href="#ref-2" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks."">2</a>] provided a set of mneumonics for the signalling
functions available to AAL Users. These mneumonics are then used in
the remainder of [<a href="#ref-2" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks."">2</a>] to indicate link layer events to which MARS
entities might react. Recast from the perspective of an NBMA based
MARS entity, the descriptions would now read:
The following generic signalling functions are presumed to be
available to local MARS entities:
L_CALL_RQ Establish a pt-pt call to a specific endpoint.
L_MULTI_RQ Establish pt-mpt call to a specific endpoint.
L_MULTI_ADD Add new leaf node to previously established pt-mpt
call.
L_MULTI_DROP Remove specific leaf node from established pt-mpt
call.
L_RELEASE Release pt-pt call, or all Leaves of a pt-mpt call.
<span class="grey">Armitage Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2269">RFC 2269</a> MARS Model in non-ATM NBMA Networks January 1998</span>
The signalling exchanges and local information passed between MARS
entity and NBMA signalling entity with these functions are outside
the scope of this document.
The following indications are assumed to be available to MARS
entities, generated by by the local NBMA signalling entity:
L_ACK Succesful completion of a local request.
L_REMOTE_CALL A new call has been established to the MARS
entity.
ERR_L_RQFAILED A remote NBMA endpoint rejected an L_CALL_RQ,
L_MULTI_RQ, or L_MULTI_ADD.
ERR_L_DROP A remote NBMA endpoint dropped off an existing
call.
ERR_L_RELEASE An existing call was terminated.
The signalling exchanges and local information passed between MARS
entity and NBMA signalling entity with these functions are outside
the scope of this document.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Open Issues.</span>
The trade offs between VC Mesh and Multicast Server modes may look
quite different for each NBMA technology. This will be especially
true in the area of VC (or equivalent) resource consumption in the
NICs of hosts, routers, and endpoints supporting MARSs or MCSs. The
use of VC mesh mode is most vulnerable to NBMA technologies that are
signalling intensive or resource challenged.
Sizing of Clusters (and hence LISes) will also be affected by a given
NBMA network's ability to support lots of pt-mpt calls.
Additionally, you cannot have more members in a cluster than you can
have leaf nodes on a pt-mpt call, without hacking the MARS model [<a href="#ref-6" title=""Issues affecting MARS Cluster Size"">6</a>].
On going developments in server synchronisation protocols for
distributed <a href="./rfc2022">RFC 2022</a> implementations are expected to be applicable to
non-ATM NBMA networks.
Quality of service considerations are outside the scope of this
document. They will be very specific to each NBMA technology's
capabilities. Related work is being pursued outside the ION Working
Group.
If the NBMA network offers some sort of native multipoint to
multipoint service then use of the MARS model may not be optimal.
Such situations require further analysis.
<span class="grey">Armitage Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2269">RFC 2269</a> MARS Model in non-ATM NBMA Networks January 1998</span>
Security Considerations
This memo is informational, and specifies no protocol for deployment.
No specific non-ATM NBMA network technologies or security
characteristics are discussed. Should enhancements to security be
required, they shall be added as an extension to the base
architecture in <a href="./rfc2022">RFC 2022</a>, or described in documents explicitly
proposing use of <a href="./rfc2022">RFC 2022</a> over specific NBMA technologies.
Acknowledgments
This memo was substantially developed while the author was with Bell
Communications Research (Bellcore).
Author's Address
Grenville Armitage
Bell Laboratories, Lucent Technologies.
101 Crawfords Corner Rd,
Holmdel, NJ, 07733
USA
EMail: gja@lucent.com
References
[<a id="ref-1">1</a>] Deering, S., "Host Extensions for IP Multicasting", STD 5, <a href="./rfc1112">RFC</a>
<a href="./rfc1112">1112</a>, Stanford University, August 1989.
[<a id="ref-2">2</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-3">3</a>] Luciani, J., et. al., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22NBMA+Next+Hop+Resolution+Protocol+%28NHRP%29%22'>"NBMA Next Hop Resolution Protocol (NHRP)"</a>,
Work in Progress.
[<a id="ref-4">4</a>] ATM Forum, "ATM User-Network Interface Specification Version
3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
[<a id="ref-5">5</a>] ATM Forum, "ATM User Network Interface (UNI) Specification
Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs,
NJ, June 1995.
[<a id="ref-6">6</a>] Armitage, G., "Issues affecting MARS Cluster Size", <a href="./rfc2121">RFC 2121</a>,
March 1997.
<span class="grey">Armitage Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2269">RFC 2269</a> MARS Model in non-ATM NBMA Networks January 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.
Armitage Informational [Page 6]
</pre>
|
