Subject: [manet] Representing addresses with PacketBB

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 15:09:58 +0200

PacketBB can represent addresses: network addresses (IPv4 and IPv6) and
other types of addresses.

>    An address is specified as a sequence of address-length octets of the
>    form head:mid:tail.  An address block is an ordered set of addresses
>    sharing the same head and tail, and having individual mids.  Network
>    addresses may be represented using the PREFIX_LENGTH TLV defined in
>    Section 6.

What are the other types of addresses that PacketBB considers?  Is it
link-layer address like MAC defined for IEEE of 48bit length?  If so, I
think it should be specified so.  These addresses have a precisely
defined semantics, including separation in two parts (vendor and id) not
three parts head-mid-tail.

Are there other addresses considered by PacketBB?

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 14:29:57 +0100

> What are the other types of addresses that PacketBB considers?

You can use it for whatever you want. Within the IETF probably
only IPv4 and IPv6. But other applications are possible.

> These addresses have a precisely defined semantics,

But packetbb doesn't. The split is purely for compression.
How we do it is informed by what sort of patterns we
expect, and therefore what sort of compression may be
useful. But as far as packetbb is concerned, addresses
are sets of octets, that we compress, send, and uncompress
at the other end. The meaning and any internal structure
of those addresses is someone else's problem. If our
compression happens to match the internal structure, or
not, don't care.

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