Subject: [6tsch] minutes WebEx 12 April 2013

From: Thomas Watteyne <[email-masked]>
Date: Mon, 15 Apr 2013 23:51:55 -0700

All,

You will find the minutes of the last webex below (thanks Xavi for taking
notes!). Please fix anything I might have missed directly in the e-mail and
reply.

The suggestions raised during the webex for the charter are filed at
https://bitbucket.org/6tsch/charter-ietf-6tsch/issues.

These minutes are also available at https://bitbucket.org/6tsch/meetings/.

Thomas

---

Note: timestamps in PDT.

Present (alphabetically)
--------------------------

* Thomas Watteyne
* Pascal Thubert
* Alfredo Grieco
* Adrian Farrel
* Herman Storey
* Maria Rita Palattella
* Ted Lemon
* Tina Tsou
* Tom Phinney
* Xavi Vilajosana
* Yoshihiro Obha
* Dominique Barthel
* Gennaro Boggia

Recording
---------

* Webex recording (audio+slides,streaming)
*
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=67438047&rKey=29d1816716c79280[65min]

Slides
------

* 130412_slides_webex.pptx: slides shared during the call

Agenda
------

* update work on PANA [Yoshihiro] [5min]
* Conclude work on NSIS [Xavi] [5min]
* Review / finalize archi 01 [Pascal] [5min]
* discuss charter [Thomas, all] [45min]

Minutes
-------

* [08.02] meeting starts
* [08.02] Context Pascal to Ted
    * Ted no opinion whether routing or internet area applies best for
6TSCH,
      but willing to help 6TSCH get IESG aware. Decision on whether Ted or
      Adrian can be taken later.
* [08.05] Pascal presents agenda
* [08.06] update work on PANA [Yoshihiro]
    * work on-going
    * 6 contributors
    * agreed on TOC
    * start analyzing gap
    * 3 phase for key management
    * discussion
        * [Pascal] From gap analysis, can we use existing standards?
        * [Yoshihiro] Depends on what requirements come up with. If need
new,
          we need to discuss next steps. This document describes more the
          architecture.
        * [Pascal] If we end up needing a new standard work, should be done
          in 6TSCH or in security area?
        * [Yoshihiro] Will depend on the requirements.
        * [Pascal] Will need to be open in the charter.
* [08.12] Conclude work on NSIS [Xavi]
    * has been doing lots of reading on NSIS.
    * NSIS clear fit for distributed scheduling in 6TSCH.
    * Yet, heavy implementation, and lots of signaling overhead.
    * Not clear whether can be used directly for transporting PCE signaling.
    * [Thomas] Could PCEP not be used for PCE-to-motes communication?
    * [Xavi] Probably.
    * [Pascal] NSIS is veyu heavy.
    * [Pascal] not a big deal is need PCEP and RSVP since very lean.
    * [Xavi] John is looking at PCEP.
* [08.19] update on draft-thubert-6tsch-architecture [Pascal]
    * Discussion hasn't moved much in last weeks
    * Yet we might want to incorporate DTLS and COAP
    * We not have a much clearer picture of the protocols, so we will be
able to
      submit a new version of the draft.
    * [Thomas] When could this submission be?
    * [Pascal] Possibly immediately.
* [08.23] discusion on draft charter [Thomas]
    * Thomas presents latest version of the draft charter
    * available at https://bitbucket.org/6tsch/charter-ietf-6tsch/src
    * outline very conventional.
    * First part of presenting IEE802.15.4e:
        * focuses on the tsch mode of the 15.4e
        * 6tsch is adaptation layer
        * support both distribute and centralized scheduling approaches
        * focuses on the scheduling of such networks.
    * [Pascal] Are we limited to IEEE802.15.4e? Can we imagine other
        macs/phy in the future?
    * [Thomas] goal is to avoid discussions about other MAC layers that are
        not related at all.
    * [Thomas] however tsch is the most wide representation of the kind of
        networks we want to address
    * 3 scheduling approaches:
        * centralized PCE: entity out the network and pushes the schedule to
          the network
        * distributed resource reservation: signaling protocol used to
          establish pipes between source and destination
        * best effort: bootstrap case. best effort traffic class. smallest
          configuration to be able to inter-operate.
    * Multiple backbone routers:
        * transit links.
        * scale devices in the same subnet-> layout a high speed
backbone(RPL
           root, or 6LowPAN lbr), that is able to route to transit nodes
which
           moved to another subnet.
        * backbone router, was presented in orlando meeting.
    * [Tom] add "diversity" together with jitter,latency, loss. Diversity
        needs to continue on the backbone as part of the routing.
    * [Thomas] absolutely, will do.
        Filed at https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/1
    * Include architecture recommendation on how to deal with multiple BBR,
how
       we aim to deal with synchronization, etc..
    * Coordination with IPSO,IoT6, ISA, IEEE. (assemble pieces from other
       groups).
    * [Herman] how to stablish a performance criteria on that networks.
       Specially for backbone. ISA100 differentiates between backhaul and
       backbone. What are the exact performance criteria which trigger a
switch
       between the two cases?
    * [Pascal] Currently, there is no item (and requirement) for backhaul,
       just BB. No particular plans on neighbor discovery, routing over the
       backhaul.
    * [Herman] Difference between BB and BH imporant in ISA100. BH can be
       used e.g. for inter-continental communication. 60% of automation is
done
       remotely.
    * [Thomas] We can have several good technocal discussions about how to
       split the management entity between close to the network and far.
From
       an administrative point of view, let's add this case to the backbone
       work
    * [Pascal] Placing constraints in terms on latency. Let's move that
       constraint on the architecture.
    * work items
    * Thomas will proxy comments from Michael richardson, who could not be
at
      the webex.
    * list of work items:
        * 6tus layer: adaptation layer. Michel suggests that bootstraping is
          too generic. This suggestion is captured in
          https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/2
        * Centralized management. presence of a PCE. define how the pce
          communicates to the network and how it extracts information from
it.
        * distributed management. looking at NSIS and RSVP.
        * best effort: 6tsch minimal operation. No PCE nor Dist.SCheduling.
          Minimum set of things that can be done to stablish a minimal
traffic
          support. Local reservation. Very minimal set of requirements.
Initial
          setup of basic links.
        * 6tsch architecture. Put together all of pieces. Describing
          implementation, highlight differences of data flows.
        * TSCH overview: highlights of 15.4e tsch mode, and what is missing
          that 6TSCH needs to do.
    * Non-milestone work items:
        * implementors guide. sharing best practices of implementation.
        * coexistence: how 6tsch network can operate in the presence of
similar
          TSCH (ISA100.11a,Whart). make cohexistence simpler.
interoperability
          testing.
        * applicability statement. How it answer the requirements.
    * [Thomas] do we put security as a work item or do we integrate it on
        each work item?
    * [Pascal] Could be part of the architecture
    * [Tom] if security is everywhere put it at every work item.
    * [Thomas] Every document we generate needs to have a security section.
      We can create a separate work item in charter. Captured in
      https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/3
    * Milestone dates:
        * too early for that, let's wait
    * [Pascal] What should be doing now thinking on the BOF in Berlin?
    * [Ted] Having the charter ready for Berlin is good.
    * [Adrian]
        * Instead of milestones and dates, put work items in chronological
          order better.
        * Work out what is missing, and clean up the drafts.
        * Work out what you want to do in the BoF. Plan the agenda. Describe
          the environment,etc. Do a good planning is what would help on the
          BoF acceptance.
        * You will get questions about deployment use cases. Why would
people
          want to run IP on that particular IEEE networks. Rather than what
          could be done, answer what the needs are.
        * Good starting points:
            * http://trac.tools.ietf.org/bof/trac/
            * RFC5434
            * RFC6771
* [09.15] meeting ends

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Apr 2013 12:01:01 +0200

Le 16/04/2013 08:51, Thomas Watteyne a écrit :
[...]
> on draft charter [Thomas] * Thomas presents latest version of the
> draft charter * available at
> https://bitbucket.org/6tsch/charter-ietf-6tsch/src

Just curious...

One of the main items suggested is an 'Adaptation Layer'.

> Produce "6tus Adaptation Layer Specification" to define the operation
> of the adaptation layer between the 6LoWPAN/RPL networking layer and
> the IEEE802.15.4e TSCH MAC layer.

