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
|
<pre>Network Working Group P. Droz
Request for Comments: 2843 IBM
Category: Informational T. Przygienda
Siara
May 2000
<span class="h1">Proxy-PAR</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
Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that
gives ATM-attached devices the ability to interact with PNNI devices
without the necessity to fully support PAR. Proxy-PAR is designed as
a client/server interaction, of which the client side is much simpler
than the server side to allow fast implementation and deployment.
The purpose of Proxy-PAR is to allow non-ATM devices to use the
flooding mechanisms provided by PNNI for registration and automatic
discovery of services offered by ATM attached devices. The first
version of PAR primarily addresses protocols available in IPv4. But
it also contains a generic interface to access the flooding of PNNI.
In addition, Proxy-PAR-capable servers provide filtering based on VPN
IDs [<a href="#ref-1" title=""Virtual Private Networks Identifier"">1</a>], IP protocols and address prefixes. This enables, for
instance, routers in a certain VPN running OSPF to find OSPF
neighbors on the same subnet. The protocol is built using a
registration/query approach where devices can register their services
and query for services and protocols registered by other clients.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a> Introduction</span>
In June of 1996, the ATM Forum accepted the "Proxy-PAR contribution
as minimal subset of PAR" as a work item of the Routing and
Addressing (RA) working group, which was previously called the PNNI
working group [<a href="#ref-2" title=""Private Network-Network Interface Specification Version 1.0."">2</a>]. The PAR [<a href="#ref-3" title=""PNNI Augmented Routing (PAR) Version 1.0."">3</a>] specification provides a detailed
description of the protocol including state machines and packet
formats.
<span class="grey">Droz & Przygienda Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
The intention of this document is to provide general information
about Proxy-PAR. For the detailed protocol description we refer the
reader to [<a href="#ref-3" title=""PNNI Augmented Routing (PAR) Version 1.0."">3</a>].
Proxy-PAR is a protocol that allows various ATM-attached devices (ATM
and non-ATM devices) to interact with PAR-capable switches to
exchange information about non-ATM services without executing PAR
themselves. The client side is much simpler in terms of
implementation complexity and memory requirements than a complete PAR
instance. This should allow an easy implementation on existing IP
devices such as IP routers. Additionally, clients can use Proxy-PAR
to register various non-ATM services and the protocols they support.
The protocol has deliberately been omitted from ILMI [<a href="#ref-4" title=""Interim Local Management Interface, (ILMI) Specification 4.0."">4</a>] because of
the complexity of PAR information passed in the protocol and the fact
that it is intended for the integration of non-ATM protocols and
services only. A device executing Proxy-PAR does not necessarily need
to execute ILMI or UNI signalling, although this will normally be the
case.
The protocol does not specify how a client should make use of the
obtained information to establish connectivity. For example, OSPF
routers finding themselves through Proxy-PAR could establish a full
mesh of P2P VCs by means of <a href="./rfc2225">RFC2225</a> [<a href="#ref-5" title=""Classical IP and ARP over ATM"">5</a>], or use <a href="./rfc1793">RFC1793</a> [<a href="#ref-6" title=""Extending OSPF to Support Demand Circuits"">6</a>] to
interact with each other. LANE [<a href="#ref-7" title=""LAN Emulation over ATM 1.0."">7</a>] or MARS [<a href="#ref-8" title=""Support for Multicast over UNI 3.0/3.1 based ATM Networks"">8</a>] could be used for the
same purpose. It is expected that the guidelines defining how a
certain protocol can make use of Proxy-PAR should be produced by the
appropriate working group or standardization body responsible for the
particular protocol. An additional RFC [<a href="#ref-9" title=""OSPF over ATM and Proxy PAR"">9</a>] describing how to run OSPF
together with Proxy-PAR is published together with this document.
The protocol has the ability to provide ATM address resolution for
IP-attached devices, but such resolutions can also be achieved by
other protocols under specification in the IETF, e.g. [<a href="#ref-10" title=""The OSPF Opaque LSA Option"">10</a>]. Again,
the main purpose of the protocol is to allow the automatic detection
of devices over an ATM cloud in a distributed fashion, omitting the
usual pitfalls of server-based solutions. Last but not least, it
should be mentioned here as well that the protocol complements and
coexists with the work done in the IETF on server detection via ILMI
extensions [<a href="#ref-11" title=""ILMI-Based Server Discovery for ATMARP"">11</a>,<a href="#ref-12" title=""ILMI-Based Server Discovery for MARS"">12</a>,<a href="#ref-13" title=""ILMI-Based Server Discovery for NHRP"">13</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a> Proxy-PAR Operation and Interaction with PNNI</span>
The protocol is asymmetric and consists of a discovery and
query/registration part. The discovery is very similar to the
existing PNNI Hello protocol and is used to initiate and maintain
communication between adjacent clients and servers. The registration
and update part execute after a Proxy-PAR adjacency has been
established. The client can register its own services by sending
<span class="grey">Droz & Przygienda Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
registration messages to the server. The client obtains information
it is interested in by sending query messages to the server. When the
client needs to change its set of registered protocols, it has to
re-register with the server. The client can withdraw all registered
services by registering a null set of services. It is important to
note that the server side does not push new information to the
client, neither does the server keep any state describing which
information the client received. It is the responsibility of the
client to update and refresh its information and to discover new
clients or update its stored information about other clients by
issuing queries and registrations at appropriate time intervals. This
simplifies the protocol, but assumes that the client will not store
and request large amounts of data. The main responsibility of the
server is to flood the registered information through the PNNI cloud
such that potential clients can discover each other. The Proxy-PAR
server side also provides filtering functions to support VPNs and IP
subnetting. It is assumed that services advertised by Proxy-PAR will
be advertised by a relatively small number of clients and be fairly
stable, so that polling and refreshing intervals can be relatively
long.
The Proxy-PAR extensions rely on appropriate flooding of information
by the PNNI protocol. When the client side registers or re-registers
a new service through Proxy-PAR, it associates an abstract membership
scope with the service. The server side maps this membership scope
into a PNNI routing level that restricts the flooding. This allows
changes of the PNNI routing level without reconfiguration of the
client. In addition, the server can set up the mapping table such
that a client can flood information only to a certain level. Nodes
within the PNNI network take into account the associated scope of the
information when it is flooded. It is thus possible to exploit the
PNNI routing hierarchy by announcing different protocols on different
levels of the hierarchy, e.g. OSPF could be run inside certain peer
groups, whereas BGP could be run between the set of peer -groups
running OSPF. Such an alignment or mapping of non-ATM protocols to
the PNNI hierarchy can drastically enhance the scalability and
flexibility of Proxy-PAR service. Figure 1 helps visualize such a
scenario. For this topology the following registrations are issued:
<span class="grey">Droz & Przygienda Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
+-+
| | PNNI peer group # PPAR capable @ PNNI capable * Router
+-+ switch switch
Level 40
+---------------------------+
| |
| |
| @ ---- @ ---- @ |
| | | |
+----- | ----------- | -----+
| |
Level 60 | |
+------------- | ---+ +-- | --------------+
| | | | | |
R1* ------#-P1------@ | | @---------P3-#------- * R3
| | | | | |
R2* ------#-P2------+ | | +---------P4-#------- * R4
| | | |
+-------------------+ +-------------------+
Figure 1: OSPF and BGP scalability with Proxy-PAR autodetection
(ATM topology).
1. R1 registers OSPF protocol as running on the IP interface
1.1.1.1 and subnet 1.1.1/24 with scope 60
2. R2 registers OSPF protocol as running on the IP interface
1.1.1.2 and subnet 1.1.1/24 with scope 60
3. R3 registers OSPF protocol as running on the IP interface
1.1.2.1 and subnet 1.1.2/24 with scope 60
4. R4 registers OSPF protocol as running on the IP interface
1.1.2.2 and subnet 1.1.2/24 with scope 60
and
1. R1 registers BGP4 protocol as running on the IP interface
1.1.3.1 and subnet 1.1/16 with scope 40 within AS101
2. R3 registers BGP4 protocol as running on the IP interface
1.1.3.2 and subnet 1.1/16 with scope 40 within AS100
<span class="grey">Droz & Przygienda Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
For simplicity the real PNNI routing level have been specified, which
are 60 and 40. Instead of these two values the clients would use an
abstract membership scope "local" and "local+1". In addition, all
registered information would be part of the same VPN ID.
Table 1 describes the resulting distribution and visibility of
registrations and whether the routers not only see but also utilize
the received information. After convergence of protocols and the
building of necessary adjacencies and sessions, the overlying IP
topology is illustrated in Figure 2.
AS101 DMZ AS100
######### ##########
# #
| # | # |
+-- R1 ---------+ # R4 --+
| # | # |
| # | BGP4 on # OSPF on |
| OSPF on # | subnet # subnet |
| subnet # | 1.1/16 # 1.1.2/24 |
| 1.1.1/24 # | # |
| # +------------------- R3 --+
+-- R2 # | # |
| # #
######### ##########
Figure 2: OSPF and BGP scalability with Proxy-PAR autodetection
(IP topology).
Expressing the above statements differently, one can say that if the
scope of the Proxy-PAR information indicates that a distribution
beyond the boundaries of the peer group is necessary, the leader of a
peer group collects such information and propagates it into a higher
layer of the PNNI hierarchy. As no assumptions except scope values
can normally be made about the information distributed (e.g. IP
addresses bound to AESAs are not assumed to be aligned with them in
any respect), such information cannot be summarized. This makes a
careful handling of scopes necessary to preserve the scalability of
the approach as described above.
<span class="grey">Droz & Przygienda Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
Reg# 1. 2. 3. 4. 5. 6.
Router#
-----------------------------
R1 R U R U
R2 U R Q Q
R3 R U R U
R4 U R Q Q
R registered
Q seen through query
U used (implies Q)
Table 1: Flooding scopes of Proxy-PAR registrations.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a> Proxy-PAR Protocols</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Hello Protocol</span>
The Proxy-PAR Hello Protocol is closely related to the Hello protocol
specified in [<a href="#ref-2" title=""Private Network-Network Interface Specification Version 1.0."">2</a>]. It uses the same packet header and version
negotiation methods. For the sake of simplicity, states that are
irrelevant to Proxy-PAR have been removed from the original PNNI
Hello protocol. The purpose of the Proxy-PAR Hello protocol is to
establish and maintain a Proxy-PAR adjacency between the client and
server that supports the exchange of registration and query messages.
If the protocol is executed across multiple, parallel links between
the same server and client pair, individual registration and query
sessions are associated with a specific link. It is the
responsibility of the client and server to assign registration and
query sessions to the various communication instances. Proxy-PAR can
be run in the same granularity as ILMI [<a href="#ref-4" title=""Interim Local Management Interface, (ILMI) Specification 4.0."">4</a>] to support virtual links
and VP tunnels.
In addition to the PNNI Hello, the Proxy-PAR Hellos travelling from
the server to the client inform the client about the lifetime the
server assigns to registered information. The client has to retrieve
this interval from the Hello packet and set its refresh interval to a
value below the obtained time interval in order to avoid the aging
out of registered information by the server.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Registration/Query Protocol</span>
The registration and query protocols enable the client to announce
and learn about protocols supported by the clients. All
query/register operations are initiated by the clients. The server
never tries to push information to the client. It is the client's
responsibility to register and refresh the set of protocols supported
<span class="grey">Droz & Przygienda Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
and to re-register them when changes occur. In the same sense, the
client must query the information from the server at appropriate time
intervals if it wishes to obtain the latest information. It is
important to note that neither client nor server is supposed to cache
any state information about the information stored by the other side.
Registered information is associated with an ATM address and scope
inside the PNNI hierarchy. From the IP point of view, all information
is associated with a VPN ID, IP address, subnet mask, and IP protocol
family. In this context, each VPN refers to a completely separated IP
address space. For example <A, 194.194.1.01, 255.255.255.0, OSPF>
describes an OSPF interface in VPN A. In addition to the IP scope
further parameters can be registered that contain more detailed
information about the protocol itself. In the above example this
would be OSPF-specific information such as the area ID or router
priority. However, Proxy-PAR server takes only the ATM and IP-
specific information into account when retrieving information that
was queried. Protocol specific information is never looked at by a
Proxy-PAR server.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a> Registration Protocol</span>
The registration protocol enables a client to register the protocols
and services it supports. All protocols are associated with a
specific AESA and membership scope in the PNNI hierarchy. As the
default scope, implementations should choose the local scope of the
PNNI peer group. In this way, manual configuration can be avoided
unless information has to cross PNNI peer group boundaries. PNNI is
responsible for the correct flooding either in the local peer group
or across the hierarchy.
The registration protocol is aligned with the standard initial
topology database exchange protocol used in link-state routing
protocols as far as possible. It uses a window size of one. A single
information element is registered at a time and must be acknowledged
before a new registration packet can be sent. The protocol uses '
initialization' and 'more' bits in the same manner PNNI and OSPF do.
Any registration on a link unconditionally overwrites all
registration data previously received on the same link. By means of a
return code the server indicates to the client whether the
registration was successful.
Apart form the IP-related information, the protocol also offers a
generic interface to the PNNI flooding. By means of so-called System
Capabilities Information Groups other information can be distributed
that can be used for proprietary or experimental implementations.
<span class="grey">Droz & Przygienda Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a> Query Protocol</span>
The client uses the query protocol to obtain information about
services registered by other clients. The client requests services
registered within a specific membership scope, VPN and IP address
prefix. It is always the client's task to request information, the
server never makes an attempt to push information to the client. If
the client needs to filter the returned data based on service-
specific information, such as BGP AS, it must parse and interpret the
received information. The server never looks beyond the IP scope.
The more generic interface to the flooding is supported in a similar
manner as the registration protocol.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a> Supported Protocols</span>
Currently the protocols indicated in Table 2 have been included.
Furthermore, for protocols marked 'yes', additional information has
been specified that is beneficial for their operation. Many of the
protocols do not need additional information; it is sufficient to
know they are supported and to which addresses they are bound.
To include other information in an experimental manner the generic
information element can be used to carry such information.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a> VPN Support</span>
To implement virtual private networks all information distributed via
PAR can be scoped under a VPN ID [<a href="#ref-1" title=""Virtual Private Networks Identifier"">1</a>]. Based on this ID, individual
VPNs can be separated. Inside a certain VPN further distinctions can
be made according to IP-address-related information and/or protocol
type.
In most cases the best VPN support can be provided when Proxy-PAR is
used between the client and server because in this way it is possible
to hide the real PNNI topology from the client. The PAR capable
server translates from the abstract membership scope into the real
PNNI routing level. In this way the real PNNI topology is hidden from
the client and the server can apply restrictions in the PNNI scope.
The server can for instance have a mapping such that the membership
scope "global" is mapped to the highest level peer group to which a
particular VPN has access. Thus the membership scopes can be seen as
hierarchical structuring inside a certain VPN. With such mappings a
network provider can also change the mapping without having to
reconfigure the clients.
<span class="grey">Droz & Przygienda Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
For more secure VPN implementations it will also be necessary to
implement VPN ID filters on the server side. In this way a client can
be restricted to a certain set (typically one) of VPN IDs. The
server will then allow queries and registrations only from the
clients that are in the allowed VPNs. In this way it is possible to
avoid an attached client from finding devices that are outside of its
own VPN. There is even room for further restriction in terms of not
allowing wildcard queries by a client. In terms of security, some of
the protocols have their own methods, so PAR is only used for the
discovery of the counterparts. For instance OSPF has an
authentication that can be used during the OSPF operation. Hence even
in the case where two wrong partners find each other, they will not
communicate because they will not be able to authenticate each other.
Protocol Additional Info
-------------------------------
OSPF yes
RIP
RIPv2
BGP3
BGP4 yes
EGP
IDPR
MOSPF yes
DVMRP
CBT
PIM-SM
IGRP
IS-IS
ES-IS
ICMP
GGP
BBN SPF IGP
PIM-DM
MARS
NHRP
ATMARP
DHCP
DNS yes
Table 2: Additional protocol information carried in PAR and PPAR.
The VPN ID used by PAR and Proxy-PAR is aligned with the VPN ID used
by other protocols from the ATM Forum and IETF. The VPN ID is
structured into two parts, namely the 3-byte-long OUI plus a 4-byte
index.
<span class="grey">Droz & Przygienda Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a> Interoperation with ILMI based Server Discovery</span>
PAR can be used to complement the server discovery via ILMI as
specified in [<a href="#ref-11" title=""ILMI-Based Server Discovery for ATMARP"">11</a>,<a href="#ref-12" title=""ILMI-Based Server Discovery for MARS"">12</a>,<a href="#ref-13" title=""ILMI-Based Server Discovery for NHRP"">13</a>]. It can be used to provide the flooding of
information across the PNNI network. For this purpose a server has to
register with a PAR-capable device. This can be achieved via Proxy-
PAR or a direct PAR interaction. Manual configuration would also be
possible. For instance the ATMARP server could register its service
via Proxy-PAR. A direct interaction with PAR will be required in
order to provide an appropriate flooding scope.
A PAR-capable device that has the additional MIB variables in the
Service Registry MIB can set these variables when getting information
via PAR. All required information is either contained in PAR or is
static, such as the IP version.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a> Security Consideration</span>
The Proxy-PAR protocol itself does not have its own security
concepts. As PAR is an extension of PNNI, it has all the security
features that come with PNNI. In addition, the protocol is mainly
used for automatic discovery of peers for certain protocols. After
the discovery process the security concepts of the individual
protocol are used for the bring-up. As explained in the section about
VPN support, the only security considerations are on the server side,
where access filters for VPN IDs can be implemented and restrictive
membership scope mappings can be configured.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a> Conclusion</span>
This document describes the basic functions of Proxy-PAR, which has
been specified within the ATM Forum body. The main purpose of the
protocol is to provide automatic detection and configuration of non-
ATM devices over an ATM cloud.
In the future, support for further protocols and address families may
be added to widen the scope of applicability of Proxy-PAR.
<span class="grey">Droz & Przygienda Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a> Bibliography</span>
[<a id="ref-1">1</a>] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
<a href="./rfc2685">RFC 2685</a>, September 1999.
[<a id="ref-2">2</a>] ATM-Forum, "Private Network-Network Interface Specification
Version 1.0." ATM Forum af-pnni-0055.000, March 1996.
[<a id="ref-3">3</a>] ATM-Forum, "PNNI Augmented Routing (PAR) Version 1.0." ATM
Forum af-ra-0104.000, January 1999.
[<a id="ref-4">4</a>] ATM-Forum, "Interim Local Management Interface, (ILMI)
Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.
[<a id="ref-5">5</a>] Laubach, J., "Classical IP and ARP over ATM", <a href="./rfc2225">RFC 2225</a>, April
1998.
[<a id="ref-6">6</a>] Moy, J., "Extending OSPF to Support Demand Circuits", <a href="./rfc1793">RFC 1793</a>,
April 1995.
[<a id="ref-7">7</a>] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-
0021.000, January 1995.
[<a id="ref-8">8</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-9">9</a>] Droz, P., Haas, R. and T. Przygienda, "OSPF over ATM and Proxy
PAR", <a href="./rfc2844">RFC 2844</a>, May 2000.
[<a id="ref-10">10</a>] Coltun, R., "The OSPF Opaque LSA Option", <a href="./rfc2328">RFC 2328</a>, July 1998.
[<a id="ref-11">11</a>] Davison, M., "ILMI-Based Server Discovery for ATMARP", <a href="./rfc2601">RFC 2601</a>,
June 1999.
[<a id="ref-12">12</a>] Davison, M., "ILMI-Based Server Discovery for MARS", <a href="./rfc2602">RFC 2602</a>,
June 1999.
[<a id="ref-13">13</a>] Davison, M., "ILMI-Based Server Discovery for NHRP", <a href="./rfc2603">RFC 2603</a>,
June 1999.
<span class="grey">Droz & Przygienda Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
Authors' Addresses
Patrick Droz
IBM Research
Zurich Research Laboratory
Saumerstrasse 4
8803 Ruschlikon
Switzerland
EMail: dro@zurich.ibm.com
Tony Przygienda
Siara Systems Incorporated
1195 Borregas Avenue
Sunnyvale, CA 94089
USA
EMail: prz@siara.com
<span class="grey">Droz & Przygienda Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc2843">RFC 2843</a> Proxy-PAR May 2000</span>
Full Copyright Statement
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.
Droz & Przygienda Informational [Page 13]
</pre>
|
