Subject: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 Apr 2016 04:19:55 +0000

Dear All:

Following up on the rough consensus at the 6TiSCH WG meeting at IETF 95:
This is a call for adoption of draft-wang-6tisch-6top-protocol-00 which details the 6P protocol and proposes a solution for a chartered item. 
Please respond by Friday to this mail indicating whether you agree or not with this adoption, and preferably provide some rationale to support your position.
The chairs will evaluate the consensus at the interim, and decide whether the adoption is confirmed or the call needs to be prolonged.

Thanks un advance!

The chairs,

Pascal

---

From: "Wang, Chonggang" <[email-masked]>
Date: Thu, 21 Apr 2016 21:14:40 +0000

Hi Pascal and All,

I have read this I-D. I support to adopt it as the working group draft if it addresses the following comment:

~~~ Beginning of Comment ~~~
In 6TiSCH architecture and terminology working group documents, the concept of ?Bundle? has been proposed to represent a link between nodes.

For example, in the architecture I-D: ?With 6TiSCH, the link abstraction is implemented as a bundle of cells; the size of a bundle is optimal when both the energy wasted idle listening and the packet drops due to congestion loss are minimized.  This can be maintained if the number of cells in a bundle is adapted dynamically, and with enough reactivity, to match the variations of best-effort traffic.?

In the terminology I-D: ?A bundle represents a half-duplex link between nodes, one  transmitter and one or more receivers, with a bandwidth that amount to the sum of the cells in the bundle.  A bundle is globally identified by (source MAC, destination MAC, TrackID).  At Layer 3 a pair of bundles forms a link.  By usining a well-known constant, NULLT, as TrackId for a L3 link, the IP link between adjacent nodes A and B comprises 2 bundles: (macA, macB, NULLT) and (macB, macA, NULLT).?

Therefore, since 6top I-D aims to enable distributed scheduling, I suggest that the 6top protocol should support ?Bundle? as defined in the architecture and terminology I-Ds; For example, to contain the bundle information in 6P messages in Section 4.2.
~~~ End of Comment ~~~

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, April 18, 2016 12:20 AM
To: [email-masked]
Subject: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear All:

Thanks un advance!

The chairs,

Pascal

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

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 22 Apr 2016 05:09:16 +0200

Dear Chonggang,

thanks for your comment. The 6P protocol offers a metadata field whose
content is defined by the scheduling policy. The metadata can specify
whether the cells to be added/remove/counted/ etc.. belong to a particular
slotframe, a particular bundle, a particular chunk, etc.. In this sense 6P
is just a L2 handshake protocol between 2 nodes (represented by macA and
macB as you indicate). The content in the metadata field to be agreed is
defined by the SF.

My feeling however is that a bundle is just a grouping abstraction,
representing indistinguishable cells in terms of behaviour between two
node. A node can track itself the mapping of cells to a bundle, I think
this is internal to the node and the counterpart(neighbor node) can group
them as well by only knowing the trackID right? the 6top message already
contains the source (macA), the destination (macB) and the metadata field
can contain the trackID to indicate that these cells need to be mapped to
the specific track ID. If eventually the node considers them in a bundle,
this is transparent to the counter part no?

Does this make sense?

kind regards,
Xavi

2016-04-21 23:14 GMT+02:00 Wang, Chonggang <[email-masked]>
:

> In 6TiSCH architecture and terminology working group documents, the
> concept of ?Bundle? has been proposed to represent a link between nodes.
>
> For example, in the architecture I-D: ?With 6TiSCH, the link abstraction
> is implemented as a bundle of cells; the size of a bundle is optimal when
> both the energy wasted idle listening and the packet drops due to
> congestion loss are minimized.  This can be maintained if the number of
> cells in a bundle is adapted dynamically, and with enough reactivity, to
> match the variations of best-effort traffic.?
>
> In the terminology I-D: ?A bundle represents a half-duplex link between
> nodes, one  transmitter and one or more receivers, with a bandwidth that
> amount to the sum of the cells in the bundle.  A bundle is globally
> identified by (source MAC, destination MAC, TrackID).  At Layer 3 a pair of
> bundles forms a link.  By usining a well-known constant, NULLT, as TrackId
> for a L3 link, the IP link between adjacent nodes A and B comprises 2
> bundles: (macA, macB, NULLT) and (macB, macA, NULLT).?
>
> Therefore, since 6top I-D aims to enable distributed scheduling, I suggest
> that the 6top protocol should support ?Bundle? as defined in the
> architecture and terminology I-Ds; For example, to contain the bundle
> information in 6P messages in Section 4.2.
> ~~~ End of Comment ~~~
>
> This is a call for adoption of draft-wang-6tisch-6top-protocol-00 which
> details the 6P protocol and proposes a solution for a chartered item.
> Please respond by Friday to this mail indicating whether you agree or not
> with this adoption, and preferably provide some rationale to support your
> position.
> The chairs will evaluate the consensus at the interim, and decide whether
> the adoption is confirmed or the call needs to be prolonged.
>
> Thanks un advance!
>
> The chairs,
>
> Pascal
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Apr 2016 08:08:50 +0000

Hello Xavi:

I agree, and we’ll note that we have yet to define a locally track ID if we need it.

The architecture has it that a L2 track is identified by a source IPv6 address and a local instance ID, both present in packets. This tuple is globally significant.

But we have not defined how that translates in a local ID, like a MPLS label. That label would not circulate in the packets if the time slot information is enough to figure it out and perform the track switching operation (for all, cf Xavi’s paper on G-MPLS).

