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

Thomas Watteyne <> Tue, 10 September 2013 04:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC20C11E8177 for <>; Mon, 9 Sep 2013 21:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.482
X-Spam-Status: No, score=0.482 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SM-ouUd1H5PH for <>; Mon, 9 Sep 2013 21:24:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::231]) by (Postfix) with ESMTP id 5778311E8178 for <>; Mon, 9 Sep 2013 21:23:57 -0700 (PDT)
Received: by with SMTP id xb4so6925483pbc.8 for <>; Mon, 09 Sep 2013 21:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=WJWNrCpUsSC/omQ5x9zpImS46ei5K5ulXBKN/yZacXw=; b=XD5I8l3v6mIw+sN5RsBv9ha1/3p0KDpKaG5s9D0yB08CLpb2C2Upb4dTJq30tODb4X RGcAcYKDRUBetWmcbze1G1hDvz8COsysAxPodmMgZbvnIq0UFOtW4cJxHgCjQZt/DOte ef3gH/NLZX6PdPB6AQMR4C6oJC9qFY9vw+t31J1osMD0DMPchlMy4l2xnTbg72SPjqlL 4NP8tpxrWQ27zFVCbbPqzQv8FsKM5lQ3wo91eRu+2yqknP8U7z5tsDlQI+QZZPdaw522 HkG8Z2TKrtzWQ7c5LF241bfVOtyekG/7eFXBrnACkxtORjp0/efsDmY2CNpUYuasj0lV 8MHw==
X-Received: by with SMTP id rv11mr24179527pab.17.1378787037054; Mon, 09 Sep 2013 21:23:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 9 Sep 2013 21:23:33 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Thomas Watteyne <>
Date: Mon, 9 Sep 2013 21:23:33 -0700
X-Google-Sender-Auth: JgXW2Ja1ViFSua0Z2LRyCV1i-L0
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary=001a11331e46908afa04e5ffdf0f
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 04:24:09 -0000


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?
> Qin
> _______________________________________________
> 6tsch mailing list