< draft-ietf-ion-proxypar-arch-00.txt		draft-ietf-ion-proxypar-arch-01.txt >
	Internet Engineering Task Force P. Droz/T. Przygienda		Internet Engineering Task Force P. Droz/T. Przygienda
	INTERNET DRAFT IBM Corp./Bell Labs, Lucent		INTERNET DRAFT IBM Corp./Bell Labs, Lucent
	9 March 1998		15 February 1999
	Proxy PAR		Proxy PAR
	<draft-ietf-ion-proxypar-arch-00.txt>		<draft-ietf-ion-proxypar-arch-01.txt>
	Status of This Memo		Status of This Memo
	This document is an Internet Draft, and can be found as		This document is an Internet-Draft and is in full conformance with
	draft-ietf-ion-proxypar-arch-00.txt in any standard internet drafts		all provisions of Section 10 of RFC2026. Internet Drafts are working
	repository. Internet Drafts are working documents of the Internet		documents of the Internet Engineering Task Force (IETF), its Areas,
	Engineering Task Force (IETF), its Areas, and its Working Groups.		and its Working Groups. Note that other groups may also distribute
	Note that other groups may also distribute working documents as		working documents as Internet Drafts.
	Internet Drafts.
	Internet Drafts are draft documents valid for a maximum of six		Internet Drafts are draft documents valid for a maximum of six
	months. Internet Drafts may be updated, replaced, or obsoleted by		months. Internet Drafts may be updated, replaced, or obsoleted by
	other documents at any time. It is not appropriate to use Internet		other documents at any time. It is not appropriate to use Internet
	Drafts as reference material, or to cite them other than as a		Drafts as reference material, or to cite them other than as a
	``working draft'' or ``work in progress.''		``working draft'' or ``work in progress.''
	Please check the I-D abstract listing contained in each Internet		Please check the I-D abstract listing contained in each Internet
	Draft directory to learn the current status of this or any other		Draft directory to learn the current status of this or any other
	Internet Draft.		Internet Draft.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 38 ¶
	gives ATM attached devices the ability to interact with PNNI devices		gives ATM attached devices the ability to interact with PNNI devices
	without the necessity to fully support PAR. Proxy PAR is designed as		without the necessity to fully support PAR. Proxy PAR is designed as
	a client/server interaction where the client side is much simpler		a client/server interaction where the client side is much simpler
	than the server side to allow fast implementation and deployment.		than the server side to allow fast implementation and deployment.
	The purpose of Proxy PAR is to allow non-ATM devices to use the		The purpose of Proxy PAR is to allow non-ATM devices to use the
	flooding mechanisms provided by PNNI for registration and automatic		flooding mechanisms provided by PNNI for registration and automatic
	discovery of services offered by ATM attached devices. The first		discovery of services offered by ATM attached devices. The first
	version of PAR addresses mainly protocols available in IPv4. But		version of PAR addresses mainly protocols available in IPv4. But
	it also disposes of a generic interface to access the flooding of		it also disposes of a generic interface to access the flooding of
	PAR. In addition, Proxy PAR capable servers provide filtering based		PNNI. In addition, Proxy PAR capable servers provide filtering based
	on VPN IDs, IP protocols and address prefixes. This enables for		on VPN IDs, IP protocols and address prefixes. This enables for
	instance routers in a certain VPN running OSPF to find OSPF neighbors		instance routers in a certain VPN running OSPF to find OSPF neighbors
	on the same subnet. The protocol is built using a registration/query		on the same subnet. The protocol is built using a registration/query
	approach where devices can register their services and query for		approach where devices can register their services and query for
	services and protocols registered by other clients.		services and protocols registered by other clients.
	1. Introduction		1. Introduction
	In June 1996, the ATM Forum accepted the Proxy PAR contribution
	[CPS96] as minimal subset of PAR [Ca96], a current work item of the
	PNNI working group [AF96b]. The latest version of the specification
	[For98] provides a detailed description of the protocol including
	state machines and packet formats.
			In June 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 PNNI working
			group [AF96b]. The PAR [Ca96] specification provides a detailed
			description of the protocol including state machines and packet
			formats.
	The intention of this I-D is to provide general information about		The intention of this I-D is to provide general information about
	Proxy PAR. For the detailed protocol description we refer the reader		Proxy PAR. For the detailed protocol description we refer the reader
	to [For98].		to [Ca96].
	Proxy PAR is a protocol allowing for different ATM attached devices		Proxy PAR is a protocol allowing for different ATM attached devices
	(ATM and non-ATM devices) to interact with PAR capable switches		(ATM and non-ATM devices) to interact with PAR capable switches
	to exchange information about non-ATM services without executing		to exchange information about non-ATM services without executing
	PAR themselves. The client side is much simpler in terms of		PAR themselves. The client side is much simpler in terms of
	implementation complexity and memory requirements than a complete		implementation complexity and memory requirements than a complete
	PAR instance. This should allow an easy implementation on existing		PAR instance. This should allow an easy implementation on existing
	IP device such as IP routers. Additionally, clients can use Proxy		IP device such as IP routers. Additionally, clients can use Proxy
	PAR to register different non-ATM services and protocols they		PAR to register different non-ATM services and protocols they
	support. The protocol has deliberately not been included as part of		support. The protocol has deliberately not been included as part of
	ILMI [AF96a] due to the complexity of PAR information passed in the		ILMI [AF96a] due to the complexity of PAR information passed in the
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	implementation complexity and memory requirements than a complete		implementation complexity and memory requirements than a complete
	PAR instance. This should allow an easy implementation on existing		PAR instance. This should allow an easy implementation on existing
	IP device such as IP routers. Additionally, clients can use Proxy		IP device such as IP routers. Additionally, clients can use Proxy
	PAR to register different non-ATM services and protocols they		PAR to register different non-ATM services and protocols they
	support. The protocol has deliberately not been included as part of		support. The protocol has deliberately not been included as part of
	ILMI [AF96a] due to the complexity of PAR information passed in the		ILMI [AF96a] due to the complexity of PAR information passed in the
	protocol and the fact that it is intended for integration of non-ATM		protocol and the fact that it is intended for integration of non-ATM
	protocols and services only. A device executing Proxy PAR does not		protocols and services only. A device executing Proxy PAR does not
	necessarily need to execute ILMI or UNI signalling although this		necessarily need to execute ILMI or UNI signalling although this
	normally will be the case.		normally will be the case.
	The protocol does not specify how a client should make use of the		The protocol does not specify how a client should make use of the
	obtained information to establish connectivity. For example, OSPF		obtained information to establish connectivity. For example, OSPF
	routers finding themselves through Proxy PAR could establish a full		routers finding themselves through Proxy PAR could establish a full
	mesh of P2P VCs by means of RFC1577 [Lau94], or use RFC1793 [Moy95]		mesh of P2P VCs by means of RFC1577 [Lau94], or use RFC1793 [Moy95]
	to interact with each other. For the same purpose LANE [AF95] or		to interact with each other. For the same purpose LANE [AF95] or
	MARS [Arm96] could be used. It is expected that the guidelines how		MARS [Arm96] could be used. It is expected that the guidelines how
	a certain protocol can make use of Proxy PAR should come out of the		a certain protocol can make use of Proxy PAR should come out of the
	appropriate working group or standardization body that is responsible		appropriate working group or standardization body that is responsible
	for the particular protocol. Currently, work in progress exists to		for the particular protocol. Currently, work in progress exists
	address the operation of OSPF in the context of ATM and Proxy PAR		to address the operation of OSPF in the context of ATM and Proxy
	[PD97]. Further work will address other protocols such as BGP-4.		PAR [DP97]. Further work will address other protocols such as BGP-4.
	The protocol has the ability to provide ATM address resolution for IP
	attached devices, but such resolutions can also be achieved by other		The protocol has the ability to provide ATM address resolution for
	protocols under specification in IETF, e.g. [CH97b, CH97a]. Again,		IP attached devices, but such resolutions can also be achieved by
	the main purpose of the protocol is to allow the automatic detection		other protocols under specification in the IETF, e.g. [CH97, Col97].
	of devices over an ATM cloud in a distributed fashion, omitting the		Again, the main purpose of the protocol is to allow the automatic
	usual pitfalls of server based solutions. Last but not least, it		detection of devices over an ATM cloud in a distributed fashion,
	should be mentioned here as well that the protocol complements and		omitting the usual pitfalls of server based solutions. Last but
	coexists with the ongoing work in the IETF on server detection via		not least, it should be mentioned here as well that the protocol
	ILMI extensions [Dav97a, Dav97b, Dav97c].		complements and coexists with the ongoing work in the IETF on server
			detection via ILMI extensions [Dav97a, Dav97b, Dav97c].
	2. Proxy PAR Operation and Interaction with PNNI		2. Proxy PAR Operation and Interaction with PNNI
	The protocol is asymmetric and consists of a discovery and		The protocol is asymmetric and consists of a discovery and
	query/registration part. The discovery is very similar to the		query/registration part. The discovery is very similar to the
	existing PNNI Hello protocol and is used to initiate and maintain		existing PNNI Hello protocol and is used to initiate and maintain
	communication between adjacent clients and servers. The registration		communication between adjacent clients and servers. The registration
	and update part execute after a Proxy PAR adjacency has been		and update part execute after a Proxy PAR adjacency has been
	established. The client can register its own services by sending		established. The client can register its own services by sending
	registration messages to the server. The client obtains information		registration messages to the server. The client obtains information
	it is interested in by sending query messages to the server. When		it is interested in by sending query messages to the server. When
	skipping to change at page 4, line 4 ¶		skipping to change at page 3, line 44 ¶
	relatively long.		relatively long.
	The Proxy PAR extensions rely on appropriate flooding of information		The Proxy PAR extensions rely on appropriate flooding of information
	by the PNNI protocol. When the client side registers or re-registers		by the PNNI protocol. When the client side registers or re-registers
	a new service through Proxy PAR, it associates an abstract membeship		a new service through Proxy PAR, it associates an abstract membeship
	scope with the service. The server side maps this membership scope		scope with the service. The server side maps this membership scope
	into a PNNI routing level that restricts the flooding. This allows		into a PNNI routing level that restricts the flooding. This allows
	the changes of the PNNI routing level without reconfiguration of the		the changes of the PNNI routing level without reconfiguration of the
	client. In addition, the server can setup the mapping table such		client. In addition, the server can setup the mapping table such
	that a client can only flood information to a certain level. Nodes		that a client can only flood information 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
	+-+		+-+
	| | PNNI peer group # PPAR capable @ PNNI capable * Router		| | PNNI peer group # PPAR capable @ PNNI capable * Router
	+-+ switch switch		+-+ switch switch
	Level 40		Level 40
	+---------------------------+		+---------------------------+
	| |		| |
	| |		| |
	| @ ---- @ ---- @ |		| @ ---- @ ---- @ |
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	| | | | | |		| | | | | |
	R1* ------#-P1------@ | | @---------P3-#------- * R3		R1* ------#-P1------@ | | @---------P3-#------- * R3
	| | | | | |		| | | | | |
	R2* ------#-P2------+ | | +---------P4-#------- * R4		R2* ------#-P2------+ | | +---------P4-#------- * R4
	| | | |		| | | |
	+-------------------+ +-------------------+		+-------------------+ +-------------------+
	Figure 1: OSPF and BGP scalability with Proxy PAR autodetection (ATM		Figure 1: OSPF and BGP scalability with Proxy PAR autodetection (ATM
	Topology)		Topology)
	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		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		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		running OSPF. Such an alignment or mapping of non-ATM protocols to
	the PNNI hierarchy can drastically increase the scalability and		the PNNI hierarchy can drastically increase the scalability and
	flexibility of Proxy PAR service. Figure 1 helps to visualize such a		flexibility of Proxy PAR service. Figure 1 helps to visualize such a
	scenario. For this topology following registrations are issued:		scenario. For this topology following registrations are issued:
	1. R1 registers OSPF protocol as running on the IP interface 1.1.1.1		1. R1 registers OSPF protocol as running on the IP interface 1.1.1.1
	and subnet 1.1.1/24 with scope 60		and subnet 1.1.1/24 with scope 60
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 25 ¶
	For simplicity the real PNNI routing level have been specified which		For simplicity the real PNNI routing level have been specified which
	are 60 and 40. Instead of these two values the clients would use as		are 60 and 40. Instead of these two values the clients would use as
	abstract membership scope "local" and "local+1". In addition, all		abstract membership scope "local" and "local+1". In addition, all
	registered information would be part of the same VPN ID.		registered information would be part of the same VPN ID.
	Table 1 describes the resulting distribution and visibility of		Table 1 describes the resulting distribution and visibility of
	registrations and whether the routers not only see but also utilize		registrations and whether the routers not only see but also utilize
	the received information. After convergence of protocols and		the received information. After convergence of protocols and
	building of necessary adjacencies and sessions the overlying IP		building of necessary adjacencies and sessions the overlying IP
	topology is visualized in Figure 2.		topology is visualized in Figure 2.
			Expressing the said above 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
	AS101 DMZ AS100		AS101 DMZ AS100
	######### ##########		######### ##########
	# #		# #
	| # | # |		| # | # |
	+-- R1 ---------+ # R4 --+		+-- R1 ---------+ # R4 --+
	| # | # |		| # | # |
	| # | BGP4 on # OSPF on |		| # | BGP4 on # OSPF on |
	| OSPF on # | subnet # subnet |		| OSPF on # | subnet # subnet |
	| subnet # | 1.1/16 # 1.1.2/24 |		| subnet # | 1.1/16 # 1.1.2/24 |
	| 1.1.1/24 # | # |		| 1.1.1/24 # | # |
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	Reg# |1. |2. |3. |4. |5. |6.		Reg# |1. |2. |3. |4. |5. |6.
	___Router#_|___|___|___|___|___|____ R registered		___Router#_|___|___|___|___|___|____ R registered
	R1 |R |U | | |R |U Q seen through query		R1 |R |U | | |R |U Q seen through query
	R2 |U |R | | |Q |Q U used (implies Q)		R2 |U |R | | |Q |Q U used (implies Q)
	R3 | | |R |U |R |U		R3 | | |R |U |R |U
	R4 | | |U |R |Q |Q		R4 | | |U |R |Q |Q
	Table 1: Flooding Scopes of Proxy PAR Registrations		Table 1: Flooding Scopes of Proxy PAR Registrations
	Expressing the said above 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		group collects such information and propagates it into a higher
	layer of the PNNI hierarchy. As no assumptions except scope values		layer of the PNNI hierarchy. As no assumptions except scope values
	can normally be made about the information distributed (e.g. IP		can normally be made about the information distributed (e.g. IP
	addresses bound to AESAs are not assumed to be aligned with them in		addresses bound to AESAs are not assumed to be aligned with them in
	any respect), such information cannot be summarised. This makes a		any respect), such information cannot be summarised. This makes a
	careful handling of scopes necessary to preserve the scalability of		careful handling of scopes necessary to preserve the scalability of
	the approach as described above.		the approach as described above.
	3. Proxy PAR Protocols		3. Proxy PAR Protocols
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 32 ¶
	255.255.255.0, OSPF> describes an OSPF interface in VPN A. In		255.255.255.0, OSPF> describes an OSPF interface in VPN A. In
	addition to the IP scope further parameters can be registered that		addition to the IP scope further parameters can be registered that
	contain more detailed information about the protocol itself. In the		contain more detailed information about the protocol itself. In the
	above example this would be OSPF specific information such as the		above example this would be OSPF specific information such as the
	area ID or router priority. However, Proxy PAR server only takes		area ID or router priority. However, Proxy PAR server only takes
	the ATM and IP specific information into account when retrieving		the ATM and IP specific information into account when retrieving
	information that was queried for. Protocol specific information is		information that was queried for. Protocol specific information is
	never looked at by a Proxy PAR server.		never looked at by a Proxy PAR server.
	3.2.1. Registration Protocol		3.2.1. Registration Protocol
	The registration protocol enables a client to register the protocols		The registration protocol enables a client to register the protocols
	and services it supports. All protocols are associated with a		and services it supports. All protocols are associated with a
	specific AESA and membership scope in the PNNI hierarchy. As the		specific AESA and membership scope in the PNNI hierarchy. As the
	default scope, implementations should choose the local scope of the		default scope, implementations should choose the local scope of the
	PNNI peer group. In this way, manual configuration can be avoided		PNNI peer group. In this way, manual configuration can be avoided
	unless information has to cross PNNI peergroup boundaries. PNNI is		unless information has to cross PNNI peergroup boundaries. PNNI is
	responsible for the correct flooding either in the local peer group		responsible for the correct flooding either in the local peer group
	or across the hierarchy.		or across the hierarchy.
	The registration protocol is aligned with the standard initial		The registration protocol is aligned with the standard initial
	topology database exchange protocol used in link-state routing		topology database exchange protocol used in link-state routing
	protocols as far as possible. It uses a window size of one. A		protocols as far as possible. It uses a window size of one. A
	single information element is registered at a time and must be		single information element is registered at a time and must be
	acknowledged before a new registration packet can be sent. The		acknowledged before a new registration packet can be sent. The
	protocol uses 'initialization' and 'more' bits in the same manner		protocol uses 'initialization' and 'more' bits in the same manner
	PNNI and OSPF do. Any registration on a link unconditionally		PNNI and OSPF do. Any registration on a link unconditionally
	overwrites all registration data previously received on the same		overwrites all registration data previously received on the same
	link. By means of a return code the server indicates to the client		link. By means of a return code the server indicates to the client
	whether the registration was successful or not.		whether the registration was successful or not.
	Apart form the IP related information the protocol also offers a		Apart form the IP related information the protocol also offers a
	generic interface to the PNNI flooding. By means of so called System		generic interface to the PNNI flooding. By means of so called System
	Capabilities Information Groups other information can be distributed		Capabilities Information Groups other information can be distributed
	that can be used for proprietary or experimental implementations.		that can be used for proprietary or experimental implementations.
	3.2.2. Query Protocol		3.2.2. Query Protocol
	The client uses the query protocol to obtain information about		The client uses the query protocol to obtain information about
	services registered by other clients. The client requests services		services registered by other clients. The client requests services
	registered within a specific membership scope, IP instance and		registered within a specific membership scope, VPN and IP address
	IP address prefix. It is always the client's task to request		prefix. It is always the client's task to request information, the
	information, the server never makes any attempt to push information		server never makes any attempt to push information to the client.
	to the client. If the client needs to filter the returned data based		If the client needs to filter the returned data based on service
	on service specific information, such as BGP AS, it must parse and		specific information, such as BGP AS, it must parse and interpret the
	interpret the received information. The server never looks beyond		received information. The server never looks beyond the IP scope.
	the IP scope.
	The more generic interface to the flooding is supported similar to		The more generic interface to the flooding is supported similar to
	the registration protocol.		the registration protocol.
	4. Supported Protocols		4. Supported Protocols
	Currently the protocols indicated in Table 2 have been included.		Currently the protocols indicated in Table 2 have been included.
	Furthermore, for protocols marked with a 'yes' additional information		Furthermore, for protocols marked with a 'yes' additional information
	has been specified that is beneficial for their operation. Many of		has been specified that is beneficial for their operation. Many of
	the protocol do not need additional information, it is sufficient to		the protocol do not need additional information, it is sufficient to
	know that they are supported and to know to which addresses they are		know that they are supported and to know to which addresses they are
	bound.		bound.
	In order to include other information in an experimental manner the		In order to include other information in an experimental manner the
	generic information element can be used to carry such information.		generic information element can be used to carry such information.
	5. Proxy PAR Detection		5. VPN Support
	Since Proxy PAR is envisioned as being used by non-ATM devices		In order to implement virtual private networks all information
	such as IP routers that implement UNI functionality to interact		distributed via PAR can be scoped under a VPN ID. Based on this ID,
	with native ATM networks, an appropriate detection of Proxy PAR		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
	Protocol | Additional Info		Protocol | Additional Info
	______________|__________________		______________|__________________
	OSPF | yes		OSPF | yes
	RIP |		RIP |
	RIPv2 |		RIPv2 |
	BGP3 |		BGP3 |
	BGP4 | yes		BGP4 | yes
	EGP |		EGP |
	IDPR |		IDPR |
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 33 ¶
	BBN SPF IGP|		BBN SPF IGP|
	PIM-DM |		PIM-DM |
	MARS |		MARS |
	NHRP |		NHRP |
	ATMARP |		ATMARP |
	DHCP |		DHCP |
	DNS | yes		DNS | yes
	Table 2: Additional Protocol Information Carried in PAR and PPAR		Table 2: Additional Protocol Information Carried in PAR and PPAR
	capabilities on the network as well as user side is crucial. The
	necessary extensions to ILMI to perform this detection in an
	automatic manner have been introduced in [Prz97].
	6. VPN Support
	In order to implement virtual private networks all information
	distributed via PAR has a corresponding VPN ID. 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 performs the translation from the abstract membership scope		server performs the translation from the abstract membership scope
	into the real PNNI routing level. In this way the real PNNI topology		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		is hidden from the client and the server can apply restrictions in
	the PNNI scope. The server can for instance have a mapping such		the PNNI scope. The server can for instance have a mapping such
	that the membership scope "global" is mapped to the highest level		that the membership scope "global" is mapped to the highest level
	peergroup to which a particular VPN has access. Thus the membership		peergroup to which a particular VPN has access. Thus the membership
	scopes can be seen as hierarchical structuring inside a certain VPN.		scopes can be seen as hierarchical structuring inside a certain VPN.
	With such mappings a network provider can also change the mapping		With such mappings a network provider can also change the mapping
	having to reconfigure the clients.		having to reconfigure the clients.
	For more secure VPN implementations it will also be necessary to		For more secure VPN implementations it will also be necessary to
	implement VPN ID filters on the server side. In this way a client		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		can be restricted to a certain set (typically one) of VPN IDs. The
	server will then allow queries and registrations only from 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		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		avoid an attached client from finding devices that are outside of
	its own VPN. There is even room for further restriction in terms 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,		not allowing wildcard queries by a client. In terms of security,
	some of the protocols have their own security methods, so PAR is only		some of the protocols have their own security methods, so PAR is only
	used for the discovery of the counterparts. For instance OSPF has		used for the discovery of the counterparts. For instance OSPF has
	authentication which can be used during the OSPF operation. So even		authentication which can be used during the OSPF operation. So even
	in the case where two wrong partners find each other, they will not		in the case where two wrong partners find each other, they will not
	communicate because they will not be able to authenticate each other.		communicate because they will not be able to authenticate each other.
	7. Interoperation with ILMI Server Discovery		The VPN ID used by PAR and Proxy PAR is aligned with the VPN ID used
			by other protocols from the ATM Forum. The VPN ID is structured into
			2 parts, namely the 3 bytes long OUI plus a 4 byte index.
			6. Interoperation with ILMI based Server Discovery
	PAR can be used to complement the server discovery via ILMI as		PAR can be used to complement the server discovery via ILMI as
	specified in [Dav97a, Dav97b, Dav97c]. It can be used to provide		specified in [Dav97a, Dav97b, Dav97c]. It can be used to provide
	the flooding of the information across the PNNI network. For this		the flooding of the information across the PNNI network. For this
	purpose a server has to register with a PAR capable device. This		purpose a server has to register with a PAR capable device. This can
	can be achieved via Proxy PAR or with a direct PAR interaction. For		be achieved via Proxy PAR or with a direct PAR interaction. Manual
	instance the ATMARP server could register its service via Proxy PAR.		configuration would also be possible. For instance the ATMARP server
	A direct interaction with PAR will be required in order to provide an		could register its service via Proxy PAR. A direct interaction with
	appropriate flooding scope.		PAR will be required in order to provide an appropriate flooding
			scope.
	A PAR capable device that has the additional MIB variables in the		A PAR capable device that has the additional MIB variables in the
	Service Registry MIB can set these variables when getting information		Service Registry MIB can set these variables when getting information
	via PAR. All required information is either contained in PAR or		via PAR. All required information is either contained in PAR or
	is static such as IP version. The only missing information in		is static such as IP version. The ATM Forum is specifying the
	the MIB is the VPN ID but this can be coded into the variable		mapping of the PAR information into the Service Registry MIB. This
	atmfSrvcReqAddressIndex. The PAR device is then responsible to		specification will be pubished as an Appendix to the PAR document.
	synchronize its database entries with these MIB variables.
	8. Security Consideration
			7. Security Consideration
	The Proxy PAR protocol itself does not have its own security		The Proxy PAR protocol itself does not have its own security
	concepts. As PAR is an extension to PNNI, it has all security		concepts. As PAR is an extension to PNNI, it has all security
	features that come with PNNI. In addition, the protocol is mainly		features that come with PNNI. In addition, the protocol is mainly
	used for automatic discovery of peers for certain protocols. After		used for automatic discovery of peers for certain protocols. After
	the discovery process the security concepts of the individual		the discovery process the security concepts of the individual
	protocol is used for the bring up. As explained in the section about		protocol is used for the bring up. As explained in the section about
	VPN support, the only security considerations are on the server side		VPN support, the only security considerations are on the server side
	where access filters for VPN IDs can be implemented and restrictive		where access filters for VPN IDs can be implemented and restrictive
	membership scope mappings can be configured.		membership scope mappings can be configured.
	9. Conclusion		8. Conclusion
			This I-D describes the basic functions of Proxy PAR that 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.
	This I-D describes the basic functions of Proxy PAR being 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		In the future support for further protocols and address families may
	be added to widen the scope of applicability of Proxy PAR.		be added to widen the scope of applicability of Proxy PAR.
	References		References
	[AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum		[AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum
	af-lane-0021.000, January 1995.		af-lane-0021.000, January 1995.
	[AF96a] ATM-Forum. Interim Local Management Interface (ILMI)		[AF96a] ATM-Forum. Interim Local Management Interface (ILMI)
	Specification 4.0. ATM Forum 95-0417R8, June 1996.		Specification 4.0. ATM Forum 95-0417R8, June 1996.
	[AF96b] ATM-Forum. Private Network-Network Interface Specification		[AF96b] ATM-Forum. Private Network-Network Interface Specification
	Version 1.0. ATM Forum af-pnni-0055.000, March 1996.		Version 1.0. ATM Forum af-pnni-0055.000, March 1996.
	[Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based		[Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based
	ATM Networks, RFC 2022. Internet Engineering Task Force,		ATM Networks, RFC 2022. Internet Engineering Task Force,
	November 1996.		November 1996.
	[Ca96] R. Callon and al. An Overview of PNNI Augmented Routing.		[Ca96] R. Callon and al. An Overview of PNNI Augmented Routing.
	ATM Forum 96-0354, April 1996.		ATM Forum 96-0354, April 1996.
	[CH97a] R. Coltun and J. Heinanen. Opaque LSA in OSPF. Internet		[CH97] R. Coltun and J. Heinanen. The OSPF Address Resolution
	Draft, 1997.
	[CH97b] R. Coltun and J. Heinanen. The OSPF Address Resolution
	Advertisement Option. Internet Draft, 1997.		Advertisement Option. Internet Draft, 1997.
	[CPS96] R. Coltun, T. Przygienda, and S. Shew. MIPAR: Minimal PNNI		[Col97] R. Coltun. Opaque LSA in OSPF. Internet Draft, 1997.
	Augmented Routing. ATM Forum 96-0838, June 1996.
	[Dav97a] M. Davison. ILMI-Based Server Discovery for ATMARP.		[Dav99a] M. Davison. ILMI-Based Server Discovery for ATMARP.
	Internet Draft, 1997.		Internet Draft, 1999.
	[Dav97b] M. Davison. ILMI-Based Server Discovery for MARS. Internet		[Dav99b] M. Davison. ILMI-Based Server Discovery for MARS. Internet
	Draft, 1997.		Draft, 1999.
	[Dav97c] M. Davison. ILMI-Based Server Discovery for NHRP. Internet		[Dav99c] M. Davison. ILMI-Based Server Discovery for NHRP. Internet
	Draft, 1997.		Draft, 1999.
	[For98] ATM Forum. PNNI Augmented Routing (PAR) Version 1.0. ATM		[DP97] P. Droz and T. Przygienda. OSPF over ATM and Proxy PAR.
	Forum PNNI-RA-PAR-01.04, 1998.		Internet Draft, 1997.
	[Lau94] M. Laubach. Classical IP and ARP over ATM, RFC 1577.		[Lau94] M. Laubach. Classical IP and ARP over ATM, RFC 1577.
	Internet Engineering Task Force, January 1994.		Internet Engineering Task Force, January 1994.
	[Moy95] J. Moy. Extending OSPF to Support Demand Circuits, RFC		[Moy95] J. Moy. Extending OSPF to Support Demand Circuits, RFC
	1793. Internet Engineering Task Force, April 1995.		1793. Internet Engineering Task Force, April 1995.
	[PD97] T. Przygienda and P. Droz. OSPF over ATM and Proxy PAR.
	Internet Draft, 1997.
	[Prz97] T. Przygienda. User- and Network Side Proxy PAR Capable
	Devices. Detection and Configuration. ATM Forum 97-0555,
	July 1997.
	Authors' Addresses		Authors' Addresses
	Tony Przygienda		Tony Przygienda
	Bell Labs, Lucent Technologies		Bell Labs, Lucent Technologies
	101 Crawfords Corner Road		101 Crawfords Corner Road
	Holmdel, NJ 07733-3030		Holmdel, NJ 07733-3030
	prz@dnrc.bell-labs.com		prz@dnrc.bell-labs.com
	Patrick Droz		Patrick Droz
	IBM Research Division		IBM Research Division
End of changes. 34 change blocks.
	99 lines changed or deleted		83 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/