But there exists already an Adaptation Layer for 802.15.4 in section 5
"LoWPAN Adaptation Layer and Frame Format" of RFC 4944 "IPv6 over 802.15.4".

Is there a relationship between these?

Alex

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Apr 2013 09:42:13 -0400

>>>>> "Thomas" == Thomas Watteyne <[email-masked]> writes:
    Thomas> * Thomas will proxy comments from Michael richardson, who
    Thomas> could not be at the webex.

Thank you...  but, it's unclear to me which items you relayed.

    Thomas> * 6tus layer: adaptation layer. Michel suggests that bootstraping is
    Thomas> too generic. This suggestion is captured in
    Thomas> https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/2

yes, that was me. s/Michel/Michael/

My other question, which I wanted an opinion was whether it made sense
for 6tsch to adopt the industrial applicability statement, or whether
the "best effort" part of the industrial uses should remain in ROLL.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Qin Wang" <[email-masked]>
Date: Tue, 16 Apr 2013 06:46:53 -0700

Hi Alex,

My understanding is for 802.15.4 only LoWPAN Adaptation layer is enough.
But for 802.15.4e TSCH, another adaptation layer is also needed, because
the schedule of TSCH has to been filled by someone instead of TSCH itself.

Thought?

Qin

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Apr 2013 09:46:51 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:

    Alexandru> Just curious...

    Alexandru> One of the main items suggested is an 'Adaptation Layer'.

    >> the IEEE802.15.4e TSCH MAC layer.

    Alexandru> But there exists already an Adaptation Layer for 802.15.4
    Alexandru> in section 5 
    Alexandru> "LoWPAN Adaptation Layer and Frame Format" of RFC 4944
    Alexandru> "IPv6 over 802.15.4". 

    Alexandru> Is there a relationship between these?

I believe that calling 6tus an "adaptation layer" is an incorrect
and confusing statement.  While there is some protocol required for
setting up the schedules (the PCE link), and some protocol may be needed
to discover/record the route which requires bandwidth (NSIS/RSVP), once
they are set up, my understanding is that the bits on the wire for a
15.4e communication will be identical to a 15.4.  

What will differ is when the bits are communicated and possibly how
they are routed.

So 6tus is really a standardized set of API requirements between the MAC
layer and a routing layer (RPL) that permits the routing layer to
understand and/or specify the constraints/features of the schedule.

I think that an outcome could be in RPL metrics, but this is not a
consensus opinion at this point.

---

From: "Qin Wang" <[email-masked]>
Date: Tue, 16 Apr 2013 07:06:25 -0700

Hi Michael,

Can you explain more about the difference between "adaptation layer" and
"standardized set of API"?

IMHO, if a message exchange protocol between two nodes is involved,
"layer" is suitable; if only a device self is involved, "API" is suitable.

Make sense?

Qin

---

From: "Qin Wang" <[email-masked]>
Date: Tue, 16 Apr 2013 07:06:28 -0700

Hi Michael,

Make sense?

Qin

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Apr 2013 11:18:22 -0400

>>>>> "Qin" == Qin Wang <[email-masked]> writes:
    Qin> Can you explain more about the difference between "adaptation
    Qin> layer" and 
    Qin> "standardized set of API"?

If you look at a picture of a protocol stack, "IP" is for instance, an
adaptation layer between TCP and Ethernet.  You can see it because there
are bits in the packet.

6lowpan is an adaptation layer, because it tells you how to split up
large IP packets into multiple 15.4 frames.

6tus will connect two parts that are inside the node, and won't reach
outside the node.

    Qin> IMHO, if a message exchange protocol between two nodes is involved,
    Qin> "layer" is suitable; if only a device self is involved, "API"
    Qin> is suitable. 

Please point to the message exchange protocol which will be used on
every packet.  (Not just the control protocol)

---

From: "Qin Wang" <[email-masked]>
Date: Tue, 16 Apr 2013 17:49:55 -0700

Michael,

>From your email, my understanding is if there are bits in packet and reach
outside the node, "Layer" should be more suitable. Correct?

