Re: [Roll] Comments on draft-ietf-6lowpan-routing-requirements-00.txt

Dear Alex,

Thank again for your detail comments. As I told you before, it helps
us to refine our draft.
Some of your comments are about fundamental of 6LoWPAN, so I guess
other 6LoWPANers may help me to give you some answers.
Anyway, I put my thoughts in line.

On Thu, Feb 12, 2009 at 1:31 AM, Alexandru Petrescu
<alexandru.petrescu@gmail.com> wrote:
> [Where should I post this message, to 6LoWPAN or to ROLL list?  Both?]
>
> Dear WG members,
>
> draft-ietf-6lowpan-routing-requirements-00 lists a Problem Statement,
> some Scenarios and a set of Routing Requirements.  Generally I find it a
> well written document, with many meaningful details.
>

Thank you very much for your possitive comments. :)

> There are very many parts of this document to which I silently agree,
> even some parts I wholehartedly agree.  I like the distinction
> route-above mesh-under, and many other parts too.

Thanks again. :)

>
> Some high-level questions:
> -is there a requirement to connect a 6LoWPAN network to the Internet?

Do you mean in terms of routing? Or a general view of 6LoWPAN?
The birth of 6LoWPAN is to make the Low-power low rate network (based
on IEEE 802.15.4) look like an IPv6 link.

If you only meant routing, the reachability can be achieved by mesh
routing (or mesh switching in your comment below) or route-over.

I don't know if it answers your question.

> -is the 6LoWPAN using addressing architecture and longest-prefix match
>  based routing as in the Internet?

Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental.
Although the header compression format is updating in 6lowpan now, you
can find a basic needs of 6lowpan in the RFC.
If I shortly explain, an IPv6 Interface Identifier is obtained from
the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local
address for an IEEE 802.15.4 interface is formed by appending the
Interface Identifier to a certain prefix (see Section 6 and Section 7
of RFC 4944). With regard to routing, I understand the answer is 'yes'
in the case of route-over.
Please kindly let me know if you already checked the RFC and your
intention from the question was different from my answer. :)

> -how many interfaces will a 15.4 device have potentially?
>

Well, currently, as I follow up, one interface only for a sensor node
in 6LoWPAN. A gateway usually have more than one interface (e.g., 15.4
+ 802.11 or others).

> Following are detail questions and comments.  I believe they're not as
> important as the items mentioned above.
>
>> 1.  Problem Statement
>
> Is this _the_ problem statement or should I better go read
> draft-ietf-6lowpan-problem-08?  They differ largely...

First of all, just for your information, draft-ietf-6lowpan-problem-08
is now RFC 4919.
The section 1, problem statement of our draft is focusing on routing
in 6LoWPANs, and RFC 4919 states general problem of 6LoWPAN, including
a brief requirement as you refered in the below.

>
>> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [3])
>> briefly mentions four requirements on routing protocols;
>>
>> (a) low overhead on data packets
>>
>> (b) low routing overhead
>
>
> What is routing more generally?  Is it the act a router performs when
> presenting with a packet, searching in a routing table, maybe exploring
> its ND structures, maybe sending ND messages and then emitting the packet?
>
> Or is it exchanging IP datagrams containing prefixes and metrics and
> reachability information, such that nodes have a common view of the
> network paths?

I would say that it include all the functionalities needed for the
selection of a path from source to destination.
However, I should be careful use the term 'router' here.
Although 6lowpan nodes may perform such routing functionality for the
reachability, it's different from traditional term of 'router'.
In route-over, they call 6lowpan nodes performing routing as 'routers'
- One radio hop is a single IP link.
However, in mesh-under, only one 6lowpan router exists in one 6lowpan
(ER in Figure 2 of the draft) - Whole 6lowpan is One IPv6 link.
To cover the both case, please understand in this way; 6LoWPAN node
may perform such a 'routing-related functionalities'.

>
> I think this is worth discussing, in order to better target what the
> work should follow this problem statement and reqs.
>
> Are the low overhead requirements put on the database construction
> messages?  Or on the individual act of forwarding a packet?

I would say 'on both'.
>
>> On the other hand, the route-over approach relies on IP routing and
>> therefore supports routing over possibly various types of interconnected
>> links (see also Figure 1).
>
> At several places in the draft, when link 'types', device 'types' are
> mentioned, I'm tempted to believe 6LoWPAN considers links other than
> 802.15.4 links?  Is it so?  Should 6LoWPAN routing protocol work also
> with aseptic point-to-point links?
> Or are the 'types' limited within the relatively large scope of 802.3
> compatible MACs (I believe 802.15.4 and 802.16 to fit within).
>
> This is of paramount importance in setting the scope.
>

Oh, link 'type'. ;) Currently 6lowpan is clearly based on 802.15.4,
although some talks that 6LoWPAN can run on top of other radios with
similar characteristics. And, for route-over (as ROLL WG is working
on), the benefit which have been insisted is that the routing
mechanism is link-independent. Mesh-under of 6lowpan is 802.15.4
dependent.
But I don't know what is 'aseptic' point to point links.

