Subject: (ION) I-D ACTION:draft-ietf-rolc-nhrp-13.txt

From: [email-masked]
Date: Thu, 08 Jan 1998 09:50:24 -0500

Note:  This announcement is being re-sent with a correction made
       in the order of authorship.

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internetworking Over NBMA Working Group 
of the IETF.

	Title		: NBMA Next Hop Resolution Protocol (NHRP)
	Author(s)	: J. Luciani, D. Katz, D. Piscitello, B. Cole
	Filename	: draft-ietf-rolc-nhrp-13.txt
	Pages		: 50
	Date		: 24-Dec-97
	
   This document describes the NBMA Next Hop Resolution Protocol (NHRP).
   NHRP can be used by a source station (host or router) connected to a
   Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
   internetworking layer address and NBMA subnetwork addresses of the
   ''NBMA next hop'' towards a destination station.  If the destination is
   connected to the NBMA subnetwork, then the NBMA next hop is the
   destination station itself.  Otherwise, the NBMA next hop is the
   egress router from the NBMA subnetwork that is ''nearest'' to the
   destination station.  NHRP is intended for use in a multiprotocol
   internetworking layer environment over NBMA subnetworks.
 
   Note that while this protocol was developed for use with NBMA
   subnetworks, it is possible, if not likely, that it will be applied
   to BMA subnetworks as well.  However, this usage of NHRP is for
   further study.
 
   This document is intended to be a functional superset of the NBMA
   Address Resolution Protocol (NARP) documented in [1].
 
   Operation of NHRP as a means of establishing a transit path across an
   NBMA subnetwork between two routers will be addressed in a separate
   document (see [13]).

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rolc-nhrp-13.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rolc-nhrp-13.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-rolc-nhrp-13.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Albert Manfredi <[email-masked]>
Date: Thu, 08 Jan 1998 10:34:04 -0500

[email-masked] wrote:

>    ''NBMA next hop'' towards a destination station.

[ ... ]
 
>    to BMA subnetworks as well.  However, this usage of NHRP is for

This last paragraph hints at the fact that the big deal about NHRP
is really not that it works with NBMA networks at all. The point of
NHRP is that it works over networks which incorporate their own
global addressing scheme, and NHRP is used to force that global
addressing scheme to match up with the IP scheme. Not so?

The evolution from ATMARP to NHRP kind of hides the true nature of
NHRP. Whereas ATMARP _only_ exists because ATM is NBMA (it emulates
ARP broadcasts on a _local_ broadcast LAN), NHRP is about making use
of two different global systems effectively. Even if ATM were a BMA
net, NHRP would be required, I guess is the point I'm trying to
make.

Bert
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Grenville Armitage <[email-masked]>
Date: Sat, 10 Jan 1998 11:09:33 -0500

Albert Manfredi wrote:

	[..]
> net, NHRP would be required, I guess is the point I'm trying to

Interesting point, but misleading. Both ATMARP and NHRP are about
makeing use of two "global" addressing systems together - one
being mapped to the other as necessary. They differ only in
the extent of knowledge that a client is allowed to discover,
and the mechanisms used to support that scope of discovery.

ATMARP model could just as easily be used on Ethernets, it
just wouldn't be the most effective method. Only difference
between it and normal ARP is that ATMARP assumes the clients
cant reach each other without a-priori knowledge. ARP assumes
that the a-priori knowledge each client needs to discover each
other is the Ethernet bcast MAC address.

cheers,
gja
________________________________________________________________________
Grenville Armitage                          High Speed Networks Research
http://nj5.injersey.com/~gja              Bell Labs, Lucent Technologies
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Albert Manfredi <[email-masked]>
Date: Sat, 10 Jan 1998 19:23:32 -0500

> Both ATMARP and NHRP are about

I shoulda known I should have been more careful.

While I agree with your point to a point, I think there's something
missing from your explanation, Grenville. ARP and ATMARP are
exhaustive searches of every host, a search that involves no routing
(no topological hierarchy). ARP requires broadcast, so ATMARP is
truly needed _only_ because ATM is a NBMA network. As a consequence
of this exhaustive search technique used, ARP and ATMARP are only
concerned about matching up two addressing schemes with the
understanding that the match-up is over a very tiny scale. The
physical address, in fact, doesn't even need to be globally unique
for ARP or ATMARP. All it needs is to be unique within this tiny
little bubble. (So I wouldn't think that ARP can be described as a
system which _necessarily_ matches up two global schemes.)

> other is the Ethernet bcast MAC address.

I agree with the above and find it analogous to the MARS situation.
MARS too could be used for BMA nets.

But the point of my former post was that NHRP goes way beyond this
"need to do something that would be best done with broadcast in a
non-broadcast net," as the intro to NHRP implied. NHRP is much more
"need to do something to match one global, hierarchical topology to
another," which is really nothing to do with NBMA or BMA. It's
pretty much irrelevant whether either of the two global topologies
usually exists over BMA or NBMA networks.

I don't find this point misleading, actually.

Bert

---

From: Grenville Armitage <[email-masked]>
Date: Sun, 11 Jan 1998 12:50:41 -0500

Bert,

> I shoulda known I should have been more careful.

I haven't been keeping up with the list for awhile,
you just kinda lucked out ;-)

	[..]

> The

Neither does NHRP  mandate that the discovered
"link" address be from a globally unique space. It just
has to be associated with the target address supplied
in the query, and unique/meaningful inside the same scope
of the supplied target address (since the scope of the target
address is, by defn, the scope of the discovery process I
originally alluded to).

> MARS too could be used for BMA nets.

Yup.

cheers,
gja