Re: NHRP/MARS version number location.

[Tim Salo <[e-mail]>]

> To: [e-mail] (Tim Salo)
> Cc: [e-mail], [e-mail], [e-mail]
> Subject: Re: NHRP/MARS version number location.
> Date: Thu, 28 Dec 1995 10:43:21 -0500
> From: Grenville Armitage <[e-mail]>
> 
> >>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.
> 	[...]

Grenville,

With all due respect, I think you missed my point completely.

You are "overlooking" what is meant by "version."  MARS Version 1 has a
format which is well known.  However, I don't think that you or anyone
else knows what the format of the MARS Version 2 messages will be,
including the format of the Version 2 "fixed header."  In other words,
your "fixed header" ought to be viewed as fixed within MARS Version 1,
not as fixed in perpetuity across all versions of MARS and across
all address resolution protocols.

My argument is that nearly every other Internet protocol makes provisions
for graceful migration to the next version, (which could possibly have
a different message format), by placing a protocol version number early
in the message.

I haven't seen any argument that MARS is somehow different than the
rest of the Internet protocols and therefore shouldn't have a version
number fairly early in the message.

However, as you show below, the MARS header doesn't really have a
version number...

> 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):
> 	[...]

I think this is a probably a mistake.  See below.

> 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.

So, it appears that what you have been calling a "version" number is
really a protocol identifier.  In other words, there is no protocol
version number within the MARS header, only a [mislabeled] field which
indicates the protocol.

> >>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.

This strategy also constrains the next address resolution protocol
we invent to use the MARS header format.  I simply don't think
our powers of prognostication are good enough to have invented the
ultimate address resolution message format.

I recommend:

o	The "address resolution protocol identifier field," (currently
	called a "version" number), be placed very early in the
	packet.  This field would differentiate between, for example,
	NHRP, MARS, and future address resolution protocols.

o	A "version number" field be added to the packet, which identifies
	the version of the  protocol identified by the "address resolution
	protocol identifier field."  This field would differentiate
	between, for example, MARS Version 1 and MARS Version 2.

I further recommend that:

o	We reexamine whether NHRP and MARS, (not to mention a bunch of
	protocols we haven't developed yet), should share a RFC 1483
	code point.

-tjs