Anthony,
Thanks for the feedback. We are also thinking of ways to simplify the
message structure of the draft, which has been identified as the biggest
problem with -00. Below is a suggestion how that could be done.
The Identity Option can be removed as you suggested. The Address Option
had fields for Suffix and Prefix compression, which are quite flexible,
but oversized. There was also plenty of reserved space in the Address
Option. So in order to simplify the message format I've made an example
with the following changes below:
- Moved the G,P,X,Status fields from Indentity Option to the RR/RC
message body.
- Moved the Lifetime to the Address Option.
- Thus the Identity Options are no longer needed, each address binding
has its own lifetime.
- Reduce P,S fields to 4-bits.
- Integrated the PAN-ID,16-bit short address options to P,S of the
Address Option.
- Thus the 6LoWPAN Address Option no longer needed separately, now part
of the Address Option.
This simplifies everything, saves 8 bytes per message, and leaves us
with a single option type for RR/RC messages. So messages would look
like this in either direction:
ICMP(RR/RC(Address Option[0], Address Option[n]))
I have drafted an update of this modified message structure below. Is
this sufficiently simple for people?
---
4. 6LoWPAN ND messages
This section introduces message formats for all messages used in this
specification. The new messages are all ICMPv6 messages and extend
the capabilities of "The IPv6 Neighbor Discovery Protocol" [RFC4861].
4.1. Router Registration/Confirmation message
The Router Registration (RR) and Router Confirmation (RC) messages
are used by a Host to register with an ER, and for the ER to confirm
the binding. Any option that is not recognized MUST be skipped
silently. The Router Registration message is sent by the LoWPAN Node
to an on-link ER or Router, and may be sent unicast or to the
6LOWPAN_ER anycast address.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID |G|P|X| rsv | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Router Registration/Confirmation message format (16 octets)
IP Fields:
Source Address: A Link-local IPv6 address. This address may be
an optimistic address.
Destination Address: A link-local IPv6 address of an Edge Router
or Edge Router Relay.
Hop Limit: 255
ICMP Fields:
Type: TBD by IANA.
Code: 0
Checksum: The ICMP checksum.
TID: A unique Transaction ID assigned by the host to match
replies.
G: 1-bit Global Address Request flag. Set to indicate that the
host is requesting global addresses in a request. Set to
indicate that a global address has been assigned in a
confirmation. Otherwise must be 0.
P: 1-bit Primary flag. Set to indicate that the router is primary
and MAY proxy for the node if Proxy ND is used on the backbone
link in a request. If the flag is not set then the router MUST
not proxy for the node. Flag is echoed in a confirmation.
X: 1-bit Proxy Flag. Only used in a confirmation, indicates that
the router actually proxies for all of the addresses in the
options field that are being assigned to the node. This can
only happen if the P flag is set as well. Set to 0 in a
request.
Status: 8-bit unsigned integer. Values TBD. 0 means unqualified
success. Any value below 128 is a positive status that means
that the binding was created or is being created
optimistically. Only used in a confirmation.
Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Host Interface Identifier: A globally unique identifier for the
requesting host's interface.
Possible Options:
Address Option(s)
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognized
and continue processing the message.
<snip>
4.5. 6LoWPAN ND Message Options
This section defines the common ND for 6LoWPAN message options.
4.5.1. Address Option
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | P | S |D| rsv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IPv6 Address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Address Option format (8-16 Octets)
Type: TBD.
Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets.
P: 4-bit unsigned integer. Identifies prefix compression in use, if
any.
0: Prefix is carried inline.
1: Prefix compressed and link-local (fe80:/10) is assumed.
2: A 16-bit PAN-ID is carried inline.
3-127: Reserved.
S: 4-bit unsigned integer. Identifies suffix compression in use, if
any.
0: Suffix carried inline.
1: Suffix compressed and assumes the same value as the Host
Interface Identifier field in the RR/RC message header.
2: Suffix compressed and is derived from the 6LoWPAN PAN ID/SHORT
address option as defined in RFC 4944.
3-127: Reserved.
D: 1-bit Duplicate flag. When set, indicates that duplicates are
allowed for this address (to support anycast) in a request.
Lifetime: 32-bit unsigned integer. The amout of time in units of
seconds remaining before the binding of this address MUST be
considered expired. A value of zero indicates that the Binding
Cache entry for the registered node MUST be deleted.
Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
IPv6 Address:
<snip>
Schoofs, Anthony wrote:
Hi Zach,
I have a comment regarding the message/option structure of the nd-00 draft.
The draft mentions: "The RR contains the addresses the node wants to register, and a
possible request for a global assigned address."
It seems that the Identity Request option will only be used by LowPAN hosts
when they send RRs, and Identity Replies by LowPAN Routers or LowPAN ERs when
they send RCs.
Therefore sending a RR already indicates that an Address/6lowpan Address option
will be an Identity request option, and sending a RC already indicates that an
Address/6lowpan Address option will be an Identity Reply option. I would then
say that the Identity Request and Identity Reply options are not that
necessary, and that you could upgrade Address Option and 6lowpan Address Option
as RR/RC options. It would mean small changes in the Address and 6lowpan
Address options format to incorporate requisite fields from Identity
Request/Reply such as Lifetime and G, P and X flags.
Best regards,
Anthony
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zach Shelby
Sent: Friday 24 October 2008 16:58
To: 6lowpan; [EMAIL PROTECTED]
Subject: [6lowpan] [Fwd: New Version Notification fordraft-shelby-6lowpan-nd-00]
Hi,
The first version of the ND for 6LoWPAN I-D has now been posted and is
available for comment. We would appreciate constructive comments and
list discussions on this before the IETF, and I would like to request a
slot in Minneapolis to present the draft.
http://www.ietf.org/internet-drafts/draft-shelby-6lowpan-nd-00.txt
There are some known open issues on this draft:
o Trickle and its optional use for RA periods in to be in next version.
o Fault tolerance to be defined in next version.
o Ad-hoc network (no infrastructure) to be discussed in next version.
o Context dissemination to be described in more detail. To be determined
in how much detail.
o Can the 6LoWPAN Address Option be integrated into the Address Option
using options in the S field? One less option..
o Consistent for both mesh under and route over may not be 100%
consistent yet
Regards,
Zach
-------- Original Message --------
Subject: New Version Notification for draft-shelby-6lowpan-nd-00
Date: Fri, 24 Oct 2008 07:47:19 -0700 (PDT)
From: IETF I-D Submission Tool <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC:
[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
A new version of I-D, draft-shelby-6lowpan-nd-00.txt has been
successfuly submitted by Zach Shelby and posted to the IETF repository.
Filename: draft-shelby-6lowpan-nd
Revision: 00
Title: Neighbor Discovery for 6LoWPAN
Creation_date: 2008-10-24
WG ID: Independent Submission
Number_of_pages: 39
Abstract:
The 6LoWPAN format allows IPv6 to be used over very low-power, low-
bandwidth wireless networks often making use of extended multihop
topologies. However, the use of standard IPv6 Neighbor Discovery
over 6LoWPAN networks has several problems. Standard ND was not
designed for wireless links, the standard IPv6 link concept and heavy
use of multicast makes it inefficient. This paper specifies Neighbor
Discovery optimized for 6LoWPAN.
The IETF Secretariat.
--
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND
mobile: +358 40 7796297
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
The information contained in this message may be confidential and legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this message is
strictly prohibited and may be unlawful. If you are not the intended recipient,
please contact the sender by return e-mail and destroy all copies of the
original message.
--
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND
mobile: +358 40 7796297
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