In the current version of 6tus, both hard cell and soft cell are
introduced. For reserving a cell in a schedule, especially soft cell,
message exchanges between one-hop neighbors are needed. It is implemented
with Information Elements (IE) in packet. In another word, you can see
specific bits in packet, and also reaching outside a node. So, I don't
understand why you think "API", instead of "Adaptation Layer", is suitable
for the case.

Did I miss something? Can you explain more?

Qin

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Apr 2013 11:37:33 +0000

Hi Michael:

The action of the 6TUS scheduler is actually visible from the outside if oine observes which frame ends up in which time slot.
6TUS will probably emulate GMPLS and switch from a time slot to another. This will also be visible and verifiable from the outside.
So will the 6TUS to 6TUS communication to establish and maintain time slots between peers. For all I know, this is a real layer.
How would you call it?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: mercredi 17 avril 2013 02:50
To: Michael Richardson
Cc: Thomas Watteyne; Alexandru Petrescu; [email-masked]; Qin Wang
Subject: Re: [6tsch] minutes WebEx 12 April 2013

Michael,

>From your email, my understanding is if there are bits in packet and reach outside the node, "Layer" should be more suitable. Correct?

In the current version of 6tus, both hard cell and soft cell are introduced. For reserving a cell in a schedule, especially soft cell, message exchanges between one-hop neighbors are needed. It is implemented with Information Elements (IE) in packet. In another word, you can see specific bits in packet, and also reaching outside a node. So, I don't understand why you think "API", instead of "Adaptation Layer", is suitable for the case.

Qin

> adaptation layer between TCP and Ethernet.  You can see it because 
> there are bits in the packet.
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Apr 2013 09:15:23 -0400

>>>>> "Qin" == Qin Wang <[email-masked]> writes:

    Qin> In the current version of 6tus, both hard cell and soft cell
    Qin> are introduced. For reserving a cell in a schedule, especially
    Qin> soft cell, message exchanges between one-hop neighbors are
    Qin> needed. It is implemented with Information Elements (IE) in
    Qin> packet. In another word, you can see specific bits in packet,

In every single data packet?
The same way that the IP header shows up underneath every single TCP
packet?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Apr 2013 09:20:26 -0400

>>>>> "pthubert" == pthubert  <Pascal> writes:
    pthubert> The action of the 6TUS scheduler is actually visible from
    pthubert> the outside if oine observes which frame ends up in which
    pthubert> time slot.  

That's nice.  The receiver doesn't need to know about the schedule 
(assuming that it's always on).  Look at this from a packet sniffer
point of view.

If it's an adaptation layer, then it needs to know it's there to skip
it.  If it's just a schedule, then there is nothing to know.

    pthubert> 6TUS will probably emulate GMPLS and switch
    pthubert> from a time slot to another. This will also be visible and
    pthubert> verifiable from the outside.  So will the 6TUS to 6TUS
    pthubert> communication to establish and maintain time slots between
    pthubert> peers. For all I know, this is a real layer.  How would
    pthubert> you call it?

The thing to establish and maintain the time slots is a protocol.
It could run over all sorts of transports.  That stuff isn't present in,
for instance, the packet that contains the CoAP traffic to turn on an actuator.

---

From: Pieter De Mil <[email-masked]>
Date: Thu, 18 Apr 2013 00:40:23 +0200

> The same way that the IP header shows up underneath every single TCP
Hi,

6tus will not add headers to data packets (data plane), IEEE 
802.15.4e-TSCH (aka the MAC or data link layer) will set its header.

For control packets, you'll see the Information Elements in the control 
packets.

I agree that it's not an "adaptation" *thing*, because we don't need to 
convert packets into something else. Adaptation of >L3 packets for IEEE 
802.15.4 data link layer is already done by 6LoWPAN. IEEE802.15.4e uses 
the same max PHY packet size as IEEE802.15.4 does (127 bytes).

Call it the "TSCH interface Specification for 6LoWPAN" (6TieS) because 
it will allow to interface between 6LoWPAN/RPL and a MAC mechanism 
(TSCH) only available in a specific link layer technology (i.e.. IEEE 
802.15.4e).

best regards,
Pieter
IBCN-iMinds

<http://tools.ietf.org/html/rfc3819>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 17 Apr 2013 22:49:29 -0700

Pieter,

Fully agreed. So if I can sum up, we have:

- 6tus does not add a specific header to packets in the data plane. So we
can not call it a "layer".
- 6tus does not transform bytes when it gets traversed (a la 6LoWPAN), so
it can not be called an "adaptation" xxx.

So basically we are saying that both terms "adaptation layer" are wrong :)