>> The most significant consequence of mesh-under routing is that routing
>> would be directly based on the IEEE 802.15.4 standard,
>
> Which 'routing' is directly based on 802.15.4 standard?  The 'IP
> routing' is based on that standard?  This brings back to defining what
> routing is.
>

Ah~ I think we should change the wording. I meant that the
requirements of 6lowpan routing inherit the stringent characterisitcs
of 802.15.4. I will change the text to make it clear. Thanks. :)

> Maybe better call 'mesh-under routing' 'mesh-under switching'.
>
> IP routing and addressing may be fundamentally different than mesh-under
> addressing and switching - in the way hosts get and maintain their
> addresses and in the way routers/switches search their databases (exact
> match vs longest-prefix).
>

Agreed. Either term is okay by me. Just due to the specific
characteristics of 6lowpan configuration,
multi-hop path selection can be achieved in mesh-under. I will ask
others if mesh-under switching is better to be clarified.

>> When a route-over protocol is built in the IPv6 layer, the Dispatch value
>> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed or
>> uncompressed IPv6, followed by the IPv6 header.
>
>
> Sorry, I can't parse this.
>
> A route-over protocol would act both at IP layer and
> application/transport layers.  Depends what a routing protocol is.  For
> example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is
> over UDP.
>
> 'followed by'... when reading left to right or reverse?
>

When I read the text again, it can be confusing. I will try to rephrase it.
6LoPWAN provides compressed or uncompressed IPv6 header.
It just wants to explain the relationship between 6lowpan header and
routing header.
You will get the information from RFC 4944.

>> For route-over, a default route to the ER could be inserted into the
>>  routing system.
>
> In the routing system of the 6LoWPAN network?  Or in the routing system
> of the fixed Internet network?

6lowpan. I will also try to rephrase it to be clear. thanks. :)

>
>> IP-based low-power WPAN technology is still in its early stage of
>
> 'WPAN'?
>
wireless personal area network.
6lowpan = IPv6 over Low power WPAN. But, actually i think it's better
to just use 6LoWPAN, to keep the consistancy of the document.
I will change it.

>> a.  Network Properties:
>>
>> *  Number of Devices, Density and Network Diameter: These parameters
>>  usually affect the routing state directly (e.g. the number of
>> entries in a routing table or neighbor list).  Especially in large
>> and dense networks, policies must
>
> What is 'large' and 'dense'?  Is it about physical dimensions?  Or IP
> dimensions?

It is about physical dimensions.

>
> Density sounds as a physical characteristic (many devices in a small
> area) whereas Diameter sounds as a pure IP term (max number of IP hops).
>
> The number of entries in the routing table mostly depends on the planned
> addressing architecture.  One can have a very high-diameter network with
> a very hierarchical addressing structures, many default routes, and very
> few entries in the routing tables (maybe only 1 per hop).
>

I fully agree with you. I will discuss woth co-authors and modify the
text, since in the case of appropriate hierarchical addressing
structures, what the text of the draft says may not be true.

> Is the addressing architecture for 6LoWPAN networks planned?
>
> Is the addressing architecture following the Internet model?
>

can be both, i think. It's dependent on 6lowpan scenario.

>> b.  Node Parameters:
>
> How many interfaces does a 6LoWPAN node typically have?  This is of
> paramount importance deciding whether any type of repeating/bridging
> needs to happen.

In my view, currently one interface for 15.4, for normal 6lowpan nodes.

>
>> *  Throughput: The maximum user data throughput of a bulk data
>> transmission between a single sender and a single receiver through an
>>  unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows
>> [19]: [...]
>>
>> In the case of 915 MHz band:
>
> Sorry, for my clarification:  is 915MHz the width of band centered on
> the 2.4GHz mentioned above?  Or is it the central frequency (thus
> replacing the "2.4GHz" mentioned above)?

it is the central frequency.

>
>> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by
>> the efficient use of control packets (e.g., minimize expensive multicast
>> which cause broadcast to the entire LoWPAN) and by the efficient routing of
>> data packets.
>
> YEs, but multicast may be more efficient than broadcast - is it
> sufficient?  I think it is sufficient to rely on multicast and avoid
> unnecessary duplication such as in broadcast.
>

multicast may be more efficient. However, 802.15.4 does not support multicast.
for 6lowpan's view, IP multicast is expensive in terms of energy usage
for 6lowpan nodes.

> 'Efficient routing of data packets' - is it also efficient search in the
> routing table?  That may be part of 'routing' too.
>

Good point. :)

>> possibliy
>
> Nit: iy

thanks. ;)

>
>> [R03] 6LoWPAN routing protocol control messages SHOULD not create
>> fragmentation of physical layer (PHY) frames.
>
> Err... I think PHY frames aren't fragmented... not sure I understand
> this requirement?
>
> Sounds as if one wants an UDP control packets to not be sent in several
> pieces, because of overhead involved fragmenting/reassembling.
>
> Then make sure first IP doesn't fragment.
>

