Re: [lisp] Meanign of R bit

[jnc at mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Margaret Wasserman <mrw at sandstorm.net>

    > Could you please explain the purpose of the R-bit and what the
    > structure of the LISP header will be when it is set?

The R-bit is for use in experimentation (and perhaps adoption into service,
if it proves to be useful) with mapping 'versioning' - i.e. a way of
detecting out-of-date mappings held at ITRs.

As to the header usage, I think the wording has been left more 'generic' than
the likely actual use will be, because we wanted to leave as few constraints
as possible (because until we do it, we won't know exactly what all data/
information we will need). My understanding/sense is that this mechanism is
likely to use just the 32-bit field in the header, 'time-shared' with the
normal locator-status functionality which uses that field.


    > From what I've heard so far, it sounds like the R-bit is a one-bit
    > version field, where (at least some) of the fields in the LISP header
    > will have other purposes when it is set.

Not really, to me, because to me a version field would imply a different
header layout entirely. To take one (or more) fields and change its
semantics, based on the setting of a flag bit, to me doesn't really qualify
as a 'new heade version'. Yeah, this is to some degree just terminology, but
still, I think it is a useful distinction.

We do have a very short header, because of space overhead concerns, and to me
it makes perfect sense to 'time-share' a field between a usage which does not
_have_ to be in every last packet if the protocol is to function (think the
TCP sequence number), and another low-duty-cycle control function. This is
especially apt in this case, as the two functions (xTR liveness, and mapping
freshness) are closely related.

    > why do we believe we need to use a version bit for that purpose, rather
    > than using one the other extensions methods we've discussed (new UDP port or
    > control- plane signaling)?

Well, in this particular case, neither really makes sense. Using a separate
port just to do a different control function would be overkill, I think. And
it's being piggy-backed on the user-data traffic _precisely_ to avoid the
overhead of separate control traffic. (I.e. while it's not done _all_ the
time, it's not a very _rare_ operation either.)

Having said that, IIRC there are other unused, 'must-be-zero' flag bits in
what is now the first byte that _could_ be dedicated to a version field -
i.e. flag a different header format. (There are 8 bits total, and if my
memory is working, only 5 have been allocated - and there are some
combinations of the existing ones which are currently illegal, and could also
be used to signal a new header format.) We haven't gone ahead and allocated
such bits/values because we want to retain maximum flexibility for the future
- we may decide that function X is more important than a version field (since
we do, as you point out, have other options for a new header format).

	Noel