We’ll also note that recent work on DetNet data plane (https://tools.ietf.org/html/draft-dt-detnet-dp-alt-00#section-4.2.7.2) indicates that we could have more than one bundle out along a track, to enable frame replication. Let us make a side thread on that.

To ChongGang’s point, we also have yet to define RSVP-like reservations using soft cells (as opposed to PCE-based using hard cells), and that process will very probably leverage 6P at each hop. DetNet has not yet provided guidance on how that would be done, but it would be great that this group considers how we’d like it done, so we can influence DetNet.

Take care,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: vendredi 22 avril 2016 05:09
To: Wang, Chonggang <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Subject: Re: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear Chonggang,

thanks for your comment. The 6P protocol offers a metadata field whose content is defined by the scheduling policy. The metadata can specify whether the cells to be added/remove/counted/ etc.. belong to a particular slotframe, a particular bundle, a particular chunk, etc.. In this sense 6P is just a L2 handshake protocol between 2 nodes (represented by macA and macB as you indicate). The content in the metadata field to be agreed is defined by the SF.

My feeling however is that a bundle is just a grouping abstraction, representing indistinguishable cells in terms of behaviour between two node. A node can track itself the mapping of cells to a bundle, I think this is internal to the node and the counterpart(neighbor node) can group them as well by only knowing the trackID right? the 6top message already contains the source (macA), the destination (macB) and the metadata field can contain the trackID to indicate that these cells need to be mapped to the specific track ID. If eventually the node considers them in a bundle, this is transparent to the counter part no?

Does this make sense?

kind regards,
Xavi

2016-04-21 23:14 GMT+02:00 Wang, Chonggang <[email-masked]<mailto:[email-masked]>>:
Hi Pascal and All,

-----Original Message-----
From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, April 18, 2016 12:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear All:

Thanks un advance!

The chairs,

Pascal

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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Apr 2016 08:15:51 +0000

Thanks a bunch, ChongGang:

As you point out, the architecture fails to indicate that the L3 link abstraction is really implemented as a pair of bundles.
I'd suggest we change to:

"
                                                                                 With 6TiSCH, the link
   abstraction is implemented as a pair of bundles of cells, on in each
   direction; the size of a bundle is optimal when both the energy
   wasted idle listening and the packet drops due to congestion loss are
   minimized.  
"

Is this better?

Pascal

> From: Wang, Chonggang [mailto:[email-masked]]
> Sent: jeudi 21 avril 2016 23:15
> To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> Subject: RE: Call for adoption for draft-wang-6tisch-6top-protocol-00
> 
> Hi Pascal and All,
> 
> For example, in the architecture I-D: ?With 6TiSCH, the link abstraction is
> implemented as a bundle of cells; the size of a bundle is optimal when both
> the energy wasted idle listening and the packet drops due to congestion loss
> are minimized.  This can be maintained if the number of cells in a bundle is
> adapted dynamically, and with enough reactivity, to match the variations of
> best-effort traffic.?
> 
> amount to the sum of the cells in the bundle.  A bundle is globally identified
> by (source MAC, destination MAC, TrackID).  At Layer 3 a pair of bundles
> forms a link.  By usining a well-known constant, NULLT, as TrackId for a L3
> link, the IP link between adjacent nodes A and B comprises 2 bundles:
> (macA, macB, NULLT) and (macB, macA, NULLT).?
> 
> Chonggang Wang * Member Technical Staff * InterDigital Communications,
> Inc.
> 1001 E. Hector Street, Suite 300, Conshohocken, PA, 19428 * T: +1
> 610.878.5731 * [email-masked] *
> www.InterDigital.com<http://www.interdigital.com>
> 
> 
> This e-mail is intended only for the use of the individual or entity to which it
> is addressed, and may contain information that is privileged, confidential
> and/or otherwise protected from disclosure to anyone other than its
> intended recipient. Unintended transmission shall not constitute waiver of
> any privilege or confidentiality obligation. If you received this
> communication in error, please do not review, copy or distribute it, notify
> me immediately by email, and delete the original message and any
> attachments. Unless expressly stated in this e-mail, nothing in this message
> or any attachment should be construed as a digital or electronic signature.
> 
>

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Fri, 22 Apr 2016 08:35:23 +0000

Hi,

From 6tisch-architecture draft, it is clear that we have two types of bundles namely L2-bundle (Track forwarding) and L3-bundle (IP Forwarding). As of now Scheduling Function Zero (SFID) and 6P protocol seems to ADD/DELETE the cells dynamically to L3-bundle for neighbor-to-neighbor scheduling.

Hence, TrackID needs to be transmitted in 6P transactions to add/delete cells in specific L3-bundle (MacA, MacB, TrackID). This TrackID in-turn helps to ADD/DELETE the cells to L2-bundle for hop-by-hop scheduling in the future.

One question that needs to be clarified is “Will the 6top generate a unique random number for TrackID or 6top will it try to map the IPv6 flow-dependent meta-data to TrackID in neighbor-to-neighbor scheduling ? ”

6tish Architecture draft: Section 4.5.1.1(Transport mode track forwarding). It is mentioned that “Protocol Data Unit (PDU) is associated with flow-dependent meta-data that refers uniquely to the Track”.

Since packets will reach to network layer in IP forwarding (neighbor-to-neighbor scheduling), it is fine to generate unique TrackID for L3-bundle without considering the PDU flow-dependent meta-data for Neighbor-to-Neighbor Scheduling.

But for hop-by-hop scheduling in the future, track forwarding through G-MPLS at 6top needs to generate TrackID with “flow-dependent-meta-data” for specific end-to-end track. Hence, TrackID generation in L2-bundle needs to consider flow characteristics from Network layer.

My 2 cents,

Satish

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: 2016年4月22日 11:09
To: Wang, Chonggang
Cc: Pascal Thubert (pthubert); [email-masked]
Subject: Re: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear Chonggang,

Does this make sense?

kind regards,
Xavi

-----Original Message-----
From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, April 18, 2016 12:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear All:

Thanks un advance!

The chairs,

Pascal

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 22 Apr 2016 15:10:21 +0200

Satish, all,

I agree that many more cool things can be done with 6P, for example
establishing a track by reserving cells along the multi-hop path between
source and destination.

The design choice for 6P has been to provide minimal information in the
headers, and leave a generic "metadata" field allowing you to do all of
that. That is, you can use today's 6P to do multi-hop track reservation.
The "only" thing you have to do is write an SF which says how the metadata
field is used.

This prevents us from having to spin the 6P version. Makes sense?

Thomas

On Fri, Apr 22, 2016 at 10:35 AM, Satish Anamalamudi (Satish Anamalamudi) <
[email-masked]> wrote:

> Hi,
>
>
>
> From 6tisch-architecture draft, it is clear that we have two types of
> bundles namely L2-bundle (Track forwarding) and L3-bundle (IP Forwarding).
> As of now Scheduling Function Zero (SFID) and 6P protocol seems to
> ADD/DELETE the cells dynamically to L3-bundle for neighbor-to-neighbor
> scheduling.
>
>
>
> Hence, TrackID needs to be transmitted in 6P transactions to add/delete
> cells in specific L3-bundle (MacA, MacB, TrackID). This TrackID in-turn
> helps to ADD/DELETE the cells to L2-bundle for hop-by-hop scheduling in the
> future.
>
>
>
> One question that needs to be clarified is “Will the 6top generate a
> unique random number for TrackID or 6top will it try to map the IPv6
> flow-dependent meta-data to TrackID in neighbor-to-neighbor scheduling ? ”
>
>
>
> *6tish Architecture draft:* Section 4.5.1.1(Transport mode track
> forwarding). It is mentioned that “Protocol Data Unit (PDU) is associated
> with flow-dependent meta-data that refers uniquely to the Track”.
>
>
>
> Since packets will reach to network layer in IP forwarding
> (neighbor-to-neighbor scheduling), it is fine to generate unique TrackID
> for L3-bundle without considering the PDU flow-dependent meta-data for
> Neighbor-to-Neighbor Scheduling.
>
>
>
> But for hop-by-hop scheduling in the future, track forwarding through
> G-MPLS at 6top needs to generate TrackID with “flow-dependent-meta-data”
> for specific end-to-end track. Hence, TrackID generation in L2-bundle needs
> to consider flow characteristics from Network layer.
>
>
>
> My 2 cents,
>
>
>
> Satish
>
>
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* 2016年4月22日 11:09
> *To:* Wang, Chonggang
> *Cc:* Pascal Thubert (pthubert); [email-masked]
> *Subject:* Re: [6tisch] Call for adoption for
> draft-wang-6tisch-6top-protocol-00
>
>
>
> Dear Chonggang,
>
>
>
> 2016-04-21 23:14 GMT+02:00 Wang, Chonggang <
> [email-masked]>:
>
> Hi Pascal and All,
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: "Wang, Chonggang" <[email-masked]>
Date: Fri, 22 Apr 2016 14:19:15 +0000

Hi Xavier,

Agreed. My comment actually should be for SF0 draft. I just clarified that in the call.

Thanks,
Chonggang

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: Thursday, April 21, 2016 11:09 PM
To: Wang, Chonggang <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Subject: Re: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear Chonggang,

Does this make sense?

kind regards,
Xavi

-----Original Message-----
From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, April 18, 2016 12:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear All:

Thanks un advance!

The chairs,

Pascal

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 22 Apr 2016 16:28:49 +0200

Thanks Chonggang for clarifying!

On Fri, Apr 22, 2016 at 4:19 PM, Wang, Chonggang <
[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Xavier Vilajosana
> *Sent:* Thursday, April 21, 2016 11:09 PM
> *To:* Wang, Chonggang <[email-masked]>
> *Cc:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked]

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Sat, 23 Apr 2016 02:18:45 +0000

Hello Thomas,

I agree with your point to keep 6P header with minimal information and it’s scheduling function objective to propose TrackID for L3-bundle (neighbor-to-neighbor scheduling) or L2-bundle (hop-by-hop scheduling).
Thank you for your suggestion to work on “metadata” field with new scheduling function.
We are very interested to work on new scheduling function that is specific to reserve the cells for L2-bundle to support track-forwarding for reactive P2P traffic flows through hop-by-hop scheduling.

Satish

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: 2016年4月22日 21:10
To: Satish Anamalamudi (Satish Anamalamudi)
Cc: Wang, Chonggang; Pascal Thubert (pthubert); [email-masked]; Xavier Vilajosana
Subject: Re: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Satish, all,

I agree that many more cool things can be done with 6P, for example establishing a track by reserving cells along the multi-hop path between source and destination.

The design choice for 6P has been to provide minimal information in the headers, and leave a generic "metadata" field allowing you to do all of that. That is, you can use today's 6P to do multi-hop track reservation. The "only" thing you have to do is write an SF which says how the metadata field is used.

Thomas

On Fri, Apr 22, 2016 at 10:35 AM, Satish Anamalamudi (Satish Anamalamudi) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

My 2 cents,

Satish

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xavier Vilajosana
Sent: 2016年4月22日 11:09
To: Wang, Chonggang
Cc: Pascal Thubert (pthubert); [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear Chonggang,

Does this make sense?

kind regards,
Xavi

-----Original Message-----
From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, April 18, 2016 12:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear All:

Thanks un advance!

The chairs,

Pascal

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________

---

From: "Wang, Chonggang" <[email-masked]>
Date: Wed, 27 Apr 2016 20:19:30 +0000

Hi Pascal,

Your suggestion looks good to me.

Thanks,
Chonggang

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Friday, April 22, 2016 4:16 AM
To: Wang, Chonggang <[email-masked]>; [email-masked]
Subject: RE: Call for adoption for draft-wang-6tisch-6top-protocol-00

"
                                                                                With 6TiSCH, the link

Is this better?

Pascal

> For example, in the architecture I-D: ?With 6TiSCH, the link
> abstraction is implemented as a bundle of cells; the size of a bundle
> is optimal when both the energy wasted idle listening and the packet
> drops due to congestion loss are minimized.  This can be maintained if
> the number of cells in a bundle is adapted dynamically, and with
> enough reactivity, to match the variations of best-effort traffic.?
>
> In the terminology I-D: ?A bundle represents a half-duplex link
> between nodes, one  transmitter and one or more receivers, with a
> bandwidth that amount to the sum of the cells in the bundle.  A bundle
> is globally identified by (source MAC, destination MAC, TrackID).  At
> Layer 3 a pair of bundles forms a link.  By usining a well-known
> constant, NULLT, as TrackId for a L3 link, the IP link between adjacent nodes A and B comprises 2 bundles:
> Therefore, since 6top I-D aims to enable distributed scheduling, I
> suggest that the 6top protocol should support ?Bundle? as defined in
> the architecture and terminology I-Ds; For example, to contain the
> bundle information in 6P messages in Section 4.2.
> ~~~ End of Comment ~~~
>
>
>
> This e-mail is intended only for the use of the individual or entity
> to which it is addressed, and may contain information that is
> privileged, confidential and/or otherwise protected from disclosure to
> anyone other than its intended recipient. Unintended transmission
> shall not constitute waiver of any privilege or confidentiality
> obligation. If you received this communication in error, please do not
> review, copy or distribute it, notify me immediately by email, and
> delete the original message and any attachments. Unless expressly
> stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
>
>
> From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal
> Thubert
> (pthubert)
> This is a call for adoption of draft-wang-6tisch-6top-protocol-00
> which details the 6P protocol and proposes a solution for a chartered item.
> Please respond by Friday to this mail indicating whether you agree or
> not with this adoption, and preferably provide some rationale to
> support your position.
> The chairs will evaluate the consensus at the interim, and decide
> whether the adoption is confirmed or the call needs to be prolonged.
>
> Thanks un advance!
>
> The chairs,
>
> Pascal
>