|
All, I took a first stab in addressing some of
the issues in the current specifications of the 6lowpan format document. Please
send suggestions on the list. Issue from the previous meeting: Issue 1: Christian Huitema suggested looking at
existing IANA registries for protocol types to avoid having to set up another
one. Specifically, he suggested looking at IP protocol identifiers. Other
people suggested looking at link-layer registries such as Ethertype and PPP
protocol IDs. This item requires further work. [6lowpan at IETF 63] When examining a specific registry, we
should make sure that it actually is a good fit. The payloads for the 6lowpan
encapsulation are somewhat 6lowpan specific. Raw IPv6 packets are just one
type; we also will have a number of rather 6lowpan specific header compression
schemes. In addition, routing and registration/management messages are quite
likely to be entirely 6lowpan specific. One other consideration would be whether
the 6lowpan registrations would place an undue burden on the original registry.
E.g., there are only 256 IP protocol numbers, which makes them a scarce
resource. One other way to manage the number space
would be to make one or more existing registries part of the 6lowpan number
space. E.g., there could be a selector that chooses between IP protocol numbers
and PPP protocol numbers (assuming both actually make sense in this context). IP protocol numbers are 8 bits. PPP
protocol numbers are 14 bits (expressed in either 8 or 16 bits depending on the
low order bit of the first byte). NK: I looked at IANA and could not find a protocol
type that had the width of 11 bits and that served the purpose of what we
needed. Please let me know if I am wrong here. As for adding ether type may be a good solution,
the document does mention about adding a SNAP header. If we were to add the
SNAP header we could potentially remove the protocol field in the adaptation
layer. But as we discussed in the meeting, how difficult would it be to get a
packet that has ethertype for 6lowpan specific packets such as route messages, etc.
Another issue with adding 8 bytes of LLC/SNAP is that we will loose those bytes
from the header. If there are no heart burns about this, then we
could perhaps choose to add the LLC/SNAP header and remove protocol field from
the header and instead use 6lowpan type field whose values are defined within
this document to indicate types of 6lowpan messages. (routing, discovery, etc).
This is of course assuming that 6lowpan could be made a type under the
definition of SNAP protocol type. Any suggestions? Issue 2 Technical work required on
encapsulation/format specification: Some
discussion ensued about the M-bit and the compression of source addresses in a
multi-hop environment. As this discussion could not be completed on-line, KiHyungKim will send an example
scenario where this matters to the mailing list. [6lowpan at IETF 63] NK: I think I understand what
KiHyungKim was getting at here. Correct me if I am wrong, his argument was that
the source address also changes on a link by link basis and just having a
destination address and compressing out the IP source and destination address
will not work. We need to also add another field that specifies a “multi
hop” source address field when the M bit is present. I would suggest the
following change for the current format when M bit is 1:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF|prot_type|M| Multihop source address | Multihop
Destination Address|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where multihop source and
destination addresses correspond to source and final destination address. Regards, Nandu |
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
