Re: NHRP/MARS version number location.

[Grenville Armitage <[e-mail]>]

Tim,

I've taken the liberty of responding to both your rolc and ip-atm
posts in one go, because they are not seperable.

I guess the summary of your concern is:

>>I was surprised to find the MARS version number in byte 16 of the fixed
>>part of the MARS header.
>>Locating the version number this far into the header appears to be
>>a poor idea.
>>It seems that in most protocols, version numbers are located near the
>>beginning of the packet on the assumption that packet formats may change
>>across versions.

Your last sentence is generally correct, but you've overlooked what
is meant by a 'fixed header'. It is exactly that. A fixed header.
Any MARS/NHRP client or server parses the 20 byte fixed header before
deciding what to do about the rest of the packet. Whether various
fields are in the 1st or 19th position of the _fixed header_ is
somewhat arbitrary. Its the mandatory parts and TLVs that may change
if substantial protocol changes mandate a new version number.

I should also point out that MARS and NHRP are not distinct in this
number space. You made this comment in the ip-atm posting:

>>There should probably also be language in the MARS spec which says that
>>MARS packets with a version number not equal to one should be silently
>>dropped.  (Alternatively, a Version 1 MARS device could return a
>>"version not supported" error [in version 1 format] to the MARS
>>Version n device.)

It may not be clear, but both MARS control messages and NHRP control
messages share the same, unique, non-rfc1577 LLC/SNAP codepoint
(in the ATM environment at least):

 [0xAA-AA-03][0x00-00-5E][0x00-03][address resolution control message]
     (LLC)       (OUI)     (PID)

The correct way to understand this is that PID 0x0003 under the IANA
OUI is for a generic address resolution control message format.
The first 20 bytes of the control message is a fixed format header.
The actual format of this header is specified in the MARS document, and
will also be shown in the next revision of the NHRP document.

Now, within the context of this generic control message there is a
version field (along with fields indicating the protocol address types
being mapped, etc) indicating which address resolution protocol
is being used. MARS is version 0. NHRP is version 1. If there is
some future alternative that we'd like to multiplex onto the VCs
that are carrying MARS or NHRP message, we'll give it version 2, and
so on.

>>I was also a bit surprised to find the version number buried in the
>>Operation Code field. 

Well, it seemed a cleaner read to me. The operation required of
an entity that receives one of these control messages is defined
entirely by the actual protocol in use (MARS or NHRP, i.e. the
version field) _and_ an operation type code that is interpreted
within the context of the protocol indicated by the 'version' field.

cheers,
gja
_________________________________________________________________________
Grenville Armitage                               [e-mail]
Bellcore, 445 South St.      http://gump.bellcore.com:8000/~gja/home.html
Morristown, NJ 07960 USA          (voice) [phone] {.. 2504 (fax)}