Re: [6tsch] About the special type of event to ask PCE to create a track

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 05 September 2013 07:25 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73BD21E808D for <6tsch@ietfa.amsl.com>; Thu, 5 Sep 2013 00:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.223
X-Spam-Level:
X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVX8fjzXw7U1 for <6tsch@ietfa.amsl.com>; Thu, 5 Sep 2013 00:25:19 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7083411E80C5 for <6tsch@ietf.org>; Thu, 5 Sep 2013 00:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27526; q=dns/txt; s=iport; t=1378365919; x=1379575519; h=from:to:cc:subject:date:message-id:mime-version; bh=T844wygLe6w031U26dCsnCeUeOdRRaxKFkA/mRGQlXo=; b=Z6CfscvkdzpZFzOfD4i8wgoALryV+bt/RDnNp/+Myf6p6TC4tADfLyDR /RlC3H7DzCxMNTW7tnfCMPP/NVdQMJvvZ+88b/jPN9PThcQ3kKu31peVy RzbiWLwZwVlf25ABoZLF//BixU/RI6+dHLp+Iwi2W1LIEH9wpO+UQ3cp0 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AukFACkxKFKtJXG9/2dsb2JhbABbDoI1RDVRuQWHNIENgSYWdIIkAQEBBAEBASo6BwsSAQgRBAEBCxYHLgsUCQkBBAENBQiHegy6K48vLQQGgx6BAAOFS4MykCeQN4JhP4Iq
X-IronPort-AV: E=Sophos; i="4.90,845,1371081600"; d="scan'208,217"; a="255873011"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 05 Sep 2013 07:25:18 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r857PH1O026610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 07:25:17 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 02:25:17 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Maria Rita PALATTELLA <maria-rita.palattella@uni.lu>, Qin Wang <qinwang@berkeley.edu>, "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
Thread-Topic: [6tsch] About the special type of event to ask PCE to create a track
Thread-Index: Ac6qCPYBexApk2NPS8iMgkcHuKbieA==
Date: Thu, 05 Sep 2013 07:25:16 +0000
Deferred-Delivery: Thu, 5 Sep 2013 07:25:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD84145A186@xmb-rcd-x01.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.84.215]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84145A186xmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] About the special type of event to ask PCE to create a track
X-BeenThere: 6tsch@ietf.org
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" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2013 07:25:25 -0000

Yes...

And the aim should be to make sure that the PCE has queued the request to build a track.
That request may be served asynchronously, considering that the PCE sometimes needs to defragment / reoptimize multiple flows, and it may stack some requests for a short while.
When the PCE is finally ready, it computes the track, and pushes it through an action flow; but I would consider that a different flow, not an embedded flow for the reason above.

Makes sense?

Pascal

From: Maria Rita PALATTELLA [mailto:maria-rita.palattella@uni.lu]
Sent: jeudi 5 septembre 2013 09:16
To: Pascal Thubert (pthubert); Qin Wang
Cc: Thomas Watteyne; 6tsch@ietf.org
Subject: RE: [6tsch] About the special type of event to ask PCE to create a track

It makes sense for me. Even though they are generated by different entities, they are both addressed to the PCE, and they have the same final aim.
Maria Rita

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Thursday, September 05, 2013 9:02 AM
To: Maria Rita PALATTELLA; Qin Wang
Cc: Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>
Subject: RE: [6tsch] About the special type of event to ask PCE to create a track

Fine with me Maria Rita,

But note that there is also a flow that fits the name "schedule flow" that is stimulated by the Net mgt Entity in the admin console as opposed to the mt entity in the device.
Same thing, this creates a req to the PCE to install a track. Do we want to merge those 2 flows? - I think so.

Cheers,

Pascal

From: Maria Rita PALATTELLA [mailto:maria-rita.palattella@uni.lu]
Sent: jeudi 5 septembre 2013 08:47
To: Pascal Thubert (pthubert); Qin Wang
Cc: Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>
Subject: RE: [6tsch] About the special type of event to ask PCE to create a track

I agree too. If we want to cut the name shorter, maybe we can just call it " Schedule Flow" (removing the update).
In the end, we know that this flow will happen when a node asks the PCE to update its schedule, and add/remove cells/tracks. What do you think?
Maria Rita

From: 6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org> [mailto:6tsch-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, September 05, 2013 7:29 AM
To: Qin Wang
Cc: Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>
Subject: Re: [6tsch] About the special type of event to ask PCE to create a track

+1

Pascal

Le 5 sept. 2013 à 00:10, "Qin Wang" <qinwang@berkeley.edu<mailto:qinwang@berkeley.edu>> a écrit :
Thomas,

I think "Flow" is a process to exchange messages for a given objective. For example, action flow consists of a Action Request from ME to 6top, and a Execution Confirm (Succ/Fail) from 6top to ME. But, "Schedule update request" looks like one step of a process. I would like to suggest that the 5th flow is called "Schedule update flow", consists of a "Schedule update request" from node to PCE, and something like "Track/cell installation" from PCE to node.

Make sense?
Qin

On Thu, Sep 5, 2013 at 5:29 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>> wrote:
I would agree that a 5th flow makes sense, especially because it allows us to use different transport mechanisms for the report flow (CoAP?) and this new flows (CoAP now? maybe PCEP later?).

Do what do we call this new flow? "Schedule update request" is a bit long.

Thomas

On Wed, Sep 4, 2013 at 2:12 PM, Qin Wang <qinwang@berkeley.edu<mailto:qinwang@berkeley.edu>> wrote:
Hi Thomas,

Thanks for your explanation. You are saying the request packet from node is generated by the upper layer of 6top, correct?

If so, since the request packet is generated by upper layer of 6top, instead of 6top internal events like alarm, I think it is reasonable to add the 5th control flow.

What do you think?

Qin

On Wed, Sep 4, 2013 at 10:12 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>> wrote:
Qin,

Thanks for bringing that up. Allow me to answer in Pascal's place. We are talking about the format of the packets exchanged between the ME and the nodes. In the centralized case, these are application-level packets, i.e. packet generated by an entity a couple of layer above 6top. That entity talks with the PCE over the network, and with 6top through the API (internal to the node) as defined in http://tools.ietf.org/html/draft-wang-6tsch-6top-00#section-2.4.

If we agree on that, the question is whether the packet the node sends to establish a new track is part of the event flow, or not. In both cases, it would originate from this application-level entity, but possibly transported in different ways.

Thomas

On Fri, Aug 30, 2013 at 11:01 AM, Qin Wang <qinwang@berkeley.edu<mailto:qinwang@berkeley.edu>> wrote:
Hi Pascal,

My understanding is that 6top is a passive role in dealing with cell/track reservation. In another word, the 6top in a node can report its state, including neighbor table, cell usage, and other statistics information, but can not make decision on if some cells/track should be added or removed, which should be the responsibility of PCE in centralized case or upper layer in distributed case. Thus, I can not see when the 5th flow will be used. Can you explain more?

Thanks
Qin

On Sat, Aug 31, 2013 at 12:08 AM, Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
Dear all,

We discussed at the call that the(PCEP?) request to ask for a track establishment could be seen as an event, or could be a new flow.
At the call, I suggested that it could be a new, 5th flow. My arguments are that this flow:
- Probably yields different data format. The demand carries and points, end to end latency and bandwidth. That's quite specific.
- Probably yields a different flow. Events do not necessarily have a response.
- Probably uses a different transport as well (PCEP vs. CoAP)

What do you think?

Pascal
_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch


_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch



_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch