Jonathan Hui a écrit :
Hi Richard,
Defining NHCs for each extension header allows the use of LOWPAN_NHC
when those extension headers are present, saving up to 6 bytes.
It could save more if more extension headers are present. For example
often both ESP and AH are present.
Alex
Note
that the current proposal for supporting extension headers only replaces
the Next Header field with the NHC encoding - so no additional bytes are
added in the worst case.
If we change the meaning of the Length field from 8-octet units to
1-octet units, then we save up to 7 bytes per extension header.
The 7 extension headers listed are the only IPv6 extension headers that
I am aware of, though, in my last email, I did solicit the WG for other
headers lurking out there in case I missed them.
--
Jonathan Hui
On Apr 8, 2009, at 10:45 AM, Richard Kelsey wrote:
From: Jonathan Hui <[email protected]>
Date: Wed, 8 Apr 2009 09:57:48 -0700
Sounds good to me. So maybe we should expand to the following:
0: Hop-by-Hop Options
1: Routing
2: Fragment
3: Destination Options
4: Encap Security Payload
5: Authentication Header
6: Mobility Header
7: Reserved
I have lost the thread a bit here. How many bytes do we
save by having an NHC identifier for a particular extension
header type? It seems likely that the marginal advantage
of adding each new NHC identifier is decreasing. Why pick
these seven in particular?
-Richard Kelsey
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
