< draft-ietf-ion-discov-nhrp-04.txt		draft-ietf-ion-discov-nhrp-05.txt >
	Internet-Draft Mike Davison		Internet-Draft Mike Davison
	Cisco Systems		Cisco Systems
	Nov 15, 1997		Nov 15, 1997
	ILMI-Based Server Discovery for NHRP		ILMI-Based Server Discovery for NHRP
	<draft-ietf-ion-discov-nhrp-04.txt>		<draft-ietf-ion-discov-nhrp-03.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance with
			all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference		time. It is inappropriate to use Internet- Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	To learn the current status of any Internet Draft, please check the		To learn the current status of any Internet Draft, please check the
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 37 ¶
	ftp.isi.edu (US West Coast).		ftp.isi.edu (US West Coast).
	This memo provides information for the Internet community. This memo		This memo provides information for the Internet community. This memo
	does not specify an Internet standard of any kind. Distribution of		does not specify an Internet standard of any kind. Distribution of
	this memo is unlimited.		this memo is unlimited.
	Abstract		Abstract
	This memo defines how ILMI-based Server Discovery, which provides a		This memo defines how ILMI-based Server Discovery, which provides a
	method for ATM-attached hosts and routers to dynamically determine		method for ATM-attached hosts and routers to dynamically determine
	the ATM address of servers, shall be used to locate NHRP servers.		the ATM addresses of servers, shall be used to locate NHRP servers.
	1. Introduction		1. Introduction
	Presently, configuring a host or router to use NHRP [1] is cumbersome		Presently, configuring a host or router to use NHRP [1] is cumbersome
	and error-prone since it requires at least one ATM addresses to be		and error-prone since it requires at least one ATM addresses to be
	statically configured on each host or router in the network.		statically configured on each host or router in the network.
	Further, it is impossible to implement a diskless host to use NHRP		Further, it is impossible to implement a diskless host to use NHRP
	since local configuration is required. ILMI-based Server Discovery,		since local configuration is required. ILMI-based Server Discovery,
	hereafter referred to as "server discovery," provides a solution to		hereafter referred to as "server discovery," provides a solution to
	these problems.		these problems.
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	The service registry table is indexed by atmfSrvcRegPort,		The service registry table is indexed by atmfSrvcRegPort,
	atmfSrvcRegServiceID and atmfSrvcRegAddressIndex.		atmfSrvcRegServiceID and atmfSrvcRegAddressIndex.
	3.1 Service Parameter String		3.1 Service Parameter String
	A generic parameter string is defined in the service registry table,		A generic parameter string is defined in the service registry table,
	thus allowing protocol-specific parameters to be specified. To be		thus allowing protocol-specific parameters to be specified. To be
	consistent with [1], the parameter string for NHRP shall be:		consistent with [1], the parameter string for NHRP shall be:
	mar$pro.type 16 bits Protocol type		ar$pro.type 16 bits Protocol type
	mar$pro.snap 40 bits Optional extension to protocol type		ar$pro.snap 40 bits Optional extension to protocol type
	mar$plen 8 bits Length of protocol address		ar$plen 8 bits Length of protocol address
	mar$addr plen octets Network address		ar$addr plen octets Network address
	mar$mask plen octets Network mask		ar$mask plen octets Network mask
	Where		Where
	mar$pro.type - See [1]. (IPv4 is 0x0800, IPv6 is 0x86DD)		ar$pro.type - See [1]. (IPv4 is 0x0800, IPv6 is 0x86DD)
	mar$pro.snap - See [1]. (IPv4 and IPv6 are 0)		ar$pro.snap - See [1]. (IPv4 and IPv6 are 0)
	mar$plen - Length of the protocol address.		ar$plen - Length of the protocol address.
	(IPv4 is 4, IPv6 is 16)		(IPv4 is 4, IPv6 is 16)
	mar$addr - Network address represented in network byte		ar$addr - Network address represented in network byte
	order		order
	mar$mask - Network mask represented in network byte order		ar$mask - Network mask represented in network byte order
	3.2 Service Object Identifier		3.2 Service Object Identifier
	This OID, assigned in the ATM Forum Service Registry MIB, names		This OID, assigned in the ATM Forum Service Registry MIB, names
	ATMARP within the context of server discovery.		ATMARP within the context of server discovery.
	atmfSrvcRegNHRP OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.5 }		atmfSrvcRegNHRP OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.5 }
	It does not name any managed objects, rather is used to locate		It does not name any managed objects, rather is used to locate
	appropriate rows in the service registery table.		appropriate rows in the service registery table.
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 42 ¶
	An NHC with no local configuration, such as a diskless workstation,		An NHC with no local configuration, such as a diskless workstation,
	must use the row with the lowest index value if multiple Next Hop		must use the row with the lowest index value if multiple Next Hop
	Server (NHS), possibly for multiple networks, are listed.		Server (NHS), possibly for multiple networks, are listed.
	NHC that have local IP configuration must use a row that has the		NHC that have local IP configuration must use a row that has the
	appropriate IP address. For example, consider the case where an IP		appropriate IP address. For example, consider the case where an IP
	router has 3 logical interfaces defined on a single physical		router has 3 logical interfaces defined on a single physical
	interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and		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		171.69.150.226/24. The router will sweep the service registry table
	looking for a rows that have atmfSrvcRegParm1 values as shown below:		looking for rows that have atmfSrvcRegParm1 values as shown below:
	Net number/mask atmfSrvcRegParm1		Net number/mask atmfSrvcRegParm1
	---------------- --------------------------------------------------		---------------- --------------------------------------------------
	1.0.0.0/8 08 00 00 00 00 00 00 04 01 00 00 00 ff 00 00 00		1.0.0.0/8 08 00 00 00 00 00 00 04 01 00 00 00 ff 00 00 00
	128.10.0.0/16 08 00 00 00 00 00 00 04 80 0a 00 00 ff ff 00 00		128.10.0.0/16 08 00 00 00 00 00 00 04 80 0a 00 00 ff ff 00 00
	171.69.150.0/24 08 00 00 00 00 00 00 04 ab 45 96 00 ff ff ff 00		171.69.150.0/24 08 00 00 00 00 00 00 04 ab 45 96 00 ff ff ff 00
	When the correct atmfSrvcRegParm1 values are located, the router may		When the correct atmfSrvcRegParm1 values are located, the router may
	then establish an SVC to the selected NHS and perform the appropriate		then establish an SVC to the selected NHS and perform the appropriate
	protocol operations.		protocol operations.
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	5. NHRP Server (NHS) Behavior		5. NHRP Server (NHS) Behavior
	A Next Hop Server (NHS) shall be locally configured. The NHS may		A Next Hop Server (NHS) shall be locally configured. The NHS may
	retrieve the NHRP service registry data to validate the results. If		retrieve the NHRP service registry data to validate the results. If
	an incorrect row is retrieved the error may be flagged in a locally		an incorrect row is retrieved the error may be flagged in a locally
	significant way.		significant way.
	6. Relationship with PNNI Augmented Routing		6. Relationship with PNNI Augmented Routing
	An augmented version PNNI ("PNNI Augmented Routing," or PAR) is being		An augmented version PNNI ("PNNI Augmented Routing," or PAR) [3] has
	developed by the ATM Forum. PAR can distribute data such as NHS		been developed by the ATM Forum. PAR can distribute data such as NHS
	addresses. Further, the ATM Forum is developing a proxy mechanism for		addresses. Further, the ATM Forum is developing a proxy mechanism for
	PAR (Proxy PAR) that would allow a UNI-attached host or router to		PAR (Proxy PAR) that would allow a UNI-attached host or router to
	access PAR data without a full PAR implementation.		access PAR data without a full PAR implementation.
	These mechanisms offer a promising way to manage the service registry		These mechanisms offer a promising way to manage the service registry
	tables maintained on each switch in an ATM network, yet would not		tables maintained on each switch in an ATM network, yet would not
	require changes to the mechanism defined in this memo. Hosts and		require changes to the mechanism defined in this memo. Hosts and
	routers can continue to utilize ILMI-based or Proxy PAR-based server		routers can continue to utilize ILMI-based or Proxy PAR-based server
	discovery and network administrators could manage the service		discovery and network administrators could manage the service
	registry data with local configuration or via PAR and Proxy PAR.		registry data with local configuration or via PAR and Proxy PAR.
	skipping to change at page 7, line 5 ¶		skipping to change at page 6, line 47 ¶
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
	References		References
	[1] Luciani, J., et al., "NBMA Next Hop Resolution Protocol,"		[1] Luciani, J., et al., "NBMA Next Hop Resolution Protocol,"
	<draft-ietf-rolc-nhrp-11.txt>, March, 1997.		<draft-ietf-rolc-nhrp-11.txt>, March, 1997.
	[2] ATM Forum, "Integrated Local Management Interface (ILMI)		[2] ATM Forum, "Integrated Local Management Interface (ILMI)
	Specification Version 4.0," af-ilmi-0065.000, September, 1996.		Specification Version 4.0," af-ilmi-0065.000, September, 1996.
			[3] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0,"
			af-ra-0104, January, 1999.
	Author's Address		Author's Address
	Mike Davison		Mike Davison
	Cisco Systems		Cisco Systems
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, California 95134		San Jose, California 95134
	Phone: (408) 526-4000		Phone: (408) 526-4000
	EMail: mike.davison@cisco.com		EMail: mike.davison@cisco.com
End of changes. 11 change blocks.
	16 lines changed or deleted		20 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/