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 M. Davison
Request for Comments: 2601 Cisco Systems
Category: Standards Track June 1999
<span class="h1">ILMI-Based Server Discovery for ATMARP</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 (1999). All Rights Reserved.
Abstract
This memo defines how ILMI-based Server Discovery, which provides a
method for ATM-attached hosts and routers to dynamically determine
the ATM addresses of servers, shall be used to locate ATMARP servers.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Presently, configuring a host or router to use ATMARP [<a href="#ref-1" title=""Classical IP and ARP over ATM,"">1</a>] is
cumbersome and error-prone since it requires at least one ATM address
to be statically configured on each host or router in the network.
Further, it is impossible to implement a diskless host to use ATMARP
since local configuration is required. ILMI-based Server Discovery,
hereafter referred to as "server discovery," provides a solution to
these problems.
A brief overview of the Integrated Local Management Interface (ILMI)
and the Service Registry MIB, as defined by the ATM Forum, are
provided in this memo. The reader should consult [<a href="#ref-2" title=""Integrated Local Management Interface (ILMI) Specification Version 4.0,"">2</a>] for a complete
description of ILMI and this MIB, but the information contained here
is sufficient for an understanding of its use to support ATMARP
server discovery.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Integrated Local Management Interface</span>
The Integrated Local Management Interface (ILMI) [<a href="#ref-2" title=""Integrated Local Management Interface (ILMI) Specification Version 4.0,"">2</a>] provides a
mechanism for ATM-attached devices, such as hosts, routers, and ATM
switches, to transfer management information. It is based on the
Simple Network Management Protocol (SNMP), Version 1, and supports
<span class="grey">Davison Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2601">RFC 2601</a> ILMI-Based Server Discovery for ATMARP June 1999</span>
get, get-next, set and trap operations.
The ILMI specification designates the switch side of the ATM link as
the 'network side' and the host/router side of the ATM link as the '
user side.' The Service Registry MIB, which is outlined in <a href="#section-3">Section 3</a>,
is implmented on the network side and is queried from the user side.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. ILMI 4.0 Service Registry MIB</span>
Server discovery utilizes the Service Registry MIB defined by the ATM
Forum in ILMI Specification Version 4.0 [<a href="#ref-2" title=""Integrated Local Management Interface (ILMI) Specification Version 4.0,"">2</a>]. To support the existing
framework for IP over ATM, ATM switches must support the Service
Registry MIB.
A row in the service registry table [<a href="#ref-2" title=""Integrated Local Management Interface (ILMI) Specification Version 4.0,"">2</a>] is defined as:
AtmfSrvcRegEntry ::= SEQUENCE {
atmfSrvcRegPort INTEGER,
atmfSrvcRegServiceID OBJECT IDENTIFIER,
atmfSrvcRegATMAddress AtmAddress,
atmfSrvcRegAddressIndex INTEGER,
atmfSrvcRegParm1 OCTET STRING
}
The definition of each field in this structure is:
atmfSrvcRegPort - The ATM port number for which this entry
contains management information. The value of zero may be used
to indicate the ATM interface over which a management request
was received.
atmfSrvcRegServiceID - This is the service identifier that
uniquely identifies the type of service at the address
provided in the table. (See <a href="#section-3.2">Section 3.2</a> for ATMARP OID.)
atmfSrvcRegATMAddress - This is the full address of the service.
The ATM client will use this address to establish a connection
with the service.
atmfSrvcRegAddressIndex - An arbitrary integer to differentiate
multiple rows containing different ATM addresses for the same
service on the same port.
atmfSrvcRegParm1 - An octet string whose size and meaning is
determined by the value of atmfSrvcRegServiceID.
The service registry table is indexed by atmfSrvcRegPort,
atmfSrvcRegServiceID and atmfSrvcRegAddressIndex.
<span class="grey">Davison Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2601">RFC 2601</a> ILMI-Based Server Discovery for ATMARP June 1999</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Service Parameter String</span>
A generic parameter string is defined in the service registry table,
thus allowing protocol-specific parameters to be specified. To be
consistent with [<a href="#ref-1" title=""Classical IP and ARP over ATM,"">1</a>], the parameter string for ATMARP shall be:
ar$pro 16 bits Protocol type
ar$plen 8 bits Length of protocol address
ar$addr plen octets Network address
ar$mask plen octets Network mask
Where
ar$pro - see Assigned Numbers for protocol type number for
protocol using ATMARP. (IPv4 is 0x0800, IPv6 is 0x86DD)
ar$plen - Length of the protocol address. (IPv4 is 4, IPv6 is 16)
ar$addr - Network address represented in network byte order
ar$mask - Network mask represented in network byte order
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Service Object Identifier</span>
This OID, assigned in the ATM Forum Service Registry MIB, names
ATMARP within the context of server discovery.
atmfSrvcRegATMARP OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.3 }
It does not name any managed objects, rather is used to locate
appropriate rows in the service registery table.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. ATMARP Client Behavior</span>
An ATMARP client will access the service registry table via ILMI
using the SNMP GetNext operator to "sweep" (SNMP parlance for a
linear search) beginning with {Port = 0, ServiceID = <see <a href="#section-3.2">Section</a>
<a href="#section-3.2">3.2</a>>, Index = 0} while holding the port number and the serviceID
constant. (Port number 0 is used within ILMI to indicate "this
port.")
An ATMARP client with no local configuration, such as a diskless
workstation, must use the row with the lowest index value if multiple
ATMARP servers, possibly for multiple networks, are listed.
ATMARP clients that have local IP configuration must use a row that
has the appropriate IP address. For example, consider the case where
an IP router has 3 logical interfaces defined on a single physical
<span class="grey">Davison Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2601">RFC 2601</a> ILMI-Based Server Discovery for ATMARP June 1999</span>
interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and
171.69.150.226/24. The router will sweep the service registry table
looking for rows that have atmfSrvcRegParm1 values as shown below:
Network number/mask atmfSrvcRegParm1
-------------------- --------------------------------------
1.0.0.0/8 08 00 04 01 00 00 00 ff 00 00 00
128.10.0.0/16 08 00 04 80 0a 00 00 ff ff 00 00
171.69.150.0/24 08 00 04 ab 45 96 00 ff ff ff 00
When the correct atmfSrvcRegParm1 values are located, the router may
then establish an SVC to the selected server and perform the
appropriate protocol operations.
Redundant ATMARP servers are supported with multiple rows in the
service registry table. This list of ATMARP servers is ordered with
the primary ATMARP server having the lowest index value. The ATMARP
client must attempt to utilize the primary ATMARP server before
utilizing a secondary ATMARP server. Administrators must ensure that
the listed ATMARP servers are synchronized.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. ATMARP Server Behavior</span>
An ATMARP server shall be locally configured. The ATMARP server may
retrieve the ATMARP service registry data to validate the results. If
an incorrect row is retrieved the error may be flagged in a locally
significant way.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Relationship with PNNI Augmented Routing</span>
An augmented version PNNI ("PNNI Augmented Routing," or PAR) [<a href="#ref-3" title=""PNNI Augmented Routing (PAR) Version 1.0,"">3</a>] has
been developed by the ATM Forum. PAR can distribute data such as
ATMARP server addresses. Further, the ATM Forum is developing a proxy
mechanism for PAR (Proxy PAR) that would allow a UNI-attached host or
router to access PAR data without a full PAR implementation. These
mechanisms offer a promising way to manage the service registry
tables maintained on each switch in an ATM network, yet would not
require changes to the mechanism defined in this memo. Hosts and
routers can continue to utilize ILMI-based or Proxy PAR-based server
discovery and network administrators could manage the service
registry data with local configuration or via PAR and Proxy PAR.
<span class="grey">Davison Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2601">RFC 2601</a> ILMI-Based Server Discovery for ATMARP June 1999</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The server discovery mechanism is built on the ILMI managment
framework and the security embodied in that framework. Access, to
user- or network-side information is controlled by MIB design rather
than protocol security mechanisms.
The service registery MIB, the table containing information for
server discovery, is defined in [<a href="#ref-2" title=""Integrated Local Management Interface (ILMI) Specification Version 4.0,"">2</a>] with read-only access. This means
that any user-side device may query the service registry, but may not
modify the service registry via ILMI. Instead, the sevice registry
table must be modified via local configuration on the ATM switch.
References
[<a id="ref-1">1</a>] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM," <a href="./rfc2225">RFC</a>
<a href="./rfc2225">2225</a>, April 1998.
[<a id="ref-2">2</a>] ATM Forum, "Integrated Local Management Interface (ILMI)
Specification Version 4.0," af-ilmi-0065.000, September 1996.
[<a id="ref-3">3</a>] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0," af-ra-
0104, January 1999.
Author's Address
Mike Davison
Cisco Systems
170 West Tasman Drive
San Jose, California 95134
Phone: (408) 526-4000
EMail: mike.davison@cisco.com
<span class="grey">Davison Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2601">RFC 2601</a> ILMI-Based Server Discovery for ATMARP June 1999</span>
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Davison Standards Track [Page 6]
</pre>
|
