The IP Over NBMA (ION) Archive

[Bryan Gleeson <bgleeson@cisco.com>]

Sanjeev,

>3. Given the extension of the classical IP model to beyond the LIS (via 
>NHRP), it is natural to consider extending Inverse ARP similarly. Hence
>upon receiving an InARP request, A STATION SHOULD BE ABLE TO REPLY WITH 
>PROTOCOL ADDRESSES NOT NECESSARILY IN THE SAME SUBNET AS THE REQUESTOR. 
>IT MAY ALSO BE DESIRABLE TO ALLOW/ MANDATE THE STATION TO SEND BACK 
>SEVERAL REPLIES IN RESPONSE TO SUCH AN InARP REQUEST, ONE FOR EACH 
>PROTOCOL ADDRESS ON THIS INTERFACE.  

In(ATM)ARP is needed for PVCs but is not needed for SVCs, and for
SVCs I think we should be deprecating it rather than extending it.

In particular it doesn't fit well with a model which allows multiple
IP addresses to map to a single ATM address. As you point out several
replies would be needed in response to a single request, and then you
have the problem of making this transfer reliable - otherwise some 
of the replies could get lost and you would not know.


>An advantage for the SVC case is if a destination 
>has been reached after sending an NHRP query through a number of NHSs, 
>the destination can directly query to determine one or all the protocol
>addresses at the source end without going through a (potentially lengthy) 
>NHRP requesting procedure itself. 

This seems to imply that the target of a shortcut can learn IP/ATM
mappings from the source which it then uses to forward data, without 
actually issuing an NHRP Resolution Request. This is currently frowned
upon by the spec (a SHOULD NOT). One reason is that this may bypass
filtering that would be imposed along the routed path. Another is that
NHRP is currently flexible in that it can be used to support shortcuts
between devices that are not actually IP entities (e.g. parts of a 
distributed router). In fact the current wording in the NHRP spec looks 
like a recipe for interoperability problems. It should either be changed 
to a MUST NOT, or we should explicitly allow "source learning" and anything 
using NHRP would have to take that feature into account.


If there are things we don't need then we should simplify, rather 
than extend, or at least restrict the extensions to PVCs which is
the scope of 1293. The use of InATMARP by ATMARP servers as 
a mechanism to register 1577 clients has already been deprecated.
NHCs currently don't need to implement InARP. We should not force 
them to do so.

Bryan Gleeson
cisco