> From: "Kushalnagar, Nandakishore" <[EMAIL PROTECTED]> > To: <[email protected]>
---------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 <http://6lowpan.tzi.org/6lowpan_20at_20IETF_2063> ] 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? ---------------------- SC: It'd be a mistake, IMHO to add LLC/SNAP (8 bytes) in 802.15.4 layer in order to use only a few bits for protocol number. Even for ethernet, LLC/SNAP only uses 2 bytes in a meaningful way and adds extra overhead of bytes (SSAP=DSSAP always same). Protocol type needs to be looked at every LL-hop - thus header compression at this level would not work. Also, the Lowpan protocol type different than the IP-protocol (L3) type, folks may want to run a lowpan specific protocol that does not run on the IP layer. Thus it may not be a good idea to hold space from IP-protocol space. I don't understand the process of protocol type assignment - but can we ask for a different space for LowPan protocol types ? Also, would like to see 11 bits to shrink to a lower number say 8bits or so. Issue 2 ---Technical work required on encapsulation/format specification: ----- 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. --------------------------------- SC: I don't quite understand the issue of header compression here for IPv6 case. We are doing header compression in IPv6 header, not on 802.15.4 MAC layer address. Since M bit signifies that this packet is routed in LL2-multihop fashion, the final destination would be a MAC-address. I don't see any header compression of final destination when M bit set. Perhaps the draft is not clear about that in the area where it describes LowPan unfragmented header format with M bit. The draft needs to clarify the final destination address type. Thanks, -Samita _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