It means 6lowpan packet should not occur fragmentation. text will be
modified to make it clear. thanks.

>> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE
>> 802.15.4 frame size [81bytes].
>
> Is this a requirement on the mesh-under link-layer switching protocol?
> Or on the 'route-above' protocol?  If the latter - I think this
> requirement is a violation of layer independence :-)
>
> It sounds very special to me to limit the size of the messages of an IP
> routing protocol.
>
> Knowing that IP can fragment too.

Yes, I know your argument. :) But it's 6lowpan specific requirement,
and as I know many 6lowpaners are agreed on this one. I got a comment
from one roll routing requirement author that this requirement can be
considered in roll as well. I may make a chance to see you to explain
some detail of 6lowpan before the meeting, if you are interested in?
;)

>
>> [R05] The design of routing protocols for 6LoWPANs must consider the
>>  end-to-end latency requirements of applications and IEEE 802.15.4 link
>> latency characteristics.
>
> 'Routing'?  Or 'Transport'?  end-to-end is what Transport typically
> takes care of, not routing.
>
> If Routing: which routing?  The forwarding ahppening at a node?  Or the
> convergence time?  The exchange of routing messages?
>

Erm.. maybe we should consider your comments more deeply. Carles, one
of the authors suggested to remove 'end-to-end' from the text. The
text meant all the mechanisms that are used to perform routing
functions.

>> Some routing protocols are aware of the hop count of a path.
>
> I think all of them are, no?

The text is to explain that simple hop-count is not enough for
6lowpan. There exist Link quality based routing metrics than number of
hops.

>
>> In homes, buildings, or infrastructure, some nodes will be installed
>>  with mains power.  Such power-installed nodes MUST be
>
> If they have mains power - will they use Power-Line Communications?
>

Not necessarily. For communication with sensors/actuators, 802.15.4
radio communication is used, but supported by affluent power instead
of small battery..

>> Building monitoring applications, for instance, require that the mobile
>> devices SHOULD be capable of leaving (handing-off) from an old
>>  network joining onto a new network within 15 seconds [17].
>
> Should such a mobile device change its IP address or is it free to
> change it?
>

Actually, I don't aware such a case that 6lowpan nodes need to change
the IP address yet.
We just give the example of ROLL documents which are targeting
specific applications, to explain some relavent work.

>> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns;
>> point-to-point, point-to-multipoint, and multipoint-to- point, while avoid
>> excessive multicast traffic (broadcast in link layer) in 6LoWPAN.
>
> It's called multicast at link-layer too (802.3); thus it avoids
> unnecessary packet duplication, thus it avoids duplication of
> broadcasted packets and thus avoids excessive traffic.
>
> If we talk IPv6 and recent link layers then I mostly forget the term
> 'broadcast' and use multicast instead.
>

As I explained before, we would like to avoid IP multicast. I will
revise the text to make it clear as 'IP multicast'.

>> 6LoWPAN routing protocols should be designed with the consideration of
>> forwarding packets from/to multiple sources/destinations.
>
> Sorry, what do you mean?  An IP packet with multiple src fields?
>

No, it means that  some applications may have multiple sources that
transmit data to one destination; or a single source may transmit data
to several destination nodes; etc.

>> Current WG drafts in the ROLL working group explain that the workload
>>  or traffic pattern of use cases for 6LoWPANs tend to be highly
>> structured, unlike the any- to-any data transfers that dominate typical
>> client and server workloads.
>
> Sorry, what do you mean by 'any-to-any' data transfers?  Any
> relationship to 'IP anycast'?

No. but if IP anycast is used, it will be one way to implement
any-to-any data transfer.

>
>> [R14] 6LoWPAN protocols SHOULD support secure delivery of control
>> messages.  A minimal security level can be achieved by utilizing AES-
>>  based mechanism provided by IEEE 802.15.4.
>
> Isn't AES superstrong and thus computation intensive and thus
> energy intensive?
>
> Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in
> constrained environments.
>

The IEEE 802.15.4 specification mandates support of AES. So, it is
given as an example of secure mechanism utilized from 802.15.4
features.

>> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello"
>> messages.
>
> ND doesn't send Hello messages, but NS, NA, RS and RA.

Ah~ Good point. we will make it clear for the revision.
>
>> [R18] If the routing protocol functionality includes enabling IP
>> multicast, then it may want to employ coordinator roles, if any, as relay
>> points of group-targeting messages instead of using link-layer
>>  multicast (broadcast).
>
> link-layer multicast no broadcast.

I don't know if 'link-layer multicast' is a proper term when 802.15.4
does not provide multicast.

>
> Nit: 'MAC sub-layer' appears only once and in the figure they're
>     all 'layers'.
>
> Alex

Thanks. we will change it. ;)

Thank you very much to spend your time to review the documents.
We will gather a bit more comments and will soon post the revision
applying your comments.
Your comments are always appreciated. :)

Best Regards,
-eunah

>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>