As per Relevance of the word information, we have this rfc below:
Network Working Group P.
Request for Comments: 2843
Category: Informational T.
May 2000
Proxy-
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing)
gives ATM-attached devices the ability to interact with PNNI
without the necessity to fully support PAR. Proxy-PAR is designed
a client/server interaction, of which the client side is much
than the server side to allow fast implementation and deployment
The purpose of Proxy-PAR is to allow non-ATM devices to use
flooding mechanisms provided by PNNI for registration and
discovery of services offered by ATM attached devices. The
version of PAR primarily addresses protocols available in IPv4.
it also contains a generic interface to access the flooding of PNNI
In addition, Proxy-PAR-capable servers provide filtering based on
IDs [1], IP protocols and address prefixes. This enables,
instance, routers in a certain VPN running OSPF to find
neighbors on the same subnet. The protocol is built using
registration/query approach where devices can register their
and query for services and protocols registered by other clients
1
In June of 1996, the ATM Forum accepted the "Proxy-PAR
as minimal subset of PAR" as a work item of the Routing
Addressing (RA) working group, which was previously called the
working group [2]. The PAR [3] specification provides a
description of the protocol including state machines and
formats
Droz & Przygienda Informational [Page 1]
RFC 2843 Proxy-PAR May 2000
The intention of this document is to provide general
about Proxy-PAR. For the detailed protocol description we refer
reader to [3].
Proxy-PAR is a protocol that allows various ATM-attached devices (
and non-ATM devices) to interact with PAR-capable switches
exchange information about non-ATM services without executing
themselves. The client side is much simpler in terms
implementation complexity and memory requirements than a complete
instance. This should allow an easy implementation on existing
devices such as IP routers. Additionally, clients can use Proxy-
to register various non-ATM services and the protocols they support
The protocol has deliberately been omitted from ILMI [4] because
the complexity of PAR information passed in the protocol and the
that it is intended for the integration of non-ATM protocols
services only. A device executing Proxy-PAR does not necessarily
to execute ILMI or UNI signalling, although this will normally be
case
The protocol does not specify how a client should make use of
obtained information to establish connectivity. For example,
routers finding themselves through Proxy-PAR could establish a
mesh of P2P VCs by means of RFC2225 [5], or use RFC1793 [6]
interact with each other. LANE [7] or MARS [8] could be used for
same purpose. It is expected that the guidelines defining how
certain protocol can make use of Proxy-PAR should be produced by
appropriate working group or standardization body responsible for
particular protocol. An additional RFC [9] describing how to run
together with Proxy-PAR is published together with this document
The protocol has the ability to provide ATM address resolution
IP-attached devices, but such resolutions can also be achieved
other protocols under specification in the IETF, e.g. [10]. Again
the main purpose of the protocol is to allow the automatic
of devices over an ATM cloud in a distributed fashion, omitting
usual pitfalls of server-based solutions. Last but not least,
should be mentioned here as well that the protocol complements
coexists with the work done in the IETF on server detection via
extensions [11,12,13].
2 Proxy-PAR Operation and Interaction with
The protocol is asymmetric and consists of a discovery
query/registration part. The discovery is very similar to
existing PNNI Hello protocol and is used to initiate and
communication between adjacent clients and servers. The
and update part execute after a Proxy-PAR adjacency has
established. The client can register its own services by
Droz & Przygienda Informational [Page 2]
RFC 2843 Proxy-PAR May 2000
registration messages to the server. The client obtains
it is interested in by sending query messages to the server. When
client needs to change its set of registered protocols, it has
re-register with the server. The client can withdraw all
services by registering a null set of services. It is important
note that the server side does not push new information to
client, neither does the server keep any state describing
information the client received. It is the responsibility of
client to update and refresh its information and to discover
clients or update its stored information about other clients
issuing queries and registrations at appropriate time intervals.
simplifies the protocol, but assumes that the client will not
and request large amounts of data. The main responsibility of
server is to flood the registered information through the PNNI
such that potential clients can discover each other. The Proxy-
server side also provides filtering functions to support VPNs and
subnetting. It is assumed that services advertised by Proxy-PAR
be advertised by a relatively small number of clients and be
stable, so that polling and refreshing intervals can be
long
The Proxy-PAR extensions rely on appropriate flooding of
by the PNNI protocol. When the client side registers or re-
a new service through Proxy-PAR, it associates an abstract
scope with the service. The server side maps this membership
into a PNNI routing level that restricts the flooding. This
changes of the PNNI routing level without reconfiguration of
client. In addition, the server can set up the mapping table
that a client can flood information only to a certain level.
within the PNNI network take into account the associated scope of
information when it is flooded. It is thus possible to exploit
PNNI routing hierarchy by announcing different protocols on
levels of the hierarchy, e.g. OSPF could be run inside certain
groups, whereas BGP could be run between the set of peer -
running OSPF. Such an alignment or mapping of non-ATM protocols
the PNNI hierarchy can drastically enhance the scalability
flexibility of Proxy-PAR service. Figure 1 helps visualize such
scenario. For this topology the following registrations are issued
Droz & Przygienda Informational [Page 3]
RFC 2843 Proxy-PAR May 2000
+-+
| | PNNI peer group # PPAR capable @ PNNI capable *
+-+ switch
Level 40
+---------------------------+
| |
| |
| @ ---- @ ---- @ |
| | | |
+----- | ----------- | -----+
| |
Level 60 | |
+------------- | ---+ +-- | --------------+
| | | | | |
R1* ------#-P1------@ | | @---------P3-#------- * R
| | | | | |
R2* ------#-P2------+ | | +---------P4-#------- * R
| | | |
+-------------------+ +-------------------+
Figure 1: OSPF and BGP scalability with Proxy-PAR
(ATM topology).
1. R1 registers OSPF protocol as running on the IP
1.1.1.1 and subnet 1.1.1/24 with scope 60
2. R2 registers OSPF protocol as running on the IP
1.1.1.2 and subnet 1.1.1/24 with scope 60
3. R3 registers OSPF protocol as running on the IP
1.1.2.1 and subnet 1.1.2/24 with scope 60
4. R4 registers OSPF protocol as running on the IP
1.1.2.2 and subnet 1.1.2/24 with scope 60
1. R1 registers BGP4 protocol as running on the IP
1.1.3.1 and subnet 1.1/16 with scope 40 within AS101
2. R3 registers BGP4 protocol as running on the IP
1.1.3.2 and subnet 1.1/16 with scope 40 within AS100
Droz & Przygienda Informational [Page 4]
RFC 2843 Proxy-PAR May 2000
For simplicity the real PNNI routing level have been specified,
are 60 and 40. Instead of these two values the clients would use
abstract membership scope "local" and "local+1". In addition,
registered information would be part of the same VPN ID
Table 1 describes the resulting distribution and visibility
registrations and whether the routers not only see but also
the received information. After convergence of protocols and
building of necessary adjacencies and sessions, the overlying
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
(IP topology).
Expressing the above statements differently, one can say that if
scope of the Proxy-PAR information indicates that a
beyond the boundaries of the peer group is necessary, the leader of
peer group collects such information and propagates it into a
layer of the PNNI hierarchy. As no assumptions except scope
can normally be made about the information distributed (e.g.
addresses bound to AESAs are not assumed to be aligned with them
any respect), such information cannot be summarized. This makes
careful handling of scopes necessary to preserve the scalability
the approach as described above
Droz & Przygienda Informational [Page 5]
RFC 2843 Proxy-PAR May 2000
Reg# 1. 2. 3. 4. 5. 6.
Router
-----------------------------
R1 R U R
R2 U R Q
R3 R U R
R4 U R Q
R
Q seen through
U used (implies Q
Table 1: Flooding scopes of Proxy-PAR registrations
3 Proxy-PAR
3.1 Hello
The Proxy-PAR Hello Protocol is closely related to the Hello
specified in [2]. It uses the same packet header and
negotiation methods. For the sake of simplicity, states that
irrelevant to Proxy-PAR have been removed from the original
Hello protocol. The purpose of the Proxy-PAR Hello protocol is
establish and maintain a Proxy-PAR adjacency between the client
server that supports the exchange of registration and query messages
If the protocol is executed across multiple, parallel links
the same server and client pair, individual registration and
sessions are associated with a specific link. It is
responsibility of the client and server to assign registration
query sessions to the various communication instances. Proxy-PAR
be run in the same granularity as ILMI [4] to support virtual
and VP tunnels
In addition to the PNNI Hello, the Proxy-PAR Hellos travelling
the server to the client inform the client about the lifetime
server assigns to registered information. The client has to
this interval from the Hello packet and set its refresh interval to
value below the obtained time interval in order to avoid the
out of registered information by the server
3.2 Registration/Query
The registration and query protocols enable the client to
and learn about protocols supported by the clients.
query/register operations are initiated by the clients. The
never tries to push information to the client. It is the client'
responsibility to register and refresh the set of protocols
Droz & Przygienda Informational [Page 6]
RFC 2843 Proxy-PAR May 2000
and to re-register them when changes occur. In the same sense,
client must query the information from the server at appropriate
intervals if it wishes to obtain the latest information. It
important to note that neither client nor server is supposed to
any state information about the information stored by the other side
Registered information is associated with an ATM address and
inside the PNNI hierarchy. From the IP point of view, all
is associated with a VPN ID, IP address, subnet mask, and IP
family. In this context, each VPN refers to a completely separated
address space. For example
describes an OSPF interface in VPN A. In addition to the IP
further parameters can be registered that contain more
information about the protocol itself. In the above example
would be OSPF-specific information such as the area ID or
priority. However, Proxy-PAR server takes only the ATM and IP
specific information into account when retrieving information
was queried. Protocol specific information is never looked at by
Proxy-PAR server
3.2.1 Registration
The registration protocol enables a client to register the
and services it supports. All protocols are associated with
specific AESA and membership scope in the PNNI hierarchy. As
default scope, implementations should choose the local scope of
PNNI peer group. In this way, manual configuration can be
unless information has to cross PNNI peer group boundaries. PNNI
responsible for the correct flooding either in the local peer
or across the hierarchy
The registration protocol is aligned with the standard
topology database exchange protocol used in link-state
protocols as far as possible. It uses a window size of one. A
information element is registered at a time and must be
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
registration data previously received on the same link. By means of
return code the server indicates to the client whether
registration was successful
Apart form the IP-related information, the protocol also offers
generic interface to the PNNI flooding. By means of so-called
Capabilities Information Groups other information can be
that can be used for proprietary or experimental implementations
Droz & Przygienda Informational [Page 7]
RFC 2843 Proxy-PAR May 2000
3.2.2 Query
The client uses the query protocol to obtain information
services registered by other clients. The client requests
registered within a specific membership scope, VPN and IP
prefix. It is always the client's task to request information,
server never makes an attempt to push information to the client.
the client needs to filter the returned data based on service
specific information, such as BGP AS, it must parse and interpret
received information. The server never looks beyond the IP scope
The more generic interface to the flooding is supported in a
manner as the registration protocol
4 Supported
Currently the protocols indicated in Table 2 have been included
Furthermore, for protocols marked 'yes', additional information
been specified that is beneficial for their operation. Many of
protocols do not need additional information; it is sufficient
know they are supported and to which addresses they are bound
To include other information in an experimental manner the
information element can be used to carry such information
5 VPN
To implement virtual private networks all information distributed
PAR can be scoped under a VPN ID [1]. Based on this ID,
VPNs can be separated. Inside a certain VPN further distinctions
be made according to IP-address-related information and/or
type
In most cases the best VPN support can be provided when Proxy-PAR
used between the client and server because in this way it is
to hide the real PNNI topology from the client. The PAR
server translates from the abstract membership scope into the
PNNI routing level. In this way the real PNNI topology is hidden
the client and the server can apply restrictions in the PNNI scope
The server can for instance have a mapping such that the
scope "global" is mapped to the highest level peer group to which
particular VPN has access. Thus the membership scopes can be seen
hierarchical structuring inside a certain VPN. With such mappings
network provider can also change the mapping without having
reconfigure the clients
Droz & Przygienda Informational [Page 8]
RFC 2843 Proxy-PAR May 2000
For more secure VPN implementations it will also be necessary
implement VPN ID filters on the server side. In this way a client
be restricted to a certain set (typically one) of VPN IDs.
server will then allow queries and registrations only from
clients that are in the allowed VPNs. In this way it is possible
avoid an attached client from finding devices that are outside of
own VPN. There is even room for further restriction in terms of
allowing wildcard queries by a client. In terms of security, some
the protocols have their own methods, so PAR is only used for
discovery of the counterparts. For instance OSPF has
authentication that can be used during the OSPF operation. Hence
in the case where two wrong partners find each other, they will
communicate because they will not be able to authenticate each other
Protocol Additional
-------------------------------
OSPF
RIPv
BGP
BGP4
MOSPF
PIM-
IS-
ES-
BBN SPF
PIM-
DNS
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
by other protocols from the ATM Forum and IETF. The VPN ID
structured into two parts, namely the 3-byte-long OUI plus a 4-
index
Droz & Przygienda Informational [Page 9]
RFC 2843 Proxy-PAR May 2000
6 Interoperation with ILMI based Server
PAR can be used to complement the server discovery via ILMI
specified in [11,12,13]. It can be used to provide the flooding
information across the PNNI network. For this purpose a server has
register with a PAR-capable device. This can be achieved via Proxy
PAR or a direct PAR interaction. Manual configuration would also
possible. For instance the ATMARP server could register its
via Proxy-PAR. A direct interaction with PAR will be required
order to provide an appropriate flooding scope
A PAR-capable device that has the additional MIB variables in
Service Registry MIB can set these variables when getting
via PAR. All required information is either contained in PAR or
static, such as the IP version
7 Security
The Proxy-PAR protocol itself does not have its own
concepts. As PAR is an extension of PNNI, it has all the
features that come with PNNI. In addition, the protocol is
used for automatic discovery of peers for certain protocols.
the discovery process the security concepts of the
protocol are used for the bring-up. As explained in the section
VPN support, the only security considerations are on the server side
where access filters for VPN IDs can be implemented and
membership scope mappings can be configured
8
This document describes the basic functions of Proxy-PAR, which
been specified within the ATM Forum body. The main purpose of
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
be added to widen the scope of applicability of Proxy-PAR
Droz & Przygienda Informational [Page 10]
RFC 2843 Proxy-PAR May 2000
9
[1] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[2] ATM-Forum, "Private Network-Network Interface
Version 1.0." ATM Forum af-pnni-0055.000, March 1996.
[3] ATM-Forum, "PNNI Augmented Routing (PAR) Version 1.0."
Forum af-ra-0104.000, January 1999.
[4] ATM-Forum, "Interim Local Management Interface, (ILMI
Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.
[5] Laubach, J., "Classical IP and ARP over ATM", RFC 2225,
1998.
[6] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
April 1995.
[7] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane
0021.000, January 1995.
[8] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
Networks", RFC 2022, November 1996.
[9] Droz, P., Haas, R. and T. Przygienda, "OSPF over ATM and
PAR", RFC 2844, May 2000.
[10] Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.
[11] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601,
June 1999.
[12] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602,
June 1999.
[13] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603,
June 1999.
Droz & Przygienda Informational [Page 11]
RFC 2843 Proxy-PAR May 2000
Authors'
Patrick
IBM
Zurich Research
Saumerstrasse 4
8803
EMail: dro@zurich.ibm.
Tony
Siara Systems
1195 Borregas
Sunnyvale, CA 94089
EMail: prz@siara.
Droz & Przygienda Informational [Page 12]
RFC 2843 Proxy-PAR May 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Droz & Przygienda Informational [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
