Re: NHRP questions

[Andy Malis <[e-mail]>]

David,

> I have been away from the discussions for longer than I would like and 
> have a few questions about the NHRP draft <draft-ietf-rolc-nhrp-IV.txt>
> 
> (a) Is NHRP intended to replace rfc1735 NBMA Address Resolution Protocol (NARP)?

Yes, NARP is an experimental protocol, with (to my knowledge) no
implementations.

> (c) Why are packets encapsulated in IP?
>     My understanding is that the packets are encapsulated in IP packets
>     with protocol type 54 (c.f. 1-ICMP, 6-TCP, 17-UDP etc).
>     The ATMARP in rfc1577 (Classical IP and ARP over ATM) uses AAL5 directly
>     with an ether type 0x08-06 (c.f. IP 0x08-00).

IP is used so that the NHRP requests can follow the network layer
routed path from the source to the destination.  This is important,
because it ensures that the requests can be stopped and handled by any
network layer firewall routers on the routed path.  If IP wasn't used,
(for example, a derivitive of ARP was used), then the NHRP code in
each router along the path would need a very tight coupling between
the "NHRP ARP" handling code and the network layer routing tables,
which I think we all agree would not be very desirable.

IP encapsulation also allows you to use fabric mode while only
deploying NHRP in the directly NBMA-attached endstations, egress
routers, and filtering routers.  Not using IP requires that fabric
mode can only be used if NHRP is implemented in ALL routers.

>     What is the IP encapsulation providing the protocol? 
>     - an easier implementation for those with IP
>     - a way of identifying the source (since there is no source HW address?)

The most important thing it is providing is automatic access to IP
layer routing, since an NHRP request will follow the routed path to
the request's destination.

>     On the downside it would seem to make things difficult for other protocols.
>     (Wouldn't another protocol implementation, e.g. IPX(?), have difficulty 
>     with just entering the IP addressing space?)

NHRP currently has hooks for other protocols.  For it to be actually
used for another network layer protocol (say, IPX), it would need an
actual IPX version of the protocol that is carried in an IPX header.
That way, IPX routing can do its own thing.

>     Are there reasons why rfc1483 encapsulation isn't used?
>     Could NHRP be implemented as extensions to ATMARP instead?

RFC 1483 encapsulation IS being used - of the IP datagram that
includes the request.  I already discussed why you can't base it on
ATMARP (that's basically NARP).

> (d) How IP masks registered?
>     I am confused as to how a edge router can register with the NHS that
>     it acts as a gateway to other IP networks. I presume it would have to
>     be via the NHRP register.

No, the edge router is the NHS for the IP networks beyond it.  They
are registered as a result of the edge router configuration.

>     In addition, the NHRP MIB <draft-ietf-rolc-nhrp-mib-00.txt> has an IP mask
>     attribute in the NHRP address table, nhrpAddrDestNetMask. How would
>     this be filled in from the protocol supplied information?

It's filled in from static configuration in this case.  For
endstations, of course, the netmask is implied to be all ones.

>     Does NHRP need an extension (IP specific) to specify the net mask 
>     associated with the source IP address?

No.

> (e) What documents exist at the moment that specify the routing functionality
>     of NHRP?

Just the spec itself.

>     Does an NHS (server mode) just look up its own IP routing tables
>     and apply those entries to the incoming NHRP requests?

You should reread the server mode section of the spec.  Quoting from
it:

     Server mode assumes that NHRP is very loosely
     coupled with IP routing, and that the path taken by NHRP requests
     has little to do with the path taken by IP data packets routed to
     the desired destination. ...
     Server mode uses static configuration of NHS identity.  The client
     station must be configured with the IP address of one or more NHSs,
     and there must be a path to that NHS (either directly, in which
     case the NHS's NBMA address must be known, or indirectly, through a
     router whose NBMA address is known).  If there are multiple NHSs,
     they must be configured with each others' addresses, the identities
     of the destinations that each of them serves, and optionally a
     logical NBMA network identifier.

> (f) Why aren't the NBMA addresses as richly defined as those in ATMARP?
>     My understanding from rfc1577 is that the ATM addresses in ATMARP are
>     defined to contain type and length fields for ATM number and subaddress,
>     effectively 6 fields (although type and length are merged so they
>     only take 1x8 bit field, so actually only 4 fields).
>     In NHRP, there is only the type, length and address field (i.e. 3 fields).
>     Why isn't the subaddress needed?
>     Is there a document describing the addressing that I need to read?

The different address types are intended to handle anything you can
express with Q.2931/ATM Forum signaling and ATMARP.  If the list in
Assigned Numbers is insufficient, we can just register more address
types with the IANA.

> (g) Is there a need for InARP with NHRP?

There's no reason why you still can't use InARP with PVCs.  There's
little need for it with SVCs.

> (h) How does an end system or intermediate system get in contact with the NHS?
>     My understanding is that each ES and IS is specially configured with
>     IP address of its designated NHS. Wouldn't that imply that you would
>     need a special config file (or other mechanism) just for NHRP, 
>     i.e. a file like /etc/nhrp?

Yes, or new lines in an existing config file.

>     Are there other options like:
>     - a well known IP address in the reserved IP address range > 240.0.0.0
>     - a well known permanent IP multicast address in the
>       reserved IP address range > 224.0.0.0
>     - a well known name that resolves to the NHS, 
>       e.g. via /etc/hosts or name serving
>     - a well known ATM address

Many of these are options, and have already been discussed in other
arenas, such as ATMARP servers and ATM Forum servers of various sorts.
Before we commit to any of these possibilities, we should determine
what's being done for these other servers, and also discuss how to
handle the non-ATM case (NHRP has to work over other link layer
networks besides ATM).

> Does that expose my degree of confusion?

I hope I was able to clear up a bit of it (and perhaps for other folks
as well).

Cheers,
Andy
__________________________________________________________________________
Andrew G. Malis   [e-mail]             [phone]
Ascom Nexion      289 Great Rd., Acton MA 01720 USA   FAX: [phone]