What we do know is:
- The 6tus thing of mote A talks to the 6tus thing of its neighbors mote B.
So there is a protocol involved.
- When this communication takes place, this protocol is carried in the IEs,
so the 6tus things somehow sits on top of IEEE802.15.4e.
- In a mote, the 6tus thing is associated some state.
- 6tus is used to manage the reservation of layer 2 resources.

So what about "6tus reservation protocol"?

Thomas

On Wed, Apr 17, 2013 at 10:48 PM, Thomas Watteyne <[email-masked]>wrote:

> Pieter,
>
> Fully agreed. So if I can sum up, we have:
>
> - 6tus does not add a specific header to packets in the data plane. So we
> can not call it a "layer".
> - 6tus does not transform bytes when it gets traversed (a la 6LoWPAN), so
> it can not be called an "adaptation" xxx.
>
> So basically we are saying that both terms "adaptation layer" are wrong :)
>
> What we do know is:
> - The 6tus thing of mote A talks to the 6tus thing of its neighbors mote
> B. So there is a protocol involved.
> - When this communication takes place, this protocol is carried in the
> IEs, so the 6tus things somehow sits on top of IEEE802.15.4e.
> - In a mote, the 6tus thing is associated some state.
> - 6tus is used to manage the reservation of layer 2 resources.
>
> So what about "6tus reservation protocol"?
>
> Thomas
>
>
> On Wed, Apr 17, 2013 at 3:40 PM, Pieter De Mil <[email-masked]> wrote:
>
>> **
>> 802.15.4 data link layer is already done by 6LoWPAN. IEEE802.15.4e uses the
>> same max PHY packet size as IEEE802.15.4 does (127 bytes).
>>
>> Call it the "TSCH interface Specification for 6LoWPAN" (6TieS) because it
>> will allow to interface between 6LoWPAN/RPL and a MAC mechanism (TSCH) only
>> available in a specific link layer technology (i.e.. IEEE 802.15.4e).
>>
>> best regards,
>> Pieter
>> IBCN-iMinds
>>
>>
> Thomas Watteyne, Ph. D
> Sr. Networking Design Engineer
> Dust Networks / Linear Technology
> 30695 Huntwood Ave
> Hayward, CA 94544-7021
> +1 (510) 400-2978
> [email-masked]
>
> This e-mail transmission, and any documents, files or previous e-mail
> messages attached to it may contain confidential information that is
> legally privileged. If you are not the intended recipient, or a person
> responsible for delivering it to the intended recipient, you are hereby
> notified that any disclosure, copying, distribution or use of any of the
> information contained in or attached to this transmission is STRICTLY
> PROHIBITED. If you have received this transmission in error, please
> immediately notify me by reply e-mail, or by telephone at (510) 400-2978,
> and destroy the original transmission and its attachments without reading
> or saving in any manner. Thank you.
>

---

From: <[email-masked]>
Date: Thu, 18 Apr 2013 09:15:24 +0000

Pitching in quite late...
This looks to me similar to what a routing protocol is w.r.t. the "network layer". Routing is not the full layer 3 by itself, it does not in general add to the data packet headers, but it *resides in* layer 3.
I view 6tus residing in layer 2.5.
One aspect I haven't seen discussed is whether the "thing" has state or not. To me an API does not contain state. I view 6tus as having state on its own.
"6tus xxx protocol" seems therefore appropriate to me to name our "thing".
My $0.02

Dominique

De : [email-masked] [mailto:[email-masked]] De la part de Thomas Watteyne
Envoyé : jeudi 18 avril 2013 07:49
À : IETF 6TSCH
Objet : Re: [6tsch] minutes WebEx 12 April 2013

Pieter,

