The Routing Over Large Clouds Mailing List Archive by date

[David Horton <horton@citr.uq.oz.au>]

I am afraid I haven't heard the details of the LA meeting, so perhaps I 
am speaking out of turn. 

I have some problems with register messages as I last saw them speced.

Consider a network with several LISs and several switches dustributed
so that any given switch could have devices from several LISs. 
Say that  there couls also be a couple of PNNI groups, so that for
different parts of the ATM network the anycast address for NHRP
service is provided by a couple of different NHS.

Our aim is for a simple host to have just the following (NHRP) configuration:
+ its own IP address (for the ATM interface)
+ If authentication is required, then its own subnet/mask and MD5 key
Other data is preset
+ Anycast address of NHS service
or determined
+ local ATM address is negotiated with switch and burned in card address
i.e. as little config as possible and as comparable to an ethernet card.

(1) Destination protocol address in register
NHRP-8 requires the protocol (IP) address of the NHS with which the host is 
registering. So, as specified, that needs to be configured.

This is an unnecessary restriction as the correct NHS can be located by 
(IP) protocol and NHRP routing of the request message using the same 
mechanisms as for resolution requests.

For the below, let us assume that this is omitted or not mandatory.

(2) NHS can't identify itself back to registrant
An NHRP request reply always has to be directly back from the NHS to the 
requesting station because the routed path from any other NHS lead back to 
the home NHS. (This is only an issue for autoconfiguration and mobile 
stations. Simple local ATMARP like cases have this configuration anyway).

The registration reply packet contains no information about the NBMA 
address of the NHS. The protocol address also contains no added value, 
since it put it there in the request packet by the host.

It may be possible through some side effects that the information could be 
obtained, since the SVC call setup will contain the ATM address, and the 
NHRP reply message received on that SVC could be correlated back.
It might also be possible to use the responder address extension, but
it seems wrong to use a debugging feature in a role in the mainstream
protocol.

It seems to me that the reply message should have the following fields added 
by the NHS:
+ NHS protocol address (that actually accepted the registration)
+ NMBA address and subaddress (both type and address) as used elsewhere
+ hold time for that binding
+ MTU size for that address

(3) NHS address is necessary
It is possible for registration procedure packets to go in a 
circle without the above suggestions without affecting the protocol 
or having authentication problems:
+ Host -> Nearest NHS
+ NearestNHS -> Home NHS
+ Home NHS -> Host

For unauthenticated resolution request processing we can get a bigger loop, 
but again without affecting the protocol
+ Host -> Nearest NHS
+ NearestNHS -> resolving NHS
+ resolving NHS -> Home NHS
+ Home NHS -> Host

However for authenticated requests the first hop of this sequence can't work 
because the Host doesn't know the key for the LIS of the Nearest NHS.

So a Host needs to have a connection to an NHS in its Home LIS, and 
probably to the Home NHS. This re-inforces the need for the NHS
address details to be in the Registration reply.


Regards,
David

========================================================================
 David Horton
 Centre for Information Technology Research
 Level 2 South Tower, 339 Coronation Drive, Milton, Australia 4064
 Email: d.horton@citr.uq.oz.au       Phone +61 7 32592222   Fax +61 7 32592259