Subject: [manet] Three issues with PacketBB

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 12:55:21 +0200

Three issues with PacketBB as specified in draft-ietf-manet-packetbb-05.

>   <address block> is defined by:
> 
>        <address-block> = <num-addr>
>                          <addr-semantics>
>                          <head-length>?
>                          <head>?
>                          <tail-length>?
>                          <tail>?
>                          <mid>*

I find it unnecessarily complex to represent two addresses by encoding 
only once their common most significant bits ('head') and followed by 
the differentiating 'tail'.

This representation proposes to encode two addresses 1.1.1.1 and 1.2.2.2 
as a unique head '1' and two tails '1.1.1' and '2.2.2'.  Two 'head-len' 
and 'tail-len' fields are used.

I think there is little gain in memory space when encoding this way as 
opposed to if we encoded fully 1.1.1.1 and 2.2.2.2.  I think it is 
indeed a more intelligent way of encoding a common head but there's 
probably little gain in memory space (because headlen and taillen should 
be encoded too).

>    <head-length>  if present is an 8 bit field, which contains the total
>       length (in octets) of the head of all of the addresses.

I think this is an error; the length of the common 'head' part of two 
addresses (most significant bits) should be counted in bits not bytes. 
IPv4 CIDR does so and in IPv6 it is so too.

This error can be seen in action at least in the DYMO spec where the 
length of the head part of an IPv4 address is specified as 3 octets 
whereas it should be 24bits.  Thus DYMO can't represent an IPv6 prefix 
length of eg 26bits (it's not a multiple of 8).

My personal oppinion is to encode fully both addresses.

>    <mid>  is omitted if mid-length == 0, otherwise each <mid> is a field
>       of length mid-length octets, representing the mid of the
>       corresponding address in the address block.

I think 'mid' terminology can overlap the OLSRv1 'MID' term: they don't 
mean the same.

I think neither DYMO nor OLSRv2 use the mid parts of an address, but I 
may be wrong.

> 5.4. Padding

IPv6 has a means to encode padding, rfc2460 (1 octet padding is a '0' 
and N octets of padding is... TLV).  I think we could reuse the IPv6 
mechanisms to do padding instead of a new mechanism.  If we do so we may 
have a contention with PacketBB: if PacketBB suggests padding 3 octets 
to be '0', '0', '0', IPv6 rfc2460 suggests differently: '1', '1', '0'.

Oppinions?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 19 Jun 2007 12:17:23 +0100

From: Alexandru Petrescu [mailto:[email-masked]] 

> opposed to if we encoded fully 1.1.1.1 and 2.2.2.2.

Assuming the latter is a typo for 1.2.2.2 then indeed there isn't much
gain. But supposing it were 1.1.1.1 and 1.1.1.2? Or indeed 1.1.1.x for
several different x values? And suppose it were IPv6 rather than IPv4?
(And IPv6 is the reason for common tail compression.)

> IPv4 CIDR does so and in IPv6 it is so too.

No, it's not an error, it's deliberate. packetbb is octet based. Trying
to make it non-octet based really does add to the complexity for a
trivial gain at best. Given that this is purely about whether the
addresses
have a common part, not any functional meaning, if you have 26 common
bits, then just treat it as 24, the fact that the next 2 bits happen
to be the same is unimportant, they are repreated in each mid.

Now should you record 24 or 3? The latter is more efficient and avoids
issues like "but what if you send 26?".

> length of eg 26bits (it's not a multiple of 8).

It's still not an error, because prefix lengths are represented by a
TLV, where you do specify it in bits.

> My personal oppinion is to encode fully both addresses.

This is the packetbb tradeoff (or one of them) complexity versus
efficiency. Your preference is for lower complexity, lower efficiency.
Other people want both higher. (Well, they want efficiency higher,
the cost is higher complexity.) We've chosen what we think is a
reasonable compromise.

Incidentally there's nothing in packetbb that insists you actually
compress addresses efficiently. You can set both head and tail
lengths to zero and send addresses uncompressed. But you'll need
to be able to handle received compressed addresses.

> I think 'mid' terminology can overlap the OLSRv1 'MID' term: they
don't 

They have nothing to do with each other. But that's all right, OLSRv1
doesn't use packetbb, and OLSRv2 doesn't use MID messages. So there's
no confusion at all.

> may be wrong.

I'm not sure what you mean here. In the example you gave above, 1.1.1.1
and 1.2.2.2, the last 24 bits are the "mid" part - the tail is empty
(zerotail is set). OLSRv2 and DYMO may send or receive addresses like
this.

> to be '0', '0', '0', IPv6 rfc2460 suggests differently: '1', '1', '0'.

The RFC2460 padding (as you report it, I'm not familiar with the
details) won't work here - padding is optional in packetbb.
(Actually I'd be happy to remove it altogether, but someone wanted
it.) All zero padding works very simply - after the end of a packet
header or message just discard all zero octets (because there is no
message type zero - which we need in order to have the option of
a packet headerless packet). I see no point in trying for spurious
compatibility with RFC2460.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 14:42:49 +0200

Hi Christopher,

Dearlove, Christopher (UK) wrote:
>> This representation proposes to encode two addresses 1.1.1.1 and 
>> 1.2.2.2 as a unique head '1' and two tails '1.1.1' and '2.2.2'. Two
>>  'head-len' and 'tail-len' fields are used.
>> 
>> I think there is little gain in memory space when encoding this way
>>  as opposed to if we encoded fully 1.1.1.1 and 2.2.2.2.
> 
> Assuming the latter is a typo for 1.2.2.2 then indeed there isn't 
> much gain. But supposing it were 1.1.1.1 and 1.1.1.2? Or indeed 
> 1.1.1.x for several different x values? And suppose it were IPv6 
> rather than IPv4? (And IPv6 is the reason for common tail 
> compression.)

(yes typo I meant 1.2.2.2 not 2.2.2.2).

Indeed memory space gains of using head-tail compared to full encoding
can vary.

>>> <head-length> if present is an 8 bit field, which contains the 
>>> total length (in octets) of the head of all of the addresses.
> 
>> I think this is an error; the length of the common 'head' part of 
>> two addresses (most significant bits) should be counted in bits not
>>  bytes.
> 
> No, it's not an error, it's deliberate. packetbb is octet based. 
> Trying to make it non-octet based really does add to the complexity 
> for a trivial gain at best. Given that this is purely about whether 
> the addresses have a common part, not any functional meaning, if you
>  have 26 common bits, then just treat it as 24, the fact that the
> next 2 bits happen to be the same is unimportant, they are repreated
> in each mid.

I meant the value contained by the 2bits between 24 and 26 are _not_ the 
same.

> Now should you record 24 or 3? The latter is more efficient and 
> avoids issues like "but what if you send 26?".

I think we don't understand each other.  I don't see how is it possible
to disambiguate two addresses represented as head-tail if we don't
precisely encode the headlength.  Receiver simply can't decode correctly 
a field saying 3octets when sender meant 26bits.

>> This error can be seen in action at least in the DYMO spec where 
>> the length of the head part of an IPv4 address is specified as 3 
>> octets whereas it should be 24bits.  Thus DYMO can't represent an 
>> IPv6 prefix
>> 

Ok - I don't mean prefix length.  I mean to disambiguate two addresses
encoded as head-tail whose headlen is only encoded as octets not bits.

This means I can't encode head-tail two addresses whose most significant 
bits differ at a boundary different than octet - right?

> efficiency. Your preference is for lower complexity, lower 
> efficiency. Other people want both higher. (Well, they want 
> efficiency higher, the cost is higher complexity.) We've chosen what
>  we think is a reasonable compromise.

I understand there's a trade-off.

> lengths to zero and send addresses uncompressed. But you'll need to 
> be able to handle received compressed addresses.

Ok then.  So I think my remark is then to DYMO, or the way DYMO uses
PacketBB to encode messages.

>>> <mid>  is omitted if mid-length == 0, otherwise each <mid> is a 
>>> field of length mid-length octets, representing the mid of the 
>  doesn't use packetbb, and OLSRv2 doesn't use MID messages. So 
> there's no confusion at all.

Ok, so OLSRv2 does _not_ use MID messages but can use mid encoding.

>> I think neither DYMO nor OLSRv2 use the mid parts of an address, 
>> but I may be wrong.
> 
> I'm not sure what you mean here. In the example you gave above, 
> 1.1.1.1 and 1.2.2.2, the last 24 bits are the "mid" part - the tail 
> is empty (zerotail is set). OLSRv2 and DYMO may send or receive 
> addresses like this.

In the example given by DYMO document the encoding is not as you say. 
The address semantics is 1bit (you seem to say it's three).  I am not 
sure whether this is a remark for PacketBB authors to simplify PacketBB 
or to DYMO authors to use it correctly.  But certainly it's an 
incoherence between PacketBB and DYMO.

PacketBB:
> <address-block> = <num-addr> <addr-semantics> <head-length>? <head>? 
> <tail-length>? <tail>? <mid>*
> 
> <addr-semantics>  is an 8 bit field specifying the interpretation of 
> the remainder of the address block:
> 
> bit 0 (nohead):  if cleared ('0'), then <head-length> is included in
> <address-block>, and <head> may be included in <address- block>.  If
> set ('1'), then <head-length> and <head> are not included in
> <address-block>.
> 
> bit 1 (notail) and bit 2 (zerotail):  MUST NOT both be set ('1'). 
> Otherwise, they are interpreted according to Table 1.
> 
> bits 3-7:  are RESERVED and MUST each be cleared ('0') to be in 
> accordance with this version of the specification.

DYMO example:
> Message Body - Address Block 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> |Number Addrs=2 |0|HeadLength=3 |             Head              : 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
> (cont)    |  Target.Tail  |   Orig.Tail   | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Also please allow me to question the necessity of the 'mid' part of an
address.

Why is it necessary to encode an address in a message as a threefold 
head-mid-tail?   Isn't it sufficient to encode an address as
address-and-eventually-prefix-length?

Is there another (non-MANET) protocol using addresses as threefold split 
entities?

>>> 5.4. Padding
>> 
>> IPv6 has a means to encode padding, rfc2460 (1 octet padding is a 
>> '0' and N octets of padding is... TLV).  I think we could reuse the
>>  IPv6 mechanisms to do padding instead of a new mechanism.  If we 
>> do so we may have a contention with PacketBB: if PacketBB suggests
>>  padding 3 octets to be '0', '0', '0', IPv6 rfc2460 suggests 
>> differently: '1', '1', '0'.
> 
> details) won't work here - padding is optional in packetbb. (Actually
>  I'd be happy to remove it altogether, but someone wanted it.)

Err... I don't know.  I think I like packets that are built on precisely
32bit boundaries, they are easier to grasp conceptually and to write
documents about.  They correspond to widely deployed computer
architecture memory schemes and compilers, to standardized ntohs and 
htons, to int C type, etc.

Then, if we accept to use only 32bit-bounded PacketBB messages then 
there exist widely available software libraries to use the IPv6 way of 
padding, no need to write new code or new parts of spec.

> All zero padding works very simply - after the end of a packet header
> or message just discard all zero octets (because there is no message
>  type zero - which we need in order to have the option of a packet 
> headerless packet). I see no point in trying for spurious 

I would find strange PacketBB to carry IPv6 addresses and not refer to 
rfc2460.

Alex

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 19 Jun 2007 14:24:45 +0100

I'm replying to this one, but I may cut it off then, as
time presses on other things.

> a field saying 3octets when sender meant 26bits.

It's really very simple. Take your example of 1.1.1.1 and 1.2.2.2.
This actually has 30 common bits. But we work in common octets
and it has 3. So we send (noting that the different pieces are
mids, not a common tail) what reports that

Head octets = 1
Tail octets = 0
(and hence mid octets = 3, as addres length = 4)
Head octet 0x01
First set of mid octets  0x01 0x01 0x01
Second set of mid octets 0x02 0x02 0x02

And it's all there.

> bits differ at a boundary different than octet - right?

Wrong. See above.

> incoherence between PacketBB and DYMO.

I can't remark on this aspect of DYMO, I haven't looked at it recently.
Obviously if I'd noticed an issue I'd have let the DYMO authors know,
so either it's not there, is there and I missed it, or has been
introduced since I last looked at DYMO. No idea which.

> Also please allow me to question the necessity of the 'mid' part of an

Two main reasons

- IPv6. A node may (I understand) use a common EUI-64 identifier for
  more than one interface, but with different prefixes. This would
  correspond to have a tail length of (at least) 8 octets.

- Network addresses. If I want to send e.g. 10.0.0.0/16 and 10.1.0.0/16
  then I have a common head (1 octet, 10) and a common tail (2 octets,
  0 and 0 - I can use the zerotail bit to avoid sending these).

> rfc2460.

We're only dealing with addresses, so we just need to refer to
IPv6 address architecture. And that's RFC 4291 (recently
obsoleted RFC 3513 which we do refer to.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 16:06:25 +0200

> time presses on other things.

That's fine, thanks.  I am curious to hear others' oppinions as well and 
or wait for your replies later.

> and it has 3.
 > So we send (noting that the different pieces are

So two IPv4 addresses differing at the seventh most significant bit will 
have to be encoded without a common head part - right?

In this case, the spec doesn't seem to say whether a head-length is 
absent or present  but equal to 0:
>    head-length  is a variable, defined to equal <head-length> if
>       present, or 0 otherwise.
> 
>    <head>  is omitted if head-length == 0, otherwise it is a field of
>       the head-length leftmost octets of all the addresses.

It seems to say that head-length must be present and equal to 0.  It 
would be present and adding to unnecessary overhead?

>   correspond to have a tail length of (at least) 8 octets.

YEs, but this doesn't show the necessity of the third 'mid' part.  There 
are only two parts: head and tail ('head' is first 64bits and 'tail' is 
the Interface ID or EUI-64).

>   0 and 0 - I can use the zerotail bit to avoid sending these).

And 'mid'?

[Generally I'm ok - I think I understand the compression effects of
  head-mid-tail type of encoding addresses.  Maybe if more indexes
  (head-uppermid-lowermid-tail) are used then more compression can be
  achieved.  But this looks so different compared to other protocols I'm
  used to.  ROHC compresses headers not addresses - why not using ROHC?.
  Mobile IPv6 message encodings don't compress addresses.  Bandwidth is
  very high on some links.  Etc.]

> obsoleted RFC 3513 which we do refer to.)

YEs, I agree, but there is much more here than just IPv6 address 
architecture once you say PacketBB packets are transported in UDP over 
IPv6...

Alex

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 19 Jun 2007 15:19:39 +0100

> have to be encoded without a common head part - right?

Right.

>>    <head-length>  if present is an 8 bit field, which contains the
total
>>       length (in octets) of the head of all of the addresses.

That "if present" is a pretty good hint that it doesn't have to
be present. But more importantly you missed

      bit 0 (nohead):  if cleared ('0'), then <head-length> is included
         in <address-block>, and <head> may be included in <address-
         block>.  If set ('1'), then <head-length> and <head> are not
         included in <address-block>.

As for including a <head-length> equal to zero, it's legal.
Not efficient, but legal.

> the Interface ID or EUI-64).

No, what I'm saying is that a node may use (using upper case letters
for 64 bits and a / to join them) A/Z and B/Z as two addresses of
the same interface, where Z is its EUI-64. Of course A and B may
also have some head bits in common, or may not.

> And 'mid'?

mid is the uncompressed bit. Always is. Sometimes you have a common
head. Sometimes you have a common tail. Sometimes you have both.
Sometimes you have neither. mid is the bit in the middle that is
different. It can have zero length but that will be (I expect)
uncommon.

> IPv6...

But invisibly to IPv6. packetbb is just carrying the addresses.
It's up to a protocol that does know something about addresses
- maybe DYMO, maybe an autoconf mechanism that uses packetbb
to interpret those addresses. packetbb is NOT a protocol.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 17:16:42 +0200

Dearlove, Christopher (UK) wrote:
> be present.
> But more importantly you missed
> 

Right... I've missed that semantics part, simply because I've never seen 
a protocol header having a 'address semantics' field.  Semantics is to 
me something to be specified in node behaviour, like when node receives 
this bit does that, but not to encode in messages...

> also have some head bits in common, or may not.

Right, that Z is the tail part.

> different. It can have zero length but that will be (I expect)

'mid' is one bit only?  It seems to me it can have a length too: 
mid-length = address-length - head-length - tail-length.

