Re: [6tsch] Is generic management method possible?

Maria Rita PALATTELLA <> Tue, 10 September 2013 06:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F5E021F9BF2 for <>; Mon, 9 Sep 2013 23:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5bRaIUudvV+U for <>; Mon, 9 Sep 2013 23:45:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A75EB21E8089 for <>; Mon, 9 Sep 2013 23:45:55 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.90,876,1371074400"; d="scan'208,217"; a="26399526"
Received: from unknown (HELO Travis.uni.lux) ([]) by with ESMTP; 10 Sep 2013 08:45:52 +0200
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Tue, 10 Sep 2013 08:45:52 +0200
From: Maria Rita PALATTELLA <>
To: Thomas Watteyne <>, "" <>
Thread-Topic: [6tsch] Is generic management method possible?
Thread-Index: AQHOrZ9gJnQwv5tFIU23+WZxyf9O+Zm+Pj+AgABHoOA=
Date: Tue, 10 Sep 2013 06:45:51 +0000
Message-ID: <F085911F642A6847987ADA23E611780D1859AB93@hoshi.uni.lux>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, en-GB
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D1859AB93hoshiunilux_"
MIME-Version: 1.0
Subject: Re: [6tsch] Is generic management method possible?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Sep 2013 06:46:01 -0000

Qin, I agree too about defining the formats in a way that we can reuse them for the distributed case. But, for the time being, I would be focused on the centralized approach and try to find a solution for it. And then, move to the distributed one (that for sure will raise other issues up).
Let's try to solve the problems one by one!
Maria Rita

From: [] On Behalf Of Thomas Watteyne
Sent: Tuesday, September 10, 2013 6:24 AM
Subject: Re: [6tsch] Is generic management method possible?


I fully agree that being able to reuse some formats in the distributed case is important. The question about the exact protocol to use for negotiation between neighbors in the distributed case is a very broad one. It is too early to discuss that. We can, however, keep the distributed case in mind when proposing formats.


On Mon, Sep 9, 2013 at 1:57 PM, Qin Wang <<>> wrote:
Hi All,

In the previous discussion, we have figured out 5 control flows between PCE and node, which were expressed in the context of centralized case. Obviously, it will be great if the messages in those identified control flows are generic, suitable for both centralized and distributed case. During last Friday's call, it was mentioned but is still a open issue. I propose to continue the discussion in this thread.

Comparing the role of PCE in centralized case,I think RSVP/NSIS will play similar role in distributed case. In another word, instead of exchanging message with PCE via a network, 6top Management Entity will exchange message with a Reservation Entity like RSVP/NSIS inside the same node. The question is if it is possible to use same design in the two cases.  (I'm not expert on RSVP and NSIS, please input your opinions).

Firstly, I think the contents of messages in the centralized and distributed case are overlap in a big portion. For example, both of them need to send action flow, both of them need statistics data, and so on.

Secondly, in terms of Message Exchange, the two cases are similar. The only difference is, in centralized case, the control messages are carried by CoAP as payload; and in distributed case, the control messages are "sent" via internal pointer.

Make sense?


6tsch mailing list<>