Subject: Re: [6lowpan] [Fwd: New Version Notification fordraft-shelby-6lowpan-nd-00]

From: "Schoofs, Anthony" <[email-masked]>
Date: Tue, 4 Nov 2008 16:22:30 +0100

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-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: Friday 24 October 2008 16:58
To: 6lowpan; [email-masked]
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-masked]>
To: [email-masked]
CC:
[email-masked],[email-masked],[email-masked],[email-masked]

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-masked]
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.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Zach Shelby <[email-masked]>
Date: Thu, 06 Nov 2008 16:18:20 +0200

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>

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297