Anyways,  would you agree a simple way to encode a NEMO Mobile Network 
Prefix with PacketBB would look like this (ignoring head:mid:tail 
features)(would you confirm the values of question marks?):

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   <num-addr>  |<addr-semantic>|       <tlv-length>            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   <tlv-type>  |<tlv-semantics>|    <length>   |   Pad '0'     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-                                                             -+
      |                                                               |
      +-                       IPv6 Address                          -+
      |                                                               |
      +-                                                             -+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   <tlv-type2> |<tlv-semantics2|    <length2>  |  PrefixLen    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      num-addr: '1'

      addr-semantics:
               bit 0 (nohead):   '1'
               bit 1 (notail):   '0'
               bit 2 (zerotail): '0'
               bits 3-7:         '0'

      tlv-length: ?

      tlv-type:   ?

      tlv-semantics:
               bit 0 (extended):    '0'
               bit 1 (novalue):     '0'
               bit 2 (noindex):     '1'
               bit 3 (singleindex): '0'
               bit 4 (multivalue):  '?'
               bits 5-7:            '0'

      length: 0x10 ('16' decimal)

      IPv6 address: the IPv6 address that is the Mobile Network Prefix.

      tlv-type2: '0'

      tlv-semantics2: '?'

      length2: '?'

      PrefixLen: Eight-bit unsigned integer indicating the prefix length
                 of the IPv6 Address.

