Re: [manet] Three issues with PacketBB

[Alexandru Petrescu <alexandru.petrescu at gmail.com>]

Thomas Clausen wrote:
> 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?

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.
> >
> > 'mid' is one bit only?  It seems to me it can have a length too: 
> > mid-length = address-length - head-length - tail-length.
>
> Chris meant to say:
>
> "mid is the uncompressed part"
>
> Which, yes, can be several bits long.

Ok, so this makes it for three parts of an IP address: head, mid and
tail - each of variable 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?):
>
> 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.

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

> Thomas


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


_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet