Subject: [6tsch] support to installing Tracks

From: Qin Wang <[email-masked]>
Date: Wed, 19 Jun 2013 23:21:08 +0800

Hi all,

We have had many discussions on Track related topic in threads like
"Routing vs switching". I would like to discuss more about what 6tus should
provide to install a Track, including installing both hard cell based Track
and soft cell based Track.

My understanding is what we can do now is as follows.
(1)  add hard cells along the path, with Cell Commands
(2) specify the mapping between each incoming cell and outgoing cell along
the path, with Label Switching Commands

If my understanding is correct, I can see the following problem: It need
more bandwidth. For example, when you add a hard cell between nodeA and
nodeB, one global communication from PCE to nodeA, and one local
communication from nodeA to nodeB are needed. But for the Label Switching
command, additional two communications, i.e. from PCE to nodeA and from PCE
to nodeB are also needed. In addition, if a given track consists more than
one incoming cells and outgoing cells, more bandwidth for installing the
track will be consumed.

Thus, I would like to suggest to use TrackID to associate incoming cells
and outgoing cells. For sure, the TrackID will not appear in packet, it is
just used to establish the relationship between incoming cells and outgoing
cells. i.e.
(1) add TrackID as a parameter of Cell commands.
(2) same procedure of adding/removing hard cell or soft cell as before.
(3) while receiving adding hard cell or soft cell command,  fill the Track
table with the TrackID. In the Track table, Rx cells are the incoming cells
and Tx cells are the outgoing cells. And then, from TSCH's point of view,
 the schedule is the overlap of all Track tables.

How do you think?

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 20 Jun 2013 00:27:37 -0700

Qin,

[I believe you sent the same e-mail twice, I'm only answering the second
one]

Having some type of track ID would indeed make life much easier. Each RX
and TX cell would simply be associated to a trackID. The switching table
(which I assume you refer to by "track table"?) might not even physically
exist as such in the node's RAM memory. Rather the switching rule is simply
"whatever you receive on an RX cell associaed with trackID 4, transmit on
the next TX cell associated with trackID 4". There could be a trackID which
means "no trackID", to identify the cells which are not associated on a
track, and which can be used for regular routing. When the PCE installs a
hard cell, it would install [direction,slotOffset,channelOffset,trackID].

Does the above sound like what you're proposing?

Assuming that a trackID identifies a flow, is there not some other
number/tuple already available somewhere which could play the role of
trackID without requiring a new numbering space? For example, could the
trackID be the tuple [destination IPv6 address, DSCP]?

Thomas

On Wed, Jun 19, 2013 at 8:21 AM, Qin Wang <[email-masked]> wrote:

> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Jun 2013 20:30:25 +0800

Thomas,

It is exactly what I proposed.

Regarding to how to express trackID, I agree that it would be better to use
something already existing. But there may be some problem to use
[destination IP address, DSCP], especially for the routing devices. For
example, assume nodeC forwards packets from both nodeA and nodeB to same
destination, in same DSCP, then, with [destination IP address, DSCP], nodeC
cannot distinguish the Track from nodeA and the Track from nodeB. Correct?

Qin

On Thu, Jun 20, 2013 at 3:27 PM, Thomas Watteyne <[email-masked]
> wrote:

>> (2) specify the mapping between each incoming cell and outgoing cell
>> along the path, with Label Switching Commands
>>
>> (3) while receiving adding hard cell or soft cell command,  fill the
>> Track table with the TrackID. In the Track table, Rx cells are the incoming
>> cells and Tx cells are the outgoing cells. And then, from TSCH's point of
>> view,  the schedule is the overlap of all Track tables.
>>
>> How do you think?
>>
>> Qin
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Jun 2013 13:48:01 +0000

Hello Thomas:

If we consider that a track is an hard core version of a route as installed by the PCE, then we might extend the thought that we placed there, and use an instance?

TrackIDs could be taken from local instances (there are 64 of those per node) of the destination so the tuple (dest IPv6 ,  instanceID) would identify the track as it identifies routes.

BTW, the proposed update of the architecture draft to reflect the previous discussions is as follows:

Centralized vs.  Distributed Routing
   6TSCH supports a mix model of centralized routes that are computed by
   a Path Computation Entity and distributed routes that are computed by
   RPL over a common physical LLN.
   Both RPL and the PCE may inject routes in the Routing Tables of the
   6TSCH routers.  In either case, each route is associated with a
   topology that is indexed by an instanceID, as defined in RPL
   [RFC6550].  RPL and PCE rely on shared sources to define Global and
   Local InstanceIDs.
   It is possible for RPL and PCE to share a same topology, in which
   case the PCE routes have precedence over RPL routes in case of a
   conflict.
   Inside the 6TSCH domain, the flow label is used to indicate the
   topology that must be used for routing and the associated Routing
   Tables as discussed in [I-D.thubert-roll-flow-label].

What do you think?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: jeudi 20 juin 2013 09:28
To: 6TSCH
Subject: Re: [6tsch] support to installing Tracks

Qin,

[I believe you sent the same e-mail twice, I'm only answering the second one]

Having some type of track ID would indeed make life much easier. Each RX and TX cell would simply be associated to a trackID. The switching table (which I assume you refer to by "track table"?) might not even physically exist as such in the node's RAM memory. Rather the switching rule is simply "whatever you receive on an RX cell associaed with trackID 4, transmit on the next TX cell associated with trackID 4". There could be a trackID which means "no trackID", to identify the cells which are not associated on a track, and which can be used for regular routing. When the PCE installs a hard cell, it would install [direction,slotOffset,channelOffset,trackID].

Assuming that a trackID identifies a flow, is there not some other number/tuple already available somewhere which could play the role of trackID without requiring a new numbering space? For example, could the trackID be the tuple [destination IPv6 address, DSCP]?

Thomas

On Wed, Jun 19, 2013 at 8:21 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

We have had many discussions on Track related topic in threads like "Routing vs switching". I would like to discuss more about what 6tus should provide to install a Track, including installing both hard cell based Track and soft cell based Track.

My understanding is what we can do now is as follows.
(1)  add hard cells along the path, with Cell Commands
(2) specify the mapping between each incoming cell and outgoing cell along the path, with Label Switching Commands

If my understanding is correct, I can see the following problem: It need more bandwidth. For example, when you add a hard cell between nodeA and nodeB, one global communication from PCE to nodeA, and one local communication from nodeA to nodeB are needed. But for the Label Switching command, additional two communications, i.e. from PCE to nodeA and from PCE to nodeB are also needed. In addition, if a given track consists more than one incoming cells and outgoing cells, more bandwidth for installing the track will be consumed.

Thus, I would like to suggest to use TrackID to associate incoming cells and outgoing cells. For sure, the TrackID will not appear in packet, it is just used to establish the relationship between incoming cells and outgoing cells. i.e.
(1) add TrackID as a parameter of Cell commands.
(2) same procedure of adding/removing hard cell or soft cell as before.
(3) while receiving adding hard cell or soft cell command,  fill the Track table with the TrackID. In the Track table, Rx cells are the incoming cells and Tx cells are the outgoing cells. And then, from TSCH's point of view,  the schedule is the overlap of all Track tables.

How do you think?

Qin

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Jun 2013 22:09:59 +0800

Hi Pascal,

I have a problem with using [dest IPv6, instanceID] to identify a Track. My
understanding is the TrackID in each node along the path should be same,
correct? It means PCE has to find a instanceID which has not been used
by  all of the nodes along the path before installing a Track. Did I miss
something?

Qin

On Thu, Jun 20, 2013 at 9:48 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Thomas:****
>
> ** **
>
> If we consider that a track is an hard core version of a route as
> installed by the PCE, then we might extend the thought that we placed
> there, and use an instance?****
>
> ** **
>
> TrackIDs could be taken from local instances (there are 64 of those per
> node) of the destination so the tuple (dest IPv6 ,  instanceID) would
> identify the track as it identifies routes.****
>
> ** **
>
> BTW, the proposed update of the architecture draft to reflect the previous
> discussions is as follows: ****
>
> ** **
>
> Centralized vs.  Distributed Routing****
>
> ****
>
>    6TSCH supports a mix model of centralized routes that are computed by**
> **
>
>    a Path Computation Entity and distributed routes that are computed by**
> **
>
>    RPL over a common physical LLN.****
>
> ****
>
>    Both RPL and the PCE may inject routes in the Routing Tables of the****
>
>    6TSCH routers.  In either case, each route is associated with a****
>
>    topology that is indexed by an instanceID, as defined in RPL****
>
>    [RFC6550].  RPL and PCE rely on shared sources to define Global and****
>
>    Local InstanceIDs.****
>
> ****
>
>    It is possible for RPL and PCE to share a same topology, in which****
>
>    case the PCE routes have precedence over RPL routes in case of a****
>
>    conflict.****
>
> ****
>
>    Inside the 6TSCH domain, the flow label is used to indicate the****
>
>    topology that must be used for routing and the associated Routing****
>
>    Tables as discussed in [I-D.thubert-roll-flow-label].****
>
> ** **
>
> What do you think?****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* jeudi 20 juin 2013 09:28
> *To:* 6TSCH
> *Subject:* Re: [6tsch] support to installing Tracks****
>
> ** **
>
> Qin,****
>
> ** **
>
> one]****
> ** **
> hard cell, it would install [direction,slotOffset,channelOffset,trackID].*
> ***
>
> ** **
>
> Does the above sound like what you're proposing?****
>
> ** **
>
> trackID be the tuple [destination IPv6 address, DSCP]?****
>
> ** **
>
> Thomas****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Wed, Jun 19, 2013 at 8:21 AM, Qin Wang <[email-masked]> wrote:***
> *
>
> Hi all,****
>
> ** **
>
> and soft cell based Track.****
>
> ** **
>
> My understanding is what we can do now is as follows.****
>
> (1)  add hard cells along the path, with Cell Commands****
>
> the path, with Label Switching Commands****
>
> ** **
>
> track will be consumed.****
>
> ** **
>
> cells. i.e.****
> (1) add TrackID as a parameter of Cell commands.****
>
> (2) same procedure of adding/removing hard cell or soft cell as before.***
> *
>
>  the schedule is the overlap of all Track tables.****
>
> ** **
>
> How do you think?****
>
> ** **
>
> Qin****
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Jun 2013 16:00:56 +0000

Hello Qin;

The Destination would be the final node of the track. The tuple allows to reuse the small space (64 local instance IDs) per node.
For nodes along the way this is just an ID as long as the track works, but then it could be useful to tunnel frames if the track breaks.
The cool thing is that the expression of the destination can be compressed with 6LoWPAN, so if we place the instanceID in the flow label we indeed have the full infomartion in the packet.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: jeudi 20 juin 2013 16:10
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] support to installing Tracks

Hi Pascal,

I have a problem with using [dest IPv6, instanceID] to identify a Track. My understanding is the TrackID in each node along the path should be same, correct? It means PCE has to find a instanceID which has not been used by  all of the nodes along the path before installing a Track. Did I miss something?

Qin

On Thu, Jun 20, 2013 at 9:48 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Thomas:

What do you think?

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: jeudi 20 juin 2013 09:28
To: 6TSCH
Subject: Re: [6tsch] support to installing Tracks

Qin,

Thomas

How do you think?

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 20 Jun 2013 17:32:07 -0700

Pascal,
I believe that using the instanceID would both prevent us from reinventing
anything, yet having this capability. In one extreme case, the PCE could
install all the routes in the routing table, which would take precedence
over the ones installed by RPL (per your text).

Qin,
Do you feel comfortable with this approach?

Thomas

---

From: Qin Wang <[email-masked]>
Date: Fri, 21 Jun 2013 08:46:44 +0800

Pascal and Thomas,

Dest IPv6 address is a very cool element in the tuple. I like it. But, I'm
not sure who and how to choose a instanceID in each node while installing a
track. Could you please explain more?

Thanks
Qin

On Fri, Jun 21, 2013 at 8:32 AM, Thomas Watteyne <[email-masked]

>> BTW, the proposed update of the architecture draft to reflect the
>> previous discussions is as follows: ****
>>
>> ** **
>>
>>    6TSCH supports a mix model of centralized routes that are computed by*
>> ***
>>
>>    a Path Computation Entity and distributed routes that are computed by*
>> ***
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Thomas Watteyne
>> On Wed, Jun 19, 2013 at 8:21 AM, Qin Wang <[email-masked]> wrote:**
>> **
>>
>> Hi all,****
>>
>> ** **
>>
>> along the path, with Label Switching Commands****
>>
>> ** **
>>
>> (2) same procedure of adding/removing hard cell or soft cell as before.**
>> **
>>
>> view,  the schedule is the overlap of all Track tables.****
>>
>> ** **
>>
>> How do you think?****
>>
>> ** **
>>
>> Qin****
>>
>>

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 20 Jun 2013 18:29:53 -0700

Hi Qin,

I think that the instanceID in the centralized case will be selected by 
the PCE, this might be part of the information it carries when 
installing a track. In a distributed case, I can think of the following 
method:

a source node aiming to create a track starts a reservation request (L4) 
that will travel through the track until it reaches the destination. At 
each hop nodes can indicate the instanceIDs of the tracks that cross 
through them. The destination will receive the track reservation request 
with all the instanceID that cannot be used. The destination will select 
an instanceID that is not reserved and will prepare the track 
reservation response so all nodes in the track can know their instanceID 
amongst other reservation information.

Note that this is L4 mechanism as we are installing a track through 
multiple nodes. 6tus at L2.5 will be notified by the reservation 
response and will install the appropriate soft links according to the 
required QoS.

this is the simplest way I can imagine.

does it make sense?
X

Al 20/06/13 17:46, En/na Qin Wang ha escrit:
> Pascal and Thomas,
>
> Dest IPv6 address is a very cool element in the tuple. I like it. But, 
> I'm not sure who and how to choose a instanceID in each node while 
> installing a track. Could you please explain more?
>
> Thanks
> Qin
>
>
>
> On Fri, Jun 21, 2013 at 8:32 AM, Thomas Watteyne 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Pascal,
>     I believe that using the instanceID would both prevent us from
>     reinventing anything, yet having this capability. In one extreme
>     case, the PCE could install all the routes in the routing table,
>     which would take precedence over the ones installed by RPL (per
>     your text).
>
>     Qin,
>     On Thu, Jun 20, 2013 at 6:48 AM, Pascal Thubert (pthubert)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hello Thomas:
>
>         If we consider that a track is an hard core version of a route
>         as installed by the PCE, then we might extend the thought that
>         we placed there, and use an instance?
>
>         TrackIDs could be taken from local instances (there are 64 of
>         those per node) of the destination so the tuple (dest IPv6 ,
>         instanceID) would identify the track as it identifies routes.
>
>         *From:[email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Thomas Watteyne
>         *Subject:* Re: [6tsch] support to installing Tracks
>
>         Qin,
>
>         Having some type of track ID would indeed make life much
>         easier. Each RX and TX cell would simply be associated to a
>         trackID. The switching table (which I assume you refer to by
>         "track table"?) might not even physically exist as such in the
>         node's RAM memory. Rather the switching rule is simply
>         "whatever you receive on an RX cell associaed with trackID 4,
>         transmit on the next TX cell associated with trackID 4". There
>         could be a trackID which means "no trackID", to identify the
>         cells which are not associated on a track, and which can be
>         used for regular routing. When the PCE installs a hard cell,
>         it would install [direction,slotOffset,channelOffset,trackID].
>
>         Assuming that a trackID identifies a flow, is there not some
>         other number/tuple already available somewhere which could
>         play the role of trackID without requiring a new numbering
>         space? For example, could the trackID be the tuple
>         [destination IPv6 address, DSCP]?
>
>         Thomas
>
>         On Wed, Jun 19, 2013 at 8:21 AM, Qin Wang
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi all,
>
>         We have had many discussions on Track related topic in threads
>         like "Routing vs switching". I would like to discuss more
>         about what 6tus should provide to install a Track, including
>         installing both hard cell based Track and soft cell based Track.
>
>         (2) specify the mapping between each incoming cell and
>         outgoing cell along the path, with Label Switching Commands
>
>         If my understanding is correct, I can see the following
>         problem: It need more bandwidth. For example, when you add a
>         hard cell between nodeA and nodeB, one global communication
>         from PCE to nodeA, and one local communication from nodeA to
>         nodeB are needed. But for the Label Switching command,
>         additional two communications, i.e. from PCE to nodeA and from
>         PCE to nodeB are also needed. In addition, if a given track
>         consists more than one incoming cells and outgoing cells, more
>         bandwidth for installing the track will be consumed.
>
>         Thus, I would like to suggest to use TrackID to associate
>         incoming cells and outgoing cells. For sure, the TrackID will
>         not appear in packet, it is just used to establish the
>         relationship between incoming cells and outgoing cells. i.e.
>
>         (3) while receiving adding hard cell or soft cell command,
>          fill the Track table with the TrackID. In the Track table, Rx
>         cells are the incoming cells and Tx cells are the outgoing
>         cells. And then, from TSCH's point of view,  the schedule is
>         the overlap of all Track tables.
>
>         How do you think?
>
>         Qin
>
>
>         [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Jun 2013 09:03:30 +0000

Hello Xavi and Thomas:

Note that the local instance ID is only unique to the IPv6 address that goes with it. So there is no need to check for uniqueness along the path. It is normally up to the owner of that IPv6 address to select an instance ID.

So if we pick the tunnel termination point as the owner of the instance ID I thought that it would be carried on the resv back that actually commits the time slots in rsvp.
OTOH if we picked the tunnel source then it could be carried in the path message.

In the case of the PCE it would be returned to the PCE upon completion of the tunnel establishment.

Do you see a need for a local ID at each hop?

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: vendredi 21 juin 2013 03:30
To: [email-masked]
Subject: Re: [6tsch] support to installing Tracks

Hi Qin,

I think that the instanceID in the centralized case will be selected by the PCE, this might be part of the information it carries when installing a track. In a distributed case, I can think of the following method:

a source node aiming to create a track starts a reservation request (L4) that will travel through the track until it reaches the destination. At each hop nodes can indicate the instanceIDs of the tracks that cross through them. The destination will receive the track reservation request with all the instanceID that cannot be used. The destination will select an instanceID that is not reserved and will prepare the track reservation response so all nodes in the track can know their instanceID amongst other reservation information.

Note that this is L4 mechanism as we are installing a track through multiple nodes. 6tus at L2.5 will be notified by the reservation response and will install the appropriate soft links according to the required QoS.

does it make sense?
X

Dest IPv6 address is a very cool element in the tuple. I like it. But, I'm not sure who and how to choose a instanceID in each node while installing a track. Could you please explain more?

Thanks
Qin

On Fri, Jun 21, 2013 at 8:32 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Pascal,
I believe that using the instanceID would both prevent us from reinventing anything, yet having this capability. In one extreme case, the PCE could install all the routes in the routing table, which would take precedence over the ones installed by RPL (per your text).

Qin,

Thomas

On Thu, Jun 20, 2013 at 6:48 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Thomas:

What do you think?

Pascal

Qin,

Thomas

How do you think?

Qin

6tsch mailing list

---

From: Qin Wang <[email-masked]>
Date: Fri, 21 Jun 2013 20:52:11 +0800

Hi all,

I like the concept of "owner of tunnel", or "owner of track" introduced by
Pascal. Based on the concept, we can define a trackID as [owner IPv6
address, owner instanceID],  and the owner is the node who initializes the
procedure to establish a track. In another word, the IPv6 address could be
the source IPv6 address or the destination IPv6 address, depending on who
is its owner. In this way,it will be guaranteed that the trackID is unique
in the network.

How do you think?

Qin

On Fri, Jun 21, 2013 at 5:03 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Xavi and Thomas:****
>
> ** **
>
> Note that the local instance ID is only unique to the IPv6 address that
> goes with it. So there is no need to check for uniqueness along the path.
> It is normally up to the owner of that IPv6 address to select an instance
> ID. ****
>
> ** **
>
> So if we pick the tunnel termination point as the owner of the instance ID
> I thought that it would be carried on the resv back that actually commits
> the time slots in rsvp.****
>
> OTOH if we picked the tunnel source then it could be carried in the path
> message. ****
>
> ** **
>
> In the case of the PCE it would be returned to the PCE upon completion of
> the tunnel establishment. ****
>
> ** **
>
> Do you see a need for a local ID at each hop?****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> Of *Xavier Vilajosana
> *Sent:* vendredi 21 juin 2013 03:30
> *To:* [email-masked]
>
> the PCE, this might be part of the information it carries when installing a
> track. In a distributed case, I can think of the following method:
>
> with all the instanceID that cannot be used. The destination will select an
> instanceID that is not reserved and will prepare the track reservation
> response so all nodes in the track can know their instanceID amongst other
> reservation information.
>
> multiple nodes. 6tus at L2.5 will be notified by the reservation response
> and will install the appropriate soft links according to the required QoS.
>
> Al 20/06/13 17:46, En/na Qin Wang ha escrit:****
>
>  Pascal and Thomas, ****
>
> ** **
>
> track. Could you please explain more?****
>
> ** **
>
> Thanks****
>
> Qin****
>
> ** **
>
> ** **
>
> On Fri, Jun 21, 2013 at 8:32 AM, Thomas Watteyne <
> [email-masked]> wrote:****
>
> Pascal, ****
>
> over the ones installed by RPL (per your text).****
>
> ** **
>
> Qin, ****
>
> Do you feel comfortable with this approach?****
>
> ** **
>
> Thomas****
>
> ** **
>
> [email-masked]> wrote:****
>
>  Hello Thomas:****
>
>  ****
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>