I will post this separately as well.

> to interpret those addresses. packetbb is NOT a protocol.

Well I agree PacketBB is not a protocol.

However, and this is something I've already remarked to DYMO, ignoring 
some fields present in the IPv6 base header (ie rfc2460) is not good 
either.  Also ignoring how other protocols encode addresses (and 
subsequently specifying new means) is too much programming effort when 
reuse could be more efficient.  Just IMHO.

Alex

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 19 Jun 2007 17:25:19 +0200

Alex,

On Jun 19, 2007, at 5:16 PM, Alexandru Petrescu wrote:

>
> Right... I've missed that semantics part, simply because I've never  
> seen a protocol header having a 'address semantics' field.   
> Semantics is to me something to be specified in node behaviour,  
> like when node receives this bit does that, but not to encode in  
> messages...
>

This is not the intended meaning. semantics == "how you should  
interpret the encoded bit-sequence, in order to get an address out of  
it"

What that address then means is for the node/protocol/whatever to  
determine.

I wasn't aware that this could be ambiguously read from the text?

<SNIP>

> mid-length = address-length - head-length - tail-length.

Chris meant to say:

	"mid is the uncompressed part"

Which, yes, can be several bits long.

> Anyways,  would you agree a simple way to encode a NEMO Mobile  
> Network Prefix with PacketBB would look like this (ignoring  
> head:mid:tail features)(would you confirm the values of question  
> marks?):
>

I am sorry, it is not clear to me what you try to do. Are you  
intending to put an address into a TLV? If so, then while you  
possibly could do that, it's not the intended usage (addresses go in  
address blocks, possibly compressed) and I shall refrain from  
commenting on it. Or else, please try to explain what it is you are  
trying to do, since it is not clear.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 17:44:17 +0200

> I wasn't aware that this could be ambiguously read from the text?

Thanks for the explanation of what you mean by semantics of an address:
how to interpret the bit sequence.

Generally, I am of the oppinion that ROHC (RObust Header Compression)
looks at several fields in an IP/UDP/TCP header and finds commonalities
between them, not just at commonalities between addresses.  I think with
some tweaking ROHC could be used in some MANET networks (maybe a new
MANET-ROHC profile?).

>>> mid is the uncompressed bit. Always is. Sometimes you have a
>>> common head. Sometimes you have a common tail. Sometimes you have
>>> both. Sometimes you have neither. mid is the bit in the middle
>>> that is different. It can have zero length but that will be (I
>>> expect) uncommon.
>> 

Ok, so this makes it for three parts of an IP address: head, mid and
tail - each of variable length.

> trying to do, since it is not clear.

I am trying to encode an IPv6 Mobile Network Prefix (an IPv6 address and
the prefixlength) with PacketBB rules.  I understand for that I need to
use a "Address Block TLV" for the prefix length, inserted within an
Address Block after the Address TLV.  Sorry, this may sound confusing,
but that's how I understand it.

I've sent a separate email depicting what I think PacketBB will result
into when encoding an IPv6  Mobile Network Prefix.  Please
agree/disagree with that format.  Otherwise please send a diagram with
what you think PacketBB will result into when encoding an IPv6 Mobile
Network Prefix (the IPv6 address and the prefix length).

Thanks,

Alex