On Oct 14, 2009, at 12:14 , Pascal Thubert (pthubert) wrote:
If you agree with this reasoning then we should really rework the text
above. The assumptions should go away. The second excerpt should
become:
"
Address Resolution: Not performed. Nodes only forward via routers
with which they have a NR/NC relationship.
Any optimization for direct host to host
connectivity is out of scope.
"
Right. 6lowpan-nd-06 is already saying this, but some of the
assumptions do need to be cleaned up (although they had been relaxed).
In Stockholm we relaxed the IID-MAC mapping, and included the
capability to deal with address resolution through the host-router
relationship set up by NR/NC. As Jonathan pointed out, that AR
capability is pretty limited.
What you are proposing is that we don't do AR, and only optimize for
the host-router relationship. Of course host-to-host connectivity is
not prevented, you can contact any node within radio range using its
link-local address.
[Editor hat off]
Personally, I agree with your approach, this is all that is needed in
real applications I have seen so far. I also agree any more general AR
mechanisms should be left for more general future work. This is
optimization at its best - if you don't need it - leave it out.
[Editor hat on]
The other approach people are suggesting is that you do need AR
between all nodes within radio range and that the NR/NC AR approach is
not sufficient.
Now this should be brought back to Carsten's question of the day - Do
we need AR at all, and if so to what extent? Once the WG agrees on
that goal - I am sure we can figure out a way to achieve it.
- Zach
What do you think?
Pascal
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Jonathan Hui
Sent: mercredi 14 octobre 2009 01:01
To: Carsten Bormann
Cc: 6lowpan
Subject: Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: (1)
Addressresolution is a waste of energy
On Oct 13, 2009, at 3:30 PM, Carsten Bormann wrote:
(1) Address resolution is a waste of energy
IPv4 needed address resolution for Ethernet to map a 32-bit address
space, n<32 bits of which were a host number within a network, to a
48-bit MAC address. IPv6 continued to follow that model for
Ethernet even if that strong need no longer was there, with a likely
default mapping but a possibility for manual assignment (or DHCP),
so address resolution (AR) was still needed.
In 6lowpans, the congruence of MAC and IP addresses is a
prerequisite to efficient header compression.
Also, we actually have a way to assign *MAC addresses* the way DHCP
did this for *IP addresses*: 16-bit addresses are not owned by a
device but can be assigned (using NR/NC in 6lowpan-nd-06), so if
there is a need to assign a functional IP address to a device this
can be done by assigning it the equivalent 16-bit MAC address.
In 6lowpans, address resolution requires the establishment (using
energy-wasting packets) and maintenance (using precious memory) of
state that no longer serves a useful purpose.
Using anything but the default mapping causes additional header
overhead, wasting energy.
The need for assigned addresses can easily be covered by assigning
16-bit addresses.
Hence, the decision was to get rid of address resolution and
hardwire the (IID part of the) mapping.
I would like to hear arguments why the above reasoning was
incorrect.
Being a part of the discussion in Dublin, I wouldn't say that the
above reasoning was incorrect, just incomplete in thinking through
the
architectural implications. Playing devil's advocate here, some
points on the flip side:
- This limits IIDs to one 64-bit and one 16-bit value at a time, is
this OK? It limits the number of addresses. It limits the ability
to
assign multiple addresses from different pools possibly from
different
administrative domains. It limits games one might play with
addressing for various purposes.
- The improvement in header compression is limited to the first and
last IP hops. Assuming 14-byte prefix is compressible, the added
cost
is 2 bytes for each address (a total of 4 bytes) overhead when both
IIDs do not map directly to their respective link addresses. When
communicating outside the network, one of the addresses is either
always compressible or not, so the compression argument is even less.
I agree with the primary concern about energy of sending extra
packets
to resolve and address. This is not a code complexity issue. I
would
prefer a mechanism to know if a link address can be computed from an
IID, if not then perform AR. But I'm not sure there is a feasible
way
to get there. There are ways to reduce the frequency by including
LLAOs wherever possible, but doesn't eliminate the need for NS/NA in
the most general case.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system
without producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
