Subject: [6tsch] 6tus label switching: summary and discussion

From: Thomas Watteyne <[email-masked]>
Date: Wed, 22 May 2013 23:50:41 -0700

All,

We have been talking about 6tus-based label switching in recent
conversations. Let's finalize this discussion so it can make its way into
the 6tus draft.

Here is a summary of what I took from those conversations:
- an inbound packet has an implicit label which is its
slotOffset/channelOffset (i.e. there if no explicit label inside a packet)
- the mote contains a switching table which maps this label to an outbound
cell.
- the packet is queued to be sent over that cell.
- it is up to an upper layer (PCE or distributed protocol) to construct
label switched tracks which correspond to some traffic class.
- it is up to the ingress point to map a packet onto the appropriate label
switched track (LST). This ingress point can be the source node inside the
LLN, or the BBR for a packet coming from outside. In the latter case, the
DSCP of the inbound packet will probably be used for mapping to a FEC.

*Thoughts?*

A number of issues appeared in the discussion, which we need to answer.

*Hop limit*

As with all label switching approaches, one problem is that a packet ends
up traveling multiple hops, without the IPv6's hop limit being decremented
as it gets switched.

There needs to be a mechanism in the way the switching is done so the hop
limit reflects the number of hops the packet traveled over. I can think of
two traditional ways of doing this:
1. a copy of the IP header's hop limit is carried in the label stack. That
copy is decremented at each hop, and copied back into the IP header when
leaving the LST (RFC3443)
2. the ingress point knows the number of hops of the LST it is sending the
packet into, and decrements the hop limits before it enters the track
(RFC3034)

I believe option 1 can not be used if we use an implicit label. Can someone
shed some light on how this is done in GMPLS?

Option 2 might be usable for downstream packets, if the root has DAO
information allowing it to compute a source route. A mote's RPL rank also
indicates something about its "distance" to the root, but it's unclear to
me how that can translate into a TTL decrement.

*Do we need to carry an explicit TTL even when using implicit label?*

*MIMO*
*
*
A bundle (see
http://tools.ietf.org/html/draft-palattella-6tsch-terminology-00) can
contain multiple cells, which are equivalent. Even better, there can be
multiple inbound and multiple outbound cells.

*What impact does this have on the label switching table inside a node?*

Thomas

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 23 May 2013 09:06:03 -0700

Hi Thomas,

this is really a very interesting feature for TSCH networks. As regards 
to the hop limit, the case is identical as tunnelling, and IMHO a little 
drawback of GMPLS, as labels are implicit there is no TTL or hop limit 
field on the label switching. Note that from the IP point of view the 
track will be one hop (as if this was a tunnel).

There are a couple of RFCs that address that issue for MPLS, we should 
go in detail through them and see if this applies to our case.

http://tools.ietf.org/html/rfc3443
http://tools.ietf.org/html/rfc5462

As regards to the mapping of input time slots to output time slots, we 
can also provide many to many mappings, i.e several input cells can be 
mapped to several output cells because all of them are in the same 
bundle. Given that approach then we can provide fancy load balancing 
techniques so output cells are used more fairly. Other approaches might 
try to minimize distance between input cells and output cells so latency 
is optimized, this however might have some impact on the cell usage 
pattern as some cells will be used more times than others for a specific 
traffic pattern.

what do you think?
X

Al 22/05/13 23:50, En/na Thomas Watteyne ha escrit:
> conversations. Let's finalize this discussion so it can make its way 
> into the 6tus draft.
>
> - the mote contains a switching table which maps this label to an 
> outbound cell.
> - it is up to an upper layer (PCE or distributed protocol) to 
> construct label switched tracks which correspond to some traffic class.
> - it is up to the ingress point to map a packet onto the appropriate 
> label switched track (LST). This ingress point can be the source node 
> inside the LLN, or the BBR for a packet coming from outside. In the 
> latter case, the DSCP of the inbound packet will probably be used for 
> mapping to a FEC.
>
> *Thoughts?*
>
> _Hop limit_
> As with all label switching approaches, one problem is that a packet 
> ends up traveling multiple hops, without the IPv6's hop limit being 
> decremented as it gets switched.
>
> There needs to be a mechanism in the way the switching is done so the 
> hop limit reflects the number of hops the packet traveled over. I can 
> think of two traditional ways of doing this:
> 1. a copy of the IP header's hop limit is carried in the label stack. 
> That copy is decremented at each hop, and copied back into the IP 
> header when leaving the LST (RFC3443)
> 2. the ingress point knows the number of hops of the LST it is sending 
> the packet into, and decrements the hop limits before it enters the 
> track (RFC3034)
>
> I believe option 1 can not be used if we use an implicit label. Can 
> someone shed some light on how this is done in GMPLS?
>
> information allowing it to compute a source route. A mote's RPL rank 
> also indicates something about its "distance" to the root, but it's 
> unclear to me how that can translate into a TTL decrement.
>
> _MIMO_
> _
> _
> contain multiple cells, which are equivalent. Even better, there can 
> be multiple inbound and multiple outbound cells.
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 23 May 2013 10:55:45 -0700

Xavi,

My feeling, from our discussions, is that, while label switching is
uber-powerful, not all packets traveling over a 6TSCH network will do so
using switching. For example, in the "best effort" case (used when
bootstrapping a network, or even during normal operation for best effort
type traffic), there will be no switching. This means that the root might
be receiving packets from the same source, but which have been both routed
and switched. To keep consistency, it would be great if those arrived at
the root with the same TTL. That is, it would be nice to be able to use the
uniform model [1], rather than the pipe models. Yet, this might require the
TLL to be carried inline, which is not really satisfying.

Thoughts?

Let me start another e-mail thread for the load balancing case, since I
believe this has an impact on
http://tools.ietf.org/html/draft-wang-6tsch-6tus-00#section-2.8.

Thomas

[1] http://tools.ietf.org/html/rfc3443#section-3.1

On Thu, May 23, 2013 at 9:06 AM, Xavier Vilajosana <
[email-masked]> wrote:

>  Hi Thomas,
>
> this is really a very interesting feature for TSCH networks. As regards to
> the hop limit, the case is identical as tunnelling, and IMHO a little
> field on the label switching. Note that from the IP point of view the track
> will be one hop (as if this was a tunnel).
>
> There are a couple of RFCs that address that issue for MPLS, we should go
> in detail through them and see if this applies to our case.
>
> As regards to the mapping of input time slots to output time slots, we can
> also provide many to many mappings, i.e several input cells can be mapped
> to several output cells because all of them are in the same bundle. Given
> that approach then we can provide fancy load balancing techniques so output
> cells are used more fairly. Other approaches might try to minimize distance
> between input cells and output cells so latency is optimized, this however
> might have some impact on the cell usage pattern as some cells will be used
> more times than others for a specific traffic pattern.
>
> what do you think?
> X
>
> hop limit reflects the number of hops the packet traveled over. I can think
> of two traditional ways of doing this:
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>