- 6tus does not add a specific header to packets in the data plane. So we can not call it a "layer".
- 6tus does not transform bytes when it gets traversed (a la 6LoWPAN), so it can not be called an "adaptation" xxx.

What we do know is:
- The 6tus thing of mote A talks to the 6tus thing of its neighbors mote B. So there is a protocol involved.
- When this communication takes place, this protocol is carried in the IEs, so the 6tus things somehow sits on top of IEEE802.15.4e.
- In a mote, the 6tus thing is associated some state.
- 6tus is used to manage the reservation of layer 2 resources.

Thomas

On Wed, Apr 17, 2013 at 10:48 PM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Pieter,

- 6tus does not add a specific header to packets in the data plane. So we can not call it a "layer".
- 6tus does not transform bytes when it gets traversed (a la 6LoWPAN), so it can not be called an "adaptation" xxx.

What we do know is:
- The 6tus thing of mote A talks to the 6tus thing of its neighbors mote B. So there is a protocol involved.
- When this communication takes place, this protocol is carried in the IEs, so the 6tus things somehow sits on top of IEEE802.15.4e.
- In a mote, the 6tus thing is associated some state.
- 6tus is used to manage the reservation of layer 2 resources.

Thomas

On Wed, Apr 17, 2013 at 3:40 PM, Pieter De Mil <[email-masked]<mailto:[email-masked]>> wrote:
On 04/17/13 15:15, Michael Richardson wrote:

packet?
Hi,

6tus will not add headers to data packets (data plane), IEEE 802.15.4e-TSCH (aka the MAC or data link layer) will set its header.

For control packets, you'll see the Information Elements in the control packets.

I agree that it's not an "adaptation" *thing*, because we don't need to convert packets into something else. Adaptation of >L3 packets for IEEE 802.15.4 data link layer is already done by 6LoWPAN. IEEE802.15.4e uses the same max PHY packet size as IEEE802.15.4 does (127 bytes).

Call it the "TSCH interface Specification for 6LoWPAN" (6TieS) because it will allow to interface between 6LoWPAN/RPL and a MAC mechanism (TSCH) only available in a specific link layer technology (i.e.. IEEE 802.15.4e).

best regards,
Pieter
IBCN-iMinds

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

--
Thomas Watteyne, Ph. D
Sr. Networking Design Engineer
Dust Networks / Linear Technology
30695 Huntwood Ave
Hayward, CA 94544-7021
+1 (510) 400-2978<tel:%2B1%20%28510%29%20400-2978>
[email-masked]<mailto:[email-masked]>

This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2978<tel:%28510%29%20400-2978>, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 18 Apr 2013 06:39:34 -0700

If the "thing" is called "6tus xxx protocol", I would like to add "cell"
into it, e.g. "6tus cell reservation protocol", to distinguish from
protocols like RSVP.

How do you think?

Qin

> This looks to me similar to what a routing protocol is w.r.t. the "network
> layer". Routing is not the full layer 3 by itself, it does not in general
> add to the data packet headers, but it *resides in* layer 3.
> One aspect I haven't seen discussed is whether the "thing" has state or
> not. To me an API does not contain state. I view 6tus as having state on
> its own.
> On Wed, Apr 17, 2013 at 10:48 PM, Thomas Watteyne
> <[email-masked]<mailto:[email-masked]>> wrote:
> Pieter,
>
> On Wed, Apr 17, 2013 at 3:40 PM, Pieter De Mil
> <[email-masked]<mailto:[email-masked]>> wrote:
> will allow to interface between 6LoWPAN/RPL and a MAC mechanism (TSCH)
> only available in a specific link layer technology (i.e.. IEEE 802.15.4e).
>
> best regards,
> Pieter
> IBCN-iMinds
>
>
>
> immediately notify me by reply e-mail, or by telephone at (510)
> 400-2978<tel:%28510%29%20400-2978>, and destroy the original transmission
> and its attachments without reading or saving in any manner. Thank you.
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 18 Apr 2013 06:46:19 -0700

Hi, my little contribution.

6tus not only reserves, in a wider sense it manages schedule, queues, 
time parents, configuration of L2, provides feedback and keeps certain 
states

what about:

"6tus resource management protocol"

X